[DRBD-user] DRBD 0.7.5 & LVM2 on 2.4.27

Lars Ellenberg Lars.Ellenberg at linbit.com
Mon Oct 4 14:34:41 CEST 2004

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

/ 2004-10-04 01:10:28 -0700
\ Tim Hasson:
> Hello Drbd'ers,
> I just setup ext3 on LVM2 on top of DRBD 0.7.5 on a single node, to hopefully
> put it in production soon (second node will come later in the next week or
> two)
> Everything went through fine and both drbd volumes (drbd0 and drbd1) come up as
> master and shows consistent.
> I had then created a pv on each of the two scsi disks (~35GB each)
> Then I created the vg and then created the lv.
> Then I run "/sbin/vgscan" (no problems so far)
> Finally, I run "/sbin/vgchange -a y" to activate my volume which reports
> success, but along I get some drbd warnings in syslog, just right after I run
> "vgchange". This also happens at shutdown - when deactivating volume groups
> ("/sbin/vgchange -a n")
> I can mount the drive, write to it, and everything looks fine. But I am
> wondering why these _initial_ warnings/errors? Is this bad?
> Oct  4 00:57:32 srv1 kernel: drbd0: ASSERT( !buffer_uptodate(bh) ) in
> drbd_compat_wrappers.h:247

well use a 2.6 kernel and be happy.
in out submit function I put in some asserts about the buffer being
submitted for write contains data, is not uptodate, needs writing, ...
some users of blockdevices seem not to care at all, and happily submit
buffers to block device that pretend to be clean.
but since these buffer flags actually are only meaningfull to the cache
and the rest of the block io stack does not care either,
we should probably remove those asserts, which will quiten out the log

this is nothing to worry about, though, just a log message.

an additional note, though.

make sure that if you failover, you failover BOTH pvs...

to simplify management, you could put a linear mapping on both
lower level devices first, then put drbd on top of that linear mapping,
and then put your lvm2 vg on top of that single drbd.
but then don't use "drbd internal meta data" on that, if you think about
later maybe adding more harddisks to the lower linear mapping and
resizing the drbd device.
but maybe "just a wrapper script" will do, too.

	Lars Ellenberg

please use the "List-Reply" function of your email client.

More information about the drbd-user mailing list