bug#17994: Linux RAID MBR type code

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/14/2014 06:58 PM, Chris Murphy wrote:
> 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.

You have provided only one reason: the mdadm man page says to.  I
don't see anything in the comments of the bug or your responses in
this thread beyond that.

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

I haven't cited anything; only called for an explanation.  The man
page explanation is vague to the point of being meaningless.

> 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.

Only if there is a viable way that not adding it could be harmful,
which so far, you have yet to demonstrate.

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

Where?  The single thing I have seen so far is "recovery from a live
cd may ( how? ) be a problem.

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

Because arguing semantics is a pointless waste of time.  If the name
of the existing type does not quite apply, then clarify the name --
don't create a whole new type code instead.  Especially since the
previous "autodetect" use is deprecated and therefore is ripe for
reuse, especially in a wholly compatible and orthogonal way.

> 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.

It does not behave any differently.  As long as you are using metadata
1.x, you get the same results whether you use 0xFD or 0xDA ( or any
other code ).  The only time you get different results is if you use
metadata 0.9, boot with a kernel that has md built in, the deprecated
auto assemble option enabled, and no initramfs.

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

That would have been nice but unfortunately the ship has already
sailed on that: the Linux community is not going to do this.  For that
matter Microsoft uses a single code for the two filesystems they support.

> 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 argument wasn't about whether Linux will auto assemble, but
whether another OS will auto mount without understanding the mdadm
metadata.  If you need to use a special type code to prevent non linux
OSes from mounting the partition, then that should apply under both
MBR and GPT.

For that matter, the whole reason for using format 1.0 on a mirror (
instead of the default 1.2, or 1.1 ) is so that you can mount the
volume in a non mdadm aware OS for recovery.  If that is what you
desire, why would you defeat it with the type code ( and why yet
another type code instead of the existing 0xFD, which already
accomplishes that? ).

> 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.

I'm open to a hypothetical problem too, provided that it is actually
thought out and described instead of left to vague statements like
"maybe something with a livecd".

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTxJ3nAAoJEI5FoCIzSKrwcOYIAJs1CLCdrR1Bnv19+/QCenEe
SM1qdFoDqCYnEafUn9V4Z2liJbB+OUN6z5rFWBqP/MNILmv/A0cv4HwagKoWPExO
ciU51D1pqQbQH+m6tSmhevAzH3rLpHdQKk6xxt4pPAkHcVCfyyn5Brz55nc0bxIF
2TI6GcqtJ8WMqu5YuHGe6CV0uYCrJFzC0C1YLcm1zWR7THaaVg2AIN20+Qi4z1n3
xDh4Mgfb5k6Yqc2urMiHmaRfw8Af6tJXFQW+JXejTnHixk3+AE/9dTmv2cGpHbmT
2YXIdVr0+RKZJSUg51NlMjC1TAOwgIe0CRPhPQTtwZCMTtCpWcs8PLfrRj1k5FU=
=xtnj
-----END PGP SIGNATURE-----