Proper partition type for components with V1.x superblocks?

Proper partition type for components with V1.x superblocks?

[Peter Rabbitson]

Hello,

The subject pretty much says it all - it obviously is not 0xFD, since there is 
nothing to autodetect. Is there some best practice/semi-standard way of 
marking a raid component partition as such? After reading the specs 0xDA 
(non-fs data) comes to mind, but I figured I'll ask here.

Thanks

Peter

Re: Proper partition type for components with V1.x superblocks?

[Andre Noll]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On 11:26, Peter Rabbitson wrote:

> The subject pretty much says it all - it obviously is not 0xFD, since there 
> is nothing to autodetect. Is there some best practice/semi-standard way of 
> marking a raid component partition as such?

Nobody really cares about the partition type these days. I usually
stick to the default 83 (Linux) for software raid partitions and
never encountered any problems.

Andre
-- 
The only person who always got his work done by Friday was Robinson Crusoe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Proper partition type for components with V1.x superblocks?

[David Greaves]

Peter Rabbitson wrote:
> Hello,
> 
> The subject pretty much says it all - it obviously is not 0xFD, since
> there is nothing to autodetect. Is there some best
> practice/semi-standard way of marking a raid component partition as
> such? After reading the specs 0xDA (non-fs data) comes to mind, but I
> figured I'll ask here.

I recently wondered if there should be a new partition type.

Partitioning tools look for (and sometimes find!) filesystems on 0x83 partitions
so 0x83 is out (anyone splitting a mirror should be happy changing the type back)

I'd rather that rescue disk didn't think 'oh, I'll use that swap partition', so
0x82 is out.

I don't want md trying to autodetect and complaining so, as you say, 0xfd is out.

I think it would be nice to mark them as 0xFC

David

Re: Proper partition type for components with V1.x superblocks?

[Peter Rabbitson]

David Greaves wrote:
> Peter Rabbitson wrote:
>> Hello,
>>
>> The subject pretty much says it all - it obviously is not 0xFD, since
>> there is nothing to autodetect. Is there some best
>> practice/semi-standard way of marking a raid component partition as
>> such? After reading the specs 0xDA (non-fs data) comes to mind, but I
>> figured I'll ask here.
> 
> I recently wondered if there should be a new partition type.
> 
> Partitioning tools look for (and sometimes find!) filesystems on 0x83 partitions
> so 0x83 is out (anyone splitting a mirror should be happy changing the type back)
> 
> I'd rather that rescue disk didn't think 'oh, I'll use that swap partition', so
> 0x82 is out.
> 
> I don't want md trying to autodetect and complaining so, as you say, 0xfd is out.
> 
> I think it would be nice to mark them as 0xFC

Nope. As per [1] (which is linked in [2]): fc VMware Swap partition

What is the process for partition type registration anyway? How did 0xFD come 
around?

Peter

[1] http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[2] http://en.wikipedia.org/wiki/Partition_(computing)

Re: Proper partition type for components with V1.x superblocks?

[Peter Rabbitson]

Andre Noll wrote:
> On 11:26, Peter Rabbitson wrote:
> 
>> The subject pretty much says it all - it obviously is not 0xFD, since there 
>> is nothing to autodetect. Is there some best practice/semi-standard way of 
>> marking a raid component partition as such?
> 
> Nobody really cares about the partition type these days. I usually
> stick to the default 83 (Linux) for software raid partitions and
> never encountered any problems.

This is a very flawed assumption. You will be surprised how many 
utilities/live CDs are there in existence, which will selently attempt to 
mount/fsck a partition based solely on its type. The implications of a 
commenced mount/fsck on a raid component are not to be uttered here :)

Re: Proper partition type for components with V1.x superblocks?

[Andre Noll]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On 14:12, Peter Rabbitson wrote:
> >Nobody really cares about the partition type these days. I usually
> >stick to the default 83 (Linux) for software raid partitions and
> >never encountered any problems.
> 
> This is a very flawed assumption. You will be surprised how many 
> utilities/live CDs are there in existence, which will selently attempt to 
> mount/fsck a partition based solely on its type.

Well, I'd consider those utilities broken by design. If it is the
exercise is to break as few utilities/live CDs as possible, I admit
you'll have to care about partition types. It's a rather pointless
exercise IMHO though.

Andre
-- 
The only person who always got his work done by Friday was Robinson Crusoe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Proper partition type for components with V1.x superblocks?

[Neil Brown]

On Wednesday June 11, rabbit+list@rabbit.us wrote:
> Hello,
> 
> The subject pretty much says it all - it obviously is not 0xFD, since there is 
> nothing to autodetect. Is there some best practice/semi-standard way of 
> marking a raid component partition as such? After reading the specs 0xDA 
> (non-fs data) comes to mind, but I figured I'll ask here.
> 

I (almost) alway make arrays out of whole devices, not partitions, so
I really never thought about this.

I suspect 0xDA is safest and hence best.
I wonder if this should be suggested in the mdadm man page
anywhere.... anyone feel like creating a patch?

NeilBrown

Re: Proper partition type for components with V1.x superblocks?

[H. Peter Anvin]

Neil Brown wrote:
> On Wednesday June 11, rabbit+list@rabbit.us wrote:
>> Hello,
>>
>> The subject pretty much says it all - it obviously is not 0xFD, since there is 
>> nothing to autodetect. Is there some best practice/semi-standard way of 
>> marking a raid component partition as such? After reading the specs 0xDA 
>> (non-fs data) comes to mind, but I figured I'll ask here.
>>
> 
> I (almost) alway make arrays out of whole devices, not partitions, so
> I really never thought about this.
> 
> I suspect 0xDA is safest and hence best.
> I wonder if this should be suggested in the mdadm man page
> anywhere.... anyone feel like creating a patch?
> 

Why 0xDA?

As far as I know, the closest thing there is to a registry is the list 
that aeb at least used to maintain.

	-hpa

Re: Proper partition type for components with V1.x superblocks?

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

On Wed, 2008-07-02 at 15:02 -0700, H. Peter Anvin wrote:
> Neil Brown wrote:
> > On Wednesday June 11, rabbit+list@rabbit.us wrote:
> >> Hello,
> >>
> >> The subject pretty much says it all - it obviously is not 0xFD, since there is 
> >> nothing to autodetect. Is there some best practice/semi-standard way of 
> >> marking a raid component partition as such? After reading the specs 0xDA 
> >> (non-fs data) comes to mind, but I figured I'll ask here.
> >>
> > 
> > I (almost) alway make arrays out of whole devices, not partitions, so
> > I really never thought about this.
> > 
> > I suspect 0xDA is safest and hence best.
> > I wonder if this should be suggested in the mdadm man page
> > anywhere.... anyone feel like creating a patch?
> > 
> 
> Why 0xDA?
> 
> As far as I know, the closest thing there is to a registry is the list 
> that aeb at least used to maintain.

Actually, if you are going to use version 1 superblocks anyway, then
just list the partitions as normal linux partitions.  The whole
linux-raid-autodetect partition type was originally only for auto detect
at bootup.  If you weren't using that feature, then standard linux type
was good enough.  And if you use version 1.1 or 1.2 superblocks, then
you really don't have anything to worry about since the location of the
superblock and the data start offset means that the partition won't get
accidentally recognized as a non-raid partition.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Proper partition type for components with V1.x superblocks?

[Neil Brown]

On Thursday July 3, dledford@redhat.com wrote:
> On Wed, 2008-07-02 at 15:02 -0700, H. Peter Anvin wrote:
> > 
> > Why 0xDA?
> > 
> > As far as I know, the closest thing there is to a registry is the list 
> > that aeb at least used to maintain.

Yes. 
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
lists 0xDA as

    da Non-FS Data

        Added on request of John Hardin (johnh@aproposretail.com).

which is the closest we could come to "you won't want to look at
or do anything to this partition".

> 
> Actually, if you are going to use version 1 superblocks anyway, then
> just list the partitions as normal linux partitions.  The whole
> linux-raid-autodetect partition type was originally only for auto detect
> at bootup.  If you weren't using that feature, then standard linux type
> was good enough.  And if you use version 1.1 or 1.2 superblocks, then
> you really don't have anything to worry about since the location of the
> superblock and the data start offset means that the partition won't get
> accidentally recognized as a non-raid partition.

But if you use 1.0, then some well-meaning install program might mount
one drive from a raid1 as a filesystem, write to it, and get your RAID
all out of sync.

The whole point of this exercise was to find a way to make sure code
that took the partition type to mean something didn't make the wrong
decision.  0xDA seems the best answer for that.

NeilBrown
 

Re: Proper partition type for components with V1.x superblocks?

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

On Mon, 2008-07-07 at 13:17 +1000, Neil Brown wrote:
> On Thursday July 3, dledford@redhat.com wrote:
> > Actually, if you are going to use version 1 superblocks anyway, then
> > just list the partitions as normal linux partitions.  The whole
> > linux-raid-autodetect partition type was originally only for auto detect
> > at bootup.  If you weren't using that feature, then standard linux type
> > was good enough.  And if you use version 1.1 or 1.2 superblocks, then
> > you really don't have anything to worry about since the location of the
> > superblock and the data start offset means that the partition won't get
> > accidentally recognized as a non-raid partition.
> 
> But if you use 1.0, then some well-meaning install program might mount
> one drive from a raid1 as a filesystem, write to it, and get your RAID
> all out of sync.

The same is true of version 0.90.0 superblocks.  It was probably a bad
decision to make raid1 arrays mountable as normal filesystems in
hindsight, but it did ease a lot of things at the time (like booting
from a raid1 device using lilo, the only boot loader back in the day).
In any case, given the number of existing 0.90.0 and 1.0 superblock
systems out there, any install code that doesn't look for them is just
flat deficient.  So I can see your point from the stand point of wanting
to correct a past mistake, but the flip side of the coin is that even if
you do such a thing, any installer will still be buggy and broken for
many years to come if it doesn't check for raid superblocks before
treating a filesystem like a normal filesystem.

> The whole point of this exercise was to find a way to make sure code
> that took the partition type to mean something didn't make the wrong
> decision.  0xDA seems the best answer for that.
> 
> NeilBrown
>  
-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Proper partition type for components with V1.x superblocks?

[H. Peter Anvin]

Neil Brown wrote:
> On Thursday July 3, dledford@redhat.com wrote:
>> On Wed, 2008-07-02 at 15:02 -0700, H. Peter Anvin wrote:
>>> Why 0xDA?
>>>
>>> As far as I know, the closest thing there is to a registry is the list 
>>> that aeb at least used to maintain.
> 
> Yes. 
> http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
> lists 0xDA as
> 
>     da Non-FS Data
> 
>         Added on request of John Hardin (johnh@aproposretail.com).
> 
> which is the closest we could come to "you won't want to look at
> or do anything to this partition".
> 

But that's not really what it is, either.  The best would be to pick a 
new partition identifier entirely.

	-hpa

Re: Proper partition type for components with V1.x superblocks?

[H. Peter Anvin]

Doug Ledford wrote:
> 
> The same is true of version 0.90.0 superblocks.  It was probably a bad
> decision to make raid1 arrays mountable as normal filesystems in
> hindsight, but it did ease a lot of things at the time (like booting
> from a raid1 device using lilo, the only boot loader back in the day).
> In any case, given the number of existing 0.90.0 and 1.0 superblock
> systems out there, any install code that doesn't look for them is just
> flat deficient.  So I can see your point from the stand point of wanting
> to correct a past mistake, but the flip side of the coin is that even if
> you do such a thing, any installer will still be buggy and broken for
> many years to come if it doesn't check for raid superblocks before
> treating a filesystem like a normal filesystem.
> 

It certainly helps bootloaders wanting to boot off RAID-1.  1.2 
superblocks, at the beginning but with an offset, are fine for that 
purpose too, but requires special handling.

	-hpa

Re: Proper partition type for components with V1.x superblocks?

[H. Peter Anvin]

Neil Brown wrote:
> 
> But if you use 1.0, then some well-meaning install program might mount
> one drive from a raid1 as a filesystem, write to it, and get your RAID
> all out of sync.
> 

One more thing on this: this is actually fine as long as the RAID code 
detects the out-of-syncness.  This can't be foolproof, of course, but 
for virtually all filesystems there is *something* in the first megabyte 
or so (usually within the first 128K) that is touched by almost every 
write -- the superblock, or its equivalent.

If the RAID code did a sanity check on the first megabyte, it would 
catch the vast majority of all unintentional desynchronization events.

	-hpa

Re: Proper partition type for components with V1.x superblocks?

[David Greaves]

H. Peter Anvin wrote:
> Neil Brown wrote:
>> On Thursday July 3, dledford@redhat.com wrote:
>>> On Wed, 2008-07-02 at 15:02 -0700, H. Peter Anvin wrote:
>>>> Why 0xDA?
>>>>
>>>> As far as I know, the closest thing there is to a registry is the
>>>> list that aeb at least used to maintain.
>>
>> Yes. http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
>> lists 0xDA as
>>
>>     da Non-FS Data
>>
>>         Added on request of John Hardin (johnh@aproposretail.com).
>>
>> which is the closest we could come to "you won't want to look at
>> or do anything to this partition".
>>
> 
> But that's not really what it is, either.  The best would be to pick a
> new partition identifier entirely.

I thought that.
But then I asked why?

Couldn't come up with a decent reason.

non-fs seems to cover everything.

David

Re: Proper partition type for components with V1.x superblocks?

[H. Peter Anvin]

David Greaves wrote:
> 
> I thought that.
> But then I asked why?
> 
> Couldn't come up with a decent reason.
> 
> non-fs seems to cover everything.
> 

Seems nicer to install software.

	-hpa