How to change Volumegroup PE size

Question

I am trying to increase the PE size of one of my Volume groups.

I mistakenly set it as 4M to start when it should have been 32M .

When I try to change the size I get

vgchange -s 32M the_vol
New extent size is not a perfect fit

vgdisplay says:

vgdisplay
--- Volume group ---
VG Name               the_vol
System ID             
Format                lvm2
Metadata Areas        1
Metadata Sequence No  173
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                43
Open LV               41
Max PV                0
Cur PV                1
Act PV                1
VG Size               864.25 GiB
PE Size               4.00 MiB
Total PE              221247
Alloc PE / Size       103680 / 405.00 GiB
Free  PE / Size       117567 / 459.25 GiB
VG UUID               uh25Y8-TOWR-pqBj-NyPV-ca6t-ec1k-jlqm4g

Is there anything I can do to get this change to 32 without recreating it/deleting the data?

Or getting it close to 32.

Thanks

Solution 1

You can use pvmove to move around the allocated physical extents on the physical volume(s). You should make any logical volumes begin and end on extent boundaries (grow with lvresize). The underlying physical volume size(s) should probably also be an exact multiple of the new extent size too (fix that with pvresize).

As mentioned in a superuser answer to a related question, you could use something like this:

pvmove --alloc anywhere /dev/sdc1:103680-221247 /dev/sdc1:0-103679

to move the extents 103680-221247 to 0-103679 on the physical volume /dev/sdc1. You might need to move segments in steps. Use pvdisplay --maps /dev/sdc1 to show what extents are allocated on the physical volume /dev/sdc1.

Note that the extent size should not affect I/O performance (on LVM2), only the performance of the LVM tools themselves and the maximum sizes of the LVM components should be affected.

Solution 2

You can only change the physical extent size of a volume group if no existing physical extents would need to be moved to complete the change. Otherwise you receive the error that you posted above.

The only other option is to recreate the volume group with the correct size.

To quote from the man page:

Once this value has been set, it is difficult to change it without recreating the volume group which would involve backing up and restoring data on any logical volumes. However, if no extents need moving for the new value to apply, it can be altered using vgchange -s.

Solution 3

It is possible, but difficult. If you have the option, re-creating the VG is a much better option.
However, that wasn't an option for me, so here's how I changed my PE size from 4MB to 32MB.

• First, shrink your PVs to a size that's divisible by your target PE size, i.e.:
  pvresize /dev/sdb --setphysicalvolumesize 3778436m
• Next, resize all your LVs to a size divisible by your intended PE size using lvresize, i.e.: lvresize /dev/libvirtstorage/debian-8.7.1-amd64-netinst.iso --size 256
• Next up is making sure the individual segments that make up each image are aligned to your new PE. This one is iffy, as you basically have to "defrag" your VG.
  I used the "lvm2defrag" tool for this (you don't need to run this on the machine itself, you can run this on any machine with PHP installed, it'll just generate the commands needed)
• After this, if your total volume size, LV fragment size and free space are all divisible by your targeted PE size, you should be able to change the PE size:
  vgchange -s 32m the_vol

This entire process can be done without any downtime, the entire VG continues operating during all this.
One more pitfal to note: Beware of the difference between 32m and 32M, LVM commands interpret lower case m as MiB and upper case M as MB.

Comments

[awmusic12635]

Thanks for that. Is there a simple way to save all the data from the VG, delete the VG then make it again and restore that data into the new one with the correct PE size? Perhaps savevg and restorevg?

[Michael Hampton]

Got another hard drive laying around somewhere? :)

[awmusic12635]

I have space offsite just not local. Just curious if what I suggested would work.

[Michael Hampton]

Anything that will get your data from one place to another intact will work.

[Corubba]

That last bit is actually not true (anymore?). The vgchange manpage states Input units are always treated as base two values, regardless of capitalization, e.g. 'k' and 'K' both refer to 1024.