Re: In this partition scheme, grub does not find md information?

[Moshe Yudkowsky <moshe@pobox.com>]

I'd like to thank everyone who wrote in with comments and explanations. 
And in particular it's nice to see that I'm not the only one who's confused.

I'm going to convert back to the RAID 1 setup I had before for /boot, 2 
hot and 2 spare across four drives. No, that's wrong: 4 hot makes the 
most sense.

And given that RAID 10 doesn't seem to confer (for me, as far as I can 
tell) advantages in speed or reliability -- or the ability to mount just 
one surviving disk of a mirrored pair -- over RAID 5, I think I'll 
convert back to RAID 5, put in a hot spare, and do regular backups (as 
always). Oh, and use reiserfs with data=journal.

Comments back:

Peter Rabbitson wrote:

> Maybe you are, depending on your settings, but this is beyond the point. 
> No matter what 1+0 you have (linux, classic, or otherwise) you can not 
> boot from it, as there is no way to see the underlying filesystem 
> without the RAID layer.

Sir, thank you for this unequivocal comment. This comment clears up all 
my confusion. I had a wrong mental model of how file system maps work.

> With the current state of affairs (available mainstream bootloaders) the 
> rule is:
> Block devices containing the kernel/initrd image _must_ be either:
>     * a regular block device (/sda1, /hda, /fd0, etc.)
>     * or a linux RAID 1 with the superblock at the end of the device 
> (0.9 or 1.2)

Thaks even more: 1.2 it is.

> This is how you find the actual raid version:
> 
> mdadm -D /dev/md[X] | grep Version
> 
> This will return a string of the form XX.YY.ZZ. Your superblock version 
> is XX.YY.

Ah hah!

Mr. Tokarev wrote:

> By the way, on all our systems I use small (256Mb for small-software systems,
> sometimes 512M, but 1G should be sufficient) partition for a root filesystem
> (/etc, /bin, /sbin, /lib, and /boot), and put it on a raid1 on all...
> ... doing [it]
> this way, you always have all the tools necessary to repair a damaged system
> even in case your raid didn't start, or you forgot where your root disk is
> etc etc.

An excellent idea. I was going to put just /boot on the RAID 1, but 
there's no reason why I can't add a bit more room and put them all 
there. (Because I was having so much fun on the install, I'm using 4GB 
that I was going to use for swap space to mount base install and I'm 
working from their to build the RAID. Same idea.)

Hmmm... I wonder if this more expansive /bin, /sbin, and /lib causes 
hits on the RAID1 drive which ultimately degrade overall performance? 
/lib is hit only at boot time to load the kernel, I'll guess, but /bin 
includes such common tools as bash and grep.

> Also, placing /dev on a tmpfs helps alot to minimize number of writes
> necessary for root fs.

Another interesting idea. I'm not familiar with using tmpfs (no need, 
until now); but I wonder how you create the devices you need when you're 
doing a rescue.

Again, my thanks to everyone who responded and clarified.

-- 
Moshe Yudkowsky * moshe@pobox.com * www.pobox.com/~moshe
"Practically perfect people never permit sentiment to muddle their 
thinking."
    			-- Mary Poppins