Te llega la alerta a las 02:13: “pool degraded.” Entras, ejecutas zpool status y ahí está: un dispositivo tiene
algunos errores de escritura.
No son errores de checksum. No son errores de lectura. Son escrituras.
Quizá la aplicación siga en marcha. Quizá la latencia esté un poco rara. Alguien sugiere un scrub y volver a la cama.
Y así es como terminas con la caída de un dispositivo a las 09:42, justo cuando el negocio empieza a funcionar.
El patrón: por qué los errores de escritura predicen caídas
En el mundo ZFS, los errores de checksum son los que acaparan titulares. Suenan alarmantes y “de corrupción de datos”.
Pero cuando intentas predecir el siguiente evento de fallo—el que expulsa un dispositivo del pool—los errores de escritura son el canario más fiable.
Este es el patrón de fallo que aparece una y otra vez en producción:
-
Se acumulan errores de escritura pequeños e intermitentes en un dispositivo. El pool puede seguir ONLINE.
A menudo es un número de una cifra que no cambia por días y luego salta. -
Picos de latencia que correlacionan con resets de enlace (SATA/SAS), colapsos de la cola del HBA o “ayudas” del firmware.
Tus aplicaciones lo notan antes que tú—a menos que grafiques las métricas correctas. -
Los logs del kernel muestran drama en el transporte: timeouts, resets, “device offline”, “rejecting I/O”.
ZFS registra la consecuencia: I/O de escritura que no se completó con éxito. -
Un scrub no “arregla” los errores de escritura. Los scrubs verifican y reparan datos usando redundancia.
No reparan un camino de transporte ni un canal de escritura moribundo. -
El dispositivo cae bajo presión: un resilver, un snapshot send, una ventana de backup o un lunes ocupado.
El pool se degrada y el incidente empieza a costarte.
La idea clave: los errores de escritura muchas veces no son “sectores malos” al inicio. Con frecuencia son
fallos a nivel de ruta: controlador, cableado, expander, backplane, alimentación o firmware.
ZFS está informando “intenté escribir y la pila debajo no entregó”.
Si tratas eso como un contador cosmético y sigues adelante, estás apostando tu disponibilidad a que la misma ruta inestable
funcione mejor mañana bajo más carga. Eso no es valentía; es jugarte el uptime.
Una cita que aún aplica en operaciones: La esperanza no es una estrategia
— a menudo atribuida a Vince Lombardi.
Broma #1: Los discos no “fallan parcialmente” por cortesía. Lo hacen para asegurarse de que tu outage quepa bien en la invitación de una reunión.
Hechos y contexto histórico que vale la pena saber
- ZFS nació en Sun a mediados de los 2000 con checksumming de extremo a extremo como idea fundacional, no como añadido.
- Los contadores de error de ZFS son estadísticas por dispositivo vdev mantenidas por el pool; persisten tras reinicios en muchas implementaciones.
- Los primeros SATA eran problemáticos en chasis empresariales: timeouts, mal comportamiento TLER y manejo frágil de enlaces enseñaron a respetar los errores de transporte.
- SMART y ZFS ven mundos distintos: SMART a menudo informa “salud del disco” mientras ZFS informa la “realidad de I/O”, y pueden discrepar durante semanas.
- Los fallos de escritura son más “visibles” que las lecturas porque las lecturas exitosas pueden servirse desde ARC/L2ARC, ocultando problemas hasta que la caché falla.
- Los bugs de firmware en expanders y backplanes han causado outages reales al emitir resets bajo carga, provocando errores de escritura en ráfagas y offlines de dispositivos.
- Los scrubs de ZFS no son un fsck: verifican bloques y reparan desde la redundancia, pero no arreglan dispositivos inestables o HBAs defectuosos.
- El comportamiento de resilver ha evolucionado: “sequential resilver” y mejoras en OpenZFS redujeron el dolor, pero los resilvers aún amplifican enlaces débiles.
- Errores en ashift son para siempre: un dimensionamiento de sector mal alineado no crea directamente errores de escritura, pero incrementa la amplificación de escritura, empujando hardware marginal al límite.
Qué significan realmente los “write errors” en ZFS
Los tres contadores: READ, WRITE, CKSUM
zpool status normalmente muestra tres números por dispositivo: READ, WRITE y CKSUM.
No son intercambiables y no implican la misma capa.
-
READ errors: el dispositivo/ruta falló al devolver datos cuando se solicitó.
Esto puede ser fallo de medio, timeout de transporte o “device not ready”. -
WRITE errors: el dispositivo/ruta no pudo persistir los datos cuando se pidió.
Esto es comúnmente un problema de transporte o firmware del dispositivo, a veces relacionado con la alimentación. -
CKSUM errors: los datos volvieron, pero no coincidieron con su checksum.
Eso suele indicar corrupción en tránsito (cable, controlador, RAM) o medio que devuelve datos erróneos.
Por qué los errores de escritura son predictivos de caída
Un dispositivo que no puede completar escrituras de forma fiable tiende a ser expulsado primero por la pila del SO.
La mayoría de HBAs y drivers tienen un presupuesto de paciencia. Bajo carga, ese presupuesto se consume más rápido.
Cuando se acumulan timeouts, el controlador resetea el enlace. ZFS ve una I/O de escritura fallida.
Suficientes de esas, y el dispositivo es efectivamente poco fiable aunque “vuelva”.
Qué no son los errores de escritura
No son automáticamente “pérdida de datos”. Si el pool tiene redundancia (mirror/RAIDZ) y la escritura falló en un lado,
ZFS aún puede completar el grupo de transacciones de forma segura, dependiendo de qué falló y cuándo.
Tampoco son automáticamente “el disco se está muriendo”. Un porcentaje sorprendente de errores de escritura en campo son
cableado, expanders, HBAs, backplanes o distribución de energía. El disco es solo el mensajero—y ya sabemos lo que las organizaciones hacen con los mensajeros.
La coreografía de la caída (lo que verás)
La secuencia clásica para un problema de ruta SATA/SAS es:
timeouts → link reset M:N → I/O en cola abortadas → ZFS registra write errors → dispositivo marcado FAULTED o REMOVED → comienza resilver.
Cuanto más “útilmente” intente el sistema recuperar enlaces (reset storms), más caótica será la latencia.
A las aplicaciones no les importa que el dispositivo haya vuelto. Les importa que la latencia del percentil 99 se haya mudado a otro país.
Playbook de diagnóstico rápido (primero/segundo/tercero)
El objetivo en los primeros 15 minutos no es dar un seminario filosófico sobre almacenamiento.
Es responder tres preguntas:
¿Los datos están seguros ahora? ¿Cuál es la capa que falla? ¿Cuál es la próxima acción que reduce el riesgo más rápido?
Primero: confirmar estado del pool y radio de impacto
- Ejecuta
zpool status -v. Identifica el vdev y la ruta del dispositivo exactos que reportan write errors. - Comprueba si la redundancia está intacta (un mirror tiene el otro lado ONLINE, RAIDZ tiene suficiente paridad).
- Busca si hay un resilver/scrub en curso. Esos amplifican hardware débil y cambian el perfil de riesgo para los próximos 30 minutos.
Segundo: correlacionar con logs kernel de transporte
- Busca en
dmesg/journalctl -kresets, timeouts, “rejecting I/O”, “device offline”, SAS phy resets. - Si los logs gritan “link reset”, deja de debatir. Trátalo como un problema de ruta hasta que se demuestre lo contrario.
Tercero: verificar identidad del dispositivo y SMART, luego decidir reemplazo vs reparación de ruta
- Mapea el dispositivo ZFS al nodo /dev y a la bahía física (usa
zpool status,ls -l /dev/disk/by-id, herramientas de enclosure si las tienes). - Ejecuta
smartctly observa sectores realocados/pending, UDMA CRC errors, command timeouts y entradas del error log SMART. - Si SMART está limpio pero dmesg muestra resets: sospecha cable/HBA/backplane/power antes que el disco.
Regla de decisión que te mantiene empleado
Si los write errors aumentan y ves resets de transporte en la misma ventana, prioriza estabilizar la ruta.
Si no puedes estabilizarla rápido, reemplaza el componente más propenso a intermitencia (cable/puerto de backplane),
y si la plataforma es “mystery meat”, reemplaza también el disco. La mano de obra cuesta; el downtime cuesta más.
Tareas prácticas: comandos, salidas, decisiones (12+)
Estas son las tareas que realmente ejecuto. Cada una incluye qué significa la salida y qué decisión impulsa.
Los comandos se muestran para un host Linux OpenZFS típico; ajusta nombres de dispositivos a tu entorno.
Task 1: Obtener la verdad de ZFS
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
scan: scrub repaired 0B in 02:41:10 with 0 errors on Tue Dec 24 03:10:11 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX-68KNBN0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68KNBN0 ONLINE 0 7 0
ata-WDC_WD80EFAX-68KNBN0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68KNBN0 ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/data/vmstore/vm-104.img
Significado: Un disco muestra WRITE=7. El pool está DEGRADED y ZFS reporta un archivo con errores permanentes.
Esto no es “tal vez.” Algo ya falló al escribir correctamente o no pudo comprometerse.
Decisión: Trátalo como un incidente activo. Identifica si el error está aislado y es recuperable por redundancia/backup.
También inicia la investigación del transporte inmediatamente; el contador de escritura es un indicador temprano de una caída.
Task 2: Verificar la ruta exacta de dispositivo que usa ZFS
cr0x@server:~$ sudo zpool status -P tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
/dev/disk/by-id/ata-WDC_WD80EFAX_A1 ONLINE 0 0 0
/dev/disk/by-id/ata-WDC_WD80EFAX_B2 ONLINE 0 7 0
/dev/disk/by-id/ata-WDC_WD80EFAX_C3 ONLINE 0 0 0
/dev/disk/by-id/ata-WDC_WD80EFAX_D4 ONLINE 0 0 0
Significado: Ahora tienes identificadores estables. Si tu pool usa nombres /dev/sdX, corrígelo después.
Decisión: Usa la ruta by-id para SMART y para localizar el disco físico. No confíes en el orden /dev/sdX tras resets.
Task 3: Comprobar si los errores siguen aumentando
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX_A1 ONLINE 0 0 0
ata-WDC_WD80EFAX_B2 ONLINE 0 9 0
ata-WDC_WD80EFAX_C3 ONLINE 0 0 0
ata-WDC_WD80EFAX_D4 ONLINE 0 0 0Significado: WRITE subió de 7 a 9. El problema está en curso.
Decisión: Deja de “esperar y ver.” O bien quita carga, migra workloads o avanza hacia la sustitución/reparación de la ruta ahora.
Task 4: Extraer logs del kernel por resets/timeouts de transporte
cr0x@server:~$ sudo journalctl -k --since "30 min ago" | egrep -i "ata|sas|scsi|reset|timeout|offline|aborted" | tail -n 20
Dec 25 01:43:11 server kernel: ata8.00: failed command: WRITE FPDMA QUEUED
Dec 25 01:43:11 server kernel: ata8.00: cmd 61/00:08:10:3c:2a/04:00:00:00:00/40 tag 1 ncq dma 524288 out
Dec 25 01:43:11 server kernel: ata8.00: status: { DRDY ERR }
Dec 25 01:43:11 server kernel: ata8.00: error: { ICRC ABRT }
Dec 25 01:43:12 server kernel: ata8: hard resetting link
Dec 25 01:43:17 server kernel: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 25 01:43:17 server kernel: ata8.00: configured for UDMA/133
Significado: Errores ICRC y resets de enlace son clásicos de problemas en cable/conector/backplane (o ocasionalmente controlador).
Esto no es ZFS “siendo quisquilloso”. El transporte está fallando.
Decisión: Trátalo como un problema de ruta primero. Reasienta/reemplaza el cable, revisa el puerto del backplane, inspecciona la alimentación, considera firmware/driver del HBA.
Si esto es una bahía hot-swap, mueve el disco a otra ranura si es posible.
Task 5: Mapear el dispositivo al nodo del kernel y verificar su estabilidad
cr0x@server:~$ ls -l /dev/disk/by-id/ata-WDC_WD80EFAX_B2
lrwxrwxrwx 1 root root 9 Dec 25 01:10 /dev/disk/by-id/ata-WDC_WD80EFAX_B2 -> ../../sdg
Significado: El disco está actualmente en /dev/sdg. Tras resets, podría convertirse en sdf o sdh.
Decisión: Usa /dev/disk/by-id/... para todas las acciones, no /dev/sdg.
Task 6: Obtener SMART health y error log
cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i "Model|Serial|Power_On_Hours|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Error|SMART overall"
Model Family: Western Digital Red
Device Model: WDC WD80EFAX-68KNBN0
Serial Number: XXXXXXXXXXXX
SMART overall-health self-assessment test result: PASSED
Power_On_Hours: 23144
Reallocated_Sector_Ct: 0
Current_Pending_Sector: 0
Offline_Uncorrectable: 0
UDMA_CRC_Error_Count: 27
SMART Error Log Version: 1
ATA Error Count: 14Significado: El medio parece limpio (sin reasignaciones/pending), pero existen errores CRC. Los CRC correlacionan fuertemente con problemas de cableado/backplane.
Decisión: Reemplaza/reasienta los componentes de la ruta SATA/SAS. Si los CRC siguen aumentando después de eso, reemplaza el disco o el HBA.
Task 7: Comprobar si ZFS considera esto un problema transitorio de I/O o corrupción permanente
cr0x@server:~$ sudo zpool status -v tank | sed -n '1,120p'
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
config:
...
errors: Permanent errors have been detected in the following files:
tank/data/vmstore/vm-104.img
Significado: “Permanent errors” significa que ZFS no pudo auto-reparar ese bloque desde la redundancia en el momento en que se detectó.
Podría haber ocurrido durante una escritura donde la paridad no pudo actualizarse de forma segura, o la redundancia estaba comprometida.
Decisión: Restaura ese archivo/objeto desde una fuente conocida buena. Para imágenes VM, eso normalmente significa restaurar desde backup o réplica.
No asumas que un scrub revivirá datos buenos que faltan.
Task 8: Identificar si hay un scrub o resilver en progreso (y cuán doloroso es)
cr0x@server:~$ sudo zpool status tank | egrep -i "scan|resilver|scrub|repaired|errors"
scan: resilver in progress since Wed Dec 25 01:21:34 2025
1.18T scanned at 802M/s, 312G issued at 210M/s, 8.34T total
78.1G resilvered, 3.65% done, 10:44:12 to go
errors: No known data errorsSignificado: Hay un resilver en ejecución. Eso es I/O sostenido alto y una excelente forma de disparar enlaces marginales.
Decisión: Considera reducir temporalmente la carga (limitar workloads, ajustar zfs_resilver_delay si procede en tu entorno),
o programar el trabajo pesado en la ventana de menor riesgo. Si la ruta es inestable, el resilver puede no terminar limpio.
Task 9: Confirmar ashift y layout de vdev (para entender estrés y comportamiento de rebuild)
cr0x@server:~$ sudo zdb -C tank | egrep -i "ashift|raidz|mirror|vdev" | head -n 30
raidz
ashift: 12
nparity: 1
children[0]:
children[1]:
children[2]:
children[3]:Significado: ashift 12 son sectores de 4K. Bien. Si ves ashift 9 en discos modernos, estás amplificando escrituras.
Decisión: Si ashift está mal, planifica una reconstrucción/migración. No “aplanes” un error estructural mientras persigues write errors.
Task 10: Comprobar presión del ARC y errores de memoria (porque RAM mala puede imitar problemas de disco)
cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep "size|c_max|memory_throttle_count|arc_no_grow" | head
size 4 8589934592
c_max 4 17179869184
memory_throttle_count 4 0
arc_no_grow 4 0Significado: ARC no está limitando por presión de memoria. Esto no descarta problemas de RAM, pero elimina un escenario común de “el sistema se está muriendo”.
Decisión: Si sospechas memoria, revisa logs ECC (mcelog/rasdaemon) y ejecuta una prueba de mantenimiento.
No reemplaces discos para arreglar corrupción de RAM.
Task 11: Inspeccionar estadísticas de errores de I/O en el layer de bloques
cr0x@server:~$ iostat -x 1 5 /dev/sdg
Linux 6.5.0 (server) 12/25/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
3.10 0.00 1.20 12.40 0.00 83.30
Device r/s w/s rkB/s wkB/s await svctm %util
sdg 0.10 220.00 1.2 28160.0 85.40 4.10 90.20
Significado: Await alto con alta utilización puede ser “normal durante un resilver”, o puede ser reintentos repetidos por problemas de transporte.
Necesitas correlacionarlo con los logs del kernel.
Decisión: Si los picos de await coinciden con resets/timeouts en logs, escala la remediación de la ruta. Si no, esto podría ser esperado durante el rebuild,
y puedes gestionarlo limitando en lugar de reemplazar hardware de inmediato.
Task 12: Confirmar clase de driver/firmware del HBA y comportamiento de colas
cr0x@server:~$ lspci -nn | egrep -i "SAS|RAID|HBA"
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097]cr0x@server:~$ modinfo mpt3sas | egrep -i "version|firmware|srcversion" | head -n 10
version: 47.00.00.00
srcversion: 9F6C3D0F5E4D2C3A2E3A1B2Significado: Estás en un stack HBA LSI/Broadcom SAS3. Bien—usualmente sólido, a veces exigente con el firmware.
Decisión: Si muchos discos muestran write errors intermitentes, sospecha HBA/expander/firmware. ¿Un solo disco? Sospecha ese lane/cable/slot/disco.
Task 13: Comprobar impacto amplio—errores en múltiples dispositivos
cr0x@server:~$ sudo zpool status tank | awk 'BEGIN{p=0} /config:/{p=1} p && $1 ~ /(ata-|scsi-|nvme|\/dev\/disk)/ {print}'
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX_A1 ONLINE 0 0 0
ata-WDC_WD80EFAX_B2 ONLINE 0 9 0
ata-WDC_WD80EFAX_C3 ONLINE 0 0 0
ata-WDC_WD80EFAX_D4 ONLINE 0 0 0
Significado: Solo un dispositivo acumula write errors. Eso reduce la sospecha sobre componentes globales—pero no lo elimina.
Un puerto malo en un backplane sigue siendo un “componente global” disfrazado.
Decisión: Enfoca la inspección física en esa ranura/cable/ruta primero. Si varios dispositivos muestran WRITE/READ errors, amplía la búsqueda al HBA/expander/power.
Task 14: Forzar un self-test SMART controlado durante mantenimiento (no en hora punta)
cr0x@server:~$ sudo smartctl -t short /dev/sdg
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i "Self-test execution status|# 1|Completed"
Self-test execution status: ( 0) The previous self-test routine completed without error.
# 1 Short offline Completed without error 00% 23145 -Significado: El test corto pasa; aún no exime al disco de escrituras sostenidas bajo carga, pero es un dato.
Decisión: Si los errores de transporte persisten, un test SMART que pasa no exime la ruta. Sigue persiguiendo resets y contadores CRC.
Task 15: Limpiar contadores de la manera correcta (solo después de arreglar la causa)
cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX_A1 ONLINE 0 0 0
ata-WDC_WD80EFAX_B2 ONLINE 0 0 0
ata-WDC_WD80EFAX_C3 ONLINE 0 0 0
ata-WDC_WD80EFAX_D4 ONLINE 0 0 0Significado: Contadores limpiados. Esto no arregla nada; solo te da una pizarra limpia para ver si el problema reaparece.
Decisión: Limpia solo después de la remediación (reasentado de cable, movimiento de slot, actualización de firmware, reemplazo de disco), y luego monitoriza la recurrencia.
Si los contadores suben otra vez, tienes prueba—no sensaciones.
Task 16: Prueba de escritura controlada en un spare no productivo (nunca el vdev en vivo)
cr0x@server:~$ sudo fio --name=writecheck --filename=/mnt/testdisk/fio.dat --rw=write --bs=1M --iodepth=16 --numjobs=1 --size=8G --direct=1 --runtime=120 --time_based=1
writecheck: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.33
writecheck: (groupid=0, jobs=1): err= 0: pid=25191: Wed Dec 25 01:58:23 2025
write: IOPS=210, BW=210MiB/s (220MB/s)(25.2GiB/123000msec)
clat (usec): min=950, max=420000, avg=7700.12, stdev=9500.10Significado: Esto es una prueba básica de escritura sostenida. Puede exponer resets de transporte si la emparejas con la vigilancia de logs.
Decisión: Si los logs del kernel muestran resets durante un simple fio, has reproducido el problema bajo condiciones controladas.
Arregla la ruta. No culpes a ZFS por reportarlo.
Tres microhistorias corporativas del mundo real
1) Incidente causado por una suposición errónea: “SMART pasó, así que el disco está bien”
Una SaaS de tamaño mediano tenía un clúster de VM respaldado por ZFS. Un host empezó a reportar un puñado de write errors en un disco.
El ingeniero on-call hizo el movimiento clásico: smartctl mostró “PASSED”, sin reasignaciones, sin sectores pendientes.
Limpiaron los errores del pool y siguieron.
Dos días después, durante la ventana de backups, el mismo disco se cayó. El pool se degradó, comenzó un resilver y
la latencia del host pasó de “bien” a “apocalipsis de helpdesk”. El on-call vio resets de enlace SATA en los logs
pero asumió que eran efecto secundario del resilver en lugar de la causa.
Un SRE sénior finalmente miró los atributos SMART otra vez—específicamente los contadores de interfaz.
Los UDMA CRC errors habían subido de forma continua. El disco no estaba fallando al almacenar datos; fallaba en comunicarse con fiabilidad.
El resumen “passed” era técnicamente correcto y operacionalmente inútil.
La solución fue vergonzosamente simple en la buena acepción: reemplazar un único cable SATA y mover la unidad a otro puerto del backplane.
Los errores cesaron. El resilver terminó. No hubo más caídas.
La suposición equivocada no era que SMART miente. La suposición era que SMART es la verdad primaria.
En incidentes ZFS, la verdad primaria es “qué I/O no pudo completar el sistema”, y ZFS está más cerca de esa verdad que el resumen de marketing del disco.
2) Optimización que salió mal: “Más throughput” mediante tuning agresivo
Otra compañía tenía un nodo de almacenamiento que en papel parecía poco potente: muchos discos, una carga de base de datos ocupada y un equipo reacio a comprar hardware.
Hicieron lo que los ingenieros hacen cuando compras dice no: tuning.
Aumentaron recordsize sin entender el perfil de I/O, ajustaron opciones de sync en nombre del throughput,
y subieron los queue depths en la pila del controlador para “mantener los discos ocupados.” Los benchmarks mejoraron. Se hicieron diapositivas.
Producción, previsiblemente, hizo otra cosa.
Bajo carga pico, el sistema empezó a acumular write errors en dos discos detrás del mismo expander.
Los logs del kernel mostraron timeouts y resets. El tuning había incrementado la duración y la ráfaga de las escrituras, estirando
la tolerancia del expander y amplificando cualquier pequeño problema de integridad de señal. El sistema no falló de inmediato; falló intermitentemente,
lo cual es lo peor porque consume el tiempo de todos.
Revirtieron la mayor parte del tuning y reemplazaron un módulo expander/backplane marginal.
El throughput bajó un poco, la latencia de cola mejoró mucho y los write errors desaparecieron.
El equipo aprendió la lección que nadie quiere: un camino más rápido hacia el fallo sigue siendo un camino hacia el fallo.
Broma #2: “Lo optimizamos por rendimiento” a veces es solo una forma elegante de decir “hicimos el incidente futuro más eficiente.”
3) Práctica aburrida pero correcta que salvó el día: disciplina en nombres de dispositivo y reemplazos escalonados
Una organización financiera ejecutaba OpenZFS en Linux para servicios de archivos internos. No era glamuroso, pero lo trataban como un sistema serio:
nombres by-id estables en pools, bandejas etiquetadas, mapas de ranuras documentados y una política estricta de que nadie hot-swappea nada
sin una segunda persona verificando el número de serie.
Una tarde, aparecieron write errors en un solo miembro de vdev. El on-call ejecutó zpool status -P,
confirmó la ruta by-id, la mapeó a una bahía física y revisó logs: resets intermitentes en una phy.
Abrieron un ticket a facilities para una ventana de mantenimiento programada y preubicaron un cable de reemplazo y un disco spare.
Durante la ventana, movieron el disco a una nueva ranura y reemplazaron el cable. Limpiaron errores y ejecutaron un scrub.
Sin recurrencia. Ni siquiera necesitaron el disco spare, pero tenerlo a mano evitó la trampa de “lo pedimos y esperamos”.
Nadie recibió un premio por esto. Ese es el punto. Las prácticas aburridas—naming estable, etiquetado físico, control de cambios—convirtieron un outage probable
en una tarea de mantenimiento rutinaria.
Errores comunes: síntoma → causa raíz → solución
1) “WRITE errors en un disco, SMART dice PASSED”
Síntoma: ZFS muestra write errors; SMART overall-health es “PASSED”, atributos de medio parecen limpios.
Causa raíz: Inestabilidad de transporte (CRC, resets de enlace), puerto de backplane, cable, lane de expander o fallos del HBA.
Solución: Revisa logs del kernel por resets; inspecciona/reemplaza el cable; mueve el disco a otra ranura; actualiza firmware del HBA/expander; solo entonces considera reemplazo del disco.
2) “El scrub se ejecutó limpio, pero los write errors siguen subiendo”
Síntoma: El scrub reporta 0 errores, pero el contador WRITE incrementa.
Causa raíz: El scrub es de lectura; tu problema está en escrituras (o resets durante escrituras). El scrub no valida la ruta de escritura bajo tu carga real.
Solución: Correlaciona con periodos intensos de escritura; reproduce con escrituras controladas fuera de pico; estabiliza la ruta.
3) “Múltiples discos muestran WRITE errors de repente”
Síntoma: Varios miembros de vdev obtienen write errors en minutos/horas.
Causa raíz: Falla de componente compartido (HBA, expander, alimentación del backplane, PCIe, bug de firmware).
Solución: Deja de reemplazar discos como ritual. Inspecciona hardware compartido, revisa logs PCIe AER, repasa cambios recientes de firmware/kernel y considera rollback.
4) “El dispositivo se cae y vuelve; el pool hace flapping”
Síntoma: El disco pasa a FAULTED/REMOVED y luego vuelve ONLINE tras resets.
Causa raíz: Inestabilidad de enlace o intermitencia de alimentación, a veces una rail de PSU marginal hacia el backplane.
Solución: Trata el flapping como urgente. Reemplaza cable/slot/backplane; revisa conectores de energía; confirma salud de la PSU y la entrega de energía al backplane.
5) “WRITE errors después de cambiar settings de sync”
Síntoma: Tras tuning de rendimiento aparecen write errors bajo carga pico.
Causa raíz: El tuning incrementó la ráfaga/queue depth de escrituras, exponiendo debilidades del controlador/expander.
Solución: Reviértelo; vuelve a probar; añade SLOG solo si entiendes tu workload sync y tienes dispositivos de clase enterprise.
6) “Errores permanentes en archivos aun con redundancia”
Síntoma: ZFS reporta permanent errors para archivos específicos.
Causa raíz: En el momento del evento, la redundancia no pudo proveer una copia buena (múltiples errores, escrituras parciales o daño silencioso previo).
Solución: Restaura desde backup/réplica; luego investiga por qué la redundancia no te salvó (segundo dispositivo fallando, ruta inestable, mala configuración).
7) “El resilver nunca termina; los errores siguen ocurriendo”
Síntoma: El resilver se ralentiza o reinicia; los write/read errors continúan.
Causa raíz: La carga del rebuild está provocando que el fallo se repita. Es común con cables marginales, expanders o HBAs sobrecalentados.
Solución: Reduce la carga, mejora refrigeración, reemplaza el componente de ruta sospechoso y solo entonces intenta el resilver otra vez.
Listas de verificación / plan paso a paso
Contención inmediata (0–30 minutos)
- Ejecuta
zpool status -vy captura la salida en las notas del incidente. - Identifica si la redundancia está intacta. Si no, pasa a modo de protección de datos: detén escrituras, haz snapshots de lo que puedas, prepara la restauración.
- Comprueba si hay un scrub/resilver activo. Si hay resilver, espera que el sistema sea frágil.
- Extrae logs del kernel por resets/timeouts. Los errores de transporte cambian tu prioridad de “salud del disco” a “estabilidad de la ruta.”
- Mapea el dispositivo a by-id y ubicación física. No toques hardware hasta que sepas exactamente qué vas a retirar.
Aislamiento de la causa raíz (mismo día)
- Compara contadores ZFS en todos los dispositivos. Un dispositivo: probable local. Muchos: componente compartido.
- Revisa atributos SMART que indiquen problemas de ruta (CRC, timeouts), no solo sectores reasignados.
- Inspecciona/reasienta/reemplaza el cable; mueve el disco a otra ranura si el chasis lo permite.
- Revisa firmware del HBA/expander y actualizaciones recientes del kernel; las regresiones existen.
- Limpiar errores ZFS solo después de la remediación para confirmar si el problema reaparece.
Recuperación y validación (tras trabajo en hardware)
- Si se reemplazó un disco, deja completar el resilver con monitorización. No declares victoria al 3%.
- Ejecuta un scrub después del resilver para validar la redundancia y descubrir problemas de lectura latentes.
- Verifica la integridad de datos de las aplicaciones para cualquier archivo que ZFS marcó como permanent errors.
- Configura o ajusta alertas: write errors > 0 deberían generar paging en horario laboral, no esperar a que el pool se degrade.
Endurecimiento (la parte que evita repetición)
- Usa naming by-id en todos los pools. Si heredaste un pool que usa
/dev/sdX, planifica una migración controlada. - Estandariza HBAs en modo IT y mantiene firmware consistente en la flota.
- Etiqueta las bandejas con números de serie y mantiene un mapa de ranuras. Así evitas “reemplazar el disco equivocado”.
- Monitorea mensajes de reset del kernel y contadores SMART CRC junto a los contadores de error de ZFS.
- Haz scrubs periódicos programados y sigue tendencias, no solo pasa/falla.
Preguntas frecuentes
1) ¿Los write errors en ZFS siempre significan un disco fallando?
No. A menudo indican que la I/O de escritura no se completó con éxito, lo cual puede ser firmware del disco, pero muy comúnmente es
cableado, backplane, expander, HBA o alimentación. Revisa logs de transporte antes de pedir un palé de discos.
2) ¿Cuál es la diferencia entre write errors y checksum errors en ZFS?
Los write errors significan que ZFS no pudo comprometer datos en el dispositivo/ruta. Los checksum errors significan que se leyó data pero no coincidió con su checksum—
corrupción o mala entrega. Ambos son malos; apuntan a capas diferentes.
3) Si ejecuto un scrub y reporta 0 errores, ¿estoy a salvo?
Más seguro, no a salvo. El scrub es de lectura y valida datos almacenados. No prueba que tu ruta de escritura sea estable bajo tu carga real.
Si los write errors siguen incrementando, aún tienes un problema de fiabilidad de la ruta de escritura.
4) ¿Debo limpiar los errores de ZFS con zpool clear?
Sí, pero solo después de haber arreglado algo y querer validar que la solución funcionó. Limpiar como “hacer desaparecer la alerta” es cómo maduran los incidentes.
5) ¿Por qué los write errors suelen aparecer durante un resilver?
El resilver es escritura sostenida y pesada además de lecturas a través del vdev. Convierte problemas marginales de transporte en fallos obvios.
Piensa en el resilver como una prueba de estrés que no programaste.
6) Mi pool está en mirror. Si un lado tiene write errors, ¿ZFS aún puede tener éxito?
A menudo sí. Pero el mirror solo te protege si el otro lado está sano y el sistema puede completar las transacciones de forma segura.
Un dispositivo que hace flapping aún puede causar picos de latencia y riesgo operativo.
7) ¿Necesito RAM ECC para evitar write errors?
ECC es muy recomendable para ZFS, pero los write errors específicamente son usualmente fallos de finalización de I/O, no corrupción de memoria.
ECC ayuda a prevenir checksum errors y corrupción silenciosa. No arregla cables malos.
8) ¿Puede un HBA causar write errors sin problemas SMART en los discos?
Absolutamente. Si el HBA o expander resetea enlaces, maneja mal colas, se sobrecalienta o tiene bugs de firmware, ZFS verá fallos de I/O de escritura.
SMART puede verse impecable porque el disco nunca tuvo una oportunidad limpia para hacer su trabajo.
9) ¿Qué umbral de alerta debería usar para write errors?
Para la mayoría de sistemas en producción: cualquier write errors no cero en un dispositivo por lo demás sano debería disparar investigación.
Si aumentan con el tiempo, escala. Las tendencias importan más que un número aislado, pero el primer write error es la advertencia más temprana.
10) Si ZFS reporta “permanent errors”, ¿significa pérdida total de datos?
No total, pero significa que ZFS no pudo reparar ciertos bloques desde la redundancia. Los archivos/objetos afectados necesitan restaurarse desde backup o réplicas.
Luego debes averiguar por qué la redundancia no fue suficiente en ese momento.
Conclusión: pasos prácticos siguientes
Los errores de escritura en ZFS no son una estadística trivial. Son un patrón de fallo. Predicen caídas porque a menudo son la primera señal visible
de que la ruta de escritura—disco, enlace, controlador, chasis—no puede completar I/O de forma fiable bajo presión.
Haz tres cosas la próxima vez que veas WRITE > 0:
- Correlaciona inmediatamente: contadores ZFS + logs del kernel + errores de interfaz SMART. Encuentra la capa que falla.
- Estabiliza la ruta: reasienta/reemplaza cables, cambia de slot, revisa HBAs y firmware, y no dejes que un resilver siga en hardware inestable.
- Prueba la solución: limpia contadores tras la remediación y vigila la recurrencia. Si el contador vuelve a subir, deja de negociar y reemplaza componentes.
La fiabilidad del almacenamiento es principalmente negarse a sorprenderse por la misma falla dos veces.
ZFS te está dando un pronóstico. Úsalo.