pvresize after pvcreate changes PV size: expected?

pvresize after pvcreate changes PV size: expected?

[Tilman Vogel]

[-- Attachment #1.1: Type: text/plain, Size: 2933 bytes --]

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?

Tilman

# ./test.sh
+ set -o errexit
+ truncate -s 100M image
++ losetup --show -f image
+ LOOP=/dev/loop0
+ echo 'LOOP /dev/loop0'
LOOP /dev/loop0
+ pvcreate /dev/loop0
 Physical volume "/dev/loop0" successfully created.
 Not creating system devices file due to existing VGs.
+ vgcreate test /dev/loop0
 Not creating system devices file due to existing VGs.
 Volume group "test" successfully created
+ pvdisplay --units b /dev/loop0
 --- Physical volume ---
 PV Name               /dev/loop0
 VG Name               test
 PV Size               104857600 B  / not usable 4194304 B
 Allocatable           yes
 PE Size               4194304 B
 Total PE              24
 Free PE               24
 Allocated PE          0
 PV UUID               zNLgIe-S8Zq-1DF5-0BhR-oGGS-q9Vy-FzNnoT

+ pvs --units b -o pv_all /dev/loop0
 Fmt  PV UUID                                DevSize    PV         Maj Min
PMdaFree  PMdaSize  PExtVsn 1st PE   PSize      PFree      Used Attr
Allocatable Exported   Missing    PE  Alloc PV Tags #PMda #PMdaUse BA Start
BA Size PInUse Duplicate DeviceID DeviceIDType
 lvm2 zNLgIe-S8Zq-1DF5-0BhR-oGGS-q9Vy-FzNnoT 104857600B /dev/loop0   7   0
  520704B  1044480B       2 1048576B 100663296B 100663296B   0B a--
 allocatable                        24     0             1        1
      0B      0B   used
+ echo RESIZE
RESIZE
+ pvresize /dev/loop0
 Physical volume "/dev/loop0" changed
 1 physical volume(s) resized or updated / 0 physical volume(s) not resized
+ pvdisplay --units b /dev/loop0
 --- Physical volume ---
 PV Name               /dev/loop0
 VG Name               test
 PV Size               103809024 B  / not usable 3145728 B
 Allocatable           yes
 PE Size               4194304 B
 Total PE              24
 Free PE               24
 Allocated PE          0
 PV UUID               zNLgIe-S8Zq-1DF5-0BhR-oGGS-q9Vy-FzNnoT

+ pvs --units b -o pv_all /dev/loop0
 Fmt  PV UUID                                DevSize    PV         Maj Min
PMdaFree  PMdaSize  PExtVsn 1st PE   PSize      PFree      Used Attr
Allocatable Exported   Missing    PE  Alloc PV Tags #PMda #PMdaUse BA Start
BA Size PInUse Duplicate DeviceID DeviceIDType
 lvm2 zNLgIe-S8Zq-1DF5-0BhR-oGGS-q9Vy-FzNnoT 104857600B /dev/loop0   7   0
  520704B  1044480B       2 1048576B 100663296B 100663296B   0B a--
 allocatable                        24     0             1        1
      0B      0B   used
+ echo CLEANUP
CLEANUP
+ vgremove test
 Volume group "test" successfully removed
+ pvremove /dev/loop0
 Labels on physical volume "/dev/loop0" successfully wiped.
+ losetup -d /dev/loop0

[-- Attachment #1.2: Type: text/html, Size: 4407 bytes --]

[-- Attachment #2: test.sh --]
[-- Type: application/x-shellscript, Size: 352 bytes --]

Re: pvresize after pvcreate changes PV size: expected?

[Zdenek Kabelac]

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.

Fwd: pvresize after pvcreate changes PV size: expected?

[Tilman Vogel]

(original message was rejected because of HTML)

---------- Forwarded message ---------
Von: Tilman Vogel <tilman.vogel@gmail.com>
Date: Mo., 13. Jan. 2025 um 17:09 Uhr
Subject: Re: pvresize after pvcreate changes PV size: expected?
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Cc: <linux-lvm@lists.linux.dev>


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@gmail.com>:
>
> 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.
>

Re: Fwd: pvresize after pvcreate changes PV size: expected?

[Stuart D Gathman]

On Mon, 13 Jan 2025, Tilman Vogel wrote:

> 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`?

I've always been confused by this as well.  I just make the containing
block device "extra big" and then let pvresize (or the filesystem
resize) detect the actual space available.