From: Doug Ledford <dledford@redhat.com>
To: linux-raid@vger.kernel.org
Subject: Re: raid array with 3T disks and GPT partition
Date: Thu, 01 Sep 2011 16:10:13 -0400 [thread overview]
Message-ID: <4E5FE6A5.3060301@redhat.com> (raw)
In-Reply-To: <20110901192035.GA25941@apartia.fr>
On 09/01/2011 03:20 PM, Louis-David Mitterrand wrote:
> On Thu, Sep 01, 2011 at 12:55:08PM -0400, Doug Ledford wrote:
>> On 09/01/2011 12:33 PM, Louis-David Mitterrand wrote:
>>> On Thu, Sep 01, 2011 at 04:59:13PM +0100, Robin Hill wrote:
>>>> On Thu Sep 01, 2011 at 05:47:59PM +0200, Louis-David Mitterrand wrote:
>>>>>
>>>>> I'm trying to create a raid6 array from 10x3T disks. Since disks> 2T
>>>>> must use the GPT partion table I used parted to created a single
>>>>> partition on each drive with the correct GPT partion type.
>>>>>
>>>>> Now how do I make sure that these partitions have the correct "raid
>>>>> autodetect" (fd) id? Is it even still needed? I didn't find any way to
>>>>> set that flag in (g)parted.
>>>>>
>>>> It's only needed for kernel auto-assembly (in which case you're also
>>>> limited to 0.90 metadata and 2TB drives), so no, there's no need to use
>>>> that. 0xDA seems to be the recommended partition type for RAID arrays
>>>> nowadays - that should prevent the OS from trying to read them directly.
>>>
>>> Auto-assembly and metadata are not related: I regularly use 1.2 metadata
>>> on non-boot partitions and they auto-assemble fine.
>>
>> They most certainly are related. There is kernel autoassembly, then
>> there is user space assembly that's done by udev. They are two
>> different things. The kernel will only autoassemble version 0.9
>> arrays, any other arrays are assembled by user space either in the
>> initramfs or later on in the boot cycle. That you don't have to
>> manually run mdadm -As doesn't mean that the kernel autoassembly is
>> working on those arrays.
>
> Ah, thanks for clearing that up. I thought that when mdadm was not
> involved then is must be the kernel. Didn't realize udev was at work
> there.
Well, udev calls mdadm. If the kernel doesn't autoassemble it, then
mdadm is involved at some point. On older systems, rc.sysinit called
mdadm to assemble non-boot arrays, on modern systems, udev calls mdadm.
next prev parent reply other threads:[~2011-09-01 20:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-01 15:47 raid array with 3T disks and GPT partition Louis-David Mitterrand
2011-09-01 15:53 ` Pim Zandbergen
2011-09-01 15:57 ` Louis-David Mitterrand
2011-09-01 16:01 ` Pim Zandbergen
2011-09-01 15:59 ` Robin Hill
2011-09-01 16:33 ` Louis-David Mitterrand
2011-09-01 16:55 ` Doug Ledford
2011-09-01 19:13 ` Rudy Zijlstra
2011-09-11 16:59 ` Bill Davidsen
2011-09-01 19:20 ` Louis-David Mitterrand
2011-09-01 20:10 ` Doug Ledford [this message]
2012-01-10 19:40 ` Phillip Susi
2012-01-25 11:15 ` Peter Grandi
2011-09-01 16:56 ` John Robinson
2011-09-01 16:58 ` Robin Hill
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=4E5FE6A5.3060301@redhat.com \
--to=dledford@redhat.com \
--cc=linux-raid@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.