Heller_Barde wrote: don't you have to format the ramdisk again every boot with linux raid partition type and stuff?

No, you just add /dev/rd/0 to the array directly; the md driver will automatically "rebuild" the array (i.e. populate the ramdisk) in the background with idle bandwidth (i.e. whenever the permanent storage device isn't being accessed).

Here is one way of doing it:

* First you choose the permanent storage device you want to use; I chose an eSATA flash drive, but a USB flash drive or a HDD would work just as well.

* Create a partition on the device, with type "fd" (linux raid autodetect). Be careful when setting its size, since it will have to be backed by a ramdisk of the exact same size. I made mine exactly 2,147,483,648 bytes (2 GiB, 2,097,152 KiB). Let's say the partition is /dev/sdc1.

* Optionally create a /boot partition for grub/lilo. Grub at least should be able to boot a RAID 1 partition directly, but I haven't bothered to try. Since I'm not using the entire drive for the RAID 1 partition anyway, I figured I might as well set up the other partition (for data) as the /boot partition.

* Make sure /dev/rd/0 is available. I set the ramdisk parameters in my kernel command line (/boot/grub/menu.lst): brd.rd_nr=1 brd.rd_size=2097152. I also added raid=autodetect in there. All three parameters can be hardcoded when compiling the kernel, with make menuconfig.

* Create the array:

mdadm -C [b]/dev/md0[/b] -n 2 -l 1 /dev/rd/0 -W [b]/dev/sdc1[/b]

Note: the choice of the /dev/md[0-9] device number is permanent; if you are already running a RAID array and have to use /dev/md1 for instance, you'll have to specify the same device (/dev/md1) as the root of the filesystem when booting.

If you want to delay writing to /dev/sdc1, add both the --write-behind and -b internal parameters:

mdadm -C /dev/md0 -n 2 -l 1 [b]-b internal[/b] /dev/rd/0 -W [b]--write-behind[/b] /dev/sdc1

I'm still not sure how much of an impact it has on general responsiveness; you should test it yourself (YMMV). See the md(4) and mdadm(8) man pages for more information.

* If the command is successful, the md driver will start populating the ramdisk with the (albeit empty) contents of /dev/sdc1. You can watch its progression by running cat /proc/mdstat, or:

watch -n 1 'cat /proc/mdstat'

* Create a filesystem on your RAID device. I chose XFS:

mkfs.xfs -L RAID1 /dev/md0

* Your hybrid RAID1 device is created, you can now mount its filesystem, like with any other device. Copy on it the contents of what will be your root filesystem, while making sure you have modified the appropriate files like /etc/fstab (with /dev/md0 for /), etc… Personally, I previously booted an Arch installation USB drive and made a tarball of my entire / partition; then, after I created the RAID1 array, I simply unpacked the tarball onto the RAID1 filesystem:

tar -C /mnt/md0 -x -p -f backup.tar

* In /etc/rc.local of the RAID filesystem, add this line: mdadm /dev/md0 -a /dev/rd/0

* Make sure /dev/sdc is bootable (set up grub on it). Use either /dev/sdc1 or /dev/sdc2 as the boot partition (depending on your earlier choice), not /dev/md0 (I'm not sure that would work).

* In /boot/grub/menu.lst of /dev/sdc1 or /dev/sdc2, set root=/dev/md0 in your kernel command line, as well as the other three parameters I mentioned above (raid=autodetect and brd.rd_nr=1 brd.rd_size=2097152). I also added rootwait just to be sure the kernel would wait for the RAID1 device to be detected before it attempts to mount it; it's particularly important if /dev/sdc is a flash drive. If that doesn't work (kernel panic before it could find the root device), use rootdelay=20.

That's pretty much it. Reboot. The kernel will detect /dev/sdc1 as being part of a RAID 1 array and mount it as root, even though it can't find its second member (the ramdisk). That's alright. When /etc/rc.local is finally executed (at the end), the ramdisk gets added to the RAID array, and md populates it; meanwhile, you can do anything you want on the filesystem (read/write). The "rebuilding" process is pretty fast (as fast as the permanent storage device allows) because it is done on a block device level, as opposed to a filesystem level: transfer blocks are fairly large (128KiB by default, it seems). The faster the device at large sequential reads, the faster the rebuilding. That's why a HDD is perfectly acceptable in such a setup.

I haven't yet tried starting X and my other apps immediately (I've waited for the rebuilding process to complete, which takes a few seconds here); but once the ramdisk is populated, everything loads instantly. It would be pretty hard to go back to a normal setup…