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
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.
Latest frfs version is
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:
But it lacks some functionality: some interesting operations are not yet implemented (but should be easy):
Also it is not thread-safe yet. Some infrastructure is there, but code is missing.
cd /some/place/frfs tar xjf /my/files/linux-184.108.40.206.tar.bz2 cd linux-220.127.116.11 make defconfig make cd
fusermount -u /some/place/frfs
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:
./frfs -s /some/place/frfs
0.0.3 (and above) do not need you specify -s, as they do force it internally.
Here is a list of somewhat ordered TODOs:
frfsis 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: