I had an idea for a filesystem as an alternative to using a raw disk
partition for storing a single (large) data file (eg. a DVD image or a
database data file), adding the convenience of a file length, permissions
and a uid/gid.
As I now have some functional code (a 'compile outside the kernel'
module, only tested against i386/2.6.9) I thought I'd share the sffs
(single file file-system) code for comments/testing.
Performance for a single file is between 0 and 40% faster than ext2,
(though sffs is not a general purpose filesystem).
Some more details/benchmarks:
http://www.arkady.demon.co.uk/sffs
the code can be downloaded from:
http://www.arkady.demon.co.uk/sffs/sffs-latest.tar.gz (13.5k)
Regards,
Bernard
In article <[email protected]>,
Bernard Hatt <[email protected]> wrote:
>I had an idea for a filesystem as an alternative to using a raw disk
>partition for storing a single (large) data file (eg. a DVD image or a
>database data file), adding the convenience of a file length, permissions
>and a uid/gid.
>
>As I now have some functional code (a 'compile outside the kernel'
>module, only tested against i386/2.6.9) I thought I'd share the sffs
>(single file file-system) code for comments/testing.
I've been using such a filesystem for years, since Linux 2.0 ..
It's at ftp://ftp.cistron.nl/pub/people/miquels/kernel/v2.[0246]/rawfs-*
I use it with the CNFS (Cyclic News File System) storage option
of INN for high-performance usenet news transit systems.
Mike.
Hi!
> I had an idea for a filesystem as an alternative to using a raw disk
> partition for storing a single (large) data file (eg. a DVD image or a
> database data file), adding the convenience of a file length,
> permissions
> and a uid/gid.
Long time ago, Martin Mares did something very similar, IIRC it was called
smugfs.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Hi!
> Long time ago, Martin Mares did something very similar, IIRC it was called
> smugfs.
Actually, it was a bit smarter (but just a small bit :) ) -- it allowed
multiple files and allocated space by dividing the whole partition to
256 blocks and remembering a single-sector FAT-like structure. However,
no subdirectories were supported.
The code is probably of historical interest only, but you can find it
at ftp://atrey.karlin.mff.cuni.cz/pub/local/mj/linux/smugfs-0.0-2.0.32.tar.gz.
Once it worked, but I don't believe it's SMP safe.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"First they ignore you. Then they laugh at you. Then they fight you. Then you win." -- Gandhi
Miquel van Smoorenburg wrote:
> I've been using such a filesystem for years, since Linux 2.0 ..
> It's at ftp://ftp.cistron.nl/pub/people/miquels/kernel/v2.[0246]/rawfs-*
> Mike.
Yes, it depends how much functionality you *need*, sffs implements
more file operations so that you can do things like:
mkisofs -o /mnt/test/blah.iso [...]
and cdrecord -v -data /mnt/test/blah.iso (without needing isosize).
But what is odd, having run my benchmarks on rawfs, that sffs
is faster by between (0.5% and 4.6%) where I was expecting
almost identical results (but then, benchmarks aren't everything).
Regards,
Bernard