https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
Andrey V. Elsukov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #37 from commit-h...@freebsd.org ---
A commit references this bug:
Author: ae
Date: Fri Sep 30 03:45:41 UTC 2016
New revision: 306476
URL: https://svnweb.freebsd.org/changeset/base/306476
Log:
MFC r303019:
Use g_resize_pr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #36 from commit-h...@freebsd.org ---
A commit references this bug:
Author: ae
Date: Mon Aug 1 20:54:54 UTC 2016
New revision: 303637
URL: https://svnweb.freebsd.org/changeset/base/303637
Log:
Do not invoke resize event if in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #35 from commit-h...@freebsd.org ---
A commit references this bug:
Author: ae
Date: Mon Jul 25 09:12:08 UTC 2016
New revision: 303288
URL: https://svnweb.freebsd.org/changeset/base/303288
Log:
Do not invoke resize method if g
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #34 from Andrey V. Elsukov ---
(In reply to Peter Wemm from comment #31)
> Note the "GEOM new disk, 0 bytes" happens before the probe messages.
> Presumably the nature of the original panic we were seeing was that was
> trying
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #33 from Peter Wemm ---
With the patch from #30 the machine in question hasn't had any more hiccups. It
is behaving in a bug-compatible way with the way it was before the commit that
started the panics.
--
You are receiving th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #32 from Peter Wemm ---
It fairly consistently prints one or two 'GEOM new disk .. 0 bytes' before the
disk probe messages but has not crashed. It is usually different disks each
time. And it has not ever detected the corrupt
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #31 from Peter Wemm ---
The first few boot attempts looked like this:
...
(da0:mpt0:0:0:0): UNMAPPED
(da1:mpt0:0:1:0): da0 at mpt0 bus 0 scbus0 target 0 lun 0
da0: Fixed Direct Access SCSI-3 device
da0: Serial Number A107P49025
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #30 from Andrey V. Elsukov ---
Created attachment 172924
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=172924&action=edit
Increase debugging in geom_disk
Can you apply this patch and enable bootverbose mode?
--
Yo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #29 from Andrey V. Elsukov ---
(In reply to Peter Wemm from comment #28)
> There is no size change. The problem is that instead of copying the media
> size, you're introducing a new resize event at open time that wasn't there
>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #28 from Peter Wemm ---
There's no size decreases. The sizes match what is in the initial probe
messages.
What's happening is that the disk is mis-partitioned like this:
Disk size: 143374650 sectors
sector 0: PMBR
sector 1-39
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #27 from Andrey V. Elsukov ---
(In reply to Peter Wemm from comment #26)
> On closer examination, the GPT headers on these drives have strange things
> going on. It does look like there's a 6 sector overallocation:
> GEOM_PART:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #26 from Peter Wemm ---
On closer examination, the GPT headers on these drives have strange things
going on. It does look like there's a 6 sector overallocation:
GEOM_PART: da1 was automatically resized.
Use `gpart commit da
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #25 from Peter Wemm ---
In case this matters it is exploding on actual SCSI disk systems.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
Peter Wemm changed:
What|Removed |Added
CC||pe...@freebsd.org
--- Comment #24 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #23 from Dexuan Cui ---
(In reply to Andrey V. Elsukov from comment #22)
Got it. Thank you, Andrey!
--
You are receiving this mail because:
You are the assignee for the bug.
___
free
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #22 from Andrey V. Elsukov ---
I think we need a bit more time to test this, so I don't think it will be in
11.0-release.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #21 from commit-h...@freebsd.org ---
A commit references this bug:
Author: ae
Date: Tue Jul 19 05:36:21 UTC 2016
New revision: 303019
URL: https://svnweb.freebsd.org/changeset/base/303019
Log:
Use g_resize_provider() to chang
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #20 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #19)
The 11-beta3 build will begin on July 22.
I hope we can have Andrey's patch committed before the date so that it can get
more tests. I think we definitely want t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #19 from Dexuan Cui ---
(In reply to Andrey V. Elsukov from comment #18)
Your patch is good and it works per my tests.
Thank you very much, Andrey!
Can you please commit it to the CURRENT branch and can we consider merging it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #18 from Andrey V. Elsukov ---
(In reply to Dexuan Cui from comment #17)
> (In reply to Dexuan Cui from comment #16)
> Please review the attached patch. It may be a little ugly since I'm pretty
> new to GEOM code... Please sugge
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #17 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #16)
Please review the attached patch. It may be a little ugly since I'm pretty new
to GEOM code... Please suggest how we should fix the issue in a better way.
--
Yo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #16 from Dexuan Cui ---
Created attachment 172554
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=172554&action=edit
The patch can work, but it may be a little ugly...
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #15 from Dexuan Cui ---
Hi all,
I know why g_disk_resize() can't work here when I open da1 for reading after a
disk capacity change:
When /dev/da1 is opened for reading (or writing) every time, amd64_syscall() ->
kern_openat()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #14 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #13)
When I got the kernel messages in comment 13, dtrace showed this:
[root@decui-b11 ~]# dtrace -n 'fbt::*disk_resize:entry
fbt::g_part_*resize:entry {stack(5);}'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #13 from Dexuan Cui ---
(In reply to Edward Tomasz Napierala from comment #11)
With kern.geom.debugflags=253 (log everything except G_T_BIO) and
debug.bootverbose=1, after the disk capacity was changed from 180GB to 200GB, I
go
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #12 from Dexuan Cui ---
(In reply to Edward Tomasz Napierala from comment #11)
Thank you both for the analysis!
The g_resize_provider() is after the first read, and before the "camcontrol
reprobe". I'm going to use try debugfla
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #11 from Edward Tomasz Napierala ---
Hm, you're right.
Dexuan - the g_resize_provider() you're seeing, is that after "camcontrol
reprobe", or after the first read? Can you bump GEOM debugflags and show what
happens on the firs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #10 from Andrey V. Elsukov ---
(In reply to Edward Tomasz Napierala from comment #9)
> Hm. Okay. The read dd works, because the da(4) driver gets notified about
> the capacity change on the first read command sent to the disk;
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #9 from Edward Tomasz Napierala ---
Hm. Okay. The read dd works, because the da(4) driver gets notified about the
capacity change on the first read command sent to the disk; basically the disk
responds with Unit Attention indi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #8 from Dexuan Cui ---
(In reply to Edward Tomasz Napierala from comment #7)
Hi Edword,
Yes, exactly.
After the disk capacity change, if I do "camcontrol reprobe da1", gpart can see
both the capacity & free space are updated.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #7 from Edward Tomasz Napierala ---
Also - correct me if I'm wrong, but even if you don't do reprobe, you still see
the new size of da1 - 50G, so GEOM already "sees" the updated size, it's just
that g_part(4) doesn't update the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #6 from Edward Tomasz Napierala ---
It looks like the da(4) driver correctly noticed the updated capacity:
(da1:storvsc1:0:0:0): Capacity data has changed
So "camcontrol reprobe" shouldn't really do anything.
--
You are rece
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #5 from Dexuan Cui ---
(In reply to Andrey V. Elsukov from comment #3)
Thank you Andrey for the detailed instructions!
g_resize_provider() returns at Line 671 and at this line, both 'size' and
'pp->mediasize' are the new disk c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #4 from Andrey V. Elsukov ---
# kldload dtraceall
# dtrace -n 'fbt::*disk_resize:entry fbt::g_part_*resize:entry {stack(5);}'
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #2 from Dexuan Cui ---
(In reply to Dexuan Cui from comment #0)
In comment 0, if I skip step 3, that is, I don't run the "dd" and only run
"camcontrol reprobe da1", "gpart show da1" can detect the new "free" space
correctly.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
--- Comment #1 from Dexuan Cui ---
BTW, dmesg shows:
This corresponds to the "dd":
(da1:storvsc1:0:0:0): storvsc scsi_status = 2
(da1:storvsc1:0:0:0): Capacity data has changed
(da1:storvsc1:0:0:0): storvsc skips the validation for short i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211028
Bug ID: 211028
Summary: [GEOM][Hyper-V] gpart can't detect the new free space
after the disk capacity changes
Product: Base System
Version: CURRENT
Hardware: Any
39 matches
Mail list logo
