(original message was rejected because of HTML) ---------- Forwarded message --------- Von: Tilman Vogel <tilman.vogel@xxxxxxxxx> Date: Mo., 13. Jan. 2025 um 17:09 Uhr Subject: Re: pvresize after pvcreate changes PV size: expected? To: Zdenek Kabelac <zdenek.kabelac@xxxxxxxxx> Cc: <linux-lvm@xxxxxxxxxxxxxxx> Hi Zdenek! Thank you for the explanation! Let me give missing context why I do care even if it is not a bug: On an SSD, I had partitioned such that all space at the end was in an LVM PV living inside a LUKS-encrypted partition. But now, I needed a new non-encrypted partition such that I had to shrink the LUKS-encrypted partition. The PV was not fully utilized and had plenty of space towards the end. So, this involved: 1. pvresize --setphysicalvolumesize <PV_size> ... 2. cryptsetup resize --size <LUKS_size> ... 3. cfdisk (or similar) to adjust the partition end My fear was that I would choose a wrong <LUKS_size> and cut off data that the PV still expects to have. When I looked at `pvdisplay --units b` (or s), I was puzzled by the discrepancy between what I had given as <PV_size> and what was listed after "PV Size". So, I started playing with what I sent as `test.sh` and found yet more fluctuating size information. So, long story short: If I want to know how much space LVM is using for the PV such that I can resize the containing block device without loss, is it safe to use the value from `pvdisplay`? Best regards, Tilman Am Mo., 13. Jan. 2025 um 14:46 Uhr schrieb Zdenek Kabelac <zdenek.kabelac@xxxxxxxxx>: > > Dne 11. 01. 25 v 23:21 Tilman Vogel napsal(a): > > Hi! > > > > I just encountered the following and do not understand it. The confusing part > > is that when I run pvresize without size parameter directly after pvcreate, > > the size still seems to change even though pvcreate of course also uses the > > underlying device size just as pvresize should. > > > > I am attaching the test.sh for your reference. > > > > What am I missing? > > > > Hi > > You are missing that the actual size of usable count of PV extents is not > changed by a single bit. > > The surrounding accounting changes with the lvm2 metadata content size accounting. > > For a user of a PV it's important there is 24 free extents of 4MiB each in > this case and this gives a usable size for LVs. > > Rest is either unused alignment space or space dedicated to PV header & lvm2 > metadata. This space is accounted a bit differently when you create a new PV > or you work with already existing PV with already existing lvm2 metadata area. > Yeah - it might be possibly 'addressed' better and PV could be readjusted > after initial create - but it's not a bug - so it avoids 'extra' clutering > of PV header space when it's not really necessary (as unlike lvm2 metadata, > PV header space is not using any backups - so the less it's touched, the > better....) > > Regards > > Zdenek > > > PS: for small PV sizes like in this case - using smaller extent size (i.e. > 256K, and reducing metadata size to i.e. 192K) may 'boost' usable space for LVs. >
