ZFS SAS vs SATA timeouts: por qué SAS parece ‘más estable’ bajo estrés

febrero 2, 2026 • febrero 3, 2026 • Lectura: 29 min • Views: 9

¿Te fue útil?

Tu pool ZFS está bien. Hasta que no lo está. Inicias un scrub o un resilver, la latencia pasa de “aburrida” a “picante”,
y de repente dmesg empieza a narrar un desastre: timeouts de comandos, reinicios de enlace y discos que desaparecen el
tiempo justo para arruinar tu día y tu confianza.

Mucha gente sale de esos incidentes con una conclusión simple: “SAS es estable; SATA es inestable.”
Eso no está mal, pero tampoco es toda la historia. La diferencia real vive en la semántica de los timeouts,
el comportamiento de recuperación de errores, las capas de transporte y cómo reaccionan los HBAs bajo estrés.
ZFS es el mensajero. No lo culpes.

Qué significa realmente “estable” en el mundo ZFS

Cuando los operadores dicen que SAS “se siente más estable”, normalmente quieren decir esto:

Los discos no desaparecen del sistema operativo durante scrub/resilver.
El manejo de errores es acotado: las fallas aparecen como errores, no como bloqueos de minutos.
Los controladores se recuperan limpiamente sin resetear enlaces enteros o buses completos.
La latencia permanece lo bastante predecible para que ZFS pueda mantener el pool sano sin entrar en pánico.

ZFS es alérgico al silencio. Si un vdev deja de responder el tiempo suficiente, ZFS asume que se fue y lo marcará como fallido.
A veces el disco está “bien” en el sentido de consumo —sin sectores re-asignados, SMART dice OK— pero pasó 45 segundos
haciendo recuperación profunda. A ZFS no le importan los sentimientos del disco; le importa que la E/S se complete a tiempo.

“Estable” por tanto a menudo significa: la pila de almacenamiento falla rápido y falla de forma estrecha.
SAS tiende a construirse para eso. SATA tiende a construirse para coste por capacidad más bajo y una expectativa tipo escritorio:
una pausa larga es aceptable si puede salvar un sector.

Timeouts 101: la falla que ves vs la falla que tienes

Un timeout en los logs rara vez es la causa raíz. Es el punto donde el SO deja de esperar. La causa real suele pertenecer
a una de estas familias:

Problemas de medio: sectores débiles/inestables que disparan reintentos internos largos.
Problemas de transporte: errores de enlace, cables marginales, fallos de backplane, expanders dramáticos.
Problemas de controlador: bugs de firmware del HBA, inanición de colas, resets bajo tormentas de errores.
Presión de carga de trabajo: scrub/resilver + lecturas aleatorias + escrituras sync pequeñas colisionan y la cola
se convierte en un estacionamiento.

En la práctica, SAS “gana” bajo estrés porque su ecosistema asume que ejecutas un backplane de almacenamiento compartido,
con multipath, con expanders, con docenas de discos y con personal operativo que reemplazará un disco en vez de pedirle
que reintente durante dos minutos.

SATA puede ser fiable, pero necesitas ser más estricto: mejor alimentación, mejores cables/backplanes, mejor firmware y
discos configurados para recuperación acotada de errores (si lo soportan). Sin eso, obtienes el modo de fallo clásico de ZFS:
un disco pausa, el HBA resetea, un par de discos reciben daño colateral y ZFS piensa que el mundo se está acabando.

Comportamientos SAS vs SATA que importan bajo ZFS estrés

Error recovery philosophy: bounded vs “let me cook”

Los discos SAS de empresa suelen estar afinados para entornos estilo RAID: si una lectura de sector falla, no pierdas
la eternidad. Devuelve un error con rapidez para que la capa de redundancia (RAID, espejo/RAIDZ de ZFS) pueda reconstruir
y reescribir. No es altruismo; es supervivencia. En un array compartido, un disco detenido puede detener a muchos.

Muchos discos SATA —especialmente modelos de escritorio/NAS ligeros— intentarán con ahínco recuperar un sector internamente.
Eso puede significar decenas de segundos de bucles de reintento. Durante ese tiempo, el disco puede no responder a otros
comandos. Desde la perspectiva del SO, el dispositivo “se colgó”.

La respuesta empresarial aquí es TLER/ERC/CCTL (distintos vendedores, mismo concepto): limitar cuánto tiempo
el disco pasa en recuperación antes de devolver fallo. Los discos SAS suelen comportarse como si esto viniera habilitado por defecto.
Los discos SATA pueden no soportarlo, tenerlo por defecto desactivado o comportarse de forma inconsistente según la versión de firmware.

Transporte y manejo de comandos: SAS es nativo SCSI; SATA es una fiesta de traducción

SAS es un transporte SCSI. SATA es ATA. Cuando conectas discos SATA detrás de un HBA/backplane SAS, normalmente lo haces vía
SATA Tunneling Protocol (STP). Eso funciona, pero no es lo mismo que SAS de extremo a extremo:
alguna información de error es menos expresiva, algunas rutas de recuperación son más torpes y bajo condiciones de error intensas
puedes ver comportamientos como reinicios de enlace que parecen desproporcionados para un único sector malo.

SAS también te da comodidades como dual-porting (en muchos discos) y mejor integración con multipath.
Eso importa cuando el objetivo es “seguir sirviendo” en lugar de “terminar la lectura eventualmente”.

Colas y equidad: quién puede hablar y por cuánto tiempo

Bajo carga, la pila de almacenamiento es un sistema de colas. Las infraestructuras SAS (HBAs, expanders, firmware) suelen
diseñarse para colas más profundas y mejor equidad entre muchos dispositivos. SATA puede hacer NCQ, pero el ecosistema
extremo a extremo es más variable —especialmente cuando introduces multiplicadores de puerto, backplanes baratos o controladores de consumo.

Tu scrub/resilver es una prueba de tortura perfecta de profundidad de cola: lecturas sostenidas más bien secuenciales más búsquedas de metadata
más escrituras ocasionales. Si un dispositivo comienza a retrasar completaciones, las colas se llenan, aparecen timeouts y ocurren resets.

Radio de reinicio: SAS tiende a ser quirúrgico; SATA puede “resetear el universo”

Cuando un dispositivo SAS se comporta mal, el manejo de errores a menudo se mantiene limitado a ese dispositivo o a ese phy.
Con SATA detrás de STP, la recuperación puede requerir resetear un enlace que también aloje otros discos en el mismo camino de backplane,
o al menos interrumpir momentáneamente el tráfico de forma que cause timeouts colaterales.

Por eso la misma carga puede producir comportamiento de “un disco malo” en SAS y “tres discos desaparecieron por 10 segundos”
en SATA dentro del mismo chasis. No es magia. Es el tamaño del dominio de reinicio.

SMART y telemetría: SAS suele contarte más, y antes

Los dispositivos SAS exponen páginas de log SCSI más ricas y a menudo reportes más consistentes de defectos crecidos y contadores de error.
SMART en SATA es famoso por atributos específicos del fabricante y por “todo está OK hasta que no lo está”. Aún puedes operar bien con SATA,
pero debes compensar con mejor trending y criterios de reemplazo más estrictos.

Primer chiste (y solo porque te mereces un descanso): la recuperación de errores de SATA es como un microondas que no para porque está “casi listo”.
Al final terminas comiéndote pizza fría a las 2 a.m.

Cómo los scrub/resilver de ZFS amplifican enlaces débiles

ZFS es un sistema de fiabilidad que realiza muchas I/O a propósito. Los scrub leen todo para validar checksums.
Los resilver leen mucho para reconstruir redundancia. Ambos son tareas en segundo plano que se parecen sospechosamente a un benchmark
cuando tu pool es lo bastante grande.

Eso crea dos efectos:

Finalmente tocas los datos fríos. El sector que estaba decayendo silenciosamente durante un año se lee.
Si el disco decide hacer recuperación extendida, obtienes bloqueos largos de comandos justo cuando el pool está ocupado.
Concentras estrés. Un resilver puede golpear con fuerza a un subconjunto de discos (los del vdev afectado)
y convertir una marginalidad de enlace/cable en errores repetidos.

ZFS también tiene opiniones sobre dispositivos lentos. Si un dispositivo falta o no responde el tiempo suficiente, ZFS lo marcará
como fallido para mantener la coherencia del pool. Esa es la conducta correcta. La pila de almacenamiento no debe bloquearse indefinidamente.

La trampa del operador es interpretar “ZFS marcó el disco como fallado” como “el disco está muerto”. A veces está muerto. A veces
el disco está bien pero tu transporte es malo. A veces el disco está “bien” en aislamiento pero no es apto para un array redundante
porque se detiene demasiado tiempo.

Hechos y contexto histórico (lo que seguimos reaprendiendo)

Hecho 1: SAS fue diseñado como sucesor serial del SCSI paralelo pensando en backplanes multi-dispositivo y expanders; “muchos discos, un HBA” siempre fue el plan.
Hecho 2: El diseño temprano de SATA apuntaba a almacenamiento de escritorio/commodity; reintentos internos largos eran aceptables si recuperaban un fichero sin intervención del usuario.
Hecho 3: El concepto TLER/ERC/CCTL surgió porque los arreglos RAID hardware necesitaban que los discos fallaran rápido para que el controlador pudiera reconstruir desde paridad/espejos.
Hecho 4: SATA detrás de backplanes SAS comúnmente usa STP, un puente de protocolo que puede reducir la fidelidad del manejo de errores comparado con SAS nativo.
Hecho 5: SAS soporta dual-porting en muchos discos empresariales, habilitando redundancia multipath; SATA generalmente no lo hace (con pocas excepciones).
Hecho 6: El scrub de ZFS fue creado para detectar y corregir corrupción silenciosa de forma continua; intencionalmente genera una carga de lectura que otros sistemas de archivos no generan por defecto.
Hecho 7: Incidentes de “disco desapareció bajo carga” a menudo se rastrean hasta dominios de reset: un reset de controlador puede aletear múltiples dispositivos SATA en una ruta compartida.
Hecho 8: La industria pasó años aprendiendo que “SMART dice OK” no es una garantía; timeouts y abortos de comandos pueden preceder a cualquier cambio en los umbrales SMART.
Hecho 9: Los ecosistemas SAS empresariales típicamente validan combinaciones de firmware (HBA + expander + disco) más rigurosamente porque el mercado exige comportamiento de fallo predecible.

Tres microhistorias corporativas desde el campo

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

Una compañía mediana movió un almacén de artefactos de build a una nueva caja ZFS. El diseño parecía razonable: RAIDZ2, muchos
discos SATA baratos de alta capacidad, un HBA SAS popular en modo IT, y un chasis de 24 bahías ordenado. Alguien preguntó, “¿Deberíamos
comprar discos SAS?” Otro contestó, “Nah, ZFS tiene checksums. Estará bien.”

El primer mes fue aburrido. Luego un scrub coincidió con un día de CI ocupado. La latencia subió. Un disco empezó a hacer timeouts.
El HBA intentó recuperarlo con resets de enlace. Dos discos SATA en bahías adyacentes fallaron lo suficiente como para lanzar timeouts también.
ZFS marcó un disco como fault, luego temporalmente declaró otro como no disponible, y el pool quedó degradado con un toque de pánico.

La suposición equivocada no fue “SATA es poco fiable.” La suposición equivocada fue “las funciones de integridad de datos eliminan
problemas de transporte y timeout.” Los checksums detectan corrupción. No obligan a un disco a responder con prontitud.

La solución no fue exótica. Reemplazaron los peores con discos de clase empresarial que tenían comportamiento de recuperación acotada,
cambiaron un cable sospechoso del backplane y ajustaron la programación de scrubs para fuera de horas punta. Lo más importante:
escribieron una regla operativa: cualquier disco que haga timeout bajo scrub se trata como sospechoso hasta probar lo contrario.

Microhistoria 2: La optimización que salió mal

Otro equipo quería resilvers más rápidos. La idea: subir profundidades de cola, aumentar paralelismo y dejar que el HBA “estire las piernas.”
Aumentaron tunables, habilitaron comportamiento agresivo de scrub y declararon victoria tras una prueba rápida en un pool vacío.

Seis semanas después un disco falló de verdad. El resilver arrancó en un pool que también servía backups de base de datos.
Los nuevos ajustes llevaron los discos a colas de operaciones muy largas. La latencia tocó techo. Un disco SATA marginal que había estado “bien”
empezó a acumular timeouts de comandos. El HBA respondió con resets, y el resilver se ralentizó de todos modos—excepto que ahora el pool
estaba degradado e inestable.

El postmortem fue contundente: optimizar la velocidad máxima de rebuild sin proteger reserva de latencia es apostar con tu ventana de redundancia.
Los rebuilds no son benchmarks; son procedimientos de emergencia.

Revirtieron los tunables, limitaron el impacto de scrub/resilver y midieron el éxito por “¿se mantiene el pool en línea y la latencia acotada?”,
no por MB/s bruto. El resilver tardó más. El negocio tuvo menos outages. El trade-off salió rentable.

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

Una firma de servicios financieros corría ZFS sobre discos SAS con una cultura de mantenimiento estricta. Nada heroico: firmware de HBA conocido
y bueno, modelos de disco consistentes, scrubs programados y el hábito simple de revisar contadores de error semanalmente. También hicieron algo poco
de moda: etiquetaron cada cable y registraron qué bahía mapeaba a qué /dev.

Un trimestre, un scrub reportó un puñado de errores de checksum y un único dispositivo con errores de transporte en aumento.
Sin outage. Sin tickets. Solo evidencia tranquila.

El on-call reemplazó un cable durante una ventana de mantenimiento y proactivamente cambió el disco que mostraba cuentas elevadas de defectos crecidos.
El siguiente scrub estuvo limpio.

Dos meses después, un rack cercano tuvo un evento de energía que causó una breve tormenta de resets de enlace. Su sistema se mantuvo arriba.
¿Por qué? Porque la higiene “aburrida” hizo que no hubiera enlaces marginales esperando convertir un transitorio en una cascada.
La estabilidad operativa es mayormente ausencia de sorpresas, y las sorpresas adoran el cableado descuidado.

Guion rápido de diagnóstico

Cuando ZFS está lanzando timeouts, no tienes tiempo para danza interpretativa. Necesitas encontrar el cuello de botella y el dominio de reset rápido.

Primero: Confirma qué piensa ZFS que está pasando

¿El pool está degradado? ¿Qué vdev?
¿Los errores son checksum (corrupción de datos) o errores de I/O/timeouts (dispositivo/transporte)?
¿El problema está localizado en un disco o en múltiples discos detrás del mismo HBA/backplane?

Segundo: Correlaciona con logs del kernel e identifica la capa de transporte

Busca timeouts SCSI, abortos, task management resets, reinicios de enlace.
Identifica el driver: mpt2sas/mpt3sas, megaraid_sas, ahci, ata_piix, etc.
Comprueba si los dispositivos afectados son SAS o SATA detrás de STP.

Tercero: Mide latencia y presión de colas durante el evento

Usa zpool iostat -v para encontrar el vdev lento.
Usa métricas de latencia por disco (iostat -x) para hallar qué disco se está quedando parado.
Revisa si el HBA está reseteando repetidamente (eso es señal de problemas de transporte/firmware o de un disco que envenena el bus).

Cuarto: Decide si poner en cuarentena el disco o arreglar la ruta

Si un disco muestra timeouts repetidos y muchos errores de medio: reemplázalo.
Si varios discos en la misma ruta de backplane hacen flap juntos: inspecciona/reemplaza cables, expander/backplane, firmware del HBA.
Si los problemas aparecen solo bajo scrub/resilver: capea la agresividad de rebuild y programa esas tareas fuera de horas punta; aun así investiga el componente débil subyacente.

Segundo chiste (último): Un disco que “solo falla durante scrubs” es como un paracaídas que “solo falla durante saltos”. El folleto no es el problema.

Tareas prácticas (comandos, salidas y decisiones)

Los comandos abajo asumen un host Linux. Si ejecutas illumos o FreeBSD, los conceptos se traducen; cambian los nombres de archivos y las herramientas.
Las salidas mostradas son representativas—tu máquina tendrá su propio drama.

Task 1: Check pool health and error type

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 in progress since Thu Dec 26 01:11:19 2025
        3.21T scanned at 812M/s, 1.94T issued at 492M/s, 12.8T total
        0B repaired, 15.15% done, 0:07:21 to go
config:

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

errors: Permanent errors have been detected in the following files:
        tank/backups/db/full-2025-12-25.sql.zst

Qué significa: Los errores de checksum significan que ZFS detectó datos que no coincidían con su checksum. Eso puede ser
un sector malo, un cable malo, RAM defectuosa o un problema de controlador—pero no es meramente un síntoma de timeout.
Decisión: Si hay errores de checksum, trátalo como un incidente de integridad de datos. Identifica los archivos afectados,
valida backups y luego busca la causa hardware.

Task 2: Watch per-vdev latency during scrub/resilver

cr0x@server:~$ sudo zpool iostat -v tank 2
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        8.44T  4.18T  2.40K    112   520M  5.12M
  raidz2-0                  8.44T  4.18T  2.40K    112   520M  5.12M
    ata-WDC_WD140EDFZ-...       -      -    410     19  86.9M   862K
    ata-WDC_WD140EDFZ-...       -      -     12     18   512K   840K
    ata-WDC_WD140EDFZ-...       -      -    398     18  84.2M   835K
    ata-WDC_WD140EDFZ-...       -      -    401     19  85.1M   860K
    ata-WDC_WD140EDFZ-...       -      -    395     19  83.7M   858K
    ata-WDC_WD140EDFZ-...       -      -    404     19  85.4M   865K
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: Un disco está realizando casi ninguna lectura mientras los demás trabajan. Eso es señal clásica de
un dispositivo atascado o un problema de path. Decisión: Identifica el nombre de dispositivo OS de ese disco e
inspecciona logs y SMART. Si se repite, planifica reemplazo o remediación de la ruta.

Task 3: Confirm which /dev node maps to the ZFS disk ID

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WD140EDFZ | head
lrwxrwxrwx 1 root root  9 Dec 26 01:12 ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC1 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 01:12 ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC2 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 01:12 ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC3 -> ../../sdd

Qué significa: ZFS muestra nombres by-id; necesitas el dispositivo del kernel para SMART, logs de error y mapeo del controlador.
Decisión: Usa by-id de forma consistente en ZFS, pero mapea a /dev/sdX para el triage.

Task 4: Pull kernel errors around the timeouts

cr0x@server:~$ sudo journalctl -k -S "2025-12-26 01:00" -g "timeout|reset|I/O error|mpt3sas|ata"
Dec 26 01:13:44 server kernel: sd 0:0:8:0: [sdb] tag#91 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
Dec 26 01:13:44 server kernel: sd 0:0:8:0: [sdb] tag#91 CDB: Read(16) 88 00 00 00 00 1b 2f 9e 80 00 00 00 01 00 00 00
Dec 26 01:13:44 server kernel: ata9: hard resetting link
Dec 26 01:13:45 server kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 26 01:13:46 server kernel: sd 0:0:8:0: [sdb] tag#93 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Dec 26 01:13:49 server kernel: mpt3sas_cm0: log_info(0x31120600): originator(PL), code(0x12), sub_code(0x0600)

Qué significa: Tienes timeouts de comandos SCSI y un reset de enlace SATA en la misma ruta. Eso sugiere
o bien un disco SATA mal comportado bajo STP o un problema de transporte (cable/backplane) causando inestabilidad de enlace.
Decisión: Si los resets se agrupan alrededor de un disco, reemplázalo. Si los resets afectan múltiples discos en el mismo
“ataX” o puerto del HBA, inspecciona cableado/backplane y firmware del HBA.

Task 5: Identify whether a disk is SAS or SATA, and through which host

cr0x@server:~$ sudo lsblk -d -o NAME,MODEL,TRAN,SERIAL,HCTL /dev/sdb
NAME MODEL          TRAN SERIAL     HCTL
sdb  WDC WD140EDFZ  sata VGH1ABC1   0:0:8:0

Qué significa: TRAN=sata te indica que es un disco SATA aunque esté en un chasis SAS.
HCTL muestra la dirección SCSI. Decisión: Espera más rarezas relacionadas con STP; sé más conservador con sensibilidad a timeouts
y calidad de cableado.

Task 6: Inspect SMART for evidence of slow recovery or link trouble (SATA)

cr0x@server:~$ sudo smartctl -a /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Red
Device Model:     WDC WD140EDFZ-11A0VA0
Serial Number:    VGH1ABC1
SATA Version is:  SATA 3.3, 6.0 Gb/s
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   0      Old_age   Always       -       3
198 Offline_Uncorrectable   0x0010   200   200   0      Old_age   Offline      -       3
199 UDMA_CRC_Error_Count    0x003e   199   199   0      Old_age   Always       -       24

Qué significa: Sectores pendientes/offline uncorrectable sugieren problemas de medio; UDMA CRC errors sugieren
problemas de enlace/cable/backplane. Decisión: Sectores pendientes durante scrubs son una señal roja—planifica reemplazo.
Errores CRC: reubica/reemplaza cable/ruta del backplane y observa si el contador sigue subiendo.

Task 7: Inspect SMART for SAS with richer error logs

cr0x@server:~$ sudo smartctl -a /dev/sde
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Vendor:               SEAGATE
Product:              ST12000NM000J
Revision:             SN03
Logical Unit id:      0x5000c500d3a1b2c3
Transport protocol:   SAS (SPL-3)
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature:     34 C
Elements in grown defect list: 8
Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
read:          1200           2         1202      1200        98123.456         0
write:            0           0            0         0        77234.112         0

Qué significa: Existen defectos crecidos pero las lecturas se corrigen sin errores no corregidos.
SAS te da una imagen más clara de la actividad de corrección. Decisión: Trend el “grown defect list” y tasas de errores corregidos.
Si aceleran o ves errores no corregidos/timeouts, reemplaza de forma proactiva.

Task 8: Check HBA driver/firmware and spot known reset storms

cr0x@server:~$ sudo lspci -nn | grep -i -E "sas|lsi|broadcom"
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087] (rev 02)

cr0x@server:~$ sudo modinfo mpt3sas | egrep "version|firmware"
version:        46.100.00.00
firmware:       0x2221 (IR)

Qué significa: Necesitas saber qué estás corriendo. Un HBA en modo IR, por ejemplo, puede no ser lo que pretendías para passthrough a ZFS.
Decisión: Asegura que el HBA esté en modo IT para ZFS y mantiene combinaciones firmware/driver consistentes en la flota.
Si ves resets, verifica que no estés en una combinación problemática.

Task 9: Check link error counters (SAS phy stats)

cr0x@server:~$ for phy in /sys/class/sas_phy/phy-*; do echo "== $phy =="; sudo cat $phy/invalid_dword_count $phy/running_disparity_error_count $phy/loss_of_dword_sync_count $phy/phy_reset_problem_count 2>/dev/null; done | head -n 20
== /sys/class/sas_phy/phy-0:0 ==
0
0
0
0
== /sys/class/sas_phy/phy-0:1 ==
12
5
3
1

Qué significa: Contadores no cero de disparity/sync/reset son problemas de capa física: cable, backplane, puerto de expander o conector marginal.
Decisión: Si los contadores aumentan con el tiempo, reemplaza los componentes de la ruta antes de culpar a ZFS o al disco.

Task 10: Identify which disks share an expander/backplane path

cr0x@server:~$ sudo lsscsi -t
[0:0:0:0]    disk    sas:0x5000c500d3a1b2c3  /dev/sde
[0:0:1:0]    disk    sas:0x5000c500d3a1b2c4  /dev/sdf
[0:0:8:0]    disk    sata:0x50014ee2b7c81234 /dev/sdb
[0:0:9:0]    disk    sata:0x50014ee2b7c85678 /dev/sdc

Qué significa: Puedes ver dispositivos SAS vs SATA y a menudo inferir cuáles están detrás de un expander.
Decisión: Si múltiples dispositivos en el mismo host/canal muestran errores juntos, sospecha de ruta compartida.

Task 11: Observe per-disk latency and queue depth during pain

cr0x@server:~$ iostat -x -d 2 3 /dev/sdb /dev/sdc
Linux 6.6.0 (server)  12/26/2025  _x86_64_ (32 CPU)

Device            r/s   w/s  rkB/s  wkB/s  await  aqu-sz  %util
sdb              8.0   1.0   512    64    980.0   31.5   99.9
sdc            210.0  12.0  86000  1200    12.4    2.1   88.0

Qué significa: sdb tiene ~1 segundo de espera media y una cola enorme. No está al día, se está atascando.
Decisión: Si esto se correlaciona con timeouts del kernel, tienes un problema de dispositivo/ruta en sdb. Reemplaza disco o arregla el transporte; no solo “tunees ZFS” y esperes.

Task 12: Check for ZFS slow I/O messages

cr0x@server:~$ sudo dmesg -T | grep -i "slow io" | tail
[Thu Dec 26 01:13:55 2025] ZFS: vdev IO failure, zio 0x0000000123456789, type 1, offset 231145472, size 131072
[Thu Dec 26 01:13:55 2025] ZFS: vdev slow I/O, zio 0x0000000123456790, 60 seconds

Qué significa: ZFS te está diciendo que una I/O está tomando decenas de segundos. Eso suele alinearse con recuperación del disco
o resets de transporte. Decisión: Trata los “slow I/O” repetidos como un indicador de pre-fallo; no son ruido normal de fondo.

Task 13: Throttle scrub impact (Linux OpenZFS)

cr0x@server:~$ sudo zfs get -H -o property,value autotrim tank
autotrim	off

cr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_vdev_scrub_max_active
10

cr0x@server:~$ echo 4 | sudo tee /sys/module/zfs/parameters/zfs_vdev_scrub_max_active
4

Qué significa: Redujiste el número de I/O concurrentes de scrub por vdev, disminuyendo la presión.
Decisión: Usa esto como palanca temporal de estabilidad durante la respuesta a incidentes. Si throttling hace desaparecer los timeouts,
aún tienes un componente débil—solo que falla solo bajo estrés.

Task 14: Temporarily pause and resume a scrub to stop the bleeding

cr0x@server:~$ sudo zpool scrub -p tank

cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
  pool: tank
 state: DEGRADED
  scan: scrub paused since Thu Dec 26 01:20:11 2025
        3.80T scanned at 0B/s, 2.41T issued at 0B/s, 12.8T total

Qué significa: Pausar reduce la carga para que puedas estabilizar e investigar sin seguir pinchando el componente fallido.
Decisión: Pausa durante tormentas activas de timeouts; reanuda después de arreglar el disco/ruta sospechada o tras aplicar throttles.

Task 15: Offline a flapping disk to protect the pool (carefully)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC1

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,25p'
  pool: tank
 state: DEGRADED
status: One or more devices is being resilvered or is offline.
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-WDC_WD140EDFZ-...   OFFLINE      0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     3
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0

Qué significa: Has retirado un dispositivo que hacía flap del camino de I/O. Esto puede detener resets de bus y proteger a los discos restantes.
Decisión: Haz esto solo si la redundancia lo permite (seguridad RAIDZ2/espejo). Si estás a un disco de pérdida de datos, arregla la ruta primero
y evita offlining a menos que el disco esté envenenando todo el vdev.

Task 16: Replace the disk and monitor resilver progress

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC1 /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_VGH9NEW1

cr0x@server:~$ sudo zpool status tank | sed -n '1,22p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 02:01:09 2025
        1.22T scanned at 421M/s, 512G issued at 176M/s, 12.8T total
        0B repaired, 3.90% done, 5:48:12 to go

Qué significa: El resilver está en marcha. Observa nuevos timeouts durante el resilver; es cuando los componentes marginales confiesan.
Decisión: Si el resilver provoca nuevos timeouts en otros discos, probablemente tienes un problema de ruta compartida o otro disco débil.

Task 17: Check SATA error handling parameters (Linux SCSI layer)

cr0x@server:~$ cat /sys/block/sdb/device/timeout
30

cr0x@server:~$ echo 60 | sudo tee /sys/block/sdb/device/timeout
60

Qué significa: El SO esperará más antes de declarar un comando como timeout. Esto puede reducir falsos positivos con discos lentos,
pero también puede ocultar cuelgues reales y extender bloqueos.
Decisión: Usa aumentos de timeout solo como medida temporal y solo si entiendes el tradeoff. Si un disco necesita 90 segundos para leer un sector,
no tienes un problema de timeout—tienes un problema de disco.

Task 18: Verify ZFS isn’t being sabotaged by write cache surprises

cr0x@server:~$ sudo hdparm -W /dev/sdb | head -n 2
/dev/sdb:
 write-caching =  1 (on)

Qué significa: La caché de escritura está activada. Eso es normal, pero en algunos discos de consumo y en algunos
chasis, caché + comportamiento ante pérdida de energía puede ser riesgoso. Decisión: Si no tienes protección contra pérdida de energía
y te importan las semánticas sync, considera un SLOG para cargas sync intensas y usa discos empresariales para comportamiento predecible en lugar de
alternar la caché a la ligera.

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

1) Síntoma: “ZFS sigue marcando distintos discos como fallidos durante scrub”

Causa raíz: Resets de ruta compartida (backplane, expander, cable o HBA) causando que múltiples dispositivos hagan timeout, no múltiples discos malos.
Solución: Correlaciona qué discos hacen flap juntos usando logs del kernel y HCTL. Reemplaza cable/backplane/expander; actualiza firmware del HBA; reduce la complejidad del dominio de reset.

2) Síntoma: “SMART parece bien pero veo timeouts de comandos”

Causa raíz: Los discos pueden quedarse atascados en recuperación de errores sin activar umbrales SMART; los errores de transporte tampoco siempre aparecen como fallos clásicos de SMART.
Solución: Trata los timeouts como una señal de fallo de primera clase. Trendea contadores CRC/enlace y resets del kernel; reemplaza disco o ruta antes de que sea un incidente de pérdida de datos.

3) Síntoma: “El resilver es dolorosamente lento y el pool se siente inestable”

Causa raíz: Paralelismo agresivo de rebuild saturando colas; un disco débil se queda atascando bajo carga; o un disco SATA hace reintentos internos largos.
Solución: Throttlea parámetros de scrub/resilver temporalmente, protege la latencia para producción y reemplaza cualquier disco con awaits/timeouts largos.

4) Síntoma: “Aparecen errores de checksum que desaparecen tras un reboot”

Causa raíz: Enlace intermitente o corrupción de memoria; el reboot lo enmascara temporalmente al resetear la ruta.
Solución: No te alegres. Ejecuta tests de memoria, revisa logs ECC e inspecciona contadores SAS phy o CRC SATA. Reemplaza componentes marginales.

5) Síntoma: “Solo los discos SATA se caen; los SAS no”

Causa raíz: Traducción STP más comportamiento de recuperación de errores de discos de consumo más un radio de reinicio mayor.
Solución: Usa discos empresariales/NAS con recuperación acotada si están disponibles; prefiere SAS para chasis densos multi-bahía; asegura que el backplane y el HBA estén validados para cargas SATA.

6) Síntoma: “Tras reemplazar un disco, otro empieza a hacer timeout durante el resilver”

Causa raíz: El resilver creó suficiente estrés para revelar el siguiente disco más débil o una ruta de transporte marginal.
Solución: Ejecuta un scrub completo después del resilver, vigila iostat/latencia y reemplaza proactivamente cualquier disco con sectores pendientes crecientes o slow I/O repetidos.

Listas de verificación / plan paso a paso

Paso a paso: cuando ves timeouts durante scrub/resilver

Congela el radio de blast: pausa el scrub si el sistema está inestable y la producción se ve afectada.
Captura evidencia: guarda zpool status -v, zpool iostat -v y logs del kernel que cubran la ventana del evento.
Identifica el/los dispositivo(s) sospechosos: mapea by-id → /dev/sdX y anota direcciones HCTL.
Diferencia medio vs transporte: SMART pending/offline uncorrectable sugiere medio; contadores CRC/enlace sugieren transporte.
Revisa correlación de ruta compartida: ¿comparten varios discos el mismo host/puerto/segmento de backplane?
Aplica throttles temporales: reduce concurrencia de scrub/resilver para estabilizar mientras trabajas.
Arregla la causa más probable: reemplaza cable/backplane primero si los contadores de enlace suben; reemplaza disco si se queda solo o muestra errores de medio.
Reanuda scrub/resilver y observa: si los errores reaparecen, fallaste al encontrar el enlace débil real.
Higiene post-incidente: programa un scrub completo tras el resilver y revisa tendencias de contadores de error semanalmente durante un mes.

Checklist de decisión: cuándo elegir SAS sobre SATA para ZFS

Elige SAS si tienes un chasis denso, expanders, muchos discos por HBA o necesidades estrictas de uptime.
Elige SAS si esperas resilvers frecuentes (pools grandes, alta rotación) y quieres recuperación de errores acotada por defecto.
Elige SATA si el coste/TB domina, tu chasis es simple y estás dispuesto a ser implacable con modelos de disco, cableado y reemplazo proactivo.
Evita mezclar SKUs SATA “lo que esté barato este trimestre” en el mismo pool. La consistencia vence a la sorpresa.

Checklist de configuración: hacer que SATA se comporte menos como un hobby

Usa un HBA real en modo IT; evita personalidades RAID.
Prefiere backplanes de calidad y cables cortos y etiquetados; reemplaza cualquier cosa que incremente contadores CRC.
Programa scrubs fuera de horas punta y thrótéalos si la latencia importa.
Trendea timeouts y resets, no solo SMART “PASSED”.
Mantén repuestos a mano; reemplaza al primer signo de slow I/O bajo scrub, no tras el tercer incidente.

Preguntas frecuentes

1) ¿SAS es inherentemente más fiable que SATA?

No inherentemente. Los ecosistemas SAS suelen estar diseñados para comportamiento de fallo predecible bajo estrés multi-disco.
Esa predictibilidad es lo que los operadores interpretan como fiabilidad.

2) ¿Por qué los discos SATA “se caen” durante un scrub de ZFS?

A menudo porque el disco se queda atascado en recuperación interna de errores, el SO hace timeout del comando y el controlador resetea el enlace.
Con STP detrás de un HBA SAS, ese reset puede ser ruidoso.

3) Si ZFS tiene checksums, ¿por qué importan los timeouts?

Los checksums detectan corrupción. No hacen que la I/O se complete a tiempo. ZFS sigue necesitando que el dispositivo responda dentro de la ventana de timeout del SO
para mantener el pool en línea y coherente.

4) ¿Debería aumentar los timeouts de disco en Linux para evitar flapping?

A veces como mitigación temporal. Pero timeouts más largos aumentan la duración de los bloqueos y pueden ocultar medios que fallan.
Si un disco necesita timeouts dramáticamente más largos, la respuesta más segura es reemplazo o moverse a discos con recuperación acotada.

5) ¿Los expanders SAS causan timeouts?

Pueden si el firmware tiene bugs, la topología está sobrecargada o el cableado es marginal. Pero un buen expander en una topología sensata no es problema.
Un cable malo fingiendo ser un problema de expander es extremadamente común.

6) ¿Los errores de checksum son siempre un problema de disco?

No. Pueden venir del disco, cable, HBA, backplane o corrupción de memoria. Por eso correlacionar logs del kernel, contadores de enlace y SMART es obligatorio.

7) ¿Por qué el “fail fast” de SAS se siente mejor para ZFS?

Porque la redundancia de ZFS funciona mejor cuando un dispositivo reporta un error con rapidez para que ZFS pueda reconstruir y sanar.
Las pausas largas silenciosas causan timeouts, resets y daño colateral multi-dispositivo.

8) ¿Mezclar SAS y SATA en el mismo pool es mala idea?

No está prohibido, pero es operacionalmente incómodo. Diferente comportamiento de timeout y telemetría hace los incidentes más difíciles de interpretar.
Si debes mezclar, aisla por clase de vdev o propósito de pool y documenta expectativas.

9) ¿Cuál es el indicador más importante de que tengo un problema de cableado/backplane?

Errores que afectan múltiples discos que comparten una ruta física, más contadores CRC/enlace en ascenso. Los fallos de medio suelen ser localizados; los fallos de transporte gustan de la compañía.

10) ¿Qué debería optimizar: velocidad de scrub o estabilidad?

Estabilidad. Un scrub es un procedimiento de seguridad. Si necesitas que termine más rápido, escala capacidad o programa mejor.
No conviertas tu comprobación de redundancia en un evento de denegación de servicio.

Conclusión: siguientes pasos para evitar el aviso a las 3 a.m.

SAS se siente más estable bajo estrés en ZFS porque toda la pila—discos, protocolo y controladores—tiende a devolver errores con rapidez,
aislar resets y proporcionar telemetría más clara. SATA puede funcionar, a veces de forma brillante, pero es mucho menos tolerante
cuando algo es marginal y mucho más probable que convierta un disco débil en un incidente a nivel de bus.

Pasos prácticos siguientes:

Clasifica tus errores (checksum vs timeout vs transporte) y deja de tratarlos como intercambiables.
Correlaciona fallos con rutas compartidas usando HCTL y contadores de enlace; reemplaza cables/backplanes de forma agresiva.
Reemplaza discos que se quedan atascados bajo scrub incluso si SMART dice “PASSED.” Tu pool necesita I/O a tiempo, no optimismo.
Throttlea scrub/resilver para proteger latencia en producción, y luego arregla la debilidad subyacente en vez de vivir con throttles.
Si la disponibilidad importa, compra SAS para sistemas densos multi-bahía. Pagas por comportamiento de fallo acotado y menor radio de reset.

Una idea para tener en un post-it, atribuida con cuidado: la fiabilidad viene de construir sistemas que esperan fallos y se recuperan de forma predecible — John Allspaw.