From: Doug Ledford <dledford@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Neil Brown <neilb@suse.de>,
Peter Rabbitson <rabbit+list@rabbit.us>,
linux-raid@vger.kernel.org
Subject: Re: Proper partition type for components with V1.x superblocks?
Date: Thu, 03 Jul 2008 01:17:56 -0400 [thread overview]
Message-ID: <1215062276.14196.6.camel@firewall.xsintricity.com> (raw)
In-Reply-To: <486BFB03.7060100@zytor.com>
[-- 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 --]
next prev parent reply other threads:[~2008-07-03 5:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-11 9:26 Proper partition type for components with V1.x superblocks? Peter Rabbitson
2008-06-11 11:23 ` Andre Noll
2008-06-11 12:12 ` Peter Rabbitson
2008-06-11 21:06 ` Andre Noll
2008-06-11 11:24 ` David Greaves
2008-06-11 11:35 ` Peter Rabbitson
2008-06-11 23:52 ` Neil Brown
2008-07-02 22:02 ` H. Peter Anvin
2008-07-03 5:17 ` Doug Ledford [this message]
2008-07-07 3:17 ` Neil Brown
2008-07-07 14:02 ` Doug Ledford
2008-07-07 17:33 ` H. Peter Anvin
2008-07-07 17:32 ` H. Peter Anvin
2008-07-07 23:10 ` David Greaves
2008-07-07 23:47 ` H. Peter Anvin
2008-07-07 17:38 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1215062276.14196.6.camel@firewall.xsintricity.com \
--to=dledford@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=rabbit+list@rabbit.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).