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

[Dexuan Cui]

Yes, this is also my suspicion.

Here with “diskinfo /dev/da1”, geom can already detect the new disk capacity but it just doesn’t update its internal structure for new free space.
I think I’ll have to locate the related code and ask geom to re-probe free space on disk capacity change.
It would be great if somebody can point out the exact code I need to dig into.

-- Dexuan

From: sobomax at sippysoft.com [mailto:sobomax at sippysoft.com] On Behalf Of Maxim Sobolev
Sent: Friday, July 8, 2016 23:20
To: Dexuan Cui <decui at microsoft.com>
Cc: freebsd-geom at freebsd.org; Allan Jude <allanjude at freebsd.org>; ken <ken at freebsd.org>; imp <imp at freebsd.org>; Hongjiang Zhang <honzhan at microsoft.com>; Sepherosa Ziehau <sepherosa at gmail.com>
Subject: Re: How to force GEOM to recalculate the free space after the disk is resized?

Smells like a bug in the geom_part where it supposed to re-read the partitions and update its internal structures. The reason why it works when you open dev/da1 for writing is because the geom_part provider that is attached to that disk is destroyed and created anew when you close the fd.

-Maxim

On Fri, Jul 8, 2016 at 5:19 AM, Dexuan Cui <decui at microsoft.com<mailto: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 don't know who exactly maintains GEOM , so I just picked some names from "git log geom/" and put you to Cc.  Sorry if this mail bothers you. :-)

Thanks,
-- Dexuan