From owner-freebsd-bugs@freebsd.org Sun Jul 24 10:30:09 2016 Return-Path: Delivered-To: freebsd-bugs@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 7D898BA11DF 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 6D1F61E75 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 u6OAU8PM037415 for ; Sun, 24 Jul 2016 10:30:09 GMT (envelope-from bugzilla-noreply@freebsd.org) 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 Date: Sun, 24 Jul 2016 10:30:08 +0000 X-Bugzilla-Reason: AssignedTo 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-bugs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Bug reports 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 the assignee for the bug.=