Skip to content

General Information and Overview

How well does mergerfs scale? Is it "production ready?"

Users have reported running mergerfs on everything from a Raspberry Pi to dual socket Xeon systems with >20 cores. I'm aware of at least a few companies which use mergerfs in production. Open Media Vault includes mergerfs as its sole solution for pooling filesystems. The author of mergerfs had it running for over 300 days managing 16+ devices with reasonably heavy 24/7 read and write usage. Stopping only after the machine's power supply died.

Most serious issues (crashes or data corruption) have been due to kernel bugs. All of which are fixed in stable releases.

Why use FUSE? Why not a kernel based solution?

As with any solution to a problem, there are advantages and disadvantages to each one.

A FUSE based solution has all the downsides of FUSE:

  • Higher IO latency due to the trips in and out of kernel space
  • Higher general overhead due to trips in and out of kernel space
  • Double caching when using page caching
  • Misc limitations due to FUSE's design

But FUSE also has a lot of upsides:

  • Easier to offer a cross platform solution
  • Easier forward and backward compatibility
  • Easier updates for users
  • Easier and faster release cadence
  • Allows more flexibility in design and features
  • Overall easier to write, secure, and maintain
  • Much lower barrier to entry (getting code into the kernel takes a lot of time and effort initially)

FUSE was chosen because of all the advantages listed above. The negatives of FUSE do not outweigh the positives.

Is my OS's libfuse needed for mergerfs to work?

No. Normally mount.fuse is needed to get mergerfs (or any FUSE filesystem to mount using the mount command but in vendoring the libfuse library the mount.fuse app has been renamed to mount.mergerfs meaning the filesystem type in fstab can simply be mergerfs. That said there should be no harm in having it installed and continuing to using fuse.mergerfs as the type in /etc/fstab.

If mergerfs doesn't work as a type it could be due to how the mount.mergerfs tool was installed. Must be in /sbin/ with proper permissions.

Why was splice support removed?

After a lot of testing over the years, splicing always appeared to at best, provide equivalent performance, and in some cases, worse performance. Splice is not supported on other platforms forcing a traditional read/write fallback to be provided. The splice code was removed to simplify the codebase.