Re: [Gptfdisk-general] [PATCH] Add partition type GUIDs for encrypted Linux partitions

[Christoph A. M. <cal...@sc...>]

Hey.

A bit late,...


From: Rod Smith <rodsmith@ro...> - 2015-05-31 22:57:38
>The trouble is that the response from Linux developers was
>overwhelmingly negative. No Linux developer found the case for the
>existence of such a code to be compelling,

I'm kinda surprised... where exactly did you read that "overwhelmingly
negative" response?
My understanding was rather that no one really cared a lot, neither
negatively nor positively, which is simply based on the fact that
partition codes themselves (including the ones for crypto and all
others) are basically useless.


>and the redundant
>information poses a risk of getting out of sync with actual partition
>contents.

Which is the case for literally any other partition type as well.
Yet, you added them.


> No Linux partitioning tool or encryption utility actually
> uses those codes.

Sure, but again, no big surprise... and probably the case for most if
not all other partition codes as well,... at least for anything used in
the Linux world.

The only exception I'd know of is the weird thing systemd offers, i.e.
fstab less booting and deciding the mountpoint of some few locations
based on a special code for them.
But that's really some badly unclean design since a different
mountpoint doesn't make a different "type" of partition content (I
wonder you supported *that* if you don't support what's actually a
proper distinguished type).

Other than that, people except the systemd guys hopefully learned
enough from the MBR types that caused MD RAID to auto-assemble, that
actually using partition types for something without verifying the real
type is kinda stupid.


>Furthermore, although the number of GUIDs is huge

More than there'd be atoms in space...

>supporting
>every possible code somebody might dream up is impractical for GPT
>fdisk, because it increases the size of the list shown when a user
>types "L"
>to get that code list. An increased list size makes it harder to find
>the codes that are actually being used, so supporting these codes
>would degrade GPT fdisk's user interface experience.

Again, we're talking about two proper and different container types,
dm-crypt and LUKS (well one could argue that plain dm-crypt isn't a
container, but it's simply nice to have something for that as well).

Also I didn't ask you to add combinations for all possible types like.
LUKS+ext*
LUKS+btrfs
LUKS+xfs
and so on (which would be bad design again, as the type should only
describe the next level).


So again I'm kinda surprised that you've added stuff like:
bf01 Solaris /usr & Mac Z
bf04 Solaris /var
bf05 Solaris /home
8301 Linux reserved      
8302 Linux /home
which are not real types, but just some fs with a connected mountpoint,
or:
8300 Linux filesystem
which isn't a real type either, but instead there should be types for
xfs, jfs, ext*, btrfs, etc.


Sure, you had to do this, due to the pressure that people did bad
design an misused the partition types for their needs... but then it's
really strange that you don't add something which is actually a type
proper.


>Thus, unless and until I learn that these codes are actually being
>used, I will not add them to GPT fdisk's code list. An individual who
>wants to use them may still do so by entering the GUID value directly,
>but there's really very little benefit to this.

Well it would have the same "benefit" than setting e.g. 8300 Linux
filesystem, it fills an in the real world unused field within the GPT
with a more proper value than e.g. "8300 Linux filesystem" (neither
luks nor dm-crypt is a filesystem).


Cheers,
Chris.