Date: Fri, 8 Jul 2016 12:03:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Dexuan Cui <decui@microsoft.com> Cc: "freebsd-geom@freebsd.org" <freebsd-geom@freebsd.org>, Allan Jude <allanjude@freebsd.org>, sobomax <sobomax@freebsd.org>, ken <ken@freebsd.org>, imp <imp@freebsd.org>, Hongjiang Zhang <honzhan@microsoft.com>, Sepherosa Ziehau <sepherosa@gmail.com> Subject: Re: How to force GEOM to recalculate the free space after the disk is resized? Message-ID: <CANCZdfqEf19pTMBBZ_YgiOVmZ7YMr1Uqfv7w_0PCiLboJjQPsA@mail.gmail.com> In-Reply-To: <CO2PR03MB2182532200F6E92F110EBAA1BF3C0@CO2PR03MB2182.namprd03.prod.outlook.com> References: <CO2PR03MB2182532200F6E92F110EBAA1BF3C0@CO2PR03MB2182.namprd03.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 8, 2016 at 6:19 AM, Dexuan Cui <decui@microsoft.com> wrote: > Hi, I have a FreeBSD virtual machine (VM) running on Hyper-V and I'm test= ing Hyper-V's Disk Online Resizing feature. The feature can expand or shrin= k 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 s= pace displayed by gpart remained the same unless I open the disk dev file f= or writing, e.g., > > [root@decui-bsd11 ~]# gpart create -s MBR /dev/da1 > da1 created > [root@decui-bsd11 ~]# gpart show /dev/da1 > =3D> 63 83886017 da1 MBR (40G) > 63 83886017 - free - (40G) > [root@decui-bsd11 ~]# diskinfo /dev/da1 > /dev/da1 512 42949672960 83886080 4096 0 5= 221 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, bu= t the free space remains the same. > (Note: the first diskinfo failure should be expected: Hyper-V only notifi= es the VM of the capacity change on the VM's next read or write request, an= d in the VM it seems there is a race condition between the ioctl and the ha= ndling 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 6= 527 255 63 > > [root@decui-bsd11 ~]# gpart show /dev/da1 > =3D> 63 83886017 da1 MBR (50G) > 63 83886017 - free - (40G) > > Now, if I run a program that only does "openat(AT_FDCWD,"/dev/da1",O_WRON= LY|O_CREAT,0644);", GEOM will detect that the free space is 50GB now and GE= OM will pass this info to gpart: > > [root@decui-bsd11 ~]# gpart show /dev/da1 > =3D> 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 proper= ly 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqEf19pTMBBZ_YgiOVmZ7YMr1Uqfv7w_0PCiLboJjQPsA>