[DRBD-user] Best option to resize without underlying lvm?
lars.ellenberg at linbit.com
Sat Nov 12 21:02:34 CET 2011
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:
> >>>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
> >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,
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.
> 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
More information about the drbd-user