GNU bug report logs - #17994
Linux RAID MBR type code

Previous Next

To reply to this bug, email your comments to 17994 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Chris Murphy <lists <at> colorremedies.com>
To: bug-parted <at> gnu.org
Subject: Linux RAID MBR type code
Date: Thu, 10 Jul 2014 17:58:26 -0600

This is in master branch.

libparted/labels/dos.c
98	#define PARTITION_LINUX_RAID	0xfd


This type code and metadata version 0.9 are long deprecated. Parted lacks support for the "non-fs data" partition type code 0xda, which is what should be used for mdadm metadata 1.x partitions.

man 8 mdadm:
"When  creating  a partition based array, using mdadm with version-1.x metadata, the partition type should be set to 0xDA (non fs-data).  This type selection allows for greater precision since using any other [RAID auto-detect (0xFD) or a GNU/Linux  partition (0x83)], might create problems in the event of array recovery through a live cdrom."

https://raid.wiki.kernel.org/index.php/Autodetect


Chris Murphy

Message #8 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: Chris Murphy <lists <at> colorremedies.com>, 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Sun, 13 Jul 2014 18:41:53 -0400

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

On 07/10/2014 07:58 PM, Chris Murphy wrote:
> This is in master branch.
> 
> libparted/labels/dos.c 98	#define PARTITION_LINUX_RAID	0xfd
> 
> 
> This type code and metadata version 0.9 are long deprecated.
> Parted lacks support for the "non-fs data" partition type code
> 0xda, which is what should be used for mdadm metadata 1.x
> partitions.
> 
> man 8 mdadm: "When  creating  a partition based array, using mdadm 
> with version-1.x metadata, the partition type should be set to
> 0xDA (non fs-data).  This type selection allows for greater
> precision since using any other [RAID auto-detect (0xFD) or a
> GNU/Linux partition (0x83)], might create problems in the event of
> array recovery through a live cdrom."

Why does it matter?  Linux doesn't pay attention to the partition type
code anyhow.  I've always just used 0x83.

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

iQEcBAEBCgAGBQJTwwsxAAoJEI5FoCIzSKrw+qYIAID8rG0Q7u1fdilQgAtK1n9x
sNuRVDbi1mGQiktMYTUcUUNNtd6sglau4XUpU/LX9jR50fHbbI4CtT/7pTEbptmC
URKWjA77ViChbf/6OJd4wevuQUhFN/WQgQTj2Tgqijr2zI6TKD5JPDyqqxaH/wz1
0A6SIF1j7dWId7Z2obzHU2vNTh/GIin50MOR+49MpBy03GwtYb+BpNXCypz0LEwk
E5QEGd1kW01RPLLF2FE0tuyjiYIqY74g95VWdFxghBGGW1ZuNHjLbq3G9b4ixthq
05Ph+FfwECqvgZr+xA9QtGbHZjEFsyHGLOf9xQH0NkRx+BZUGMQQDCiYAgkEJfU=
=T7uG
-----END PGP SIGNATURE-----

Message #11 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Chris Murphy <lists <at> colorremedies.com>
To: Phillip Susi <psusi <at> ubuntu.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Sun, 13 Jul 2014 19:07:24 -0600

On Jul 13, 2014, at 4:41 PM, Phillip Susi <psusi <at> ubuntu.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 07/10/2014 07:58 PM, Chris Murphy wrote:
>> This is in master branch.
>> 
>> libparted/labels/dos.c 98	#define PARTITION_LINUX_RAID	0xfd
>> 
>> 
>> This type code and metadata version 0.9 are long deprecated.
>> Parted lacks support for the "non-fs data" partition type code
>> 0xda, which is what should be used for mdadm metadata 1.x
>> partitions.
>> 
>> man 8 mdadm: "When  creating  a partition based array, using mdadm 
>> with version-1.x metadata, the partition type should be set to
>> 0xDA (non fs-data).  This type selection allows for greater
>> precision since using any other [RAID auto-detect (0xFD) or a
>> GNU/Linux partition (0x83)], might create problems in the event of
>> array recovery through a live cdrom."
> 
> 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.

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.


Chris Murphy

Message #14 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: Chris Murphy <lists <at> colorremedies.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 10:03:58 -0400

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

> 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?  Nobody pays attention to the type codes.
 Also if you really want a different type code for raid, there already
is one: 0xFD.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTw+NOAAoJEI5FoCIzSKrw6vsH/Rxuwlqtw7Ef7KmBNMqWeZvz
6jGf4hxDUy176O6GRFMDlroJY4Gk5apSZdzyTGcIhprMYVe12DVZA5/rJOz1GmP7
/ArqaJoDtyRXP0/yuDqXxlwHoA0u8HaUGtXv2D1SEqw+dbi3Rb1f+D8E/tZ/TcXG
Y+Tcr9cyl0W2gvS9UrYrIgErscaUhJeGV7r1Njiv6GDmyExDm9zhtlafC+g9Z2ZZ
XK7MV3y2mReSiZOnZejZ+3ZT0Doiv2tPDlGkG73L+rZ4fJdN1/FS4L22UDEIhZtS
d36qKBPDWAuij9LR5Yz+1oK0c9f34cWn2mo8rDDZyU7USdiEA2eorevHwCaFHaI=
=gn+C
-----END PGP SIGNATURE-----

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Brian C. Lane" <bcl <at> redhat.com>
To: bug-parted <at> gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 08:40:43 -0700

On Mon, Jul 14, 2014 at 10:03:58AM -0400, Phillip Susi wrote:
> 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.
> 
> > 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?  Nobody pays attention to the type codes.
>  Also if you really want a different type code for raid, there already
> is one: 0xFD.

It ends up that 0xFD is only supposed to be used for mdraid 0.9
metadata. For 1.0 and later they want 0xDA so that it isn't auto
assembled and gets ignored by everything else.

I've been meaning to write a patch to allow setting arbitrary values for
partition id / guid since it is a bit of a pain to add new flags every
time someone comes up with something new.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

Message #20 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: "Brian C. Lane" <bcl <at> redhat.com>, 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 12:01:45 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/2014 11:40 AM, Brian C. Lane wrote:
> It ends up that 0xFD is only supposed to be used for mdraid 0.9 
> metadata. For 1.0 and later they want 0xDA so that it isn't auto 
> assembled and gets ignored by everything else.

Says who?  1.x won't be auto assembled no matter what the type code
says.  Why introduce this 0xDA instead of keeping the existing code?
Also what about gpt?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTw/7pAAoJEI5FoCIzSKrwAJoH/jKMgdhKKziwCpg1az2z5gnb
pnQwkgOKlCpHtpvj0K4qqaZPiR2SVmEOp8eX2ljVkQVLv/0T3fVR8JmzdakIGCnD
eTGt5JGc8skQs4sfxtyCa+VXy26dKT1vySbrDIHq3Ocu74uzcLrxv30lR5FyuX0V
5WXOgjhElxWQ1Fb9lT7PiNr98s+3M+63U3OvFKqlcM1TOiP5t/g3sO5JhR4b/avX
++xOBVHqbHQAd0wwX4G6ecv4PlS2L/3bXkzQfKba7R4thXy2VtIpkGqcXf2WlyRw
e+/RC0g5NFyYgWqmkjJ7P0/6pdL99ilRRVtJNRILFcltL9b4RlcenoZcUsDQ0cE=
=SlVM
-----END PGP SIGNATURE-----

Message #23 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Chris Murphy <lists <at> colorremedies.com>
To: Phillip Susi <psusi <at> ubuntu.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 10:26:31 -0600

On Jul 14, 2014, at 8:03 AM, Phillip Susi <psusi <at> ubuntu.com> 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

Message #26 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: Chris Murphy <lists <at> colorremedies.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 14:08:57 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/2014 12:26 PM, Chris Murphy wrote:
>> 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.

That is why we fixed that mistake, and it still has absolutely nothing
to do with this issue since Windows does not try to use 0x83 *or* 0xFD.

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

The kernel only uses 0xfd as a hint that it should look for 0.9
metadata, and only if the md driver is build in ( not a module ) and
has CONFIG_MD_AUTODETECT set.  It reads no meaning into it beyond
that.  Using 0xfd for 1.x metadata has no ill effects, and since it is
the original type code for linux raid, there does not appear to be any
reason to add yet another one.

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

I've never tried the ext2 driver on Windows or used OSX.  I thought
they required an explicit mount command.  Are you sure that these two
OSes will automatically ( i.e. without being explicitly given a mount
command ) try to mount an md 1.x partition that has a type code of
0x83?  Even if it does, they certainly already must leave 0xFD alone,
so stick with that.

> That contradicts md developers' recommendations.
> 
> https://raid.wiki.kernel.org/index.php/Partition_Types 
> https://raid.wiki.kernel.org/index.php/Autodetect

That page starts off by saying "There is no right answer - you can
choose. "

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxBy5AAoJEI5FoCIzSKrw1h4IAJZaNQMT+k7YzLSabREaFOlf
AgJuwIj24BoN2by5Ao+9LAnV9Dh/qNJd4eDLurJqfGkLIgEejPTdBuhhFEpveWmX
jhorxKNks72Z1N3Slk5WT4avg0vUV1EvwCGdc4MHu9+2GSqhHPrySOjWN6iAakpA
92SRjFDtTOa81Dml9iG7UFV4n7C72XcCyr9Lnu70sm775bo6KhE7+HBFC7LVpPVc
rSxV8a7d7JFdf7aU75TjP8IeywUProPHLn1mka4dGdFVFJhYyH7JLVM2Kh0Ox56t
jYX/94YziGWlZEHV34TGkPp5l45xwvlpfOF/MWra93DoRP5MDUqU4fyscTDx8vo=
=br7j
-----END PGP SIGNATURE-----

Message #29 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Chris Murphy <lists <at> colorremedies.com>
To: Phillip Susi <psusi <at> ubuntu.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 12:33:43 -0600

On Jul 14, 2014, at 12:08 PM, Phillip Susi <psusi <at> ubuntu.com> wrote:
> 
> I've never tried the ext2 driver on Windows or used OSX.  I thought
> they required an explicit mount command.  Are you sure that these two
> OSes will automatically ( i.e. without being explicitly given a mount
> command ) try to mount an md 1.x partition that has a type code of
> 0x83?

I haven't test it, but as Apple long ago deprecated fstab in favor of automounting anything it recognizes, I'd expect it would automount this configuration. But what does happen isn't as important as what legitimately can happen now or in the future which is automounting because this is invited due to the use of the wrong type code.

>  Even if it does, they certainly already must leave 0xFD alone,
> so stick with that.
> 
>> That contradicts md developers' recommendations.
>> 
>> https://raid.wiki.kernel.org/index.php/Partition_Types 
>> https://raid.wiki.kernel.org/index.php/Autodetect
> 
> That page starts off by saying "There is no right answer - you can
> choose. "

That is a completely disingenuous reading. If you take the entire page as a whole, it's saying you can choose 0xfd with 0.9 metadata, or you can choose 0xda with 1.x metadata. It is not suggesting use of 0xfd with 1.x metadata.

And this has sufficiently explained the conflict with using either 0xfd or 0x83, even on Linux.


Chris Murphy

Message #32 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: Chris Murphy <lists <at> colorremedies.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 14:55:16 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/2014 2:33 PM, Chris Murphy wrote:
> I haven't test it, but as Apple long ago deprecated fstab in favor
> of automounting anything it recognizes, I'd expect it would
> automount this configuration. But what does happen isn't as
> important as what legitimately can happen now or in the future
> which is automounting because this is invited due to the use of the
> wrong type code.

What can legitimately happen now or in the future is anything and
everything since partition type codes are not standardized.  The
question is, does apple actually look at the type code, or do they
work like Linux does and probe the actual contents?  Since the windows
ext2 driver was written by the Linux community, I would at least
expect it to work like Linux does, and not give a hoot about the
partition type code.  In any case, if they already deal with 0xfd
correctly, why change?

> That is a completely disingenuous reading. If you take the entire 
> page as a whole, it's saying you can choose 0xfd with 0.9
> metadata, or you can choose 0xda with 1.x metadata. It is not
> suggesting use of 0xfd with 1.x metadata.

It is pretty clear to me that it is simply a suggestion and they make
it clear that it really doesn't matter.  Since it doesn't really
matter, and there appears to be no reason to add a new code instead of
sticking with 0xfd, I'm disinclined to needlessly complicate the
partitioning process any further for no gain.

> And this has sufficiently explained the conflict with using either 
> 0xfd or 0x83, even on Linux.

What conflict?  The only conflict I am aware of is user confusion over
which one to use, which will only be made worse by adding yet another
code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxCeUAAoJEI5FoCIzSKrwa0gIAKb8dZAM0it66Qt93bvRFxqW
hwCmXODFdysma1KfRPf2R2H9BCznllXhJa9MaVuTqaAH/9jzg46c8ZJeVktc5ULB
pn71qsVTbZq7FV6H1KLrt/01vAV/4Um9P23g6UH0tbZ/TS+leKe6SC1air8kb1pK
NakVg06iOWkgbJU7E0eZyjoz5dWmJ6gMBFrtE/BsagKFvkQIn/z39U9EY5DytNvf
woU18fuGeM6tWV7vnk/ug1bIBs1/zlhH/1e9CVTdcxXDvI/kOLcsRkHlMl+bNbhP
6ka6X6RusQaVNz5mX3exLl+aqVa2Y99WsiIKV4opIshxEdY1QmNuNbhLQcLHd9c=
=JB8g
-----END PGP SIGNATURE-----

Message #35 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Chris Murphy <lists <at> colorremedies.com>
To: Phillip Susi <psusi <at> ubuntu.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 14:03:04 -0600

On Jul 14, 2014, at 12:55 PM, Phillip Susi <psusi <at> ubuntu.com> wrote:
> 
> What can legitimately happen now or in the future is anything and
> everything since partition type codes are not standardized.  The
> question is, does apple actually look at the type code, or do they
> work like Linux does and probe the actual contents?

They look at the type code first. If it's a type code they support, but the partition isn't something they expect, they actively suggest the user initialize the partition. It's similar for Windows.




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



>> That is a completely disingenuous reading. If you take the entire 
>> page as a whole, it's saying you can choose 0xfd with 0.9
>> metadata, or you can choose 0xda with 1.x metadata. It is not
>> suggesting use of 0xfd with 1.x metadata.
> 
> It is pretty clear to me that it is simply a suggestion and they make
> it clear that it really doesn't matter.

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.


>  Since it doesn't really
> matter, and there appears to be no reason to add a new code instead of
> sticking with 0xfd, I'm disinclined to needlessly complicate the
> partitioning process any further for no gain.

Right, let's wait for problems to happen rather than avoid them in the first place.


> 
>> And this has sufficiently explained the conflict with using either 
>> 0xfd or 0x83, even on Linux.
> 
> What conflict?  The only conflict I am aware of is user confusion over
> which one to use, which will only be made worse by adding yet another
> code.

All the official documentation on mdadm explicitly recommends metadata v1.2 and type code 0xda. There is no confusion on this point. Saying there is doesn't make it true.

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.


Chris Murphy

Message #38 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: Chris Murphy <lists <at> colorremedies.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 17:02:44 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/2014 4:03 PM, Chris Murphy wrote:
> They look at the type code first. If it's a type code they support,
> but the partition isn't something they expect, they actively
> suggest the user initialize the partition. It's similar for
> Windows.

Right, so they look for their own type code and ignore everything else,
including 0x83 and 0xfd.

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

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

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

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.

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

Are we also supposed to allocate a new GUID for GPT partitions?  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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTxEV0AAoJEI5FoCIzSKrw/QYH/2kXm3BOmoI85jvfBzGGankR
RDmcEtfQ/NX6wOR6vnUJS5gbLam5IuO6bSwVI9kn8PmYKI9RtKAaqwd0AAClp4oC
KxnRyJAVjnsdjSEIckeAcbGuJzwJAsKHso0ucMznXcqfmLZxdeNLeJg+yF3MBd9T
GVcnuE4PJ4t5my1QkUsHQ4wR5tO0kOrKLygTHq/2zlI/n2dl6hMrwtsG3AkkwdXG
Tcnc1/v9aFUZIir86jPV8GK1eGKdDjq1u749/2/6NE0q+z8JHAF6K0Pv97+d4wbO
iGIuEKpITKyNMq0ncetWTq8gUBZ0H26kwFXyL/NzXr3iZW/l5cT5N+Bhs17Xj6I=
=KE9o
-----END PGP SIGNATURE-----

Message #41 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Chris Murphy <lists <at> colorremedies.com>
To: Phillip Susi <psusi <at> ubuntu.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: bug#17994: Linux RAID MBR type code
Date: Mon, 14 Jul 2014 16:58:15 -0600

On Jul 14, 2014, at 3:02 PM, Phillip Susi <psusi <at> ubuntu.com> 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

Message #44 received at 17994 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: Chris Murphy <lists <at> colorremedies.com>
Cc: 17994 <at> debbugs.gnu.org
Subject: Re: 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-----

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.