I know some filesystems present themselves through Fuse and I was wondering about the pros and cons to this approach.


I'm not positive if you mean real, on-disk filesystems or any filesystem. I've never seen a normal filesystem use FUSE, although I suppose it's possible; the main benefit of FUSE is it lets you present something to applications (or the user) that looks like a filesystem, but really just calls functions within your application when the user tries to do things like list the files in a directory or create a new file. Plan9 is well known for trying to make everything accessible through the filesystem, and the /proc pseudo-filesystem comes from them; FUSE is a way for applications to easily follow that pattern

For example, here's a screenshot of a (very featureless) FUSE filesystem that gives access to SE site data:

Screenshot of FUSE filesystem in action

Naturally none of those files actually exist; when ls asked for the list of files in the directory FUSE called a function in my program which did an API request to this site to load information about user 73 (me); cat trying to read from display_name and website_url called more functions that returned the cached data from memory, without anything actually existing on-disk

  • 3
    There are FUSE implementations of FAT, NTFS, iso9660, ext2, and more. – Gilles 'SO- stop being evil' Nov 17 '10 at 22:26
  • 2
    You will find heavy duty filesystems implemented in fuse: LessFS, GlusterFS, MooseFS. Google's GFS (not POSIX) also runs in userspace. – Tobu Feb 28 '11 at 0:36
  • Where did you find that app?!?! – Nathan Osman May 6 '11 at 2:01
  • 4
    @George I wrote it when I was messing with the SO API. It doesn't use any routes except /users, so you're basically seeing all the implemented features in that screenshot; it was just to see how hard it would be – Michael Mrozek May 6 '11 at 3:32
  • 5
    @George I put it on github – Michael Mrozek May 6 '11 at 4:18

Unix filesystems are traditionally implemented in the kernel. FUSE allows filesystems to be implemented by a user program.

In-kernel filesystems are better suited for main filesystems for programs and data:

  • They can be used on boot media (the program implementing a FUSE filesystem has to be loaded from somewhere).
  • They're more robust, in that they won't go away due to a process crashing or being killed by mistake.
  • They're somewhat faster.

FUSE filesystems have other advantages, mostly revolving around their flexibility:

  • They can be loaded and mounted by ordinary users, so they're convenient for file systems that users tend to mount by themselves: for network access, for going through archive files, for removable media, etc.
  • If a FUSE filesystem driver crashes, it won't panic your kernel: you'll see nothing worse than I/O errors in applications that were accessing the filesystem.
  • They can be programmed very quickly; there are FUSE bindings for many scripting languages where a useful FUSE filesystem driver can be written in a few hundred lines of code.
  • They can be deployed very quickly, both because there is no need for administrator intervention to install them and because they can be ported easily between supported OSes.
  • There are no licensing issues related to being statically linked with a kernel (this is affecting zfs).

FUSE isn't really a file system per se but code that allows file systems to be implemented as processes instead of kernel modules.

One of the most useful benefit of FUSE is to allow GPL code to "mix" with non GPL one. For example, Gnu/Linux and ZFS http://zfs-fuse.net/ or NTFS-3G on many OSes like OpenSolaris and *BSD http://www.tuxera.com/community/ntfs-3g-download/

The main drawback is the performance impact compared to native (kernel) drivers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.