Re: GPT vs BSD-label

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Tue, 9 Feb 2016, Christos Zoulas wrote:
> OpenBSD has done it. I've made the same code changes but I stopped just 
> before committing because we have dozens of custom copies of disklabel 
> code that would need to be adjusted and tested.

Well, not like I have any authority, but I'd welcome that change. I can 
learn to love GPT at some point, too. It's just a bit different. However, 
there is still some functionality that comes with labels that seems needed 
above and beyond what a simple partition table will do. Ie.. things like 
the 'overlap' partitions.

Of course, the way Linux does it also works, but if you think about it, 
it's the same as the BSD system in reverse ie..

/dev/sda1 vs /dev/sd1a

So, they use letters first, then numbers. When they run out of letters 
Linux doubles them up:

/dev/sdaa1

I'm not sure there are applications where folks want to make more than 26 
total slices on a disk, but maybe someone knows of one. Since in BSD, the 
disc names are ordinal, that's not going to be a problem. They can just 
number off till the end of time (or their buffer, whichever comes first).

Anyhow, it sounds like GPT is the short answer, and BSD disklabels still 
have some mindshare and it's possible they will also see some enhancement 
(I'm hoping). I will certainly be willing to test on i386, AMD64, SGIMIPS, 
and SPARC platforms. I'll have Amiga 68k going soon as well, but I won't 
have any huge disks to test with on the A68k platform.

Anyhow, I guess there is probably also work to do in other areas like RAID 
Frame and LVM to make sure they can cope with any changes to the disklabel 
code. Hopefully, most of that is abstracted in library calls.

-Swift