Re: Adding an ioctl to check for disklabel existence

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 2 Oct 2019 21:47:38 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <201910030147.VAA03745%Stone.Rodents-Montreal.ORG@localhost>

John Nemeth said pretty much exactly what I would have said, but
there are a few points on which I would like to expand...

  | - Partitions are huge.  128 bytes,

Who cares?   These days I (and may others) align partitions on
fairly large boundaries (I use 1MB) for (some) future proofing of drive
technology - that means that the space between 0 and 1MB is unused
for any filesystem purpose, we may as well use all of it for labels
(though even the biggest GPT label doesn't come near to that).

Back in the 1970's when labels (MBR and disklabel) were invented,
trying to compress them into the smallest possible space made sense.
Now it is simply false ecomomy, saving a few meaningless sectors
is irrelevant, losing flexibility is a killer.

  | - Partition types are UUIDs.  Why use 16 bytes when you have, in the
  |    information-theoretic sense, maybe three bits of information?

We know it isn't 3, the 8 bits that MBRs allowed is almost all used up.
You might only need a few, but other people need a different few (you
omitted LFS, ZFS, HFS, ...)

But what really matters is that any small number scheme needs a central
registry, and someone to maintain it - and then some mechanism to extend
it when it starts to run out.

Any new partition scheme designed now really needs to be planned to
last for at least as long, hopefully 10 times as long, as disklabels
and MBR have lasted (40 years) - with who knows what kinds of uses 
of it into the future.

Anyone ought to be able to design a new filesystem and give it a type
which won't conflict with others (MBR types already failed at that,
disklabels are used in such limited systems that it hasn't been such
a problem).   And they ought to be able to do that without having to
deal with a central bureaucracy which might say "no" or "use one of the
private use types we have defined until there are millions of users,
then we'll allocate a real number, and all those millions can be changed",
and "by the way, where do we send the invoice for this service?"

  | - Partition names(!) are character strings, rather than octet strings

The thing that matters is actually a UUID, what you're referring to is
the one thing that is missing from MBR and disklabels that I miss most.

I can see from the label that there are N partitions on the drive,
and what generic type they are (7 FFS and 1 swap) - but which one is
which?   Currently we do that (for FFS anyway) by checking the "last
mounted" in the superblock, but that is unreliable (doesn't work at all
for read only mounted filesystems which might never have been mounted
RW, and if they were might have been on /mnt when they were) and isn't
available at all in many other filesystem types (which of these swap
partitions had dumps enabled on it?)

A human readable name, in the label (ie: associated with the partition,
not the filesystem) can help with that it - it even assists during planning
when no filesystems have yet been created, just to make it easier to keep
track of which have had space allocated.   They're not required (by anything)
to be unique, or really usable for much, but they're an incredibly useful
thing to have.

  |    It most certainly is
  |    not appropriate for the partition table format to mandate/demand the
  |    presence of Unicode support in the operating system.

Nothing of the kind is required, the OS doesn't need to use the label (name)
at all if it doesn't want (for a long time, NetBSD used GPT without doing
so in the kernel - only recently has some of this been added.)

  | It does have one nice thing, a (supposedly-)unique partition
  | identifier.

That's the real name (identifier) of the partition, not the name.

  | (Of course, nothing can ensure this actually _is_ unique;

No, but statistically, cloning aside (where sometimes being not unique
is exactly what is required, a clone should be identical) they are
very likely unique, and if generater properly, I don't imagine I'll
even see a (non-clone) duplicate.   I don't imagine you will either,
unless you force it.

  | No, not to be different.  To be better.
  |
  | Except, of course, that (I assume) you don't think it _would_ be
  | better.

It is entirely possible that one might design a partitioning scheme
that is better than GPT.   But by your argument I couldn't use that
one, as it is just as possible to design one even better still, and
even that one isn't usable for the same reason.

At some point we (the world, not NetBSD) needs to simply say "good enough"
and stop arguing.   GPT is certainly good enough.   Much better than
disklabels or MBR (aside from anything else it has no fixed maximum number
of partitions ... a particular label can only handle some number, but you
get to decide when you create the label how many you need).   Further
everything you don't like about it, I consider a step in the right direction.

If anything the problem with GPT might be that the numbers aren't big
enough (the GUID fields should be fine, but only 64 bits for sector
addresses?)   Fortunately the GPT header has a revision field, so this
can be fixed in a reasonably backwards compatible way when it is needed.
(I probably would have simply made the partition data (gpt_ent) be 512
bytes each - with much of it simply paddin for now).

Even now, the GPT system is missing creation/modification date fields
which I certainly would have added. I probably would have simply made
the partition data (gpt_ent) be 512 bytes each - with much of it simply
padding for now.   So, it isn't perfect.   It is however adequate.


In another message, David Brownlee <abs%absd.org@localhost> said:
  | there is also prior art in extending disklabel to 64bits - OpenBSD
  | did this back in 2007

In 2007, that might have made some sense - then it was obvious that
filesystems would eventually exceed the 2TB limit (and some with raid
type systems already had) but there was no replacement labelling scheme
on the horizon (if GPT was designed, or planned, back then, it certainly
wasn't well known).

Now it makes no sense at all.

kre

ps: on old small drives you can still use disklabels of course, they're
not being deleted, and even when (which I forsee happening someday) the
primary interface isn't them, I still expect code to exist to read the
things and convert into whatever internal form is being used (perhaps
GPT, perhaps some subset of that, or extended subset) if for no other
reason than that it would be needed for transition, and once the code
exists there's no good reason to ever delete it, even when it reaches
the stage that it is very rarely used any more.