Date: Sun, 01 Jun 2014 09:00:37 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Warren Block <wblock@wonkity.com> Cc: John-Mark Gurney <jmg@funkthat.com>, hackers@FreeBSD.org, "Michael W. Lucas" <mwlucas@michaelwlucas.com> Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <1401634837.20883.74.camel@revolution.hippie.lan> In-Reply-To: <alpine.BSF.2.00.1406010833290.24305@wonkity.com> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> <alpine.BSF.2.00.1406010833290.24305@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1401634837.20883.74.camel>