From owner-freebsd-geom@freebsd.org Sat Jul 9 15:07:29 2016 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01098B84101 for ; Sat, 9 Jul 2016 15:07:29 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB1CF1A1C; Sat, 9 Jul 2016 15:07:28 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 120271086; Sat, 9 Jul 2016 15:07:27 +0000 (UTC) Subject: Re: How to force GEOM to recalculate the free space after the disk is resized? To: Dexuan Cui , "Andrey V. Elsukov" , "freebsd-geom@freebsd.org" References: <577FE380.8020601@yandex.ru> Cc: sobomax , Sepherosa Ziehau , ken , Hongjiang Zhang , imp From: Allan Jude Message-ID: <81898d87-3413-d7a4-9462-069567a69701@freebsd.org> Date: Sat, 9 Jul 2016 11:07:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fPTf5NRdVwC7r793SaOc9wnga8fWsd446" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 15:07:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fPTf5NRdVwC7r793SaOc9wnga8fWsd446 Content-Type: multipart/mixed; boundary="7kXAVjkNJl0xqOHUpWDenvEP9DH1DJ2dJ" From: Allan Jude To: Dexuan Cui , "Andrey V. Elsukov" , "freebsd-geom@freebsd.org" Cc: sobomax , Sepherosa Ziehau , ken , Hongjiang Zhang , imp Message-ID: <81898d87-3413-d7a4-9462-069567a69701@freebsd.org> Subject: Re: How to force GEOM to recalculate the free space after the disk is resized? References: <577FE380.8020601@yandex.ru> In-Reply-To: --7kXAVjkNJl0xqOHUpWDenvEP9DH1DJ2dJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-07-08 22:32, Dexuan Cui wrote: >> From: Andrey V. Elsukov [mailto:bu7cher@yandex.ru] >> Sent: Saturday, July 9, 2016 1:32 >> To: Dexuan Cui ; freebsd-geom@freebsd.org >> Cc: sobomax ; Sepherosa Ziehau >> ; ken ; Allan Jude >> ; Hongjiang Zhang ; imp >> >> 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 >=20 > I'm using 11-CURRENT, but I also tried 10.3 and got the same result. >=20 > I'm using verbose krenel message but I only see such a line on the firs= t > "diskinfo /dev/da1": WARNING: Disk drive da1 has no d_delmaxsize >=20 > If I use "sysctl kern.geom.debugflags=3D253" (log everything except G_T= _BIO), I get > the below very verbose output FYI: >=20 > Dexuan: after the disk capacity change, this is for the first "diskinf= o /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] 0xfffff80004a635= 00(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] 0xfffff80004a63= 500(da1) > 10 g_disk_access(da1, -1, 0, 0) > 11 >=20 > 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] 0xfffff80004a635= 00(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] 0xfffff80004a63= 500(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. > 21 g_disk_access(da1, -1, 0, 0) > 22 >=20 > Dexuan: after disk capacity change, this is for the first "gpart show /= dev/da1": > the new free space is not detected, though the new disk capacity is det= ected. > 23 > 24 g_post_event_x(0xffffffff80998520, 0xfffff800043942c0, 2, 262144) > 25 g_post_event_x(0xffffffff80998520, 0xfffff800043942c0, 2, 262144) > 26 g_post_event_x(0xffffffff80998520, 0xfffff800043942c0, 2, 262144) > 27 g_post_event_x(0xffffffff80998520, 0xfffff800043942c0, 2, 262144) > 28 >=20 > Dexuan: this is for the=20 > openat(AT_FDCWD,"/dev/da1",O_WRONLY|O_CREAT,0644);": > 29 > 30 g_dev_open(da1, 2, 8192, 0xfffff80111d95500) > 31 g_access(0xfffff80004c92880(da1), 0, 1, 0) > 32 open delta:[r0w1e0] old:[r0w0e0] provider:[r0w0e0] 0xfffff80004a635= 00(da1) > 33 g_disk_access(da1, 0, 1, 0) > 34 g_post_event_x(0xffffffff80996bb0, 0xfffff8001369e400, 1, 0) > 35 g_post_event_x(0xffffffff8099e760, 0xfffff80004a63500, 2, 0) > 36 ref 0xfffff80004a63500 > 37 g_spoil_event 0xfffff80004a63500(DISK:da1:da1) > 38 g_part_spoiled(da1) > 39 g_wither_geom(0xfffff802693bc700(da1)) > 40 g_detach(0xfffff80004c92800) > 41 g_destroy_consumer(0xfffff80004c92800) > 42 g_destroy_geom(0xfffff802693bc700(da1)) > 43 g_dev_close(da1, 131074, 8192, 0xfffff80111d95500) > 44 g_access(0xfffff80004c92880(da1), 0, -1, 0) > 45 open delta:[r0w-1e0] old:[r0w1e0] provider:[r0w1e0] 0xfffff80004a63= 500(da1) > 46 g_disk_access(da1, 0, -1, 0) > 47 g_post_event_x(0xffffffff8099db70, 0xfffff80004a63500, 2, 0) > 48 ref 0xfffff80004a63500 > 49 g_raid_taste(RAID, da1) > 50 g_attach(0xfffff80004c92800, 0xfffff80004a63500) > 51 g_access(0xfffff80004c92800(da1), 1, 0, 0) > 52 open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xfffff80004a635= 00(da1) > 53 g_disk_access(da1, 1, 0, 0) > 54 g_post_event_x(0xffffffff80996bb0, 0xfffff8001369e400, 1, 0) > 55 g_access(0xfffff80004c92800(da1), -1, 0, 0) > 56 open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xfffff80004a63= 500(da1) > 57 g_disk_access(da1, -1, 0, 0) > 58 g_detach(0xfffff80004c92800) > 59 g_destroy_consumer(0xfffff80004c92800) > 60 g_destroy_geom(0xfffff80269439400(raid:taste)) > 61 g_label_taste(LABEL, da1) > 62 g_attach(0xfffff80004c92800, 0xfffff80004a63500) > 63 g_access(0xfffff80004c92800(da1), 1, 0, 0) > 64 open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xfffff80004a635= 00(da1) > 65 g_disk_access(da1, 1, 0, 0) > 66 g_post_event_x(0xffffffff80996bb0, 0xfffff8001369e400, 1, 0) > 67 g_access(0xfffff80004c92800(da1), -1, 0, 0) > 68 open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xfffff80004a63= 500(da1) > 69 g_disk_access(da1, -1, 0, 0) > 70 g_detach(0xfffff80004c92800) > 71 g_destroy_consumer(0xfffff80004c92800) > 72 g_destroy_geom(0xfffff80269439400(label:taste)) > 73 g_part_taste(PART,da1) > 74 g_attach(0xfffff80004c92800, 0xfffff80004a63500) > 75 g_access(0xfffff80004c92800(da1), 1, 0, 0) > 76 open delta:[r1w0e0] old:[r0w0e0] provider:[r0w0e0] 0xfffff80004a635= 00(da1) > 77 g_disk_access(da1, 1, 0, 0) > 78 g_post_event_x(0xffffffff80996bb0, 0xfffff8001369e400, 1, 0) > 79 g_access(0xfffff80004c92800(da1), -1, 0, 0) > 80 open delta:[r-1w0e0] old:[r1w0e0] provider:[r1w0e0] 0xfffff80004a63= 500(da1) > 81 g_disk_access(da1, -1, 0, 0) > 81 g_disk_access(da1, -1, 0, 0) >=20 > Dexuan: this is for the second "gpart show /dev/da1": the new free spac= e is > detected: > 82 > 83 g_post_event_x(0xffffffff80998520, 0xfffff800043942c0, 2, 262144) > 84 g_post_event_x(0xffffffff80998520, 0xfffff800043942c0, 2, 262144) > 85 g_post_event_x(0xffffffff80998520, 0xfffff800043942c0, 2, 262144) > 86 g_post_event_x(0xffffffff80998520, 0xfffff800043942c0, 2, 262144 >=20 >=20 > Thanks, > -- Dexuan >=20 --=20 Allan Jude --7kXAVjkNJl0xqOHUpWDenvEP9DH1DJ2dJ-- --fPTf5NRdVwC7r793SaOc9wnga8fWsd446 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJXgRMuAAoJEBmVNT4SmAt+2hQP/0KRnvWTV+2oj/UlV8O2B1Fx HEWcomqPosVJaSnnxzq8ykgK9GzoujC4tCAsuSYuEL7gqK6N5RsIvr+Mptu0SuIX jFLhaXTqSxdR23GVz27OKseGUh9kMjDIKvvkXR/VToyX+hbsnQ7uEynsCv6WdYZE SMPoGoOl5zzlemPnEf0sFnighvPyKpj3XoHoW0phITTuzetFxPObE1Rapn0boQWf e0esfujmGRA8HNb4RDAbOG6vPlb7oOfFtmP/ESVcoGPl8VtQJZpWozHq6KujnQx2 +K/aWkrj9dmeICWMy5MYTJqSZcurhHbbCo1X7cy07ZNcj03QRDAo+Zacel+K2lGo myxU5Xff1EtXlHg5dfJGSiLSF78buTwszQ8ZVWY9ul2AsPO3BHUF4h8owAlZ/8LA 3v0qsvom+KJyPO4SUCl2WFn6RLgMTBQPDo3r2wB+2WE6c/gLXvS+c9KvbtUiYdca QBAH62LK6GyMQ+avTxLdGkuU0Fd1lkAieiDzBRHLN1Adscc1hGPACy9NHsu9Hyup VZOYErK/TM0/C5TiEYzLq2SLqnqafawWaK4bEjHnstDyN72r9e6uM13zHVX+POAX 6zSF/uoB2K2eaxxKtdzlSOzS0t7DMLdDc6cC9Or4JZ7rYST/U8AXV75PLu69pLX4 zfkw26Aady/w08sZ8dOP =tNRB -----END PGP SIGNATURE----- --fPTf5NRdVwC7r793SaOc9wnga8fWsd446--