[DRBD-user] Delayed replication /w Protocol C?

[c smith]

Hi-

I'm experiencing a strange issue with DRBD not following protocol C and
replication happening long after local writes are complete. If, for example,
I've got /dev/drbd0 mounted at /mnt with an ext3 filesystem, `dd
if=/dev/zero of=/mnt/test.zero bs=1000M count=1` will write the file at
local speeds and complete long before DRBD replicates any of it (or as far
as I can see by watching /proc/drbd)  It sometime takes as long as 10s
before there is any activity in /proc/drbd.

I've only observed this happening when I write to a file system on a DRBD
resource or using a Xen VM dependent on DRBD (both phy: and file:
configurations).  If I write directly to the /dev/drbdXX device, /proc/drbd
reports replication is taking place when it should and writes do note
complete until after activity in /proc/drbd has stopped.

My aim is to map DRBD resources to LVs. I have done some testing using both
LVs and physical partitions as DRBD resources' devices and have found the
same results.  I'm using 8.3.1 compiled against 2.6.27.21-0.1-xen on
OpenSUSE 11.1.  From what I can tell there must be something  else on a
higher level messing with replication but I can't for the life of me think
of what it might be. I haven't seen anything out of the ordinary in log
files.  After data is finally replicated, files check out okay on the other
node but this is not the behavior I was expecting.  Attached is a copy of
the most recent test drbd.conf. Thanks

Any assistance would be greatly appreciated,
CSMITH

global { usage-count no; }
resource test {
        protocol C;
        net     { shared-secret "test"; }
        syncer { rate 100M; }
        on node1 {
                device /dev/drbd10;
                disk /dev/sdb4;
                address 192.168.100.2:7795;
                meta-disk internal;
        }
        on node2 {
                device /dev/drbd10;
                disk /dev/sdb4;
                address 192.168.100.1:7795;
                meta-disk internal;
        }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090509/fd85b823/attachment.htm>