<box red 700px|(BAD) NEWS>
I haven't got time to work on ''frfs'' any longer.\\
I focus mainly on my house and my girlfriend, then ''crosstool-NG'' and the Toshiba e800 Linux port.\\
\\
''frfs'' was my first attempt to work with ''[[http://fuse.sourceforge.net/|FUSE]]'', and it proved quite easy to create a simple file system. All the complexity does not lie within ''FUSE'', but really within the file system you implement. That was very instructive, and I learnt quite a big deal.
\\
I may resume work on ''frfs'' later, though. Should this happen, I hope I will have a better design before I start.
----
----
\\
Sorry for those of you who had hope in frfs.
</box>
----
<box right orange 390px|**Latest version**>
Latest frfs version is __**''[[http://ymorin.is-a-geek.org/download/frfs/frfs-0.0.3.tar.bz2|frfs-0.0.3]]''**__.
</box>

====== Introduction ======

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 ''[[http://fuse.sourceforge.net/|FUSE]]'' library and pseudo- file system and let the casual user mount the file system.

''frfs'' is just that: a __**F**__USE-based, in-__**R**__AM __**F**__ile __**S**__ystem (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.

====== Usage ======

  * get ''frfs'':
    * browse the repository __''[[http://ymorin.is-a-geek.org/websvn/listing.php?repname=frfs&path=%2F&sc=0|on-line]]''__
    * as a tarball from __''[[http://ymorin.is-a-geek.org/download/frfs]]''__
    * subversion trunk at __''http:/''''/ymorin.is-a-geek.org/svn/frfs/trunk''__
  * unpack if needed
  * build:
<file>make</file>
  * mount:
<file>./frfs /some/place/frfs</file>
  * use:
<file>
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
</file>
  * umount:
<file>fusermount -u /some/place/frfs</file>

<box round left red 400px|WARNING!!!>
Versions prior to 0.0.3 are not thread-safe, and don't force single-threaded mode in FUSE. You have to specify the ''-s'' option when running frfs, as:
<file>
./frfs -s /some/place/frfs
</file>

0.0.3 (and above) do not need you specify -s, as they do force it internally.
</box>

====== Prospective work ======

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! :-P )
  * ''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 whith 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