LVM issue: cannot resize to N extents as M are allocated

Question

I setup default Fedora partitioning with LVM. Now, I would like to shrink my partition to create 1 new partition. Could you please help me understand why I am getting such error?

[root@host]# lvm pvresize /dev/sda2 --setphysicalvolumesize 60G
  /dev/sda2: cannot resize to 1919 extents as 22340 are allocated.
  0 physical volume(s) resized / 1 physical volume(s) not resized

Some details on my partitioning:

[root@host]# lvm pvs
  PV         VG        Fmt  Attr PSize   PFree
  /dev/sda2  vg_andrew lvm2 a--  698.12g    0

[root@host]# pvs --segments
  PV         VG        Fmt  Attr PSize   PFree Start SSize
  /dev/sda2  vg_andrew lvm2 a--  698.12g    0      0   310
  /dev/sda2  vg_andrew lvm2 a--  698.12g    0    310 20430
  /dev/sda2  vg_andrew lvm2 a--  698.12g    0  20740  1600

[root@host]# df -h
Filesystem                     Size  Used Avail Use% Mounted on
rootfs                          50G  6.5G   43G  14% /
devtmpfs                       3.9G     0  3.9G   0% /dev
tmpfs                          3.9G  816K  3.9G   1% /dev/shm
tmpfs                          3.9G  1.1M  3.9G   1% /run
/dev/mapper/vg_andrew-lv_root   50G  6.5G   43G  14% /
tmpfs                          3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs                          3.9G     0  3.9G   0% /media
/dev/sda1                      485M   96M  364M  21% /boot
/dev/mapper/vg_andrew-lv_home  629G   53G  545G   9% /home

Sorry if the answer is obvious, I am new to LVM. Thank you for your help.

Rule #1 of using LVM, don't pre-allocate all of your space. As in, you really shouldn't have created a huge `/home`. Instead you should make small filesystems and add space as needed, leaving all your extra space un-allocated, so you have flexibility in the future. — Zoredache, Oct 03 '12 at 16:51
I encountered this because my swap volume was at the end of the volume group. Use `pvmove`, as explained [here](https://unix.stackexchange.com/questions/67702/how-to-reduce-volume-group-size-in-lvm), to move the volume. Afterwards, `pvresize` worked fine for me. — Matthias Braun, Jan 10 '18 at 15:00

dsz · Answer 1 · 2021-08-11T10:54:27.033

My personal approach; I love using KDE's partitionmanager for most of my disk work; it can even cope with shrinking LVs and the file systems within them at the same time. I use this to shrink the LVs where I want to be able to reclaim some space.

Now I get to the OP's problem - the resize of the PV fails.

So, lets see what extents are being used:

******# pvs -v --segments /dev/sda3                 
  PV         VG         Fmt  Attr PSize   PFree   Start SSize LV   Start Type   PE Ranges            
  /dev/sda3  metabox-vg lvm2 a--  237.73g 122.98g     0  3239 var      0 linear /dev/sda3:0-3238     ******
  /dev/sda3  metabox-vg lvm2 a--  237.73g 122.98g  3239  3436          0 free                        
  /dev/sda3  metabox-vg lvm2 a--  237.73g 122.98g  6675  9680 usr      0 linear /dev/sda3:6675-16354 
  /dev/sda3  metabox-vg lvm2 a--  237.73g 122.98g 16355  8360          0 free                        
  /dev/sda3  metabox-vg lvm2 a--  237.73g 122.98g 24715   476 tmp      0 linear /dev/sda3:24715-25190
  /dev/sda3  metabox-vg lvm2 a--  237.73g 122.98g 25191 12800 home     0 linear /dev/sda3:25191-37990
  /dev/sda3  metabox-vg lvm2 a--  237.73g 122.98g 37991  1053 tmp    476 linear /dev/sda3:37991-39043
  /dev/sda3  metabox-vg lvm2 a--  237.73g 122.98g 39044  2128 root     0 linear /dev/sda3:39044-41171
  /dev/sda3  metabox-vg lvm2 a--  237.73g 122.98g 41172 19688          0 free

I look at the last non-free space:

39044  2128 root     0 linear /dev/sda3:39044-41171

and the first free space

 3239  3436          0 free

and I run

******# pvmove --alloc anywhere /dev/sda3:39044+2128 /dev/sda3:3239+2128

to move the blocks at the end to the first free block.

And repeat...

Now, on an SSD, you probably don't mind if you fragment the extents of a single LV. You probably won't wont to do that on an HDD - in which case you'll have to trade how much space you reclaim, vs you're tolerance for LV fragmentation, vs the time you're willing to wait for all of the bit-suffling that may be required for a "full defrag".

When you get to moving partial LVs, some bash maths can come in handy too:

***# pvmove --alloc anywhere /dev/sda3:$((37990-8359))+8359 /dev/sda3:16355+8359

Nice answer. I think I'm starting to get how the pmove is supposed work. Could you possibly take a look at this question: https://serverfault.com/questions/1074171/reducing-an-lvmgroup-cannot-resize-to-xxxx-extents-as-later-ones-are-allocated — Jack BeNimble, Aug 11 '21 at 16:31
@JackBeNimble - done! Thanks for the upvote, and hope you like my answer to your question! — dsz, Aug 11 '21 at 23:43

score 2 · Answer 2 · answered Oct 03 '12 at 16:30

2

The best approach is to do following:

# yum install system-config-lvm
...
# system-config-lvm

and then do it through GUI), but be careful whenever you're doing changes such as LVM (make sure you have backup!)

answered Oct 03 '12 at 16:30

alexus

12,342
27
115
173

score 2 · Accepted Answer · answered Oct 03 '12 at 16:35

2

First of all, you can't resize the physical volume if you have booted from it. Boot from a rescure CD, run pvscan, vgscan and lvscan and then follow those steps:

Resize the filesystems in all your logical volumes in the volume group vg_andrew
Resize the logical volumes so that the sum of all volumes are smaller then the size you want the physical volume to be
Now resize the volume group vg_andrew (which is he comtainers for all of your logical volumes)
Now you can resize the physical volume itself. After that you still need to resize the partition which holds your physical volume.

Alltogether this is not a trivial task. You have to take care to resize the filesystems in your logical volumes correctly so that you don't lose any data.

If you'd post the output of lvdisplay, vgdisplay and pvdisplay we might be able to give further details, but the process which I described above would be the correct way to do it.

answered Oct 03 '12 at 16:35

Alexander Janssen

2,557
15
21

2

Also, be sure to resize the filesystem itself (eg resize2fs) before resizing the logical volume. See http://serverfault.com/questions/433275/lvm-logical-volume-partition-corrupted-after-lvreduce for what happens when you don't – DerfK Oct 03 '12 at 16:37
@DerfK phew, while reading your comment I realized I had a blatant error in step 1. Wrote partitions where I meant filesystems. – Alexander Janssen Oct 03 '12 at 16:40
@Andrew Did you manage to solve your issues? – Alexander Janssen Oct 09 '12 at 19:07
@AlexanderJanssen Yes and I set accepted status of your answer as comprehensive and helpful. I appreciate your time spent to help other not-experienced people. – Andrew Oct 10 '12 at 09:48
ugh, this is annoying if you've used Ubuntu's installer with LVM support. – Sridhar Sarnobat Mar 27 '22 at 07:17

LVM issue: cannot resize to N extents as M are allocated

3 Answers3