On Mon, 2014-01-27 at 10:53 +0100, Karel Zak wrote: > Frankly, who cares about partition types? Sure... > It's bad idea to use partition types for something else ... but,.. GPT part types are there and won't go away just because they're mostly unused... An I think it's actually much worse to have people set *some value* (which may actually be used by something else in some way - since people will not just set a random UUID, but something that their part manager provides them from its list) than a well defined value (even if that is never used by dm-crypt or its tools. Moreover,... it may actually make sense for the plain dm-crypt type (which would of course need another ID than the LUKS type), where we have no other way to see that this is dmcrypt. On the other hand one could argue, that this is much like the issue with MIME types and stuff like .gz or .bz2. The MIME-type of a gzipped PNG, e.g. image.png.gz should still be image/gz and not something like application/x-gzip. GZIP in that case is not a type, but an encoding. With tar or zip it would be different, since both are not just encodings of a file. Now coming back to GPT UUIDs and plain dm-crypt/LUKS: 1) IMHO for LUKS it's clear - it's not like an encoding, but contains additional stuff (all the header parts) => own GPT type 2) With plain dm-crypt one could argue that this is just an "encoding" of something below it like "Linux FS" or "MD containter". So one could do three things: a) either the GPT type of encrypted partition would apply (if one follows the principles of MIME) b) One makes a new GPT type for each <whatever>-on-top-of<plain dmcrypt> e.g. plainly-dmcrypted-Linux-FS, plainly-dmcrypted-MD-container, and so on. c) One goes the pragmatic way and makes just one single type for any plain dm-crypt partition. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt