Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> > Hmm, I just tried it with above mentioned error corrected and got to > same result: > > A: /sbin/drbdsetup 5 disk /dev/mapper/obrazy-vvsys5 > /dev/mapper/obrazy-vvsys5 internal --set-defaults --create-device > A: /sbin/drbdsetup 5 primary > B: /sbin/drbdsetup 5 net 192.168.1.192:19005 192.168.1.191:19005 C -m > --create-device > A: /sbin/drbdsetup 5 net 192.168.1.191:19005 192.168.1.192:19005 C -m > --create-device > > ... wait until connection is established (about 1 second) > > B: /sbin/drbdsetup 5 primary > > After that connection is dropped immediately and dmesg shows the same > thing I pasted in previous e-mail. (Re-establishing the connection takes > about 1 second in this case.) > > Any ideas? Looks like I finally managed to figure out where the problem (bug?) is - things go bad only when DRBD device doesn't use all storage space available to it. Example: I want a DRBD device with size 1000MB (exactly) with internal metadata, so I calculate space needed for metadata and create LVM partition to accommodate it: A: lvcreate -L 1001M -n test images Rounding up size to full physical extent 1004.00 MiB Logical volume "test" created A: drbdadm 248 v08 /dev/mapper/images-test internal create-md Simple attach would use extra space, I don't want that, so in drbdsetup disk I specify exact size with -d : A: drbdsetup 1 disk /dev/mapper/images-test /dev/mapper/images-test \ internal --set-defaults --create-device -m -d 1000M A: drbdsetup 1 primary Then I create diskless peer with: A: drbdsetup 1 net 192.168.1.191:19001 192.168.1.192:19001 \ C -m --create-device B: drbdsetup 1 net 192.168.1.192:19001 192.168.1.191:19001 \ C -m --create-device And make the peer primary B: drbdsetup 1 primary After that device disconnects and reconnects again with errors in dmesg mentioned earlier. However even after reconnect /dev/drbd1 is unusable on B: B: cat /dev/drbd1 >/dev/null cat: /dev/drbd1: Input/output error With disconnect - reconnect cycle repeating itself. The problem seems to be in this: A: blockdev --getsize64 /dev/drbd1 1048576000 But: B: blockdev --getsize64 /dev/drbd1 1052700672 Looks to me B determines size of DRBD device from the size of A's underlying storage instead of actual size of DRBD device on A. That in turn causes problems, when some process on B is trying to actually use the device. Trying to solve this I looked for a way to specify DRBD size in drbdsetup net, but no luck. The problem can be worked around by creating LVM on B temporarily and forcing the correct size in drbdsetup disk command, but I still think current behaviour is buggy (fixing it is, however, out of my league) Didn't manage to find where to report bugs, so I hope someone will pick it up here. Running kernel 2.6.37. Regards JB