Restablecimientos de enlace SATA en ZFS: patrón de fallo del controlador/cable

Qué parece el patrón “controlador/cable”

ZFS es brutalmente honesto con el I/O. Comprueba sumas de verificación en todo, reintenta cuando puede y marcará un dispositivo
como degradado o fallido cuando el subsistema no puede entregar bloques de forma fiable. Los restablecimientos de enlace SATA viven por debajo de ZFS:
el kernel dice “el enlace se fue,” luego “lo reinicié,” luego “volvió,” a veces repitiendo hasta que ZFS se rinde.

El patrón “controlador/cable” es específicamente cuando el disco no es la falla principal.
El disco es un espectador que se convierte en acusado porque es el extremo del transporte inestable.
La firma es una inestabilidad repetible que se correlaciona con un camino (puerto, cable, pista del backplane, expander),
no con un mecanismo de disco específico.

Lista de verificación de campo: señales de que no es el disco

• Varios discos muestran restablecimientos de enlace, pero comparten el mismo controlador/backplane/rail de PSU.
• SMART parece limpio (sin sectores realocados, sin sectores pendientes) pero ves que los errores UDMA CRC aumentan.
• Los errores se agrupan alrededor de I/O elevado, vibración, cambios de temperatura o una puerta del chasis que se cierra de golpe como si debiera dinero.
• Reemplazar el disco no ayuda. El “nuevo” disco falla de la misma forma en el mismo puerto.
• Mover el mismo disco a otro puerto lo arregla. No es magia; es aislamiento de ruta.

Aquí está la diferencia operativa: un disco moribundo tiende a empeorar de forma específica al disco (errores de medio, lecturas lentas, realocaciones crecientes).
Un enlace defectuoso tiende a ser caótico (restablecimientos, timeouts, errores CRC, desconexiones aleatorias), afectando con frecuencia lo que esté conectado a esa ruta.

Broma #1: SATA es el único “bus serie de alta velocidad” que puede ser derrotado por un cable que parece perfectamente bien. Es básicamente redes con tornillos.

Por qué ZFS hace esto más visible

ZFS verifica lecturas con sumas, por lo que la corrupción transitoria en el cable no se convierte silenciosamente en datos corruptos.
En su lugar, ZFS registra errores de checksum, reintenta lecturas y, si existe redundancia, repara desde una copia buena.
Eso es fantástico para la integridad de los datos—y brutal para tu pager cuando un enlace inestable convierte cada scrub en un evento de resistencia.

Datos interesantes y contexto histórico (lo que explica el dolor de hoy)

1. Los errores UDMA CRC fueron diseñados como un sistema de alerta temprana. A menudo indican problemas de cableado/integridad de señal más que defectos del medio del disco.
2. SATA heredó mucha cultura de “probablemente está bien” de los PCs de sobremesa. Los racks empresariales exigen tolerancias más estrictas que las cajas de consumo.
3. NCQ (Native Command Queuing) mejoró el rendimiento pero amplió el radio de impacto de los fallos de enlace. Más comandos pendientes significan más cosas que pueden expirar cuando el bus falla.
4. Los backplanes no son magia pasiva. Incluso “solo una placa” puede tener trazas marginales, conectores desgastados o puesta a tierra deficiente que aparece como CRC/reintentos.
5. AHCI se diseñó para generalidad, no para heroísmo. Muchos controladores SATA integrados se comportan mal bajo tormentas de errores comparados con HBAs adecuados.
6. Las semánticas de hot-swap son complicadas en SATA. SAS se diseñó pensando en hot-plug; SATA tiene hot-plug, pero las implementaciones varían mucho.
7. Las funciones de gestión de energía (HIPM/DIPM, ALPM) han causado inestabilidad en el mundo real. Los cambios agresivos de estado de enlace pueden desencadenar restablecimientos en configuraciones marginales.
8. Los hábitos de cableado de SATA 3Gb/s no siempre sobrevivieron a 6Gb/s. “Funcionó durante años” puede ser un artefacto de una tasa de señalización más baja.
9. ZFS hizo que los errores de checksum sean comunes en operaciones. Las pilas tradicionales a menudo enmascaraban la corrupción transitoria con “reintenta hasta que funcione”; ZFS te dice la verdad.

Guion de diagnóstico rápido

Este es el plan de “necesito una dirección en 10 minutos”. No te vuelvas loco. Establece si tratas con:
(a) un solo disco fallando, (b) un enlace/ruta inestable, o (c) un controlador/backplane/energía que puede tirar abajo el pool.

Primero: confirma lo que ZFS cree que pasa

• Revisa zpool status -v y anota qué vdev(s) y qué dispositivo(s) muestran errores.
• Busca patrones: misma familia de puerto HBA, misma caja, mismo backplane, misma alimentación.

Segundo: lee la historia del kernel, no solo el resumen de ZFS

• Extrae dmesg -T y/o journalctl -k alrededor del momento del incidente.
• Busca: link is slow to respond, hard resetting link, COMRESET failed, SError, failed command: READ FPDMA QUEUED.

Tercero: decide “disco vs ruta” usando SMART y contadores

• smartctl -a para reallocated/pending/uncorrectable sectors (salud del medio) y UDMA CRC errors (salud del enlace).
• Si los errores CRC aumentan mientras los contadores de medio se mantienen estables, trátalo como cable/backplane/controlador hasta probar lo contrario.

Cuarto: aisla moviendo una variable

• Mueve el disco a otro puerto/cable/slot del backplane (un cambio a la vez).
• Si el problema sigue con el puerto, es la ruta/puerto. Si sigue con el disco entre puertos, es el disco.

Quinto: estabiliza y solo entonces haz scrub/resilver

• Arregla el problema físico/de ruta primero. Hacer resilver a través de un enlace defectuoso es cómo conviertes un pequeño incidente en un fin de semana largo.

Firmas en los logs que separan disco vs enlace vs controlador

El kernel es verboso cuando SATA se pone raro. Esa verbosidad es tu amiga si aprendes las frases comunes.
Abajo hay patrones que trato como indicadores “probables”, no absolutos.

Bucle clásico de restablecimiento de enlace

Busca secuencias repetidas como: exception Emask → hard resetting link → SATA link up → repetir.
Cuando esto ocurre bajo carga, ZFS ve timeouts y errores I/O; tus aplicaciones ven picos de latencia y fallos “aleatorios”.

CRC y errores de transporte (cable/backplane/ruta)

Indicadores incluyen aumento de UDMA_CRC_Error_Count, SError: { CommWake }, y errores que desaparecen tras un reinicio del enlace.
Los contadores de medio a menudo permanecen estables. El disco dice: “puedo guardar bits; simplemente no puedo hablar ahora.”

Timeouts de comando con NCQ

Mensajes como failed command: READ FPDMA QUEUED pueden ser problema de enlace o fallo de firmware del disco.
Tu desempate es la repetibilidad y la correlación: si varios discos muestran lo mismo en el mismo controlador, acusa a la ruta.

Firma de fallo del medio del disco

Esto tiende a mostrar aumento de Reallocated_Sector_Ct, Current_Pending_Sector,
Offline_Uncorrectable, y errores de checksum ZFS que se concentran en un dispositivo independientemente del puerto.

Firma de fallo a nivel de controlador

Cuando un HBA o un controlador integrado es el culpable, a menudo ves reinicios en varios discos adjuntos en una ventana de tiempo estrecha.
ZFS puede degradar múltiples vdevs simultáneamente. Eso no es “mala suerte”. Es destino compartido.

Una idea parafraseada a menudo atribuida a Jim Gray: Los fallos son normales; los sistemas deben asumir que los componentes fallan y recuperarse automáticamente.
ZFS asume eso. Tu cableado SATA probablemente no.

Tareas prácticas: comandos, salidas y decisiones

El objetivo aquí no es memorizar comandos. Es convertir “disco caído” en una decisión estructurada:
reemplazar disco, reemplazar cable, cambiar HBA, modificar alimentación o ajustar opciones del kernel.
Cada tarea abajo incluye: comando, salida de ejemplo, qué significa y qué haces luego.

Tarea 1: Obtener la verdad desde ZFS

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Thu Dec 26 01:10:02 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE      0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE      0     0     0
            ata-ST8000VN004-2M2101   DEGRADED    12     0     0  too many errors
            ata-ST8000VN004-2M2101   ONLINE      0     0     0
errors: No known data errors

Qué significa: ZFS vio errores de lectura en un dispositivo (READ=12). No hay errores de checksum, lo que indica que las lecturas fallaron a nivel de transporte, no se devolvieron “datos malos”.

Decisión: No reemplaces el disco todavía. Ve a los logs del kernel y a SMART. Los errores de capa de transporte huelen a restablecimientos de enlace.

Tarea 2: Mapear los nombres de dispositivo ZFS a rutas físicas

cr0x@server:~$ ls -l /dev/disk/by-id | grep ST8000VN004 | head
lrwxrwxrwx 1 root root  9 Dec 26 01:21 ata-ST8000VN004-2M2101_ZA1ABCDF -> ../../sdc
lrwxrwxrwx 1 root root 10 Dec 26 01:21 ata-ST8000VN004-2M2101_ZA1ABCDF-part1 -> ../../sdc1

Qué significa: El disco problemático es actualmente /dev/sdc.

Decisión: Usa /dev/sdc para SMART y para mapear al puerto del controlador.

Tarea 3: Extraer mensajes del kernel alrededor del evento

cr0x@server:~$ sudo journalctl -k --since "2025-12-26 00:50" --until "2025-12-26 01:30" | egrep -i "ata[0-9]|reset|link|SError|I/O error" | tail -n 25
Dec 26 01:03:12 server kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
Dec 26 01:03:12 server kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Dec 26 01:03:12 server kernel: ata7: SError: { RecovComm Persist PHYRdyChg CommWake DevExch }
Dec 26 01:03:13 server kernel: ata7: hard resetting link
Dec 26 01:03:18 server kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 26 01:03:18 server kernel: ata7.00: configured for UDMA/133
Dec 26 01:03:19 server kernel: sd 6:0:0:0: [sdc] tag#11 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 26 01:03:19 server kernel: blk_update_request: I/O error, dev sdc, sector 912345678 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Dec 26 01:03:25 server kernel: ata7.00: failed command: READ FPDMA QUEUED
Dec 26 01:03:25 server kernel: ata7: hard resetting link

Qué significa: Esto es una tormenta de restablecimientos de enlace. Las frases clave son “interface fatal error,” “hard resetting link,” y banderas SError como PHYRdyChg.

Decisión: Trátalo primero como cable/backplane/controlador. Mueve el disco o cambia el cable SATA/pista del backplane antes de resilverizar.

Tarea 4: Comprobar SMART para indicadores de medio vs transporte

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Power_On_Hours|Temperature"
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       42110
194 Temperature_Celsius     0x0022   108   098   000    Old_age   Always       -       42
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   197   000    Old_age   Always       -       54

Qué significa: Pending/uncorrectable son cero: el medio parece bien. Los errores CRC no son cero y suelen subir cuando el cableado/backplane es marginal.

Decisión: Cambia cable/slot del backplane, reasienta conectores, inspecciona por curvas bruscas y tensión. Controla si el contador CRC aumenta después de los cambios.

Tarea 5: Confirmar el mapeo controlador/puerto para el disco

cr0x@server:~$ sudo ls -l /sys/block/sdc/device | head -n 5
lrwxrwxrwx 1 root root 0 Dec 26 01:25 driver -> ../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Dec 26 01:25 scsi_device -> ../../../../bus/scsi/devices/6:0:0:0
lrwxrwxrwx 1 root root 0 Dec 26 01:25 subsystem -> ../../../../bus/scsi
lrwxrwxrwx 1 root root 0 Dec 26 01:25 target6:0:0 -> ../../../../bus/scsi/targets/6:0:0

Qué significa: Estamos en tierra de traducción SCSI (normal para SATA detrás de libata). El siguiente paso es mapear a ata7 (desde los logs) y al dispositivo PCI.

Decisión: Identifica qué controlador y puerto son responsables para poder intercambiar el cable correcto o mover carga lejos de un controlador inestable.

Tarea 6: Identificar el dispositivo PCI del controlador SATA/AHCI

cr0x@server:~$ sudo lspci -nnk | egrep -A3 -i "sata|ahci"
00:17.0 SATA controller [0106]: Intel Corporation C620 Series Chipset Family SATA Controller [AHCI mode] [8086:a282]
        Subsystem: Supermicro Computer Inc Device [15d9:0888]
        Kernel driver in use: ahci
        Kernel modules: ahci

Qué significa: AHCI integrado Intel. No es inherentemente malo, pero la recuperación de errores y el aislamiento de puertos pueden ser peores comparados con un HBA en algunas combinaciones de chasis/backplane.

Decisión: Si ves reinicios repetidos en varios discos en este controlador, considera migrar discos a un HBA de buena reputación para recuperación de errores.

Tarea 7: Inspeccionar la velocidad de enlace y el estado negociado

cr0x@server:~$ sudo dmesg -T | egrep -i "ata7: SATA link|configured for UDMA" | tail -n 5
[Thu Dec 26 01:03:18 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Thu Dec 26 01:03:18 2025] ata7.00: configured for UDMA/133

Qué significa: El enlace negocia a 6.0 Gbps. Si ves bajadas frecuentes (a 3.0 o 1.5), es una gran pista de problemas de señal.

Decisión: Si la estabilidad mejora forzando 3.0 Gbps (mitigación temporal), trátalo como un problema de capa física y planifica correcciones de hardware.

Tarea 8: Comprobar contadores de error ZFS por dispositivo a lo largo del tiempo

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,80p'
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         DEGRADED     0     0     0
          raidz2-0                   DEGRADED     0     0     0
            ata-WDC_WD80EFAX-...      ONLINE      0     0     0
            ata-WDC_WD80EFAX-...      ONLINE      0     0     0
            ata-ST8000VN004-...       DEGRADED    12     0     0  too many errors

Qué significa: Errores READ pero sin CKSUM. Si CKSUM comienza a subir, podrías estar recibiendo datos corruptos (o lecturas con sectores no coincidentes) en vez de solo timeouts.

Decisión: Errores solo de READ: enfócate en restablecimientos/timeouts del enlace. Errores CKSUM: trata como riesgo de integridad—acelera la remediación y considera sacar el dispositivo si está envenenando lecturas.

Tarea 9: Limpiar errores después de arreglar la ruta (para ver si vuelven)

cr0x@server:~$ sudo zpool clear tank ata-ST8000VN004-2M2101_ZA1ABCDF
cr0x@server:~$ sudo zpool status -v tank | egrep -A2 "ata-ST8000VN004|READ|WRITE|CKSUM"
            ata-ST8000VN004-2M2101_ZA1ABCDF  ONLINE       0     0     0

Qué significa: Los contadores se reinician. Ahora nuevos errores son nuevos, no historia antigua.

Decisión: Monitoriza. Si los errores regresan rápido, no arreglaste la causa raíz.

Tarea 10: Ejecutar un self-test SMART dirigido (tras estabilizar)

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 -l selftest /dev/sdc | head -n 8
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%     42111         -

Qué significa: Las diagnósticas internas del disco no encontraron problemas obvios del medio.

Decisión: Refuerza la hipótesis de “problema de ruta.” Si las auto-pruebas fallan con errores de lectura, reconsidera el disco.

Tarea 11: Hacer un scrub tras la remediación para confirmar integridad

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | egrep -i "scan|scrub|errors"
  scan: scrub in progress since Thu Dec 26 02:10:01 2025
        1.23T scanned at 1.10G/s, 210G issued at 187M/s, 20.1T total
        0B repaired, 1.02% done, no estimated completion time
errors: No known data errors

Qué significa: El scrub está leyendo todo; si el enlace sigue siendo inestable, normalmente se mostrará aquí.

Decisión: Si los restablecimientos reaparecen durante el scrub, todavía tienes un problema de transporte. Para y arregla el hardware; no “scrubees más fuerte”.

Tarea 12: Vigilar restablecimientos en vivo durante carga

cr0x@server:~$ sudo dmesg -wT | egrep -i "ata7|hard resetting link|I/O error|SError"
[Thu Dec 26 02:14:22 2025] ata7: hard resetting link
[Thu Dec 26 02:14:27 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Qué significa: El problema está ocurriendo ahora mismo. Esto es buena noticia: los bugs reproducibles se arreglan.

Decisión: Detén cualquier resilver/scrub pesado, reasienta/reemplaza el cable y considera mover el disco a otro controlador para confirmar la correlación de ruta.

Tarea 13: Comprobar si varios discos comparten el mismo dolor (sospecha controlador/backplane)

cr0x@server:~$ sudo journalctl -k -b | egrep -i "hard resetting link|COMRESET failed|SATA link down" | awk '{print $(NF-1),$NF}' | tail
link up
link
link up
link
link up

Qué significa: No es muy legible, pero la intención es: cuenta los restablecimientos y comprueba si involucran varios puertos ataX.

Decisión: Si ves varios puertos ata reiniciándose juntos, deja de culpar discos individuales. Empieza a sospechar del controlador, la alimentación, el backplane, el expander o EMI a nivel de chasis.

Tarea 14: Verificar que ZFS vea IDs físicos de forma estable (evita renombrados sorpresa)

cr0x@server:~$ sudo zpool status -P tank | sed -n '1,40p'
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-...  ONLINE  0 0 0
            /dev/disk/by-id/ata-ST8000VN004-...   DEGRADED 12 0 0

Qué significa: Usar rutas by-id ayuda cuando el orden /dev/sdX cambia tras resets o reinicios.

Decisión: Si tu pool usa nombres /dev/sdX crudos, planifica una ventana de mantenimiento para migrar a identificadores persistentes (o al menos asegúrate de que el SO use nombres estables).

Tarea 15: Reemplazar un dispositivo correctamente cuando realmente sea el disco

cr0x@server:~$ sudo zpool offline tank ata-ST8000VN004-2M2101_ZA1ABCDF
cr0x@server:~$ sudo zpool replace tank ata-ST8000VN004-2M2101_ZA1ABCDF /dev/disk/by-id/ata-ST8000VN004-2M2101_ZA9NEWID
cr0x@server:~$ sudo zpool status tank | egrep -i "resilver|scan|state"
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 03:01:10 2025

Qué significa: Flujo correcto de reemplazo: offline → replace → monitor resilver.

Decisión: Haz esto solo después de que el enlace esté estable. Resilverizar sobre un enlace defectuoso es cómo “fabricas” errores de checksum misteriosos que consumen días.

Broma #2: Resilverizar a través de un cable SATA malo es como hacer cirugía durante un terremoto—técnicamente posible, emocionalmente innecesario.

Causas raíz: los sospechosos habituales con detalle de grado productivo

Cables: los villanos silenciosos

Los cables SATA son baratos, lo cual es genial hasta que te das cuenta de que su modo de fallo es intermitente. El cable puede pasar conectividad básica,
funcionar bien con poca carga y fallar solo durante lecturas con alta profundidad de cola, scrubs o resilvers.
Un cable también puede estar “bien” hasta que cierras el chasis o reencaminas el flujo de aire y empieza a rozar una carcasa de ventilador.

Qué hacer: Reemplaza por cables cortos y de buena calidad; evita curvas cerradas; asegúrate de que los conectores encajen; mantén los cables lejos de zonas de alta vibración.
Si tienes un backplane, el “cable” incluye el conector del backplane y sus ciclos de acoplamiento. Reasentar no es superstición; es mantenimiento.

Backplanes: integridad de señal y conectores desgastados

Los backplanes añaden conveniencia y hot-swap, pero también agregan conectores, trazas y a veces puestas a tierra cuestionables.
Un conector ligeramente oxidado puede comportarse como un generador de números aleatorios con cambios de temperatura.
Algunos backplanes son excelentes. Otros están “bien” hasta que los ejecutas a 6Gb/s con ciertos discos y un cierto controlador.

Qué hacer: Mueve el disco a otro slot; si el error se queda con el slot, encontraste la pista del backplane.
Si tu chasis lo permite, evita temporalmente el backplane con un cable directo para demostrar el punto.

Controladores AHCI integrados: adecuados hasta que no lo son

Muchos sistemas usan SATA integrado durante años. El problema es lo que pasa cuando algo sale mal.
Algunos controladores se recuperan limpiamente de glitches de enlace; otros desencadenan tormentas, bloquean puertos o reinician varios enlaces juntos.
Bajo ZFS, ese comportamiento se vuelve caro operativamente: un fallo momentáneo se convierte en errores de vdev y degradación del pool.

Qué hacer: Para almacenamiento serio, usa un HBA adecuado con buen manejo de errores y firmware estable.
Si debes usar integrado, mantén el firmware actualizado, evita gestión de energía agresiva y vigila reinicios correlacionados en varios discos.

Alimentación: la categoría “no es la alimentación” que a menudo es alimentación

Los discos consumen corriente significativa durante el spin-up y ciertas operaciones. PSUs marginales, divisores de alimentación sobrecargados
o conectores flojos pueden causar caídas momentáneas. Los restablecimientos de enlace pueden ser el síntoma educado; el síntoma brusco es un disco que desaparece.

Qué hacer: Elimina divisores, usa feeds de alimentación de backplane adecuados, verifica que las PSUs estén sanas y evita alimentar demasiados discos desde un mismo arnés.
Si los restablecimientos se correlacionan con spin-up o picos de I/O, la alimentación vuelve a la lista de sospechosos.

Templadas y vibración: el entorno contraataca

Los cambios de temperatura afectan la resistencia de los conectores y los márgenes de señal. La vibración afecta el asiento y la calidad del contacto.
Un chasis con ventiladores de alta RPM y un manojo de cables SATA tensos es básicamente un pequeño banco de pruebas mecánico.

Qué hacer: Mejora la gestión de cables, usa conectores con seguro, asegura caddies de disco correctos y estabiliza el flujo de aire.
Si los errores aparecen tras reemplazos de ventiladores o cambios de flujo, trátalo como una pista, no una coincidencia.

ALPM/HIPM/DIPM y el ahorro “útil” de energía

La gestión de energía del enlace puede provocar transiciones que el hardware marginal no puede manejar. Verás patrones raros: idle está bien,
luego un estallido de tráfico causa un restablecimiento; o al revés—activo está bien, pero idle causa caídas.

Qué hacer: Considera deshabilitar la gestión de energía agresiva del enlace para sistemas de almacenamiento, especialmente si ya viste restablecimientos.
No se trata de perseguir puntos de benchmark; se trata de mantener el bus aburrido.

Interacciones de firmware: muerte por matriz de compatibilidad

Los discos tienen peculiaridades de firmware. Los controladores tienen peculiaridades de firmware. A veces los expanders del backplane también.
Júntalos y obtienes comportamientos emergentes. El tipo de bug más molesto es el que desaparece cuando cambias una referencia de pieza.

Qué hacer: Estandariza. Mantén HBAs en modo IT donde sea apropiado, mantiene firmware consistente y evita mezclar demasiados modelos de disco en un mismo chasis si puedes.
Cuando encuentres una combinación estable, documenta y defiéndela contra el “solo este disco diferente”.

Tres micro-historias del mundo corporativo (anonimizadas, plausibles y dolorosamente familiares)

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

Una empresa SaaS mediana ejecutaba un par de servidores de almacenamiento con vdevs mirror en ZFS. Tenían alertas ocasionales: un disco se caía,
volvía y ZFS registraba algunos errores de lectura. El equipo supuso “el disco está muriendo” porque esa es la historia común.
Cambiaron el disco. Dos semanas después, otro disco en el mismo chasis hizo lo mismo.

Cambiaron ese disco también. Tras el tercer “fallo de disco” en un mes, compras se involucró, se abrieron tickets de proveedor
y se realizaron reuniones. Mientras tanto, la verdadera señal se mantenía en silencio en el atributo SMART 199: los errores UDMA CRC subían en varios discos,
pero solo en los conectados a la mitad del backplane.

La suposición equivocada fue sutil: creyeron que las fallas de disco son independientes y aleatorias. En almacenamiento ZFS, las fallas correlacionadas importan más que las individuales.
Cuando varios “discos malos” aparecen en la misma ruta física, estás viendo infraestructura compartida.

La solución fue aburrida: reemplazar el set de cables SATA afectados y reasentar los conectores del backplane durante una ventana de mantenimiento.
¿Los “discos fallidos” que habían retirado? La mayoría pasaron diagnósticos del proveedor. El equipo aprendió que cambiar piezas sin aislar variables
es solo adivinanza cara con mejor iluminación.

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

Un grupo de análisis de datos quiso reducir consumo y calor en un rack denso. Habilitaron una gestión agresiva de energía del enlace SATA
y ajustaron algunas opciones del SO para que discos y enlaces bajaran a estados de menor consumo más a menudo. En papel era razonable:
la carga era intermitente y el tiempo idle sobraba.

Dos meses después, sus ventanas de scrub empezaron a fallar. No de forma consistente—solo lo suficiente para ser enfurecedor.
Los scrubs desencadenaban una ola de hard resetting link en ciertos puertos y el pool se degradaba. Los reinicios “arreglaban” temporalmente,
lo que facilitaba el diagnóstico erróneo como un fallo de software.

El retroceso vino de la combinación de integridad de señal marginal y transiciones frecuentes de estado de energía.
El sistema era estable cuando los enlaces permanecían arriba. Era inestable cuando los enlaces rebotaban entre estados todo el día.
La optimización aumentó el número de transiciones, lo que aumentó las probabilidades de golpear el caso límite.

Revertieron las configuraciones agresivas y los restablecimientos pararon. Más tarde mejoraron el cableado y reemplazaron un backplane sospechoso,
luego reintrodujeron una gestión de energía más suave con cuidado. La lección no fue “nunca optimizar”. Fue “no optimices un sistema que no has hecho robusto”.

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

Un equipo de TI empresarial usaba ZFS para almacenamiento de VM. Tenían una costumbre que parecía tediosa: cada slot de disco estaba etiquetado, cada recorrido de cable documentado,
y cada disco estaba mapeado desde /dev/disk/by-id a una bahía física y a un puerto del controlador. También guardaban un pequeño stock de cables conocidos buenos.
Nadie lo presumía en reuniones de arquitectura.

Una noche, un pool se degradó durante una carga de lectura intensa. Las alertas incluían restablecimientos de enlace y timeouts. El ingeniero de guardia ejecutó zpool status -P,
obtuvo el dispositivo by-id y luego consultó la doc de mapeo: “Bahía 12, puerto HBA 2, pista backplane B.” No adivinó qué disco extraer.
Sacó el sled correcto en el primer intento.

Los datos SMART mostraron errores CRC pero medio limpio. Eso empujó el diagnóstico hacia “problema de ruta.”
Movieron el disco a una bahía de repuesto en otra pista, limpiaron errores y reanudaron operaciones. El pool sanó y el incidente paró.
A la luz del día, reemplazaron la pista del backplane y el cable sospechoso.

La práctica no era glamorosa. No mejoró el rendimiento. Mejoró el tiempo medio hasta recuperar la cordura.
Cuando gestionas producción, “aburrido y correcto” es una característica, no un defecto de personalidad.

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

1) Síntoma: ZFS muestra errores READ, pero SMART reallocated/pending son cero

Causa raíz: Timeouts de transporte y restablecimientos de enlace, a menudo cableado/backplane/controlador.

Solución: Revisa logs del kernel para restablecimientos; inspecciona/reemplaza el cable SATA; mueve el disco a otro puerto/slot; controla el conteo UDMA CRC antes/después.

2) Síntoma: “hard resetting link” se repite durante scrub/resilver

Causa raíz: Integridad de señal marginal que solo falla bajo profundidad de cola sostenida y lecturas/escrituras continuas.

Solución: Detén scrub/resilver; arregla la capa física primero. Tras la remediación, vuelve a correr scrub para confirmar estabilidad.

3) Síntoma: Varios discos caen en la misma marca temporal

Causa raíz: Reinicio de controlador compartido, problema de alimentación del backplane, fallo de expander/backplane o problema de PSU/harness.

Solución: Correlaciona por controlador y alimentación; inspecciona cableado de alimentación; considera migrar a un HBA mejor; verifica salud del backplane.

4) Síntoma: Errores CRC suben constantemente, pero el rendimiento parece bien

Causa raíz: El enlace “funciona” mediante reintentos. Pagas impuesto de latencia y arriesgas fallos escalados.

Solución: Reemplaza cable/slot proactivamente. Los contadores CRC no son decorativos.

5) Síntoma: Tras reiniciar, todo está “bien” por un tiempo

Causa raíz: El reinicio reasienta tiempos/estado; no arregla la ruta marginal. También reinicia contadores y esconde la tendencia.

Solución: No aceptes el reinicio como remediación. Recopila logs y SMART antes de reiniciar; luego arregla el componente físico o del controlador.

6) Síntoma: Reemplazas el disco y el nuevo disco “falla” en la misma bahía

Causa raíz: Pista del backplane o conector/cable defectuoso.

Solución: Cambia bahía/slot; reemplaza cable; inspecciona conector del backplane; para churn de RMA innecesario.

7) Síntoma: Aparecen errores de checksum ZFS junto con restablecimientos de enlace

Causa raíz: Puede que estés recibiendo datos corruptos devueltos (o lecturas no coincidentes), no solo timeouts; podría ser integridad de ruta, controlador o firmware del disco.

Solución: Escala la severidad. Asegura que la redundancia esté intacta, haz scrub tras estabilizar y considera reemplazar el componente de la ruta completa (controlador/backplane) en vez de perseguir cables individuales.

8) Síntoma: Los errores solo ocurren cuando se toca el chasis o durante mantenimiento

Causa raíz: Estrés mecánico en conectores; asiento marginal; tensión en cables; mala fijación.

Solución: Rehaz gestión de cables con holgura, usa cables con seguro, reasienta discos y verifica que sleds/conectores del backplane no estén desgastados.

Listas de verificación / plan paso a paso

Paso a paso: contener el incidente sin empeorarlo

1. Detén I/O pesado innecesario (pausa scrubs/resilvers si el enlace está reiniciándose activamente).
2. Captura evidencia: zpool status -v, ventana de journalctl -k y smartctl -a para los dispositivos afectados.
3. Decide disco vs ruta usando SMART (medio vs CRC) y logs del kernel (resets/timeouts).
4. Estabiliza la ruta: reasenta ambos extremos; reemplaza cable SATA; prueba otro slot del backplane; asegúrate de que el conector de alimentación esté sólido.
5. Limpia errores ZFS tras la remediación para que la recurrencia sea obvia.
6. Scrub una vez estable para validar integridad y dejar salir cualquier eslabón débil restante.
7. Solo entonces reemplaza discos que muestren indicadores claros de medio o fallen auto-pruebas.

Checklist de higiene de hardware (hazlo antes de estar en llamas)

• Usa cables SATA con seguro; evita “cables de la caja misteriosa”.
• Mantén recorridos de cables cortos y con holgura; sin curvas cerradas, sin tensión en conectores.
• Documenta el mapeo bahía-a-dispositivo y el mapeo de puertos de controlador.
• Estandariza HBAs y firmware; evita mezclar controladores en el mismo pool si puedes.
• Valida la calidad del backplane para operación a 6Gb/s; trata slots gastados como consumibles.
• No sobrecargues los arneses de PSU; evita divisores baratos en almacenamiento de producción.
• Programa scrubs en momentos en que puedas observar su impacto; los scrubs son diagnósticos, no solo tareas.

Checklist de decisión: ¿qué reemplazar exactamente?

• Reemplaza el disco cuando: los errores de medio suben, las auto-pruebas SMART fallan, los errores siguen al disco a través de puertos, o ZFS muestra errores persistentes de checksum ligados a ese disco.
• Reemplaza el cable cuando: los errores UDMA CRC suben, ocurren restablecimientos de enlace, o el problema desaparece tras intercambiar el cable/movimiento.
• Reemplaza/actualiza el controlador (HBA) cuando: varios puertos se reinician juntos, la recuperación de errores es pobre, o la estabilidad mejora al mover discos a otro controlador.
• Reemplaza la pista/backplane cuando: los errores se pegan a un slot sin importar el disco, o varios discos en el mismo segmento de backplane muestran problemas correlacionados.
• Arregla la alimentación cuando: las caídas se correlacionan con spin-up/picos de carga, varios discos desaparecen, o el mismo arnés alimenta todos los discos afectados.

Preguntas frecuentes (FAQ)

1) ¿Los restablecimientos de enlace SATA siempre significan un disco fallando?

No. A menudo son una falla de la ruta: cable, conector del backplane, puerto del controlador o alimentación. Usa SMART (CRC vs medio) y logs (bucles de reset) para decidir.

2) ¿Cuál es el mejor atributo SMART para sospecha de “cable malo”?

UDMA_CRC_Error_Count (atributo 199) es el indicador clásico. No es perfecto, pero un CRC creciente con contadores de medio limpios es una pista fuerte.

3) Si los errores CRC son no nulos, ¿debo entrar en pánico?

No nulo significa “algo ocurrió en algún momento.” Creciente significa “está ocurriendo ahora.” La tendencia importa. Limpia los errores ZFS, registra valores SMART y luego vigila aumentos.

4) ¿Por qué aparece esto en scrub/resilver más que en cargas normales?

Scrub/resilver es sostenido, amplio e implacable en I/O. Aumenta la profundidad de cola y ejerce cada bloque. Los enlaces marginales fallan bajo estrés sostenido.

5) ¿Pueden los errores de checksum ZFS ser causados por cableado SATA?

Sí. Si el transporte corrompe datos y el disco/controlador no lo detecta antes de entregarlos, ZFS lo detectará con checksums. Eso es ZFS haciendo su trabajo—y diciéndote que arregles la ruta.

6) ¿Debo deshabilitar NCQ para “arreglar” restablecimientos de enlace?

Deshabilitar NCQ puede reducir estrés y a veces cambia el timing lo suficiente para enmascarar un problema, pero normalmente es un parche. Arregla el problema físico/controlador. No bases una estrategia de almacenamiento en supersticiones.

7) ¿Por qué los errores a veces desaparecen después de mover cables?

Porque reasentar cambia la resistencia de contacto, la alineación y la tensión mecánica. Si reasentar lo arregla, tenías un problema de conector/cable/backplane. Trátalo como diagnóstico, no como solución definitiva.

8) ¿Cuándo debo reemplazar el controlador/HBA en vez de perseguir cables?

Cuando ves restablecimientos correlacionados en varios puertos, recuperación pobre de errores o inestabilidad que sigue al controlador en vez de a un disco. También cuando dependes de AHCI integrado para pools serios y actúa como si te odiara.

9) ¿Es seguro resilverizar mientras ocurren restablecimientos de enlace?

Es arriesgado. Alargarás el incidente, aumentarás el estrés en el pool y podrías desencadenar más fallos. Estabiliza el enlace primero, luego resilveriza.

10) ¿Cómo demuestro que es la pista del backplane?

Inserta un disco conocido bueno en ese slot y mueve el disco sospechoso a otro slot. Si el error se queda con el slot, tienes un problema de pista/conector del backplane.

Siguientes pasos que realmente puedes hacer mañana

Si ves restablecimientos de enlace SATA en un sistema ZFS, tu trabajo es volver a hacer aburrido el camino de I/O. ZFS se encargará de la integridad,
pero no puede soldar conectores por ti.

1. Basaliza tu evidencia: captura zpool status -v, logs del kernel alrededor del reset y smartctl -a de los discos afectados.
2. Clasifica: indicadores de medio → disco; CRC/bucles de reset → ruta; restablecimientos correlacionados en varios discos → controlador/energía/backplane.
3. Haz un cambio a la vez: intercambia cable, cambia slot, cambia de controlador. Confirma que el problema sigue al componente que sospechas.
4. Limpia y monitoriza: reinicia contadores ZFS tras la remediación; controla si los errores vuelven durante un scrub.
5. Mejora el eslabón débil: si ejecutas almacenamiento ZFS serio sobre SATA integrado defectuoso, pasa a un HBA adecuado y a un backplane/cableado en el que puedas confiar.

La idea no es eliminar todos los fallos. La idea es eliminar fallos ambiguos—aquellos que hacen perder tiempo, desencadenan RMA innecesarios y amenazan silenciosamente la redundancia.
Arregla la ruta y luego deja que ZFS haga el trabajo para el que lo elegiste.