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
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
