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. > 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
signature.asc
Description: OpenPGP digital signature
