ZFS te da un regalo raro en producción: te dice lo que sabe y normalmente es honesto. Pero zpool status no es un chequeo de salud de sí/no; es un informe de choque, una foto de la escena y un pronóstico del tiempo en uno. Léelo como un analista forense y te salvará del peor tipo de outage: el que parece estar bien hasta que no lo está.
Esta es una guía de campo para SREs e ingenieros de almacenamiento que quieren pasar de “pool is DEGRADED, panic” a “aquí está el dominio de fallo, aquí está el radio de alcance, aquí está el siguiente comando.” Vamos a diseccionar la salida, mapear síntomas a causas raíz y recorrer tareas operativas reales—scrubs, clears, replacements, resilvers, y los momentos incómodos cuando los discos son inocentes y el cableado es el culpable.
Qué zpool status realmente es (y no es)
zpool status es una vista resumida de un sistema de almacenamiento transaccional que puede auto-sanarse, auto-diagnosticar y a veces auto-incriminarse. No es un informe SMART completo, no es un panel de rendimiento y no es un oráculo. Es un conjunto estructurado de pistas: la topología del pool, el estado de cada vdev, contadores de errores y los últimos eventos notables.
En términos forenses: es la línea de tiempo del incidente más la lista de sospechosos. Aún tienes que interrogar a los sospechosos (SMART, cableado, HBAs, multipath), reconstruir la línea de tiempo (logs de scrub/resilver) y confirmar si la “víctima” es datos, rendimiento o ambos.
Una verdad operativa: zpool status está sesgado hacia la corrección, no hacia la comodidad. Si dice “DEGRADED,” no te pide que medites; te pide que actúes, o al menos que entiendas el riesgo que has aceptado.
Anatomía de zpool status: cada línea importa
Comencemos con una salida representativa y luego la desmontaremos como un informe postmortem.
cr0x@server:~$ sudo zpool status -v
pool: tank
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: ZFS-8000-2Q
scan: scrub repaired 0B in 0 days 02:41:19 with 0 errors on Tue Dec 24 03:12:18 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ata-SAMSUNG_SSD_860... ONLINE 0 0 0
ata-SAMSUNG_SSD_860... UNAVAIL 0 0 0 cannot open
raidz1-1 ONLINE 0 0 0
ata-WDC_WD40EFRX... ONLINE 0 0 0
ata-WDC_WD40EFRX... ONLINE 0 0 0
ata-WDC_WD40EFRX... ONLINE 0 0 0
errors: No known data errorspool / state / status / action: el resumen ejecutivo
pool: es el nombre del pool. En la respuesta a incidentes, también es tu etiqueta de radio de alcance: todo lo montado desde este pool comparte destino durante un outage.
state: es la clasificación gruesa de salud. No es solo “bien/mal”; es “de cuántas formas aún puedo leer la verdad.” ONLINE significa que la redundancia está intacta. DEGRADED significa que la redundancia está comprometida pero existen réplicas suficientes para seguir sirviendo datos. FAULTED significa que el pool no puede proporcionar datos consistentes.
status: es la interpretación legible para humanos. ZFS a menudo te dirá si falta un dispositivo, si hay corrupción o si ha habido errores de I/O. No es perfecto, pero suele apuntar en la dirección correcta.
action: es la sugerencia del siguiente paso. No la trates como una galleta de la suerte; trátala como una pista de runbook. Puede recomendar zpool clear, zpool online, reemplazar un dispositivo o restaurar desde backup.
scan: la salida de scrub/resilver es tu línea de tiempo
scan: te dice si un scrub está en ejecución, terminó o si hay un resilver en curso. Esta línea responde preguntas cruciales:
- ¿Hicimos un scrub recientemente, o estamos apostando por corrupción silenciosa?
- ¿ZFS reparó algo? Si sí, ¿reparó desde paridad/mirror o solo detectó?
- ¿Hubo errores durante el scrub? “0 errors” es reconfortante; “with N errors” es una escalada.
config: la topología es el mapa de dominios de fallo
El árbol config: es la sección más importante para leer como ingeniero de almacenamiento, no como cola de helpdesk. Te dice:
- Qué tipos de vdev tienes (mirror, raidz1/2/3, special, log, cache, spare).
- Qué dispositivos leaf respaldan cada vdev.
- Qué capa está degradada (un disco leaf, un vdev entero o el pool).
Los pools ZFS son una “stripe de vdevs.” Eso significa que la disponibilidad del pool depende de cada vdev de primer nivel. Un único fallo de vdev de primer nivel puede tumbar el pool, incluso si otros vdevs están bien. Aquí es donde la gente lee “solo falta un disco” y lo traduce erróneamente a “solo un disco importa”.
errors: el final engañosamente calmado
errors: No known data errors no es lo mismo que “no pasó nada malo.” Significa que ZFS no ha identificado corrupción de datos persistente que no pudiera sanar o que permanezca después de la reparación. Aún puedes tener:
- Timeouts de I/O transitorios que incrementaron errores READ/WRITE pero no corrompieron datos.
- Errores de checksum que fueron sanados desde la redundancia (lo cual es bueno) pero siguen siendo una advertencia (lo cual también es bueno).
- Un dispositivo que desapareció y volvió, dejándote a un reboot de distancia de un mal día.
Primera broma (una que apreciarás a las 03:00): ZFS es como un buen pager—cuando está en silencio, no significa que todo esté bien, significa que no has hecho la pregunta correcta todavía.
Estados de salud: ONLINE, DEGRADED, FAULTED, UNAVAIL, SUSPENDED
Las palabras de estado de ZFS son cortas porque tienen que caber en una consola en el peor momento de tu semana. Aquí cómo interpretarlas operacionalmente.
ONLINE
ONLINE significa que el vdev/pool es accesible y la redundancia está intacta en esa capa. Aún puedes tener contadores de error acumulándose en un disco mientras permanece ONLINE. “ONLINE con errores” es un estado real del mundo y es una señal de advertencia para tu yo futuro.
DEGRADED
DEGRADED significa que ZFS ha perdido algo de redundancia pero aún puede servir datos. En un mirror, un lado puede faltar/fallar y el mirror queda DEGRADED. En RAIDZ, un disco (RAIDZ1) o dos discos (RAIDZ2) pueden faltar y el vdev RAIDZ sigue vivo, hasta que no.
Operacionalmente: DEGRADED es donde aún tienes tiempo, pero tu presupuesto de tiempo es desconocido. Depende de la carga, del tiempo de rebuild y de si los dispositivos restantes están sanos.
FAULTED
FAULTED normalmente significa que ZFS ha determinado que el dispositivo o vdev está lo suficientemente roto como para no poder usarse de forma segura. A veces es un disco. A veces es la ruta al disco. A veces es un controlador entero que salió a tomar café y nunca regresó.
UNAVAIL
UNAVAIL significa que ZFS no puede acceder al dispositivo. El disco puede haber desaparecido, el SO puede haberlo renombrado, el expander SAS puede estar fallando o multipath cambió identidades. UNAVAIL con “cannot open” es un clásico: ZFS lo intentó, el OS dijo “nope”.
SUSPENDED
SUSPENDED es el estado de “detener el mundo”. ZFS suspenderá I/O cuando continuar pondría en riesgo una corrupción mayor o cuando está viendo fallos repetidos de I/O. Esto no es un momento de “limpiar errores y seguir”; es tiempo de “estabilizar el sistema”.
READ/WRITE/CKSUM: los contadores por los que te pagan
Los tres contadores en zpool status son la forma más rápida de distinguir “disco muriendo” de “cable malo” de “rayos cósmicos” de “mal comportamiento del driver.” También suelen ser malentendidos.
READ errors
Un READ error significa que el dispositivo no devolvió los datos que ZFS solicitó. Esto puede ser un error de medio, un timeout, un reset de bus o un problema de ruta. Si el vdev tiene redundancia, ZFS puede obtener los datos de otro lugar y luego (a menudo) reescribirlos para sanar. Pero la presencia de READ errors es una señal fuerte de que algo en la pila es poco confiable.
WRITE errors
Un WRITE error significa que ZFS intentó escribir y el dispositivo no lo aceptó. Esto puede indicar medio fallando, un problema de controlador o que el dispositivo desapareció a mitad de vuelo. WRITE errors repetidos dan miedo porque a menudo preceden a que un dispositivo caiga por completo.
CKSUM errors
Los errores de checksum son ZFS haciendo lo que fue diseñado para hacer: detectar datos que no coinciden con su checksum esperado. Un CKSUM error no es “ZFS está roto”; es “ZFS encontró algo que habría sido corrupción silenciosa en otro lugar.”
Los CKSUM errors típicamente apuntan a:
- RAM mala (menos común con ECC, más común sin ECC).
- Cableado/backplane/expander defectuoso causando flips de bits o tramas perdidas.
- Problemas de firmware/driver que devuelven datos incorrectos sin errores de I/O (sí, eso pasa).
- Disco fallando que devuelve datos corruptos que aún pasan las comprobaciones internas del disco.
La gran pista: si ves CKSUM errors sin READ/WRITE errors, sospecha del camino de transporte o de la memoria antes de culpar al disco.
Segunda broma, porque nos la ganamos: Un error de checksum es ZFS diciendo educadamente, “encontré una mentira.” Es el equivalente de almacenamiento de atrapar a tu GPS sugiriéndote calmadamente conducir hacia un lago.
La línea “errors:”: cuando “No known data errors” es una trampa
Esa última línea es un resumen de si ZFS cree que hay corrupción no reparada. Puedes tener un pool con riesgo significativo y aún mostrar “No known data errors.” Escenarios comunes:
- Corrupción sanada: ZFS detectó datos malos, los reparó desde la redundancia y ahora todo es consistente. El evento aún importa porque indica un problema de fiabilidad subyacente.
- Pérdida transitoria de dispositivo: Un disco desapareció durante carga pico, los errores se incrementaron y luego volvió. Los datos pueden estar bien; la redundancia pudo haber sido estresada. Tu próximo reboot puede ser el que no vuelva limpio.
- Scrub no reciente: Si no has hecho scrub en meses, “No known data errors” solo significa “no hemos buscado a fondo.” ZFS verifica checksums en lectura; bloques fríos pueden permanecer sin verificar por largo tiempo.
Eventos, scrubs, resilvers y la línea de tiempo del dolor
zpool status muestra una pequeña línea de tiempo: estado de “scan” y a veces algunos eventos recientes. Pero el arte operativo real es correlacionar esto con logs del sistema y tu propia historia de cambios. ¿Cuándo comenzaron los errores? ¿Alguien reemplazó un cable? ¿Se actualizó firmware? ¿Comenzó un scrub justo después de un job batch intenso?
Dos mecánicas clave para recordar:
- Scrub lee todos los bloques y verifica checksums; con redundancia puede reparar corrupción silenciosa. Scrub es tu auditoría periódica.
- Resilver reconstruye la redundancia después de reemplazar/adjuntar/onlinear un dispositivo. Resilver es trabajo de recuperación, a menudo realizado mientras se sirve carga en vivo.
La velocidad de resilver y de scrub no es solo “velocidad del disco.” Depende de fragmentación, recordsize, compresión, carga concurrente y si estás tratando con RAIDZ (reconstrucción de paridad) versus mirrors (copia directa). En el mundo real, la diferencia entre un resilver de 2 horas y uno de 2 días es la diferencia entre un “ticket rutinario” y una “llamada de puente ejecutiva.”
Hechos interesantes y contexto histórico (6–10 puntos)
- ZFS fue diseñado para detectar corrupción silenciosa de extremo a extremo con checksums almacenados separadamente de los datos—por eso puede detectar errores introducidos por discos, controladores o transporte.
- “Scrub” no es solo una característica agradable; se incluyó porque los discos pueden devolver datos corruptos pero con apariencia válida mucho tiempo después de haber sido escritos.
- El modelo de vdev (stripe a través de vdevs) es la razón por la que añadir un único vdev RAIDZ aumenta capacidad pero también añade un nuevo dominio de fallo que puede derribar el pool.
- RAIDZ fue la respuesta de ZFS al problema del write hole que las implementaciones clásicas de RAID-5 podían sufrir durante escrituras parciales y pérdidas de energía.
- Los contadores de error de ZFS tratan sobre fallos observados, no predicciones SMART; puedes tener un “disco SMART perfecto” causando problemas reales de I/O en ZFS debido a un cable malo.
- Ashift existe porque los discos mienten sobre el tamaño de sector; ZFS necesita una suposición de alineación para evitar penalizaciones de read-modify-write.
- Los vdevs especiales (metadata/pequeños bloques en dispositivos rápidos) cambiaron el juego de rendimiento—pero también introdujeron una nueva forma de perder un pool si se usan sin redundancia.
- L2ARC y SLOG fueron ampliamente malentendidos al principio; muchos outages fueron causados por tratarlos como “mejoras obligatorias de velocidad” en lugar de herramientas específicas para cargas de trabajo.
- El “auto-sanado” de ZFS depende de la redundancia; sin ella, ZFS aún puede detectar corrupción pero puede no ser capaz de arreglarla—la detección sola sigue siendo valiosa para forensear.
Guion rápido de diagnóstico (chequea primero, segundo, tercero)
Esta es la secuencia “tengo cinco minutos antes de que la próxima reunión se convierta en una revisión de incidente”. El objetivo es clasificar rápidamente el problema: riesgo de disponibilidad, riesgo de integridad de datos o riesgo de rendimiento.
Primero: clasifica el dominio de fallo desde la topología
cr0x@server:~$ sudo zpool status -xv
pool 'tank' is not healthy
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.Interpretación: -x te dice si ZFS piensa que el pool está healthy; -v da detalles. Si un vdev de primer nivel está DEGRADED/FAULTED, tu riesgo es a nivel de pool. Si un único dispositivo leaf está portándose mal dentro de un vdev redundante, tienes una ventana para actuar.
Segundo: lee los contadores como un detective
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sda ONLINE 0 0 0
sdb UNAVAIL 12 3 0 cannot openInterpretación: READ/WRITE en un dispositivo faltante a menudo indica que estaba generando errores antes de desaparecer. CKSUM permaneciendo en 0 sugiere que el dispositivo está fallando por completo, no corrompiendo silenciosamente—todavía malo, pero un tipo diferente de malo.
Tercero: decide si persigues integridad o rendimiento
Si el pool está ONLINE pero las apps están lentas, no te quedes mirando zpool status como si te debiera una disculpa. Úsalo para confirmar que no hay un resilver/scrub activo y no hay una tormenta de errores, y luego cambia a latencia y profundidad de colas.
cr0x@server:~$ sudo zpool iostat -v 1 5
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 12.3T 3.2T 210 980 18.4M 92.1M
raidz1-0 12.3T 3.2T 210 980 18.4M 92.1M
sdc - - 70 340 6.1M 30.2M
sdd - - 68 320 6.0M 29.1M
sde - - 72 320 6.3M 32.8M
-------------------------- ----- ----- ----- ----- ----- -----Interpretación: Si un disco está rezagado, a menudo verás operaciones/bandwidth desparejos. Si todo está uniformemente ocupado pero la latencia es alta, la carga puede estar presionando sync, ser de bloques pequeños o sufrir un recordsize/volblocksize inapropiado.
Tareas prácticas: comandos + interpretación (12+)
Estas son cosas reales que haces en un shell cuando el pool intenta contarte una historia. Para cada tarea: ejecuta el comando, lee la salida y decide la siguiente acción.
Tarea 1: Chequeo rápido de salud en todos los pools
cr0x@server:~$ sudo zpool status -x
all pools are healthyInterpretación: Genial para checks de cron y dashboards. Si reporta unhealthy, sigue inmediatamente con zpool status -v para detalles.
Tarea 2: Vista forense completa con rutas de dispositivo y detalles de error
cr0x@server:~$ sudo zpool status -vP tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 0 days 01:10:22 with 0 errors on Mon Dec 23 02:11:40 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
/dev/disk/by-id/ata-A... ONLINE 0 0 0
/dev/disk/by-id/ata-B... ONLINE 0 0 0
errors: No known data errorsInterpretación: Usa -P para mostrar rutas completas; usa rutas by-id para evitar sorpresas por renombrado de dispositivos. Si ves /dev/sdX en un pool de producción, considera migrar a identificadores estables cuando tengas margen.
Tarea 3: Confirma qué cree ZFS que es cada disco (verdad a nivel GUID)
cr0x@server:~$ sudo zpool status -g tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
11465380813255340816 ONLINE 0 0 0
13955087861460021762 ONLINE 0 0 0Interpretación: Los GUIDs son cómo ZFS identifica internamente a los vdevs. Esto es útil cuando cambian los nombres de dispositivo o multipath hace su juego de sillas.
Tarea 4: Mapear un vdev faltante a la visión del SO de los discos
cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,TYPE,MOUNTPOINT
NAME SIZE MODEL SERIAL WWN TYPE MOUNTPOINT
sda 3.6T HGST_HUS726T4... K8G... 0x5000cca2... disk
sdb 3.6T HGST_HUS726T4... K8H... 0x5000cca2... disk
nvme0n1 1.8T Samsung_SSD... S5G... eui.002538... diskInterpretación: Si zpool status muestra un disco UNAVAIL pero lsblk no lo lista, probablemente tienes un problema físico/ruta: cable, backplane, HBA, expander, alimentación, o el disco está realmente muerto.
Tarea 5: Onlinear un dispositivo que volvió (con cuidado)
cr0x@server:~$ sudo zpool online tank /dev/disk/by-id/ata-SAMSUNG_SSD_860_EVO_S4X...
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: resilvered 12.4G in 0 days 00:03:12 with 0 errors on Tue Dec 24 10:44:01 2025Interpretación: Si el dispositivo faltó brevemente, onlinear puede desencadenar un resilver. Si el dispositivo está flapping (desapareciendo y reapareciendo), no te alegres; reemplaza el disco o arregla la ruta antes de que falle otra vez a mitad de resilver.
Tarea 6: Limpiar contadores de error después de arreglar la causa raíz
cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0Interpretación: Limpiar contadores no es “arreglar ZFS.” Es resetear el odómetro después de reparar el motor. Si limpias sin arreglar la causa, los errores vuelven—y ahora perdiste la línea de tiempo.
Tarea 7: Iniciar un scrub y vigilarlo como si te debiera dinero
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Tue Dec 24 11:02:33 2025
1.32T scanned at 1.01G/s, 412G issued at 322M/s, 12.3T total
0B repaired, 3.27% done, no estimated completion timeInterpretación: El throughput del scrub puede estar muy por debajo de la “velocidad del disco” cuando el pool está ocupado. Si ETA de scrub es “no estimated completion time,” puede significar que el sistema no puede predecir debido a tasa cambiante, no necesariamente que esté atascado.
Tarea 8: Pausar y reanudar un scrub (cuando la producción necesita aire)
cr0x@server:~$ sudo zpool scrub -p tank
cr0x@server:~$ sudo zpool status tank
scan: scrub paused since Tue Dec 24 11:10:44 2025
2.01T scanned, 0B repaired, 16.3% donecr0x@server:~$ sudo zpool scrub -w tank
cr0x@server:~$ sudo zpool status tank
scan: scrub in progress since Tue Dec 24 11:02:33 2025
2.05T scanned, 0B repaired, 16.6% doneInterpretación: Útil cuando los scrubs chocan con carga pico. Pausar no es sustituto de planificación de capacidad; es una herramienta operativa para evitar convertir una tarea de mantenimiento en un outage.
Tarea 9: Reemplazar un disco fallado en un mirror
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sda ONLINE 0 0 0
sdb FAULTED 64 0 0 too many errorscr0x@server:~$ sudo zpool replace tank sdb /dev/disk/by-id/ata-WDC_WD40EFRX-NEW_DISK
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 24 11:20:06 2025
412G scanned at 1.12G/s, 96.1G issued at 268M/s, 3.60T total
95.9G resilvered, 2.60% done, 0:23:55 to goInterpretación: En mirrors, resilver es mayormente una copia desde el lado sano. Vigila nuevos errores durante el resilver; un segundo disco fallando durante el resilver es cómo “degradado pero bien” se convierte en “restaurar desde backup.”
Tarea 10: Reemplazar un disco en RAIDZ (y entender el riesgo)
cr0x@server:~$ sudo zpool replace tank raidz1-0 sdd /dev/disk/by-id/ata-WDC_WD40EFRX-REPL
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 24 11:31:18 2025
2.14T scanned at 512M/s, 1.02T issued at 244M/s, 12.3T total
0B resilvered, 8.32% done, 11:42:10 to goInterpretación: El resilver en RAIDZ es reconstrucción, no una simple copia, y puede ser más lento y estresante. Si ya estás en RAIDZ1 con discos grandes, el tiempo de resilver es tu enemigo; trata el periodo degradado como una ventana de alto riesgo.
Tarea 11: Identificar e interpretar una situación de “too many errors”
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 14
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/projects/build-cache.binInterpretación: Esta es una clase diferente de emergencia: ZFS te está diciendo que hay errores permanentes en un objeto específico. Eso significa que la redundancia no fue suficiente en el momento de la lectura/repair, o que existía corrupción en suficientes réplicas. Tu siguiente paso es restaurar ese archivo (o dataset) desde una fuente conocida buena, y luego investigar por qué ocurrieron los CKSUM errors.
Tarea 12: Encontrar qué dataset y mountpoint poseen el archivo dañado
cr0x@server:~$ zfs list -o name,mountpoint
NAME MOUNTPOINT
tank /tank
tank/projects /tank/projectsInterpretación: Cuando ZFS reporta una ruta, confirma que mapea al dataset esperado. En entornos complejos con datasets anidados, esto te ayuda a acotar el impacto y a elegir si restaurar un solo archivo, una snapshot del dataset o algo mayor.
Tarea 13: Correlacionar la salud del pool con eventos recientes del kernel/almacenamiento
cr0x@server:~$ sudo dmesg -T | tail -n 30
[Tue Dec 24 11:05:02 2025] ata9: hard resetting link
[Tue Dec 24 11:05:03 2025] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Tue Dec 24 11:05:04 2025] sd 9:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Tue Dec 24 11:05:04 2025] blk_update_request: I/O error, dev sdb, sector 128Interpretación: Resets de enlace y timeouts a menudo implican cableado, backplane o controlador tanto como el disco. Si múltiples discos detrás del mismo HBA muestran resets al mismo tiempo, sospecha primero del componente compartido.
Tarea 14: Chequear ashift y diseño de vdev cuando el rendimiento es raro
cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|vdev_tree|type' -n | head -n 30
56: vdev_tree:
57: type: 'root'
73: type: 'mirror'
91: ashift: 12
118: ashift: 12Interpretación: ashift: 12 significa sectores de 4K (2^12). Un ashift desalineado puede causar amplificación crónica de escritura. No puedes cambiar ashift en sitio para vdevs existentes; arreglarlo es un ejercicio de rebuild/recreate, por eso diagnosticarlo temprano importa.
Tarea 15: Validar que usas IDs de dispositivo estables (prevenir drama UNAVAIL futuro)
cr0x@server:~$ sudo zpool status tank | awk '/^ *[a-z]/{print $1}' | head
tank
mirror-0
sda
sdbcr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sda|sdb' | head
lrwxrwxrwx 1 root root 9 Dec 24 10:01 ata-HGST_HUS726T4... -> ../../sda
lrwxrwxrwx 1 root root 9 Dec 24 10:01 ata-HGST_HUS726T4... -> ../../sdbInterpretación: Si tu pool está construido sobre /dev/sdX, dependes de que el orden de descubrimiento permanezca consistente. Eso está bien hasta que no. Planea una ventana de mantenimiento para reemplazar referencias de dispositivos por rutas by-id cuando sea posible (a menudo hecho durante reemplazos de disco, una hoja a la vez).
Tres mini-historias del mundo corporativo (cómo se rompen las cosas)
Mini-historia 1: El incidente causado por una suposición equivocada
Tenían una configuración “simple”: dos vdevs de primer nivel, cada uno un RAIDZ1 de discos grandes, en stripe dentro de un pool. La capacidad se veía genial en una diapositiva. La suposición—compartida de forma silenciosa entre equipos—era que “perder un disco está bien.” Era cierto en un sentido estrecho: perder un disco por vdev RAIDZ1 es sobrevivible.
El primer disco falló un lunes por la mañana. zpool status informó DEGRADED, y el equipo se movió rápido: disco nuevo pedido (bien), reemplazo planificado (bien) y un resilver comenzó tarde en la tarde (también bien). Durante el resilver, un segundo disco en el otro vdev RAIDZ1 comenzó a sacar CKSUM errors—nada dramático al principio, solo un pequeño número que parecía “ruido.” Alguien limpió los errores para dejar el dashboard en verde otra vez, porque a nadie le gusta un recuadro rojo en la revisión semanal.
Para el martes, los errores del segundo disco ya no eran ruido. Bajo la carga de rebuild, los componentes marginales dejan de ser educados. El disco cayó, el segundo vdev quedó DEGRADED, y ahora el pool estaba a un fallo más de la catástrofe—a través de dos vdevs diferentes. Un job batch arrancó (no relacionado, programado e inocente), la I/O subió y un tercer disco tuvo un fallo lo bastante largo para volverse UNAVAIL. Eso fue todo: el pool faulted porque un vdev de primer nivel se volvió indisponible, y el pool vive solo mientras su vdev menos disponible lo permita.
El postmortem fue doloroso pero productivo. La suposición equivocada no fue “RAIDZ1 sobrevive un disco,” sino tratar el pool como si tuviera un único presupuesto de paridad. En una pool stripeada, la paridad es local a cada vdev; el riesgo se acumula. La corrección no fue un script héroe. Fue una corrección de diseño: RAIDZ2 para discos de gran capacidad, scrubs programados y tratar los CKSUM errors como incidentes de primera clase, no como una métrica para limpiar.
Mini-historia 2: La optimización que salió mal
Otra compañía, otro pecado: añadieron un dispositivo SLOG para “acelerar escrituras.” La carga era una mezcla de bases de datos e ingestión de logs, y alguien había leído lo suficiente para saber “las escrituras sync son lentas; SLOG ayuda.” Verdadero, a veces. Instalaron un NVMe de consumo porque daba buenos benchmarks y procurement tenía alergia a precios “enterprise”.
Durante una semana, los gráficos se vieron geniales. La latencia bajó. El equipo se felicitó y siguió. Luego un evento de energía no relacionado golpeó el rack—nada dramático, solo un brownout corto y recuperación. Los sistemas volvieron, pero el pool no estaba contento. zpool status mostró el log vdev como FAULTED, y peor, el pool se negó a importarse limpio en un nodo. El NVMe “rápido” no tenía protección contra pérdida de energía; reconoció escrituras que nunca llegaron a medios durables.
Aquí es donde zpool status lee como un forense: el log vdev no era solo “cache opcional.” Para cargas sync, ZIL/SLOG es parte de la ruta transaccional. Un dispositivo SLOG mentiroso puede convertir un crash limpio en un problema de consistencia. La recuperación implicó quitar y reemplazar el dispositivo de log, reproducir lo que ZFS pudo y validar integridad a nivel de aplicación. El resultado no fue pérdida total de datos, pero fue el tipo de incidente que quema confianza.
La lección que anotaron (y eventualmente creyeron): las mejoras de rendimiento son cambios al modelo de fallo. Un dispositivo SLOG debe tratarse como una pequeña base de datos: alta resistencia, protección contra pérdida de energía y redundancia si la plataforma lo permite. Luego probaron con cortes de energía intencionales en laboratorio. La “optimización” era real, pero solo cuando se diseñaba como producción, no como benchmark.
Mini-historia 3: La práctica aburrida pero correcta que salvó el día
La tercera historia no es glamorosa. Trata de un equipo que ejecutaba scrubs mensuales, revisaba salidas de zpool status como parte de la higiene on-call y reemplazaba discos ante señales de advertencia tempranas en lugar de esperar una falla completa. También mantenían un pequeño inventario de discos idénticos de reemplazo en sitio. Nadie puso eso en un comunicado de prensa.
Un mes, un scrub reportó un puñado de CKSUM errors reparados en un solo disco. El pool permaneció ONLINE, y errors: No known data errors se veía reconfortante. Pero el equipo trató “reparado” como “confirmado que algo estaba mal.” Correlacionaron con logs del kernel y encontraron resets intermitentes de enlace en la misma bahía. Movieron el disco a otra bahía durante una ventana programada; los errores siguieron a la bahía, no al disco. Ese es el tipo de hecho que solo obtienes si te tomas la molestia de mirar.
Reemplazaron el conector del backplane y reinsertaron los cables. Luego corrieron otro scrub. Limpio. Los contadores de errores se quedaron en cero. Un mes después, otro disco falló por ciclo de vida normal. El pool se degradó, se insertó un reemplazo, el resilver completó y el negocio no se enteró.
La jugada salvadora no fue genial. Fue la disciplina aburrida de hacer scrubs, revisar y actuar sobre señales débiles mientras el sistema aún cooperaba. En la vida corporativa, la corrección aburrida es a menudo la forma más alta de competencia, y rara vez se recompensa hasta el día en que previene un outage.
Errores comunes (con síntomas y soluciones)
Error 1: Tratar CKSUM errors como “el disco está malo, reemplázalo” sin chequear la ruta
Síntomas: CKSUM incrementa en uno o más discos; READ/WRITE se mantienen cerca de cero; discos pasan SMART básico; errores correlacionan con picos de carga o movimiento de cables.
Solución: Revisa dmesg por resets/timeouts de enlace; inspecciona/reemplaza cables SATA/SAS; reinsertar discos; verifica la estabilidad de firmware/driver del HBA. Si los errores siguen a la bahía o puerto del controlador en vez del disco, no pierdas tiempo RMAeando discos inocentes.
Error 2: Limpiar errores para poner el monitoring en verde
Síntomas: zpool clear se ejecutó repetidamente; los contadores vuelven; nadie puede responder “¿cuándo empezó?”
Solución: Preserva evidencia. Captura zpool status -vP, logs relevantes y timestamps antes de limpiar. Limpia solo después de abordar la causa probable y preferiblemente tras un scrub que confirme estabilidad.
Error 3: Construir pools sobre /dev/sdX y sorprenderse cuando los dispositivos se mueven
Síntomas: Tras un reboot o cambio de hardware, un disco muestra UNAVAIL aunque esté presente; letras de dispositivo cambiaron; la importación se vuelve confusa.
Solución: Usa /dev/disk/by-id consistentemente. Si heredaste un pool construido sobre sdX, planea “migrar” dispositivos leaf durante reemplazos usando rutas by-id en zpool replace.
Error 4: Asumir que el resilver de RAIDZ es “solo copiar” y programarlo en horas pico
Síntomas: Resilver tarda mucho más de lo esperado; la latencia de la aplicación sube; otro disco comienza a tirar errores bajo estrés.
Solución: Trata el resilver de RAIDZ como un trabajo pesado de reconstrucción. Reduce la carga concurrente si es posible, programa ventanas de rebuild y considera añadir redundancia (RAIDZ2) para discos grandes donde las ventanas de rebuild son largas.
Error 5: Malinterpretar “No known data errors” como “no hay problema”
Síntomas: Pool se mantiene ONLINE, pero READ/WRITE/CKSUM contadores aumentan; scrubs reparan datos ocasionalmente; errores intermitentes en apps.
Solución: Investiga la tendencia. Un bloque reparado no es una crisis, pero sí una señal. Ejecuta un scrub, revisa logs y rastrea si los errores se concentran en un solo dispositivo o ruta.
Error 6: Añadir un vdev especial o SLOG sin redundancia o validación
Síntomas: Tras pérdida de dispositivo, el pool queda inservible o sufre colapso severo de rendimiento; problemas de import inesperados; cargas heavy en metadata se detienen.
Solución: Los vdevs especiales deben ser redundantes si sostienen metadata/pequeños bloques de los que depende el pool. El SLOG debe ser seguro contra pérdida de energía y apropiado para cargas sync. Valida escenarios de fallo en laboratorio.
Listas de verificación / plan paso a paso
Checklist A: Cuando ves DEGRADED
- Captura evidencia:
zpool status -vPoutput y timestamps. - Identifica la capa degradada: disco leaf, mirror/raidz vdev o vdev de primer nivel.
- Chequea contadores: ¿son errores READ/WRITE (I/O) o CKSUM (integridad/ruta)?
- Confirma visibilidad en OS:
lsblkydmesgpara resets/timeouts. - Si el dispositivo está presente pero offline/unavail: intenta
zpool onlineuna vez después de estabilizar cableado/energía. - Si el dispositivo está fallando realmente:
zpool replacecon una ruta by-id estable. - Monitorea el resilver en
zpool status; vigila nuevos errores en otros discos. - Después del resilver: ejecuta un scrub durante una ventana controlada.
- Solo entonces: considera
zpool clearpara resetear contadores para detección futura.
Checklist B: Cuando ves CKSUM errors pero el pool está ONLINE
- No reemplaces hardware a ciegas. Primero, captura
zpool status -vP. - Chequea si múltiples discos detrás de un mismo HBA/expander muestran incrementos de CKSUM.
- Inspecciona
dmesg -Tpor resets de enlace, errores de bus o timeouts. - Reinserta/reemplaza cables; reinsertar el drive; considera otra bahía.
- Ejecuta un scrub para forzar verificación y reparación:
zpool scrub. - Si CKSUM continúa en el mismo disco tras remediar la ruta: reemplaza el disco.
Checklist C: Cuando el rendimiento es malo pero el pool parece saludable
- Confirma que no hay scrub/resilver ejecutándose: línea scan de
zpool status. - Chequea actividad pool/vdev:
zpool iostat -v 1. - Busca un dispositivo lento que sesgue un vdev: ops/bw desparejos en iostat.
- Revisa presión de escrituras sync: comportamiento de la app y ajustes de datasets ZFS (sync, logbias).
- Valida ashift y diseño:
zdb -Cpara ashift y supuestos de diseño de vdev. - Solo entonces considera “mejoras de rendimiento” (SLOG, vdev especial, más vdevs)—y modela el impacto de fallos primero.
FAQ
1) Si el pool está DEGRADED, ¿mis datos ya están corruptos?
No necesariamente. DEGRADED usualmente significa que la redundancia está reducida (un disco faltante/faulted) pero los datos aún pueden servirse desde réplicas/paridad restantes. El riesgo es que un segundo fallo en el mismo vdev pueda derivar en pérdida de datos o pérdida del pool, dependiendo del layout.
2) ¿Cuál es la diferencia entre errores READ/WRITE y CKSUM?
READ/WRITE son fallos de I/O: el dispositivo no completó la operación. CKSUM significa que ZFS recibió datos pero no coincidían con el checksum esperado—a menudo implicando corrupción en tránsito, firmware o medio que devuelve datos erróneos.
3) ¿Puedo simplemente ejecutar zpool clear para arreglar un pool degradado?
No. zpool clear limpia contadores de error y algunos estados; no resucita discos faltantes ni repara causas subyacentes. Úsalo después de arreglar el problema y quieres contadores limpios para monitoreo.
4) ¿Por qué zpool status muestra “No known data errors” cuando los contadores son no cero?
Porque los contadores pueden reflejar errores transitorios que fueron recuperados vía redundancia o errores que no resultaron en corrupción permanente. Sigue siendo una señal de que algo es poco fiable y vale la pena investigar.
5) ¿Debo reemplazar un disco tan pronto vea cualquier error?
Reemplaza inmediatamente si hay READ/WRITE persistentes o un disco que se cae offline. Para CKSUM aislados, primero sospecha de cableado/backplane/HBA y verifica con logs y un scrub. Reemplaza el disco si los errores persisten tras remediar la ruta.
6) ¿Por qué mi resilver RAIDZ es tan lento?
El resilver RAIDZ puede implicar reconstruir paridad a través de muchos bloques, y compite con carga en vivo. La fragmentación y cargas de pequeños bloques lo empeoran. Los mirrors normalmente resilverizan más rápido porque copian desde una réplica superviviente.
7) ¿Qué significa “too many errors” en zpool status?
ZFS decidió que un dispositivo es lo bastante poco fiable como para marcarlo faulted. Eso puede deberse a fallos repetidos de I/O, timeouts o eventos de corrupción. La respuesta correcta es identificar si el disco está malo o la ruta está mala, y luego reemplazar/arreglar según corresponda.
8) ¿Es seguro hot-swap de discos mientras el pool está online?
A menudo sí, si tu hardware y SO lo soportan y tu procedimiento es disciplinado. El riesgo no es solo el swap—es identificar mal el disco, sacar el incorrecto o desencadenar un backplane inestable a un outage mayor. Verifica rutas by-id antes de sacar nada.
9) Si zpool status lista un archivo específico con errores permanentes, ¿qué hago?
Trátalo como pérdida de datos en ese objeto. Restaura el archivo desde una fuente conocida buena (backup, replicación, reconstrucción de artefacto), luego ejecuta scrub e investiga por qué la redundancia no lo sanó (múltiples errores de dispositivo, corrupción previa o redundancia insuficiente).
Conclusión
zpool status no es una verificación de buena onda. Es evidencia. La topología te dice qué puede fallar. Los estados te dicen qué ya falló. Los contadores te dicen cómo falló. Y la línea scan te dice qué está haciendo ZFS al respecto.
Léelo como un analista forense y dejarás de adivinar. Sabrás cuándo un disco está muriendo, cuándo un cable está mintiendo, cuándo un scrub está atrasado y cuándo una “mejora de rendimiento” silenciosamente reescribió tu modelo de fallo. En producción, eso es la diferencia entre mantenimiento rutinario y una lección muy cara.