[linux-lvm] lvm fails trying to expand an LV into available space in VG.

Bryn M. Reeves breeves at redhat.com
Thu Jul 19 13:50:57 UTC 2007

Hash: SHA1

David Timms wrote:
> James Parsons wrote:
>> Hi - I'm the s-c-lvm guy; this will take a bit to digest. Just wanted
>> to let you know you were heard.
>> Yes, 3 minutes to scan for state seems a bit abnormal :)  
> Actually, its more like 5-6 minutes (I get bored waiting and start doing
> other stuff). During boot up it takes about 8 seconds to activate the
> lvm volumes.

Nothing to do with the s-c-lvm problem, but these times sound perfectly
normal if you have a metadata area on each of the 25 PVs in the volume

By default, pvcreate will set each PV up with a single metadata area
(MDA). This is fine for small volume groups but will kill tool
performance for volume groups with large numbers of PVs since the
runtime grows as something like N^3 in the number of metadata areas.

Note that it's only tool performance that suffers - I/O performance is
not affected.

You can prevent this by creating most of the PVs in such a VG with the
option "--metadatacopies=0" on the pvcreate command line. Create a small
number with either "--metadatacopies=1" (or just use the default - it's
1 anyway) and you should find the time to scan/activate the VG is much

It's possible to fix this in-place without destroying the VG but you
need to be a little careful; it'd be wise to back up anything important
first in case things don't work out.

First, deactivate all volumes in the group and backup the metadata:

# vgchange -an <VolGroup>
# vgcfgbackup <VolGroup>

Now recreate all the PVs except those that you want to contain metadata
with their original UUIDs and the --restorefile and --metadatacopies=0

# pvcreate --uuid=$UUID --restorefile=/etc/lvm/backup/<VolGroup>
- --metadatacopies=0 /dev/$DEVICE

Next create the metadata-holding PVs:

# pvcreate --uuid=$UUID --restorefile=/etc/lvm/backup/<VolGroup>
- --metadatacopies=1 /dev/$DEVICE

And finally restore the metadata:

# vgcfgrestore <VolGroup>

The last time I had to do this was on a VG with 100 PVs, I used a script
that parsed the output of pvs to automate all this stuff. Drop me a line
off-list if you're interested & I'll see if I can pull it up.

Kind regards,

Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the linux-lvm mailing list