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