Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Sat, Nov 12, 2011 at 11:06:17AM -0700, David Mohr wrote: > On Sat, 12 Nov 2011 13:15:35 +0100, Lars Ellenberg wrote: > >On Fri, Nov 11, 2011 at 03:33:33PM -0700, David Mohr wrote: > <snip> > >>>Device size would be truncated, which > >>>would corrupt data and result in > >>>'access beyond end of device' errors. > >>>If you want me to do this, you need to zero out the first part > >>>of the device (destroy the content). > >>>You should be very sure that you mean it. > >>>Operation refused. > >>> > >>>Command 'drbdmeta 0 v08 /dev/sdb1 internal create-md' terminated > >>>with exit > >>>code 40 > >>>drbdadm create-md vm1: exited with code 40 > >>> > >>I'm assuming drbd sees the lvm that is contained _within_ this > >>resource and bails out. > >> > >>What would be the best course of action to make the additional > >>storage space available? > > > >drbdmeta create-md detects the LVM meta data signature, > >and calls out to pvs to do the meta data parsing. > >Your filter in lvm.conf correctly tells pvs to ignore sdb1, > >so drbdmeta can not determine the size, and plays it safe. > > > >If you invoke it like so: > >LVM_SYSTEM_DIR= drbdadm create-md vm1 > > > >pvs will not find your lvm.conf, > >default to it's builtin filter settings, > >which should allow it to read and parse the LVM meta data block. > >drbdmeta should then figure that the currently used space is much > >less > >than the device size, and that it is ok to create the meta data. > > Ah interesting to know! We will probably give it another shot then. > > So while I am already asking questions, we were trying to do a > mixture of off-line and online resize: > - Take node 1 offline, resize the partition, move the metadata to > the correct place, then bring it back online > - Do the same for the other node > - Then run an on-line resize > > Given my limited experience with drbd and resizing this should work, > right? DRBD will notice the new available space on its own in that case. You only need to pvresize /dev/drbd0 then. > > >>We are trying to avoid version upgrades as > >>much as possible since this is a production system (yes, I realize > >>it was failure on our part to not get everything setup right away). > >>I could live with upgrading drbd to 8.3.8, > > > >You should upgrade to 8.3.12, actually. > >Which, btw, also can do up to 1 Petabyte per device, > >if you are 64bit and got enough RAM to store the bitmap. > > We have a decent amount of RAM so it would be tempting to get the > whole space online. > > Another advantage of the upgrade would be the check-resize -- which > should automate the export-md/restore-md commands as far as I > understand it. > > >>but we're on 2.6.34 and 8.3.8 recommends a newer kernel. > > > >Huh? What makes you think so? > > This page did: http://www.drbd.org/download/mainline/ DRBD was an out-of-tree module for a long time. It was accepted into mainline in 2.6.33, with the then out-of-tree version equivalent of 8.3.7. As DRBD evolved, newer mainline linux releases include newer DRBD code, and that table states the mainline linux release vs out-of-tree DRBD release version equivalent. We did not try to push newer DRBD releases into "stable" revisions of older linux releases, given that you can simply upgrade via the out-of-tree module, if you so chose. > Or what's the recommended procedure for using a newer drbd version > with an older kernel? DRBD still is available as out-of-tree module, just grab the 8.3.12 tarball, and build both userland and kernel module. > ~David > > P.S. I must say, drbd is extremely nice to work with. It really > seems to be doing the "right thing" all the time, which is very nice > when you value your data. So thanks! Also availalbe as prebuild packages for LINBIT customers, maybe one of our subscription or support offerings ... ;) -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com