With Linux, creating RAM-backed file system is easy: su to root, mount a tmpfs some place, come back to plain user.

Ah, but you've got to become root! I abhor being root when that can be avoided.

The solution is to use the FUSE library and pseudo- file system and let the casual user mount the file system.

frfs is just that: a FUSE-based, in-RAM File System (and no, it does not stand for FRench FileSystem, though I happen to be French).

In its current state, frfs does work quite nicely. It supports most of the usefull features of a Linux file system:

• files and directories
• symlinks
• hard links
• unlink open files, free on last close()
• most file operations:
  • open(2)
  • read(2)
  • write(2)
  • close(2)
  • opendir(2)
  • readdir(2)
  • truncate(2)
  • and so on…

But it lacks some functionality: some interesting operations are not yet implemented (but should be easy):

• statfs(2)
• flush(2)
• and so on…
• extended attributes

Also it is not thread-safe yet. Some infrastructure is there, but code is missing.

• get frfs:
  • clone the Mercurial repository at: http://ymorin.is-a-geek.org/hg/frfs
  • download a tarball from: http://ymorin.is-a-geek.org/download/frfs
• unpack if needed
• build:

make

• mount:

./frfs /some/place/frfs

• use:

cd /some/place/frfs
tar xjf /my/files/linux-2.6.22.3.tar.bz2
cd linux-2.6.22.3
make defconfig
make
cd

• umount:

fusermount -u /some/place/frfs

./frfs -s /some/place/frfs

Here is a list of somewhat ordered TODOs:

• Make it thread-safe.
• Make it build on 32-bit archs with debug messages (without debug msg, it's OK).
• Make the opened file handles table dynamic (how many open file can there be at any one time in a UNIX system?)
• Unfortunately, it is quite slow. Internal structures are based on chained lists, which is really slow when it comes to big trees (say, a Linux kernel!). There is much work in this area. Some idea come to mind:
  • a cache for recently searched dentries
  • hash-tables (there is a CRC-8-based lookup table in place now)
  • B-trees or red-black-trees
  • use a garbage collector (I don't yet know what for, but I like garbage collectors! )
• frfs is an in-RAM file system, which means that all data is lost on umount. It could be interesting to have the data written to disk in a compact form (compressed, for example) before actual umount, so it could be retrieved on the next mount. Snapshots would then be easy to implement:
  • send a signal to the file system so it dumps its internal structures onto disk
  • periodic dumps
  • use extended attributes to mark data (not) to be saved on dumps
• Distribute the file system across a cluster of nodes (Oh yes, I know: I'm dreaming ):
  • centralised model
    • access the same data from whatever machine in the cluster
    • similar to what NFS, samba et al. provide
  • distributed model
    • migrate data between machines, live
      • migrate to the most demanding machine
      • migrate with nodes coming and going
      • migrate for fast access when behind a slow link
    • replicate data in more than one machine, live
      • no loss (or reduced risk of loss) of data
      • replicate for fast access when behind a slow link
      • use extended attributes to mark (un)important or (un)shareable data