If Scrubs Hurt, Your ZFS Design Is Broken - Klara Systems Skip to content Home Resources Articles If Scrubs Hurt, Your ZFS Design Is Broken
If Scrubs Hurt, Your ZFS Design Is Broken<br>July 22, 2026ZFS scrub performance shouldn’t come at the expense of production worklaods. If scrubs cause latency or downtime, your pool lacks the IOPs and metadata performance needed for healthy maintanance. Learn why scrub performance suffers, how pool design contributres to the problem, and how metadata offload with sepcial VDEVs can improve both scrub and resilver performance.
Enter your email address to subscribe to Klara's newsletter.*
Key Article Takeaways<br>ZFS scrub performance reflects pool health. If scrubs noticeably impact production, it's a sign your storage design lacks the IOPS and headroom needed for routine maintenance.<br>Pool design matters as much as capacity. High fill ratios, fragmented pools, and wide RAIDZ VDEVs increase metadata overhead, making scrubs and resilvers significantly slower.<br>Special VDEVs reduce maintenance impact. Offloading metadata—and optionally small blocks—to mirrored SSDs or NVMe devices improves scrubs, resilver, and day-to-day filesystem performance without redesigning the entire pool.
Allan Jude
Did you know?Improve the way you make use of ZFS in your company.<br>Did you know you can rely on Klara engineers for anything from a ZFS performance audit to developing new ZFS features to ultimately deploying an entire storage system on ZFS?<br>ZFS Support ZFS Development
Additional Resources<br>Here are more interesting articles on ZFS that you may find useful:<br>ZFS vs Ceph: Do You Actually Need Ceph?<br>Using Object Storage with OpenZFS and SeaweedFS<br>Managing Cache and DirectIO for Databases on ZFS<br>Why ZFS Is the Ideal Filesystem for Multi-User/Department Media Production<br>Which ZFS Storage Metrics Matter for Database Performance<br>View More Articles
Every ZFS operator has had this conversation. The regularly scheduled monthly ZFS scrub is running and application latency doubles for the next two days. Workloads slow, monitoring alerts, users complain. You move the scrub to a quarterly schedule, then to “before the audit,” then to never. Twelve months later a disk fails, the resilver crawls for a week, and a latent checksum error on a second disk turns a routine replacement into a restore-from-backup incident.<br>When Maintenance Becomes the Outage<br>Delaying the scrub is rational from the operator’s chair. The scrub visibly hurts production, and the value it delivers is invisible until the day it saves you. What gets missed is what the pain is telling you. A scrub is a read-only workload that runs at the lowest I/O priority ZFS has. If the lowest-priority class in the scheduler can push your application into unacceptable latency, the pool has no performance headroom at all. The scrub did not create that condition. It measured it.<br>If the simple act of reading all the data in the storage system causes enough performance impact to degrade protection, that is the canary in the coal mine trying to save you from what comes next.<br>What a Scrub Actually Does<br>A scrub walks every allocated block in the pool and verifies its checksum against the block pointer that references it. On a healthy pool it finds nothing. On an unhealthy pool it finds bit rot, failing sectors, and misdirected writes while you still have the redundancy to repair them, which is the entire point.<br>Since OpenZFS 0.8, scrubs run in two phases. The first phase traverses the pool’s metadata, the tree of indirect blocks and dnodes that describes where everything lives on disk, and builds a sorted list of block ranges in memory. The second phase issues those ranges as large sequential reads. This was a major improvement over the old block-pointer-order scrub, which hammered spinning disks with many small random reads for the entire run. But the first phase is still bound by metadata traversal, and on a fragmented pool full of small blocks, that traversal is a random-read workload no sorting can fix.<br>Scrub I/O is also explicitly deprioritized. The ZIO scheduler caps in-flight scrub reads (zfs_vdev_scrub_max_active) and throttles the amount of outstanding bytes to be read (zfs_scan_vdev_limit) per VDEV. Operators who feel scrub pain usually reach for these knobs first, and for zpool scrub -p to pause the run during business hours:<br># zpool status tank
scan: scrub in progress since Sat Jul 11 02:00:14 2026
18.4T / 214T scanned at 312M/s, 9.1T / 214T issued at 154M/s
0B repaired, 4.25% done, 16 days 02:11:32 to go A 16-day estimate on a 214TB pool is the number that starts the “can we skip this month” conversation. Turning the tunables down makes the estimate worse. Turning them up makes production worse. The knobs are not the problem. The pool was designed without room for this workload.<br>Where the Sizing Went Wrong<br>Pools that suffer during scrubs were almost always sized by two numbers: usable terabytes and price. The workloads that keep a pool...