On Sat, Jul 09, 2016 at 11:07:22AM -0400, Allan Jude wrote: > On 2016-07-08 22:32, Dexuan Cui wrote: > >> From: Andrey V. Elsukov [mailto:bu7c...@yandex.ru] > >> Sent: Saturday, July 9, 2016 1:32 > >> To: Dexuan Cui <de...@microsoft.com>; freebsd-geom@freebsd.org > >> Cc: sobomax <sobo...@freebsd.org>; Sepherosa Ziehau > >> <sepher...@gmail.com>; ken <k...@freebsd.org>; Allan Jude > >> <allanj...@freebsd.org>; Hongjiang Zhang <honz...@microsoft.com>; imp > >> <i...@freebsd.org> > >> Subject: Re: How to force GEOM to recalculate the free space after the > >> disk is > >> resized? > >> > >> On 08.07.16 15:19, Dexuan Cui via freebsd-geom wrote: > >>> I'm not familiar with GEOM. Can somebody please explain the > >>> behavior? > >>> > >> > >> What FreeBSD version do you use? > >> What messages do you see in the console/dmesg after resizing of disk? > >> > >> WBR, Andrey V. Elsukov > > > > I'm using 11-CURRENT, but I also tried 10.3 and got the same result. > > > > I'm using verbose krenel message but I only see such a line on the first > > "diskinfo /dev/da1": WARNING: Disk drive da1 has no d_delmaxsize > > > > If I use "sysctl kern.geom.debugflags=253" (log everything except G_T_BIO), > > I get > > the below very verbose output FYI: > > > > Dexuan: after the disk capacity change, this is for the first "diskinfo > > /dev/da1". > > 1 g_dev_open(da1, 1, 8192, 0xfffff80111d95000) > > 2 g_access(0xfffff80004c92880(da1), 1, 0, 0) > > 3 open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] > > 0xfffff80004a63500(da1) > > 4 g_disk_access(da1, 1, 0, 0) > > 5 g_post_event_x(0xffffffff80996bb0, 0xfffff8001369e400, 1, 0) > > 6 WARNING: Disk drive da1 has no d_delmaxsize > > 7 g_dev_close(da1, 131073, 8192, 0xfffff80111d95000) > > 8 g_access(0xfffff80004c92880(da1), -1, 0, 0) > > 9 open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] > > 0xfffff80004a63500(da1) > > 10 g_disk_access(da1, -1, 0, 0) > > 11 > > > > Dexuan: this is for the second "diskinfo /dev/da1". > > 12 > > 13 g_dev_open(da1, 1, 8192, 0xfffff80111d95500) > > 14 g_access(0xfffff80004c92880(da1), 1, 0, 0) > > 15 open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] > > 0xfffff80004a63500(da1) > > 16 g_disk_access(da1, 1, 0, 0) > > 17 g_post_event_x(0xffffffff80996bb0, 0xfffff8001369e400, 1, 0) > > 18 g_dev_close(da1, 131073, 8192, 0xfffff80111d95500) > > 19 g_access(0xfffff80004c92880(da1), -1, 0, 0) > > 20 open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] > > 0xfffff80004a63500(da1) > > I don't think any of the r/w/e numbers should ever be able to go > negative. I am just guessing, but might be related to the problem.
They don't go negative. By doing g_access(prov, -1, 0, 0) you simply close read access to the provider. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com
signature.asc
Description: PGP signature