[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18019: bug-parted Digest, Vol 140, Issue 9

From: Rod Smith
Subject: bug#18019: bug-parted Digest, Vol 140, Issue 9
Date: Mon, 14 Jul 2014 13:11:26 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/14/2014 12:01 PM, Phillip Susi <address@hidden> wrote:

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 with the default set of drivers. What if somebody loads a Linux filesystem driver, though? I don't happen to know what actually happens in this case, but that's (partly) the point: When you set inaccurate data, you can't predict what will happen with some random tool with which you're unfamiliar.

Suggests?  Lieing?  To whom?  Nobody pays attention to the type codes.

The Linux kernel doesn't, but there are at least two other cases to consider:

* Non-kernel tools might care about the type code. In fact, Chris quoted
  the mdadm man page earlier in this thread, and it explicitly states
  that it DOES care about the type code!
* Other OSes do check the type code, and if some non-Linux driver or
  utility behaves in a particular way based on the type code, setting
  something inappropriate invites problems that we can't predict.

  Also if you really want a different type code for raid, there already
is one: 0xFD.

That's not what the modern version of mdadm wants, though.

In an ideal world, of course, the mdadm developers wouldn't have changed their tools' expectations from 0.9 to 1.0; but they did, and that means that the tools that actually set the partition type codes must adapt.

All that said, there is a further complication, and this one isn't parted's fault: The 0xDA type code that's suggested by the mdadm man page is NOT specific to Linux RAID. According to http://www.win.tue.nl/~aeb/partitions/partition_types-1.html, it refers to "non-FS data"; and according to https://en.wikipedia.org/wiki/Partition_type, it can be that or a Powercopy backup. There may be other specific tools that use it, too. Thus, I'd be a little wary of just switching 0xFD to 0xDA as the MBR RAID flag in parted. IMHO, what's needed is some coordination between mdadm, parted, fdisk, and gdisk authors to settle on a standard for this.

Rod Smith

reply via email to

[Prev in Thread] Current Thread [Next in Thread]