Cada administrador de ZFS conoce la situación: el scrub mensual dispara la latencia de las aplicaciones durante días, los usuarios protestan y la tarea se va aplazando hasta que un disco falla, el resilver se arrastra y un error de checksum latente convierte una sustitución rutinaria en una restauración desde backup. El artículo de Klara Systems sostiene que el dolor del scrub no es el problema: es el diagnóstico. Un scrub es una carga de trabajo de solo lectura que se ejecuta en la clase de prioridad más baja del planificador ZIO; si esa clase mínima puede degradar la producción, el pool carece de margen de rendimiento.
El texto recorre las causas estructurales: pools dimensionados solo por capacidad y precio que trabajan al 85-95% de ocupación, lo que fragmenta el espacio y dispara el uso de gang blocks; arreglos RAIDZ amplios que ofrecen la IOPS de un solo disco por VDEV; y un diseño que olvida presupuestar las operaciones de mantenimiento (scrub, resilver, limpieza de snapshots, replicación) como parte de la carga de producción. Los parámetros del planificador (zfs_vdev_scrub_max_active, zfs_scan_vdev_limit) no resuelven la carencia: bajarlos alarga la ventana de scrub, subirlos empeora la producción.
La solución propuesta es reorganizar el diseño añadiendo VDEVs, estrechando los RAIDZ, usando mirrors y reduciendo el fill ratio. Cuando el presupuesto de hardware es rígido, se recurre a un special VDEV de SSDs o NVMe en mirror para alojar los metadatos del pool, descargando de los discos giratorios la fase de traversal de metadatos del scrub y mejorando también resilvers y rendimiento diario.