linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "Bryn M. Reeves" <bmr@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] shrink VG and PV
Date: Tue, 18 May 2010 10:13:36 +0100	[thread overview]
Message-ID: <4BF25A40.7060304@redhat.com> (raw)
In-Reply-To: <4BF225AE.3080303@gmail.com>

On 05/18/2010 06:29 AM, kanonmatswe wrote:
> On 05/17/2010 11:30 PM, Stuart D. Gathman wrote:
> 
>> Conclusion: always use only one metadata area per PV (but on multiple PVs
>> when available).
> 
> I don't know how that second metadata area got there :)  I don't think I'm using it or will have any use for it.
> So there is no way of erasing it? If I do "backup VG, redo pvcreate with uuid&  restorefile, restore VG"
> as Alasdair said as quoted by malahal@us.ibm.com, I will erase all data, right? The solution seems to be
> roughly equivalent to backing up all data and then repartition before copying back?

No - if you carry this out correctly the data area of the drive will be
unchanged and in the final step you restore the current content of the
VG metadata to the one remaining metadata area rendering any previously
created LVs (and their contents) accessible.

You can find an example of the basic steps to re-pvcreate a PV and
restore metadata to it here:

https://www.redhat.com/archives/linux-lvm/2009-January/msg00014.html

You'll want to follow the same kind of process but make sure you add
--metadatacopies=1 to avoid recreating the PV with two copies. If you're
not sure how you ended up with this you might want to review what's in
your /etc/lvm/lvm.conf - there is a pvmetadatacopies directive in the
metadata section that can be used to set the default number of metadata
areas for new PVs:

# metadata {
 # Default number of copies of metadata to hold on each PV.  0, 1 or 2.
 # You might want to override it from the command line with 0
 # when running pvcreate on new PVs which are to be added to large VGs.
 # pvmetadatacopies = 1
[...]

Once you have done this you should be able to issue pvresize with
--physicalvolumesize as in your first post to reduce the space used by
LVM2. Once that's done you can shrink your sda2 partition (note that
this last step will likely still need a reboot - the kernel is still not
at all happy about modifying in-use partitions, even for shrinking).

Regards,
Bryn.

  reply	other threads:[~2010-05-18  9:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-17 19:44 [linux-lvm] shrink VG and PV Dael Elcar
2010-05-17 20:56 ` Malahal Naineni
2010-05-17 21:14 ` Malahal Naineni
2010-05-17 21:30   ` Stuart D. Gathman
2010-05-18  5:29     ` kanonmatswe
2010-05-18  9:13       ` Bryn M. Reeves [this message]
2010-05-18  9:38         ` Bryn M. Reeves

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=4BF25A40.7060304@redhat.com \
    --to=bmr@redhat.com \
    --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).