[ale] initramfs capable of a multi-device btrfs / new initramfs with dracut help?

[Michael B. Trausch]

On Fri, 2010-07-16 at 16:37 -0400, Jim Kinney wrote:
> current fedora and redhat don't use /etc/mdadm.conf any more. All
> partitions are marked autodetect (don't recal the label in fdisk) 

According to upstream documentation, using 0xfd ("Linux raid
autodetect") is now deprecated; instead, software RAID should be on the
device directly or contained in partitions of type 0xda ("Non-FS data")
and explicitly configured.[0]  Using autodetect-style partitions was
deprecated as of as far back as Linux kernel 2.6.8[1], which was
released nearly six years ago.

At least part of the problem that I had was that when the kernel
autodetection tried to find the array, it would only assemble the array
with the minimum number of drives to make it work in maximally degraded
mode---for this layout, being a RAID6 with 5 drives, it would bring it
up with three drives, and then adding the other two drives back to the
array would force a rebuild.  Uncool.

Sadly, I didn't read the part about using the Non-FS data partition
until today---I've already converted three of the drives to whole-drive
components.  Now that I know that it's possible to use a partition type
that is for "non filesystem data", I think that having them all setup
that way is the best bet, because at least then the array can be
recognized on any operating system that understands the MBR partition
model with a bit of code put together.

The next time that I do this, I think I will go for something that is
connected to the computer using a faster bus, presenting a large drive
to the system without the server system worrying about the RAID details.
Currently, the RAID6 array is connected via eSATA, which is proving to
be a bit slow since the system is actually sending lots of redundant
data to the drives over the link.  An eSATA connection would probably be
adequate for the array if I had a dedicated hardware RAID controller, so
that the data was only going through the bus once as a single request to
a large virtual drive, instead of requests to 5 different drives.  I
cannot imagine that my client will want to spring for a dedicated
hardware-RAID system, but I can probably get them to spring for an
embedded system running a Linux or BSD kernel and minimal system and
exporting the whole array as a single virtual drive to the server.
Depends on what the cost is.  It's working satisfactorily for the moment
except when there are spikes of relatively high load.

	--- Mike

[0] http://is.gd/duM4L
[1] http://is.gd/duMck