Date: Sun, 1 Jun 2014 09:53:21 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Ian Lepore <ian@FreeBSD.org> Cc: hackers@FreeBSD.org, "Michael W. Lucas" <mwlucas@michaelwlucas.com> Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <20140601165320.GV43976@funkthat.com> In-Reply-To: <1401634837.20883.74.camel@revolution.hippie.lan> 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> <1401634837.20883.74.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Lepore wrote this message on Sun, Jun 01, 2014 at 09:00 -0600: > 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. Considering that I just brought up head on a 15+ year old machine, and was quite surprised how it "just worked", it is likely that we will still see machines that will break if CHS isn't handled properly... FreeBSD 11.0-CURRENT #2 r265148M: Sat May 3 00:19:19 PDT 2014 jmg@carbon.funkthat.com:/usr/obj/i386.i386/usr/src/sys/serbox i386 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 CPU: AMD-K6tm w/ multimedia extensions (200.46-MHz 586-class CPU) Origin="AuthenticAMD" Id=0x562 Family=0x5 Model=0x6 Stepping=2 Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX> AMD Features=0x400<<b10>> real memory = 134217728 (128 MB) avail memory = 120770560 (115 MB) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140601165320.GV43976>