What FUSE 3.12 Changed About One Mount’s Throughput
A MooseFS mount on Debian 12 or 13, Ubuntu 24 or 26, RHEL 10, Fedora 44, or FreeBSD 14 or 15 can move less data through a single mount than the same mount on an earlier release.
The cluster isn’t the problem, and neither is the network. These systems use libfuse 3.12 or newer, and libfuse 3.12 brought back a limit that a single mount can hit.
If you’re choosing a client machine today, an earlier OS release can give you more throughput from a single mount. If the machine is already running one of the affected releases, adding more mounts is the practical way around the limit. Adding more application threads won’t help.
libfuse Put a Limit Back on Worker Threads
Every operation from a mount goes through a single FUSE connection. libfuse has a pool of worker threads that reads requests from that connection and sends the replies back.
Older libfuse versions handled this differently. libfuse 2.5 had a limit on the number of worker threads. Later versions removed that limit, allowing the pool to grow as the workload increased. libfuse 3.12 added the limit again, with a default of ten worker threads.
That means a mount using the default settings can process at most ten operations at a time.
The important part is where the limit sits: below the application. You can add more application threads, make the queues deeper, or use asynchronous I/O, but all that work still ends up going through the same ten FUSE workers. So application-level tuning doesn’t remove the bottleneck.
The limit is configurable through the libfuse 3.12 interface. However, mfsmount currently asks libfuse for an older interface, which doesn’t have a setting for the worker-thread count. As a result, the libfuse default remains in effect.
There’s also no MooseFS mount option that controls this setting. In practice, that leaves multiple mounts as the way around the limit.
Check the FUSE Version on the Mount Itself
It’s tempting to keep a list of affected operating-system releases, but that list will change as distributions release new versions.
A better approach is to check the FUSE version that the mount is actually using. The .params file in the root of the mount contains this information. The file is readable only by root.
cat /mnt/mfs/.paramsYou’ll see something like:
fuse_library_version: 31.2The value is libfuse’s version code rather than the usual dotted version number. For example:
31.2= libfuse 3.1231.0= libfuse 3.10
A value of 31.2 or higher means the mount is subject to the worker-thread limit.
Multiple Mounts Can Increase Total Throughput
A single mount sends all of its operations through one FUSE connection and its worker pool.
If you create a second mount on the same machine, it gets its own FUSE connection and its own pool of workers. Splitting the workload across several mounts can therefore increase the total throughput of the machine.
This was already a useful approach when a single mount couldn’t fully use the available hardware or network bandwidth. The libfuse 3.12 limit simply means more systems can now run into that situation.
There’s another option if the application doesn’t actually need a filesystem mount.
An application linked against libmfsio can act as the client directly and communicate with the Master Server and Chunkservers without going through FUSE. MooseFS Block Device uses this library, so a block-device client doesn’t depend on FUSE and isn’t affected by this particular limit.
This is a temporary situation. Once a newer version of mfsmount supports the 3.12 protocol, this limitation will no longer affect MooseFS mounts using libfuse 3.12 or newer.