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

[Michael B. Trausch]

On Sat, 2010-07-17 at 18:21 -0400, Brian Pitts wrote:
> On 07/17/2010 02:47 PM, Michael Trausch wrote:
> > You would configure the array in mdadm.conf (either
> in /etc/mdadm.conf or
> > /etc/mdadm/mdadm.conf) and the use mdadm to start up the array, for
> example:
> > 
> > ARRAY /dev/md0 level=raid6 metadata=1.1 num-devices=5
> > UUID=3b4045f1:253f01cd:de8
> > 023f1:8438c90d name=fennel:ATS_SRVR_R6_0
> > 
> > And:
> > 
> > mdadm --assemble /dev/md0 --uuid=3b4045f1:253f01cd:de8023f1:8438c90d
> 
> What if / is on the RAID?

Well, that depends.

The directory that really matters is the one that contains the static
bootloader files.  To understand why that is, one must first understand
at least a high-level overview as to how the boot process works, so I'll
first answer your question and then explain why that is.

First, / can be on the RAID---so can /usr, /home, or any other
filesystem.  However, /boot can _not_ be on a RAID array, unless it is a
RAID 1 array (see below for additional detail).  This of course makes
the assumption that your static boot files (that is, any bootloader
support files, the Linux kernel itself, and an appropriately stocked
initrd) are located in the /boot directory; this is the case for every
single distribution of a Linux-based system that I am aware of, though
in my personal opinion it could still be made better.

Before I go any further, I have to say that this is one of the
simultaneously great and awful things about free software.  There is no
one single answer that will apply to all distributions, because some
distribution could have patches or entirely different pieces in its
software stack that do not exist elsewhere.  So I could be wrong for
some value of $DISTRO that I am unfamiliar with, unaware of, or for all
values of $DISTRO where $USER is a developer and working on making me
wrong.  :-)

We all know that a RAID array is nothing more than an arrangement of
bits on multiple disks which adds redundancy, additional space, or both.
We also know that when it comes to software RAID, which is what we're
talking about here, all of the pieces of the software stack have to
support read/write operations on the RAID array (or, for some things
like bootloaders, at the very least a read operation on it).

Now, for the GRUB bootloader, a kernel and initrd can be read from one
disk in a RAID 1 array, or it can be read from a single static partition
that is not in an array at all.  AFAIK, GRUB (even GRUB 2) does not
support more complex RAID setups at this moment in time.  Since RAID is
not a backup method, just a "keep things up and running longer" strategy
(except in the case of RAID 0, which I'd argue is a mostly pointless
RAID level anyway), this doesn't matter all that much.  You keep your
kernel, initrd, and bootloader support files on an ext2 partition
mounted at /boot, and keep it mounted with the sync option (and possibly
ro for normal operation) and you're all set.  Then you can have every
single other filesystem be in whatever RAID you want, because once the
bootloader loads the operating system kernel and transfers control to
it, you presumably have enough in the initrd to bring up your arrays
and, pivot_root(2), and bring up userspace.

To go on a bit of a tangent, I can think of a few different ways that
this could be made better.  I recall at least one bootloader (though the
name escapes me, even whether or not it had a name escapes me, but I am
pretty sure it was the OS/2 bootloader program) that had as a
requirement a dedicated partition just for it.  I think that the ideal
bootloader would keep this requirement.  You could then afford to have a
slightly larger bootloader that understood things like the types of
software RAID used by various operating systems such as Linux and the
BSD family of operating systems, and be able to boot from them all
without a terribly large amount of effort.

This would make it possible to do something like have a read-only SD
card or similar flash device contain the bootloader (or, for that
matter, for the bootloader to be placed in a decently sized firmware).
It could afford to understand a wide variety of filesystems and storage
formats, including LVM2, BSD disklabels, and the various types of
software RAID used by different operating systems.

Of course, that wouldn't fix all the problems involved with booting.
It's 2010, and we still have a different method required for booting
every single operating system out there.  It's pretty obnoxious, really;
only a small handful of free software operating systems support the
Multiboot specification, and it would really be to everyone's benefit
(even Apple's and Microsoft's) to be bootable without operating-system
specific versions of the hokey pokey (it's not like Multiboot is
terribly hard to implement, either, it's just a well-defined entry point
and interface agreement between the bootloader and operating system
kernel).

That would also mean, though, that the kernel's loadable modules (in the
case of the Linux kernel, anyway) would need to be available in /boot,
and an initrd would be completely unnecessary, because the bootloader
could be configured (say, at operating system installation time and any
time that some major change requires it) to load only the modules
required, before hitting the kernel's entry point.  Unfortunately,
that's just not the way it is at present.

Anyway, this particular email has gotten to be far too long, so I'll end
it now... later!

	--- Mike