2.4 KiB
Tweaking Performance
mergerfs is effectively a filesystem proxy and therefore its theoretical max performance is that of the underlying devices (ignoring caching performed by the kernel.) However, given it is a FUSE based filesystem working from userspace and it must combine the behavior and information from multiple underlying branches there can be an increase in overhead relative to other solutions. That said the performance of certain functions, such as IO, can match the theoretical max but it depends greatly on the system's configuration. There are many things which can impact performance. Device speeds and latency, network speeds and latency, concurrency and parallel limits of the hardware, read/write sizes, the number of branches, etc.
While some settings can impact performance they are all functional in nature. Meaning they change mergerfs' behavior in some way. As a result there is really no such thing as a "performance mode".
If you're having performance concerns please read over the benchmarking section of these docs and then the details below.
NOTE: Be sure to read about available features before changing them to understand how functionality will change.
- test theoretical performance using
nullrwor using a ram disk as a branch - enable passthrough.io (likely to have the biggest impact)
- change read or process thread pools
- change func.readdir
- increase readahead:
readahead=1024 - disable
security-capabilityand/or xattr - increase cache timeouts cache.attr, cache.entry, cache.negative-entry
- toggle page caching
- enable
parallel-direct-writes - enable cache.statfs
- enable cache.symlinks
- enable cache.readdir
- disable
posix-acl - disable
async-read - use symlinkify if your data is largely static and read-only
- use tiered cache devices
- use LVM and LVM cache to place a SSD in front of your HDDs