bug#17994: Linux RAID MBR type code

[Chris Murphy]

On Jul 14, 2014, at 3:02 PM, Phillip Susi <address@hidden> 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