From owner-freebsd-geom@freebsd.org Sun Jul 24 10:30:09 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 26FFCBA11DC for ; Sun, 24 Jul 2016 10:30:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 156741E6E for ; Sun, 24 Jul 2016 10:30:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u6OAU8PG037415 for ; Sun, 24 Jul 2016 10:30:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 211028] [GEOM][Hyper-V] gpart can't detect the new free space after the disk capacity changes Date: Sun, 24 Jul 2016 10:30:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 24 Jul 2016 10:30:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211028 --- 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 > 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 on the CC list for the bug.=