rt/mergerfs
1
0
Fork 0
mirror of https://github.com/trapexit/mergerfs.git synced 2026-10-25 18:40:18 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs: add FAQ on SMR (shingled) drives in mergerfs pools

Browse source 
Note that mergerfs itself is drive-technology agnostic, but that the
SnapRAID parity and mergerfs.balance workloads commonly paired with a
pool expose SMR write-amplification, so CMR is preferable for pool and
especially parity members.
This commit is contained in:
Adam D 2026-10-05 21:58:20 +01:00
parent 8e87bcbff2
commit 2ca3f6fcef
1 changed files with 30 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

30
mkdocs/docs/faq/reliability_and_scalability.md
View file

@ -39,3 +39,33 @@ explained in the question about scale mergerfs is mostly limited by
the tolerated cost of aggregating branches and the cost associated
with interacting with them. If you pool slow network filesystem then
that will naturally impact performance more than low latency SSDs.
## Should I avoid SMR (shingled) drives in a mergerfs pool?
mergerfs itself is only a proxy and has no opinion about the recording
technology of the underlying drives — on its own it neither helps nor
hurts an SMR (shingled) drive.
The caveat is the workloads mergerfs pools are commonly paired
with. SMR drives rewrite overlapping tracks and absorb bursts in a
small CMR cache zone; once that zone fills under sustained random or
large sequential writes, throughput can collapse to single-digit MB/s
until the drive reorganizes itself. Two common mergerfs patterns hit
exactly that:
* **[SnapRAID](compatibility_and_integration.md#can-i-use-mergerfs-without-snapraid-snapraid-without-mergerfs)
parity**: a full `sync` or `scrub` writes large, sustained streams
to the parity drive(s). On an SMR parity drive this can stretch a
sync from hours into days or cause timeouts.
* **Rebalancing** (e.g. `mergerfs.balance` moving files between
branches to even out used space — see [tooling](../tooling.md))
produces the same sustained write pattern on the destination drive.
For pool members, and especially for parity drives, prefer CMR
(conventional) drives. SMR is generally fine for cold,
write-once-read-many data that is not re-synced or rebalanced. Drive
data sheets rarely state the recording technology outright, so
community-maintained CMR/SMR lists and per-capacity
[price-per-terabyte comparisons](https://hddhunt.com/cheapest-hdd-per-tb/)
are useful when sizing large CMR drives for a pool.