Is it time to dump disklabel and use GPT instead?

[Samuel J. Greear]

On Tue, Jul 27, 2010 at 7:44 PM,  <elekktretterr at exemail.com.au> wrote:
>> What evidence do you have of newcomers being "more than often" turned
>> away by having to use "archaic tools"?
>
> I visit a couple of Linux forums, and while the word "DragonFly" surely
> seems to have picked up some usage in the recent months, I also hear that
> they go somewhere else after a brief experience setting it up. Majority of
> these people seem try DragonFly because of HAMMER and their aim is to
> setup a "backup" box.
>
>> If they want DragonFly only on their whole disk, they can just let the
>> installer install DragonFly to the whole disk without having to use
>> either fdisk or disklabel.
>
> From what I hear, people prefer to use a separate hard disk(s) instead of
> using the one on which they installed DragonFly initially to store their
> backups. So they cannot avoid fdisk and disklabel.
>
> It made me think, what advantage do we get by over-complicating things
> with disklabels, sectors, offsets etc? They are things that, I feel,
> majority of *nix users don't wanna hear about these days. I've used *BSD
> for a few years and while i never really had problems with
> disklabel(except once), it does seem kind of cool to "partition a slice",
> it is redundant at the same time especially now that GPT is here and it
> does work with existing BIOSes.
>
> I blasted away a DF disklabel by accident once(installing FreeBSD on
> another slice) and I didnt have backups and I managed to recover my data
> only partially, sure my fault..i didnt have a backup, but on the other
> hand I blame the disklabel to be too easy to stuff up.
>
> As I mentioned earlier, another issue they seem to find, is the
> non-availability of choosing BASH during the install.
>
> -------------
>
> So, what is the real world advantage of using disklabel, that can't be
> done with GPT on 99.99% of all OS install? that is worth breaking
> compatibility with other *BSDs - each BSD implements disklabel
> differently- and other OSs like Linux - doesn't use disklabel at all but
> for Linux to support reading/writing to HAMMER or UFS, it would have to
> implement some basic disklabel support.
>
> Petr
>

I am relatively certain nobody is going to argue, your points are
mostly valid, and there are others you did not mention.

I am also relatively certain nobody is going to stand up and do the
work, unless you do. There is finite manpower and to my knowledge
existing committers have any number of priorities before even
considering GPT.

Failing this it is possible someone would make it a priority if there
were a reasonable code bounty placed on it.

Sam