[DRBD-user] STRANGE ISSUE - disk partition deleted after resync

Roberto Fastec roberto.fastec at gmail.com
Thu Jul 22 18:03:31 CEST 2010

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


I'm doing my first tests with drbd.
My configuration is two pcs with two hdd each.
One drive is xenserver the second is drbd dedicated. On the drbd dedicated
drive, I created /dev/sdb1 which in drbd.conf is assigned to drbd0.

Well, because it is a test environment, I messed up the things a bit and so
I had to erase drbd0 (which still is not clear to me which is the correct
procedure, but I did it) and, to be sure, I also deleted and recreated
/dev/sdb1.

The idea was to start over with the creation of drbd0 resource.

The first issue I had was about one error that was exiting the command *drbdadm
create-md drbd0*. Googleing I've found the solution was to (I'm not so
strong with dd) issue this command *dd if=/dev/zero bs=1M count=1
of=/dev/sdb; sync*, looks like that first 1MB data are moved (?), anyway
this worked.

Then *drbdadm create-md drbd0*  worked again and I finished the sequence
# drbdadm create-md drbd0    #Create device metadata
# drbdadm attach drbd0        #Attach to backing device
# drbdadm syncer drbd0        #Set synchronization parameters
# drbdadm connect drbd0        #Connect to peer

last I launched the primary command and started the sync
# drbdadm -- --overwrite-data-of-peer primary drbd0

and the sync worked fine, with a final average speed of 81MB/sec, in 35
minutes the 200GB volume was synced, I also copied and pasted to my notes
the cat /proc/drbd command result while syncing
[root at xenserver-2 dev]# cat /proc/drbd
version: 8.3.8.1 (api:88/proto:86-94)
GIT-hash: 0d8589fcc32c874df57c930ca1691399b55ec893 build by
root at localhost.localdomain, 2010-07-17 10:04:02
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r----
    ns:935040 nr:0 dw:0 dr:11435392 al:0 bm:697 lo:145 pe:0 ua:145 ap:0 ep:1
wo:b oos:183876844
        [>...................] sync'ed:  5.9% (179564/190732)M
        finish: 0:34:18 speed: 89,308 (76,232) K/sec

when finished, it was late night and so I turned off the secondary, last the
primary and I went at home.

Now I'm here to go on with my tests. Turned on the primary, turned on the
secondary and with my big surprise, I've found this

[root at xenserver-2 ~]# drbd-overview
  0:drbd0  Unconfigured . . . .

so I also lauched cat /proc/drbd

[root at xenserver-2 ~]# cat /proc/drbd
version: 8.3.8.1 (api:88/proto:86-94)
GIT-hash: 0d8589fcc32c874df57c930ca1691399b55ec893 build by
root at localhost.localdomain, 2010-07-17 10:04:02
 0: cs:Unconfigured

so I issued

[root at xenserver-2 ~]# drbdadm up drbd0
Can not open device '/dev/sdb1': No such file or directory
Command 'drbdsetup 0 disk /dev/sdb1 /dev/sdb1 internal --set-defaults
--create-device --max-bio-bvecs=1 --on-io-error=detach' terminated with exit
code 20
drbdadm attach drbd0: exited with code 20

and because of the message, I checked with fdisk -l

[root at xenserver-2 ~]# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         523     4194304   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2             523        1045     4194304   83  Linux
/dev/sda3            1045       60801   479995393   8e  Linux LVM

Disk /dev/sdb: 1000.2 GB, 1000215724032 bytes
255 heads, 63 sectors/track, 121602 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdb doesn't contain a valid partition table

Yes it is, /dev/sdb1 is disappeared... on both computers...

Below you find the drbd.conf.

My question are:
- which is the correct mode to erase one drbd resource ?
- is it possible what described above?
- to be able to do such "disaster" (I'm thinking about a production
environment), what could be the error/mistake?
- with the following configuration file, both the drbd are starting in
secondary mode, maybe this is wanted by drbd concept, but I can't understand
it very well.
I mean, when everything works fine, I have one primary and one secondary.
If I do a clean shutdown and I shut down first of all the secondary, next I
shut down the primary, why starting up first the primary and last the
secondary both of them are secondary? Is it the only solution
*become-primary-on
server-1* statement? If yes... I have another issue.. this didn't worked...
and powercycling the two pcs in the correct order, again returned a
secondary/secondary situation.
- Is it correct to use the server name in the following statement
*become-primary-on
server-1* ?
- Which are the downsides of usignthis setting in the drbd.conf:
*become-primary-on
server-1* ?

Thank you for any tip and help, follows the conf file
Robert


drbd.conf

# You can find an example in  /usr/share/doc/drbd.../drbd.conf.example

#include "drbd.d/global_common.conf";
#include "drbd.d/*.res";

global {
    usage-count yes;
    }

common {
    syncer {
        rate 1G;
        verify-alg md5;
        csums-alg md5;
        }
    }

resource drbd0 {
    protocol C;

    startup {
        #become-primary-on xenserver-2;
    }

    net {
        cram-hmac-alg md5;
        shared-secret "ColdWater";
        sndbuf-size 0;
        rcvbuf-size 0;
        data-integrity-alg md5;
    }

    disk {
        max-bio-bvecs 1;
        on-io-error detach;
    }

    on server-1 {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 10.1.1.2:7789;
        meta-disk internal;
    }

    on server-2 {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 10.1.1.3:7789;
        meta-disk internal;
    }

    handlers {
        split-brain "/usr/lib/drbd/notify-split-brain.sh root";
    }

}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20100722/bca297a3/attachment.htm>


More information about the drbd-user mailing list