3 ms·

Build your own filesystem, hellowordFS.c in 100 lines!

27 points by captaincrunch 16y ago

captaincrunch 16y ago
New to me, but perhaps not everyone else...
Bjoern 16y ago
FUSE has been around for a while, it is really a great piece of software. Especially the many different language bindings make it interesting. Here is one for instance in Ruby (Hello World) http://www.debian-administration.org/article/Creating_Filesystems_with_Ruby__and_FUSE http://www.debian-administration.org/article/Creating_Filesy... Only disclaimer, as it runs in Userspace it's quite a bit slower than its kernel space twin.
- chasingsparks 16y ago
  Ditto on FUSE. I use fusecompress to store a lot of CSV data on my SSD. It was a solution borne of necessity -- I skimped on capacity when buying the SSD -- but it worked very well. http://code.google.com/p/fusecompress/ http://code.google.com/p/fusecompress/
- koenigdavidmj 16y ago
  Not too much slower (well, you're bringing Ruby into the picture, so maybe it is after all ;). According to [1], NTFS-3G (FUSE) is basically on par with XFS (native), only slightly slower on rewriting. ZFS on FUSE reads almost as fast and lacks in write speed, which is reasonable---it's not optimised in the slightest and ZFS has a reputation for being somewhat slow even on Solaris, where it is native. Not too shabby, I think. (It's a benchmark, though. Your mileage may vary.) 1: http://www.csamuel.org/2007/04/25/comparing-ntfs-3g-to-zfs-fuse-for-fuse-performance/ http://www.csamuel.org/2007/04/25/comparing-ntfs-3g-to-zfs-f...
  - leif 16y ago
    No, FUSE is really slow, it just depends what you're benchmarking. That guy is really benchmarking the disk, not the filesystem. If you benchmark things that test the filesystem layer on its operations---that is, make it do lots of things to metadata but not read or write much actual data---FUSE gets the crap beaten out of it. As an example, write a no-op filesystem in FUSE and a no-op filesystem under the VFS, and run postmark[1] on it. You should get some pretty drastic results. My professor has something called FiST[2] (like yacc for filesystem devs) that gets about 1-2% overhead over a native FS, and I believe one of his papers contains a comparison with FUSE that shows how bad FUSE is, but I don't remember it. [1]: http://www.shub-internet.org/brad/FreeBSD/postmark.html http://www.shub-internet.org/brad/FreeBSD/postmark.html [2]: http://www.fsl.cs.sunysb.edu/project-fist.html http://www.fsl.cs.sunysb.edu/project-fist.html
coned88 16y ago
I build my own fs in college, it was pretty fun.
yummyfajitas 16y ago
On the topic of fuse, I'll just take a moment to shamelessly plug mp3fs, a filesystem I wrote: https://bitbucket.org/stucchio/mp3fs/ https://bitbucket.org/stucchio/mp3fs/ $ ls music 01 Ghosts I.flac 03 Ghosts I.wav mp3file.mp3 02 Ghosts I.wav 04 Ghosts I.ogg list_of_music.txt $ mkdir mp3music $ mp3fs music mp3music $ ls mp3music 01 Ghosts I.mp3 03 Ghosts I.mp3 mp3file.mp3 02 Ghosts I.mp3 04 Ghosts I.mp3 $ cp mp3music/*.mp3 /media/mp3_player_that_doesnt_play_flac_or_ogg_files

27 points by captaincrunch 16y ago

New to me, but perhaps not everyone else...

FUSE has been around for a while, it is really a great piece of software. Especially the many different language bindings make it interesting. Here is one for instance in Ruby (Hello World) http://www.debian-administration.org/article/Creating_Filesystems_with_Ruby__and_FUSE http://www.debian-administration.org/article/Creating_Filesy... Only disclaimer, as it runs in Userspace it's quite a bit slower than its kernel space twin.

chasingsparks 16y ago
Ditto on FUSE. I use fusecompress to store a lot of CSV data on my SSD. It was a solution borne of necessity -- I skimped on capacity when buying the SSD -- but it worked very well. http://code.google.com/p/fusecompress/ http://code.google.com/p/fusecompress/
koenigdavidmj 16y ago
Not too much slower (well, you're bringing Ruby into the picture, so maybe it is after all ;). According to [1], NTFS-3G (FUSE) is basically on par with XFS (native), only slightly slower on rewriting. ZFS on FUSE reads almost as fast and lacks in write speed, which is reasonable---it's not optimised in the slightest and ZFS has a reputation for being somewhat slow even on Solaris, where it is native. Not too shabby, I think. (It's a benchmark, though. Your mileage may vary.) 1: http://www.csamuel.org/2007/04/25/comparing-ntfs-3g-to-zfs-fuse-for-fuse-performance/ http://www.csamuel.org/2007/04/25/comparing-ntfs-3g-to-zfs-f...
- leif 16y ago
  No, FUSE is really slow, it just depends what you're benchmarking. That guy is really benchmarking the disk, not the filesystem. If you benchmark things that test the filesystem layer on its operations---that is, make it do lots of things to metadata but not read or write much actual data---FUSE gets the crap beaten out of it. As an example, write a no-op filesystem in FUSE and a no-op filesystem under the VFS, and run postmark[1] on it. You should get some pretty drastic results. My professor has something called FiST[2] (like yacc for filesystem devs) that gets about 1-2% overhead over a native FS, and I believe one of his papers contains a comparison with FUSE that shows how bad FUSE is, but I don't remember it. [1]: http://www.shub-internet.org/brad/FreeBSD/postmark.html http://www.shub-internet.org/brad/FreeBSD/postmark.html [2]: http://www.fsl.cs.sunysb.edu/project-fist.html http://www.fsl.cs.sunysb.edu/project-fist.html

coned88 16y ago

I build my own fs in college, it was pretty fun.

yummyfajitas 16y ago

On the topic of fuse, I'll just take a moment to shamelessly plug mp3fs, a filesystem I wrote: https://bitbucket.org/stucchio/mp3fs/ https://bitbucket.org/stucchio/mp3fs/ $ ls music 01 Ghosts I.flac 03 Ghosts I.wav mp3file.mp3 02 Ghosts I.wav 04 Ghosts I.ogg list_of_music.txt $ mkdir mp3music $ mp3fs music mp3music $ ls mp3music 01 Ghosts I.mp3 03 Ghosts I.mp3 mp3file.mp3 02 Ghosts I.mp3 04 Ghosts I.mp3 $ cp mp3music/*.mp3 /media/mp3_player_that_doesnt_play_flac_or_ogg_files