Passthrough de controladores RAID para ZFS: modo IT vs HBA vs “HBA falso”

El principio: ZFS quiere discos, no opiniones

ZFS es un sistema de archivos y un gestor de volúmenes. Eso no es un eslogan; es un contrato de diseño. ZFS espera ver los discos reales (o al menos algo que se comporte como discos) porque quiere:

• controlar la redundancia (mirrors, RAIDZ) y entenderla de extremo a extremo,
• rastrear checksums y reparar usando copias redundantes,
• gestionar el orden de escrituras y la semántica de flush,
• observar errores de I/O y actuar sobre ellos (marcar un dispositivo, resilver, scrub),
• ver la identidad y la topología (seriales, rutas) para poder sobrevivir a rarezas de cables/controladoras.

Los controladores RAID de hardware fueron construidos para un contrato diferente: abstraer discos en “unidades virtuales”, ocultar bloques malos, reintentar internamente, reordenar escrituras y, en general, dar la ilusión de que todo está bien. El propósito de ZFS es que el mundo no está bien, y fingir lo contrario conduce al tipo de pérdida de datos que parece “corrupción aleatoria” hasta que te das cuenta de que era determinista todo el tiempo.

El objetivo, si ejecutas ZFS, es simple: presentar cada disco físico al SO con la mínima traducción. Ahí es donde brillan el modo IT y los HBAs adecuados. Y ahí es donde los controladores RAID con “passthrough” a veces te mienten.

Términos que los proveedores abusan: modo IT, HBA, JBOD, passthrough

Modo IT (Initiator-Target)

En el mundo LSI/Broadcom (y la mayoría del ecosistema re-etiquetado: Dell PERC, IBM ServeRAID, Fujitsu, etc.), “modo IT” es un firmware que convierte un controlador capaz de RAID en un iniciador SAS más simple. Deja de hacer la virtualización RAID y expone cada unidad como su propio target.

“Modo IT” no es un término universal entre todos los proveedores, pero en la práctica es una abreviatura de “firmware HBA en un controlador SAS LSI.”

HBA (Host Bus Adapter)

Un HBA verdadero es un controlador diseñado para conectar discos y exponerlos tal cual. Sin pila RAID, sin capa de unidades virtuales, sin caché write-back fingiendo ser tu sistema de archivos. Puede soportar expanders SAS, multipath y mayores profundidades de cola. Es el equivalente en almacenamiento de una buena llave: no emocionante, siempre ahí.

Modo JBOD

JBOD es donde las cosas se vuelven resbaladizas. Algunos controladores tienen una opción “JBOD” que crea una “unidad virtual” por cada disco físico. A veces eso es suficiente. Otras veces es un wrapper RAID0 alrededor de cada disco con estado adicional, caching, remapeo y manejo de errores. ZFS puede funcionar encima de eso, pero ahora has insertado una capa de traducción que puede enmascarar errores y romper suposiciones.

Passthrough

“Passthrough” puede significar:

• el SO recibe dispositivos SCSI/SAS directamente, incluidos seriales y SMART,
• o el SO recibe un dispositivo virtual que reenvía la mayoría de comandos pero no todos,
• o el SO recibe un “objeto parecido a un disco” que comparte solo lo suficiente de la realidad para arrancar.

Cuando alguien dice “passthrough”, tu siguiente pregunta es: ¿passthrough de qué, exactamente? ¿Errores? ¿Flushes? ¿SMART? ¿Profundidad de cola? ¿TRIM? ¿Comportamiento ante pérdida de energía? Porque ahí es donde se entierran los cuerpos.

Modo IT: qué es, qué te da y qué aún puede fallar

El modo IT es el punto óptimo para muchas construcciones ZFS porque está ampliamente disponible, es barato en el mercado secundario y estable en drivers de SO comunes (Linux mpt2sas/mpt3sas, FreeBSD mps/mpr). Obtienes discos físicos apareciendo como discos físicos. ZFS puede hacer su trabajo.

Qué ganas con modo IT

• Visibilidad directa de disco: números de serie, WWN y IDs de dispositivo predecibles.
• Reporte honesto de errores: los errores de medios aparecen en el SO; ZFS puede marcar discos.
• Semántica de flush predecible: los flushes de caché del disco no son “reinterpretados” por el firmware RAID.
• Menos rarezas en la ruta de escritura: sin caché write-back tratando de adelantarse a la pérdida de energía.
• Mejor compatibilidad: herramientas como smartctl y sg_ses suelen comportarse.

Qué aún puede fallar

El modo IT no arregla la física mágicamente. Tus cuellos de botella simplemente se vuelven más honestos.

• Cables/backplanes malos: SAS es robusto hasta que no lo es. Un cable mini-SAS marginal puede convertirse en reinicios de enlace y timeouts que parecen “errores de disco aleatorios.”
• Expanders bajo carga: los expanders baratos pueden introducir bloqueo head-of-line, especialmente con muchos HDDs haciendo scrub simultáneamente.
• Desajuste de profundidad de cola: demasiado baja y desperdicias rendimiento; demasiado alta y aumentas la latencia durante la contención.
• Incompatibilidad de firmware: mezclar generaciones de firmware puede estar bien hasta que cierto modelo de disco golpea un caso límite. El almacenamiento es un museo de casos límite.
• Térmicas: los HBAs se calientan. “Funciona en laboratorio” se convierte en “flaps de enlace en producción” cuando el flujo de aire del chasis no es real.

Broma #1: Un HBA sin flujo de aire es como una base de datos sin copias de seguridad—técnicamente funcional hasta que deja de ser tu personalidad.

HBAs reales: aburridos, correctos, lo suficientemente rápidos

Si tienes elección, un HBA real es la opción menos sorprendente para ZFS. Eso es un cumplido. La producción ama “lo menos sorprendente.”

Los HBAs “reales” modernos suelen ser SAS3 (12Gbps) o SAS4 (24Gbps), soportan expanders correctamente y tienen drivers que han sido golpeados por una década de uso real. Con pools de HDD, golpearás las limitaciones del disco mucho antes que las del HBA. Con pools de SSD, la selección del HBA importa más, pero la regla se mantiene: mantén el camino simple.

Las diferencias prácticas que notarás con un HBA verdadero:

• La identidad del disco se mantiene estable tras reinicios y rescans.
• SMART y contadores de error son legibles sin invocaciones específicas extrañas del controlador.
• La gestión de fallos de ZFS se comporta de forma predecible cuando un disco degrada.
• La latencia es “solo discos” más la sobrecarga del bus, no “discos más comité de firmware”.

“HBA falso”: controladoras RAID con maquillaje de passthrough

Definamos “HBA falso” con claridad: un controlador RAID que afirma exponer discos individuales pero que aún mantiene una capa de abstracción de la era RAID delante de ellos. A veces esto se llama JBOD, a veces “modo HBA”, a veces “passthrough”. No siempre es malicioso. Simplemente no siempre es honesto.

Por qué existe

Los proveedores construyeron controladoras RAID para centros de datos de la era Windows/VMware donde la controladora es el cerebro del almacenamiento. Luego ZFS (y el RAID por software en general) se volvió común, y de repente la gente quería “solo un disco”. En lugar de rediseñar el silicio, los proveedores a menudo enviaron una función de firmware que aproxima la exposición de discos.

Qué rompe el “HBA falso”

• Transparencia SMART: podrías ver SMART parcial, o nada, o puede que esté mapeado a través de páginas específicas del controlador.
• Semántica de errores: el controlador puede reintentar y ocultar medios marginales, convirtiendo un disco fallando en picos de latencia largos en lugar de errores claros.
• Barreras/flush: el controlador puede reconocer flushes temprano debido a su política de caché.
• Identidad del dispositivo: los discos aparecen como “Virtual Disk 0” en lugar de seriales/WWNs estables.
• Comportamiento de recuperación: en reinicios o eventos de energía, el controlador puede reordenar lo que el SO ve y cuándo.

Cuando es “suficientemente bueno”

A veces heredas hardware y no puedes cambiarlo este trimestre. Si el controlador proporciona JBOD verdadero que expone cada disco con identificadores estables y SMART completo, y puedes desactivar caché y políticas de read-ahead limpiamente, puedes hacerlo funcionar. La pregunta es: ¿puedes verificar todo eso, repetidamente, y detectar cuando una actualización de firmware cambia el comportamiento?

Cuando es un rotundo no

Si no puedes obtener SMART fiable, si los IDs de disco son inestables, si ZFS ve timeouts extraños durante scrubs, o si el controlador requiere wrappers de unidades virtuales por disco, deja de negociar. Cámbialo por un HBA. El dinero que “ahorras” lo gastarás en respuesta a incidentes. Y lo pagarás en fines de semana.

Broma #2: Un controlador RAID en “modo passthrough” es como una reunión que “podría haber sido un correo”—aún así de alguna manera toma dos horas y rompe tu tarde.

Hechos interesantes y contexto histórico (la versión corta y útil)

1. ZFS nació en una era de discos que mentían. Los primeros discos SATA de consumo y controladoras reordenaban escrituras agresivamente; el énfasis de ZFS en checksums end-to-end fue en parte una respuesta.
2. “Modo IT” vino del mundo SAS, no del mundo ZFS. El firmware Initiator-Target estaba pensado para hosts que solo necesitaban hablar SAS sin lógica RAID en medio.
3. Muchas “tarjetas controlador RAID” famosas son solo rebrands de silicio LSI. Las líneas Dell PERC e IBM ServeRAID a menudo se mapean a las mismas familias de chips, con diferentes restricciones de firmware.
4. La caché write-back fue históricamente un parche de rendimiento para discos lentos. Mejoró benchmarks dramáticamente, pero también convirtió la corrección ante pérdida de energía en problema de otro—a menudo tu problema.
5. La caché con batería evolucionó a caché con flash. Las baterías envejecen y se hinchan; los módulos flash con supercaps se volvieron comunes para preservar el contenido de caché sin cuidar baterías constantemente.
6. SMART no fue diseñado para controladoras RAID. Las controladoras que se interponen entre SO y disco a menudo necesitan mecanismos de passthrough específicos del proveedor; no todas los implementan completamente.
7. Los expanders SAS son básicamente switches Ethernet para discos. Multiplexan carriles; los buenos se comportan, los malos introducen patrones sutiles de congestión durante scrubs/resilvers.
8. La profundidad de cola se volvió la perilla oculta del rendimiento. A medida que los SSD crecieron, la capacidad de sostener muchos comandos pendientes importó más que la velocidad bruta del enlace.
9. Algunos controladores presentan RAID0 por disco como “JBOD.” Se parece a un disco, huele a disco, y aún tiene metadata y políticas que pueden morderte después.

Qué comprar y qué evitar (opinión)

Compra esto

• Un HBA real (SAS3/SAS4) bien soportado por tu SO, especialmente si usas SSDs o muchos discos.
• Un controlador LSI/Broadcom flasheado a modo IT si te sientes cómodo validando firmware y manteniendo repuestos.
• Buenos cables y un backplane sensato. La mayoría de “problemas de controlador” son problemas de cobre con otro disfraz.

Evita esto

• RAID de hardware para ZFS (arrays reales). ZFS sobre un disco virtual RAID5/6 es la forma de obtener errores de checksum que no puedes reparar.
• “JBOD” que en realidad son wrappers RAID0 por disco, especialmente si no puedes leer SMART limpiamente.
• Controladoras que no pueden pasar seriales/WWNs. Si no puedes identificar con confianza un disco fallido, eventualmente tirarás del equivocado.
• Cualquier configuración donde no puedas desactivar la caché write-back o al menos verificar el comportamiento de flush. ZFS necesita barreras veraces, no buenas intenciones.

La cita

“La esperanza no es una estrategia.” — General Gordon R. Sullivan

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos no son comandos “de juguete”. Son los que ejecutas cuando decides si tienes un HBA real, si el passthrough está mintiendo y a dónde se fue tu rendimiento. Los ejemplos asumen Linux, pero la lógica se aplica en otros sitios.

Tarea 1: Identificar el controlador y su driver

cr0x@server:~$ lspci -nn | egrep -i 'sas|scsi|raid'
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097] (rev 02)
04:00.0 RAID bus controller [0104]: Broadcom / LSI MegaRAID SAS-3 3108 [1000:005d] (rev 02)

Qué significa: La primera línea es un controlador Fusion-MPT SAS (a menudo usado como HBA/dispositivo en modo IT). La segunda es MegaRAID (personalidad RAID).

Decisión: Prefiere el dispositivo Fusion-MPT para ZFS. Si debes usar el MegaRAID, planea validar agresivamente el comportamiento “JBOD” o reemplázalo.

Tarea 2: Confirmar qué módulos del kernel están en uso

cr0x@server:~$ lsmod | egrep 'mpt3sas|megaraid|aacraid|hpsa'
mpt3sas               307200  2
megaraid_sas          180224  0

Qué significa: mpt3sas es típico para HBAs/modo IT LSI SAS3; megaraid_sas indica pila RAID.

Decisión: Si tus discos están detrás de megaraid_sas, asume que podrías tener un “HBA falso” hasta comprobar lo contrario.

Tarea 3: Mapear discos a rutas del controlador y comprobar si parecen “virtuales”

cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,HCTL,TYPE,SIZE
NAME   MODEL              SERIAL          HCTL       TYPE  SIZE
sda    ST12000NM0008      ZHZ123AB        3:0:0:0    disk  10.9T
sdb    ST12000NM0008      ZHZ124CD        3:0:1:0    disk  10.9T
sdc    MR9361-8i          00c0ffee        4:2:0:0    disk  7.3T

Qué significa: sda/sdb muestran modelo/serial reales. sdc muestra el modelo del controlador como modelo de “disco”—presentación típica de unidad virtual.

Decisión: No construyas un pool ZFS sobre sdc a menos que entiendas exactamente qué se está virtualizando y por qué.

Tarea 4: Verificar que ZFS vea identificadores estables (WWN) y no solo /dev/sdX

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'wwn|scsi'
lrwxrwxrwx 1 root root  9 Dec 26 09:11 wwn-0x5000c500a1b2c3d4 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 09:11 wwn-0x5000c500a1b2c3d5 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 09:11 scsi-35000c500a1b2c3d4 -> ../../sda

Qué significa: Existen IDs basadas en WWN y son estables entre reinicios (suponiendo que el controlador no reescriba la identidad).

Decisión: Usa rutas /dev/disk/by-id/wwn-* al crear pools. Si no tienes WWNs, trátalo como una bandera roja.

Tarea 5: Comprobar si SMART funciona directamente (mejor señal de passthrough real)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep 'Model Family|Device Model|Serial Number|SMART overall-health'
Model Family:     Seagate IronWolf Pro
Device Model:     ST12000NM0008
Serial Number:    ZHZ123AB
SMART overall-health self-assessment test result: PASSED

Qué significa: El acceso SMART directo en /dev/sda funciona normalmente.

Decisión: Esta ruta de disco es “suficientemente real” para ZFS. Repite para todos los discos; un bay/backplane problemático puede ser la excepción.

Tarea 6: SMART detrás de MegaRAID (si debes), y cómo se ve un fallo

cr0x@server:~$ sudo smartctl -a /dev/sdc
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.0] (local build)
Smartctl open device: /dev/sdc failed: DELL or MegaRaid controller, please try adding '-d megaraid,N'

Qué significa: El SO ve un disco virtual. SMART no es visible directamente.

Decisión: Si continúas, ahora dependes de herramientas específicas del controlador (-d megaraid,N) y de su corrección. Para ZFS, eso es un paso atrás.

Tarea 7: Confirmar visibilidad física de discos detrás de MegaRAID (específica del controlador)

cr0x@server:~$ sudo smartctl -a -d megaraid,0 /dev/sdc | egrep 'Device Model|Serial Number|SMART overall-health'
Device Model:     ST12000NM0008
Serial Number:    ZHZ999XY
SMART overall-health self-assessment test result: PASSED

Qué significa: Puedes acceder al SMART físico del disco mediante un índice en la capa RAID.

Decisión: Esto es mejor que nada, pero debes asegurarte de que ZFS reciba errores de I/O honestos y comportamiento de flush correcto. El acceso SMART por sí solo no certifica la calidad del passthrough.

Tarea 8: Comprobar la topología del pool ZFS y confirmar que usa rutas by-id

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

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          raidz2-0                                ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500a1b2c3d7  ONLINE       0     0     0

Qué significa: ZFS está anclado a identificadores de dispositivo estables, no a /dev/sdX.

Decisión: Si ves /dev/sdX en producción, programa una ventana de mantenimiento para arreglarlo. Es una interrupción retrasada.

Tarea 9: Detectar picos de latencia inducidos por el controlador durante scrub

cr0x@server:~$ sudo zpool iostat -v tank 5 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        12.3T  21.4T    220     15   420M  2.1M
  raidz2    12.3T  21.4T    220     15   420M  2.1M
    wwn-...      -      -     55      4   105M  0.6M
    wwn-...      -      -     54      4   104M  0.5M
    wwn-...      -      -     56      3   107M  0.6M
    wwn-...      -      -     55      4   104M  0.4M

Qué significa: Las lecturas están balanceadas. No hay un disco claramente fuera de lugar.

Decisión: Si un disco muestra ancho de banda drásticamente menor o casi cero ops durante un scrub, sospecha de un disco malo, una línea mala, problemas con el expander o una tormenta de reintentos del controlador que oculta errores.

Tarea 10: Comprobar reinicios de enlace y timeouts de comando (prueba clásica de “es el cable”)

cr0x@server:~$ sudo dmesg -T | egrep -i 'mpt3sas|sas|reset|timeout|link'
[Thu Dec 26 09:22:11 2025] mpt3sas_cm0: SAS host is non-operational !!!!
[Thu Dec 26 09:22:12 2025] mpt3sas_cm0: sending diag reset !!
[Thu Dec 26 09:22:20 2025] sd 3:0:1:0: [sdb] tag#129 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK

Qué significa: El HBA se reinició o el enlace falló. Los discos empiezan a hacer timeout.

Decisión: Antes de culpar a ZFS, reemplaza/asienta cables y comprueba potencia/termal del backplane. Si esto se repite bajo carga, estás coqueteando con la inestabilidad del pool.

Tarea 11: Validar la política de caché de escritura a nivel de disco

cr0x@server:~$ sudo hdparm -W /dev/sda

/dev/sda:
 write-caching =  1 (on)

Qué significa: La caché de escritura del disco está activada. Eso puede estar bien si los flushes se cumplen y la energía es estable; si no, puede ser picante.

Decisión: Si no puedes garantizar protección ante pérdida de energía (UPS, apagado correcto, o PLP de SSD), considera desactivar la caché de escritura en HDDs para una semántica más segura—aceptando una pérdida de rendimiento.

Tarea 12: Comprobar si se emiten barreras/flush (guiado por síntomas)

cr0x@server:~$ sudo cat /sys/block/sda/queue/write_cache
write back

Qué significa: El kernel cree que el dispositivo usa caché write-back. Eso aumenta la importancia de un comportamiento de flush correcto.

Decisión: En controladoras “HBA falsas” RAID, aquí es donde te pones nervioso: ¿el controlador realmente hace flush al disco, o solo a su propia caché?

Tarea 13: Confirmar soporte TRIM/discard para pools SSD (y detectar virtualización)

cr0x@server:~$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME  DISC-GRAN DISC-MAX DISC-ZERO
sda         4K       2G         0
sdb         4K       2G         0
sdc         0B       0B         0

Qué significa: sda/sdb soportan discard. sdc no lo hace, lo cual es común para discos virtuales detrás de controladoras RAID.

Decisión: Para pools SSD en ZFS, la falta de discard es una preocupación de rendimiento y resistencia. Prefiere HBAs reales o controladoras con passthrough verificado.

Tarea 14: Medir profundidad de cola y comprobar saturación

cr0x@server:~$ cat /sys/block/sda/device/queue_depth
32

Qué significa: La profundidad de cola del dispositivo es 32. Esto puede estar bien para HDDs; SSDs y concurrencia intensa pueden querer más, pero depende del controlador y la carga.

Decisión: Si la latencia salta bajo carga paralela, no subas la profundidad de cola reflexivamente. Primero confirma que no estás ocultando errores o golpeando cuellos de botella del expander.

Tarea 15: Comprobar versión de firmware/BIOS del controlador (combustible para control de cambios)

cr0x@server:~$ sudo lshw -class storage -short
H/W path   Device  Class          Description
/0/100/3           storage        Serial Attached SCSI controller
/0/100/4           storage        RAID bus controller

Qué significa: Has identificado dispositivos de almacenamiento, pero no el firmware. El siguiente paso es tooling del proveedor o storcli/sas3flash según la familia de controladora.

Decisión: Lleva versiones de firmware en tu CMDB o al menos en las notas de construcción. “Cambiaron” es la mitad de cada postmortem.

Guion de diagnóstico rápido (encuentra el cuello de botella)

Cuando el rendimiento de ZFS cae o un pool empieza a lanzar errores, no tienes tiempo para filosofía. Necesitas un bucle cerrado que te diga: ¿es esto un disco, un controlador, una ruta o el propio ZFS?

Primero: ¿ZFS está descontento o el hardware está mintiendo?

• Ejecuta zpool status -P. Busca incrementos en READ/WRITE/CKSUM y dispositivos degradados/fallados.
• Comprueba si las rutas de dispositivo son estables (/dev/disk/by-id/wwn-*).
• Si los errores aparecen solo como timeouts/reinicios en dmesg sin un fallo de disco claro, sospecha de cableado/HBA/expander.

Segundo: encuentra el componente lento bajo carga

• Ejecuta zpool iostat -v pool 5 durante el problema. Identifica discos con comportamiento atípico y bajo ancho de banda.
• Correlaciona con iostat -x 5 para ver utilización de dispositivo y tiempos de espera.
• Si un disco muestra gran await y bajo throughput, probablemente está fallando o reintentando. Si todos los discos muestran await elevado simultáneamente, sospecha de cuello de botella en controlador/expander o de un patrón de carga sync.

Tercero: verifica el modo del controlador y la transparencia

• Comprueba lspci + lsmod para confirmar la pila de drivers (mpt3sas es buena, megaraid_sas necesita escrutinio).
• Confirma passthrough SMART. Si necesitas índices del controlador para leer SMART, podrías tener un “HBA falso”.
• Comprueba soporte de discard para SSDs (lsblk -D).

Cuarto: decide si esto es “reemplazar disco” o “reemplazar controlador/cable”

• Reemplazar disco si SMART muestra sectores realocados/pending, errores de media, o si ZFS declara consistentemente ese disco.
• Reemplazar/asentar cable/backplane si los errores se mueven al mover el disco, o si los logs muestran reinicios de enlace afectando a múltiples discos.
• Reemplazar controlador si ves reinicios recurrentes de HBA, timeouts de comandos en muchos discos, o virtualización que bloquea la monitorización fiable.

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

1) Los scrubs son dolorosamente lentos y se “cuelgan” aleatoriamente

Síntoma: El scrub comienza rápido y luego el throughput colapsa; a veces un solo disco muestra 0 ops por largos intervalos.

Causa raíz: Tormentas de reintentos del controlador que ocultan medios marginales, o un problema de enlace SAS causando reinicios; los expanders lo amplifican.

Solución: Revisa dmesg por reinicios/timeouts, intercambia cables, mueve el disco sospechoso a otra bahía y ejecuta tests SMART largos. Si está detrás de una capa de passthrough RAID, considera seriamente pasarte a modo IT/HBA real.

2) Errores de checksum en ZFS que no puedes reparar con fiabilidad

Síntoma: CKSUM aumenta; los scrubs encuentran errores; las reparaciones no permanecen o los errores reaparecen.

Causa raíz: ZFS sobre un disco virtual RAID, o un controlador que hace remapeo/caching silencioso que rompe las suposiciones end-to-end.

Solución: Deja de usar arrays RAID de hardware bajo ZFS. Reconstruye con discos directos (HBA/modo IT). Si no puedes, al menos asegura que un disco sea un dispositivo con reporte de errores completo—pero trátalo como temporal.

3) Después de reiniciar, los discos “cambiaron de nombre” y el pool no importa limpiamente

Síntoma: La importación del pool queja de dispositivos faltantes; el orden de /dev/sdX cambió.

Causa raíz: Pool creado usando /dev/sdX; enumeración inestable; la virtualización del controlador puede empeorar esto.

Solución: Usa rutas by-id y exporta/importa con cuidado. Reemplaza el modo del controlador si reescribe identidades.

4) Los datos SMART parecen vacíos o genéricos (“Modelo desconocido”)

Síntoma: Las consultas SMART fallan a menos que pases flags especiales; el modelo aparece como el controlador.

Causa raíz: Unidades virtuales presentadas por firmware RAID, no discos físicos.

Solución: Usa un HBA/modo IT si es posible. Si estás atascado, configura monitorización usando métodos específicos del controlador y verifica que cubre todos los discos y atributos que te importan.

5) El rendimiento parece genial hasta un evento de energía, luego hay drama en el pool

Síntoma: Después de una pérdida de energía abrupta, el pool importa pero tiene errores, o faltan datos recientes de forma sospechosa.

Causa raíz: Caché write-back en la capa del controlador que admite escrituras temprano; las semánticas de flush no se cumplen end-to-end.

Solución: Desactiva la caché write-back (controlador y discos) a menos que tengas protección ante pérdida de energía verificada y semántica de flush correcta. Prefiere HBAs más simples para ZFS.

6) Eventos “aleatorios” de fallo multi-disco durante I/O intensivo

Síntoma: Varios discos registran errores a la vez; ZFS reporta timeouts; luego todo “se recupera.”

Causa raíz: Sobrecalentamiento del HBA, saturación del expander o inestabilidad PSU/backplane causando caídas momentáneas de enlace.

Solución: Mejora el flujo de aire sobre el disipador del HBA, valida conectores de potencia y backplane, y evita expanders baratos en cajas con alta cantidad de discos.

Tres mini-historias corporativas desde las trincheras de almacenamiento

Incidente causado por una suposición errónea: “Passthrough significa passthrough”

Una empresa SaaS mediana heredó un par de servidores de almacenamiento durante una rápida reestructuración del equipo. El propietario anterior dejó una nota: “Controladora en passthrough, ZFS maneja la redundancia.” Todos asintieron. Arrancó, el pool se importó, los paneles estaban verdes. El equipo tenía incendios más grandes.

Meses después vieron un patrón: picos periódicos de latencia en la réplica primaria de la base de datos, siempre durante ventanas de scrub. No había un disco obvio fallando. ZFS no marcaba nada, pero la latencia de la aplicación pasó de “bien” a “clientes enfadados” en minutos. El on-call silenciaba alertas, desactivó scrubs y prometió revisarlo.

La revisión ocurrió después de un apagado no limpio durante mantenimiento del edificio. El pool volvió, pero ZFS reportó errores de checksum que no se correlacionaban con un solo disco. Peor aún, el patrón de errores se movía entre scrubs. El equipo sospechó de RAM, luego de bugs del kernel, luego de rayos cósmicos. El borrador del postmortem ya culpaba a la “complejidad de ZFS”.

El problema real: el “passthrough” de la controladora era un wrapper de unidad virtual con caché write-back aún habilitada a nivel del controlador. Los flushes no se respetaban como ZFS esperaba. Bajo operación normal fue “aceptable”; bajo scrub + carga produjo picos de latencia por reintentos internos y comportamiento de caché; bajo pérdida de energía la corrección quedó a la suerte.

La solución fue contundente: reemplazar la controladora por un HBA apropiado y reconstruir el pool desde backups. También escribieron una regla de runbook: “Passthrough no es una característica; es una afirmación. Verifica con SMART, identidad de dispositivo y política de caché.”

Optimización que salió mal: “Usemos caché write-back para más IOPS”

Otra organización ejecutaba un almacenamiento para VMs sobre ZFS. Alguien notó que activar caché write-back en la controladora hacía que los benchmarks se vieran heroicos. La petición de cambio sonaba bien: “Mejora latencia y throughput; riesgo mitigado por UPS.” Fue aprobado porque los gráficos eran bonitos y nadie quería ser quien bloqueara rendimiento.

Por un tiempo funcionó. La latencia bajó. El equipo celebró aumentando ratios de consolidación. Así sabes que una optimización fue adoptada culturalmente: la gente comienza a depender de ella.

Entonces una actualización de firmware rutinaria cambió el comportamiento del controlador alrededor de los flushes. No dramáticamente. Solo lo suficiente. Bajo carga intensa de escrituras sync (las VMs aman sync cuando menos lo esperas), el controlador ocasionalmente admitía escrituras temprano y reordenó operaciones de maneras que ZFS no anticipaba. ZFS no gritó inmediatamente. Hizo lo que pudo con la información que recibió.

Semanas después, un nodo de almacenamiento se cayó y reimportó con un puñado de discos VM corruptos. No todo el pool, no una falla limpia—justo el tipo que arruina tu día y tu credibilidad. El UPS no ayudó porque no se trataba solo de “pérdida de energía”; se trataba de garantías de corrección en el límite.

Volvieron atrás con la caché y aceptaron el golpe de rendimiento. La lección no fue “nunca optimices.” Fue “nunca optimices violando el contrato del sistema de archivos.” ZFS ya tiene una caché (ARC), y ya sabe ordenar escrituras. Tu controladora no entiende tu intención, solo tus paquetes.

Práctica aburrida pero correcta que salvó el día: IDs estables, repuestos probados y transparencia de controladora

Una firma de servicios financieros (del tipo que prefiere ventanas de cambio más que humanos) estandarizó una lista corta de HBAs. Cada servidor se construyó usando rutas by-id, y cada disco se etiquetó físicamente con el sufijo de su WWN. La política sonaba pedante hasta que la viste en acción.

Una tarde, un pool quedó DEGRADED. ZFS marcó un disco limpiamente. No hubo ambigüedad: la ruta de zpool status -P coincidía con un WWN, y la etiqueta del chasis coincidía con la bahía. El técnico sacó el disco correcto a la primera. Eso ya es más raro de lo que debería.

Aquí está la parte que los salvó: también validaron passthrough SMART y reporte de errores durante la puesta en servicio. Cuando el disco empezó a lanzar errores de lectura, esos errores surgieron rápido y consistentemente. ZFS no tuvo que adivinar. Hizo su trabajo: reparar desde la redundancia, marcar el disco malo y seguir sirviendo.

El reemplazo resilverizó sin drama porque el HBA no inyectaba sus propias políticas de recuperación. No hubo reintentos ocultos, ni “unidad virtual degradada” opaca, ni alarmas de controlador que solo una persona supiera interpretar. El ticket del incidente se cerró con el comentario más seco del mundo: “Reemplazado disco fallado; resilver completo.”

Ese es el sueño: una falla que se comporta como los documentos de diseño. El truco es que eso solo pasa cuando construyes para que ocurra.

Listas de verificación / plan paso a paso

Paso a paso: validar una controladora para ZFS (construcción nueva o heredada)

1. Identificar tipo de controladora y driver.
   • Ejecuta lspci -nn y lsmod.
   • Objetivo: pila de driver HBA/modo IT (p. ej., mpt3sas), no una pila de virtualización RAID a menos que hayas verificado transparencia.
2. Confirmar que la identidad del disco es real.
   • Ejecuta lsblk -o NAME,MODEL,SERIAL.
   • Objetivo: el modelo/serial del disco coincide con la etiqueta del disco, no con el modelo del controlador.
3. Confirmar que existen rutas by-id estables.
   • Revisa /dev/disk/by-id/ en busca de WWNs.
   • Objetivo: crear pools usando rutas basadas en WWN, nunca /dev/sdX.
4. Validar que SMART funcione normalmente para cada disco.
   • smartctl -a /dev/sdX debería tener éxito.
   • Si requiere -d megaraid,N, implementa monitorización que lo cubra y trata la controladora como riesgo.
5. Validar comportamiento de error bajo carga.
   • Ejecuta un scrub y observa zpool iostat -v.
   • Revisa dmesg por reinicios/timeouts.
   • Objetivo: no flaps de enlace; cualquier disco malo debe mostrarse limpiamente como error de disco, no como caos a nivel controlador.
6. Decidir la política de caché deliberadamente.
   • Si tu controladora tiene caché write-back, comprende y documenta cuándo está habilitada y por qué.
   • Prefiere corrección sobre benchmarks a menos que tengas protección ante pérdida de energía y semánticas de flush verificadas end-to-end.

Lista operativa: cada trimestre (sí, en serio)

• Ejecuta un scrub y confirma que termina en un tiempo predecible.
• Revisa estadísticas SMART por fallos lentos (sectores pendientes, errores CRC).
• Verifica que los IDs de disco en ZFS aún coinciden con el etiquetado físico.
• Verifica que las versiones de firmware no hayan derivado de forma impredecible en la flota.
• Prueba un procedimiento de reemplazo de disco en un nodo no crítico (la memoria muscular importa).

Checklist de migración: mover de “HBA falso” a HBA real/modo IT

• Asume que necesitarás una ventana de mantenimiento y backups en los que confíes.
• Inventorya la disposición actual del pool con zpool status -P y guárdala.
• Registra WWNs de discos y mapeo de bahías.
• Planifica el intercambio de controladora y verifica la estrategia de arranque/raíz (no dejes el SO aislado).
• Después del cambio: valida SMART, discard (para SSD) y rutas by-id estables antes de importar/crear pools.
• Ejecuta un scrub después de la primera semana de carga intensa para detectar problemas de ruta temprano.

Preguntas frecuentes

1) ¿Tengo que usar modo IT para ZFS?

No. Tienes que darle a ZFS discos directos y veraces. El modo IT es una forma común de lograr eso en tarjetas basadas en LSI. Los HBAs reales también funcionan. Evita las capas RAID bajo ZFS.

2) ¿Cuál es la señal más simple de que trato con un “HBA falso”?

Si lsblk muestra el modelo del controlador como modelo del disco, o smartctl -a /dev/sdX falla sin flags específicos del controlador, probablemente no estás viendo discos crudos.

3) ¿Es aceptable “un RAID0 por disco” para ZFS?

Puede funcionar, pero no equivale a un HBA real. Heredas metadata/estado por disco, manejo de errores del controlador y a veces peculiaridades de caché/flush. Si es producción y tienes opción, no lo uses.

4) ¿Puedo ejecutar ZFS sobre un disco virtual RAID5/6?

Puedes, y hay gente que lo hace y sobrevive. Pero cuando tienes corrupción o casos límite en reconstrucción, ZFS no puede sanar correctamente porque no ve qué disco físico mintió. Para sistemas importantes, no apiles capas de redundancia que oculten detalles de fallo.

5) ¿Hace una caché con batería/flash a los controladores RAID seguros para ZFS?

Reduce un riesgo (pérdida de energía durante caché write-back). No resuelve el problema mayor: el controlador aún puede enmascarar errores, reescribir identidad o cambiar semánticas de comando. ZFS quiere visibilidad, no solo “durabilidad la mayoría de los días.”

6) ¿Cómo sé si se respetan flush/barriers?

Es difícil probarlo perfectamente sin pruebas dirigidas y detalles del proveedor. Prácticamente: evita capas que puedan reinterpretar flushes, desactiva caché write-back del controlador cuando sea posible y prefiere modo IT/HBAs reales donde la semántica del disco sea directa.

7) ¿Funcionan los expanders SAS con ZFS?

Sí, comúnmente. El riesgo es la calidad y la sobre-suscripción: durante scrubs/resilvers con muchos HDDs, los expanders pueden convertirse en puntos de contención. Si ves reinicios de controladora o ralentizaciones consistentes, prueba con una configuración de conexión directa.

8) Mi pool está lento. ¿Es culpa del HBA?

A veces, pero normalmente son discos, cableado o patrones de workload sync. Usa zpool iostat -v para encontrar outliers por disco, y dmesg para capturar reinicios de enlace. Los HBAs suelen ser inocentes hasta que se demuestra lo contrario.

9) ¿Y la virtualización: puedo pasar un HBA a una VM y ejecutar ZFS dentro?

Sí, con IOMMU/PCI passthrough, y puede ser sólido. La clave es que el invitado debe ver discos reales, no discos virtuales del hipervisor o de la capa RAID. Si no puedes hacer passthrough completo, vuelves al territorio de “alguien está mintiendo”.

10) ¿Están bien los discos SATA detrás de HBAs SAS?

Sí. Los HBAs SAS comúnmente conectan SATA vía tunneling SATA. Solo ten en cuenta peculiaridades de gestión de energía y que el manejo de errores SATA históricamente es menos determinista que SAS bajo condiciones de fallo intensas.

Conclusión: pasos prácticos siguientes

Si recuerdas una cosa: ZFS no quiere un gestor intermedio de almacenamiento. Quiere discos directos, errores honestos e identidad estable. El modo IT y los HBAs reales entregan eso. Las controladoras RAID con la chapa de “passthrough” podrían hacerlo, pero debes verificarlo—y la verificación es trabajo que repetirás siempre.

Pasos que puedes hacer esta semana:

• Inventorya tus controladoras (lspci) y drivers (lsmod) en la flota.
• Elige un host ZFS y verifica SMART, discard (si SSD) y estabilidad by-id end-to-end.
• Durante el próximo scrub, observa el comportamiento por disco con zpool iostat -v y revisa logs por reinicios/timeouts.
• Si encuentras un “HBA falso”, decide si estás dispuesto a asumir su monitorización y semánticas—o programa el cambio de controladora y listo.

La fiabilidad del almacenamiento es mayormente quitar sorpresas. El camino más rápido hacia menos sorpresas es un HBA sencillo, buenos cables y que ZFS vea lo que espera: discos reales haciendo cosas reales de disco.