fdisk(8) vs gpart(8), and gnop

[John-Mark Gurney]

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 at 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."