Errores de checksum en ZFS: qué significan y qué hacer primero

Qué significan realmente los errores de checksum (y qué no significan)

Cuando ZFS escribe un bloque, calcula un checksum y lo guarda en los metadatos (no junto al bloque de datos en el mismo lugar donde una única falla podría corromper ambos). Más tarde, cuando ZFS lee ese bloque, vuelve a calcular el checksum y lo compara con lo que espera.

Un error de checksum significa: los bytes devueltos por la ruta de almacenamiento son diferentes de lo que ZFS escribió previamente. ZFS leyó algo con éxito—simplemente no era lo correcto.

Un error de checksum no significa automáticamente: “el disco está malo.” Significa “los datos están corruptos en algún punto entre las pistas/NAND y ZFS.” Ese “algún punto” incluye:

• Medio del disco o su controlador (falla clásica)
• Cable SATA/SAS, conector, backplane, expander (deprimidamente común)
• Problemas de firmware/controlador HBA (especialmente alrededor de resets y timeouts)
• Problemas de alimentación (brownouts, PSUs marginales, conector de alimentación suelto)
• Corrupción de RAM (ECC ayuda; sin ECC la historia se vuelve… más picante)
• Inestabilidad de CPU/IMC por overclocking o undervolting (sí, también en servidores)

Si existe redundancia (mirror/RAIDZ) y ZFS puede obtener una copia buena desde otro dispositivo, reparará los datos malos durante un scrub o una lectura. Esa es la parte que la gente adora de ZFS. La parte que suelen ignorar es la implicación: si sigues viendo errores de checksum, el sistema está recibiendo repetidamente datos corruptos. La reparación es un parche, no una cura.

También, no confundas estos tres contadores:

• READ errors: el dispositivo no pudo leer datos (error I/O). Eso suele indicar disco, cable o HBA.
• WRITE errors: ZFS no pudo escribir (error I/O) o el dispositivo rechazó la escritura. También suele ser hardware.
• CKSUM errors: los datos regresaron, pero estaban equivocados. Aquí “disco malo” compite con “ruta mala”.

Aquí va una regla opinada: trata los errores de checksum como un incidente de producción hasta que pruebes que son benignos. A menudo empiezan como “unos pocos.” Rara vez se quedan así.

Chiste #1 (corto, pertinente): Los errores de checksum de ZFS son como una alarma de humo que además te puede decir qué habitación está ardiendo. Aún así no deberías ignorarla porque la cocina “parece estar bien”.

Por qué ZFS detecta lo que otros sistemas de archivos pasan por alto

ZFS aplica checksums de extremo a extremo. Esa frase se usa mucho, pero la consecuencia operativa es simple: ZFS desconfía del hardware por defecto. Históricamente la mayoría de las pilas confiaban en que los discos o bien devolvían datos correctos o devolvían un error. En realidad, los dispositivos a veces devuelven datos incorrectos sin elevar un error I/O. Esa es la “corrupción silenciosa,” y es la razón por la que existe la categoría de errores de checksum.

ZFS también sabe cómo reparar lo que detecta—siempre que le hayas dado redundancia. Un mirror puede leer desde el otro lado. RAIDZ puede reconstruir usando paridad. Sin redundancia, ZFS solo puede decir “este bloque está mal” y entonces obtienes el tipo de error menos divertido: el honesto.

Operativamente, la meticulosidad de ZFS es un regalo. Convierte “error misterioso de la aplicación” en “el almacenamiento devolvió bytes corruptos.” Pero también te obliga a hacer el trabajo: debes decidir si la fuente es el disco, el bus, la memoria o el software.

Una nota práctica más: los errores de checksum pueden aparecer mucho después de que ocurrió la corrupción original. Los datos malos pueden permanecer sin leerse durante semanas. Luego un scrub (o un trabajo de backup) los toca y ZFS finalmente se queja. El error es real; el momento es solo grosero.

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

Primero: determina el alcance y si ZFS puede autocorregirse

• ¿Está el pool DEGRADED o solo reportando errores?
• ¿Los errores están aumentando ahora mismo o son históricos?
• ¿Están confinados a un solo dispositivo, a un vdev o están dispersos?
• ¿Hay redundancia (mirror/RAIDZ) que pueda reparar?

Segundo: clasifica el modo de falla por patrón

• Un solo disco, CKSUM en aumento lento con historial de cableado/backplane limpio: sospecha del disco o de su bahía.
• Varios discos en el mismo HBA/backplane muestran CKSUM: sospecha del cable/backplane/expander/HBA.
• CKSUM sin READ/WRITE y con inestabilidad del sistema: sospecha de RAM/CPU/firmware.
• Errores solo durante scrub/resilver: sospecha de hardware marginal bajo carga sostenida (disco, cable, expander, HBA, alimentación).

Tercero: recopila evidencia antes de “arreglar” nada

• Captura zpool status -v, zpool events -v y los logs del sistema en torno a las marcas de tiempo.
• Registra identificadores de dispositivos: el mapeo /dev/disk/by-id importa más que sdX.
• Extrae datos SMART / registros de NVMe y logs de errores.
• Si múltiples dispositivos muestran errores, mapea la cadena física (puerto HBA → expander → ranura backplane).

Entonces—y solo entonces—comienza a reemplazar partes o a recolocar cables. De lo contrario borras la traza y mantienes el misterio vivo para el siguiente de guardia.

Tareas prácticas: comandos, salidas y decisiones

El objetivo aquí no es ejecutar comandos por comodidad. Es extraer una decisión. Cada tarea incluye: el comando, qué significa la salida y qué haces a continuación.

Tarea 1: Obtén la verdad actual desde ZFS

cr0x@server:~$ zpool status -v tank
  pool: tank
 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 128K in 0 days 00:12:31 with 0 errors on Tue Dec 24 01:10:18 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0    14

errors: No known data errors

Significado: Un dispositivo muestra 14 errores de checksum, pero ZFS reparó datos durante el scrub y hay “No known data errors.” Eso implica que la redundancia funcionó.

Decisión: Trata la ruta del dispositivo como sospechosa. Investiga el hardware, pero no estás en territorio inmediato de “restaurar desde backup”.

Tarea 2: Confirma si los errores siguen aumentando

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0    14

Significado: Mismo número que antes. Eso es bueno: sugiere un evento histórico en lugar de un flujo de corrupción en curso.

Decisión: Continúa recopilando evidencia. Si el contador sube durante carga o scrub, escala al troubleshooting físico y considera reemplazo.

Tarea 3: Extrae la identidad del dispositivo y evita la trampa sdX

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'WDC_WD80EFAX|ata-WDC'
lrwxrwxrwx 1 root root  9 Dec 25 01:22 ata-WDC_WD80EFAX-68LHPN0_VKJ9KABC -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 25 01:22 ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ -> ../../sdc

Significado: Tienes identificadores estables que mapean a nombres de kernel sdb/sdc. Los nombres del kernel pueden cambiar al reiniciar; los by-id generalmente no.

Decisión: Usa rutas by-id en reemplazos y documentación. Si extraes el disco equivocado, ZFS lo recordará.

Tarea 4: Revisa eventos de ZFS para la línea temporal

cr0x@server:~$ zpool events -v | tail -n 20
Dec 24 01:06:12.900760000 sysevent.fs.zfs.checksum
  pool = tank
  vdev_path = /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ
  vdev_guid = 1234567890123456789
  vdev_state = 0
  vdev_read_errors = 0
  vdev_write_errors = 0
  vdev_checksum_errors = 14
Dec 24 01:10:18.112233000 sysevent.fs.zfs.scrub_finish
  pool = tank
  scrub_repaired = 131072
  scrub_errors = 0

Significado: El evento de checksum ocurrió durante el scrub. Reparó 128K y finalizó sin errores no corregidos.

Decisión: Investiga qué cambió alrededor de ese momento: trabajo de cableado, actualizaciones de firmware, eventos de energía, I/O intensivo o un reset del controlador.

Tarea 5: Busca resets de controlador y errores de enlace en los logs del sistema

cr0x@server:~$ sudo journalctl -k --since "2025-12-24 00:45" --until "2025-12-24 01:30" | egrep -i "ata|sas|scsi|reset|link|error" | tail -n 20
Dec 24 01:05:44 server kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x400100 action 0x6 frozen
Dec 24 01:05:44 server kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Dec 24 01:05:44 server kernel: ata7: SError: { UnrecovData Handshk }
Dec 24 01:05:45 server kernel: ata7: hard resetting link
Dec 24 01:05:50 server kernel: ata7: link is slow to respond, please be patient (ready=0)
Dec 24 01:05:51 server kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 24 01:05:51 server kernel: sd 6:0:0:0: [sdc] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=7s

Significado: El kernel detectó un error de enlace SATA y hizo un reset. Esa es una señal de alerta para cableado/backplane/interfaz de disco—especialmente si se repite.

Decisión: Si ves resets de enlace ligados a la misma bahía, empieza por la capa física: recoloca/reemplaza el cable, mueve el disco a otra ranura o intercambia el cable de conexión.

Tarea 6: Comprueba la salud SMART (SATA/SAS vía smartctl)

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Reallocated_Sector_Ct|Reported_Uncorrect|UDMA_CRC_Error_Count|Current_Pending_Sector|Offline_Uncorrectable|SMART overall"
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       -       0
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       23

Significado: Los errores CRC (UDMA_CRC_Error_Count) apuntan a corrupción en tránsito—cable/backplane—no a defectos del medio. Reallocated/pending sectors en cero debilitan el diagnóstico de “plato muriéndose”.

Decisión: Arregla primero el transporte: cable/backplane/ranura. Si los CRC siguen subiendo después de la remediación física, entonces considera disco o controlador.

Tarea 7: Ejecuta un autotest SMART corto y lee resultados

cr0x@server:~$ sudo smartctl -t short /dev/sdc
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Self-test execution status|SMART Self-test log" -A5
Self-test execution status:      (  0) The previous self-test routine completed without error.
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      9123         -

Significado: El disco pasó su propia prueba. Eso no exime al disco, pero desplaza la sospecha hacia cableado/backplane/controlador si los errores de checksum persisten.

Decisión: Si los errores de ZFS siguen acumulándose y SMART está limpio excepto por CRCs, deja de culpar al disco y comienza a intercambiar cables/ranuras.

Tarea 8: Para NVMe, revisa SMART y logs de error (nvme-cli)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 41 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 3%
media_errors                        : 0
num_err_log_entries                 : 2

Significado: NVMe reporta media_errors y entradas en el log de errores. Media errors son serios; un pequeño número de entradas en el log puede ser benigno dependiendo del tipo, pero es evidencia.

Decisión: Si media_errors > 0 o el log de errores muestra problemas repetidos de integridad, planifica el reemplazo. NVMe tiende a fallar rápido y sin nostalgia.

Tarea 9: Identifica qué tipo de vdev tienes (afecta la urgencia)

cr0x@server:~$ zpool list -v tank
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank       14.5T  9.12T  5.38T        -         -    21%    62%  1.00x  ONLINE  -
  mirror-0  7.25T  4.56T  2.69T        -         -    19%    62%      -  ONLINE
  mirror-1  7.25T  4.56T  2.69T        -         -    23%    62%      -  ONLINE

Significado: Mirrors: buenos para autocuración y resilvers rápidos. RAIDZ: comportamiento diferente, ventanas de reconstrucción más largas y perfil de riesgo distinto.

Decisión: Si estás en RAIDZ con discos grandes, sé más agresivo con la remediación temprana porque la ventana de resilver/scrub es mayor y expone componentes marginales por más tiempo.

Tarea 10: Ejecuta un scrub a propósito, no por reflejo

cr0x@server:~$ sudo zpool scrub tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 01:40:02 2025
        1.27T scanned at 3.10G/s, 912G issued at 2.23G/s, 9.12T total
        0B repaired, 9.76% done, 0:59:31 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0    14

errors: No known data errors

Significado: El scrub estresa toda la ruta. Si los errores aumentan durante el scrub, estás reproduciendo el problema (bueno para diagnóstico, malo para hardware frágil).

Decisión: Ejecuta scrubs cuando puedas observarlos y capturar logs. No inicies un scrub y te vayas a dormir a menos que disfrutes recibir alertas sorpresa.

Tarea 11: Limpia los errores solo después de la remediación

cr0x@server:~$ sudo zpool clear tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

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

errors: No known data errors

Significado: Los contadores se reinician. Esto no arregla nada. Solo deja el panel en silencio.

Decisión: Limpia después de haber recolocado cables, cambiado ranuras, reemplazado un disco, actualizado firmware o cambiado algo en el mundo. Luego observa si los errores reaparecen.

Tarea 12: Reemplaza un disco a la manera de ZFS (ejemplo mirror)

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_NEWDRIVE

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: resilver in progress since Wed Dec 25 02:05:11 2025
        612G scanned at 1.45G/s, 210G issued at 512M/s, 9.12T total
        210G resilvered, 2.25% done, 4:58:40 to go
config:

        NAME                                              STATE     READ WRITE CKSUM
        tank                                              ONLINE       0     0     0
          mirror-0                                        ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ9KABC             ONLINE       0     0     0
            replacing-1                                   ONLINE       0     0     0
              ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ           ONLINE       0     0     0
              ata-WDC_WD80EFAX-68LHPN0_NEWDRIVE           ONLINE       0     0     0

errors: No known data errors

Significado: ZFS está resilverizando. Si ocurren errores de checksum durante el resilver, eso es diagnóstico: tu ruta es inestable bajo I/O sostenido.

Decisión: Monitoriza journalctl -k al mismo tiempo. Si aparecen resets de enlace o errores de transporte, pausa y arregla el cableado/HBA antes de terminar el reemplazo.

Tarea 13: Usa zdb solo cuando estés listo para ser preciso

cr0x@server:~$ sudo zdb -bbbbbb tank 2>/dev/null | head -n 20
Dataset tank [ZPL], ID 50, cr_txg 4, 1.62G, 1021 objects, rootbp DVA[0]=<0:1c3f4a8000:200> ...

Significado: zdb es para forense profundo, no para curiosear. Puede ayudar a identificar qué bloques están afectados cuando tienes “known data errors”.

Decisión: Úsalo si enfrentas errores no corregibles y necesitas decidir qué datos restaurar, o para validar supuestos sobre corrupción de metadatos vs datos de archivo.

Tarea 14: Revisa señales de salud de la memoria (ECC y reportes del kernel)

cr0x@server:~$ sudo journalctl -k | egrep -i "mce|edac|ecc|machine check" | tail -n 20
Dec 25 00:12:08 server kernel: EDAC MC0: 1 CE memory error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0)

Significado: Errores ECC corregidos (CE) significan que la RAM se está comportando mal pero se está corrigiendo. Eso aún puede correlacionarse con errores de checksum e inestabilidad.

Decisión: Trata eventos ECC repetidos como un incidente de hardware. Programa el reemplazo de DIMMs y deja de culpar a discos por lo que la RAM está corrompiendo aguas arriba.

Tarea 15: Inspecciona propiedades ZFS que afectan la visibilidad de corrupción

cr0x@server:~$ zfs get checksum,compression,recordsize,atime tank
NAME  PROPERTY     VALUE     SOURCE
tank  checksum     on        default
tank  compression  lz4       local
tank  recordsize   128K      local
tank  atime        off       local

Significado: El checksumming está activado (bueno). La compresión no causa errores de checksum, pero cambia los patrones de I/O y puede exponer hardware débil durante lecturas/escrituras intensas.

Decisión: No “arregles” errores de checksum cambiando propiedades del dataset. Arregla la ruta del hardware. ZFS es el mensajero, no el villano.

Tarea 16: Mapea la topología física (ejemplo SAS) para encontrar componentes compartidos

cr0x@server:~$ sudo sas2ircu 0 DISPLAY | egrep -i "Enclosure|Slot|Device is a Hard disk|SAS Address|State" -A2
Enclosure#                             : 1
  Slot#                                : 4
    Device is a Hard disk
    State                              : Optimal
  Slot#                                : 5
    Device is a Hard disk
    State                              : Optimal

Significado: Cuando varios discos afectados comparten una bahía/backplane/expander, mapear la topología convierte “errores aleatorios” en “punto único de fallo”.

Decisión: Si los errores se correlacionan por enclosure/puerto, prioriza el componente compartido (cable, expander, backplane, HBA) sobre swaps de discos.

Guía de interpretación: disco vs cable vs RAM vs firmware

Patrón A: Un dispositivo, errores de checksum suben lentamente, SMART muestra reasignaciones/pending

Probable culpable: el disco. Si las reallocated sectors aumentan o aparecen pending sectors, el medio está fallando o el disco no puede leer datos antiguos de forma fiable.

Qué hacer: reemplaza el disco. No negocies. En vdevs espejo tienes margen; en RAIDZ tienes matemática, no piedad.

Patrón B: Un dispositivo, errores de checksum + SMART UDMA CRC errors

Probable culpable: la capa de transporte. Los errores CRC suelen ser cable/backplane/conector. Con expanders SAS puede ser una línea marginal.

Qué hacer: recoloca y reemplaza el cable; mueve el disco a otra bahía; si usas SATA en un backplane, comprueba el ajuste y la tensión. Luego limpia errores y observa.

Patrón C: Varios dispositivos en un HBA/backplane muestran checksum errors

Probable culpable: componente compartido: HBA, expander, backplane, alimentación o bug de firmware. ZFS te está diciendo que la corrupción es sistémica, no una tragedia de un solo disco.

Qué hacer: correlaciona los discos afectados a una cadena de puerto específica. Cambia el cable SAS. Actualiza firmware del HBA a una versión conocida y estable. Revisa rieles de alimentación y el asiento del backplane.

Patrón D: Checksum errors sin errores a nivel de disco, más reportes kernel MCE/EDAC

Probable culpable: inestabilidad de memoria/plataforma CPU. ZFS protege la integridad en disco, pero la RAM mala puede corromper datos antes de que se checksumeen o después de que se lean en memoria.

Qué hacer: trata esto como un problema de plataforma hardware. Verifica que ECC esté habilitado. Ejecuta un test de memoria en mantenimiento. Deja de hacer overclock. Reemplaza DIMMs con errores corregidos recurrentes.

Patrón E: Los errores aparecen solo después de actualizaciones de firmware o del kernel

Probable culpable: interacciones driver/firmware, comportamiento de profundidad de cola, gestión de energía o una regresión. No es glamoroso, pero ocurre.

Qué hacer: revierte si es posible, o avanza hacia una versión arreglada. Conserva la evidencia (eventos, logs). No lo “arregles” suprimiendo errores.

Una cita, porque la operación es sobre todo humildad: “La esperanza no es una estrategia.” — General Gordon R. Sullivan

Chiste #2 (corto, pertinente): Limpiar errores de ZFS sin arreglar la causa es como apagar la luz del testigo del motor quitando la bombilla. Sí, reduce el ruido del panel.

Tres microhistorias empresariales (dolorosamente familiares)

Microhistoria 1: El incidente causado por una suposición errónea

El equipo heredó un nodo de almacenamiento que “tenía unos pocos errores de checksum durante meses.” La nota del admin anterior decía que era un “disco conocido malo” y “no urgente porque RAIDZ.” Sonó plausible, así que quedó en el fondo del backlog con otras cosas plausibles.

Entonces un scrub rutinario empezó el domingo por la mañana. A mitad del proceso, los errores de checksum empezaron a subir en dos discos diferentes del mismo vdev. El de guardia reemplazó primero el “disco conocido malo”, esperando que los errores se detuvieran. No fue así. De hecho, durante el resilver un tercer disco empezó a registrar resets de transporte. Ahora el pool estaba degradado y furioso.

La suposición errónea fue sutil: asumieron que los errores de checksum se comportan como las reasignaciones SMART—específicos del disco y locales. Pero los errores de checksum de ZFS suelen ser específicos de la ruta. Tras una hora frenética intercambiando discos, alguien finalmente revisó los logs del kernel y notó resets de enlace repetidos en el mismo puerto SAS.

La causa raíz resultó ser un cable breakout SAS marginal que había sido doblado en una forma que se veía bien en fotos y mal en física. El cable funcionaba con carga ligera y fallaba bajo scrub/resilver sostenido. Una vez reemplazado, el “disco malo” dejó de estar malo. El equipo aprendió la lección: un error de checksum es evidencia de corrupción, no un veredicto sobre un disco específico.

Microhistoria 2: La optimización que salió mal

Otra empresa tenía una iniciativa de rendimiento: reducir el tiempo de scrub y ventanas de backup. Aumentaron la paralelización en sus trabajos de backup y ajustaron la pila de almacenamiento para rendimiento. Los scrubs terminaban más rápido, los dashboards se veían más verdes y todos felicitaron la hoja de cálculo.

Un mes después, empezaron a aparecer errores de checksum durante los scrubs en múltiples pools—principalmente en sistemas con expanders más antiguos. Las lecturas ahora eran más agresivas y concurrentes. Los expanders empezaron a mostrar su edad: flaps de enlace ocasionales, reintentos y eventos de corrupción sutil que ZFS detectó como desajustes de checksum.

La optimización no “causó” corrupción de la nada. Convirtió un sistema marginal en una falla reproducible. Antes, el entorno nunca sostenía el patrón de I/O el tiempo suficiente para exponer la debilidad. Ahora sí, en horario pico.

La solución no fue reducir el rendimiento para siempre. Movieron los scrubs a una ventana más tranquila, redujeron la concurrencia durante scrubs, actualizaron firmware de expanders cuando fue seguro y reemplazaron el hardware más defectuoso. Pero la solución mayor fue cultural: la afinación de rendimiento ahora requería un plan de pruebas de confiabilidad, no solo un gráfico de throughput.

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

En una empresa, el equipo de almacenamiento tenía una costumbre que parecía burocrática: cada trimestre corrían un scrub, exportaban el último informe de scrub y archivaban las salidas de zpool status -v junto con los logs del kernel del periodo. Etiquetaban las bahías con los seriales by-id. Era aburrido. También era exactamente lo que necesitas durante un incidente real.

Una noche, los errores de checksum se dispararon en un miembro de un mirror. Porque tenían artefactos de referencia, supieron dos cosas inmediatamente: el disco nunca había mostrado errores CRC antes, y la bahía tenía historial de resets de enlace hace dos años con otro disco distinto. Misma bahía. Disco distinto. Familia de síntomas igual.

Reemplazaron el cable de la bahía durante una ventana de mantenimiento, limpiaron errores y ejecutaron un scrub controlado observando logs. No aparecieron nuevos errores. Dejaron el disco en su lugar y lo mantuvieron bajo observación. Si hubieran seguido el instinto por defecto—reemplazar el disco—habrían desperdiciado tiempo, dinero y probablemente provocado más interrupciones.

El resumen ejecutivo para la dirección también fue aburrido: “Arreglamos un interconector defectuoso y validamos la integridad.” Sin drama, sin heroísmo, solo un sistema que cumplió su promesa. Ese es el trabajo.

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

1) “Los errores de checksum suben, así que reemplaza el disco inmediatamente”

Síntoma: CKSUM incrementa, pero SMART muestra UDMA CRC en aumento y sin reasignaciones.

Causa raíz: corrupción en el cable/backplane/conector, no fallo del medio.

Solución: reemplaza/reubica cables, mueve el disco a otra bahía, revisa conectores del backplane; luego haz un scrub y observa.

2) “Limpiamos errores y desaparecieron, así que está solucionado”

Síntoma: Alguien ejecutó zpool clear; el panel estuvo en silencio por una semana.

Causa raíz: los contadores se reiniciaron; la causa subyacente permanece. Acabas de perder datos de tendencia.

Solución: trata zpool clear como un paso posterior a la remediación con scrubs y monitoreo de seguimiento.

3) “Los errores aparecieron tras un scrub, así que el scrub causó la corrupción”

Síntoma: La primera vez que alguien notó errores fue durante un scrub.

Causa raíz: el scrub leyó los datos y descubrió corrupción existente o estresó hardware marginal para mostrar sus fallos.

Solución: mantén los scrubs; cambia cuándo/cómo haces scrubs; arregla hardware débil y verifica con scrubs controlados.

4) “El pool está ONLINE, así que los datos están bien”

Síntoma: El pool muestra ONLINE pero los contadores CKSUM del dispositivo son no cero.

Causa raíz: la redundancia enmascaró la corrupción, pero la corrupción ocurrió de todos modos.

Solución: investiga, remedia y confirma que no haya nuevos errores bajo carga. ONLINE no es un certificado de salud completo.

5) “Varios discos tienen errores de checksum, así que hubo múltiples fallos de disco”

Síntoma: Varios discos en el mismo chasis muestran incrementos CKSUM en la misma hora.

Causa raíz: componente compartido (HBA, expander, backplane, PSU) comportándose mal.

Solución: mapea la topología; apunta al punto común; revisa logs por resets; intercambia cables y prueba.

6) “ZFS es demasiado sensible; apaguemos los checksums”

Síntoma: Alguien sugiere deshabilitar checksumming o ignorar eventos.

Causa raíz: malentendido: ZFS está detectando corrupción real que tu pila antes ignoraba.

Solución: mantén el checksumming; arregla la ruta de hardware; mejora el monitoreo y las ventanas de mantenimiento.

7) “Los errores ECC corregidos son inofensivos”

Síntoma: Logs EDAC muestran errores corregidos; el almacenamiento ve problemas de checksum ocasionales.

Causa raíz: los errores corregidos pueden ser una advertencia temprana. Pueden seguir errores no corregidos; la estabilidad puede estar comprometida.

Solución: programa el reemplazo de DIMMs, comprueba asientos, actualiza BIOS/microcódigo cuando proceda y valida con pruebas de estrés.

8) “Podemos mantener un pool degradado mientras investigamos varios días”

Síntoma: Un vdev RAIDZ está degradado y alguien quiere esperar por procuración.

Causa raíz: exposición prolongada: una falla más y estás restaurando desde backup.

Solución: prioriza restaurar la redundancia de inmediato—repuestos, reemplazos temporales o mover cargas de trabajo.

Listas de verificación / plan paso a paso

Paso a paso de triage (haz esto en orden)

1. Captura el estado: guarda la salida de zpool status -v y añade marca de tiempo. No limpies nada aún.
2. Verifica si los errores son corregibles: busca “errors: No known data errors” vs rutas/objetos listados con errores.
3. Revisa la tendencia: ejecuta zpool status otra vez tras carga o pasados 10–30 minutos. ¿CKSUM aumenta?
4. Revisa eventos: zpool events -v para ligar errores a scrub/resilver/lecturas normales.
5. Revisa logs del kernel: busca resets, errores de enlace, timeouts en la misma ventana.
6. Revisa SMART/NVMe: específicamente CRC, reallocated/pending, media errors, logs de errores.
7. Mapea la topología: ¿los discos afectados comparten puerto/backplane/expander? Si sí, sospecha del componente compartido.
8. Remedia físicamente: recoloca/reemplaza cable, mueve bahías, intercambia puerto HBA, revisa conexiones de energía.
9. Limpiar errores: solo después de un cambio; luego ejecuta un scrub controlado o una carga de lectura mientras observas.
10. Reemplaza hardware si es necesario: disco, cable, expander, HBA, DIMM—según la evidencia.
11. Verifica: completa un scrub sin nuevos errores; confirma que los logs están tranquilos; monitorea contadores durante una semana.
12. Documenta: qué se cambió, qué evidencia lo justificó y cómo luce ahora la normalidad.

Cuándo reemplazar el disco (mis criterios directos)

• SMART muestra aumento de reallocated sectors, pending sectors u offline uncorrectables.
• NVMe reporta media_errors no nulos o entradas repetidas relacionadas con integridad en su log.
• Los errores de checksum siguen aumentando en el mismo disco después de haber intercambiado cables/puertos y verificado logs limpios.
• El disco es el caso aislado en un mirror (el otro lado está limpio) y el patrón de error sigue al disco cuando se mueve a otra bahía.

Cuándo sospechar primero de cableado/backplane/expander

• UDMA CRC errors en SMART aumentan.
• Logs del kernel muestran resets de enlace, PHY resets o errores de transporte.
• Varios discos en la misma enclosure/chain muestran problemas.
• Los errores aparecen bajo lecturas secuenciales sostenidas (scrub/resilver) más que bajo cargas aleatorias.

Cuándo sospechar de RAM/CPU/estabilidad de plataforma

• Logs EDAC/MCE muestran errores de memoria corregidos o no corregidos.
• Los errores de checksum aparecen en dispositivos sin una topología física consistente.
• Ves crashes inexplicables, panics o problemas de datos fuera de ZFS también.
• El sistema usa RAM sin ECC para cargas que realmente importan.

Datos interesantes y contexto histórico (lo que solo aprendes tras quemarte)

• Dato 1: ZFS se originó en Sun Microsystems a principios de los 2000 con el objetivo explícito de integridad de datos de extremo a extremo, no solo “un sistema de archivos rápido”.
• Dato 2: Las pilas de almacenamiento tradicionales a menudo confiaban en que el disco detectara lecturas malas mediante ECC a nivel de sector; la corrupción silenciosa puede eludir eso y aún devolver “éxito”.
• Dato 3: ZFS guarda checksums en metadatos en lugar de junto al bloque de datos, reduciendo la probabilidad de que una mala escritura corrompa datos y su checksum a la vez.
• Dato 4: Los scrubs no son “teatro de mantenimiento.” Son una lectura sistemática del pool para sacar a la luz errores latentes antes de que tu trabajo de restauración los descubra.
• Dato 5: El aumento de discos muy grandes hizo normales las ventanas largas de rebuild/resilver, lo que incrementó la importancia de detectar y reparar corrupción silenciosa temprano.
• Dato 6: Los errores CRC en SATA han sido una pista clásica de “no es el disco” durante décadas; implican integridad de señal y conectores más que el medio.
• Dato 7: Algunos de los incidentes más desagradables por errores de checksum involucran expanders/backplanes porque crean fallos correlacionados en muchos discos a la vez.
• Dato 8: ZFS puede reparar datos corruptos de forma transparente en vdevs redundantes, pero seguirá incrementando contadores de error—porque mereces saber que ocurrió.
• Dato 9: El estado de pool “ONLINE” puede coexistir con problemas subyacentes serios; ZFS prioriza disponibilidad mientras reporta problemas de integridad para que tomes acción.

Preguntas frecuentes

1) ¿Los errores de checksum siempre son signo de pérdida de datos?

No. Si tienes redundancia y ZFS reporta “No known data errors,” ZFS probablemente reparó los bloques malos. Sigue siendo un signo de corrupción en algún lugar, pero no necesariamente pérdida de datos de aplicaciones.

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

READ errors significa que el dispositivo no pudo entregar datos (fallo I/O). CKSUM errors significa que entregó datos que no coincidieron con el checksum esperado. READ grita “no se puede leer.” CKSUM susurra “leí algo, pero está mal.”

3) ¿Debo ejecutar un scrub inmediatamente al ver errores de checksum?

Normalmente sí—si puedes vigilarlo. Un scrub puede tanto reparar como reproducir el problema bajo carga, lo que es excelente para diagnóstico. No lo inicies a ciegas en una ventana de riesgo.

4) ¿Es seguro ejecutar zpool clear?

Es seguro en el sentido de que no borra datos. Es inseguro operativamente si lo usas para ocultar evidencia. Limpia después de remediar algo, para poder detectar recurrencias.

5) Tengo errores de checksum en un disco espejo. ¿Puedo ignorarlos?

Puedes posponer el reemplazo si el contador está estable y la evidencia apunta a un evento puntual (como un reset de enlace transitorio). No ignores aumentos recurrentes. Los mirrors son tolerantes; no mágicos.

6) ¿La RAM defectuosa puede causar errores de checksum en ZFS?

Sí. La RAM mala puede corromper datos en memoria antes de escribirse (así ZFS checksumea datos corruptos de buena fe) o corromper datos después de leerse. ECC reduce el riesgo y te da evidencia mediante logs EDAC/MCE.

7) ¿Por qué suelen aparecer los errores de checksum durante scrub/resilver?

Porque esas operaciones leen mucho dato y estresan toda la ruta de I/O de forma continua. Los cables marginales, expanders inestables y discos en el límite odian el trabajo sostenido y predecible.

8) Si SMART dice “PASSED”, ¿por qué ZFS reporta errores?

SMART “PASSED” no es un certificado de salud total; es una comprobación mínima. ZFS mide resultados de integridad reales. Crea confianza en el sistema que valida datos de extremo a extremo.

9) ¿Qué pasa si zpool status -v lista archivos con errores?

Eso significa que ZFS tiene known data errors que no pudo reparar. Tu árbol de decisiones cambia: identifica datasets afectados, restaura desde backup/snapshot cuando sea posible y arregla el hardware de inmediato.

10) ¿Los errores de checksum significan que mi HBA está mal?

A veces. Si los errores se correlacionan en múltiples discos conectados al mismo puerto HBA o aparecen resets/timeouts del controlador en los logs, el HBA (o su firmware/driver) sube rápido en la lista de sospechosos.

Pasos prácticos siguientes

Los errores de checksum son ZFS haciendo su trabajo: detectar corrupción que el resto de la pila con gusto serviría a tus aplicaciones con una sonrisa. Tu trabajo es convertir “CKSUM=14” en una solución concreta.

1. Recopila evidencia primero: zpool status -v, zpool events -v y logs del kernel alrededor del tiempo de los errores.
2. Clasifica el patrón: dispositivo único vs múltiples, solo durante scrub vs en cualquier momento, CRC vs reasignaciones, correlación topológica.
3. Remedia la causa más probable (a menudo cableado/backplane) antes de cambiar discos a ciegas.
4. Solo limpia errores después de un cambio, luego ejecuta un scrub controlado mientras observas logs.
5. Si los errores reaparecen, reemplaza el componente que indique la evidencia—disco, cable, expander, HBA o DIMM—y verifica con un scrub limpio.

Si tomas una lección operativa de todo esto: no confundas que ZFS reporte un problema de integridad con que ZFS sea el problema. Es el testigo. Trátalo como tal.