Supervisión SMART de ZFS: correlacionando advertencias de disco con errores ZFS

Un modelo mental: qué sabe ZFS vs qué sabe SMART

ZFS y SMART no son rivales. Son dos testigos del mismo crimen, situados en distintas esquinas.
Uno vio la cara del sospechoso. El otro oyó los chirridos de las ruedas. Ninguna historia está completa por sí sola.

ZFS: basado en evidencias, extremo a extremo y brutalmente literal

ZFS observa el mundo mediante operaciones I/O y checksums. Cuando ZFS lee un bloque, valida el checksum.
Si el checksum no coincide, ZFS lo marca como un error de checksum. Si el dispositivo se niega a leer
o escribir, ZFS lo marca como un error I/O. Si ZFS puede corregir datos malos gracias a la redundancia (mirror/RAIDZ),
incrementa contadores y sigue funcionando, a menudo mientras duermes.

ZFS no sabe intrínsecamente por qué falló una lectura. Podría ser una superficie de plato defectuosa. Podría ser un puerto de expander SAS malo.
Podría ser un fallo de firmware del controlador. Podría ser un rayo cósmico. ZFS simplemente sabe que solicitó datos y recibió algo incorrecto.

SMART: predictivo, con matices de proveedor y ocasionalmente dramático

SMART es un conjunto de contadores y resultados de pruebas autoinformados por el firmware del disco. Conoce sobre reasignaciones,
sectores pendientes, read disturb, resistencia, errores CRC en el enlace SATA y más. Puede ejecutar auto-pruebas.
También puede ocultar problemas mediante la “normalización de atributos” donde el valor bruto importa pero el “VALUE/WORST/THRESH”
intenta mantenerte tranquilo hasta que ya es demasiado tarde.

SMART también tiene un gran punto ciego: si el problema está aguas arriba (cable, HBA, backplane, alimentación), el disco puede parecer sano
mientras ZFS se ahoga en errores I/O. O SMART puede mostrar errores UDMA CRC que gritan “cable” mientras los contadores de ZFS suben,
y estarás tentado de RMA el disco porque es emocionalmente satisfactorio.

Correlacionar es la disciplina de preguntar: ¿estas señales describen el mismo modo de fallo y apuntan a una acción concreta?
Esto es menos “monitorización” y más “contrainterrogatorio en sala”.

Una idea parafraseada de Richard Cook (ingeniería de la resiliencia): El éxito en operaciones viene de la capacidad de las personas para adaptarse continuamente a la complejidad bajo presión.

Datos interesantes y contexto histórico

• ZFS se diseñó teniendo en cuenta la corrupción silenciosa de datos. Los checksums extremo a extremo surgieron como reacción a pilas de almacenamiento que asumían que los discos “en su mayoría dicen la verdad”.
• SMART es anterior a las características de integridad de los sistemas de archivos modernos. Emergió cuando el sistema operativo tenía muy poca visibilidad del comportamiento interno del disco.
• Los atributos SMART no están estandarizados en la práctica. Los nombres parecen consistentes; el significado y la escala a menudo no lo son, especialmente entre proveedores y generaciones de SSD.
• “UDMA CRC error count” es uno de los atributos más accionables. A menudo indica problemas de cableado/backplane más que fallo del medio.
• Los scrubs de ZFS fueron polémicos al principio. La gente temía que los scrubs “gastaran” los discos; la realidad es que los scrubs son cómo descubres errores latentes antes de que un rebuild te obligue a afrontarlos.
• Los SMART tempranos de SSD eran extremadamente optimistas. Algunos dispositivos reportaban salud casi perfecta hasta la falla; la telemetría NVMe moderna es mejor pero sigue sin ser infalible.
• Los rebuilds de RAID solían ser “la parte aterradora”. Con discos multi-TB, los errores de lectura no recuperables durante un rebuild se convirtieron en un riesgo práctico; los scrubs y checksums de ZFS ayudan a exponer riesgos antes.
• Los contadores de errores de ZFS pueden aumentar sin una interrupción visible para el usuario. Las lecturas de autocorrección reparan datos silenciosamente en vdevs redundantes; “sin interrupción” no significa “sin problema”.

Mapa de señales: advertencias SMART ↔ errores ZFS

Empieza por los tipos de error de ZFS (porque están ligados a la corrección de datos)

• Errores de checksum: los datos devueltos por el dispositivo no concuerdan con el checksum esperado. A menudo problemas de medio, a veces corrupción del controlador/cable, ocasionalmente RAM (si no hay ECC y tienes mala suerte).
• Errores de lectura / escritura: el dispositivo falló la operación I/O. A menudo reinicios de enlace, timeouts, alimentación/cable, o el dispositivo rindiéndose.
• Remoción/estado faulted del dispositivo: el OS perdió el dispositivo. Piensa en: alimentación SATA inestable, reinicio del expander, problemas del HBA, o que el propio disco se reseteó.

Ahora los atributos SMART que realmente merecen tu atención

Los atributos “mejores” son los que tienen un significado físico claro y buena correlación con fallo:
pending sectors, reallocated sectors, uncorrectable errors y interface CRC errors.
La temperatura también importa, pero sobre todo como factor de riesgo.

• Reallocated_Sector_Ct: sectores que el disco ha reasignado. Un valor distinto de cero no es muerte instantánea, pero si aumenta es una tendencia a vigilar.
• Current_Pending_Sector: sectores que no se pudieron leer y esperan reescritura para reasignarse. A menudo es el atributo que indica “pérdida de datos pronto”.
• Offline_Uncorrectable / UNC: errores de lectura no corregibles hallados durante escaneos offline o en operaciones normales.
• UDMA_CRC_Error_Count: corrupción de datos en el enlace (SATA). Casi siempre problemas de cableado/backplane/conector, no del medio.
• SMART overall-health: útil cuando falla; no es confiable cuando pasa.
• NVMe Media and Data Integrity Errors: señal fuerte en dispositivos NVMe cuando es distinta de cero y aumenta.
• Power_On_Hours / Power_Cycle_Count: contexto. Ciclos de encendido frecuentes se correlacionan con fallos extraños y problemas de conectores.

Patrones de correlación en los que puedes confiar

Patrón A: errores de checksum de ZFS + pending sectors (o offline uncorrectables)

Este es el caso más claro. El dispositivo está devolviendo datos malos o no puede leerlos de forma fiable. ZFS a menudo lo corrige desde la redundancia,
pero tu trabajo es dejar de jugar a la ruleta. Ejecuta un scrub, captura evidencias y reemplaza el disco si los contadores se mueven.

Patrón B: errores I/O de ZFS + UDMA CRC errors (SATA)

Habitualmente no es el disco. Es la ruta: cable, backplane, oxidación del conector, un splitter barato,
o una bahía “hot-swap” que es más “warm-swap si prometes no estornudar”.
Reasienta/reemplaza cables, cambia puertos, revisa la alimentación. Si los CRC dejan de incrementarse, el disco está bien.

Patrón C: fallos/remociones de dispositivo en ZFS + SMART limpio

Piensa en alimentación y transporte. Los discos pueden desaparecer bajo alimentación marginal, reinicios de expander o problemas de firmware del HBA.
SMART no siempre lo registrará porque el disco no falló internamente; simplemente fue arrancado de la realidad.

Patrón D: SMART “PASSED” + errores de checksum en ZFS

SMART overall-health es un instrumento contundente. Algunos discos no declaran fallo hasta que la situación ya está en llamas.
Trata los checksums de ZFS como prioridad para la corrección de datos, y luego examina atributos SMART en bruto y los logs de transporte.

Patrón E: sin errores ZFS, advertencias SMART en aumento

Aquí es donde la gente se relaja. ZFS no ha observado datos incorrectos aún. SMART te está diciendo que el disco
hace un esfuerzo extra para mantener las apariencias. Si los atributos SMART son los “reales” (pending/uncorrectable),
planifica un reemplazo controlado. Si solo son picos de temperatura o una reasignación aislada de hace años, vigila de cerca.

Broma #1: SMART es como el testigo de “revisa el motor”: a veces es catastrófico, a veces tu tapa del depósito está suelta, y en cualquier caso llegas tarde al trabajo.

Guía de diagnóstico rápido (primero/segundo/tercero)

Primero: averigua de qué se queja ZFS

1. Ejecuta zpool status -xv y léelo como un contrato. Busca contadores READ, WRITE, CKSUM y cualquier mensaje de “demasiados errores”.
2. Identifica el dispositivo exacto y el vdev (por ID persistente, no por la ruleta /dev/sdX).
3. Comprueba si los errores siguen aumentando (ejecuta el estado otra vez tras algo de I/O, o después de un minuto). Los errores históricos estáticos son distintos de los activos.

Segundo: decide si huele a medio vs transporte vs host

1. Sospecha de medio: errores de checksum en un disco, pending/uncorrectable/reallocated en SMART aumentando, auto-test falla.
2. Sospecha de transporte: errores I/O, reinicios de dispositivo, errores CRC, múltiples discos en el mismo puerto de backplane, logs del kernel muestran resets/timeouts del enlace.
3. Sospecha de host: errores en muchos vdevs a la vez, resets del HBA, mensajes PCIe AER, inestabilidad de memoria, bugs de firmware.

Tercero: elige una acción segura que reduzca el riesgo rápidamente

1. Si la redundancia está intacta: ejecuta un scrub para forzar lecturas; recopila SMART; programa reemplazo o trabajo de cableado en horario laboral.
2. Si la redundancia está comprometida (RAIDZ/mirror degradado con un miembro ya faltante): deja de experimentar. Minimiza la carga, toma backups/snapshots en serio y reemplaza primero al culpable más probable.
3. Si el dispositivo está intermitente: estabiliza el transporte (reasentar/reemplazar cable, cambiar puerto) antes de resilverar. Resilverar a través de un enlace inestable es solo arte performático.

Tareas prácticas: comandos, salidas, decisiones

A continuación hay tareas prácticas que puedes ejecutar en un host Linux ZFS típico (OpenZFS). Cada tarea incluye: un comando, un fragmento realista de salida,
qué significa y la decisión que tomas. Hazlas en orden cuando estés de guardia. Hazlas en cámara lenta cuando no lo estés.

Tarea 1: Confirma si algún pool está descontento

cr0x@server:~$ zpool status -x
pool 'tank' is healthy
pool 'backup' has experienced errors

Significado: -x imprime solo problemas. “Healthy” no significa “perfecto”, significa que no hay fallos conocidos que requieran acción.

Decisión: Si algún pool no está healthy, pasa inmediatamente a un estado verbose completo y empieza a recopilar evidencias antes de reiniciar nada.

Tarea 2: Obtén la vista detallada de ZFS (tu fuente primaria)

cr0x@server:~$ zpool status -xv backup
  pool: backup
 state: ONLINE
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:30 with 2 errors on Sun Dec 22 03:10:12 2025
config:

        NAME                                     STATE     READ WRITE CKSUM
        backup                                   ONLINE       0     0     0
          raidz1-0                               ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ7...     ONLINE       0     0     2
            ata-WDC_WD80EFAX-68LHPN0_VKJ8...     ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ9...     ONLINE       0     0     0

errors: No known data errors

Significado: Ocurrieron dos errores de checksum y fueron corregidos. “No known data errors” significa que ZFS cree que reparó o aisló el daño.

Decisión: Trata los errores de checksum corregidos como una advertencia. No borres los contadores todavía; correlaciona con SMART y logs de transporte primero.

Tarea 3: Mapea el ID del dispositivo de ZFS al dispositivo de bloque del SO

cr0x@server:~$ ls -l /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ7*
lrwxrwxrwx 1 root root 9 Dec 26 01:12 /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ7XXXX -> ../../sdc

Significado: El ID persistente apunta a /dev/sdc ahora. Mañana podría no ser así.

Decisión: Usa rutas /dev/disk/by-id para todas las operaciones de replace en ZFS. Anota el mapeo slot/serial mientras estés tranquilo.

Tarea 4: Verifica la salud general SMART (rápido pero no concluyente)

cr0x@server:~$ sudo smartctl -H /dev/sdc
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.0] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Significado: El disco no declara fallo. Eso no es lo mismo que “el disco está bien”.

Decisión: Continúa con atributos y logs de error. No permitas que “PASSED” anule los checksums de ZFS.

Tarea 5: Extrae atributos SMART que se correlacionan con fallo de medio

cr0x@server:~$ sudo smartctl -A /dev/sdc
=== START OF READ SMART DATA SECTION ===
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Significado: Existen sectores pendientes y no corregibles. Es un disco que no pudo leer dos sectores de forma fiable.

Decisión: Si este disco está en un vdev redundante: planifica el reemplazo. Si es un pool de un solo disco: haz backup ahora y luego reemplaza. También ejecuta un self-test largo para confirmación, pero no esperes a que “empeore”.

Tarea 6: Lee el registro de errores SMART (a menudo muestra el patrón)

cr0x@server:~$ sudo smartctl -l error /dev/sdc
=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
ATA Error Count: 3
  CR = Command Register [HEX]
  FR = Features Register [HEX]
  ...
Error 3 occurred at disk power-on lifetime: 42110 hours
  When the command that caused the error occurred, the device was active or idle.
  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  ...
  40 -- 51 0008  00000000f3a1c2  ...  UNC

Significado: UNC indica un error de lectura no corregible en un LBA específico. Eso concuerda con pending/uncorrectable y problemas de checksum en ZFS.

Decisión: Reemplaza el disco según tu calendario, no el del disco. Antes de reemplazar, ejecuta un scrub para forzar a ZFS a tocar la mayor superficie posible.

Tarea 7: Ejecuta una prueba SMART larga (evidencia, no terapia)

cr0x@server:~$ sudo smartctl -t long /dev/sdc
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 780 minutes for test to complete.

Significado: El disco escaneará la superficie. Esto puede sacar a la luz más errores UNC.

Decisión: Si el pool está degradado o la carga es sensible a latencia, considera programarlo. Si ya tienes sectores pendientes, no necesitas esta prueba para autorizar el reemplazo.

Tarea 8: Revisa los resultados de auto-prueba SMART

cr0x@server:~$ sudo smartctl -l selftest /dev/sdc
=== START OF READ SMART DATA SECTION ===
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%     42112         16062914
# 2  Short offline       Completed without error       00%     42001         -

Significado: La prueba larga encontró una falla de lectura. Esto es lo más cercano a una declaración jurada que ofrece SMART.

Decisión: Reemplaza el disco. Si tienes repuestos, hazlo ahora. Si la adquisición es lenta, al menos mueve los conjuntos de datos críticos fuera de este vdev o ajusta los planes de redundancia.

Tarea 9: Busca problemas de transporte/enlace en los logs del kernel

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata[0-9]|sas|reset|link|I/O error|blk_update_request' | tail -n 20
[Tue Dec 24 02:12:11 2025] ata7: hard resetting link
[Tue Dec 24 02:12:12 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Tue Dec 24 02:12:12 2025] ata7.00: configured for UDMA/133
[Tue Dec 24 02:12:12 2025] blk_update_request: I/O error, dev sdc, sector 16062914 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Tue Dec 24 02:12:13 2025] ata7.00: failed command: READ FPDMA QUEUED

Significado: Reinicios de enlace + fallos de lectura. Podría ser disco o cable; combina con SMART para decidir. Con UNC/pending presente, el disco es lo suficientemente culpable.

Decisión: Si los errores CRC son cero pero existe UNC, reemplaza el disco. Si los CRC aumentan, arregla el cableado también; puedes tener ambos problemas.

Tarea 10: Revisa UDMA CRC específicamente (clásico “no RMA al cable”)

cr0x@server:~$ sudo smartctl -A /dev/sdd | egrep 'UDMA_CRC_Error_Count|CRC'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       41

Significado: Ocurrieron errores CRC en el enlace SATA. Si este número sigue aumentando con el tiempo, tu ruta de transporte está corrompiendo o perdiendo tramas.

Decisión: Reasienta/reemplaza el cable SATA, revisa los conectores del backplane, inspecciona splitters de alimentación y considera mover el disco a otro puerto. No reemplaces el disco solo por CRC a menos que otras evidencias apunten al medio.

Tarea 11: Identifica en qué bahía física está un disco (deja de adivinar)

cr0x@server:~$ sudo udevadm info --query=all --name=/dev/sdc | egrep 'ID_SERIAL=|ID_SERIAL_SHORT=|ID_PATH=|DEVLINKS='
E: ID_SERIAL=WDC_WD80EFAX-68LHPN0_VKJ7XXXX
E: ID_SERIAL_SHORT=VKJ7XXXX
E: ID_PATH=pci-0000:3b:00.0-ata-7
E: DEVLINKS=/dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ7XXXX /dev/disk/by-path/pci-0000:3b:00.0-ata-7

Significado: Puedes mapear el disco a un puerto del controlador vía by-path. En un chasis con bahías etiquetadas, esto te evita sacar el disco equivocado.

Decisión: Documenta el mapeo (serial → bahía). Si no puedes mapear de forma fiable, no estás operando almacenamiento; estás apostando con hardware.

Tarea 12: Ejecuta un scrub (búsqueda controlada de la verdad)

cr0x@server:~$ sudo zpool scrub backup
cr0x@server:~$ zpool status backup
  pool: backup
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 01:20:05 2025
        1.12T scanned at 1.05G/s, 410G issued at 384M/s, 16.2T total
        0B repaired, 2.50% done, 11:42:16 to go

Significado: Scrub fuerza lecturas y verificación de checksums. Si un disco es marginal, los scrubs suelen provocar los errores que necesitas ver.

Decisión: Si los errores aumentan durante el scrub en un solo dispositivo, prepara el reemplazo. Si aparecen errores en múltiples discos del mismo chasis, sospecha de transporte/alimentación/HBA.

Tarea 13: Inspecciona detalles de errores de ZFS para archivos afectados (cuando ZFS lo sabe)

cr0x@server:~$ zpool status -v backup
  pool: backup
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
...
errors: Permanent errors have been detected in the following files:

        backup/media@autosnap_2025-12-25:some/path/video.mp4

Significado: ZFS no pudo reparar datos para ese archivo/bloque. Esto no es una “alerta de monitorización”. Esto es pérdida de datos.

Decisión: Restaura desde backup/snapshot/replica. Luego investiga el hardware. Además: deja de borrar errores; necesitas la auditoría hasta arreglar la causa raíz.

Tarea 14: Reemplaza un disco fallado correctamente (usa by-id)

cr0x@server:~$ sudo zpool replace backup ata-WDC_WD80EFAX-68LHPN0_VKJ7XXXX ata-WDC_WD80EFAX-68LHPN0_VNEW1234
cr0x@server:~$ zpool status backup
  pool: backup
 state: ONLINE
  scan: resilver in progress since Thu Dec 26 02:01:44 2025
        1.84T scanned at 512M/s, 620G issued at 172M/s, 16.2T total
        610G resilvered, 3.74% done, 07:55:10 to go
config:

        NAME                                       STATE     READ WRITE CKSUM
        backup                                     ONLINE       0     0     0
          raidz1-0                                 ONLINE       0     0     0
            ata-WDC_WD80EFAX-...VKJ7XXXX           ONLINE       0     0     6  (resilvering)
            ata-WDC_WD80EFAX-...VKJ8YYYY           ONLINE       0     0     0
            ata-WDC_WD80EFAX-...VKJ9ZZZZ           ONLINE       0     0     0
            ata-WDC_WD80EFAX-...VNEW1234           ONLINE       0     0     0  (resilvering)

Significado: El resilver está en curso. ZFS mantiene el dispositivo antiguo hasta la finalización si es posible. Los errores de checksum en el dispositivo antiguo pueden continuar mientras se lee durante el resilver.

Decisión: Vigila que otros discos no incrementen errores. Si el resilver se ralentiza drásticamente o los dispositivos se resetean, pausa y arregla el transporte antes de forzar la operación.

Tarea 15: Borra errores solo después de haber arreglado la causa

cr0x@server:~$ sudo zpool clear backup
cr0x@server:~$ zpool status -xv backup
  pool 'backup' is healthy

Significado: Los contadores se reinician. Esto no es “curado”; es “pizarra limpia”.

Decisión: Borra solo después de reemplazo/repair y tras un scrub limpio. De lo contrario borras tu propia evidencia forense e invitas a incidentes repetidos.

Tarea 16: SMART/health específico de NVMe (vocabulario distinto, mismo trabajo)

cr0x@server:~$ sudo smartctl -a /dev/nvme0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        47 Celsius
Available Spare:                    100%
Percentage Used:                    6%
Media and Data Integrity Errors:    12
Error Information Log Entries:      44

Significado: Errores de media y de integridad de datos distintos de cero y en aumento son un fuerte predictor de problemas en NVMe.

Decisión: Correlaciona con checksum/I/O de ZFS y resets NVMe en el kernel. Si los errores aumentan, planifica reemplazo; NVMe tiende a fallar “rápido” una vez que empieza.

Broma #2: Resilverar a través de un cable defectuoso es como intentar fregar una fuga mientras alguien sigue abriendo el grifo—técnicamente posible, espiritualmente imprudente.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición equivocada

Una compañía SaaS mediana ejecutaba un store de objetos respaldado por ZFS en un par de servidores de almacenamiento. La monitorización marcaba SMART “PASSED” en todo.
ZFS reportó un puñado de errores de checksum durante scrubs, siempre corregidos, siempre en el mismo vdev. La rotación on-call lo trató como ruido de fondo inofensivo.

La suposición equivocada fue simple: “Si el pool está ONLINE y SMART dice PASSED, el disco está sano.” Es una historia reconfortante porque te permite no hacer nada.
Y no hacer nada es la estrategia operacional más popular en la Tierra.

Semanas después, un disco en ese vdev comenzó a acumular Current_Pending_Sector y Offline_Uncorrectable. Nadie lo vio porque nadie tenía dashboards para atributos SMART en bruto,
solo el bit de overall-health. Luego un segundo disco del mismo RAIDZ mostró timeouts de lectura durante una ventana de ingest concurrida.

ZFS hizo lo que pudo, pero RAIDZ no es magia cuando varios miembros están enfermos. El pool se degradó, el rendimiento colapsó y la actividad de scrub/resilver compitió con el I/O de producción.
El incidente no fue una pérdida de datos instantánea—fue peor en sentido corporativo: una caída lenta y ruidosa con errores parciales y mucho “reintente más tarde”.

Después del incidente, la solución fue aburrida: alertar sobre los atributos SMART en bruto que importan, alertar sobre errores corregidos de ZFS y requerir una decisión humana cuando cualquiera de los dos cambie.
El equipo no eliminó las fallas de disco. Eliminó la sorpresa.

Microhistoria 2: La optimización que salió mal

Una firma de servicios financieros quería scrubs más rápidos. Habían leído que aumentar el throughput del scrub ayuda a detectar errores latentes antes.
Cierto. También querían reducir “ventanas de mantenimiento”, así que subieron la paralelización, programaron scrubs en horario laboral y ajustaron el sistema para priorizar I/O de scrub.

Los primeros scrubs fueron ultrarrápidos. Todos se felicitaron. Luego dieron con un vdev con un disco marginal y un backplane SAS borderline.
El scrub agresivo produjo una tormenta: reinicios de enlace, timeouts de comando, reintentos. Los contadores de ZFS crecieron. Los gráficos de latencia se convirtieron en arte abstracto.

La moraleja fue que la optimización cambió el modo de fallo. En lugar de descubrir unos pocos sectores malos suavemente con el tiempo, forzaron al sistema a una carga de alto estrés
que magnificó la inestabilidad del transporte y generó picos de latencia visibles para clientes. Peor aún, su monitorización trató “scrub en progreso” como “ruido de mantenimiento” y suprimió alertas.

La remediación no fue “nunca scrubees”. Fue: scrubea regularmente, pero ajusta el impacto del scrub, no suprimas las alertas equivocadas y trata los errores de transporte durante scrub como señal de máxima prioridad.
Aprendieron también a escalonar scrubs entre hosts y evitar tormentas de I/O sincronizadas.

Acabaron con scrubs más lentos y menos incidentes. Ese intercambio valió la pena. El rendimiento es una característica; la previsibilidad es un producto.

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

Una compañía manejaba un gran pool ZFS para almacenamiento de máquinas virtuales. Nada glamuroso. Hacían tres cosas consistentemente:
scrubs mensuales, revisión semanal de atributos SMART en bruto y nombrado estricto de dispositivos vía /dev/disk/by-id con un mapa vivo de serial-a-bahía.

Un viernes por la tarde, ZFS reportó algunos errores de checksum en un solo disco durante un scrub. SMART mostró UDMA_CRC_Error_Count subiendo, pero sin sectores pendientes.
El ingeniero de guardia no entró en pánico. No pidió un envío de discos de emergencia. Siguió la checklist.

Reasentó el disco, reemplazó el cable SATA y movió el puerto a una línea de controlador diferente. Los errores CRC dejaron de aumentar inmediatamente.
El siguiente scrub completó limpio. Los contadores de ZFS se mantuvieron planos.

El “salvamento” no fue una depuración heroica. Fue tener suficiente línea base y mapeo para que el ingeniero pudiera tocar un cable con confianza sabiendo que era el correcto.
El informe del incidente fue corto. Así sabes que fue un buen día.

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

1) “Errores de checksum de ZFS en un disco, SMART dice PASSED”

Síntoma: ZFS CKSUM incrementa; SMART overall-health pasa.

Causa raíz: SMART overall-health no es sensible; los atributos brutos pueden mostrar pending/uncorrectables. O la corrupción está en el transporte (cable/controlador) no en el medio interno.

Solución: Revisa atributos SMART en bruto y el registro de errores; revisa logs del kernel por resets; si hay pending/UNC, reemplaza el disco. Si predominan patrones de CRC/reset, arregla cableado/HBA primero.

2) “Muchos errores I/O en varios discos en la misma bahía”

Síntoma: Varios miembros de vdev muestran errores de lectura/escritura simultáneamente.

Causa raíz: Componente compartido: backplane, expander, rail de alimentación, HBA, firmware o un mini-SAS flojo.

Solución: Inspecciona la ruta de transporte; intercambia puerto/cable del expander; revisa la distribución de energía. No reemplaces en serie varios discos a menos que los errores SMART del medio lo corroboren.

3) “Errores CRC en aumento pero ZFS está bien”

Síntoma: UDMA_CRC_Error_Count aumenta; ZFS aún no muestra errores.

Causa raíz: La integridad del enlace se está degradando; los reintentos lo enmascaran.

Solución: Reemplaza/asegura cables, limpia conectores, verifica el correcto asiento. Si los CRC dejan de aumentar, probablemente preveniste un incidente futuro de ZFS.

4) “El scrub reparó 0B pero reportó errores”

Síntoma: La salida del scrub muestra errores pero 0 bytes reparados.

Causa raíz: Los errores pueden ser timeouts I/O o fallos de transporte transitorios en lugar de corrupción corregible por checksum.

Solución: Examina zpool status -v y logs del kernel; revisa errores CRC de SMART y resets del controlador. Repara el transporte; vuelve a ejecutar el scrub.

5) “El resilver es lento y se reinicia constantemente”

Síntoma: El progreso del resilver se estanca; los dispositivos se resetean; el pool oscila entre DEGRADED/ONLINE.

Causa raíz: Inestabilidad del transporte o problemas de alimentación. Bajo carga de rebuild, los enlaces marginales fallan más a menudo.

Solución: Estabiliza cables/backplane/energía primero. Considera reducir la carga, pausar trabajos disruptivos y evitar resets repetidos de dispositivos.

6) “Borré errores de ZFS y ahora no sabemos qué pasó”

Síntoma: Contadores históricos desaparecidos; errores intermitentes vuelven; no hay línea temporal.

Causa raíz: zpool clear prematuro borró evidencia antes de arreglar la causa raíz.

Solución: Conserva los contadores hasta después de la remediación y un scrub limpio. Usa notas en el ticket para registrar contadores antes/después y valores SMART en bruto.

7) “Reemplazé un disco y los errores siguieron en la bahía”

Síntoma: El disco nuevo muestra errores inmediatamente, misma bahía/puerto.

Causa raíz: El slot del backplane, el cable o el puerto HBA es el problema.

Solución: Mueve el disco a otra bahía/puerto; reemplaza el cable o el componente del backplane sospechoso. No sigas sacrificando discos a un conector defectuoso.

8) “ZFS reporta errores permanentes, pero SMART parece limpio”

Síntoma: zpool status -v lista archivos con errores permanentes.

Causa raíz: Los datos se escribieron corruptos (p. ej., corrupción transitoria en la ruta) y luego se convirtieron en la “verdad” en la paridad, o la redundancia no pudo reconstruir por múltiples fallos.

Solución: Restaura los datos afectados desde backup/replica; luego investiga transporte e inestabilidad de memoria. Trátalo como un incidente de integridad de datos, no solo como reemplazo de disco.

Listas de verificación / plan paso a paso

Lista A: Cuando recibes una alerta SMART

1. Ejecuta zpool status -xv. Si ZFS ya se queja, prioriza las señales de ZFS.
2. Identifica el dispositivo mediante el symlink /dev/disk/by-id. Registra serial y by-path.
3. Recopila SMART: smartctl -H, -A, -l error, -l selftest.
4. Clasifica la alerta SMART:
   • Pending/uncorrectable/reallocated en aumento: planifica reemplazo de disco.
   • Errores CRC en aumento: arregla cableado/backplane/puerto.
   • Temperatura alta: arregla refrigeración/flujo de aire y vuelve a comprobar; el calor acelera la falla.
5. Ejecuta un scrub si existe redundancia y el impacto operativo es aceptable.
6. Decide: reemplazar disco ahora, programar reemplazo, o remediar transporte y monitorizar.

Lista B: Cuando ZFS reporta errores de checksum o I/O

1. No borres errores. Captura la salida de zpool status -xv en un ticket.
2. Comprueba si los errores aumentan con el tiempo. Si sí, trátalo como incidente activo.
3. Mapea el dispositivo: ls -l /dev/disk/by-id/ y udevadm info.
4. Recopila atributos SMART en bruto y registros de error.
5. Revisa logs del kernel por resets/timeouts y patrones de ruta compartida (múltiples discos).
6. Si hay indicadores de medio: reemplaza usando zpool replace con by-id.
7. Si predominan indicadores de transporte: arregla cableado/HBA/backplane, luego vuelve a scrubear.
8. Después de la remediación: scrub limpio y entonces zpool clear para reiniciar contadores.

Lista C: Antes de declarar victoria

1. Verifica que el pool esté estable: zpool status -x debería estar silencioso.
2. Verifica que no se incrementen contadores durante la carga normal.
3. Verifica que SMART CRC deje de aumentar (si era un problema de transporte).
4. Programa un scrub de seguimiento (o confirma que un scrub finalizó limpio tras la reparación).
5. Actualiza la documentación serial-a-bahía para que la próxima vez sea más rápido y menos creativo.

Preguntas frecuentes

1) ¿A cuál debo confiar más: ZFS o SMART?

Para la corrección de datos, confía más en ZFS. Para predecir un disco que va a fallar pronto, los atributos SMART en bruto ayudan.
El PASSED general de SMART no tiene derecho a vetar los errores de checksum de ZFS.

2) ¿Reemplazo un disco tras un único error de checksum?

No siempre. Un único error de checksum corregido puede ser transitorio. El movimiento correcto es: ejecutar un scrub, inspeccionar atributos SMART en bruto,
revisar logs de transporte. Si los errores se repiten o SMART muestra pending/uncorrectables, reemplaza. Si los CRC aumentan, arregla el cableado.

3) ¿Cuál es la diferencia entre scrub y resilver de ZFS para diagnóstico?

Scrub lee y verifica los datos existentes en el pool; es una auditoría periódica de integridad. Resilver reconstruye datos sobre un dispositivo reemplazado.
Ambos estresan los discos, pero resilver es más urgente y riesgoso si el transporte es inestable porque está reconstruyendo estado bajo carga.

4) ¿Por qué veo errores de ZFS pero “errors: No known data errors”?

Porque ZFS puede corregir ciertas fallas usando redundancia y aun así registra que tuvo que hacerlo. “No known data errors” significa que cree que los datos de usuario son consistentes ahora.
No significa que el hardware esté sano.

5) ¿Son los errores UDMA CRC motivo para RMA de un disco?

Normalmente no. Los CRC implican la integridad del enlace SATA: cable, conector, backplane, EMI. Reemplaza el cable, reasienta, mueve puertos.
Si CRC deja de aumentar, lo solucionaste. Si el disco también tiene pending/UNC, entonces sí, el disco podría estar fallando también.

6) ¿Cómo evito reemplazar el disco equivocado?

Usa nombrado persistente y mapeo. Opera con /dev/disk/by-id. Confirma el serial con smartctl -i y mapea a la bahía con by-path o herramientas de enclosure.
Nunca confíes en nombres /dev/sdX para mantenimiento planificado.

7) ¿Debo ejecutar pruebas SMART largas en discos de producción?

Sí, pero con intención. Las pruebas largas pueden añadir carga y latencia. Progámalas, escalónalas y no las ejecutes cuando el pool esté degradado a menos que estés recopilando evidencia urgente.
Si ya tienes indicadores fuertes de fallo, reemplaza en vez de “probar hasta que falle peor”.

8) ¿Qué hago si SMART muestra sectores pendientes pero ZFS no tiene errores?

Los sectores pendientes significan que el disco no pudo leer algunos datos de forma fiable. ZFS puede no haber tocado esos bloques recientemente.
Ejecuta un scrub para forzar lecturas. Si pending/uncorrectable persiste o aumenta, reemplaza el disco mientras la redundancia esté intacta.

9) ¿La RAM defectuosa puede causar errores de checksum de ZFS que parezcan problemas de disco?

Sí, aunque es menos común de lo que muchos afirman cuando quieren evitar reemplazar un disco. Si los errores de checksum aparecen en múltiples dispositivos o se mueven,
considera la memoria/CPU/estabilidad PCIe del host. ECC ayuda; no te hace inmortal.

10) ¿Por qué los errores se disparan durante scrubs?

El scrub lee todo. Errores latentes de medio que nunca se tocaron bajo la carga normal se ejercitan de pronto.
Los problemas de transporte también aparecen porque el throughput sostenido aumenta la probabilidad de resets/timeouts.
Un scrub que revela errores está cumpliendo su función; el error es ignorar los resultados.

Conclusión: próximos pasos que puedes hacer hoy

Correlacionar advertencias SMART con errores ZFS no se trata de coleccionar más gráficos. Se trata de convertir dos fuentes de verdad imperfectas en una decisión.
Tus mejores resultados son aburridos: un intercambio de disco planeado, un cable reemplazado, un scrub que termina limpio y un ticket que se cierra sin drama.

1. Estandariza la identificación: opera ZFS usando /dev/disk/by-id y mantén un mapa serial-a-bahía.
2. Alerta sobre atributos SMART significativos: tendencias de pending, uncorrectable, reallocated; errores CRC para transporte.
3. Trata los errores corregidos de ZFS como señales accionables: no emergencias, pero tampoco ruido de fondo.
4. Scrubea regularmente e intencionalmente: escalona scrubs, vigila errores durante el scrub y no suprimas las alertas que realmente necesitas.
5. Borra contadores solo después de la reparación: evidencia primero, cosmética después.

La meta no es cero alertas. La meta es menos sorpresas, y menos fines de semana aprendiendo la firma acústica exacta de un disco que muere.