Date: Sun, 24 Jul 2016 10:30:08 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 211028] [GEOM][Hyper-V] gpart can't detect the new free space after the disk capacity changes Message-ID: <bug-211028-8-YoZFz1IFJ6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-211028-8@https.bugs.freebsd.org/bugzilla/> References: <bug-211028-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211028 --- Comment #29 from Andrey V. Elsukov <ae@FreeBSD.org> --- (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 > before - even when there's no resize. g_part is now calling its resize c= ode > paths and trying to make sense. When geom_disk object is created its size is initialized. If its size is the same, resize event will not be invoked. So, there is definitely present size change. At least sometimes disks reported different size. > GEOM_PART: partition 3 has end offset beyond last LBA: 143374615 > 143374= 610 > GEOM_PART: integrity check failed (da1, GPT) >=20 > This matches the bad partitioning and the GPT should have been rejected t= he > very first time around. The problem is that it is only being detected > perhaps 1 in 10 times. >=20 > Aside from the panic, the second problem is the inconsistency. It should= be > attempting to repair all 6 drives, but isn't. Sometimes it doesn't detect > any of the bad disks and boots successfully. Is the event getting lost? = I > think you're racing with initialization / tasting somehow and I suspect > that's a bigger problem. The metadata on the disk cannot be sometimes correct and sometimes not. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211028-8-YoZFz1IFJ6>