Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Jul 2016 13:36:30 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-geom@FreeBSD.org
Subject:   [Bug 211028] [GEOM][Hyper-V] gpart can't detect the new free space after the disk capacity changes
Message-ID:  <bug-211028-14739-Psr75wI1wL@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-211028-14739@https.bugs.freebsd.org/bugzilla/>
References:  <bug-211028-14739@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211028

--- Comment #15 from Dexuan Cui <decui@microsoft.com> ---
Hi all,
I know why g_disk_resize() can't work here when I open da1 for reading afte=
r a
disk capacity change:

When /dev/da1 is opened for reading (or writing) every time, amd64_syscall(=
) ->
kern_openat() -> ... -> g_dev_open() -> g_access() -> g_disk_access() ->
daopen() -> dareprobe() sends the DA_STATE_PROBE_RC16 command; if the disk
capacity was changed, in g_disk_access(), we update provide's mediasize
***immediately***: pp->mediasize =3D dp->d_mediasize;

Later, in disk_resize(), g_disk_resize() -> g_resize_provider(): because of
disk's size =3D=3D pp->mediasize, g_resize_provider() doesn't post the
g_resize_provider_event event at all. This is why "camcontrol reprobe da1"
can't help.

BTW, opening da1 for writing can work because the provider is destroyed and
re-created, as you mentioned.

I'll be proposing a patch.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211028-14739-Psr75wI1wL>