What are the benefits and downsides to use FuseFS filesystems?
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:
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
website_url called more functions that returned the cached data from memory, without anything actually existing on-disk
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 (zfs-fuse, now deprecated and obsoleted by openZFS) or NTFS-3G on many OSes like OpenSolaris/illumos and *BSD
The main drawback is the performance impact of a userland driver compared to a native (i.e. kernel) driver.
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).