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

c smith smith.c.tech at gmail.com
Mon May 11 05:28:50 CEST 2009

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


Lars-
Thanks.  Page cache was what I had assumed was going on and I've since
altered my dd commands and have noted the expected activity in /proc/drbd.
Performance is satisfactory.  Now my question is, what can be done to ensure
data integrity on node2?  I've scanned the mailing list for related threads
and from what I've gathered it is the application's responsibility--not
DRBD's.  This makes perfect sense but I wonder what is the common way to
deal with this when integrating DRBD? Does it require kernel modification or
reconfiguration of our RAID system or something else?   My goal is to put
Xen VMs ontop of DRBD for replication to a remote location.  I know this is
a very common and widely deployed setup so there must be solution.  Any
hints, clues or advice would be greatly appreciated.

CSMITH


On Sun, May 10, 2009 at 9:22 AM, Lars Ellenberg
<lars.ellenberg at linbit.com>wrote:

> On Sat, May 09, 2009 at 08:29:22PM -0700, c smith wrote:
> > 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.
>
> man fsync
>
> > 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.
>
> page cache
>
>
> --
> : Lars Ellenberg
> : LINBIT HA-Solutions GmbH
> : DRBD®/HA support and consulting    http://www.linbit.com
>
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> __
> please don't Cc me, but send to list   --   I'm subscribed
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090510/00c1aa38/attachment.htm>


More information about the drbd-user mailing list