* [linux-lvm] shrink VG and PV
@ 2010-05-17 19:44 Dael Elcar
2010-05-17 20:56 ` Malahal Naineni
2010-05-17 21:14 ` Malahal Naineni
0 siblings, 2 replies; 7+ messages in thread
From: Dael Elcar @ 2010-05-17 19:44 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]
My system is archlinux i386. lvm version 2.02.62(1) (2010-03-09)
I'd like to shrink a partition with lvm on it. Can this be done? In order to
shrink it I need to reduce the size of the PV, right? I have successfully
removed an LV (from the end on the VG) and there is no mention of it with
lvdisplay or in the file i get with vgcfgbackup. I think the next step is to
reduce the size of the VG and remove the now unallocated 3884 PEs from it. I
can't find a command for that. I have tried pvresize. How do I solve the
problem with "metadata areas"? vgdisplay says VG Status is "resizable".
pvresize /dev/sda2 --test --setphysicalvolumesize 49256M
Test mode: Metadata will NOT be updated.
/dev/sda2: too many metadata areas for pvresize
0 physical volume(s) resized / 1 physical volume(s) not resized
vgdisplay
--- Volume group ---
VG Name nonxpvg
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 6
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 1
Act PV 1
VG Size 63.27 GiB
PE Size 4.00 MiB
Total PE 16198
Alloc PE / Size 12314 / 48.10 GiB
Free PE / Size 3884 / 15.17 GiB
VG UUID 7nSsEo-Hend-4Xi8-2Udy-hFTR-2s8K-7Z7bbm
[-- Attachment #2: Type: text/html, Size: 1601 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] shrink VG and PV
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
1 sibling, 0 replies; 7+ messages in thread
From: Malahal Naineni @ 2010-05-17 20:56 UTC (permalink / raw)
To: linux-lvm
Dael Elcar [kanonmatswe@gmail.com] wrote:
> My system is archlinux i386. lvm version 2.02.62(1) (2010-03-09)
> I'd like to shrink a partition with lvm on it. Can this be done? In order
> to shrink it I need to reduce the size of the PV, right? I have
> successfully removed an LV (from the end on the VG) and there is no
> mention of it with lvdisplay or in the file i get with vgcfgbackup. I
> think the next step is to reduce the size of the VG and remove the now
> unallocated 3884 PEs from it. I can't find a command for that. I have
> tried pvresize. How do I solve the problem with "metadata areas"?
> vgdisplay says VG Status is "resizable".
You will need to resize the PV and that would automatically reduce the
VG size. That is why you don't find a command to resize VG.
> pvresize /dev/sda2 --test --setphysicalvolumesize 49256M
> Test mode: Metadata will NOT be updated.
> /dev/sda2: too many metadata areas for pvresize
> 0 physical volume(s) resized / 1 physical volume(s) not resized
>
> vgdisplay
> --- Volume group ---
> VG Name nonxpvg
> System ID
> Format lvm2
> Metadata Areas 2
Looks like you have 2 copies of metadata (one at the front and another
one at the end of the PV). Resize on this PV is not supported. Here is
what I see from 'man pvresize':
"pvresize won't currently work correctly on LVM1 volumes or
PVs with extra metadata areas."
Unfortunately, there is no easy way to reduce the metadata copies,
resize and add another copy as you have now.
Thanks, Malahal.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] shrink VG and PV
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
1 sibling, 1 reply; 7+ messages in thread
From: Malahal Naineni @ 2010-05-17 21:14 UTC (permalink / raw)
To: linux-lvm
Dael Elcar [kanonmatswe@gmail.com] wrote:
> pvresize /dev/sda2 --test --setphysicalvolumesize 49256M
> Test mode: Metadata will NOT be updated.
> /dev/sda2: too many metadata areas for pvresize
> 0 physical volume(s) resized / 1 physical volume(s) not resized
I have now looked at how to reduce the number of metadata copies. Here
is what Alasdair said:
Q: /dev/md1: too many metadata areas for pvresize
That's meant to be saying you chose to place a second copy of
the metadata at the end of the device and if you want to
increase the size of the data area you have to shift that
metadata first and there is no code that does that.
Workaround is to reduce to 1 metadata area first (backup VG,
redo pvcreate with uuid & restorefile, restore VG), then extend,
then put the 2nd metadata area back (same process) if you still
want it.
Hope that helps!
--Malahal.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] shrink VG and PV
2010-05-17 21:14 ` Malahal Naineni
@ 2010-05-17 21:30 ` Stuart D. Gathman
2010-05-18 5:29 ` kanonmatswe
0 siblings, 1 reply; 7+ messages in thread
From: Stuart D. Gathman @ 2010-05-17 21:30 UTC (permalink / raw)
To: LVM general discussion and development
Captain Hindsight here with more advice! :-)
On Mon, 17 May 2010, Malahal Naineni wrote:
> Q: /dev/md1: too many metadata areas for pvresize
>
> That's meant to be saying you chose to place a second copy of
> the metadata at the end of the device and if you want to
> increase the size of the data area you have to shift that
> metadata first and there is no code that does that.
Having 1 metadata erase per PV generally provides sufficient redundancy
under the assumption that PVs are atomic - you lose an entire PV, or
you don't lose it at all. A 2nd metadata area is only useful when trying
to recover data from a partially destroyed PV - and it is the only PV
in the VG.
A better solution to that scenario is to regularly backup /etc/lvm (or whatever
dir your distro puts metadata backups in) to someplace outside the single PV
VG. For instance, I favor keeping an /etc/lvm backup on /boot (which is of
necessity a non-LVM filesystem until grub has robust LVM support). I've
thought about making /etc/lvm a symlink to /boot/lvm, but haven't studied the
idea for unintended consequences.
If you have regular system backups, then you can get a copy of /etc/lvm from
one of those, and won't need the 2nd metadata area.
Conclusion: always use only one metadata area per PV (but on multiple PVs
when available).
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] shrink VG and PV
2010-05-17 21:30 ` Stuart D. Gathman
@ 2010-05-18 5:29 ` kanonmatswe
2010-05-18 9:13 ` Bryn M. Reeves
0 siblings, 1 reply; 7+ messages in thread
From: kanonmatswe @ 2010-05-18 5:29 UTC (permalink / raw)
To: linux-lvm
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] shrink VG and PV
2010-05-18 5:29 ` kanonmatswe
@ 2010-05-18 9:13 ` Bryn M. Reeves
2010-05-18 9:38 ` Bryn M. Reeves
0 siblings, 1 reply; 7+ messages in thread
From: Bryn M. Reeves @ 2010-05-18 9:13 UTC (permalink / raw)
To: LVM general discussion and development
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] shrink VG and PV
2010-05-18 9:13 ` Bryn M. Reeves
@ 2010-05-18 9:38 ` Bryn M. Reeves
0 siblings, 0 replies; 7+ messages in thread
From: Bryn M. Reeves @ 2010-05-18 9:38 UTC (permalink / raw)
To: LVM general discussion and development
On 05/18/2010 10:13 AM, Bryn M. Reeves wrote:
> 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).
More detailed example here:
http://pastebin.org/246926
Regards,
Bryn.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-05-18 9:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2010-05-18 9:38 ` Bryn M. Reeves
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).