On Sun, Apr 4, 2010 at 3:47 PM, Kerin Millar <[email protected]> wrote:
> On 04/04/2010 23:16, Mark Knecht wrote:
>>
>> First, thanks for sticking with me on this. I really appreciate it.
>> Second, I apologize for the length of the reply but it's still not
>> working and I wanted to try and clearly show the steps I've taken.
>> Maybe you or someone else will see the step I'm missing.
>
> [snip]
>
>> I don't know what to try next.
>
> OK, I think I now understand what's happening here. I regret that I did not
> recall this earlier but only the original RAID superblock format (version
> 0.90.00) is supported for automatic assembly! I have two servers that are
> set up in a similar way as your box, and they both use this format. It's
> possible that the docs may be out of date but
> /usr/src/linux/Documentation/md.txt says:
>
> "When md is compiled into the kernel (not as module), partitions of type
> 0xfd are scanned and automatically assembled into RAID arrays. This
> autodetection may be suppressed with the kernel parameter
> "raid=noautodetect". As of kernel 2.6.9, only drives with a type 0
> superblock can be autodetected and run at boot time."
>
> Also, look at this:
>
> http://www.mail-archive.com/[email protected]/msg06215.html
>
> To quote Neil Brown:
>
> "v0.90 can be used with 'in kernel autodetect' (i.e. partition type 0xfd).
> v1 cannot (I consider this an improvement :-)"
>
> Well, I can't say I agree with him there.
>
> Anyway, it seems that you're using the 1.1 superblock format. So, what
> options does this leave you with?
>
> a) Backup the root filesystem, and re-create the array with the regular
> superblock format. If necessary, coerce mdadm with -e 0 but it should
> be a default.
>
> b) Rely on userspace tools to assemble the array. This means either
> having the root filesystem off raid, or using an initrd/initramfs
> image.
>
> I'd got for the first option as it keeps things simple and the benefits of
> the v1 format are nebulous in practical terms.
>
> Cheers,
>
> --Kerin
>
>
>
Hi,
From my post this morning:
"No problem supplying it. I did the rebuild this morning but forced
metadata to Type 1.0. No change as you suggested there wouldn't be."
I guess I didn't post it there but what I meant by that was the following:
1) If you don't specify metadata then you get the newest - I think
that's currently ver. 1.2 or something.
2) I tried 1.0 this morning (shown below) which didn't fix it.
(commands used are below)
I will immediately try 0.90 as I have no problem with the limitations
at this time:
0, 0.90
Use the original 0.90 format superblock.
This format limits arrays to 28 component
devices and limits component devices of levels 1
and greater to 2 terabytes.
I should hopefully know in an hour or two how this worked.
Thanks for the help!
Cheers,
Mark
keeper ~ # mdadm --create /dev/md0 --level=1 --raid-devices=2
/dev/sdb3 /dev/sdc3
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/' or '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=1.0
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/' or '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=1.0
Continue creating array? n
mdadm: create aborted.
keeper ~ # mdadm --create /dev/md0 --level=1 --raid-devices=2
--metadata=1.0 /dev/sdb3 /dev/sdc3
mdadm: array /dev/md0 started.
keeper ~ # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdc3[1] sdb3[0]
31463228 blocks super 1.0 [2/2] [UU]
[>....................] resync = 3.9% (1241664/31463228)
finish=5.2min speed=95512K/sec
unused devices: <none>
keeper ~ #
