Possible off-by-one error in %VG notation in lvmtools

[ltd-beget-admin]

I spotted a curious behavior when using lvcreate/lvextend:

root@thinkpad:~# dpkg -l | grep 'lvm2 '
ii  lvm2                                  2.02.176-4.1ubuntu3                 amd64        Linux Logical Volume Manager
root@thinkpad:~# lvextend /dev/xubuntu-vg/lvol0 -l 1%VG ^C
root@thinkpad:~# dpkg -l | grep 'lvm2 '
ii  lvm2                                  2.02.176-4.1ubuntu3                 amd64        Linux Logical Volume Manager
root@thinkpad:~# lvcreate /dev/xubuntu-vg -l 1%VG 
  Logical volume "lvol0" created.
root@thinkpad:~# lvextend /dev/xubuntu-vg/lvol0 -l 1%VG 
  Size of logical volume xubuntu-vg/lvol0 changed from 2,23 GiB (571 extents) to 2,23 GiB (572 extents).
  Logical volume xubuntu-vg/lvol0 successfully resized.

To me it seems that it should be calculated to the same absolute number of extents in both tools

In my limited testing it was always extended by one extent, no matter which size i used

[zkabelac]

Hi

Here is what's going on there - from 'man lvcreate' -lXX%VG specifier is formulated this way:

'the size defines an upper limit for the number of logical extents'

Which mean - the size is calculated as 1% and then is rounded-down to nearest extent and gives you 'AT MOST' the specified size - so lvcreate gives you 571 extents.

The story however is different with 'lvextend' - where you want to 'extend' LV - so rounding-down could be leading to actually getting 'smaller' sized value - so the rounding here must go UP.
With resizing the resulting size is always made 'AT LEAST' - this is mainly important with lvreduce so you are never getting less space then requested (lvextend & lvreduce are 'lvresize' calls with extra validation you are extending or reducing LV - but all 3 gives you same numbers).

Perhaps when adding extra 'complexity' it would be possible to check that lvextend does not reduce the size and it could be seen as 'zero' operation if it's rounding issue - but that would require couple specific math operation for very specific case which by definition of sizes defined with % modifier is very fuzzy on its own as you can get differently rounded result with every invocation of the command actually. Biggest issue would be that lvresize -lXX%VG would behave differently from lvextend -lXX%VG - so IMHO we should preserve current logic - which might look in this particular case somewhat mysterious - but provides more consistent results overall.

I'd probably recommend to use exact extent sizes defined instead of relying on %VG - you may get very varying results.

Hopefully this explains what's going on there.