From 2ca3f6fcef3ddaa07818967412d2cf26013de108 Mon Sep 17 00:00:00 2001 From: Adam D Date: Mon, 5 Oct 2026 21:58:20 +0100 Subject: [PATCH] docs: add FAQ on SMR (shingled) drives in mergerfs pools 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. --- .../docs/faq/reliability_and_scalability.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/mkdocs/docs/faq/reliability_and_scalability.md b/mkdocs/docs/faq/reliability_and_scalability.md index 4158c8c6..0b7ec92e 100644 --- a/mkdocs/docs/faq/reliability_and_scalability.md +++ b/mkdocs/docs/faq/reliability_and_scalability.md @@ -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.