Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, Jan 14, 2008 at 06:11:38PM +0100, Tomasz Chmielewski wrote: > Lars Ellenberg schrieb: > >On Mon, Jan 14, 2008 at 05:29:01PM +0100, Tomasz Chmielewski wrote: > >>After a couple of days of struggling I got to the point where I have to > >>conclude that using LVM reliably over DRBD devices is impossible. > > > >after a couple of seconds of contemplating I got to the point where I > >have to conclude that this would mean that a non-negligible number of > >our managed production deployments are impossible, there for non > >existent. I wonder why I hear no customer complaints, though. > > ;) > > Did any of them use dm-crypt? :) > > > >>7. pvs confirms it - LVM sits on /dev/sdb, not on /dev/drbd0 - > >>certainly, nothing will be replicated by DRBD: > > > >as pointed out earlier, you have to fix your lvm conf, specifically the > >filter setting. if you don't, it won't work. > > That I know. > How I don't :| > > > >>As device names are not necessarily persistent (if /dev/sdb is a iSCSI > >>drive, next time one boots it can be /dev/sdc) and a similar is for > >>device mapper devices (think of crypted devices), setting up filters in > >>lvm.conf will not be reliable. > > > >you did hear about udev and scsi id, did you? > > For iSCSI, true, I could use a link like /dev/iscsi/blah -> /dev/sdX and > put that /dev/iscsi/blah as a filter for lvm.conf. > > dm-crypt devices don't have any ID or anything unique (that I know). you are supposed to be able to pass wanted major/minor numbers to dmsetup. lvm e.g. is able to provide "persistent minors" (persistent major theoretically only "mostly", not strictly, with kernel 2.6, though for al practical purposes I found that to be good enough, you get the same major anyways) > 2. On system startup, find out which one of /dev/dm-XY devices is our > crypted device. How to do it? If the device has unique size, just parse > the output of fdisk -l. If there are multiple devices with the same > size, it gets problematic. you could also use dm-crypt on top of drbd, instead of below it? I guess that would be the easiest way. > This way, by choosing a correct metadata format, one can be sure of data > integrity - with metadata at start, mounting or using an underlying > device accidentally is impossible. > > Storing DRBD metadata at the beginning of the device would effectively > make some administration tasks easier (no need to write custom scripts > for detecting correct dm-XY device) and/or more reliable (not possible > to mount or use a device accidentally) - this thread wouldn't have to > exist I guess (and some of split-brain posts as well, I guess). drbd was designed to be transparent on purpose. if you want it to be offset, put some strange dm linear mapping below it (you tried that with your kpartx "partitions" already). -- : Lars Ellenberg http://www.linbit.com : : DRBD/HA support and consulting sales at linbit.com : : LINBIT Information Technologies GmbH Tel +43-1-8178292-0 : : Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 : __ please use the "List-Reply" function of your email client.