The ZFS 80% Rule: Why It Exists and When You Can Bend It
Ask a room of storage admins why ZFS pools slow down past 80% capacity, and you'll get a lot of confident head-nodding and not many actual answers. It's become industry folklore - repeated so often it's treated as gospel, rarely questioned.
The truth is more useful than the myth. Every filesystem pays some version of this tax eventually. ZFS just happens to name its mechanisms out loud, so it gets blamed by name.
The slowdown comes from three distinct mechanisms - fragmentation, metaslab pressure, and (on spinning disk only) LBA weighting - and how much they affect you depends entirely on your workload.
An archival backup pool with mostly sequential, write-once data? It can comfortably run at 90-95% full. A pool handling heavy random I/O for virtualization or databases? 80% might already be cutting it too close.
We wrote up the real mechanics behind the rule - including where even ZFS's own creators say it can safely bend - so you can stop guessing and start watching the metric that actually matters: performance under your actual workload.
