lvmteam / lvm2

Mirror of upstream LVM2 repository
https://gitlab.com/lvmteam/lvm2
GNU General Public License v2.0
128 stars 72 forks source link

please integrate pvshrink into lvm2 tools #108

Open devZer0 opened 1 year ago

devZer0 commented 1 year ago

hello,

unfortunately, my question at https://listman.redhat.com/archives/linux-lvm/2023-February/026319.html has not been answered/commented.

trying here again, so it won't get lost.

i wanted to resize/shrink a virtual machines disk to a smaller size and found this tool very helpful:

https://github.com/mythic-beasts/pvshrink

there is a python3 enable version at

https://github.com/sensimple-contrib/pvshrink

"pvshrink automates the invocation of pvmove to condense PV usage at the start of the volume, and then invokes pvresize to shrink a PV to its minimum possible size."

is there something similar in lvm2 tools in the meantime , or could this utility please get integrated into the lvm2 tools suite ?

jwesterd-redhat commented 1 year ago

Add on to above: Is there a way to pvshrink (pvmove+pvevacuate) off the --head or --tail of a physical volume? .

Why? to solve the all-too-common issue of /dev/sda1 being 200MB ( preventing In-Place-Upgrade - AKA IPU ) ... and /dev/sda2 ( 200MB -> 100% ) where that PV holds rootvg and has many GB of unused extents! Space is there already, just cant use it!!! There is always a way!

I learned recently of the of the issue of extent renumbering, where extent 0-9000 are snipped off the beginning of the PV. Hmmm ... Could first extent be numbered 9000?

It does complicate matters if mirrored, striped or in a RAID configuration, PVMove seems to already have some smarts for the stripe/mirror handling (cling etc) though RAID 5/10/... seem another case?

Adding this functionality at a lower level might keep it from being done in shell or playbook (dd, parted, hack /etc/lvm* etc).

Might even be doable while system is up?

Maybe there is another simple way to trim extents off the head or tail of a PV?

Would help a lot of people as well as automation tremendously. Juggling minimal data to free up some space seems a good idea, and not fiddling with the whole PV at some higher level language - that is the qvest.

Growing /dev/sda1 is trivial, just need some unused space between /dev/sda1 & /dev/sda2 (or /dev/vda etc...)