ZFS Scrub vs SMART Long Test: qué detectan

El modelo mental: quién revisa qué

Empieza por la pila, porque la confusión siempre es sobre capas:

• SMART long test es la unidad comprobándose a sí misma: superficie del medio, corrección interna de errores, posicionamiento de cabezas, estabilidad de lectura y lo que el firmware del proveedor considere importante. Es centrado en el dispositivo.
• ZFS scrub es ZFS leyendo tus datos y verificándolos frente a checksums de extremo a extremo almacenados en metadatos, y luego reparando desde la redundancia si es posible. Es centrado en los datos.

Esos puntos de vista se solapan, pero no lo suficiente como para confiar en uno solo. SMART puede decirte que un disco está degradándose incluso cuando ZFS aún no ha tocado las zonas débiles. ZFS puede decirte que los datos que te importan están corruptos aunque SMART insista en que el disco “PASSED”.

Operativamente: SMART es una señal predictiva. Scrub es una garantía de corrección. Quieres ambos porque los sistemas en producción fallan en múltiples dimensiones, a menudo al mismo tiempo.

Una cita que debería estar tatuada en cada runbook de almacenamiento: “Hope is not a strategy.” — James Cameron. El almacenamiento es donde la esperanza va a morir.

Qué encuentra (y repara) un ZFS scrub

Qué hace un scrub, con precisión

Un ZFS scrub es una lectura intencional de todo el pool sobre bloques asignados, verificando el checksum de cada bloque. Si ZFS encuentra una discrepancia, intenta reparar obteniendo una copia buena desde la redundancia (mirror/RAIDZ) y reescribiendo la mala. Esa reparación no es mágica. Depende de:

• Que exista redundancia y esté sana.
• Que la anomalía esté limitada a un lado de la redundancia (o al menos no supere la paridad).
• Que la corrupción sea detectable (mismatch de checksum) en lugar de invisible (escribiste bytes equivocados y les calculaste el checksum).

Fallos que los scrubs detectan bien

Los scrubs son excelentes para detectar corrupción silenciosa de datos dentro del trayecto protegido por ZFS. Eso incluye:

• Bit rot / sectores latentes: sectores que se han vuelto ilegibles o devuelven datos incorrectos más tarde.
• Lecturas erróneas que “parecen exitosas” para el disco: el disco devuelve datos, pero están mal. ZFS lo detecta porque el checksum no coincide.
• Problemas de cableado/controlador que resultan en transferencias corrompidas (a veces aparecen como errores de checksum en lugar de errores de lectura).
• Errores de lectura no corregibles durante el scrub: ZFS los registra y puede reparar si existe redundancia.

Fallos que los scrubs no detectan bien

Un scrub no es un “diagnóstico de disco” y tiene puntos ciegos:

• El espacio no asignado no se lee. Un scrub no probará sectores que ZFS no haya asignado.
• Fallas en la ruta de escritura pueden pasar desapercibidas si se escribieron bytes equivocados y se checksummaron como correctos (esto es más raro de lo que la gente teme, pero existe en el universo de bugs, escrituras dirigidas erróneamente y corrupción de memoria sin ECC).
• Mecánica del disco como búsquedas lentas, cabezas marginales o caché fallando pueden desarrollarse mientras tu conjunto de trabajo actual aún se lee bien.
• Timeouts transitorios pueden no manifestarse durante el timing del scrub; o pueden aparecer solo bajo un patrón de IO distinto.

Realidad irónica: un scrub es como auditar los gastos de tu empresa. Encuentra fraude en los recibos presentados, no en lo que nadie presentó.

Qué significa realmente “scrub repaired X”

Si zpool status indica que un scrub “reparó” bytes, has aprendido exactamente una cosa: el pool sirvió al menos una copia mala de un bloque, y ZFS encontró otra copia buena. Es una victoria de corrección, pero también una señal de alerta. Es evidencia de un componente fallando o de un problema en la ruta. Tu trabajo es averiguar cuál, antes de que se convierta en una falla multi-disco durante un resilver.

Scrub vs resilver, porque la gente las confunde

Un scrub lee y valida los datos asignados en su lugar. Un resilver es la reconstrucción después de reemplazar o volver a conectar un dispositivo, copiando los datos necesarios para restaurar la redundancia. Ambos implican lecturas intensas. Ambos pueden desencadenar sectores latentes. Pero la intención difiere:

• Scrub: “probar que los datos existentes del pool son correctos.”
• Resilver: “reconstruir la redundancia y repoblar un dispositivo.”

Si solo te enteras de errores latentes durante un resilver, te enteraste demasiado tarde.

Qué encuentra (y predice) una prueba SMART long

Qué hacen las pruebas SMART long

Las autopruebas SMART son diagnósticos dirigidos por firmware. Una prueba long (extendida) típicamente lee la mayor parte o toda la superficie del dispositivo (la implementación varía mucho), poniendo a prueba la capacidad del disco para leer sectores y corregir errores internamente. A diferencia del scrub de ZFS, no verifica el checksum de tus datos. Verifica la capacidad del propio disco para recuperar sectores con su ECC interno y mecanismos de remapeo.

Qué detecta bien SMART

• Degradación del medio (sectores pendientes, sectores realocados, errores no corregibles).
• Inestabilidad de lectura que los discos ocultan hasta que empeora (mayor corrección de errores, reintentos, lecturas lentas).
• Patrones de estrés térmico correlacionados con fallos (historial de temperatura, eventos de sobretemperatura).
• Errores a nivel de interfaz (los errores CRC a menudo indican problemas de cableado/backplane, no del medio).

Qué no es bueno SMART (especialmente en 2025)

SMART no es un oráculo. Es el firmware del proveedor diciéndote cómo se siente hoy. Problemas:

• La semántica de los atributos varía entre proveedores. Un valor bruto puede ser “real” en un disco y “aritmética del proveedor” en otro.
• SMART “PASSED” es un consuelo sin sentido. Muchos discos fallan sin disparar la bandera de salud general.
• Las pruebas long pueden no cubrir todos los LBAs en algunos dispositivos, o pueden ser interrumpidas por peculiaridades de gestión de energía.
• El comportamiento de los SSD difiere: “sectores malos” se vuelven un problema de la capa de traducción, y algunas fallas se presentan como muerte súbita, no degradación gradual.

Las pruebas SMART long siguen valiendo la pena. Solo no las uses como carta de libertad cuando ZFS empieza a chillar.

Broma #1: SMART “PASSED” es como un manager diciendo “todo parece bien” cinco minutos antes de que cambie el organigrama.

Cómo mapear fallos SMART a decisiones operativas

SMART te da advertencia temprana, pero la decisión no siempre es “reemplazar de inmediato.” Disparadores típicos:

• Cualquier Offline_Uncorrectable no cero o tendencia creciente: programa reemplazo. Ese disco está produciendo fallos duros.
• Reallocated_Sector_Ct en aumento: reemplaza pronto, especialmente si va acompañado de sectores pendientes.
• Current_Pending_Sector no cero: trátalo como urgente; un scrub/resilver probablemente los encontrará y fallará lecturas.
• UDMA_CRC_Error_Count en aumento: a menudo reemplaza primero cable/backplane, no el disco.

Solapamientos, huecos y por qué necesitas ambos

El solapamiento: cuando ambas herramientas coinciden

A veces la vida es simple. Un disco está fallando, lanza errores de lectura, SMART muestra sectores pendientes y un scrub informa errores de lectura o checksum. Genial. Reemplazas el disco y sigues adelante.

Hueco #1: SMART parece limpio, ZFS reporta errores de checksum

Esto es común y asusta a la gente. No debería. Los checksums son de extremo a extremo: pueden detectar corrupción desde la RAM, controladores, HBAs, cableado, expanders, backplanes, firmware y travesuras cósmicas. SMART solo sabe lo que el disco ve internamente.

Si ZFS dice “checksum error,” no asumas que el disco miente. Asume que la ruta es culpable hasta que se demuestre lo contrario. Los problemas de cableado suelen manifestarse como errores CRC en SMART (especialmente SATA), pero no siempre a tiempo.

Hueco #2: SMART se ve mal, ZFS está tranquilo

Este es el escenario de “fallo latente”. El disco está degradándose en áreas que ZFS no ha leído recientemente (datos fríos, datasets escasos, bloques no asignados). ZFS está tranquilo porque nadie le ha pedido leer esos sectores. Un scrub probablemente lo encontrará—si el scrub se ejecuta antes de que un resilver fuerce lecturas de toda la franja bajo presión.

Hueco #3: los scrubs pasan, pero aún pierdes datos

Los scrubs validan lo que existe y es legible. No garantizan:

• Que tus copias de seguridad sean válidas.
• Que tu hardware no fallará catastróficamente mañana.
• Que tengas redundancia apropiada para tu dominio de falla (mismo lote de discos, mismo backplane, mismo bug de firmware).

Los scrubs reducen el riesgo. No anulan la física.

Mi regla con sesgo

Si ejecutas ZFS en producción y no estás programando scrubs y pruebas SMART long, no estás “ahorrando desgaste.” Estás ahorrando ignorancia para más tarde, con intereses.

Datos interesantes y contexto histórico

• ZFS incorporó checksums de extremo a extremo desde el primer día (era Solaris), explícitamente para abordar la corrupción silenciosa que los sistemas de archivos tradicionales no podían detectar.
• El término “scrub” se popularizó en almacenamiento vía RAID scrubbing: lecturas periódicas para encontrar sectores latentes antes del tiempo de reconstrucción, cuando menos te conviene tener sorpresas.
• SMART data de los años 90, con implementaciones específicas de proveedores antes de que ATA estandarizara un conjunto básico de comportamientos.
• La bandera de salud general “PASSED” de SMART es notoriamente conservadora; muchos fallos ocurren sin que se active, por eso los SREs vigilan atributos y tendencias.
• La información de salud ATA y SCSI/SAS divergió: SAS usa log pages y mecanismos de “self-test” que se sienten familiares pero no son idénticos a los atributos SMART de ATA.
• Los discos modernos pueden reintentar lecturas de forma invisible, convirtiendo un “sector malo” en “sector lento”, que aparece primero como picos de latencia, no errores inmediatos.
• Los scrubs de ZFS solo leen bloques asignados, así que un pool mayoritariamente vacío puede ocultar áreas malas hasta que los datos crezcan o se reubiquen.
• Los controladores de SSD remapean constantemente; los “sectores” son lógicos, y las fallas pueden ser súbitas (firmware, corrupción de metadatos FTL) en lugar de decadencia gradual.
• El comportamiento de resilver en RAIDZ históricamente requería más lectura que los mirrors; las funciones nuevas de ZFS como el resilvering secuencial ayudan, pero las reconstrucciones aún estresan la flota.

Guion de diagnóstico rápido

Esta es la secuencia de “deja de discutir en el chat y encuentra el cuello de botella”. Úsala cuando veas errores de checksum, errores de lectura, IO lento o un scrub que tarda una eternidad.

Primero: ¿el pool es actualmente seguro?

• Revisa zpool status -v: ¿algún vdev está degradado, algún dispositivo en fault, errores irrecuperables?
• Si la redundancia está comprometida (mirror degradado, RAIDZ con un disco muerto), prioriza restaurar la redundancia sobre ajustar rendimiento.

Segundo: ¿es un disco, la ruta o el host?

• Disco: SMART muestra pendiente/uncorrectable/reallocated en aumento; ZFS muestra errores de lectura en ese dispositivo.
• Ruta: SMART muestra errores CRC; ZFS muestra errores de checksum en múltiples discos detrás del mismo HBA/backplane; dmesg muestra resets de enlace/timeouts.
• Host: errores de memoria, eventos ECC, warnings del kernel o una actualización reciente de driver/firmware.

Tercero: ¿estás limitado por IO o por latencia ahora?

• Usa zpool iostat -v 1 para ver qué vdev está saturado.
• Usa iostat -x para detectar un dispositivo con await/util elevados.
• Durante un scrub: espera lecturas intensas; si el sistema colapsa, limita la velocidad o reprográmalo mejor.

Cuarto: Decide—reparar, reemplazar o reconectar

• Si es medio: reemplaza el disco y luego ejecuta scrub tras el resilver.
• Si es ruta: repara cableado/backplane/HBA primero, luego scrub para confirmar que los contadores de error dejan de aumentar.
• Si es host: valida RAM (registros ECC), revisa cambios recientes y considera aislar el nodo.

Broma #2: La forma más rápida de “arreglar” errores de checksum es dejar de comprobar—esto también es la forma de convertirte en una advertencia viva.

Tareas prácticas con comandos, significado de salidas y la decisión que tomas

Todos los ejemplos asumen un host Linux con ZFS y smartmontools instalados. Sustituye nombres de dispositivos y nombres de pools por los de tu entorno. El punto es el flujo de trabajo: observar → interpretar → decidir.

Task 1: Comprobar estado de scrub y si los errores siguen acumulándose

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Determine if the device needs to be replaced, and clear the errors
  see: zpool(8)
  scan: scrub repaired 128K in 02:13:44 with 0 errors on Tue Dec 24 03:11:09 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       2     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0

errors: No known data errors

Qué significa: el scrub reparó datos y un disco tiene errores de lectura (READ=2). ZFS lo arregló usando paridad, así que no hay errores de datos conocidos. Esto es un aviso.

Decisión: obtener SMART del disco afectado, comprobar cableado/logs del HBA y planear reemplazo si SMART muestra pendientes/uncorrectable o si los errores de lectura se repiten.

Task 2: Ver si los errores de checksum están localizados o repartidos

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 01:00:03 2025
        2.11T scanned at 1.02G/s, 1.44T issued at 711M/s, 18.2T total
        0B repaired, 0.00% done, 06:59:12 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-Samsung_SSD_...     ONLINE       0     0     0
            ata-Samsung_SSD_...     ONLINE       0     0     17

Qué significa: los errores CKSUM están en un lado del mirror. Eso apunta más a ese dispositivo o su ruta (cable/backplane/HBA) que a una corrupción de pool general.

Decisión: revisar SMART y los logs del kernel para ese dispositivo; si los CRC aumentan, sospecha del cableado; si los errores de medio aumentan, reemplaza.

Task 3: Borrar errores de ZFS solo después de arreglar la causa

cr0x@server:~$ zpool clear tank

Qué significa: los contadores se reinician. Esto no es una reparación; es una forma de confirmar si el problema vuelve.

Decisión: borrar solo después de reemplazar hardware o arreglar la ruta; luego monitorear si reaparecen durante un scrub posterior.

Task 4: Iniciar un scrub intencionalmente (y no lo hagas al mediodía el día de nómina)

cr0x@server:~$ sudo zpool scrub tank

Qué significa: scrub en cola/iniciado. En pools ocupados, competirá con cargas de trabajo.

Decisión: si el scrub causa dolor de latencia, ajusta la programación y considera elecciones con zfs set (recordsize) por separado; no desactives los scrubs.

Task 5: Vigilar el progreso del scrub e identificar el vdev lento

cr0x@server:~$ zpool iostat -v tank 1
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        9.12T  8.97T    512     44   820M  23.1M
  raidz2-0                  9.12T  8.97T    512     44   820M  23.1M
    ata-WDC_WD140EDFZ-1     -      -        82      7   131M  5.8M
    ata-WDC_WD140EDFZ-2     -      -        85      6   138M  5.2M
    ata-WDC_WD140EDFZ-3     -      -        19      6    12M  5.4M
    ata-WDC_WD140EDFZ-4     -      -        86      6   139M  5.3M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: un disco entrega mucho menos ancho de banda de lectura que sus pares (WD140EDFZ-3). Ese es probablemente tu cuello de botella o el que está haciendo muchos reintentos.

Decisión: inspeccionar SMART y logs del kernel para ese disco; planear reemplazo si está lento por reintentos de medio.

Task 6: Ejecutar una prueba SMART long en un disco SATA

cr0x@server:~$ sudo smartctl -t long /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== 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 255 minutes for test to complete.
Test will complete after Wed Dec 25 06:14:02 2025

Qué significa: el disco aceptó la prueba; se ejecuta en firmware mientras el IO continúa (pero puede impactar el rendimiento).

Decisión: programa las pruebas long en horas no pico; en arrays ocupados, espárcelas para evitar picos de latencia sincronizados.

Task 7: Leer resultados de self-test SMART y decidir si reemplazar ya

cr0x@server:~$ sudo smartctl -a /dev/sda | sed -n '/Self-test execution status/,$p' | head -n 25
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever been run.
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       00%     18432         723451233
# 2  Extended offline    Completed without error       00%     18390         -

Qué significa: ocurrió una falla de lectura en un LBA. Eso no es “monitorearlo”, es “este disco no puede leer parte de su superficie de forma fiable”.

Decisión: reemplaza el disco. Antes de reemplazar, considera forzar lecturas en ZFS (scrub) para ver si la redundancia puede reescribir los bloques malos, pero no apuestes la producción a ello.

Task 8: Revisar atributos SMART clave (HDD) en busca de señales latentes

cr0x@server:~$ sudo smartctl -A /dev/sda | egrep 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count'
  5 Reallocated_Sector_Ct   0x0033   188   188   140    Pre-fail  Always       -       24
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       3
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Qué significa: existen sectores pendientes y no corregibles. Ya ocurrieron sectores realocados. CRC está limpio, por lo que probablemente sea medio, no cableado.

Decisión: reemplaza el disco y ejecuta un scrub tras el resilver para verificar que no queden errores residuales.

Task 9: Detectar problema de cableado/backplane vía errores CRC

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

Qué significa: los errores CRC son a nivel de transporte. Los datos se corrompieron o tuvieron reintentos entre disco y controlador. Los discos a menudo permanecen “healthy” mientras el enlace es inestable.

Decisión: vuelve a conectar/reemplaza el cable, inspecciona conectores del backplane, cambia de puerto en el HBA. No reemplaces el disco primero a menos que disfrutes perder tiempo.

Task 10: Correlacionar errores de dispositivos ZFS con dispositivos físicos

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WDC_WD140EDFZ | head
lrwxrwxrwx 1 root root  9 Dec 26 00:41 ata-WDC_WD140EDFZ-11A0VA0_V9J0ABCD -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 00:41 ata-WDC_WD140EDFZ-11A0VA0_V9J0EFGH -> ../../sdd

Qué significa: mapeas los nombres by-id que reporta ZFS a dispositivos del kernel. Esto importa al intercambiar discos; /dev/sdX no es estable.

Decisión: usa siempre /dev/disk/by-id en vdevs ZFS y en tu procedimiento de reemplazo.

Task 11: Revisar logs del kernel por resets de enlace y timeouts (problemas de ruta)

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata[0-9]+|link is slow|hard resetting link|I/O error|blk_update_request' | tail -n 12
[Wed Dec 25 02:14:11 2025] ata7: hard resetting link
[Wed Dec 25 02:14:12 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 25 02:14:14 2025] blk_update_request: I/O error, dev sdc, sector 723451233 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[Wed Dec 25 02:14:14 2025] ata7.00: failed command: READ FPDMA QUEUED

Qué significa: reset de enlace + errores de lectura. Podría ser un disco moribundo, podría ser una conexión inestable. Combina con CRC y sectores pendientes en SMART para decidir.

Decisión: si CRC crece, trátalo como ruta; si pending/uncorrectable crece, trátalo como medio. Si ambos crecen, reemplaza el disco y el cable/backplane, porque estás en la zona divertida.

Task 12: Identificar si ZFS tiene errores permanentes de datos (el peor escenario)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Restore the file in question if possible.
  scan: scrub completed after 07:44:02 with 0 errors on Thu Dec 26 04:12:09 2025
config:

        NAME                      STATE     READ WRITE CKSUM
        tank                      ONLINE       0     0     0
          raidz1-0                ONLINE       0     0     0
            ata-ST8000DM-1        ONLINE       0     0     0
            ata-ST8000DM-2        ONLINE       0     0     0
            ata-ST8000DM-3        ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        tank/data/db/pg_wal/000000010000000A000000FE

Qué significa: la redundancia no pudo reparar un bloque corrupto. ZFS puede decirte qué archivo fue afectado. Esto es exactamente por lo que ejecutas ZFS.

Decisión: restaurar desde backup o replicación a nivel de aplicación; investigar por qué la redundancia no fue suficiente (RAIDZ1, múltiples errores de lectura, issues silenciosos previos). Considera aumentar la redundancia para esta carga.

Task 13: Ver qué datasets consumen más tiempo de scrub (método indirecto)

cr0x@server:~$ sudo zfs list -o name,used,logicalused,recordsize,compression -S used | head -n 10
NAME                 USED  LUSED  RECSIZE  COMPRESS
tank/data            6.12T  6.70T  128K     lz4
tank/backups         2.44T  2.80T  1M       lz4
tank/vm              1.91T  2.10T  16K      lz4
tank/home            312G   330G   128K     lz4

Qué significa: los datasets con mucho uso dominan el IO del scrub. Un recordsize pequeño (como 16K para VMs) puede incrementar metadata y overhead de IO.

Decisión: no “optimices” recordsize durante un incidente. Pero toma nota de qué datasets podrían justificar pools separados o layouts distintos si los scrubs son constantemente dolorosos.

Task 14: Ejecutar SMART long en un dispositivo NVMe (self-test/log difiere)

cr0x@server:~$ sudo smartctl -a /dev/nvme0
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990 PRO 2TB
Serial Number:                      S7HBNX0T123456A
Firmware Version:                   5B2QJXD7
SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Percentage Used:                    2%
Data Units Read:                    12,384,921
Data Units Written:                 9,221,114
Media and Data Integrity Errors:     0
Error Information Log Entries:       0

Qué significa: la salud NVMe es diferente: percentage used, media errors, critical warnings. No existe la historia de “sectores pendientes”; las fallas a menudo se muestran mediante media errors o problemas súbitos de controlador.

Decisión: rastrea media/data integrity errors y entradas del error log en NVMe a lo largo del tiempo; reemplaza ante cualquier tendencia ascendente, no solo cuando “critical warning” cambie.

Tres micro-historias del mundo corporativo

Micro-historia 1: El incidente causado por una asunción equivocada

Tenían una regla ordenada: “Si SMART dice PASSED, el disco está bien.” Estaba escrita en la wiki de on-call, se repetía en los handoffs y se usaba para cerrar tickets rápidamente. El pool era ZFS mirrors en SSD SATA en una caja 2U, respaldando un conjunto de servicios internos que nunca fueron “críticos” hasta que lo fueron.

Un día, ZFS empezó a reportar errores de checksum en una pata del mirror. No eran errores de lectura. No eran errores de escritura. Solo incrementos de checksum durante la operación normal. SMART parecía limpio. El equipo borró errores, ejecutó un scrub, vio “repaired 0B” y siguió. El contador de checksum subió otra vez. Mismo guion: borrar, encogerse de hombros, posponer.

Entonces hubo una actualización de firmware en el HBA. Bajo carga, la caja empezó a loguear resets de enlace. De pronto, la pata del mirror con errores de checksum quedó no disponible durante tráfico pico. El lado restante asumió la carga, pero el pool estaba a un mal día de convertirse en una semana realmente mala.

El postmortem fue directo: la asunción equivocada no era “SMART es inútil”. La asunción equivocada era que SMART es la herramienta correcta para validar la corrección de datos. Los errores de checksum eran un problema de ruta—probablemente cableado/backplane marginal que solo aparecía bajo ciertos patrones de IO. SMART no lo vio porque el disco en sí no estaba fallando. ZFS lo vio porque los datos que llegaban no coincidían con el checksum. La solución fue aburrida: reemplazar cables, volver a asentar conectores del backplane y dejar de borrar contadores hasta entender la causa. Después de eso, los errores de checksum cesaron por completo.

Lección: SMART PASSED no anula los checksums de ZFS. Cuando discrepan, investiga el bus.

Micro-historia 2: La optimización que salió mal

Una empresa distinta ejecutaba enormes pools RAIDZ2 ZFS para backups y almacenamiento de objetos. Los scrubs se programaban mensualmente porque “son pools de datos fríos”, y las pruebas SMART long estaban deshabilitadas porque “ralentizan el IO.” Alguien decidió ser ingenioso: los scrubs deberían ser trimestrales, porque los pools eran grandes y los scrubs molestaban a los stakeholders.

Durante un tiempo, no pasó nada. Ese es el truco. Los sectores latentes no envían invitación de calendario. Entonces un disco falló y arrancaron un resilver. Durante el resilver, otro disco empezó a lanzar errores de lectura en una región que no se había tocado en meses. El pool siguió cojeando, pero el resilver se ralentizó porque el disco estaba reintentando lecturas. Finalmente, ZFS declaró errores irrecuperables en un puñado de objetos de backup.

Esos eran “solo backups,” hasta que dejaron de serlo. Cuando más tarde necesitaron restaurar producción, un subconjunto de puntos de recuperación más antiguos estaba corrupto. El equipo de aplicaciones tuvo que elegir entre restaurar un snapshot más nuevo (más pérdida de datos) o reconstruir el estado manualmente (más dolor). Hicieron ambas cosas, mal.

La optimización se basó en un malentendido: los scrubs no son “mantenimiento opcional.” Son cómo ZFS convierte fallos latentes desconocidos en bloques reparados mientras todavía existe redundancia y el pool está estable. El tiempo de resilver es el peor momento para descubrir sectores ilegibles.

Revirtieron a scrubs mensuales y escalonaron las pruebas SMART long semanalmente entre dispositivos. Los scrubs seguían molestando a stakeholders, pero menos que la pérdida de datos molestaba a los ejecutivos. Así se aclaran las prioridades.

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

Un equipo que manejaba un clúster de virtualización multi-tenant tenía una rutina simple y poco sexy: pruebas SMART long semanales escalonadas por host, scrubs ZFS mensuales escalonados por pool y un dashboard que trazaba deltas de tres atributos SMART: pending sectors, offline uncorrectable y CRC errors. Nada de machine learning sofisticado. Solo tendencias.

Un lunes, el dashboard mostró un pequeño pero real incremento en UDMA_CRC_Error_Count en dos discos detrás del mismo backplane. Los discos no tenían sectores pendientes ni realocados. ZFS estaba limpio. El rendimiento estaba bien. Nadie hacía page. Este es el momento donde los equipos o ignoran o parecen paranoicos.

Programaron una breve ventana de mantenimiento, volvieron a asentar el conector del backplane y reemplazaron dos cables SATA. Los CRC dejaron de incrementarse. Sin incidentes. Sin downtime más allá de la ventana. Todo el mundo lo olvidó, que es el resultado correcto del mantenimiento preventivo.

Tres semanas después, otro host en el mismo rack mostró un patrón CRC similar. Cambiaron cables de nuevo y encontraron un problema de lote con un modelo específico de cable. Los reemplazaron proactivamente en la flota durante ventanas de mantenimiento normales. Aún sin incidentes.

Esto es lo que parece el trabajo de confiabilidad bien hecho: tranquilo, repetitivo y algo aburrido. Ese es el objetivo.

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

1) Síntoma: aumentan errores de checksum en ZFS, pero SMART parece bien

Causa raíz: corrupción en el transporte o reintentos (cableado/backplane/HBA), ocasionalmente problemas de memoria/driver.

Solución: revisar contadores CRC en SMART, dmesg por resets de enlace, volver a asentar/reemplazar cables, mover el disco a otro puerto, considerar rollback de firmware/driver del HBA.

2) Síntoma: el scrub “reparó” datos y lo tratas como resuelto

Causa raíz: errores latentes de medio o inestabilidad intermitente de lectura; tuviste suerte porque la redundancia aún funcionó.

Solución: identificar qué dispositivo registró errores de lectura/checksum; ejecutar SMART long; reemplazar el disco sospechoso si los atributos son no cero o los errores se repiten.

3) Síntoma: los scrubs tardan una eternidad y matan la latencia

Causa raíz: scrubs ejecutándose en horas punta; un dispositivo lento que limita un vdev RAIDZ; discos SMR en la mezcla; o discos haciendo reintentos internos pesados.

Solución: programar scrubs fuera de pico; escalonar entre pools; identificar discos lentos con zpool iostat -v; reemplazar el rezagado; evitar SMR donde esperas lecturas consistentes bajo carga.

4) Síntoma: SMART muestra sectores pendientes, pero el scrub de ZFS está limpio

Causa raíz: los sectores problemáticos están en áreas que ZFS no ha leído recientemente (o nunca).

Solución: trata sectores pendientes como urgentes; ejecuta un scrub (o lecturas dirigidas) para forzar detección/ reparación; planifica reemplazo del disco.

5) Síntoma: “Permanent errors” en zpool status

Causa raíz: la corrupción superó la redundancia, o la corrupción se escribió y se checksummó como “válida”, o múltiples dispositivos devolvieron datos malos.

Solución: restaurar archivos afectados desde backup/replicación; aumentar el diseño de redundancia (mirrors/RAIDZ2/3), y auditar integridad de memoria (ECC) y firmware de controladores.

6) Síntoma: la prueba SMART long falla o aborta repetidamente

Causa raíz: problemas de medio; resets del dispositivo; peculiaridades de gestión de energía; o el dispositivo está detrás de un controlador que bloquea el passthrough SMART.

Solución: ejecutar SMART usando el tipo de dispositivo correcto (-d sat, -d megaraid,N, etc.); revisar dmesg; reemplazar disco ante fallos genuinos de lectura.

7) Síntoma: reemplazas un disco “malo” pero los errores continúan en el nuevo

Causa raíz: la ruta era el problema (cable/backplane/HBA), no el disco.

Solución: investigar errores CRC y resets de enlace; cambiar puerto/HBA; validar alimentación; no sigas sacrificando discos a los dioses del cable.

8) Síntoma: el resilver falla con errores de lectura desde discos sobrevivientes

Causa raíz: sectores latentes descubiertos bajo estrés de reconstrucción porque los scrubs no eran lo bastante frecuentes.

Solución: aumentar frecuencia de scrubs; reemplazar discos marginales antes según tendencias SMART; considerar mayor redundancia y anchos de vdev más pequeños para gestionar el riesgo de reconstrucción.

Listas de verificación / plan paso a paso

Política base (ZFS en producción)

1. Habilita scrubs ZFS programados por pool (mensual es un buen valor por defecto; más frecuente para datos calientes o pools HDD grandes).
2. Programa pruebas SMART long escalonadas entre discos (semanal o quincenal; tests cortos diarios si quieres señal rápida).
3. Alerta sobre errores ZFS: cualquier READ/WRITE/CKSUM por dispositivo no cero, y cualquier byte “repaired”.
4. Alerta sobre tendencias SMART: sectores pendientes, offline uncorrectable, crecimiento de realocados, crecimiento de CRC, y errores de integridad media NVMe.
5. Documenta el procedimiento de reemplazo usando /dev/disk/by-id e incluye un paso de verificación scrub/resilver post-reemplazo.

Cuando ZFS reporta errores de checksum

1. Ejecuta zpool status -v, identifica dispositivo(s) y si la redundancia está degradada.
2. Revisa dmesg por resets/timeouts alrededor de las marcas de tiempo.
3. Revisa atributos SMART, especialmente CRC, pending, uncorrectable y reallocated.
4. Si CRC está aumentando: arregla cableado/backplane/HBA primero.
5. Si pending/uncorrectable está aumentando: reemplaza el disco.
6. Después de la reparación: zpool clear, luego scrub, y verifica que los contadores se mantengan en cero.

Cuando una prueba SMART long falla pero ZFS está tranquilo

1. Confirma la falla en los logs de self-test y atributos SMART.
2. Ejecuta un scrub ZFS para forzar lecturas de datos asignados; vigila errores de lectura/checksum.
3. Reemplaza el disco incluso si ZFS aún no se queja, si la long test muestra fallos de lectura o no corregibles.
4. Tras reemplazo/resilver: scrubea otra vez para confirmar salud del pool.

Consejos de programación que no te harán odiar

• Escalona todo: no scrubees todos los pools a las 01:00 del domingo y ejecutes SMART long tests a las 01:05. Te crearás tu propio incidente.
• Prefiere “lento y predecible” sobre “lento aleatorio”: un scrub programado es molesto; un resilver no programado define tu carrera.
• Rastrea tendencias de duración: si el tiempo de scrub se duplica mes a mes, algo cambió (capacidad, carga, disco lento o regresión de firmware).

Preguntas frecuentes

1) Si ejecuto scrubs ZFS regularmente, ¿sigo necesitando pruebas SMART long?

Sí. Los scrubs validan datos asignados; SMART puede avisar sobre degradación en áreas que ZFS no ha tocado y puede revelar problemas de ruta mediante contadores CRC.

2) Si las pruebas SMART long están limpias, ¿puedo ignorar los errores de checksum de ZFS?

No. Los checksums son de extremo a extremo. SMART puede estar limpio mientras el controlador, cable, backplane o driver corrompe o reintenta IO.

3) ¿Los scrubs “desgastan” las SSD?

Los scrubs son mayormente lecturas; las lecturas tienen un impacto mínimo en el desgaste comparado con las escrituras. El mayor riesgo es el impacto en rendimiento, no la resistencia. Programa adecuadamente.

4) ¿Por qué un scrub reparó datos pero SMART no muestra sectores realocados?

Porque la corrupción puede no haber sido un defecto de medio que dispare remapeo. Podría ser una mala lectura que aún pasó las comprobaciones internas del disco, o un problema de ruta.

5) ¿Con qué frecuencia debo scrubar?

Mensual es un buen valor por defecto para pools HDD. Para pools muy grandes o datos de alta criticidad, considera cada 2–4 semanas. Si los scrubs son dolorosos, arregla la arquitectura, no el calendario.

6) ¿Con qué frecuencia ejecutar pruebas SMART long?

Semanal o quincenal es razonable si escalonas discos. Para laptops o sistemas poco usados, mensual está bien. Para arrays, mantenlo regular y automatizado.

7) ¿Cuál es la diferencia entre READ errors y CKSUM errors en zpool status?

READ errors significan que el dispositivo falló en entregar datos. CKSUM errors significan que los datos se entregaron pero no coincidieron con el checksum—a menudo un problema de ruta o corrupción.

8) ¿Debo reemplazar un disco con algunas reubicaciones (reallocated sectors)?

Reubicaciones puntuales que se estabilizan pueden ser manejables, pero en producción reemplazo por tendencia: si el contador aumenta, o si aparecen pending/uncorrectable.

9) ¿Pueden los scrubs encontrar corrupción en RAM o CPU?

Indirectamente. Si la memoria mala corrompe datos en vuelo o en escritura, ZFS puede detectar discrepancias más tarde. La memoria ECC reduce mucho este riesgo; sin ECC, estás jugando.

10) ¿Qué pasa si el pool es RAIDZ1 y veo bytes reparados?

Tómalo en serio. RAIDZ1 tiene menos margen para problemas multi-sector o multi-disco durante reconstrucciones. Considera aumentar la redundancia si los datos importan.

Conclusión: próximos pasos que puedes hacer esta semana

Deja de tratar ZFS scrub y la prueba SMART long como herramientas rivales. Son sensores complementarios apuntando a partes distintas del sistema: uno valida tus datos, el otro interroga al dispositivo.

1. Programa scrubs mensuales por pool y escalónalos en tu flota.
2. Programa pruebas SMART long semanal/quincenal, escalonadas por disco, y alerta sobre los atributos que realmente predicen dolor (pending, uncorrectable, reallocations, CRC).
3. Cuando ZFS reporte errores de checksum, investiga la ruta primero—cables, backplane, HBA, firmware—luego el disco.
4. Cuando SMART reporte pending/uncorrectable, no esperes a un resilver para descubrir que es real. Reemplaza el disco en tus términos.
5. Después de cualquier reparación, borra contadores, scruba y confirma que los errores se detienen. La evidencia vence al optimismo.

Tu yo futuro seguirá recibiendo pages. Pero será por algo nuevo, no por la misma tragedia de almacenamiento evitable con una marca de tiempo distinta.