Re: GPT vs BSD-label

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Feb 8,  3:02pm, Swift Griggs wrote:
} On Mon, 8 Feb 2016, John Nemeth wrote:
} > Standard BSD disklabels have the same limitation as MBRs as they use 
} > 32-bit numbers for partition start and size.
} 
} I take it that there is more to it than that... ? I'm sure I'm 
} over-simplifying, but simply changing the long to a int64_t I suppose has 
} greater impact and implications for other tools and code that read 
} disklabels, right ?

     Those problems could be solved.  Obviously, old tools wouldn't
work with the new format; however, new tools could work with either
format.  But, the first issue is that it is an on-disk format.
You need to find the space to expand the disklabel and do so in a
manner that doesn't break anything.  As demonstrated by OpenBSD,
supposedly, this is possible (I have not examined it in any depth
to assure myself that it doesn't break anything; I am simply aware
of it).

} I'm sure you see where I'm going. I'm just basically thinking that I have 
} no need for GPT partition tables on systems that will never run anything 
} but NetBSD. The only concern is losing capacity or the ability to get at 

     Slowly, but surely, that is the way that NetBSD is moving, at
least on system where that will be the norm.

} future capacity. Your point about 6TB disks is spot-on. However, disk 
} slices are fundemental to BSD and it's tools, so I figured I do an 

     So are many other things that seemed like a great idea 40
years ago, but times change.  Some of those things are still good
ideas, some are not.

} experiment with "nothing but what I need". I find GPT's tail-backup 
} annoying anyway.

     I consider it a feature.  Loss/corruption of sectors at the
beginning of a disk isn't totally uncommon.  Having a quick and
easy way of recovering a disk is quite useful.  One just needs to
be aware of it and what they are doing with respect to it.  It's
a learning curve, but so were disklabels at one time.

     Keep in mind, that I am definitely not an advocate of change
for the sake of change, but if there is a need or a clear advantage
then yes.  In this case, the need was is obvious, the limitations
of the format bumping up against newer drives.  The other need was
to keep up and be usable on modern PCs and certain other systems.
Right now, most systems still have a Compatibility Support Module,
but the day will come when you work with the modern stuff, or you
don't work at all.

     BTW, disklabels were released with 4.3BSD-Tahoe, which was
released in June 1988 (28 years ago).  There were plenty of versions
of BSD prior to that which didn't support disklabel.  The first
release of BSD was in 1977, so it took 11 years for disklabel to
come about.  In 1988, an 80MB HD would have been huge and probably
not available for the type of machines that BSD ran on.  With 80MB
HDs, you would need 25,000 of them to make 2TB, which means 2TB
was unfathomable.  Given the constraints of the time, disklabel
was a reasonable format.  However, time tends to blow away all
constraints.

}-- End of excerpt from Swift Griggs