linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: David Timms <dtimms@iinet.net.au>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] lvm fails trying to expand an LV into available space in VG.
Date: Fri, 20 Jul 2007 00:44:13 +1000	[thread overview]
Message-ID: <469F78BD.9030908@iinet.net.au> (raw)
In-Reply-To: <469F6C41.3070601@redhat.com>

Bryn M. Reeves wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> group.
> 
> 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.
Hmmn, sounds like a good addition for the howto / FAQ !

I wonder if system-config-lvm has any tests for subprocesses taking to 
long, that might cause it to time before the process finishes ?

If the many of the existing pv assigned to the vg are full {0 bytes 
free}, could it cause the resizing of the lvm to fail due to no space to 
put more metadata ?

> 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
> shorter.
Does value 1 means the original plus 1 copy, or only 1 copy total ?

...
> Now recreate all the PVs except those that you want to contain metadata
> with their original UUIDs and the --restorefile and --metadatacopies=0
> flags:
> 
> # pvcreate --uuid=$UUID --restorefile=/etc/lvm/backup/<VolGroup>
> - --metadatacopies=0 /dev/$DEVICE
Does this keep or trash the filesystem {ext3} within the lv that takes 
of most of this vg ?

Can I actually recreate the PVs without losing data ?

> Next create the metadata-holding PVs:
> 
...
> The last time I had to do this was on a VG with 100 PVs,
Had you created 100PV's during development / testing, or was that a live 
system ? How long did the scan take ?

> 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.
Will do, hopefully it means finger errors wont trash the data.

Thanks, DavidT

      reply	other threads:[~2007-07-19 14:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-12 19:45 [linux-lvm] s-c-lvm fails trying to expand an LV into available space in VG David Timms
2007-07-12 20:10 ` James Parsons
2007-07-19 13:10   ` [linux-lvm] lvm " David Timms
2007-07-19 13:50     ` Bryn M. Reeves
2007-07-19 14:44       ` David Timms [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=469F78BD.9030908@iinet.net.au \
    --to=dtimms@iinet.net.au \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).