Hay una razón por la que RAIDZ2 aparece una y otra vez en las conversaciones sobre “infraestructura aburrida que sobrevive”. No es llamativo ni está de moda, y no ganará carreras de benchmark contra mirrors en pequeñas I/O aleatorias. Lo que hace—cuando lo dimensionas con sensatez y lo operas con disciplina—es mantener tus datos en pie cuando un disco muere un martes y otro muestra síntomas el miércoles.
Esta es una guía de campo desde la perspectiva de alguien que ha visto pools degradarse en tiempo real, discutir con compras sobre “simplemente comprar discos más grandes” y aprender que la diferencia entre una noche de on-call tranquila y un incidente que marca la carrera suele ser una sola suposición hecha meses antes.
Qué es realmente RAIDZ2 (y qué no es)
RAIDZ2 es el RAID de doble paridad de ZFS. En términos simples: dentro de un único vdev RAIDZ, puedes perder dos discos y el vdev aún puede reconstruir los datos. ZFS stripea los datos a través de todos los discos de ese vdev, con paridad distribuida. Cuando construyes un pool a partir de uno o más vdevs RAIDZ2, la disponibilidad del pool es la disponibilidad de sus vdevs—pierde un vdev y pierdes el pool.
RAIDZ2 no es “dos discos de seguridad sin importar qué”. Es protección contra la pérdida de dispositivos y sectores ilegibles durante la reconstrucción—hasta cierto punto. No te protege contra:
- el borrado accidental (usa snapshots, replicación, backups)
- corrupción a nivel de aplicación (usa sumas de verificación, también snapshots/replicación)
- mentiras del controlador o caos en el cableado (monitoriza, prueba y mantén firmware razonable)
- error humano (lamentablemente, sigue siendo una de las principales causas de fallo)
En operaciones, la gente confunde “nivel RAID” con “seguridad de datos”. RAIDZ2 es una capa. Es una capa fuerte, pero no es toda la historia. Si solo recuerdas una cosa: RAIDZ2 te mantiene en línea durante algunas fallas de hardware; no te mantiene intacto frente a todas las fallas.
Broma #1 (corta, relevante): RAIDZ2 es como llevar una rueda de repuesto y un bote de sellador—útil. Igual no ayuda si te metes en un lago.
Por qué RAIDZ2 suele ser el punto óptimo
La mayoría del diseño de almacenamiento es una negociación entre cuatro partes que no se llevan bien: capacidad, rendimiento, resiliencia y presupuesto. Los mirrors ganan en IOPS y comportamiento de rebuild, pero te cuestan 50% de capacidad bruta. RAIDZ1 es tentador hasta que lo operas con tamaños de disco modernos y tasas reales de URE; no querrás aprender esa lección durante una ventana de resilver. RAIDZ3 es robusto pero empieza a sentirse como si pagaras un impuesto que tu perfil de riesgo puede no justificar (a menos que manejes vdevs enormes o discos muy grandes en cargas de trabajo de alta tensión).
RAIDZ2 suele quedar en el medio: “gastas” dos discos por vdev en paridad, que es una sobrecarga relativamente fija a medida que escalas el ancho del vdev. En un RAIDZ2 de 8 discos, tienes 75% usable (antes de overhead de ZFS). En uno de 10 discos, 80%. Esa es la historia de capacidad.
La historia de supervivencia es más sutil. Los discos modernos son grandes, y la reconstrucción/resilver es una caminata larga, no un sprint. Durante ese tiempo estás expuesto: cada lectura adicional es una oportunidad de descubrir un error latente; cada vibración o evento térmico es una posibilidad de que otro disco se comporte raro. RAIDZ2 suele ser el punto donde puedes tolerar una segunda sorpresa sin convertir una molestia en una catástrofe.
El rendimiento es donde la gente se sorprende. RAIDZ2 puede ofrecer un gran throughput secuencial—streaming, backups, almacenamiento de objetos grandes, flujos de trabajo multimedia, escaneos analíticos—porque estás usando muchos spindles. Pero las escrituras aleatorias pequeñas son más complejas: la paridad implica comportamiento read-modify-write en el nivel vdev. ZFS tiene mitigaciones (ancho de stripe variable, transaction groups, caching), pero la física sigue apareciendo en la reunión.
Así que “punto óptimo” suele significar: eficiencia de capacidad decente, supervivencia frente a fallos realistas, rendimiento aceptable para cargas mixtas cuando se configura correctamente, y no tan caro como para que compras empiecen a inventar adjetivos.
Hechos y contexto histórico que importan
La ingeniería de almacenamiento tiene buena memoria, sobre todo porque repetimos los mismos errores a mayor escala. Algunos hechos y contextos que moldean las decisiones sobre RAIDZ2:
- ZFS se diseñó asumiendo que los discos mienten. Las sumas de verificación de extremo a extremo fueron una respuesta a la corrupción silenciosa que era lo suficientemente común como para importar en arrays empresariales y hardware commodity.
- RAIDZ existe en parte para evitar el problema del “write hole” de RAID-5. El copy-on-write y la semántica de transacciones de ZFS cambian los modos de fallo respecto a implementaciones clásicas de RAID por hardware.
- Las capacidades de los discos crecieron más rápido que la velocidad de rebuild. Puedes comprar muchos terabytes barato; no puedes comprar tiempo durante un rebuild cuando estás leyendo casi todo el vdev.
- La matemática de URE (unrecoverable read error) pasó de teoría a informes de incidentes. Lo que antes era “improbable” se vuelve “inevitable” cuando lees decenas de terabytes bajo estrés.
- Ashift became a career-defining footgun. Advanced Format (sectores de 4K) hizo que la alineación 512e/4Kn fuera un precipicio de rendimiento en el mundo real. ZFS lo registra en la creación del vdev; no lo cambias casualmente después.
- LZ4 compression se convirtió en el predeterminado por una razón. En muchas cargas de trabajo mejora el throughput efectivo porque la CPU es más rápida que tus discos, y mueves menos bytes.
- Los scrubs solían ser “agradables de tener”. Con pools grandes, los scrubs son descubrimiento proactivo de fallos: quieres encontrar sectores malos en tu horario, no durante un resilver.
- Los debates sobre RAM ECC nunca mueren. ZFS no “requiere” ECC para funcionar, pero operadores en producción han visto corrupción de memoria hacer cosas espectaculares. El riesgo depende de la carga y la plataforma, pero descartarlo como mitología es cómo nacen los postmortems.
- NVMe cambió la arquitectura. Special vdevs, SLOG y L2ARC pueden hacer que RAIDZ2 se comporte de forma dramáticamente distinta, para bien o para mal, según cómo los despliegues.
Decisiones de diseño que deciden tu destino
1) Ancho del vdev: ¿cuántos discos por RAIDZ2?
La sobrecarga de RAIDZ2 son “dos discos”, así que vdevs más anchos mejoran la eficiencia de capacidad. Esa es la tentación. El contrapeso es el dominio de fallo y el tiempo de rebuild: un vdev más ancho significa más datos totales a leer y más discos participando, lo que incrementa tanto el potencial de rendimiento como la superficie para errores durante resilver y scrub.
En la práctica, muchas implementaciones en producción se sitúan alrededor de 6–10 discos por vdev RAIDZ2 para almacenamiento de propósito general. Vdevs más estrechos (6–8) suelen ser más amigables con el tiempo de resilver y la predictibilidad de IOPS; los más anchos (10–12+) son comunes en sistemas centrados en throughput donde puedes tolerar ventanas de mantenimiento más largas y tu postura de monitorización y repuestos es madura.
Una regla menos equivocada de lo que suena: elige un ancho que puedas reconstruir dentro de tu paciencia operativa, no dentro de las diapositivas de marketing del proveedor. Si tu rotación de on-call entra en pánico con un resilver de tres días, diseña para un resilver de un día. Si no puedes reconstruir rápido, necesitas más redundancia, mejores repuestos, o vdevs más pequeños—o las tres cosas.
2) ¿Cuántos vdevs por pool?
El rendimiento de ZFS escala más por número de vdevs que por número de discos dentro de un solo vdev para muchos patrones de I/O aleatoria. Dos vdevs RAIDZ2 de 8 discos generalmente se comportan mejor para cargas concurrentes que un vdev RAIDZ2 de 16 discos, porque tienes dos colas de asignación e I/O independientes en el nivel de vdev.
Operativamente, más vdevs también significan más componentes y más oportunidades de fallos individuales—pero eso no es automáticamente peor. Si cada vdev es más pequeño, los resilvers pueden ser más cortos y los dominios de fallo más fáciles de razonar. La clave es mantener el diseño consistente: vdevs idénticos, mismo ashift, misma clase de disco, mismo firmware, misma topología.
3) Recordsize, volblocksize y la forma de la carga
ZFS no es almacenamiento en bloque del mismo modo que un controlador RAID clásico; es un sistema de archivos y un gestor de volúmenes con muchos controles. La perilla crítica para datasets de archivos es recordsize. Un recordsize mayor puede mejorar el throughput de streaming y reducir el overhead de metadatos; un recordsize menor puede reducir la amplificación de lectura para lecturas aleatorias pequeñas.
Para zvols (iSCSI, discos de VM), te importa volblocksize. Equivocarte aquí puede crear amplificación de escritura que haga que RAIDZ2 se sienta como si trabajara en melaza. Para almacenamiento de VM, 8K–16K en volblocksize es común; para bases de datos, afina al tamaño de página y patrones de acceso. La respuesta correcta depende de la carga; la incorrecta depende de suposiciones.
4) Compresión y checksums: no opcionales, solo gestionados
La compresión (normalmente LZ4) suele ser ganancia neta incluso cuando no “necesitas” el espacio. Puede reducir la carga de I/O, lo que reduce la latencia y acelera resilver/scrub. Las checksums son la razón de ser de ZFS; no las apagues. Si te preocupa la CPU, perfílala—no adivines.
5) Special vdevs, SLOG y L2ARC: herramientas potentes, no adornos
Añadir un special vdev (metadatos y bloques pequeños en SSD) puede transformar pools RAIDZ2 que sirven muchos archivos pequeños o cargas con mucho metadato. También puede convertirse en un punto único de fallo del pool si lo construyes sin redundancia. En otras palabras: puede ser un salvador de rendimiento o un generador de interrupciones muy caras.
SLOG (dispositivo de log separado) ayuda las escrituras síncronas solo si realmente tienes escrituras síncronas. Si tu carga es asíncrona (común en muchos shares de archivos), un SLOG no hace nada. Un L2ARC puede ayudar cargas de solo lectura con working sets mayores que la RAM, pero no es magia; es una caché con su propio overhead.
Broma #2 (corta, relevante): Un SLOG para una carga asíncrona es como poner un turbo en un carrito de la compra—impresiona, pero aún lo empujas a mano.
Realidad del rendimiento: throughput, IOPS, latencia
RAIDZ2 suele ser juzgado injustamente por un benchmark que no coincide con producción. También a veces se despliega en cargas donde los mirrors hubieran sido la elección correcta. Separemos los modos.
Lecturas y escrituras secuenciales
Si empujas bloques grandes—backups, medios, archivos, flujos de replicación—RAIDZ2 puede ser excelente. Obtienes throughput agregado de múltiples discos, y la sobrecarga de paridad se convierte en una fracción menor del trabajo porque escribes stripes completos con más frecuencia.
Donde tropieza es cuando tu carga “secuencial” no es realmente secuencial: escrituras síncronas pequeñas, datasets fragmentados, o muchos escritores concurrentes pueden convertir el patrón en algo más cercano a I/O aleatoria. El comportamiento de transaction group de ZFS puede enmascarar algo de eso, hasta que no puede.
Lecturas aleatorias
Las lecturas aleatorias pueden estar bien si son cacheables. ARC (en RAM) es tu primera línea de defensa. Si tu working set cabe, el rendimiento de RAIDZ2 es básicamente “qué tan rápido pueden servirlo la CPU y la RAM”, y los discos mayormente descansan.
Si no cabe, quedas a merced de la latencia de los spindles. Más vdevs ayudan porque tienes más rutas de I/O independientes. Vdevs RAIDZ más anchos no te dan más IOPS de la manera en que añadir vdevs sí lo hace; mayormente te dan más throughput por vdev y más eficiencia de capacidad.
Escrituras aleatorias y el impuesto de paridad
Las escrituras aleatorias en RAIDZ2 pueden ser costosas porque la paridad necesita actualizarse. ZFS hace stripes de ancho variable y puede evitar el peor comportamiento del RAID clásico, pero todavía hay trabajo por hacer. Escribir pequeños bloques puede requerir leer datos/paridad antiguos y luego escribir datos/paridad nuevos. Eso implica I/O extra y latencia adicional.
En la práctica, cargas con muchas escrituras aleatorias (granjas de VM con invitados activos, logs de bases de datos, escrituras síncronas pequeñas) a menudo prefieren mirrors, o RAIDZ2 más un special vdev y ajuste cuidadoso, o un enfoque híbrido: mirrors para datos calientes, RAIDZ2 para tiers de capacidad.
Latencia: la métrica que arruina carreras
El throughput es fácil de vender; la latencia es lo que notan los usuarios. Los pools RAIDZ2 bajo presión pueden mostrar “cliffs” de latencia durante scrubs, resilvers o cuando el pool está demasiado lleno. ZFS se esfuerza, pero si tus discos están saturados y las colas crecen, la latencia sube.
El trabajo del operador es mantener suficiente margen para que eventos de mantenimiento no se conviertan en incidentes visibles para clientes. Eso significa: no ejecutes pools al 95% y luego te sorprendas cuando el rendimiento se desploma. ZFS no es único en esto; solo es honesto al respecto.
Operaciones que mantienen RAIDZ2 sano
El diseño RAIDZ2 te lleva a “sobrevivible”. Las operaciones te llevan a “aburridamente fiable”. La diferencia es la rutina.
Scrubs: dolor controlado vence al dolor sorpresa
Los scrubs leen todos los datos y verifican checksums. Sacan a la luz errores de sectores latentes mientras aún tienes redundancia. Si omites scrubs, apuestas a que el primer descubrimiento de sectores malos ocurra durante un resilver—cuando ya estás estresado y ya falta un disco.
Programa scrubs según tamaño del pool y carga. Mensual es común; pools grandes y fríos a veces escruban menos; pools críticos escruban más seguido. El cronograma correcto es el que termina de forma fiable y no destruye tu presupuesto de latencia.
Comportamiento de resilver: los rebuilds secuenciales son un mito ahora
Los rebuilds clásicos de RAID eran esencialmente “leer todo el disco”. El resilver de ZFS es más quirúrgico: reconstruye solo bloques asignados. Eso es genial para pools que no están llenos. Pero en muchas realidades corporativas, los pools están… llenos. Y “bloques asignados” se convierte en “la mayor parte del disco”.
Planifica como si los resilvers fueran largos. Asegúrate de poder detectar y reemplazar discos fallando rápidamente. Mantén spares o al menos vías de compra rápidas. En operaciones, el tiempo hasta reemplazar es una métrica de fiabilidad.
No trates SMART como una bola de cristal
Los datos SMART son útiles, pero no una garantía. Algunos discos fallan ruidosamente; otros empiezan a devolver lecturas lentas, timeouts y rarezas que aparecen como mensajes del kernel y errores de checksum en ZFS. Observa los contadores de error en zpool status y los logs del sistema. Esos son los síntomas que ZFS realmente considera.
Mantén los pools por debajo de la zona de peligro
A medida que los pools se llenan, la asignación se complica, la fragmentación aumenta y la amplificación de escritura sube. El resultado es rendimiento más lento y resilvers/scrubs más largos. Un objetivo operativo común es mantener pools por debajo de ~80% para cargas mixtas, a veces menos si te importa la latencia consistente.
Esto no es superstición. Es geometría y planificación. Cuando el espacio libre se fragmenta, ZFS tiene menos buenas opciones, así que toma opciones menos buenas con más frecuencia.
Tres mini-historias del mundo corporativo
Mini-historia 1: Un incidente causado por una suposición equivocada
La suposición: “RAIDZ2 significa que podemos perder dos discos, así que estamos seguros durante el mantenimiento.” La configuración era un clúster de virtualización de tamaño medio que almacenaba discos de VM en un pool RAIDZ2. El equipo planeó una actualización de firmware en caliente para el HBA y el backplane de discos. Lo habían hecho antes en sistemas más pequeños y no pasó nada interesante.
Actualizaron un host, reiniciaron y el pool volvió degradado: un disco no se enumeró. Sin pánico. “Podemos perder dos discos,” dijo alguien, y continuó la ventana de mantenimiento. Luego el segundo host se reinició y una ruta de disco diferente empezó a flapear. El pool pasó de degradado a muy enfadado—timeouts y luego una segunda falla de dispositivo.
En ese punto las cuentas cambiaron. RAIDZ2 puede perder dos dispositivos, pero no puede perder dos dispositivos mientras además sobrevive a un tercer dispositivo que “no falló, solo está lento y con timeouts”, más un controlador renegociando enlaces. El pool no murió al instante, pero las VM hicieron lo que hacen bajo latencia de almacenamiento: llenaron las colas de I/O, y luego el clúster empezó a fencear nodos por “almacenamiento no respondiente”.
El postmortem no fue sobre ZFS siendo malo. Fue sobre la suposición equivocada: “la pérdida de disco es binaria”. En sistemas reales, las fallas son desordenadas: conectividad parcial, tormentas de timeout y “funciona al reiniciar”. La corrección operativa no fue abandonar RAIDZ2; fue dejar de hacer mantenimiento multi-host sin un plan de validación escalonado, y tratar “degradado” como “estamos a un mal día de una semana muy larga”.
Mini-historia 2: Una optimización que salió mal
El objetivo: hacer un pool RAIDZ2 “más rápido” para archivos pequeños en un farm de builds. El equipo tenía un pool de HDDs y decidió añadir un special vdev en un único NVMe muy rápido. Los benchmarks fueron geniales. Las operaciones de metadatos volaron. Los desarrolladores aplaudieron. Alguien escribió “problema resuelto” en el ticket y lo cerró con confianza.
Luego vino la parte silenciosa: unos meses después, el NVMe empezó a lanzar errores de media. No catastróficos al principio—solo unos cuantos. Pero el special vdev no estaba en espejo. En ZFS, si un special vdev contiene metadatos y bloques pequeños, no es opcional: perderlo y puedes perder el pool, porque no encuentras tus datos sin los metadatos. El pool pasó de “rápido” a “crisis existencial” en un solo turno de on-call.
La recuperación fue dolorosa: tenían replicación, pero no lo suficientemente reciente como para dejar a todos contentos. Algunos artefactos se reconstruyeron; otros se volvieron a descargar; algunos se regeneraron. La causa raíz no fue “NVMe es poco fiable”. La causa raíz fue tratar el special vdev como caché. No lo es; es una capa.
La solución fue simple y aburrida: espejar el special vdev, monitorizarlo como ciudadano de primera clase y dimensionarlo correctamente. El rendimiento volvió, y también el sueño. La lección: cuando añades una herramienta potente a RAIDZ2, lee la etiqueta de seguridad.
Mini-historia 3: Una práctica aburrida pero correcta que salvó el día
La práctica: scrubs mensuales y alertas en errores de checksum, más una regla permanente de que “cualquier error de checksum genera un ticket”. No fue glamoroso. No recibió aplausos en planificación trimestral. Fue la disciplina que la gente llama “paranoica” hasta que la llaman “liderazgo”.
Una semana, saltó una alerta: un puñado de errores de checksum en un disco durante un scrub. El pool por lo demás estaba sano. Nadie gritaba. Los gráficos de almacenamiento no eran dramáticos. Pero el ticket recibió atención porque siempre la recibía. El on-call reemplazó el disco al día siguiente en horario laboral. El resilver terminó limpio.
Dos semanas después, otro disco en el mismo vdev falló en serio. En otra línea temporal—donde scrubs eran “lo haremos más tarde”—ese primer disco habría seguido en servicio con errores latentes. La segunda falla habría convertido el resilver en una ruleta: errores de lectura durante la reconstrucción, pérdida de datos y una reunión ejecutiva donde todos fingen que siempre quisieron mejores backups.
En cambio, RAIDZ2 hizo lo que debía: absorber fallos sin drama. El día se salvó no por heroísmos, sino por un recordatorio en el calendario y una cultura de tratar señales “pequeñas” como reales.
Tareas prácticas (comandos + interpretación)
Estas son tareas prácticas que puedes ejecutar en un sistema típico ZFS-on-Linux o illumos/FreeBSD. Ajusta nombres de dispositivos y pools. Los ejemplos de salida son ilustrativos; tu sistema diferirá.
Tarea 1: Inspeccionar salud del pool y contadores de error
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 05:12:44 with 0 errors on Sun Dec 15 03:12:44 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
errors: No known data errorsInterpretación: Te importan los contadores READ/WRITE/CKSUM y la línea de scan. Cualquier CKSUM distinto de cero merece investigación; con frecuencia indican problemas de cableado/HBA tanto como discos.
Tarea 2: Ver el layout del vdev y ashift
cr0x@server:~$ sudo zdb -C tank | sed -n '1,120p'
MOS Configuration:
vdev_children: 1
version: 5000
pool_guid: 1234567890123456789
vdev_tree:
type: 'root'
id: 0
guid: 1111111111111111111
children[0]:
type: 'raidz'
id: 0
guid: 2222222222222222222
nparity: 2
ashift: 12Interpretación: nparity: 2 confirma RAIDZ2. ashift: 12 significa sectores de 4K. Si creaste accidentalmente ashift: 9 en discos modernos, llevas una penalización de rendimiento y desgaste que no puedes “tune-lear” después.
Tarea 3: Comprobar propiedades de datasets que afectan comportamiento RAIDZ2
cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,compression,atime,sync,primarycache tank
NAME PROPERTY VALUE SOURCE
tank recordsize 128K default
tank compression lz4 local
tank atime off local
tank sync standard default
tank primarycache all defaultInterpretación: compression=lz4 suele ser bueno. atime=off evita escrituras extra para datasets de solo lectura. No pongas sync=disabled a la ligera; eso no es tuning, es apostar con fallos de energía.
Tarea 4: Medir I/O del pool en tiempo real y detectar impacto de scrub/resilver
cr0x@server:~$ sudo zpool iostat -v tank 1 5
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 72.1T 14.2T 210 480 48.2M 96.1M
raidz2-0 72.1T 14.2T 210 480 48.2M 96.1M
ata-WDC_WD120... - - 28 60 6.3M 12.1M
ata-WDC_WD120... - - 25 58 6.0M 11.5M
ata-WDC_WD120... - - 31 61 6.8M 12.4M
-------------------------- ----- ----- ----- ----- ----- -----Interpretación: Busca un disco haciendo mucho menos/más trabajo, o mostrando alta latencia en otro lugar (ve iostat/smartctl). Durante un scrub, las lecturas suben; si las escrituras también se disparan, puedes estar thrashing metadatos o lidiando con una carga ocupada.
Tarea 5: Iniciar un scrub y verificar que progresa
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
pool: tank
state: ONLINE
scan: scrub in progress since Tue Dec 23 01:05:11 2025
9.34T scanned at 1.12G/s, 3.02T issued at 371M/s, 72.1T total
0B repaired, 4.19% done, 2 days 03:14:00 to goInterpretación: Si el ancho de banda “issued” está muy por debajo de “scanned”, ARC está sirviendo datos (bueno). Si ambos son lentos, los discos son el cuello de botella. Si el ETA es absurdamente largo, investiga salud de discos y contención del pool.
Tarea 6: Limitar el impacto de resilver/scrub (tunables Linux/OpenZFS)
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_resilver_delay
2
cr0x@server:~$ echo 4 | sudo tee /sys/module/zfs/parameters/zfs_resilver_delay
4
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_scrub_delay
4Interpretación: Aumentar delays puede reducir el impacto en la latencia de producción a costa de tiempos de resilver/scrub más largos. Hazlo deliberadamente: si extiendes demasiado la ventana de exposición, puedes cambiar rendimiento por riesgo.
Tarea 7: Encontrar datasets que consumen espacio y detectar riesgo de “pool lleno”
cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint -S used | head
NAME USED AVAIL REFER MOUNTPOINT
tank/vm 38.2T 14.2T 38.2T /tank/vm
tank/backups 19.4T 14.2T 19.4T /tank/backups
tank/home 7.9T 14.2T 7.9T /tank/home
tank 65.5T 14.2T 112K /tankInterpretación: Cuando AVAIL se estrecha, rendimiento y mantenimiento sufren. Considera cuotas, reservas o expansión de capacidad antes de llegar a la fase de “todo está lento”.
Tarea 8: Comprobar fragmentación y por qué “está más lento que el año pasado” puede ser verdad
cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag,health tank
NAME SIZE ALLOC FREE CAP FRAG HEALTH
tank 86.3T 72.1T 14.2T 83% 52% ONLINEInterpretación: Alta fragmentación más alta capacidad es una mala combinación para la latencia. Aquí es donde “mantenerlo por debajo del 80%” deja de sonar a folklore.
Tarea 9: Reemplazar un disco fallando de forma segura (offline/replace)
cr0x@server:~$ sudo zpool offline tank ata-WDC_WD120...-part1
cr0x@server:~$ sudo zpool replace tank ata-WDC_WD120...-part1 /dev/disk/by-id/ata-WDC_WD120_NEWDRIVE-part1
cr0x@server:~$ sudo zpool status tank | sed -n '1,20p'
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 23 02:21:02 2025
1.18T scanned at 622M/s, 140G issued at 74.1M/s, 72.1T total
0B resilvered, 0.19% done, 5 days 06:10:00 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
replacing-0 DEGRADED 0 0 0
ata-WDC_WD120...-part1 OFFLINE 0 0 0
ata-WDC_WD120_NEWDRIVE-part1 ONLINE 0 0 0Interpretación: Observa el progreso del resilver y los contadores de error. Si el ETA es enorme, confirma que el pool no está saturado por la carga y que el disco nuevo está sano y rindiendo.
Tarea 10: Identificar discos lentos y problemas de transporte con SMART
cr0x@server:~$ sudo smartctl -a /dev/sdc | sed -n '1,60p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model: WDC WD120...
Serial Number: XXXXX
User Capacity: 12,000,000,000,000 bytes
...
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
...
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 2
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 18Interpretación: Sectores pendientes y CRC importan. Los CRC a menudo indican problemas de cableado/backplane, no “disco malo”. En incidentes RAIDZ2, mitad de la batalla es distinguir fallo de media de fallo de transporte.
Tarea 11: Comprobar eficiencia del ARC y si “añadir RAM” es la respuesta
cr0x@server:~$ sudo arcstat 1 3
time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
02:10:01 812 122 15 92 75 30 25 0 0 124G 128G
02:10:02 790 118 14 88 75 30 25 0 0 124G 128G
02:10:03 835 140 17 101 72 39 28 0 0 124G 128GInterpretación: Un miss% bajo sugiere que la caché funciona. Un miss% alto durante una carga de solo lectura sugiere que los discos están siendo golpeados. Si ARC está al tope (arcsz cerca de c) y los misses son altos, más RAM podría ayudar—si el working set es cacheable.
Tarea 12: Confirmar si realmente tienes escrituras síncronas
cr0x@server:~$ sudo zfs get -o name,property,value sync tank/vm
NAME PROPERTY VALUE
tank/vm sync standardInterpretación: standard significa “honrar peticiones de la aplicación”. Si tu carga es NFS con semántica sync o bases de datos con fsync, un SLOG puede importar. Si tu carga rara vez emite escrituras sync, un SLOG es mayormente decoración.
Tarea 13: Usar fio para comprobar comportamiento (con cuidado, fuera de pico)
cr0x@server:~$ sudo fio --name=randwrite --directory=/tank/test --size=8G --bs=4k --rw=randwrite --iodepth=16 --numjobs=4 --direct=1 --runtime=60 --time_based
...
write: IOPS=820, BW=3.2MiB/s (3.4MB/s)(192MiB/60001msec)
lat (usec): min=420, max=120000, avg=18500.12, stdev=9200.55Interpretación: Escrituras aleatorias 4K en HDD RAIDZ2 pueden verse feas; eso no es necesariamente una mala configuración. Usa esto para validar expectativas, no para ganar discusiones en Internet.
Tarea 14: Verificar estado de autoexpand y postura de expansión de dispositivos
cr0x@server:~$ sudo zpool get autoexpand tank
NAME PROPERTY VALUE SOURCE
tank autoexpand off defaultInterpretación: autoexpand afecta si un pool crece automáticamente cuando dispositivos subyacentes crecen. No te salvará de una mala planificación, pero evita sorpresas de “reemplazamos todos los discos y el pool no aumentó”.
Guía rápida de diagnóstico
Cuando el rendimiento de RAIDZ2 cae o aparecen errores, no tienes tiempo para debates filosóficos. Necesitas un bucle cerrado: confirmar síntomas, aislar la capa y decidir si estás en modo “arreglar ahora” o “monitorizar”.
Primero: establece si esto es un evento de salud o de rendimiento
- Revisa la salud del pool:
zpool status -v. Cualquier estado DEGRADED/FAULTED, resilver en progreso o errores de checksum cambia prioridades de inmediato. - Revisa si hay scrub/resilver activo: la línea scan en
zpool status. Si sí, espera rendimiento reducido; decide si throttlear o reprogramar. - Revisa espacio y fragmentación:
zpool list -o cap,fragyzfs list. Un pool lleno puede hacerse pasar por “hardware más lento”.
Segundo: identifica la capa que es cuello (CPU, RAM, discos o red)
- Presión en disco/vdev:
zpool iostat -v 1. Busca ancho de banda desigual por disco o un vdev pegado a su límite. - Espera I/O del sistema y colas:
iostat -x 1yvmstat 1. Await alto y util cerca del 100% sugiere discos saturados o un disco lento. - Comportamiento ARC/caché:
arcstat(o equivalente). Misses altos en carga de lectura significan que los discos están trabajando de verdad. - Red (si aplica):
nfsstat,ss -s, contadores NIC. La “lentitud” del almacenamiento a veces son retransmisiones y bufferbloat disfrazados de disco.
Tercero: determina si hay un actor malo único
- Busca errores de checksum/lectura/escritura por dispositivo:
zpool status. - Comprueba SMART por sectores pendientes o CRC:
smartctl -a. CRC altos gritan “cable/backplane”. Sectores pendientes gritan “media”. - Revisa logs del kernel:
dmesg -Tojournalctl -kpara resets de enlace, timeouts y errores SCSI.
Punto de decisión: qué hacer ahora mismo
- Si la salud del pool está comprometida: detén cambios riesgosos, reduce carga si puedes y planifica reemplazo de disco o arreglo de transporte. Ajustar rendimiento no es la prioridad.
- Si el pool está lleno/fragmentado: libera espacio, añade capacidad o migra datos. No puedes tunear geométricamente.
- Si un disco está lento: trátalo como fallo en progreso. RAIDZ2 maneja discos muertos mejor que a medios muertos.
- Si es desajuste de carga: considera mirrors para tiers calientes o añade vdevs para aumentar paralelismo.
Errores comunes: síntomas y soluciones
Error 1: vdevs RAIDZ2 sobredimensionados por “eficiencia de capacidad”
Síntomas: resilvers eternos; scrubs que llegan a horas de negocio; colapso de rendimiento durante mantenimiento; eventos de estrés multi-disco más frecuentes.
Solución: prefiere más vdevs de ancho moderado en lugar de un vdev muy ancho; mantén capacidad de repuesto; planifica expansión añadiendo otro vdev RAIDZ2 en lugar de ampliar uno existente (a menos que tengas una función de expansión verificada y un proceso probado).
Error 2: Tratar special vdev como caché y dejarlo sin espejo
Síntomas: todo es rápido hasta que deja de serlo; un error en el dispositivo especial amenaza todo el pool; comportamiento aterrador al importar el pool tras problemas en SSD.
Solución: espeja dispositivos del special vdev; monitorízalos; dimensiona para crecimiento de metadatos; trátalos como almacenamiento crítico, no como aceleración opcional.
Error 3: Ejecutar demasiado cerca del 100% y llamarlo “eficiente”
Síntomas: latencia creciente, eliminaciones lentas, largos tiempos de sync de transaction groups, scrubs/resilvers muy lentos.
Solución: aplica cuotas, archiva snapshots viejos, añade capacidad antes, y mantén margen operativo. Si necesitas 90%+ de utilización, diseña una tier para eso y acepta rendimiento degradado.
Error 4: ashift incorrecto, descubierto tras el go-live
Síntomas: rendimiento de escritura inexplicablemente bajo; mayor utilización de discos; preocupaciones por desgaste de SSD; “era más rápido en staging” confusión.
Solución: ashift no se puede cambiar en el sitio para vdevs existentes. La solución real es rebuild/migrar: replica a un pool creado correctamente y cortar al nuevo.
Error 5: Deshabilitar sync para “arreglar” latencia
Síntomas: la latencia de escritura mejora; más tarde, tras un apagón o evento de energía, aplicaciones reportan corrupción, transacciones perdidas o discos de VM inconsistentes.
Solución: deja sync=standard a menos que entiendas y aceptes el trade-off de durabilidad. Si las escrituras sync son el cuello, considera un SLOG en SSD con protección contra pérdida de energía, o mueve cargas sync-heavy a mirrors.
Error 6: Ignorar errores de checksum porque “sigue ONLINE”
Síntomas: incrementos ocasionales en CKSUM; errores intermitentes en clientes; luego, cascada de fallos de dispositivo durante un scrub/resilver.
Solución: investiga temprano. Revisa cableado, firmware HBA, backplane y SMART. Reemplaza componentes sospechosos antes de que el pool esté bajo estrés de reconstrucción.
Listas de verificación / plan paso a paso
Checklist de planificación: elegir geometría RAIDZ2
- Define la carga: ¿mayoritariamente secuencial, mayormente aleatoria, con muchas syncs, con metadatos pesados, mixta?
- Elige un techo de utilización objetivo (p. ej., 75–80% para cargas mixtas sensibles a latencia).
- Escoge ancho de vdev según tolerancia a rebuild y postura de riesgo (a menudo 6–10 discos por vdev RAIDZ2).
- Elige número de vdevs para cubrir necesidades de IOPS/paralelismo.
- Decide special vdev (espejado) si hay muchos metadatos/archivos pequeños; decide SLOG solo si las escrituras síncronas son reales.
- Configura ashift correctamente en la creación para el medio real (asume 4K mínimo; considera 8K/16K para algunos SSDs donde aplique).
- Establece defaults sensatos:
compression=lz4,atime=offdonde aplique,recordsize/volblocksizeajustados. - Planifica scrubs, alertas y un runbook probado de reemplazo de discos.
Plan de construcción: crear un pool RAIDZ2 (ejemplo)
Solo ejemplo—verifica IDs de dispositivo y particionado. Usa rutas by-id estables.
cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ata-|nvme-' | head
cr0x@server:~$ sudo zpool create -o ashift=12 tank raidz2 \
/dev/disk/by-id/ata-DISK1-part1 \
/dev/disk/by-id/ata-DISK2-part1 \
/dev/disk/by-id/ata-DISK3-part1 \
/dev/disk/by-id/ata-DISK4-part1 \
/dev/disk/by-id/ata-DISK5-part1 \
/dev/disk/by-id/ata-DISK6-part1 \
/dev/disk/by-id/ata-DISK7-part1 \
/dev/disk/by-id/ata-DISK8-part1Interpretación: Esto crea un vdev RAIDZ2 de 8 discos. Para más rendimiento, típicamente añades otro vdev similar más tarde, no ensanchas el existente.
Plan operativo: scrub mensual y flujo de alertas
- Programación: ejecutar
zpool scrubfuera de horas pico. - Monitorización: alertar ante cualquier cambio no cero en
READ/WRITE/CKSUMy al completar scrubs con errores. - En caso de error: abrir ticket, capturar
zpool status -v, logs del kernel y datos SMART. - Remediación: arregla transporte primero (CRC/resets de enlace), luego reemplaza discos con sectores pendientes/reallocados o timeouts repetidos.
- Verificación: re-scrub si hace falta y confirma que los contadores de error se estabilizan.
Plan de expansión de capacidad: añadir un nuevo vdev RAIDZ2
El patrón normal de crecimiento ZFS es añadir vdevs. Mantienes la geometría existente y añades paralelismo.
cr0x@server:~$ sudo zpool add tank raidz2 \
/dev/disk/by-id/ata-NEWDISK1-part1 \
/dev/disk/by-id/ata-NEWDISK2-part1 \
/dev/disk/by-id/ata-NEWDISK3-part1 \
/dev/disk/by-id/ata-NEWDISK4-part1 \
/dev/disk/by-id/ata-NEWDISK5-part1 \
/dev/disk/by-id/ata-NEWDISK6-part1 \
/dev/disk/by-id/ata-NEWDISK7-part1 \
/dev/disk/by-id/ata-NEWDISK8-part1
cr0x@server:~$ sudo zpool status tankInterpretación: Ahora tienes dos vdevs RAIDZ2. La I/O aleatoria generalmente mejora porque las asignaciones pueden repartirse entre vdevs.
FAQ
1) ¿RAIDZ2 es “suficiente” para discos grandes (16–24TB)?
Con frecuencia sí—si mantienes anchos de vdev razonables, haces scrubs regularmente y reemplazas discos sospechosos rápido. Con discos muy grandes y vdevs muy anchos, RAIDZ3 se vuelve más atractivo. La cuestión real es operativa: ¿cuánto dura tu ventana de exposición durante un resilver, y qué tan confiado estás en evitar un tercer modo de fallo (timeouts, UREs, resets de transporte) durante esa ventana?
2) RAIDZ2 vs mirrors para almacenamiento de VM: ¿qué elegir?
Si la carga de VM tiene muchas escrituras aleatorias y es sensible a latencia, los mirrors suelen ganar. RAIDZ2 puede funcionar para VMs, pero es menos indulgente y puede necesitar más vdevs, special vdevs en SSD, ajuste cuidadoso de volblocksize y suficiente RAM. Si quieres la respuesta simple y predecible: mirrors para tiers calientes; RAIDZ2 para capacidad o tiers fríos.
3) ¿Cuál es un buen ancho RAIDZ2?
Para cargas mixtas en HDDs, 6–10 discos por vdev RAIDZ2 es un rango práctico común. Los más estrechos tienden a reconstruirse más rápido y comportarse mejor bajo I/O aleatoria; los más anchos mejoran eficiencia de capacidad y throughput secuencial. Si no conoces bien tu carga, no construyas un RAIDZ2 de 14 discos esperando que la monitorización te salve.
4) ¿Necesito un SLOG con RAIDZ2?
Sólo si tienes escrituras síncronas significativas. Muchas cargas de archivos son mayormente async; un SLOG no ayudará. Para NFS con semántica sync, bases de datos con fsync o almacenamiento de VM con escrituras sync, un SLOG en SSD con protección contra pérdida de energía puede reducir latencia. Pero debe ser la clase de dispositivo adecuada; SSDs de consumo sin PLP pueden empeorar las cosas.
5) ¿La compresión LZ4 ralentiza?
Usualmente no, y a menudo acelera. LZ4 es rápido y al escribir menos bytes reduces trabajo de disco—especialmente útil en HDD RAIDZ2. Hay casos límite (media ya comprimida, sistemas con CPU limitada), pero la postura por defecto en producción es “habilitar LZ4 salvo razón medida para no hacerlo”.
6) ¿Por qué veo errores de checksum pero SMART dice PASSED?
Porque SMART “PASSED” es una autoevaluación tosca, no una garantía. Los errores de checksum a menudo apuntan a problemas de transporte (cables malos, backplane inestable, problemas de HBA) además de la media. Trata errores de checksum repetidos como reales: captura zpool status, revisa UDMA_CRC_Error_Count y lee logs del kernel por resets de enlace.
7) ¿Puedo expandir un vdev RAIDZ2 existente añadiendo un disco?
Históricamente, la expansión de RAIDZ no estaba disponible en muchas implementaciones; OpenZFS más reciente ha introducido funciones de expansión RAIDZ, pero la madurez operativa varía por plataforma y versión. En muchos entornos productivos, el método conservador y ampliamente usado sigue siendo: añadir un nuevo vdev (otro grupo RAIDZ2) al pool. Si planeas usar expansión, pruébala en staging que refleje producción y planea una historia de rollback.
8) ¿Qué tan lleno es “demasiado lleno” para un pool RAIDZ2?
Depende, pero para cargas mixtas donde la latencia importa, trata ~80% como línea amarilla, no como objetivo. Si operas más alto, espera más fragmentación y peor latencia cola, además de scrubs/resilvers más lentos. Para pools fríos de archivo con acceso mayormente secuencial puedes empujar más, pero estás intercambiando confort operativo por uso de capacidad.
9) ¿Cuál es el mayor riesgo operativo con RAIDZ2?
No es la segunda falla de disco—that es la que planificaste. Los mayores riesgos son ventanas de exposición extendidas durante resilver, “medios medio-fallidos” (timeouts y resets de transporte) y operar pools demasiado llenos asumiendo que la paridad te salvará de todo. RAIDZ2 compra tiempo; no compra inmunidad.
Conclusión
RAIDZ2 es popular en producción por la misma razón que una buena rotación de pagers es popular: acepta la realidad. Los discos fallan. También se comportan mal, se ralentizan y ocasionalmente engañan a tu monitorización hasta el peor momento posible. RAIDZ2 no previene el drama, pero te da margen para responder sin convertir un disco malo en un titular de pérdida de datos.
El “punto óptimo” viene con condiciones. Mantén anchos de vdev sensatos. Añade vdevs para escalar rendimiento. Scrubea según calendario. Trata los errores de checksum como señales, no como trivia. No llenes el pool hasta el borde y luego culpes a ZFS por la física. Haz eso, y RAIDZ2 se convierte en lo que debe ser: almacenamiento poco llamativo que sigue presentándose a trabajar.