resampeling of a ZVOL that has been resized

[Willem Jan Withagen]

On 24/04/2015 04:56, Andrey V. Elsukov wrote:
> On 23.04.2015 00:22, Willem Jan Withagen wrote:
>> Now the question:
>> 	How can I get GEOM to resample the zvol, and have it really detect that
>> the disk has changed.... It sort of does, but not enough to actually
>> allow it to grow to the new size.
> 
> You need to read dmesg, where you will find the message:
> GEOM_PART: zvol/zfsdata/vol was automatically resized.
>   Use `gpart commit zvol/zfsdata/vol` to save changes or
>   `gpart undo zvol/zfsdata/vol` to revert them.
> 

This does not really resolve the issue.
after growing the volume in ZFS, the new size is reported in '
gpart show':

freetest# gpart show zvol/zfsdata/vol
=>       40  209715120  zvol/zfsdata/vol  GPT  (200G)
         40          8                    - free -  (4.0K)
         48  209715104                 1  freebsd-ufs  (100G)
  209715152          8                    - free -  (4.0K)

However the free space at the end stays at a mere 4.0K, not allowing
gpart resize to take any value other than less than 100G, effectively
shrinking the partition.

And there is no incantation of any of commit, recover, etc... to get
gpart to actually do "the right thing"

When I did this on a VMware VM, gpart show reported the volume as
[CORRUPTED] and gpart recover fixed that.
Supposedly the backup blocks were at the wrong place in the grown disk
and recover again placed them at the end.

But the ZFS case does not go into the [CORRUPTED] state.
Perhaps that is due to also missing the message that you suggest that
can be found in dmesg after resizing the ZVOL.
And thus a recover is not needed, nor dies issueing it fix anything.

Now after a reboot the bootup log tells:
GEOM: zvol/zfsdata/vol: the secondary GPT header is not in the last LBA.

And now gpart report as expected:
=>       40  209715120  zvol/zfsdata/vol  GPT  (200G) [CORRUPT]
         40          8                    - free -  (4.0K)
         48  209715104                 1  freebsd-ufs  (100G)
  209715152          8                    - free -  (4.0K)

gpart recover sets the free space to 100G:
=>       40  419430320  zvol/zfsdata/vol  GPT  (200G)
         40          8                    - free -  (4.0K)
         48  209715104                 1  freebsd-ufs  (100G)
  209715152  209715208                    - free -  (100G)

And from now on I can resize the partition 1 to 200G...

So it seems that although gpart understands that the ZVOL volume has
grown, it does not take it far enough and set it to CORRUPTED and then
let the user correct/grow it.

--WjW