Package: parted;
Reported by: Chris Murphy <lists <at> colorremedies.com>
Date: Fri, 11 Jul 2014 00:43:02 UTC
Severity: normal
View this message in rfc822 format
From: Phillip Susi <psusi <at> ubuntu.com> To: Chris Murphy <lists <at> colorremedies.com> Cc: 17994 <at> debbugs.gnu.org Subject: bug#17994: Linux RAID MBR type code Date: Mon, 14 Jul 2014 23:20:07 -0400
-----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-----
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.