From owner-svn-src-head@freebsd.org Tue Oct 9 14:19:27 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D60A810AB3B5 for ; Tue, 9 Oct 2018 14:19:27 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 51F238AE66 for ; Tue, 9 Oct 2018 14:19:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 4f93d205-cbce-11e8-aed8-99744f00ac98 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 4f93d205-cbce-11e8-aed8-99744f00ac98; Tue, 09 Oct 2018 14:19:20 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w99EJJqe012906; Tue, 9 Oct 2018 08:19:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1539094759.72469.37.camel@freebsd.org> Subject: Re: svn commit: r264378 - head/sys/geom/part From: Ian Lepore To: Warner Losh , "Andrey V. Elsukov" Cc: John Baldwin , Marcel Moolenaar , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Josh Paetzel Date: Tue, 09 Oct 2018 08:19:19 -0600 In-Reply-To: References: <201404122028.s3CKSdo1026394@svn.freebsd.org> <2f72f3b3-d890-bed2-742e-fcc39c5618e3@yandex.ru> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 14:19:28 -0000 On Tue, 2018-10-09 at 07:33 -0600, Warner Losh wrote: > On Tue, Oct 9, 2018 at 2:41 AM Andrey V. Elsukov > wrote: > > > > > On 08.10.2018 19:46, John Baldwin wrote: > > > > > > This needs a way to be overridden.  If you have a machine > > > installed with > > a > > > > > > layout created prior to this change (e.g. a zpool mirror or RAID > > > or some > > > other mirror or RAID), you can no longer create a matching > > > partition > > since > > > > > > the starting sector is now always 40 instead of 34 and the > > > partition size > > > won't match.  Also, while we may want to create sane layouts by > > > default, > > we > > > > > > should probably always provide a way to create less-sane layouts > > > that are > > > still conformant to the spec.  I do wonder if this kind of > > > default > > > preference shouldn't belong in the userspace gpart tool rather > > > than the > > > kernel and the kernel should create any compliant layout as > > > requested by > > > userland instead. > > > > > > jpaetzel@ just ran into this case where he can't replace a failed > > > disk > > in a > > > > > > system running 12 that was first formatted on 10, so it's not > > > academic. > > As a workaround you can try to copy first 34 sectors from old disk > > to > > new using dd(1). And then use `gpart recover`. I think this should > > work. > > > Clever hack, but we shouldn't need crazy stuff like this.... > > Yes. This absolutely needs to be in userland, under user control. The > rounding should *ALWAYS* be optional. The reported geometry that the > code > bases the 'rounding' on is bogus often times, and not invariant. I've > fought with this misfeature since I was making CF images on a USB > adapter > that never had the right geometry for the system it was deployed > into. It's > silly. > > Warner While we're at it, kern.geom.part.mbr.enforce_chs is another thing that needs to be controllable on a per-invocation (of gpart) basis, not as a system-wide setting. -- Ian