Errores de lectura en ZFS: ¿disco, cable o controlador?

Un modelo mental: lo que ZFS puede probar vs. lo que solo puede sugerir

ZFS es un sistema de almacenamiento con recibos. Cada bloque tiene un checksum; los metadatos están protegidos; la redundancia (mirror/RAIDZ)
permite que ZFS se autocorrija leyendo una copia buena y reparando la mala. Esa es la parte que la gente recuerda.

La parte que la gente olvida: ZFS se sienta encima de una pila de I/O que incluye controladores, firmware, un controlador (HBA/tarjeta RAID en modo IT),
un backplane, cables, alimentación y finalmente el propio controlador y medio del disco. Si alguna capa miente, reintenta, hace timeout o devuelve datos corruptos
mientras aún dice éxito, ZFS lo detectará (mismatch de checksum) pero no necesariamente sabrá dónde se corrompió.

Así que trata los errores de ZFS como evidencia en una escena del crimen:

• ZFS puede probar que los datos no coincidieron con el checksum. No puede probar dónde ocurrió la corrupción.
• ZFS puede contar errores de I/O por dispositivo. No puede garantizar que la etiqueta del dispositivo corresponda a un disco físico si tu cableado es caótico.
• ZFS puede reparar si existe redundancia y la falla es transitoria. No puede reparar si has perdido redundancia y la única copia está dañada.

Operativamente, quieres responder tres preguntas con rapidez:

1. ¿La integridad de los datos está en riesgo ahora mismo (más de lo que tolera tu redundancia)?
2. ¿La falla está localizada (un disco) o es sistémica (ruta/controlador/backplane/energía)?
3. ¿Cuál es la acción más segura que mejora las probabilidades de inmediato?

Una regla útil: reemplaza componentes solo después de haber reducido la incertidumbre. Cambiar lo equivocado es como crear
“problemas nuevos”: por ejemplo, mover un cable marginal y convertir un enlace inestable en uno muerto.

READ vs CHECKSUM vs WRITE: qué indica cada error

Errores READ: el dispositivo no entregó los datos solicitados

Un error READ en zpool status es ZFS diciendo “le pedí bytes al dispositivo de bloques y me devolvió un error.”
Ese error podría venir del disco (error de medio, reinicio interno), del enlace (errores CRC que provocan comandos abortados),
del controlador/controlador de dispositivo/drivers (timeouts, resets), o de eventos de energía. No es tan específico como la gente espera.

Si los errores READ están aislados a un dispositivo y los registros del SO muestran que ese dispositivo reporta errores de medio, el disco es un sospechoso principal.
Si los errores READ saltan entre discos detrás del mismo puerto HBA, el enlace o el controlador se vuelven más interesantes.

Errores CHECKSUM: los datos llegaron, pero estaban equivocados

Los errores CHECKSUM son la tarjeta de presentación de ZFS. El dispositivo devolvió datos con éxito, pero el checksum no coincidió.
Si existe redundancia, ZFS intentará con otras réplicas/paridad y corregirá la copia mala. Si no, tu “lectura exitosa” te acaba de entregar corrupción.

Los errores de checksum a menudo implican la ruta: cables SAS/SATA defectuosos, un backplane inestable o un controlador haciendo algo “creativo.”
También pueden ser causados por problemas de RAM, pero si ejecutas ZFS sin ECC y ves errores de checksum, eso no es “mala suerte”—
es motivo para revisar el diseño.

Errores WRITE: el dispositivo se negó a aceptar datos

Los errores de escritura son más directos: ZFS intentó escribir y la ruta del dispositivo devolvió fallo.
Los errores de escritura persistentes suelen señalar a un dispositivo o ruta que está muriendo o desconectándose intermitentemente.

El patrón que debe cambiar tu postura de inmediato:
errores de checksum en varios dispositivos a la vez. Eso no es “dos discos fallando juntos.”
Eso es “algo compartido se está comportando mal.”

Broma #1: RAID no es una copia de seguridad, y tampoco lo es “nunca hemos tenido un problema.” Eso es solo un deseo con una hoja de cálculo.

Hechos interesantes y contexto histórico (lo que explica las rarezas actuales)

• ZFS se creó en Sun para acabar con la corrupción silenciosa de datos. El diseño de checksum en todo fue una respuesta directa a pilas de almacenamiento que “confiaban en el disco.”
• Los primeros SATA ganaron la reputación de “simplemente funcionan” hasta que no fue así. El cableado y los conectores SATA de consumo no fueron pensados para chasis densos con vibración.
• SAS se diseñó con topologías de expander/backplane en mente. Por eso los contadores de error SAS y el reporting a nivel de enlace pueden ser más ricos—si tus herramientas lo exponen.
• La caché de controladoras RAID antes ocultaba problemas de disco. La caché con batería podía enmascarar latencia e incluso reordenar síntomas de fallo, haciendo los postmortems divertidos en el peor sentido.
• Los HBAs en modo IT se convirtieron en la norma para ZFS porque ZFS quiere la verdad. ZFS espera semánticas de dispositivo directo; el firmware RAID que remapea errores puede sabotear el diagnóstico.
• El reporte de errores ATA es inconsistente entre fabricantes. SMART es útil, pero los vendedores implementan atributos de forma distinta y a veces optimista.
• Los errores UDMA CRC suelen ser errores de la ruta, no del medio. Si ese contador sube, sospecha primero de cables, backplanes o ruido eléctrico.
• Los reintentos internos del disco pueden parecer “latencia aleatoria” antes de fallar. Cuando ves errores duros, el disco puede llevar semanas luchando.
• Los scrubs de ZFS existen para atrapar sectores latentes. El objetivo es encontrar sectores malos mientras aún tienes redundancia, no durante un rebuild sin redundancia.

Una idea parafraseada de Werner Vogels: “Todo falla, todo el tiempo.” Trátalo como una restricción de diseño, no como un póster motivacional.

Guion rápido de diagnóstico (primeras/segundas/terceras comprobaciones)

Primero: establece el radio de impacto y el riesgo actual

1. Ejecuta zpool status -xv. Buscas qué vdevs están degradados, si los errores aumentan y si ZFS reparó algo.
2. Comprueba si hay un scrub/resilver en curso y su ETA. Si ya estás degradado, tu objetivo es evitar añadir estrés o provocar más fallos.
3. Identifica el margen de redundancia. Mirror: puedes perder un lado. RAIDZ1: puedes perder un disco total. RAIDZ2: dos. Sé brutalmente honesto.

Segundo: correlaciona con evidencia a nivel SO

1. Mira dmesg / journald en busca de resets, timeouts, errores de enlace. Si ves “hard resetting link,” “device offline,” o “COMRESET failed,” estás en territorio de cable/controlador.
2. Extrae SMART, especialmente UDMA CRC y sectores reallocados/pending. CRC en aumento apunta a la ruta; reallocated/pending apunta al disco.
3. Comprueba si varios discos en el mismo puerto HBA o expander muestran síntomas. Destino compartido sugiere hardware compartido.

Tercero: actúa con conservadurismo y verifica después de cada cambio

1. Si la evidencia apunta a un disco: reemplázalo. No “lo vigiles” si ya estás degradado y el disco arroja errores de medio.
2. Si la evidencia apunta a la ruta: recoloca/reemplaza el componente más simple primero. Empieza por el cable, luego la ranura del backplane, luego el HBA— salvo que los logs griten otra cosa.
3. Tras cualquier cambio de hardware: borra errores, haz un scrub y observa los contadores. “Arreglado” significa que los contadores dejan de aumentar bajo carga.

Tareas prácticas: comandos, salida esperada y la decisión que tomas

Tarea 1: Obtén la lista autorizada de síntomas de ZFS

cr0x@server:~$ sudo zpool status -xv
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 02:11:09 with 0 errors on Tue Dec 24 03:12:21 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       3     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

errors: No known data errors

Qué significa: Un disco acumuló errores READ, pero ZFS dice que las aplicaciones no se vieron afectadas y que no hay errores de datos conocidos.
Eso sugiere que ZFS tuvo redundancia para recuperarse.

Decisión: No has terminado. Necesitas identificar si esas lecturas son problema del disco (medio) o del camino (CRC/timeouts).
No borres los errores aún; son migas de pan.

Tarea 2: Observa si los contadores de 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_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       7     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

Qué significa: Los errores crecieron de 3 a 7. Algo sigue estando mal.

Decisión: Aumenta la urgencia. Comienza la correlación con logs del SO inmediatamente; planifica una acción de mantenimiento (reemplazar disco o arreglar la ruta) hoy, no “en la próxima ventana.”

Tarea 3: Mapea el dispositivo ZFS a un disco físico que puedas tocar

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WDC_WD80 | head
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-WDC_WD80...-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-WDC_WD80...-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-WDC_WD80...-part1 -> ../../sdd1

Qué significa: Puedes traducir el nombre by-id a /dev/sdX.
No te saltes esto: la gente reemplaza el disco equivocado más a menudo de lo que admite.

Decisión: Identifica el nodo de dispositivo sospechoso (por ejemplo /dev/sdc) y úsalo consistentemente para SMART y logs.

Tarea 4: Inspecciona los logs del kernel en busca de resets/timeouts de enlace (olor a path/controlador)

cr0x@server:~$ sudo dmesg -T | egrep -i 'sdc|ata[0-9]|reset|timeout|failed command|I/O error' | tail -n 20
[Wed Dec 25 01:44:02 2025] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
[Wed Dec 25 01:44:02 2025] ata6.00: irq_stat 0x08000000, interface fatal error
[Wed Dec 25 01:44:02 2025] ata6: SError: { CommWake DevExch }
[Wed Dec 25 01:44:03 2025] ata6: hard resetting link
[Wed Dec 25 01:44:08 2025] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 25 01:44:08 2025] sd 5:0:0:0: [sdc] tag#15 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed Dec 25 01:44:08 2025] sd 5:0:0:0: [sdc] Sense Key : Medium Error [current]
[Wed Dec 25 01:44:08 2025] sd 5:0:0:0: [sdc] Add. Sense: Unrecovered read error

Qué significa: Tienes drama tanto a nivel de enlace (hard resetting link) como un error de medio (unrecovered read error).
Aquí el diagnóstico se pone picante: un cable malo puede provocar resets; un disco defectuoso también puede provocar resets.

Decisión: Ejecuta SMART a continuación. Si SMART muestra pending/reallocated sectors, el disco es lo suficientemente culpable como para reemplazarlo.
Si SMART está limpio pero los CRC suben, sospecha cable/backplane/controlador.

Tarea 5: Comprueba el resumen SMART y los atributos que importan

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i 'SMART overall|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Power_On_Hours|Temperature' 
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       12
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       7
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   074   074   000    Old_age   Always       -       22816
194 Temperature_Celsius     0x0022   110   099   000    Old_age   Always       -       40

Qué significa: SMART “PASSED” no es una exoneración. Tienes 12 sectores pendientes y 7 offline uncorrectables.
Eso no es un problema de cable; es el disco admitiendo que no puede leer partes del plato/tabla flash.

Decisión: Reemplaza el disco. No pierdas tiempo cambiando cables primero cuando el medio ya admite la derrota.

Tarea 6: Busca errores UDMA CRC (evidencia clásica de cable/backplane)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i 'UDMA_CRC_Error_Count|Interface_CRC|CRC'
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       43

Qué significa: Los errores CRC aumentan cuando el enlace corrompe tramas. Los discos no pueden arreglar eso con reallocación.
Un puñado durante años puede ocurrir, pero un contador que sube en un periodo corto es un problema de ruta de hardware.

Decisión: Recoloca/reemplaza el cable SATA/SAS para esa bahía, revisa conectores del backplane y asegúrate de que el disco esté bien asentado.
Tras los cambios, verifica que el contador CRC deje de aumentar bajo carga.

Tarea 7: Ejecuta una auto-prueba SMART dirigida para validar la sospecha

cr0x@server:~$ sudo smartctl -t long /dev/sdc
Please wait 780 minutes for test to complete.
Test will complete after Wed Dec 25 15:10:22 2025

Qué significa: Una prueba larga obliga al disco a recorrer el medio. Si falla, obtienes evidencia concreta.

Decisión: Si no puedes esperar, reemplaza ahora. Si puedes, deja que termine y revisa resultados—especialmente útil cuando discutes con compras.

Tarea 8: Lee los resultados de la auto-prueba SMART (el paso de “muestra tu trabajo”)

cr0x@server:~$ sudo smartctl -a /dev/sdc | sed -n '/SMART Self-test log/,$p' | head -n 20
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       10%     22820         3912456672
# 2  Short offline       Completed without error       00%     22816         -

Qué significa: “Completed: read failure” con un LBA es una pistola humeante por problemas de medio.

Decisión: Reemplaza el disco, luego haz un scrub después del resilver. Si estás en RAIDZ1 y ya degradado, actúa rápido y evita carga no esencial.

Tarea 9: Identifica si los errores se agrupan por controlador / expander

cr0x@server:~$ lsscsi -t
[0:0:0:0]    disk    ata:WDC_WD80...  /dev/sdb  -  sata:ahci
[0:0:1:0]    disk    ata:WDC_WD80...  /dev/sdc  -  sata:ahci
[2:0:0:0]    disk    sas:SEAGATE...   /dev/sdd  -  sas:phy0
[2:0:1:0]    disk    sas:SEAGATE...   /dev/sde  -  sas:phy0

Qué significa: Tienes dispositivos detrás de distintos hosts/phys. Si todos los discos “sas:phy0” muestran errores de checksum juntos,
dejas de culpar “discos aleatorios” y empiezas a culpar la infraestructura compartida.

Decisión: Agrupa errores por host/puerto. Si el patrón coincide con un único HBA/expander, programa mantenimiento en ese componente.

Tarea 10: Inspecciona eventos del HBA/driver (los resets no son una buena señal)

cr0x@server:~$ sudo dmesg -T | egrep -i 'mpt2sas|mpt3sas|sas|reset|ioc|task abort' | tail -n 30
[Wed Dec 25 01:20:11 2025] mpt3sas_cm0: log_info(0x31120100): originator(PL), code(0x12), sub_code(0x0100)
[Wed Dec 25 01:20:12 2025] mpt3sas_cm0: sending diag reset !!
[Wed Dec 25 01:20:20 2025] mpt3sas_cm0: diag reset: SUCCESS
[Wed Dec 25 01:20:23 2025] sd 2:0:1:0: [sde] tag#91 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK

Qué significa: El controlador se reinició, y los discos vieron DID_RESET. ZFS puede registrar problemas de lectura/checksum porque la secuencia de I/O se interrumpió.

Decisión: Trata esto como territorio de controlador/firmware/PCIe/energía. Revisa versiones de firmware, errores PCIe y condiciones térmicas.
Si los resets se repiten, planifica un intercambio de HBA en lugar de “vamos a monitorizar.”

Tarea 11: Confirma la salud de la capa PCIe (porque los HBA están en PCIe, no en el aire)

cr0x@server:~$ sudo journalctl -k | egrep -i 'pcie|aer|corrected|uncorrected|fatal' | tail -n 20
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER: Corrected error received: 0000:3b:00.0
Dec 25 01:20:10 server kernel: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER:   device [8086:2030] error status/mask=00000040/00002000
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER:    [ 6] Bad TLP

Qué significa: AER de PCIe “Bad TLP” es la plataforma admitiendo problemas de la capa de enlace de datos. Eso puede manifestarse como resets de HBA y errores de I/O.

Decisión: Reasienta el HBA, verifica la salud de la ranura PCIe, revisa ajustes del BIOS y considera mover el HBA a otra ranura.
Si los errores persisten, sospecha de la placa base/risers.

Tarea 12: Borra errores solo después de abordar el problema subyacente

cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status -xv
all pools are healthy

Qué significa: Los contadores se reinician. Genial para visibilidad, terrible si lo hiciste antes de arreglar algo.

Decisión: Ahora aplica carga (trabajo normal o un scrub) y confirma que los contadores se mantengan en cero.
Si vuelven, tu “arreglo” fue teatral.

Tarea 13: Inicia un scrub e interpreta lo que encuentre

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 02:05:18 2025
        1.20T scanned at 1.45G/s, 220G issued at 270M/s, 8.00T total
        0B repaired, 2.75% done, 08:07:12 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

Qué significa: El scrub va limpio hasta ahora y los contadores permanecen en cero. Así es como se ve “arreglado.”

Decisión: Deja que el scrub termine. Si completa con 0 errores y los contadores se mantienen estables durante la carga pico,
puedes cerrar el incidente con buena confianza.

Tarea 14: Reemplaza un disco fallado correctamente (y evita el incidente de “disco equivocado”)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD80...-part1
cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80...-part1 /dev/disk/by-id/ata-WDC_WD80_NEW_DISK-part1
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Wed Dec 25 02:12:44 2025
        620G scanned at 1.10G/s, 85.2G issued at 155M/s, 8.00T total
        85.2G resilvered, 1.04% done, 09:11:33 to go

Qué significa: El resilver está en marcha. Degradado es esperado hasta que termine.

Decisión: Monitoriza nuevos errores durante el resilver. Si otro disco empieza a fallar durante el resilver, detente y reevalúa el riesgo:
podrías estar a un mal día de la pérdida de datos (especialmente RAIDZ1).

Tarea 15: Verifica el historial de eventos de ZFS (útil si el contador ya fue borrado)

cr0x@server:~$ sudo zpool events -v | tail -n 25
Dec 25 2025 01:44:08.123456789 ereport.fs.zfs.io
        class = "ereport.fs.zfs.io"
        ena = 0x7f0b2c00000001
        detector = (embedded nvlist)
        (snip)
        vdev_path = "/dev/disk/by-id/ata-WDC_WD80...-part1"
        vdev_guid = 1234567890123456789
        io_error = 5

Qué significa: ZFS registró ereports de I/O, incluyendo qué ruta vdev fue implicada. Útil para reconstruir la línea temporal.

Decisión: Usa los eventos para correlacionar con logs del SO y cambios de hardware. Si ves ráfagas de eventos alineadas con resets del controlador, el controlador es el sospechoso.

Broma #2: Si tu “arreglo rápido” es reiniciar el servidor de almacenamiento, eso no es troubleshooting—es la versión TI de subir el volumen de la radio.

Disco vs cable vs controlador: patrones que realmente se mantienen

Cuando es el disco

Los discos fallan de maneras predecibles y enloquecedoras. La parte predecible: los errores de medio aparecen como sectores pendientes,
uncorrectables y auto-pruebas SMART que no pueden completarse. La parte enloquecedora: muchos discos “pasan” SMART hasta que dejan de hacerlo,
porque SMART es un conjunto de umbrales definidos por el vendedor, no una garantía.

Indicadores que apuntan al disco:

• Current_Pending_Sector o Offline_Uncorrectable es distinto de cero y está creciendo.
• Los logs del kernel muestran Medium Error, “Unrecovered read error” u datos de sentido similares para el mismo disco.
• La prueba larga SMART falla con un fallo de lectura y un LBA.
• Los errores de ZFS permanecen localizados en una hoja del vdev a lo largo del tiempo y tras reinicios.

Reemplazar un disco no es una falla moral. Es el trabajo. El único error real es dudar hasta que falle un segundo componente
mientras aún discutes el primero.

Cuando es el cable o backplane

Los cables y los backplanes no reciben suficiente culpa porque son aburridos. Tampoco vienen con paneles de garantía.
Pero la integridad de la señal es física, y la física no se preocupa de que tu revisión trimestral sea mañana.

Indicadores que apuntan a cable/backplane:

• UDMA_CRC_Error_Count aumenta (especialmente rápidamente) mientras los atributos de medio parecen limpios.
• Los logs del kernel muestran link resets, COMRESET failed, “SATA link down” o “device offlined” sin errores claros de medio.
• Los errores se mueven cuando mueves el disco a otra bahía, o cuando cambias el cable.
• Varios discos en la misma fila de backplane/expander muestran errores durante vibraciones/cambios de temperatura.

Consejo práctico: si usas SATA en un chasis denso, usa cables de calidad con seguro/latch, minimiza curvas y trata los backplanes como componentes
con ciclo de vida. Si no puedes conseguir cables con latch, estás a un tirón accidental de un incidente.

Cuando es el controlador (HBA, expander, firmware o PCIe)

Los controladores fallan de manera única: fallan “sistémicamente” y lo hacen ruidosamente en los logs. También fallan de maneras que parecen fallos de disco,
porque el disco es el mensajero que recibe los disparos.

Indicadores que apuntan al controlador:

• Los logs del kernel muestran mpt2sas/mpt3sas resets, abortos de tarea, IOC resets o resets repetidos de bus.
• Los errores aparecen en múltiples discos detrás del mismo HBA/expander, especialmente dentro de la misma ventana temporal.
• Errores AER de PCIe se correlacionan con interrupciones de I/O.
• Cambiar firmware/driver altera el patrón de síntomas (a veces a mejor, a veces a “nuevo y emocionante”).

Guía opinada: si usas ZFS, tu HBA debería estar en modo IT, en una versión de firmware estable que puedas reproducir,
y deberías poder identificar exactamente qué discos cuelgan de qué puertos. Si no puedes, estás operando a ciegas.

El medio confuso: señales mixtas y daño secundario

Los incidentes reales a menudo implican más de un factor contribuyente:

• Un cable marginal causa resets de enlace intermitentes.
• Esos resets obligan a los discos a entrar en recuperación de errores con más frecuencia.
• Un disco con sectores débiles ahora tiene que reintentar lecturas bajo estrés, y aparecen sectores pendientes.

Por eso no te detienes en “es el disco” si los errores CRC se están disparando, y no te detienes en “es el cable” si SMART reporta uncorrectables.
A veces la respuesta correcta es: reemplazar el disco y el cable, luego vigilar resets de controlador que iniciaron toda la cadena.

Tres microhistorias del mundo corporativo (anonimizadas, dolorosamente plausibles)

1) El incidente causado por una suposición equivocada

Una empresa mediana operaba una granja NFS respaldada por ZFS para artefactos de compilación. Nada exótico: un par de pools RAIDZ2, discos decentes,
y la costumbre de ignorar las advertencias hasta que se convirtieron en páginas. Una mañana, los desarrolladores se quejaron de que las compilaciones no podían obtener artefactos.
El host de almacenamiento mostró errores de lectura en un disco de un vdev.

El ingeniero on-call hizo una suposición clásica: “READ errors significan que el disco está mal.” Puso el disco offline, fue al rack
y extrajo la unidad de la bahía que creía correspondía a /dev/sde. Lo reemplazó, ejecutó zpool replace,
y vio comenzar el resilver. Parecía competente. No lo fue.

El problema era que el chasis había sido recableado meses antes, y el mapeo físico de bahías nunca se actualizó.
El disco que sacaron no era sde. Era un disco sano hermano en el mismo vdev. El disco que fallaba se quedó online,
siguió fallando, y mientras tanto el pool corrió degradado durante el resilver. Entonces el disco defectuoso arrojó más errores bajo carga de resilver y fue expulsado.
Ahora el vdev estaba en peor estado que al inicio del día.

Se recuperaron porque era RAIDZ2, no RAIDZ1, y porque ZFS mantuvo suficientes datos consistentes para terminar el resilver tras una pausa desordenada.
El postmortem fue corto y claro: la falla no fue el disco; fue la suposición de que los nombres de dispositivo corresponden a bahías sin verificación.

La solución no fue heroica. Añadieron un procedimiento: siempre mapear by-id a la bahía física usando herramientas del enclosure o números de serie,
y etiquetar el chasis. Aburrido. Correcto. De ese aburrimiento dependen tus fines de semana.

2) La optimización que salió mal

Otra organización tenía una plataforma analítica intensiva en almacenamiento. Estaban orgullosos del rendimiento y siempre querían más.
Alguien notó que los scrubs “gastaban I/O” durante horas de negocio, así que redujeron la frecuencia de scrub y ajustaron ZFS para que el trabajo de fondo fuera menos agresivo.
Los dashboards se vieron mejor. Por un tiempo.

Meses después, un disco falló durante un pico de carga rutinario. El reemplazo fue sencillo, pero el resilver fue lento.
Durante el resilver, un segundo disco tuvo un error de lectura irreparable en un sector que no se había tocado en años.
ZFS no pudo reparar el bloque porque la paridad restante no cubría la combinación de fallos.

La verdad incómoda: el sector del segundo disco llevaba malo mucho tiempo. Un scrub regular lo habría encontrado mientras la redundancia estaba intacta,
y ZFS habría reescrito el sector malo a partir de una copia buena. Al optimizar los scrubs, optimizaron también la alerta temprana y la autocorrección.

Terminaron restaurando un fragmento de datos desde backups y reprocesando algunos trabajos analíticos. El impacto no fue existencial,
pero sí caro y embarazoso. El ingeniero que propuso el cambio no fue descuidado; estaba optimizando una métrica sin entender lo que ganaba en integridad y reducción de riesgo.

La política revisada fue contundente: hacer scrub regularmente, limitar su impacto si es necesario, pero no eliminarlos. Si hay que elegir,
sacrifica un poco de rendimiento para evitar descubrir errores latentes en el peor momento posible.

3) La práctica aburrida pero correcta que salvó el día

Una empresa SaaS ejecutaba ZFS en una flota de nodos de almacenamiento. La configuración fue intencionadamente simple: vdevs en espejo para la capa caliente,
RAIDZ2 para la capa fría, RAM ECC en todas partes y una regla estricta de estandarizar HBAs y firmware.
La regla molestaba porque retrasaba “actualizaciones rápidas.”

Un nodo comenzó a mostrar errores de checksum intermitentes en múltiples discos del mismo shelf.
El on-call siguió el runbook: capturar zpool status, capturar SMART, capturar logs del kernel,
y comprobar si los errores se correlacionaban con un puerto de HBA en particular. No borraron contadores. No reiniciaron.
Trataron el sistema como evidencia.

Los logs mostraron resets repetidos del controlador en las mismas marcas temporales que las ráfagas de checksum.
SMART en los discos estaba limpio—sin sectores pendientes, sin uncorrectables, CRC estable. Cambiaron un cable SAS y movieron la conexión del shelf
a un puerto HBA de repuesto. Los errores pararon inmediatamente y el scrub completó limpio.

La verdadera “salvación” ocurrió una semana después. Otro nodo mostró síntomas similares, pero esta vez los contadores CRC subieron rápido.
Como tenían métricas base de CRC y resets, la desviación fue obvia en minutos.
Cambiaron el cable antes de que cualquier pool se degradara.

Nada de esto es glamoroso. La práctica que los salvó fue la consistencia: firmware estandarizado, ECC, scrubs rutinarios
y el hábito de recopilar la misma evidencia cada vez. Su informe de incidentes fue corto. Su sueño, largo.

Errores comunes: síntoma → causa raíz → solución

1) “ZFS muestra errores; los borré y ahora está bien.”

Síntoma: Los errores reaparecen días después, a veces peor.

Causa raíz: Borrar los contadores eliminó evidencia sin arreglar el hardware/ruta subyacente.

Solución: Captura zpool status -xv, logs y SMART primero. Borra solo después de la remediación y valida con scrub/carga.

2) Errores CHECKSUM achacados al disco sin comprobar CRC

Síntoma: Múltiples discos muestran errores de checksum, a menudo en ráfagas.

Causa raíz: Corrupción de datos en tránsito (cable/backplane/HBA) en lugar de defectos de medio.

Solución: Comprueba UDMA_CRC_Error_Count, dmesg en busca de link resets y si los errores se agrupan por HBA/expander. Reemplaza/repara el componente compartido.

3) Tratar SMART “PASSED” como “saludable”

Síntoma: SMART dice PASSED, pero los errores de lectura siguen y existen sectores pendientes.

Causa raíz: El estado general SMART es basado en umbrales y a menudo demasiado tolerante.

Solución: Observa atributos específicos (pending, uncorrectable, reallocated, CRC). Ejecuta pruebas largas cuando sea posible.

4) Reemplazar el disco equivocado

Síntoma: Tras el reemplazo, los errores persisten; a veces el pool queda más degradado.

Causa raíz: El mapeo dispositivo→bahía fue adivinado, no verificado. Se cambió el cableado; la enumeración cambió.

Solución: Usa /dev/disk/by-id, números de serie y herramientas de mapeo del enclosure. Etiqueta bahías. Exige una comprobación de segunda persona en producción.

5) Ejecutar RAIDZ1 en lugares donde el riesgo de reconstrucción no es aceptable

Síntoma: Durante el resilver, un segundo error de disco causa pérdida de datos o bloques irreparables.

Causa raíz: Vdevs de paridad simple son frágiles durante reconstrucciones, especialmente con discos grandes y sectores latentes.

Solución: Prefiere mirrors (resilver rápido, dominio de fallo simple) o RAIDZ2/3 para vdevs de gran capacidad. Haz scrubs regularmente.

6) Ignorar resets del controlador como “ruido”

Síntoma: Bloqueos intermitentes de I/O, múltiples discos fallan brevemente, los errores vienen en oleadas.

Causa raíz: Inestabilidad de firmware/driver del HBA, problemas PCIe, sobrecalentamiento o eventos de energía.

Solución: Revisa dmesg en busca de resets, verifica PCIe AER, comprueba refrigeración, estandariza firmware y reemplaza/traslada el HBA si es necesario.

7) Sobrecargar el pool durante un resilver

Síntoma: El resilver tarda una eternidad; aparecen más errores; otro disco cae.

Causa raíz: I/O aleatorio pesado + estrés de reconstrucción dispara componentes marginales.

Solución: Reduce la carga si es posible, programa reconstrucciones y evita forzar trabajos sensibles a latencia durante estados degradados. Considera mirrors para capas hot.

Listas de verificación / plan paso a paso

Lista de contención inmediata (primeros 30 minutos)

1. Ejecuta zpool status -xv. Guarda la salida en el ticket.
2. Confirma el margen de redundancia (mirror/RAIDZ) y si algún vdev ya está degradado.
3. Comprueba si los contadores de error están aumentando (ejecuta zpool status dos veces, con minutos de diferencia).
4. Captura logs del SO alrededor de la ventana del incidente: dmesg -T y journalctl -k.
5. Extrae SMART de los discos sospechosos (al menos los que presentan errores en ZFS; idealmente todos en el vdev).
6. Si está degradado: reduce la carga no esencial y evita acciones de mantenimiento que añadan estrés (como actualizaciones de firmware) a menos que sean necesarias.

Lista de decisión: disco vs ruta

• Reemplaza el disco ahora si sectores pending/offline uncorrectable son distintos de cero, o la prueba larga SMART falla.
• Arregla la ruta primero si los errores CRC aumentan, los resets de enlace dominan los logs y los indicadores de medio SMART están limpios.
• Sospecha del controlador/plataforma si múltiples discos detrás de un HBA muestran problemas y ves resets del controlador o eventos PCIe AER.
• Haz ambos si el disco muestra problemas de medio y la ruta muestra CRC/resets. Suceden fallos mixtos.

Plan de remediación (cambia una cosa a la vez)

1. Identifica el componente físico exacto (serie del disco, bahía, cable, puerto HBA).
2. Reemplaza/arregla el componente más probable con el menor radio de impacto:
   • Reasentar/reemplazar cable
   • Mover disco a otra bahía (si tu enclosure lo permite y puedes mantener el mapeo correcto)
   • Reemplazar disco
   • Intercambiar HBA o mover a otra ranura PCIe
3. Borra errores de ZFS solo después de la remediación.
4. Ejecuta un scrub. Monitoriza errores durante el scrub.
5. Documenta el mapeo y lo que fue reemplazado (tu yo futuro estará cansado y agradecido).

Lista de validación (fase de “demuéstralo”)

1. El scrub completa con 0 errores.
2. zpool status muestra que READ/WRITE/CKSUM no aumentan durante la carga pico.
3. Los contadores SMART CRC dejan de aumentar tras la remediación de cable/backplane.
4. No hay resets del controlador ni errores PCIe AER en logs durante al menos un ciclo laboral completo.

FAQ

1) ¿Los errores de lectura de ZFS siempre significan un disco fallando?

No. READ errors significan que la capa de bloques devolvió un error. Eso puede ser medio del disco, pero también resets de enlace, timeouts de controlador o energía.
Usa atributos SMART de medio y logs del SO para separar disco de ruta.

2) ¿Cuál es la diferencia entre errores READ y CHECKSUM en zpool status?

READ errors significan que el dispositivo no devolvió datos con éxito. CHECKSUM errors significan que el dispositivo devolvió datos, pero no coincidieron con el checksum de ZFS,
apuntando a corrupción en tránsito, firmware o memoria (menos común).

3) Si ZFS dice “errors: No known data errors,” ¿puedo ignorarlo?

No puedes ignorarlo. Ese mensaje significa que ZFS cree que reparó o evitó corrupción visible por el usuario. No significa que el hardware esté sano.
Trátalo como una advertencia temprana—tu tipo de advertencia más barato.

4) ¿Debería ejecutar zpool clear de inmediato?

No de inmediato. Captura evidencia primero. Borra después de reemplazar/arreglar algo para poder ver si el problema vuelve.

5) ¿Cuántos errores UDMA CRC son “demasiados”?

Unos pocos a lo largo de la vida pueden ocurrir por eventos transitorios. Un contador CRC que aumenta durante la operación normal—especialmente rápido—significa que la ruta está poco saludable.
La tendencia importa más que el valor absoluto.

6) ¿Problemas de RAM ECC pueden mostrarse como errores de checksum?

Sí, pero es menos común que cable/backplane/HBA en sistemas bien construidos. ECC normalmente corrige errores de un bit y los registra.
Si sospechas memoria, revisa logs del kernel por eventos ECC y considera una prueba de memoria en ventana de mantenimiento.

7) ¿Es seguro usar RAIDZ1 con discos grandes?

Depende de tu tolerancia al riesgo, carga de trabajo y disciplina operativa. En la práctica, discos grandes y tiempos de rebuild largos hacen a RAIDZ1 frágil.
Los mirrors o RAIDZ2 son opciones más seguras en producción donde el downtime o la pérdida de datos es caro.

8) ¿Por qué los errores aparecen durante un scrub o resilver?

Porque los scrubs y resilvers fuerzan lecturas de superficie completa. Tocan datos fríos que no se han leído en meses.
Eso es exactamente cuando se exponen sectores latentes, cables marginales y controladores marginales.

9) Si cambio un cable, ¿cómo confirmo que lo arregló?

Borra errores de ZFS después del cambio, luego ejecuta un scrub y observa. También revisa contadores SMART CRC: deben dejar de aumentar.
Si los resets de enlace continúan en los logs, el problema no está resuelto.

10) ¿Un backplane puede causar errores de checksum sin expulsar discos?

Sí. Un backplane marginal puede corromper tráfico o provocar reintentos intermitentes sin desconectar completamente un disco.
Eso suele aparecer como errores de checksum, resets ocasionales de enlace y contadores CRC que suben lentamente.

Siguientes pasos (qué hacer después de detener la hemorragia)

Una vez el pool esté estable y el scrub limpio, no desperdicies el dolor. Conviértelo en postura:

• Estandariza el mapeo de discos. Etiquetas, uso de by-id y un mapa de bahías documentado reducen errores humanos más que cualquier herramienta.
• Genera línea base de señales SMART y logs. Contadores CRC, sectores pendientes, resets de controlador y PCIe AER deberían graficarse o al menos revisarse periódicamente.
• Programa scrubs. Ajústalos para mitigar impacto, pero no los omitas. Los scrubs son tu ejercicio de integridad, no un pasatiempo opcional.
• Mantén firmware aburrido. Combinaciones de firmware/driver de HBA estables baten a “lo último” en producción salvo que necesites un arreglo específico.
• Diseña para reconstrucciones. Mirrors o RAIDZ2/3, más ventanas de reconstrucción realistas, convierten fallos de disco en mantenimiento en lugar de incidentes.
• Practica reemplazos. Ejecuta un reemplazo de disco en un laboratorio. El peor momento para aprender las peculiaridades de tu chasis es durante un vdev degradado.

Los sistemas de almacenamiento más fiables no son los que nunca fallan. Son los que hacen que la falla parezca rutinaria: evidencia clara, aislamiento rápido,
un componente reemplazado, scrub, listo. Ese es el estándar. Fíjalo, y tus futuros errores de lectura serán un recado en lugar de una crisis.