Subject: bug#17994: Linux RAID MBR type code

From: Chris Murphy <[email-masked]>
Date: Mon, 14 Jul 2014 10:26:31 -0600

On Jul 14, 2014, at 8:03 AM, Phillip Susi <[email-masked]> 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