How to force GEOM to recalculate the free space after the disk is resized?

[Warner Losh]

On Fri, Jul 8, 2016 at 6:19 AM, Dexuan Cui <decui at microsoft.com> wrote:
> Hi, I have a FreeBSD virtual machine (VM) running on Hyper-V and I'm testing Hyper-V's Disk Online Resizing feature. The feature can expand or shrink the (virtual) disk capacity of a VM when the VM is running.
>
> There is an issue with gpart or GEOM: after the disk capacity is expanded (or shrunk), gpart/GEOM can detect the new bigger capacity, but the free space displayed by gpart remained the same unless I open the disk dev file for writing, e.g.,
>
> [root at decui-bsd11 ~]# gpart create -s MBR   /dev/da1
> da1 created
> [root at decui-bsd11 ~]# gpart show /dev/da1
> =>      63  83886017  da1  MBR  (40G)
>         63  83886017       - free -  (40G)
> [root at decui-bsd11 ~]# diskinfo /dev/da1
> /dev/da1        512     42949672960     83886080        4096    0       5221    255     63
>
> Now I expand the disk from 40GB to 50GB by Hyper-V management tool.
>
> Next, I get the below, i.e., gpart/GEOM detects the new disk capacity, but the free space remains the same.
> (Note: the first diskinfo failure should be expected: Hyper-V only notifies the VM of the capacity change on the VM's next read or write request, and in the VM it seems there is a race condition between the ioctl and the handling of capacity change. I'll see how this can be fixed.)
>
> [root at decui-bsd11 ~]# diskinfo /dev/da1
> diskinfo: /dev/da1: ioctl(DIOCGMEDIASIZE) failed, probably not a disk.
> [root at decui-bsd11 ~]# diskinfo /dev/da1
> /dev/da1        512     53687091200     104857600       4096    0       6527    255     63
>
> [root at decui-bsd11 ~]# gpart show /dev/da1
> =>      63  83886017  da1  MBR  (50G)
>         63  83886017       - free -  (40G)
>
> Now, if I run a program that only does "openat(AT_FDCWD,"/dev/da1",O_WRONLY|O_CREAT,0644);", GEOM will detect that the free space is 50GB now and GEOM will pass this info to gpart:
>
> [root at decui-bsd11 ~]# gpart show /dev/da1
> =>       63  104857537  da1  MBR  (50G)
>          63  104857537       - free -  (50G)
>
> I'm not familiar with GEOM.
> Can somebody please explain the behavior?

I'm guessing that the new code in the da driver to do 'resize' isn't properly
signaling up the stack so that GEOM re-tastes the drive. The resize code
was just recently added to camcontrol (I'm assuming that's what you are
using to force the da driver to requery the size).a

Geom normally retastes the drive when it closes after it has been opened
for writing, which is why your open hack works.

Warner