On Fri, Jul 8, 2016 at 6:19 AM, Dexuan Cui <de...@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@decui-bsd11 ~]# gpart create -s MBR /dev/da1 > da1 created > [root@decui-bsd11 ~]# gpart show /dev/da1 > => 63 83886017 da1 MBR (40G) > 63 83886017 - free - (40G) > [root@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@decui-bsd11 ~]# diskinfo /dev/da1 > diskinfo: /dev/da1: ioctl(DIOCGMEDIASIZE) failed, probably not a disk. > [root@decui-bsd11 ~]# diskinfo /dev/da1 > /dev/da1 512 53687091200 104857600 4096 0 6527 > 255 63 > > [root@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@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 _______________________________________________ freebsd-geom@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
