github/mergerfs
4
0
Fork 0
mirror of https://github.com/trapexit/mergerfs.git synced 2026-10-20 18:54:32 +00:00
Code Issues Releases Wiki Activity

Update docs; add nofs, policyfs and greyhole

Browse Source
This commit is contained in:
Antonio SJ Musumeci
2026-03-27 22:54:39 -05:00
parent 06433a0548
commit b8776d205d
10 changed files with 172 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files
mkdocs/docs/benchmarking.md
+5 -5
View File
@@ -58,13 +58,13 @@ read/writes. Contact the software author or worse case the mergerfs
author so it may be investigated further.
### write benchmark
### Write Benchmark
```
$ dd if=/dev/zero of=/mnt/mergerfs/16GB.file bs=1M count=16384 oflag=nocache conv=fdatasync status=progress
```
### read benchmark
### Read Benchmark
```
$ dd if=/mnt/mergerfs/16GB.file of=/dev/null bs=1M iflag=nocache conv=fdatasync status=progress
@@ -79,21 +79,21 @@ Below are some basic tests but also try setting `--direct=0`, changing
the `ioengine`, or playing with other options.
#### write
#### Write
```
$ fio --name=writetest --filename=/mnt/mergerfs/16GB.file --size=16Gb --rw=write --bs=1M --direct=1 --numjobs=1 --iodepth=8 --group_reporting --runtime=60 --startdelay=0 --ioengine=psync
```
#### read
#### Read
```
$ fio --name=readtest --filename=/mnt/mergerfs/16GB.file --size=16Gb --rw=read --bs=1M --direct=1 --numjobs=1 --iodepth=8 --group_reporting --runtime=60 --startdelay=0 --ioengine=psync
```
### other benchmarks
### Other Benchmarks
If you are attempting to benchmark other behaviors you must ensure you
clear kernel caches before runs. In fact it would be a good deal to
mkdocs/docs/error_handling_and_logging.md
+1 -1
View File
@@ -90,7 +90,7 @@ filesystems. Mainly `ext4`.
Filesystems, and therefore mergerfs, are doing **lots** of small
actions at high speed. It simply isn't reasonable to log all the
actions of the system all time time. However, there is a debug mode
actions of the system all the time. However, there is a debug mode
which can be toggled on as needed, even at runtime, which will record
some information to help with debugging. The main thing it will record
is a trace of all FUSE messages to the location defined by the
mkdocs/docs/known_issues_bugs.md
+1 -1
View File
@@ -170,7 +170,7 @@ may need to disable the use of the inode in the software if possible
or change the [inodecalc](config/inodecalc.md) setting if possible.
Generally speaking, in modern setups where there are many non-fully
complient POSIX filesystem in use, reliance on inode to have a
compliant POSIX filesystems in use, reliance on inode to have a
specific meaning is not always reasonable. FUSE, for instance, has no
requirement that inode values need to be unique or that two files that
happen to be the same underlying file have the same inode.
mkdocs/docs/project_comparisons.md
+135 -45
View File
@@ -17,9 +17,11 @@ and offers better performance. As of 2020 the author of mhddfs has
Below is an example of mhddfs and mergerfs setup to work similarly.
`mhddfs -o mlimit=4G,allow_other /mnt/drive1,/mnt/drive2 /mnt/pool`
```
mhddfs -o mlimit=4G,allow_other /mnt/drive1,/mnt/drive2 /mnt/pool
`mergerfs -o minfreespace=4G,category.create=ff /mnt/drive1:/mnt/drive2 /mnt/pool`
mergerfs -o minfreespace=4G,category.create=ff /mnt/drive1:/mnt/drive2 /mnt/pool
```
## aufs
@@ -30,15 +32,15 @@ Below is an example of mhddfs and mergerfs setup to work similarly.
aufs, another union filesystem, is a kernel based overlay filesystem
with basic file creation placement policies.
While aufs still is maintained it failed to be included in the
mainline kernel and is no longer available in most Linux distros
making it harder to get installed for the average user.
aufs failed to be included in the mainline kernel and is no longer
available in most Linux distros, making it harder to get installed for
the average user. Development has been largely dormant for years.
While aufs can often offer better peak performance due to being
primarily kernel based (at least when `passthrough.io` is disabled),
mergerfs provides more configurability and is generally easier to
use. mergerfs however does not offer the overlay / copy-on-write (CoW)
features which aufs has.
primarily kernel based (at least when `passthrough.io` is disabled in
mergerfs), mergerfs provides more configurability and is generally
easier to use. mergerfs however does not offer the overlay /
copy-on-write (CoW) features which aufs has.
## unionfs
@@ -74,14 +76,13 @@ as unionfs, aufs, and overlayfs require.
* [https://docs.kernel.org/filesystems/overlayfs.html](https://docs.kernel.org/filesystems/overlayfs.html)
overlayfs is effectively the successor to unionfs, unionfs-fuse, and
aufs and is widely used by Linux container platforms such as Docker and
Podman. It was developed and is maintained by the same developer who
created FUSE.
overlayfs is effectively the functional successor to unionfs,
unionfs-fuse, and aufs and is widely used by Linux container platforms
such as Docker and Podman. Both overlayfs and FUSE were originally created by Miklos Szeredi.
If your use case is layering a writable filesystem on top of read-only
filesystems then you should look first to overlayfs. Its feature set
however is very different from mergerfs and solve different problems.
however is very different from mergerfs and solves different problems.
## RAID0, JBOD, SPAN, drive concatenation, striping
@@ -110,18 +111,6 @@ used those other technologies. Meaning you can't create a file greater
than 1TB on a pool of two 1TB filesystems.
## BTRFS Single Data Profile
[BTRFS'](https://btrfs.readthedocs.io) `single` data profile is
similar to RAID0, spreading data across multiple devices but offering
no redundancy. Unlike mergerfs which pools existing filesystems at a
high level, BTRFS is a complete filesystem that manages storage
directly. If a single device fails in BTRFS single mode, you lose all
data. mergerfs takes a different approach: it pools filesystems as-is
without redundancy, so a device failure only affects data on that one
device, not the entire pool.
## RAID5, RAID6
* [RAID5](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5)
@@ -134,11 +123,11 @@ data once the device is replaced.
mergerfs offers no parity or redundancy features so in that regard the
technologies are not comparable. [SnapRAID](https://www.snapraid.it)
or [nonraid](https://github.com/qvr/nonraid) can be used in
or [NonRAID](https://github.com/qvr/nonraid) can be used in
combination with mergerfs to provide redundancy. Unlike traditional
RAID5 or RAID6 SnapRAID works with drives of different sizes and can
have more than 2 parity drives. However, parity calculations are not
done in real-time. However, nonraid is realtime.
have more than 2 parity drives. Parity calculations with SnapRAID are
not done in real-time but NonRAID's are.
For more details and comparison of SnapRAID to related technologies
see [https://www.snapraid.it/compare](https://www.snapraid.it/compare).
@@ -148,14 +137,14 @@ see [https://www.snapraid.it/compare](https://www.snapraid.it/compare).
* [https://unraid.net](https://unraid.net)
UnRAID is a full OS and offers a (FUSE based?) filesystem which
UnRAID is a full OS and offers a filesystem (likely FUSE based) which
provides a union of filesystems like mergerfs but with the addition of
live parity calculation and storage. Outside parity calculations
mergerfs offers more features and due to the lack of real-time parity
calculation can have higher peak performance. For some users mergerfs
being open source is also preferable.
For semi-static data mergerfs + [SnapRAID](http://www.snapraid.it)
For semi-static data mergerfs + [SnapRAID](https://www.snapraid.it)
provides a similar, but not real-time,
solution. [NonRAID](https://github.com/qvr/nonraid) (see below) is a
fork of UnRAID's parity calculation solution and can also be used with
@@ -208,8 +197,10 @@ bulk media is pooled across regular filesystems using mergerfs.
## ZFS AnyRAID
[ZFS
AnyRAID](https://hexos.com/blog/introducing-zfs-anyraid-sponsored-by-eshtek)
* [https://github.com/openzfs/zfs/discussions/16773](https://github.com/openzfs/zfs/discussions/16773)
[ZFS AnyRAID](https://github.com/openzfs/zfs/discussions/16773)
([announcement](https://hexos.com/blog/introducing-zfs-anyraid-sponsored-by-eshtek))
is a feature being developed for ZFS to provide more flexibility in
pools by allowing mixed-capacity disks while maintaining live
redundancy.
@@ -220,7 +211,7 @@ already provides this flexibility today: add drives of any size at any
time with no redundancy overhead. If you need redundancy with that
flexibility, ZFS AnyRAID could be an option when available; until
then, mergerfs remains the simpler choice for mixed-capacity pooling
with redendancy and integrity available via SnapRAID and/or NonRAID.
with redundancy and integrity available via SnapRAID and/or NonRAID.
## Bcachefs
@@ -258,10 +249,26 @@ a pooling layer, providing built-in redundancy and automatic data
placement rather than relying on external tools or the properties of
underlying filesystems.
Bcachefs is under active development and as of early 2026 should be
considered beta quality. It is suitable for testing and non-critical
deployments, but careful evaluation is recommended before use in
production systems.
Bcachefs is under active development but has had a turbulent
relationship with the mainline kernel: it was merged into Linux 6.7
(January 2024) but subsequently removed in Linux 6.18 (late 2025)
following disagreements over development practices. It is now
distributed as an external DKMS module. It should be considered beta
quality and evaluated carefully before use in production systems.
## Btrfs Single Data Profile
* [https://btrfs.readthedocs.io](https://btrfs.readthedocs.io)
[Btrfs'](https://btrfs.readthedocs.io) `single` data profile is
similar to RAID0, spreading data across multiple devices but offering
no redundancy. Unlike mergerfs which pools existing filesystems at a
high level, Btrfs is a complete filesystem that manages storage
directly. If a single device fails in Btrfs single mode, you lose all
data. mergerfs takes a different approach: it pools filesystems as-is
without redundancy, so a device failure only affects data on that one
device, not the entire pool.
## StableBit's DrivePool
@@ -305,7 +312,7 @@ choice. For Linux users seeking lightweight pooling without redundancy
overhead, mergerfs is the better option.
## Plan9 binds
## Plan 9 binds
* [https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Union_directories_and_namespaces](https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Union_directories_and_namespaces)
@@ -321,6 +328,8 @@ Plan 9 isn't a widely used OS so this comparison is mostly academic.
## SnapRAID pooling
* [https://www.snapraid.it/manual](https://www.snapraid.it/manual)
[SnapRAID](https://www.snapraid.it/manual) has a pooling feature which
creates "a read-only virtual view of all the files in your array using
symbolic links."
@@ -341,6 +350,8 @@ that kind of setup.
## rclone union
* [https://rclone.org/union](https://rclone.org/union)
rclone's [union](https://rclone.org/union) backend allows you to
create a union of multiple rclone backends and was inspired by
[mergerfs](https://rclone.org/union/#behavior-policies). Given rclone
@@ -355,11 +366,11 @@ given the differing feature sets and focuses of the two projects.
## distributed filesystems
* AFS
* Ceph/CephFS
* GlusterFS
* LizardFS
* MooseFS
* [AFS](https://www.openafs.org)
* [Ceph/CephFS](https://ceph.io)
* [GlusterFS](https://www.gluster.org)
* [LizardFS](https://lizardfs.com)
* [MooseFS](https://moosefs.com)
* etc.
Distributed remote filesystems come in many forms. Some offering POSIX
@@ -370,7 +381,7 @@ filesystems with duplication.
These filesystems almost always require a significant amount of
compute to run well and are typically deployed on their own
hardware. Often in an "orchestrators" + "workers" configuration across
hardware. Often in an orchestrator + worker node configuration across
numerous nodes. This limits their usefulness for casual and homelab
users. There could also be issues with network congestion and general
performance if using a single network and that network is slower than
@@ -382,8 +393,87 @@ complicated setup and more compute resources than mergerfs (while also
offering a different set of capabilities.)
## nofs
* [https://github.com/chapmanjacobd/nofs](https://github.com/chapmanjacobd/nofs)
nofs is a tool that provides mergerfs-like functionality for combining
multiple filesystems/directories into a unified view but does so
entirely through subcommands which replicate traditional POSIX
commands rather than providing a proper filesystem. It takes a lot of
inspiration from mergerfs in that it supports policy-based branch
selection (mfs, ff, pfrd, epmfs, and others), read-only and no-create
branch modes, and recreates POSIX-like commands such as `ls`, `find`,
`which`, `cp`, `mv`, and `rm`.
Given its design nofs is not suited for general usage as 3rd party
applications will not be able to take advantage of the unioning
behavior it offers. It is primarily for more simple situations where
something like mergerfs is unable to be used.
## policyfs
* [https://policyfs.org](https://policyfs.org)
* [https://github.com/hieutdo/policyfs](https://github.com/hieutdo/policyfs)
policyfs is a Linux FUSE storage daemon that unifies multiple storage
paths under a single mountpoint, similarly to mergerfs. Its
distinguishing features are explicit path-pattern-based routing rules
for reads and writes, and an optional SQLite metadata index that can
serve `readdir` and `getattr` operations without spinning up HDDs.
Where mergerfs applies a single policy across all operations (with
per-function overrides), policyfs lets you write explicit routing
rules matched against path patterns, giving finer-grained control over
which physical storage a particular directory subtree reads from or
writes to. The SQLite metadata index is a notable addition for
HDD-heavy setups where keeping disks spun down is a priority (though
how effective it is will depend on access patterns); mergerfs does not
have an equivalent cache (though does leverage kernel caches when
enabled). policyfs also supports deferred physical operations,
recording delete and rename events for indexed paths and applying them
later.
policyfs is a young project (first released in late 2025) and should
be evaluated accordingly for production use. mergerfs has a longer
track record, a broader policy set, and wider community adoption. If
spin-down-friendly metadata serving or explicit per-path routing rules
are important to your workload, policyfs might be an option.
## Greyhole
* [https://www.greyhole.net](https://www.greyhole.net)
* [https://github.com/gboudreau/Greyhole](https://github.com/gboudreau/Greyhole)
Greyhole is an open-source storage pooling application that works via
Samba. Rather than implementing a FUSE filesystem, it hooks into Samba
VFS to intercept file operations and distribute files across multiple
drives. Its headline feature compared to mergerfs is per-share
redundancy: you can configure how many copies of each file Greyhole
keeps, with copies spread across different physical drives to protect
against drive failure.
Because Greyhole operates through Samba, all file access must go
through Samba shares; it cannot be used as a general-purpose local
filesystem mount. mergerfs is a FUSE filesystem and works with any
application that uses normal POSIX filesystem calls. Greyhole is also
not well-suited for large numbers of small files or frequently-changing
files, and write performance is lower because files first land in a
temporary "landing zone" before being moved to the pool.
For users who need storage pooling with built-in per-file redundancy
and are already using Samba for file sharing, Greyhole provides both
in a single tool. For local filesystem pooling without Samba,
mergerfs is the more appropriate choice; redundancy can then be added
separately via SnapRAID or NonRAID.
## 9P
* [https://en.wikipedia.org/wiki/9P_(protocol)](https://en.wikipedia.org/wiki/9P_(protocol))
[9P](https://en.wikipedia.org/wiki/9P_(protocol)) is a filesystem
protocol from the Plan 9 operating system. While historically
important, it's not directly relevant for users looking to pool
mkdocs/docs/quickstart.md
+1 -1
View File
@@ -1,4 +1,4 @@
# QuickStart
# Quick Start
## Install
mkdocs/docs/remote_filesystems.md
+2 -2
View File
@@ -55,7 +55,7 @@ NFS export settings:
other software. By setting `softerr` or `soft` the NFS client will
timeout eventually and return an error.
* `softreval`: NFS client will serve up cached data after `retrans`
attempts to revalidate the data. Helps with intermitent network
attempts to revalidate the data. Helps with intermittent network
issues.
* `timeo=150`: Timeout till retrying request.
* `retrans=3`: Number of retrying a request.
@@ -122,7 +122,7 @@ line tool `uuid` or `uuidgen` or through a website such as
`no_root_squash` is required for the same reason mergerfs needs to run
as `root`. Certain behaviors of mergerfs require control over the
filesystem that only `root` can preform. If squashing is enabled, or
filesystem that only `root` can perform. If squashing is enabled, or
mergerfs was running as non-root, it would be unable to perform
certain function and you will receive permission errors.
mkdocs/docs/resource_usage.md
+3 -2
View File
@@ -23,8 +23,9 @@
value to -990.
* mergerfs increases [its available file descriptor and file size
limit.](https://www.man7.org/linux/man-pages/man3/setrlimit.3p.html)
* mergerfs lowers its [scheduling
* mergerfs sets its [scheduling
priority](https://man7.org/linux/man-pages/man3/setpriority.3p.html)
to -10 ([by default](config/options.md))
(nice value) to -10 ([by default](config/options.md)), raising its
CPU scheduling priority above the default of 0.
* The [readahead](config/readahead.md) values of mergerfs itself and
managed filesystems can be modified.
mkdocs/docs/runtime_interface.md
+3 -3
View File
@@ -35,7 +35,7 @@ configure the mounting of mergerfs (/etc/fstab, systemd, etc.).
### Command Line Tooling
Extended attributes is prevelant enough that there are common tools
Extended attributes are prevalent enough that there are common tools
available for interacting with them.
In Debian / Ubuntu distributions you can get the tools
@@ -122,14 +122,14 @@ user.mergerfs.category.search="mfs"
[trapexit:/mnt/mergerfs] $ getfattr -n user.mergerfs.category.create .mergerfs
user.mergerfs.category.search="prfd"
[trapexit:/mnt/mergerfs] $ setfattr -n user.mergerfs.branches -v "'+</mnt/c=RO .mergerfs
[trapexit:/mnt/mergerfs] $ setfattr -n user.mergerfs.branches -v '+</mnt/c=RO' .mergerfs
[trapexit:/mnt/mergerfs] $ getfattr -n user.mergerfs.branches .mergerfs
user.mergerfs.branches="/mnt/c=RO:/mnt/a=RW:/mnt/b=RW"
```
### Commands
There are a number of commands / behaviors which can be triggerd by
There are a number of commands / behaviors which can be triggered by
writing ([setfattr](https://linux.die.net/man/1/setfattr),
[setxattr](https://linux.die.net/man/2/setxattr)) particular xattr
keys of `/mountpoint/.mergerfs`. These keys do not show up in key
mkdocs/docs/tooling.md
+4 -4
View File
@@ -75,7 +75,7 @@ the read/write workflow, such as
[moveonenospc](config/moveonenospc.md), will no longer work.
Also, understand that this will only work on dynamically linked
software (a that dynamically linked with the same general libc version
software (that is dynamically linked with the same general libc version
as the software being used with it.) Anything statically compiled will
not work. Many GoLang and Rust apps are statically compiled.
@@ -83,8 +83,8 @@ The library will not interfere with non-mergerfs filesystems. The
library is written to always fallback to returning the mergerfs opened
file on error.
While the library was written to account for a number of edgecases
there could be some yet accounted for so please report any oddities.
While the library was written to account for a number of edge cases
there could be some yet unaccounted for so please report any oddities.
Thank you to
[nohajc](https://github.com/nohajc/mergerfs-io-passthrough) for
@@ -112,7 +112,7 @@ the same path as found on the host so the preload library can see
them.
**NOTE:** Since a container can have its own OS setup there is no
guarentee that `preload.so` from the host install will be compatible
guarantee that `preload.so` from the host install will be compatible
with the loader found in the container. If that is true it simply
won't work and shouldn't cause any issues.
mkdocs/mkdocs.yml
+17 -17
View File
@@ -63,8 +63,8 @@ nav:
- setup/installation.md
- setup/upgrade.md
- setup/build.md
- terminology.md
- intro_to_filesystems.md
- Terminology: terminology.md
- Intro to Filesystems: intro_to_filesystems.md
- Config:
- config/options.md
- config/deprecated_options.md
@@ -96,17 +96,17 @@ nav:
- config/export-support.md
- config/kernel-permissions-check.md
- config/lazy-umount-mountpoint.md
- error_handling_and_logging.md
- resource_usage.md
- runtime_interface.md
- remote_filesystems.md
- tips_notes.md
- known_issues_bugs.md
- project_comparisons.md
- benchmarking.md
- performance.md
- tooling.md
- extended_usage_patterns.md
- Error Handling and Logging: error_handling_and_logging.md
- Resource Usage: resource_usage.md
- Runtime Interface: runtime_interface.md
- Remote Filesystems: remote_filesystems.md
- Tips and Notes: tips_notes.md
- Known Issues and Bugs: known_issues_bugs.md
- Project Comparisons: project_comparisons.md
- Benchmarking: benchmarking.md
- Performance: performance.md
- Tooling: tooling.md
- Extended Usage Patterns: extended_usage_patterns.md
- FAQ:
- faq/why_isnt_it_working.md
- faq/configuration_and_policies.md
@@ -116,7 +116,7 @@ nav:
- faq/technical_behavior_and_limitations.md
- faq/have_you_considered.md
- faq/limit_drive_spinup.md
- related_projects.md
- media_and_publicity.md
- support.md
- sponsorship_and_donations.md
- Related Projects: related_projects.md
- Media and Publicity: media_and_publicity.md
- Support: support.md
- Sponsorship and Donations: sponsorship_and_donations.md