Debian 13 reinicios de enlace SATA: demuestra que es el cable o la backplane, no Linux

Qué es realmente un reinicio de enlace SATA (y qué no es)

Un “reinicio de enlace SATA” es cuando el controlador intenta restablecer el enlace físico y de protocolo con un disco. Linux lo informa a través de libata (el subsistema del kernel que maneja ATA/SATA). Verás frases como:

• link is slow to respond
• COMRESET failed
• hard resetting link
• SATA link up 6.0 Gbps (después de la recuperación)
• ataX: device reported invalid CHS (a menudo ruido)
• I/O error, dev sdX (el radio de impacto visible por las aplicaciones)

Distinción importante: un reinicio de enlace no es lo mismo que un error de medio.

• Error de medio: el disco no puede leer un sector de forma fiable. Normalmente incrementa atributos SMART como “Reallocated_Sector_Ct” o registra errores de lectura.
• Error de enlace: el controlador y el disco no pueden comunicarse correctamente. Esto suele incrementar SMART “UDMA_CRC_Error_Count” y aparece como reinicios/tiempos de espera. Los platos pueden estar bien; la conversación no.

Linux no está “provocando” que la señal eléctrica se degrade. Pero Linux será absolutamente el mensajero, y se lo echarán en cara. Tu trabajo es separar: (1) una regresión del kernel, (2) un problema del controlador/firmware, (3) un disco que está fallando, (4) un cable/backplane/camino de alimentación que no mantiene un enlace estable.

Aquí está la realidad operativa: si ves reinicios de enlace repetidos y errores CRC en una bahía/puerto, intercambiar el disco suele “arreglarlo” solo porque volviste a asentar el cable o cambiaste el patrón de vibración. Eso no es una solución; es que ganaste en la ruleta.

Una cita para mantener la honestidad: “La esperanza no es una estrategia.” — Gen. Gordon R. Sullivan

Chiste #1: Un cable SATA es como una invitación a una reunión—todo parece bien hasta que empieza a perder paquetes y todos culpan al calendario.

Hechos y contexto: por qué SATA falla así

Algunos puntos cortos y concretos de contexto que te ayudan a razonar sobre lo que ves en los registros de Debian 13. No son trivialidades por amor al arte; explican las modalidades de fallo.

1. SATA es serial, pero sigue siendo analógico en los bordes. Los bits viajan sobre un enlace eléctrico sensible a la impedancia, el apantallamiento, el desgaste de los conectores y la diafonía—especialmente en backplanes densos.
2. COMRESET es un verdadero apretón de manos eléctrico. Cuando ves “COMRESET failed”, el host está intentando resetear el enlace a nivel PHY y no obtiene una respuesta limpia. Eso suele ser cable/backplane, a veces alimentación, ocasionalmente el controlador.
3. Los errores CRC de SMART fueron básicamente inventados para detectar problemas de cableado. “UDMA_CRC_Error_Count” incrementa cuando el disco detecta errores de transmisión entre disco y host. Los errores de medio no lo incrementan.
4. NCQ hizo SATA más rápido y la depuración más difícil. Native Command Queuing permite múltiples comandos en curso. Cuando el enlace se vuelve inestable, las fallas pueden parecer tiempos de espera en una cola, no errores limpios de “sector de lectura malo”.
5. Los conectores SATA de consumo no están diseñados para ciclos infinitos de reinserción. Un backplane que ha visto años de intercambios de discos sufre desgaste: cambia la tensión de los resortes, aparece oxidación, el plástico se deforma con el calor.
6. Muchos “backplanes SATA” son realmente pasivos hasta que dejan de serlo. Algunos tienen multiplexores, retimers, LEDs o conectores baratos que funcionan bien a 1.5 Gbps y se vuelven caóticos a 6.0 Gbps.
7. La recuperación de errores de libata en Linux es agresiva por diseño. Intenta hard resets, soft resets, reducir velocidad y revalidaciones. Esto es bueno para la disponibilidad y terrible para buscar culpables.
8. Las negociaciones de velocidad a una tasa menor son una señal inequívoca. Un puerto que negocia de 6.0 a 3.0 o 1.5 Gbps bajo carga suele indicar un problema de integridad de señal, no un bug de sistema de archivos.
9. La vibración y el calor importan más de lo que se admite. Una conexión apenas marginal puede fallar solo durante picos de E/S (más EMI, más calor) o durante cambios en el perfil de ventiladores.

Guion de diagnóstico rápido (primero/segundo/tercero)

Estás de guardia. La matriz está degradada. La aplicación hace timeouts. Necesitas el camino más rápido a “qué reemplazamos y qué dejamos de tocar”. Este es ese camino.

Primero: confirma que es inestabilidad a nivel de enlace, no solo un disco que muere

• Escanea journalctl/dmesg buscando hard resetting link, COMRESET, failed command: READ FPDMA QUEUED, link up/down.
• Revisa SMART UDMA_CRC_Error_Count (o el registro PHY SATA si está disponible). Si está aumentando, trata a cableado/backplane como sospecha principal.
• Comprueba si los reinicios siguen una bahía/puerto, no un número de serie específico del disco.

Segundo: correlaciona errores con un solo puerto/bahía bajo carga

• Mapea /dev/sdX → ataX → puerto del controlador → bahía física.
• Busca cambios de velocidad de enlace y reinicios repetidos en el mismo ataX.
• Ejecuta una prueba de lectura controlada en ese disco solo y observa los registros en vivo.

Tercero: aísla el dominio de fallo con intercambios que te enseñen algo

• Intercambia la ruta de cableado/backplane antes de cambiar el SO o “tunear el kernel”. Mueve el disco a otra bahía; si los errores se quedan con la bahía, tienes al culpable.
• Cambia a un cable conocido bueno (o a un conector diferente del backplane) y vuelve a ejecutar la misma prueba de carga.
• Sólo después de descartar cableado/backplane/alimentación inviertas tiempo en firmware, controladores del HBA o regresiones del kernel.

Ese orden no es ideología. Es matemática: fallos de cableado y backplane son comunes, rápidos de probar y no aparecen en tu pipeline de CI.

Tu estándar de evidencia: construir un caso que resista un postmortem

Si quieres detener el bucle “Linux lo rompió”, necesitas una cadena repetible de evidencia:

1. Línea temporal: marcas de tiempo exactas de reinicios y errores de I/O.
2. Identidad: qué disco (WWN y serial), qué ataX, qué puerto del HBA, qué bahía.
3. Tipo de señal: CRC/enlace/apretón de manos vs reasignación de medio vs bug del controlador.
4. Reproducción: una prueba que dispare el error (o no) en condiciones controladas.
5. Resultado del intercambio: el error sigue a la bahía/cable/backplane (ruta de hardware) o sigue al disco (dispositivo).

Una actualización de kernel puede cambiar el timing lo suficiente como para revelar un enlace marginal. Eso no significa que el kernel “rompiera SATA”. Significa que el kernel dejó de caminar sobre puntillas alrededor de tu capa física defectuosa.

Tareas prácticas: comandos, salidas, qué significan y qué decides

Estas son tareas reales que puedes ejecutar en Debian 13. Cada una incluye: un comando, salida de ejemplo, qué significa y la decisión que tomas a partir de ello. No ejecutes pruebas de esfuerzo en una matriz de producción sin coordinar; “caos controlado” sigue siendo caos.

Task 1: Pull a focused SATA/libata error timeline from the journal

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i "ata[0-9]+|sata|hard reset|link up|link down|comreset|i/o error|exception"
Dec 29 10:11:02 server kernel: ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0x6 frozen
Dec 29 10:11:02 server kernel: ata7: SError: { CommWake 10B8B DevExch }
Dec 29 10:11:02 server kernel: ata7: hard resetting link
Dec 29 10:11:03 server kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 29 10:11:03 server kernel: ata7.00: configured for UDMA/133
Dec 29 10:11:04 server kernel: blk_update_request: I/O error, dev sde, sector 124518400 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Significado: Emask 0x10 y las banderas SErr con un hard reset sugieren fuertemente un evento de transporte/enlace. El error de I/O es daño colateral.

Decisión: Trata esto como inestabilidad de enlace hasta que se demuestre lo contrario. Siguiente paso: identificar qué disco es sde y revisar sus contadores CRC de SMART.

Task 2: Confirm which disk is sde (serial, WWN, model)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,HCTL /dev/sde
NAME SIZE MODEL            SERIAL         WWN                HCTL
sde  12T  ST12000NM0008-2A ZS2ABC12       0x5000c500cafe1234 3:0:6:0

Significado: Ahora tienes identificadores estables (serial/WWN) y una ruta HCTL.

Decisión: Usa WWN/serial en tickets y postmortems, no /dev/sde. Los nombres de dispositivo cambian; los WWN no (usualmente).

Task 3: Read SMART attributes; look specifically for CRC errors vs media errors

cr0x@server:~$ sudo smartctl -a /dev/sde | egrep -i "UDMA_CRC_Error_Count|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|SMART overall"
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
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   200   000    Old_age   Always       -       47

Significado: El medio parece limpio (no hay reasignaciones/pending). Los errores CRC son distintos de cero. Los errores CRC casi siempre indican problemas de cableado/backplane/controlador, no la superficie del disco.

Decisión: Deja de cambiar discos “porque está fallando”. Enfócate en el enlace: cable, conector del backplane, puerto del HBA y ruta de alimentación a esa bahía.

Task 4: Check whether CRC errors are still increasing

cr0x@server:~$ sudo smartctl -A /dev/sde | awk '$1==199{print}'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       47

cr0x@server:~$ sleep 60; sudo smartctl -A /dev/sde | awk '$1==199{print}'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       49

Significado: Subió de 47 a 49 en un minuto. Eso es un problema activo de transporte.

Decisión: Escala a intervención física. Planifica una ventana de mantenimiento si la matriz es redundante; si no lo es, trátalo como riesgo inminente de outage.

Task 5: Watch kernel messages live while you do a controlled read

cr0x@server:~$ sudo dmesg -Tw
[Sun Dec 29 10:21:17 2025] ata7: hard resetting link
[Sun Dec 29 10:21:18 2025] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[Sun Dec 29 10:21:18 2025] ata7.00: configured for UDMA/133

cr0x@server:~$ sudo dd if=/dev/sde of=/dev/null bs=4M status=progress iflag=direct
12582912000 bytes (13 GB, 12 GiB) copied, 7 s, 1.8 GB/s

Significado: El enlace volvió a 3.0 Gbps en lugar de 6.0. Esa degradación de velocidad es clásica de “la integridad de la señal empeoró bajo estrés”.

Decisión: Marca la ruta de bahía/puerto como sospechosa. Planifica el cambio del cable/conexión del backplane para ese puerto. No pierdas tiempo afinando planificadores de I/O.

Task 6: Identify the libata “ata7” mapping in sysfs

cr0x@server:~$ readlink -f /sys/class/block/sde/device
/sys/devices/pci0000:00/0000:00:1f.2/ata7/host6/target6:0:6/6:0:6:0

Significado: Puedes enlazar el dispositivo de bloque a un puerto ATA específico (ata7) y host.

Decisión: Usa esta ruta para encontrar el dispositivo PCI del controlador y, desde ahí, la cadena slot/HBA/backplane.

Task 7: Confirm the controller PCI identity and driver

cr0x@server:~$ lspci -nnk | egrep -A3 -i "sata|ahci|scsi|sas"
00:1f.2 SATA controller [0106]: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller [8086:3a22]
	Subsystem: Supermicro Computer Inc Device [15d9:0801]
	Kernel driver in use: ahci
	Kernel modules: ahci

Significado: Estás en AHCI (SATA integrado común). Si fuera un HBA, verías mpt3sas, megaraid_sas, etc.

Decisión: Si esto es SATA integrado con un cableado de backplane barato, asume fragilidad física hasta que se demuestre lo contrario.

Task 8: Verify link speed and negotiated features (where available)

cr0x@server:~$ sudo grep -H . /sys/class/ata_link/link*/sata_spd 2>/dev/null | head
/sys/class/ata_link/link6/sata_spd: 3.0 Gbps
/sys/class/ata_link/link7/sata_spd: 6.0 Gbps

Significado: Al menos un enlace está a 3.0 Gbps. Si tus discos y controlador soportan 6.0, esto puede ser una renegociación a menor velocidad tras errores.

Decisión: Trata una degradación sostenida en el puerto problemático como evidencia. Inclúyelo en las notas del incidente; es persuasivo para quienes no son del kernel.

Task 9: Inspect per-disk error counters and kernel “timeout” patterns

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i "failed command|READ FPDMA|WRITE FPDMA|cmd|timeout|resetting"
Dec 29 10:21:16 server kernel: ata7.00: failed command: READ FPDMA QUEUED
Dec 29 10:21:16 server kernel: ata7.00: cmd 60/08:00:00:10:6e/00:00:00:00:00/40 tag 0 ncq dma 4096 in
Dec 29 10:21:16 server kernel: ata7.00: status: { DRDY }
Dec 29 10:21:16 server kernel: ata7: softreset failed (1st FIS failed)
Dec 29 10:21:17 server kernel: ata7: hard resetting link

Significado: “FIS failed” y tiempos de espera de comandos con reinicios son consistentes con fallo de transporte, no con “el sistema de archivos está molesto”.

Decisión: Procede a aislar moviendo el disco a otra bahía o intercambiando el cable. Acciones solo de software no detendrán la física.

Task 10: Check if the drive is actually being power-cycled (power path/backplane)

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i "rejecting i/o|device offline|Spinning|Start/Stop|Power-on|reset"
Dec 29 10:21:19 server kernel: sd 6:0:6:0: [sde] rejecting I/O to offline device
Dec 29 10:21:19 server kernel: sd 6:0:6:0: [sde] tag#12 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00

Significado: “offline device” puede ocurrir por pérdida de enlace, pero si va acompañado de mensajes repetidos de “nuevo disco” detectado, sospecha interrupciones de alimentación o comportamiento del backplane.

Decisión: Si ves ciclos de remove/add, prioriza conectores de alimentación del backplane y la estabilidad de las rails de la PSU. Los reinicios de enlace más desaparición del dispositivo son una alarma más fuerte.

Task 11: Verify drive identity is stable across resets (same WWN comes back)

cr0x@server:~$ udevadm info --query=all --name=/dev/sde | egrep "ID_WWN=|ID_SERIAL=|DEVPATH="
E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata7/host6/target6:0:6/6:0:6:0/block/sde
E: ID_SERIAL=ST12000NM0008-2A_ZS2ABC12
E: ID_WWN=0x5000c500cafe1234

Significado: Puedes confirmar que la misma identidad regresa tras un reset. Si la identidad cambia o desaparece, puede que tengas un multiplexor del backplane inestable o un problema del controlador.

Decisión: Identidad estable + CRC en aumento apunta a calidad del enlace físico más que a rarezas del firmware del disco.

Task 12: If you run mdadm, confirm whether the array is dropping the same member repeatedly

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5]
md0 : active raid10 sde1[2](F) sdb1[0] sdc1[1] sdd1[3]
      11718067200 blocks super 1.2 512K chunks 2 near-copies [4/3] [_UUU]

Significado: (F) indica un miembro fallado. Si la misma ranura sigue fallando, raramente es “Linux RAID es inestable”; es la ruta de enlace subyacente.

Decisión: No vuelvas a añadir el mismo disco sin abordar el transporte. Quemarás ciclos de reconstrucción y aumentas el riesgo de una segunda falla.

Task 13: If you run ZFS, see whether errors are checksum or I/O-level, and which vdev

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: Replace the device using 'zpool replace'.
  scan: resilver in progress since Sun Dec 29 10:30:01 2025
config:

	NAME                        STATE     READ WRITE CKSUM
	tank                        DEGRADED     0     0     0
	  raidz2-0                  DEGRADED     0     0     0
	    wwn-0x5000c500cafe1234  DEGRADED     5     0     0  too many errors
	    wwn-0x5000c500beef5678  ONLINE       0     0     0
	    wwn-0x5000c500abcd9999  ONLINE       0     0     0
	    wwn-0x5000c5001234aaaa  ONLINE       0     0     0

Significado: ZFS muestra errores de LECTURA en un WWN específico. Eso es consistente con reinicios de enlace causando fallos de I/O (no necesariamente desajustes de checksum).

Decisión: Si CKSUM es cero y READ es distinto de cero junto con reinicios de libata, probablemente no sea corrupción silenciosa: son lecturas fallidas por caídas de enlace. Arregla el transporte primero y luego limpia/reemplaza.

Task 14: Check drive temperature and error log to rule out overheating-induced instability

cr0x@server:~$ sudo smartctl -a /dev/sde | egrep -i "Temperature|Error Log|ATA Error Count"
194 Temperature_Celsius     0x0022   037   045   000    Old_age   Always       -       63
SMART Error Log Version: 1
ATA Error Count: 0

Significado: 63°C es alto para muchos discos SATA empresariales. Puede seguir “trabajando”, pero los márgenes de señal se reducen con el calor y los backplanes se deforman.

Decisión: Mejora la refrigeración y vuelve a probar. Si los errores solo ocurren en caliente, no declares victoria tras una prueba en sala fría.

Mapear /dev/sdX a un puerto físico sin adivinar

La forma más rápida de perder credibilidad es sacar el disco equivocado. La segunda más rápida es “reconectar cables” genéricamente y darlo por hecho. Mapea.

Usa identificadores estables: WWN, serial, HCTL y ataX

Empieza con WWN/serial desde lsblk o udevadm. Luego conecta esos datos a:

• HCTL (Host:Channel:Target:Lun) para la enumeración estilo SCSI (común en HBAs)
• ataX para numeración de puertos libata (común en AHCI y muchas rutas SATA)
• Ruta PCI para encontrar el controlador real

En muchos servidores, el eslabón perdido es el etiquetado físico de las bahías. La solución correcta no es “conocimiento tribal”. Es documentación: un mapa de puertos desde puerto HBA → conector del backplane → números de bahía.

Enfoque práctico de mapeo cuando no tienes un mapa de puertos

1. Identifica el disco con fallo por WWN/serial.
2. Encuentra su DEVPATH y la asociación ataX.
3. Correlaciona ataX con el conector de la placa base/HBA comprobando diagramas de cableado, el manual del chasis o trazando físicamente durante una ventana.
4. Valida moviendo solo ese disco a otra bahía y viendo si los errores siguen a la bahía.

Ese último paso importa porque convierte “sospecha informada” en evidencia.

Patrones de hardware: cómo los cables y backplanes se autoincriminan

Cuando la gente culpa a Linux, normalmente reaccionan a una correlación: “actualizamos Debian y luego los discos empezaron a reiniciarse”. Esa correlación es real. Simplemente no significa lo que piensan.

Aquí están los patrones que separan con fiabilidad los dominios de fallo.

Patrones de fallo por cable

• Los errores CRC aumentan (atributo SMART 199) mientras reasignaciones/pending se mantienen estables.
• Los errores se correlacionan con vibración o movimiento: golpear el chasis, rampa de ventiladores, movimiento de racimos de cables cercanos.
• El problema sigue al cable/conexión del backplane: mover el disco a otra bahía lo arregla sin reemplazar el disco.
• La velocidad de enlace se degrada a 3.0/1.5 Gbps en ese puerto tras reinicios.

Qué hacer: reemplaza el cable por uno conocido bueno, idealmente más corto y mejor apantallado; evita curvas pronunciadas; reruta lejos de racimos de potencia cuando sea posible. Si es un Mini-SAS a SATA breakout, trátalo como consumible.

Patrones de fallo de backplane

• Sólo una bahía está maldita, independientemente del modelo o serial del disco.
• La presencia del disco parpadea: el SO registra la desaparición y reaparición del disco.
• Varios discos en el mismo segmento del backplane muestran errores tras un aumento de temperatura o un evento de vibración.
• Comportamiento extraño de LEDs/SGPIO: LEDs de actividad atascados o parpadeo en bahía equivocada puede correlacionar con problemas de señal o puesta a tierra en backplanes baratos.

Qué hacer: mueve el disco a otra bahía como prueba; si la bahía es culpable, reemplaza el backplane o deja de usar esa ranura. “Limpiar contactos” no es un plan a menos que también controles la recurrencia con reemplazo.

Patrones de fallo de la ruta de alimentación

• Reinicios simultáneos en múltiples puertos, a menudo tras un escalón de carga (picos de CPU, rampas de ventiladores, arranque de discos).
• Los reinicios de discos coinciden con alarmas de PSU o caídas de voltaje reportadas por BMC.
• Los discos registran eventos relacionados con la alimentación (depende del modelo; a menudo no es explícito).

Qué hacer: verifica la salud de la PSU, el cableado de alimentación al backplane y si el arranque de discos está escalonado. Una PSU “buena” aún puede fallar en respuesta a transitorios.

Patrones de fallo de controlador/firmware

• Los errores se extienden por muchos puertos sin correlación con una bahía única.
• Los reinicios se desencadenan por patrones de comandos específicos (TRIM, profundidad NCQ, escrituras encoladas) y desaparecen con actualizaciones de driver/firmware.
• Los registros del kernel muestran reinicios del controlador, no solo reinicios de enlace.

Qué hacer: comprueba niveles de firmware; prueba con otro HBA si es posible. Pero no uses “tal vez el controlador” como excusa para ignorar evidencia de CRC.

Patrones de fallo del disco

• Reasignaciones/pending aumentan, SMART falla en health, los autotests fallan.
• Los errores siguen al disco a una bahía y cable conocidos buenos.
• El registro de errores SMART muestra fallos de lectura/escritura sin crecimiento correspondiente de CRC.

Qué hacer: reemplaza el disco y no discutas con los números.

Chiste #2: Si tu almacenamiento “solo falla bajo carga”, felicitaciones—has construido un sistema perfectamente fiable cuando está inactivo.

Tres mini-historias corporativas desde el terreno

1) El incidente causado por una suposición equivocada: “Es el nuevo kernel de Debian”

El entorno era ordinario: un par de máquinas Debian ejecutando una base de datos replicada, cada una con varios SSD SATA en un chasis frontal hot-swap. Una actualización rutinaria trajo un kernel más nuevo y, en un día, un nodo empezó a lanzar reinicios ata. El equipo hizo lo que hacen los equipos: revertieron el kernel.

Los errores se redujeron, pero no se detuvieron. Esa fue la primera pista. La segunda pista fue peor: el otro nodo empezó a mostrar reinicios ocasionales también. Entonces la narrativa cambió de “regresión del kernel” a “quizá el firmware del SSD odia Linux”. Se abrió un ticket al proveedor. Se invirtió tiempo en recopilar trazas del kernel que dijeron a todos lo que ya sabían: el enlace se estaba reiniciando.

Lo que finalmente rompió el bucle fue una correlación disciplinada. Un SRE comparó el UDMA_CRC_Error_Count para cada disco en el chasis. Solo los discos en las bahías 5–8 tenían CRC en aumento. Esas bahías compartían un conector de backplane y una corrida de cable breakout. La actualización no fue la causa; fue el momento en que el sistema se puso lo bastante ocupado como para exponer una conexión marginal.

La “solución” fue aburrida: reemplazar el cable breakout y asentar de nuevo el conector del backplane. Luego volver a ejecutar la misma carga que antes desencadenaba reinicios. Los errores no volvieron. El kernel siguió actualizado. El postmortem fue incómodo porque la suposición equivocada no era tonta; era plausible. Pero lo plausible no es prueba, y la producción no te paga por lo plausible.

2) La optimización que salió mal: “Aumentemos la profundidad de cola y ahorremos dinero”

Una flota intensiva en almacenamiento se estaba ajustando para rendimiento. Alguien leyó que colas más profundas y más paralelismo mejoran la utilización. Aumentaron la concurrencia de I/O en la aplicación y también ajustaron algunas configuraciones de la capa de bloques para mantener los discos ocupados. Los benchmarks iniciales fueron geniales. Todos se felicitaron y siguieron con su trabajo.

Dos semanas después, un subconjunto de hosts comenzó a ver fallos esporádicos READ FPDMA QUEUED y reinicios de enlace. Las fallas se agrupaban durante las ventanas de batch. El equipo trató el problema como de carga y distribuyó trabajos, lo que ayudó. Esa fue la trampa: el sistema solo era estable cuando era menos útil.

La causa raíz resultó ser física. El chasis usaba cables SATA largos enrutados junto a arneses de potencia de alta corriente. A baja I/O, los márgenes de enlace eran apenas aceptables. Con mayor profundidad de cola, los discos y el controlador trabajaban más, el perfil térmico cambió y la tasa de errores de enlace aumentó—hasta que libata empezó a resetear puertos. No ocurrió nada “místico”; movieron un sistema de “funciona en laboratorio” a “falla a escala” apoyándose en márgenes de señal delgados.

La acción correctiva no fue abandonar la optimización. Fue tratar el cableado como parte del envelope de rendimiento: cables más cortos, enrutamiento más limpio y, en algunos casos, mover cargas de alta intensidad a HBAs SAS con conectores más robustos. Tras eso, el mismo ajuste ya no desencadenaba reinicios. La optimización no fue la villana. Optimizar encima de hardware inestable sí lo fue.

3) La práctica aburrida pero correcta que salvó el día: un mapa real de puertos e identificadores consistentes

Otra organización ejecutaba almacenamiento mixto: algo de mdadm, algo de ZFS, muchas bahías hot-swap. Tenían una costumbre casi anticuada: cada chasis tenía un mapa de puertos en el runbook. Listaba números de puerto HBA, números de parte de cables, etiquetas de conector del backplane y el rango de bahías que servía cada conector. También registraban WWN de los discos en inventario cuando se instalaban.

Una tarde, un host empezó a registrar reinicios de enlace en un disco. El on-call siguió el playbook: identificar el WWN, mapear al puerto HBA, mapear a la bahía. No sacaron discos al azar. No reiniciaron “para limpiarlo”. No degradaron un kernel. Moveron el disco a una bahía de repuesto en el mismo host y repitieron la prueba de lectura. Los errores se quedaron con la bahía original.

Con eso, la remediación fue precisa: el conector del backplane para ese grupo de bahías se reemplazó durante una ventana planificada. El disco siguió en servicio y nunca mostró errores de medio. El ticket fue corto y convincente porque tenían los recibos: errores CRC, correlación de bahía y un intercambio de aislamiento exitoso.

Esto es lo que a la gente no le gusta: el “debug heroico” fue innecesario porque existía trabajo aburrido previo. La documentación no hace que nadie se sienta inteligente, pero hace que el sistema sea más barato de operar. Ese es el trabajo.

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

Esto es lo que mantiene incidentes más tiempo del necesario.

1) Síntoma: repetidos hard resetting link + CRC en aumento

Causa raíz: ruta de señal SATA marginal (cable, conector, backplane).
Solución: reemplazar cable/ruta del backplane; rerutar; evitar curvas cerradas; retestar bajo carga; verificar que el contador CRC deje de aumentar.

2) Síntoma: el disco cae totalmente y vuelve como “nuevo”

Causa raíz: interrupción de alimentación a la bahía/backplane, o detección de presencia del backplane oscilante.
Solución: inspeccionar/reemplazar conectores de alimentación del backplane; revisar salud de la PSU; comprobar tensiones compartidas en arneses; validar logs del BMC.

3) Síntoma: los errores “se mueven” después de que intercambias discos

Causa raíz: reinsertaste o perturbaste el cable/conector que fallaba, mejorando temporalmente el contacto.
Solución: deja de decir que está arreglado; ejecuta una prueba de carga controlada y observa los contadores CRC; reemplaza el cable sospechoso igualmente.

4) Síntoma: el enlace negocia a 1.5/3.0 Gbps tras reinicios

Causa raíz: degradación por recuperación de errores que baja la velocidad debido a mala integridad de señal.
Solución: trátalo como problema de capa física; reemplaza cable/backplane; confirma que se mantiene a 6.0 Gbps bajo carga sostenida.

5) Síntoma: “El cambio del planificador de I/O de Linux lo arregló”

Causa raíz: redujiste la intensidad de I/O, ocultando el problema.
Solución: mantén el planificador si ayuda, pero reemplaza el enlace marginal. Los fallos ocultos vuelven cuando necesites rendimiento.

6) Síntoma: las reconstrucciones ZFS/mdadm siguen reiniciando en el mismo disco

Causa raíz: transporte inestable causando fallos de I/O transitorios durante lecturas/escrituras secuenciales pesadas.
Solución: arregla el enlace primero; luego reconstruye una vez. Las tormentas de reconstrucción son cómo conviertes un camino defectuoso en un outage.

7) Síntoma: la actualización del kernel “disparó” el problema

Causa raíz: la carga, el timing o el perfil de alimentación cambiaron lo suficiente como para exponer un camino marginal; el kernel es catalizador, no causa.
Solución: mantén la actualización a menos que reproduzcas en el kernel antiguo y pruebes una regresión; enfócate en evidencia física (CRC, correlación de bahía).

Listas de verificación / plan paso a paso

Lista de respuesta a incidentes (mientras el sistema está degradado)

1. Captura registros: journalctl -k alrededor del evento. Guárdalos en un lugar duradero.
2. Registra la identidad del disco: modelo, serial, WWN, HCTL y mapeo ataX.
3. Revisa SMART para indicadores de medio vs CRC. Si CRC aumenta, eleva a cableado/backplane.
4. Reduce el radio de impacto: pausa trabajos pesados no esenciales; evita intentos repetidos de reconstrucción.
5. Si existe redundancia, planifica un intercambio de aislamiento controlado (mover disco a otra bahía).
6. Después del cambio físico, ejecuta la misma prueba de lectura y observa registros en vivo.
7. Verifica contadores: el CRC debe dejar de aumentar; el enlace debe permanecer a la velocidad esperada.

Plan para la ventana de mantenimiento (qué reemplazar y en qué orden)

1. Reemplaza el cable SATA/breakout que sirve el puerto/bloque de bahías con fallo.
2. Si persisten fallos y siguen la bahía, reemplaza/repara el segmento del backplane o deja de usar la bahía.
3. Valida la alimentación: asienta conectores de alimentación al backplane; comprueba estado de la PSU; verifica que no haya brownouts bajo carga.
4. Solo entonces considera actualizaciones de firmware del controlador o cambiar el HBA/placa base SATA.
5. Ejecuta un burn-in de lectura/escritura sostenida en los discos afectados después de los cambios.

Lista de endurecimiento post-incidente (prevenir la secuela)

1. Crea un mapa de puertos: puerto HBA → etiqueta de cable → conector del backplane → números de bahía.
2. Estandariza el uso de nombres basados en WWN en configuraciones ZFS/mdadm cuando sea posible.
3. Monitorea contadores CRC SMART a lo largo del tiempo; alerta por deltas, no solo umbrales absolutos.
4. Mantén cables conocidos buenos de repuesto y (si es posible) un backplane de repuesto a mano.
5. Documenta un procedimiento de prueba de aislamiento para que el siguiente on-call no improvise.

FAQ

1) ¿Un reinicio de enlace SATA siempre significa que el disco está malo?

No. A menudo el disco está bien y el enlace no. Si SMART muestra UDMA_CRC_Error_Count en aumento con atributos de medio limpios, sospecha cableado/backplane primero.

2) Si SMART overall-health dice PASSED, ¿puede el disco seguir siendo el problema?

Sí. SMART “PASSED” no es una garantía; es una comprobación de umbral débil. Pero para casos de reinicio de enlace, el discriminador suele ser CRC vs reasignaciones/pending.

3) ¿Por qué empezó justo después de actualizar a Debian 13?

Porque el timing, la gestión de energía o el patrón de carga cambiaron. Una actualización de kernel puede cambiar patrones de I/O y exponer hardware marginal. Trata la actualización como un disparador, no como prueba de causalidad.

4) ¿Puede la mala alimentación causar errores CRC?

Indirectamente. La inestabilidad de alimentación puede causar caídas de enlace y reinicios de dispositivo, y el comportamiento resultante puede parecer un problema de transporte. Si los discos desaparecen y reaparecen, investiga la alimentación y los circuitos de detección del backplane.

5) ¿Es seguro seguir en funcionamiento si los CRC son no cero pero estables?

Si el contador CRC es antiguo y no está aumentando, puede ser un evento histórico (un cable fue movido una vez). Si está aumentando, estás perdiendo integridad de enlace activamente y debes arreglarlo con prontitud.

6) ¿Cómo pruebo que es el backplane y no el disco?

Mueve el mismo disco (mismo WWN/serial) a otra bahía/camino de cableado. Si los errores paran, la bahía/camino antiguo es culpable. Si los errores siguen al disco, el disco es culpable.

7) ¿Por qué veo la velocidad de enlace caer a 3.0 Gbps?

Tras errores, SATA puede renegociar a una velocidad menor para mantener estabilidad. Eso es señal de calidad de señal marginal. No es una “característica de rendimiento”.

8) ¿Debo cambiar parámetros del kernel o ajustes de libata para reducir reinicios?

Evita usar parámetros del kernel como parche a menos que estés diagnosticando un problema confirmado de driver/controlador. Si la evidencia física apunta al enlace, cambiar timeouts solo cambia cuánto tiempo esperas antes de fallar.

9) ¿Qué pasa si múltiples discos en diferentes bahías muestran aumentos de CRC?

Sospecha algo compartido: un racimo de cables, un conector del backplane que alimenta múltiples bahías, un grupo de puertos del HBA o la alimentación. Busca la comúnidad, no la coincidencia.

10) ¿Necesito SAS para evitar esto?

No estrictamente, pero los conectores y cables SAS suelen ser más robustos en entornos de servidor. SATA puede ser fiable; solo exige más disciplina en la capa física que muchos chasis proporcionan.

Conclusión: siguientes pasos que realmente reducen el riesgo

Si Debian 13 está registrando reinicios de enlace SATA, trátalo como una investigación, no como un debate. Linux te está diciendo lo que ve. Tu trabajo es determinar si el problema está en los platos, en el controlador o en el cobre y plástico que todos olvidan que existen.

Haz esto a continuación, en orden:

1. Extrae una línea temporal ajustada del kernel y captura la evidencia.
2. Revisa SMART: CRC vs atributos de medio. Si CRC se mueve, deja de culpar a los sistemas de archivos.
3. Mapea el dispositivo con fallo a ataX/HCTL y a una bahía física.
4. Ejecuta una prueba de lectura controlada mientras observas dmesg en vivo.
5. Aísla con un intercambio que te enseñe algo: mueve el disco a otra bahía o reemplaza la ruta de cableado.
6. Tras la solución, verifica: velocidad de enlace estable, CRC que ya no aumenta y ausencia de reinicios bajo carga.

Si solo tomas una lección operativa: escribe el mapa de puertos y sigue deltas de CRC. No es glamuroso, pero convierte un espeluznante “problema de almacenamiento de Linux” en un simple reemplazo de piezas con recibos.