Subject: Re: bug#17994: Linux RAID MBR type code

From: Chris Murphy <[email-masked]>
Date: Mon, 14 Jul 2014 16:58:15 -0600

On Jul 14, 2014, at 3:02 PM, Phillip Susi <[email-masked]> wrote:

>>> In any case, if they already deal with 0xfd correctly, why 
>>> change?
>> 
>> This is made clear in the mdadm page page, as well as the 
>> previously cited bug comment by Doug Ledford who is an md raid 
>> kernel developer.
> 
> No, it isn't... the only thing it says about it is that it "might create
> problems in the event of array recovery through a live cdrom" which is
> hand waving.

This is just changing the goal posts. You asked why change, I provided several reasons, you come back with "hand waving" for only one of those reasons, and ignore the three comments in the bug report. The type code exists whether parted supports it or not, it's what the md kernel developers decided on. And fdisk supports it.

> 
>> man 8 mdadm "the partition type should be set to 0xDA"
>> 
>> Oxford American English: should |SHo͝od| modalverb ( 3rd sing. 
>> should ) 1 used to indicate obligation, duty, or correctness,
>> 
>> The man page goes on to explain the problem with using 0xfd or 0x83
>> for 1.x metadata arrays.
> 
> Previously you referred to the wiki page which made it clear that it
> doesn't matter.  Now you point to the man page, which yes, does say to
> use 0xda, but fails to explain why beyond hand waving.

No you've only dismissed their explanations by citing opinion, i.e. actual hand waving without explanation. There's a difference.

> 
>> Right, let's wait for problems to happen rather than avoid them in
>> the first place.
> 
> Right, let's needlessly complicate users lives' over hypothetical
> hand waving.

And appealing to users is rather ridiculous, because if you cared about users even remotely experiencing data loss/corruption, which is the proposed concern, you'd have have done an "oops yeah we should add this" rather than protect a piece of petrified dog crap.

> 
> 0xfd already tells all who care to keep their mitts off unless they
> understand mdadm.  I have yet to see any concrete reason, even a
> hypothetical one, for adding a new type to differentiate between 0.9 and
> 1.x.

Considering several have been hypothesized, you've labeled them hand waving, and now they're dismissed entirely is… more weird than amusing.

> 
>> 0xfd is defined as "Linux raid autodetect" which is what parted 
>> also calls it. But mdadm metadata 1.x is not autodetect. And
>> you're saying calling it the wrong thing is nevertheless still OK
>> because it doesn't matter. It's fingers in the ears lalala logic.
> 
> So remove the word "autodetect" if you don't like it.  What difference
> does it make?

Because words should have meaning. What's the point of labeling things incorrectly when it's not difficult to name them correctly?

>  Most people see the word raid and figure that's what
> they should use.  "But it isn't really autodetect!" or other semantic
> arguments is not a good reason to add yet another code.

That's exactly backwards for two reasons: forcing usage of inapplicable semantics is wrong because it causes confusion; and the other is that it's not only a semantic difference but the Linux kernel in fact behaves differently based on the two partition types.

> Are we also supposed to allocate a new GUID for GPT partitions?

To comply with the UEFI spec, yes. Technically every filesystem must have its own partitiontype GUID. 

But seeing as the kernel apparently doesn't look for the Linux RAID partitiontype GUID, RAID autodetect (version 0.9 mdadm metadata) is not supported on GPT disks, and in any case is considered deprecated so the lack of a GPT equivalent for 0xfd seems inconsequential.

>  The
> man page is mum on that subject.  That, combined with the hand waving
> explanation given, indicates that this was not well thought out when
> it was added to the man page.

Right, the kernel developers attempting to avoid, as much as practical, the possibility of confusion down the road were thoughtless; rather than the person who's arguing in favor of not thinking or doing anything about it until there's an actual manifested problem. 

Chris Murphy