Re: Adding an ioctl to check for disklabel existence

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

On Oct 2,  9:47pm, Mouse wrote:
}
} >> If _that_'s what you're concerned about, then just grow the relevant
} >> fields (and, presumably, change the magic number).
} > Any change to the label format or semantics would make it be a
} > completely different object, no longer compatible with anything.
} 
} Of course.
} 
} > If we were going to invent something new that way, we may as well
} > make it lots better - and ideally compatible with other systems so we
} > can read one another's drives.
} 
} > That's what GPT is, and it is already supported.
} 
} Except for the "better" part, which is a matter of opinion.  I don't
} care for GPT.
} 
} - Partitions are huge.  128 bytes, when you actually need maybe 18 (and
}    about a quarter of even that is pure future-proofing paranoia).

     I assume that you're talking about the size of a partition
entry here.  The size might be somewhat wasteful, but on a
multi-terabyte drive isn't a particularly large concern.

} - Partition types are UUIDs.  Why use 16 bytes when you have, in the
}    information-theoretic sense, maybe three bits of information?
}    (At least, I can't recall the last time I used a partition type
}    other than FFS, unused, swap, MSDOS, or NTFS - and NTFS only for
}    trying to figure out what's on Windows disks.  Six bits, maybe,
}    based on doubling the number of types I see in disklabel_gpt.h.  My
}    "18" above assumes 16 bits.)

     I have 38 types in my list, which I'm sure is incomplete.
That's a bit more than three bits.  When the space is small compared
to the utilisation, collisions are highly likely.  Anybody can
generate an UUID and if done properly the likelihood of collisions
is very small.  This would be the obvious reason for using an UUID.
Remember that GPT is a standard meant to be used by all operating
systems on multiple platforms

} - Partition names(!) are character strings, rather than octet strings
}    or integers (an encoding is specified).  This mandates a lot of
}    character-handling crap that does not belong in boot blocks and
}    arguably does not belong in operating systems.  It most certainly is
}    not appropriate for the partition table format to mandate/demand the
}    presence of Unicode support in the operating system.
} 
} It does have one nice thing, a (supposedly-)unique partition
} identifier.  (Of course, nothing can ensure this actually _is_ unique;
} if nothing else, cloning an entire disk will perforce clone these
} `unique' IDs.)  But it doesn't need to be 16 bytes long!  Even adding
} 14 bytes of partition ID to the 18 bytes above still comes out to only
} a quarter of the space GPT burns on each partition.

     Cloning disks always presents issues.  However, gpt(8) has
grown a "uuid" command to generate new UUIDs.  This was primarily
done to help with the cloning problem.  Cloning a disk and then
putting two disks with the same UUIDs on the same system is an
operator error.

} > Why would we want to invent something new, just to be different?
} 
} No, not to be different.  To be better.

     Ah yes, https://xkcd.org/927/

} Except, of course, that (I assume) you don't think it _would_ be
} better.

     Better or not better is not really the point, being incompatible
for specious reasons is.

}-- End of excerpt from Mouse