resampeling of a ZVOL that has been resized
Adam Nowacki
nowakpl at platinum.linux.pl
Mon Apr 27 10:23:48 UTC 2015
On 2015-04-25 12:52, Willem Jan Withagen wrote:
> 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.
You can tell kernel to retaste the device without rebooting by running:
true > /dev/zvol/zfsdata/vol
More information about the freebsd-fs
mailing list