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

Attachment: signature.asc
Description: PGP signature

Reply via email to