pvresize problem

pvresize problem

[David Teigland]

I'm trying to verify shrinking with pvresize --setphysicalvolumesize

When the pv is an orphan, it works as expected, but when the pv is
not an orphan, the resulting size is always 8192S less than the
requested size.

Getting the same result with the latest git code and from tag v2_02_98.

--

test_description='pvresize setphysicalvolumesize'

. lib/test

aux prepare_devs 2

# non-orphan
vgcreate $vg1 "$dev1"

# orphan
pvcreate "$dev2"

size1=$(get pv_field "$dev1" pv_size --units s)
size2=$(get pv_field "$dev2" pv_size --units s)

pvresize --setphysicalvolumesize 57344S $dev2
check pv_field $dev2 pv_size "57344S" --units s

pvresize --setphysicalvolumesize 57344S $dev1
check pv_field $dev1 pv_size "57344S" --units s

--

pvresize -vv --setphysicalvolumesize 57344S $dev1
#pvresize.sh:30+ pvresize -vv --setphysicalvolumesize 57344S @TESTDIR@/dev/mapper/@PREFIX at pv1
      Setting activation/monitoring to 0
      Setting global/locking_type to 1
      global/wait_for_locks not found in config: defaulting to 1
      File-based locking selected.
      Setting global/locking_dir to @TESTDIR@/var/lock/lvm
      global/prioritise_write_locks not found in config: defaulting to 1
    Using physical volume(s) on command line
      @TESTDIR@/dev/mapper/@PREFIX at pv1: size is 68608 sectors
      @TESTDIR@/dev/mapper/@PREFIX at pv1: lvm2 label detected at sector 1
      @TESTDIR@/dev/mapper/@PREFIX at pv1: size is 68608 sectors
      @TESTDIR@/dev/mapper/@PREFIX at pv1: size is 68608 sectors
      @TESTDIR@/dev/mapper/@PREFIX at pv2: size is 68608 sectors
      @TESTDIR@/dev/mapper/@PREFIX at pv2: lvm2 label detected at sector 1
      Locking @TESTDIR@/var/lock/lvm/V_ at PREFIX@vg1 WB
      @TESTDIR@/dev/mapper/@PREFIX at pv1: lvm2 label detected at sector 1
      @TESTDIR@/dev/mapper/@PREFIX at pv1: size is 68608 sectors
      @TESTDIR@/dev/mapper/@PREFIX at pv1: size is 68608 sectors
    @TESTDIR@/dev/mapper/@PREFIX at pv1: Pretending size is 57344 not 68608 sectors.
    Resizing volume "@TESTDIR@/dev/mapper/@PREFIX at pv1" to 68608 sectors.
    Resizing physical volume @TESTDIR@/dev/mapper/@PREFIX at pv1 from 0 to 6 extents.
    Updating physical volume "@TESTDIR@/dev/mapper/@PREFIX at pv1"
  WARNING: This metadata update is NOT backed up
  Physical volume "@TESTDIR@/dev/mapper/@PREFIX at pv1" changed
      Unlocking @TESTDIR@/var/lock/lvm/V_ at PREFIX@vg1
  1 physical volume(s) resized / 0 physical volume(s) not resized
check pv_field $dev1 pv_size "57344S" --units s
#pvresize.sh:31+ check pv_field @TESTDIR@/dev/mapper/@PREFIX at pv1 pv_size 57344S --units s
pv_field: PV="@TESTDIR@/dev/mapper/@PREFIX at pv1", field="pv_size", actual="49152S", expected="57344S"

pvresize problem

[David Teigland]

On Tue, Mar 26, 2013 at 12:59:13PM -0400, David Teigland wrote:
> I'm trying to verify shrinking with pvresize --setphysicalvolumesize
> 
> When the pv is an orphan, it works as expected, but when the pv is
> not an orphan, the resulting size is always 8192S less than the
> requested size.

Looking in _text_pv_resize(), I'm guessing the difference I see might be
"pv->size -= size_reduction" which would indicate things are working as
intended.  If so, I'll adjust my checks to include this reduction.

pvresize problem

[Peter Rajnoha]

On 26.03.2013 22:50, David Teigland wrote:
> On Tue, Mar 26, 2013 at 12:59:13PM -0400, David Teigland wrote:
>> I'm trying to verify shrinking with pvresize --setphysicalvolumesize
>>
>> When the pv is an orphan, it works as expected, but when the pv is
>> not an orphan, the resulting size is always 8192S less than the
>> requested size.
> 
> Looking in _text_pv_resize(), I'm guessing the difference I see might be
> "pv->size -= size_reduction" which would indicate things are working as
> intended.  If so, I'll adjust my checks to include this reduction.
> 

Yes, exactly. When the PV is orphan, we're always reporting the size that
includes any alignments, metadata areas and PV headers (IOW, the "disk size
itself" or "pretended disk size" if the size was forced).

If the PV is in a VG, we're reporting only usable "data area" size, meaning the
size that is reserved for the data itself where extents can be allocated.

I can imagine this could cause confusion, but the problem is that it has been
reported this way since ages (though I don't know the exact historical reason
for this logic). The best would be if we could report the PV size for orphan
the same way as we do for non-orphans and then have an extra field that would
report the exact space used together with all the alignment and metadata...

(Though changing the PV size report for the orphan would mean changing existing
report which people can already use... Which is not a backward compatible
change unfortunately.)

Peter