bug#17994: Linux RAID MBR type code

[Chris Murphy]

On Jul 14, 2014, at 8:03 AM, Phillip Susi <address@hidden> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 7/13/2014 9:07 PM, Chris Murphy wrote:
>>> Why does it matter?  Linux doesn't pay attention to the
>>> partition type code anyhow.  I've always just used 0x83.
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c5 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1118065#c8
>> 
>> 
>> I find this logic troubling. It's rather similar to the logic that 
>> lead to parted using the pre-existing Microsoft basic data GUID
>> when making Linux partitions on GPT disks; out of a pool of just
>> under infinite alternative GUIDs. "Oh it doesn't really matter" on
>> Linux, but meanwhile on dual boot systems, Windows recognizes its 
>> partitiontype GUID, but not the contents of the partition, and 
>> actively invites the user to reformat it.
> 
> How is this at all related?  Windows already ignores 0x83.

It does not ignore EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 on GPT disks. Yet 
parted for *years* has wrongly used this type code by default for Linux 
partitions.

And this relates here because it's the same preposterously flawed logic being 
demonstrated in your responses about this bug, which is that only Linux 
behavior matters. And complete ignorance about how the rest of the world does 
consider partition type codes important.


> 
>> For example, 0x83 partition type, and mdadm metadata 1.0 on md
>> raid1 suggests that the partition can be mounted stand alone rather
>> than first assembling the raid. If something actually were to do
>> this, the array would become inconsistent and unrepairable without
>> rather knowledgable manual intervention. A partition with md
>> metadata is in fact not a Linux filesystem, so really we shouldn't
>> lie about what it is by using the wrong partition type code.
> 
> Suggests?  Lieing?  To whom?

The kernel for one, 0xfd applies to 0.9 metadata, not 1.x. The detection and 
assembly methods are different. Since metadata 0.9 is deprecated, in effect 
type code 0xfd is deprecated since they go together.

And for two, anything else in the world that understands Linux filesystems but 
not Linux RAID. For example, FUSE supporting ext on OS X or Windows. The 0x83 
type code tells them this is a Linux *filesystem*. Yet it isn't. It's a RAID 
member. If the partition is an mdadm RAID1 member, such software will mount the 
filesystem as if it's a stand alone filesystem, and now the RAID is corrupt. So 
if you care to protect the array it needs to be properly set to 0xfd when mdadm 
0.9 metadata is used, and 0xda when mdadm 1.x metadata is used. Using 0x83 is 
the wrong type code for Linux software RAID.


> Nobody pays attention to the type codes.

Right, there's no outside world at all. You're familiar with the behavior of 
100% of the world's code, open source and proprietary, and you've personally 
determined nobody pays attention to type codes.


> Also if you really want a different type code for raid, there already
> is one: 0xFD.

That contradicts md developers' recommendations.

https://raid.wiki.kernel.org/index.php/Partition_Types
https://raid.wiki.kernel.org/index.php/Autodetect


Chris Murphy