(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 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 version
Latest frfs version is frfs-0.0.3
.
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:
open(2)
read(2)
write(2)
close(2)
opendir(2)
readdir(2)
truncate(2)
But it lacks some functionality: some interesting operations are not yet implemented (but should be easy):
statfs(2)
flush(2)
Also it is not thread-safe yet. Some infrastructure is there, but code is missing.
frfs
:http://ymorin.is-a-geek.org/hg/frfs
http://ymorin.is-a-geek.org/download/frfs
make
./frfs /some/place/frfs
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
fusermount -u /some/place/frfs
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:
./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:
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: