How to force GEOM to recalculate the free space after the disk is resized?
Allan Jude
allanjude at freebsd.org
Sat Jul 9 15:07:29 UTC 2016
On 2016-07-08 22:32, Dexuan Cui wrote:
>> From: Andrey V. Elsukov [mailto:bu7cher at yandex.ru]
>> Sent: Saturday, July 9, 2016 1:32
>> To: Dexuan Cui <decui at microsoft.com>; freebsd-geom at freebsd.org
>> Cc: sobomax <sobomax at FreeBSD.org>; Sepherosa Ziehau
>> <sepherosa at gmail.com>; ken <ken at FreeBSD.org>; Allan Jude
>> <allanjude at freebsd.org>; Hongjiang Zhang <honzhan at microsoft.com>; imp
>> <imp at 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.
> 21 g_disk_access(da1, -1, 0, 0)
> 22
>
> 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 detected.
> 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
>
> Dexuan: this is for the
> 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] 0xfffff80004a63500(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] 0xfffff80004a63500(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] 0xfffff80004a63500(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] 0xfffff80004a63500(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] 0xfffff80004a63500(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] 0xfffff80004a63500(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] 0xfffff80004a63500(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] 0xfffff80004a63500(da1)
> 81 g_disk_access(da1, -1, 0, 0)
> 81 g_disk_access(da1, -1, 0, 0)
>
> Dexuan: this is for the second "gpart show /dev/da1": the new free space 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
>
>
> Thanks,
> -- Dexuan
>
--
Allan Jude
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20160709/a7205806/attachment.sig>
More information about the freebsd-geom
mailing list