[DRBD-user] Best option to resize without underlying lvm?

David Mohr david at mcbf.net
Sat Nov 12 19:06:17 CET 2011

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, 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?

>> 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/

Or what's the recommended procedure for using a newer drbd version with 
an older kernel?

~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!



More information about the drbd-user mailing list