From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 15:00:42 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1202E6BE for ; Sun, 1 Jun 2014 15:00:42 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8DC02335 for ; Sun, 1 Jun 2014 15:00:41 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wr7FY-000IMV-KQ; Sun, 01 Jun 2014 15:00:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s51F0cnV001554; Sun, 1 Jun 2014 09:00:38 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19u8jY+VCCXLNWzXD5Hty+X Subject: Re: fdisk(8) vs gpart(8), and gnop From: Ian Lepore To: Warren Block In-Reply-To: References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Jun 2014 09:00:37 -0600 Message-ID: <1401634837.20883.74.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: John-Mark Gurney , hackers@FreeBSD.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:00:42 -0000 On Sun, 2014-06-01 at 08:36 -0600, Warren Block wrote: > On Sun, 1 Jun 2014, Ian Lepore wrote: > > > On Sat, 2014-05-31 at 19:00 -0700, John-Mark Gurney wrote: > >> Michael W. Lucas wrote this message on Sat, May 31, 2014 at 20:42 -0400: > >>> $SUBJECT have been two contentious points of discussion in private > >>> mail, Twitter, the BSDCan bar track, and random people passing on the > >>> street. I was very surprised at the number of knowledgeable people who > >>> have different ideas on this and argue about it at length. > >>> > >>> I'm hoping to verify what seems to be correct. > >>> > >>> First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' > >>> handles all alignment issues for the 512B/4KB sector issues. If you > >> > >> gpart's -a will not properly align MBR's slices due to enforced CHS... > > > > Maybe this is naive, but... can't we just *fix* that? > > Thread starts here: > http://lists.freebsd.org/pipermail/freebsd-geom/2014-February/005835.html > > > For the longest time geom would warn about "geometry does not match > > label" that had something to do with different parts of the code > > calculating different CHS values. Eventually it was decided to remove > > the unactionable message, and my vague memory is that the justification > > was basically "because CHS is meaningless to geom and modern BIOSen." > > > > If there's some "it would cause problems on this ancient hardware that > > only 3 people in the world use" (I'm usually one of those people -- we > > support some old equipment in the field at $work), then maybe there > > could be a flag that enables the old CHS alignment behavior. > > Short form of above: gpart is supposed to hide and handle underlying > GEOM issues, so it needs an override to be able to create these > "non-standard" MBRs with slices aligned to arbitrary values. Hmm. If it takes a special "do what I actually said" flag, that's okay I guess. My problem with that thread is the implicit assumption that CHS alignment is required by *something* but there's no evidence what that something is, other than "MBR has always in the past been CHS aligned." I don't have enough knowledge in this area to contradict that assumption, I'm just always skeptical of "thus it was spoken in 1982 and thus it will always be" as an argument against sensible change. Looking at what's done on other modern OSes seems reasonable, for example. And then of course there's the matter of a conclusion (perhaps not 100% satisfying, but workable) having been reached, and yet code was never changed. Not that I can volunteer to do it right now, I'm already overcomitted. -- Ian