7

Until now I have never dwelled on the word fuse but then I saw that there is nofuse.

Based on searches I have done in the the internet they don't clearly explain the difference. What is the difference between fuse and nofuse?

For example, what does fuse versus nofuse this in terms of performance and benefits? nofuse allows you to start a flash drive at boot time and fuse doesn't? This is what interests me.

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
Mario Palumbo
  • 219
  • 1
  • 8
  • 2
    These questions are better for [unix.se] – Evan Carroll Feb 15 '22 at 15:03
  • 3
    Happy you got an answer, Mario. But you shouldn’t [edit your question](https://superuser.com/posts/1705073/revisions) to add commands you will use to remove the fuse exfat stuff. Just accept the answer as posted and move on. We’re happy the community has helped, but this site is not a forum. – Giacomo1968 Feb 15 '22 at 16:01

3 Answers3

18

They're two different drivers. One of them is created using FUSE, the other is a kernel module.

FUSE is a framework that allows filesystem drivers to be written in "userspace", i.e. as standalone services rather than kernel modules. This makes development much easier, at the cost of lower performance.

FUSE-based filesystems may be somewhat slower than in-kernel ones, as each operation goes through several context switches – from your program to the kernel to the corresponding FUSE service (which has to read data from a device, so back into the kernel and out again), then the reply is again handled by the kernel and delivered to your process. It's nothing special compared to e.g. databases which also run as services, but it does make things slower when compared to filesystems that directly run as part of the kernel.

However, FUSE-based drivers like exfat-fuse can be installed regardless of currently running kernel (the interface is specifically meant to be stable), compared to kernel-based ones such as ZFS which have to be adapted to each new major kernel version and the module has to be recompiled separately for each minor version (often on the user's machine).

So for filesystems that are not (yet) part of the Linux kernel (regardless of the reason), using FUSE is a common choice because it makes the driver easier to write and easier to deploy – which is why exfat-fuse became commonly used. (Due to the drivers being ordinary programs, FUSE also makes it easy to build custom filesystems like sshfs, ftpfs, or wikipediafs.)

At this time, though, the 'exfat-nofuse' package is now obsolete (well, both of them are obsolete), as current kernel versions have a built-in exFAT driver, so neither of the external drivers is needed anymore.

Similarly, the "ntfs-3g" NTFS driver is also FUSE-based, though it is likely to be replaced by the new in-kernel "ntfs3" driver at some point.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • 1
    Thank you very much, you brought me to the solution to use non-fuse, which I will include in the question. – Mario Palumbo Feb 15 '22 at 15:48
  • I don't think this part is correct _So for filesystems that are not (yet) part of the Linux kernel (regardless of the reason), using FUSE is a common choice because it makes the driver easier to write and easier to deploy – which is why exfat-fuse became commonly used._ I don't think _easier to write_ has much to do with it. For most ground-up filesystem development, it's probably harder to write something to an abstraction than to the metal. You'll have to write a user-space daemon and IPC code. – Evan Carroll Feb 15 '22 at 16:43
  • 3
    @EvanCarroll: FUSE is the IPC code, you don't have to write it yourself. (And I assume some helper stuff for the user-space part). I think you just have to write code with callbacks for different FS operations like path lookup and metadata lookup, similar to the struct of function-pointers a kernel module would have to provide. (I might be mistaken since I haven't looked at the details of a FUSE-implemented FS.) But instead of doing lower-level I/O by calling into Linux block-device functions, you'd use normal read/write system calls. – Peter Cordes Feb 16 '22 at 11:19
  • 1
    One key difference is debuggability with normal user-space GDB and `strace`, and unit tests and so on. And restarting the user-space part. And memory-corruption bugs in the user-space part won't crash the system, they'll just segfault that user-space process. This is pretty huge for ease of development vs. a kernel oops and worst-case maybe corrupting other filesystems. Either way, a Linux FS module doesn't do "bare-metal" I/O, that's how the same code can run BTRFS on a SATA driver or NVMe, or USB, or iSCSI, or a loopback file. – Peter Cordes Feb 16 '22 at 11:21
4

From fuse(8):

FUSE (Filesystem in Userspace) is a simple interface for userspace programs to export a virtual filesystem to the Linux kernel. FUSE also aims to provide a secure method for non privileged users to create and mount their own filesystem implementations.

The nofuse, means it is handled purely by a kernel module.

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
Bib
  • 1,175
  • 1
  • 6
  • 8
  • and what does this mean in terms of performance and benefits? `nofuse` allows you to start a flash drive at boot time and `fuse` doesn't? This is what interests me. – Mario Palumbo Feb 15 '22 at 15:04
  • 3
    The kernel should be faster. This is a bit historical and goes back to when exfat was propriety surrounded by patents, when Samsung inadvertantly release source code, to when MS announced they would not take action against the os community and others. At least, that's what it boild down to. – Bib Feb 15 '22 at 15:09
2

Your Kernel has a method of talking to hardware. This method (and the kernel itself) runs in Ring 0, which means it's privileged. Filesystem code can contain a rootkit. Moreover, you have to be root to install a kernel module that implements a filesystem driver. You also have to be root to set up the mount point.

FUSE means the filesystem driver runs in user space. A module in the kernel bridges to code that executes as a regular user. This means the footprint for vulnerability is smaller, and more universal. A novice implementation of a FUSE driver, will rely on the same kernel bridge as every other FUSE driver.

Here your distro provides two methods for exfat, one is kernel based one is in FUSE.

Evan Carroll
  • 8,863
  • 17
  • 76
  • 129