There are some caveats to this (see below), but here's a way I've been playing
with to run a filesystem from RAM:

[1]. Make a RAID-1 device (say /dev/md0) smaller than the size of your RAM and
put the filesystem there. Initially create this the usual way, i.e. using an
ordinary physical disk. Make this RAID device have room for one more disk,
e.g.:

mdadm --create /dev/md0 -l 1 -n 2 /dev/sda2 missing

[2]. make a tmpfs (ramdisk) filesystem big enough to hold a mirror of the RAID
device:

mkdir /raid_ramdisk

mount -t tmpfs -o size=XX none /raid_ramdisk

where XX is slightly larger than the size of /dev/sda2, in bytes.

truncate -s YY /raid_ramdisk/root

where YY is exactly the size of /dev/sda2 in bytes

[3]. Now add that mirror to the RAID set:

losetup /dev/loop0 /raid_ramdisk/root

mdadm /dev/md0 --add /dev/loop0

[4]. ...and tell the RAID driver not to read from /dev/sda2 any more (but still
keep it synched):

echo writemostly > /sys/block/md0/md/dev-sda2/state

Now you have your entire root filesystem in RAM, and things should run quickly
:) You can verify this by running:

hdparm -t /dev/md0

On my system this returns numbers like:

	/dev/md0:
	Timing buffered disk reads: 5218 MB in  2.63 seconds = 1984.92 MB/sec

Benefits of this method:

- The disk copy is always kept in synch with the in-RAM copy, so there's no
  need to manually update the disk copy.

- If you do this on a laptop, you can use this to put your laptop into "solid
  state" mode: remove the physical disk from the array, then use "hdparm -Y" to
  spin it down and park the heads. Now you can toss your laptop around as if it
  were turned off :) (Of course, this only works if you also unmount any other
  filesystems from the disk... so it can be useful for e.g. working on one or
  two things while you're on public transit, then spinning up the disk again
  when you need access to mass storage.)

- Even if you only have one physical disk, your system can survive a physical
  disk failure -- as long as you don't turn it off, and can plug in a
  replacement disk and get it synched up before the next power outage.

Caveats:

- Linux's memory management has a bug, in that it doesn't count tmpfs
  filesystems when determining in-use RAM. It thinks the entire contents of
  tmpfs is "freeable" (it most decidedly isn't). If you have a swap partition,
  this will result in lots of swapping when Linux gets overconfident about RAM;
  if you don't have swap, the system will freeze or crash. One of these days
  I'll get around to filing a bug report about it.

- I don't know of a way to tell Linux "this filesystem is already in RAM, you
  don't need to use the pagecache for it" -- so it will redundantly cache data
  from here. This probably won't have much impact though, as file caches are
  reclaimed when memory is needed.

- It might be more efficient to use a filesystem actually designed for ramdisk
  use, so that it could use compression or at least not allocate memory to
  storing empty space... but this would probably make keeping the on-disk copy
  in synch a little trickier.

- This is (considerably) faster than an SSD, but even so it's probably not
  really worth it. If you have enough RAM to try this, Linux is keeping most of
  the parts of your root filesystem that you actually use cached in RAM anyway.
  It might be a good idea on laptops, though.