There are some caveats to this (see below), but here's a way I've been playing with to run a filesystem from RAM: . 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 . 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 . Now add that mirror to the RAID set: losetup /dev/loop0 /raid_ramdisk/root mdadm /dev/md0 --add /dev/loop0 . ...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.