Fallo del special vdev de ZFS: cómo sobrevivir al escenario de pesadilla

Qué es realmente un special vdev (y por qué es distinto)

Un special vdev es una clase de asignación en ZFS diseñada para almacenar metadata y (opcionalmente) bloques de archivos pequeños.
No es una caché. No es un buffer de escritura. No es un “nivel SSD agradable de tener”.
Es almacenamiento real del pool, participa en las reglas de redundancia—aunque mucha gente lo configura como si fuera un disco temporal.

Special vdev: qué almacena

• Metadata: punteros de bloque, bloques indirectos, dnodes, estructuras de directorio, spacemaps, etc.
• Opcionalmente bloques pequeños: dependiendo de special_small_blocks, datos de archivos pequeños pueden colocarse en special.
• No es una caché: a diferencia de L2ARC, los datos en special son autoritativos y necesarios si están asignados allí.

La parte que duele: permanencia de la asignación

Una vez que un bloque se asigna a un special vdev, permanece allí hasta que se reescribe en otro sitio.
Si pierdes la única copia, ZFS no puede “reconstruir” ese bloque desde discos más lentos. No hay magia de “reconstruir metadata desde paridad”
si la metadata nunca existió en los vdevs principales.

Los fallos de special vdev son brutales porque la metadata es el mapa. Perder el mapa significa que puedes tener el territorio (tus bloques de datos)
y aun así no poder encontrarlos.

Hechos interesantes y contexto histórico (porque el pasado se repite)

1. Las clases de asignación llegaron después: los special vdevs aparecieron después de que ZFS ya se hubiera hecho un nombre, por eso muchos documentos antiguos de “mejores prácticas” no los mencionan.
2. La función surgió por dolor real: pools grandes con ficheros pequeños eran rápidos en streaming y lentos en “ls -lR”; operaciones exigieron una solución que no fuera “compra más RAM”.
3. ZFS siempre trató la metadata como de primera clase: sumas de comprobación, copy-on-write y self-healing se diseñaron para proteger la estructura tanto como el contenido.
4. La gente lo confunde con SLOG: porque ambos son “dispositivos rápidos que agregas”, pero SLOG trata escrituras síncronas; special trata colocación persistente.
5. Los spacemaps importan: ZFS moderno usa spacemaps para seguir el espacio libre; si special contiene spacemaps críticos y muere, importar el pool puede volverse imposible.
6. El offload de bloques pequeños se hizo popular con la virtualización: imágenes VM y capas de contenedores generan mucha metadata y I/O aleatorio pequeño; special suele reducir significativamente la latencia.
7. Los dominios de fallo se volvieron más extraños: con special vdevs, tu pool puede ser “RAIDZ2” en HDDs y “SSD único” para metadata. La redundancia real del pool se convierte en “SSD único”.
8. La resistencia write-endurance es una limitación real: metadata y bloques pequeños son intensivos en escritura; los SSDs de consumo han muerto temprano en duty de special, especialmente con atime o cargas muy ruidosas.

Una regla seca: si te incomoda almacenar el superblock del sistema de archivos en un solo dispositivo, tampoco almacenes tu metadata ZFS de esa manera.

Escenarios de pesadilla: qué ocurre realmente cuando se rompe

Escenario A: special vdev está degradado, el pool aún importa, todo va lento y raro

Este es el caso “afortunado”. Un dispositivo en un special vdev en mirror está fallando pero no ha muerto del todo.
Las lecturas pueden reintentarse, hay picos de latencia, ZFS empieza a lanzar errores de checksum y tu aplicación comienza a hacer timeouts.
La mayoría de equipos pierde tiempo precioso culpando a la red, luego al hipervisor, luego a la base de datos. Mientras tanto, las lecturas de metadata tratan con un SSD agonizante.

Escenario B: special vdev desapareció, el pool no se importa

Si special era de un solo disco (o el mirror perdió demasiados miembros), puedes acabar con un pool no importable.
ZFS puede informar dispositivos faltantes, o peor: “importa” pero los datasets no montan o el recorrido de directorios devuelve errores de E/S.
En ese punto no estás haciendo “reemplazo de disco”. Estás respondiendo un incidente con un kit de cirujano de sistemas de archivos.

Escenario C: el pool se suspende durante IO

ZFS puede suspender un pool cuando detecta errores lo bastante graves como para que continuar suponga riesgo de más corrupción.
Verás “pool I/O is currently suspended” y los servicios se caerán en un montón sincronizado.
Trata esto como un freno de seguridad, no como una molestia.

Broma #1: Un pool suspendido es ZFS diciendo, “Puedo seguir, pero prefiero no ser culpado después.” Es el software más responsable en tu rack.

Escenario D: “lo arreglas” y el rendimiento nunca vuelve

A veces la recuperación tiene éxito pero el pool ahora funciona con metadata en HDDs porque eliminaste special o dejó de usarse eficazmente.
El sistema está “arriba”, pero los usuarios se quejan de que la interfaz parece renderizarse por conexión dial-up. Sobreviviste al fuego; ahora vives en el humo.

Qué determina lo malo que puede ser

• Redundancia del special vdev: mirror vs single; ancho del mirror; calidad del dispositivo.
• Cuánto estaba asignado a special: solo metadata, o metadata más bloques pequeños.
• Cuánto tiempo estuvo degradado: los reintentos y la corrupción se acumulan; el tiempo de resilver aumenta.
• Higiene operativa: scrubs, alertas, discos de repuesto y pasos de recuperación documentados.

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

Este es el orden que suele cortar la confusión. La meta es responder tres preguntas rápido:
“¿El pool es seguro?” “¿Está involucrado el special vdev?” “¿Cuál es la acción segura más rápida?”

Primero: confirma la salud del pool e identifica el estado del special vdev

• Ejecuta zpool status -v y busca específicamente vdevs de clase special y recuentos de errores.
• Comprueba si el pool está SUSPENDED, DEGRADED o FAULTED.
• Escanea dmesg/registros del sistema en busca de resets NVMe, timeouts o retiradas de dispositivos.

Segundo: determina el radio de impacto (solo metadata vs también bloques pequeños)

• Verifica con zfs get special_small_blocks en los datasets principales.
• Busca síntomas: listados de directorios lentos (metadata), o lecturas de archivos pequeños fallando (bloques pequeños en special).
• Comprueba flags de características del pool y si special es requerido para importar (usualmente lo es si bloques están asignados allí).

Tercero: elige una ruta de acción segura

• Si special está en mirror y solo falló un dispositivo: reemplaza inmediatamente, luego haz scrub y vigila el resilver.
• Si special es single y falló: deja de improvisar. Decide entre restaurar desde backup, intentar recuperar el dispositivo o intentos especializados de import forense.
• Si el pool está suspendido: estabiliza el hardware, exporta si es posible y planifica una importación controlada; no sigas golpeándolo con reintentos de las aplicaciones.

El único “arreglo rápido” es el que no empeora la recuperación. Muchos equipos pierden el pool por hacer escrituras frenéticas durante una falla de metadata.

Tareas prácticas de recuperación (comandos, salidas, decisiones)

Abajo hay tareas prácticas que puedes ejecutar en un host Linux con OpenZFS. Los comandos son reales. Las salidas son representativas.
El punto no es la redacción exacta; es lo que infieres y lo que haces después.

Tarea 1: Identificar la falla y confirmar que es special

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 0 days 00:19:21 with 0 errors on Thu Dec 26 01:10:12 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-HDD1                ONLINE       0     0     0
            ata-HDD2                ONLINE       0     0     0
            ata-HDD3                ONLINE       0     0     0
            ata-HDD4                ONLINE       0     0     0
            ata-HDD5                ONLINE       0     0     0
            ata-HDD6                ONLINE       0     0     0
        special
          mirror-1                  DEGRADED     7     0   118
            nvme-SAMSUNG_SSD_A      FAULTED     7     0   118  too many errors
            nvme-SAMSUNG_SSD_B      ONLINE       0     0     0

errors: No known data errors

Qué significa: el pool está degradado porque un dispositivo dentro de la clase special está faulted.
Las lecturas/errores CKSUM en special son especialmente graves porque ahí vive la metadata.

Decisión: reemplaza el NVMe fallado de inmediato. No “esperes a la ventana de mantenimiento.” Ya estás en una.

Tarea 2: Comprueba si el pool está suspendido

cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
  pool: tank
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
action: The pool can be imported using its name or numeric identifier.
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0

Qué significa: no hay suspensión aquí. Si hubieras visto state: SUSPENDED, eso cambia el plan: para IO, estabiliza y planifica una recuperación controlada.

Decisión: continúa con el reemplazo y el resilver limitando la carga, pero no necesitas maniobras de export/import de emergencia todavía.

Tarea 3: Correlaciona con errores del kernel (timeouts/resets)

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Thu Dec 26 02:14:03 2025] nvme nvme1: I/O 123 QID 6 timeout, completion polled
[Thu Dec 26 02:14:03 2025] nvme nvme1: Abort status: 0x371
[Thu Dec 26 02:14:04 2025] nvme nvme1: controller is down; will reset: CSTS=0x3, PCI_STATUS=0x10
[Thu Dec 26 02:14:06 2025] nvme nvme1: Removing after probe failure status: -19

Qué significa: el dispositivo desapareció o se reinició repetidamente. Esto no es un “bug de ZFS.” Es inestabilidad de hardware/firmware/energía/ruta PCIe.

Decisión: trata el dispositivo como poco fiable incluso si vuelve tras un reinicio. Reemplázalo; no lo confíes de nuevo con metadata.

Tarea 4: Identifica nombres by-id (evita reemplazar el disco equivocado)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'nvme-SAMSUNG_SSD_A|nvme-SAMSUNG_SSD_B'
lrwxrwxrwx 1 root root 13 Dec 26 01:59 nvme-SAMSUNG_SSD_A -> ../../nvme1n1
lrwxrwxrwx 1 root root 13 Dec 26 01:59 nvme-SAMSUNG_SSD_B -> ../../nvme0n1

Qué significa: tienes identificadores estables. Bien. Si usas solo /dev/nvme1n1, estás a un reinicio de cambiar el disco equivocado.

Decisión: realiza todas las operaciones ZFS usando rutas /dev/disk/by-id.

Tarea 5: Confirma la política de dataset para bloques pequeños (chequeo de radio de impacto)

cr0x@server:~$ sudo zfs get -r -o name,property,value special_small_blocks tank
NAME                 PROPERTY              VALUE
tank                 special_small_blocks  0
tank/vm              special_small_blocks  16K
tank/home            special_small_blocks  0
tank/containers      special_small_blocks  8K

Qué significa: algunos datasets están colocando bloques pequeños en special (vm, containers).
La pérdida de un special aquí no es solo “inconveniente de metadata.” Puede llevarse contenidos reales de archivos.

Decisión: prioriza la recuperación de esos datasets; considera redundancia más estricta y umbrales más conservadores después.

Tarea 6: Comprueba si los dispositivos special están en mirror (deberían estarlo)

cr0x@server:~$ sudo zpool status tank | sed -n '/special/,$p'
        special
          mirror-1                  DEGRADED     7     0   118
            nvme-SAMSUNG_SSD_A      FAULTED     7     0   118  too many errors
            nvme-SAMSUNG_SSD_B      ONLINE       0     0     0

errors: No known data errors

Qué significa: special vdev en mirror. Aún tienes una copia de la metadata. Estás en “modo reparación”, no en “modo forense”.

Decisión: reemplaza el miembro fallado y resilveriza lo antes posible, cuidando el SSD superviviente (vigila temperaturas, cola de operaciones, errores).

Tarea 7: Reemplaza el dispositivo special fallado

cr0x@server:~$ sudo zpool replace tank nvme-SAMSUNG_SSD_A /dev/disk/by-id/nvme-SAMSUNG_SSD_NEW
cannot open 'nvme-SAMSUNG_SSD_A': no such device in pool

Qué significa: usaste la cadena de identificador equivocada. ZFS quiere el nombre del vdev exactamente como aparece en zpool status, o la ruta GUID.

Decisión: copia y pega el token exacto de zpool status o usa zpool status -g para referenciar el GUID de forma segura.

cr0x@server:~$ sudo zpool status -g tank | sed -n '/special/,$p'
        special
          mirror-1                  DEGRADED
            12293847561234567890    FAULTED  too many errors
            99887766554433221100    ONLINE

Qué significa: hay GUIDs disponibles. Esto evita ambigüedad si los paths de dispositivos cambiaron.

Decisión: reemplaza por GUID.

cr0x@server:~$ sudo zpool replace tank 12293847561234567890 /dev/disk/by-id/nvme-SAMSUNG_SSD_NEW
invalid vdev specification
use '-f' to override the following errors:
/dev/disk/by-id/nvme-SAMSUNG_SSD_NEW is part of potentially active pool 'rpool'

Qué significa: el nuevo dispositivo contiene etiquetas ZFS antiguas (quizá vino de otro host, o se usó antes).
Esto es común con “teníamos uno en stock” drives.

Decisión: borra las etiquetas ZFS del disco nuevo con cuidado, luego reintenta el reemplazo.

Tarea 8: Borra etiquetas antiguas en el disco de reemplazo (con cuidado)

cr0x@server:~$ sudo zpool labelclear -f /dev/disk/by-id/nvme-SAMSUNG_SSD_NEW

Qué significa: la etiqueta fue borrada con éxito (es silencioso en caso de éxito).

Decisión: procede con zpool replace.

cr0x@server:~$ sudo zpool replace tank 12293847561234567890 /dev/disk/by-id/nvme-SAMSUNG_SSD_NEW
cr0x@server:~$ sudo zpool status tank | sed -n '/scan/,$p'
  scan: resilver in progress since Thu Dec 26 02:21:12 2025
        19.2G scanned at 1.12G/s, 2.88G issued at 170M/s, 19.2G total
        2.90G resilvered, 14.98% done, 0:01:12 to go
config:

        NAME                          STATE     READ WRITE CKSUM
        tank                          DEGRADED     0     0     0
          raidz2-0                    ONLINE       0     0     0
            ata-HDD1                  ONLINE       0     0     0
            ata-HDD2                  ONLINE       0     0     0
            ata-HDD3                  ONLINE       0     0     0
            ata-HDD4                  ONLINE       0     0     0
            ata-HDD5                  ONLINE       0     0     0
            ata-HDD6                  ONLINE       0     0     0
        special
          mirror-1                    DEGRADED     0     0     0
            replacing-0               DEGRADED     0     0     0
              12293847561234567890    FAULTED     0     0     0  too many errors
              nvme-SAMSUNG_SSD_NEW    ONLINE       0     0     0  (resilvering)
            99887766554433221100      ONLINE       0     0     0

Qué significa: el resilver está en progreso; ZFS está reconstruyendo la réplica faltante en el SSD nuevo.
Durante esta ventana, el SSD superviviente es tu única copia buena de metadata. Protégelo.

Decisión: reduce la carga si es posible, evita reinicios y monitorea errores de E/S en el dispositivo superviviente.

Tarea 9: Monitorea la finalización del resilver y los contadores de errores

cr0x@server:~$ watch -n 10 'sudo zpool status tank'
  pool: tank
 state: ONLINE
  scan: resilvered 19.2G in 0 days 00:03:18 with 0 errors on Thu Dec 26 02:24:30 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-HDD1                ONLINE       0     0     0
            ata-HDD2                ONLINE       0     0     0
            ata-HDD3                ONLINE       0     0     0
            ata-HDD4                ONLINE       0     0     0
            ata-HDD5                ONLINE       0     0     0
            ata-HDD6                ONLINE       0     0     0
        special
          mirror-1                  ONLINE       0     0     0
            nvme-SAMSUNG_SSD_NEW    ONLINE       0     0     0
            nvme-SAMSUNG_SSD_B      ONLINE       0     0     0

errors: No known data errors

Qué significa: el resilver terminó limpio. Tienes redundancia otra vez.

Decisión: ahora haz un scrub y valida; no declares victoria solo por un resilver.

Tarea 10: Ejecuta un scrub para confirmar sumas de comprobación end-to-end

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | sed -n '1,18p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 02:27:01 2025
        412G scanned at 1.88G/s, 64.1G issued at 291M/s, 2.41T total
        0B repaired, 2.59% done, 0 days 02:19:31 to go

Qué significa: el scrub está leyendo y verificando sumas en todo el pool, reparando desde redundancia cuando es posible.

Decisión: déjalo terminar. Si informa reparaciones, investiga por qué (cable malo, controlador inestable, disco que muere).

Tarea 11: Revisa SMART/NVMe health para los dispositivos supervivientes y los nuevos

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'critical_warning|media_errors|percentage_used|data_units_written'
Critical Warning:                   0x00
Percentage Used:                   12%
Media and Data Integrity Errors:   0
Data Units Written:                9,812,334

Qué significa: sin advertencias críticas, bajo desgaste, sin errores de media. Este SSD parece sano.

Decisión: mantenlo. Si Media and Data Integrity Errors o Critical Warning son no cero, planifica reemplazo aunque ZFS esté contento.

Tarea 12: Mide si la metadata es el cuello de botella (triage de latencia)

cr0x@server:~$ sudo zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                         1.2T  1.1T    820    410  62.1M  28.4M
  raidz2-0                   1.2T  1.1T    120    360  51.2M  26.9M
    ata-HDD1                    -      -     20     60  8.40M  4.60M
    ata-HDD2                    -      -     19     60  8.22M  4.58M
    ata-HDD3                    -      -     21     60  8.62M  4.56M
    ata-HDD4                    -      -     20     60  8.51M  4.51M
    ata-HDD5                    -      -     20     60  8.70M  4.54M
    ata-HDD6                    -      -     20     60  8.75M  4.55M
special                         -      -    700     50  10.9M  1.50M
  mirror-1                      -      -    700     50  10.9M  1.50M
    nvme-SAMSUNG_SSD_NEW         -      -    350     25  5.40M  0.76M
    nvme-SAMSUNG_SSD_B           -      -    350     25  5.50M  0.74M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: alto conteo de operaciones en special relativo al ancho de banda sugiere I/O intensivo en metadata (muchas lecturas pequeñas y aleatorias).
Eso es normal para escaneos de directorio, contenedores y churn de metadata.

Decisión: si la latencia de special es alta o muestra errores, arregla special primero. Si special está sano pero raidz está saturado, el cuello de botella está en otro lado.

Tarea 13: Confirma uso del special vdev y presión de metadata

cr0x@server:~$ sudo zdb -bbbs tank | sed -n '1,24p'
Dataset tank [ZPL], ID 53, cr_txg 5, 3.12T, 2 objects
Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
     1    2   128K    16K  3.20K    512   16.0K  100.0  DMU dnode
    17    1   128K    16K  3.20K    512   16.0K  100.0  ZAP

Qué significa: zdb puede mostrar estructuras de metadata y tamaños. No es una herramienta de uso diario, pero es útil para demostrar “esta carga es intensiva en metadata.”

Decisión: si tu entorno está dominado por ficheros diminutos/metadata de VM, dimensiona special en consecuencia y haz mirror con intención.

Tarea 14: Si la importación falla, lista pools importables y dispositivos faltantes

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1234567890123456789
  state: UNAVAIL
status: One or more devices are missing from the system.
action: The pool cannot be imported. Attach the missing devices and try again.
   see: zpool-import(8)
config:

        tank                        UNAVAIL  missing device
          raidz2-0                  ONLINE
            ata-HDD1                ONLINE
            ata-HDD2                ONLINE
            ata-HDD3                ONLINE
            ata-HDD4                ONLINE
            ata-HDD5                ONLINE
            ata-HDD6                ONLINE
        special
          nvme-SAMSUNG_SSD_A         UNAVAIL

Qué significa: el pool no está disponible porque falta el dispositivo special. Si ese special era de un solo disco, esto es tan grave como parece.

Decisión: no intentes imports forzados aleatorios con -f. Tu mejor movimiento es recuperar la ruta del dispositivo (arreglo de hardware) o pivotar a recuperación desde backups/replicas.

Tarea 15: Si el pool está suspendido, confirma y detén el churn

cr0x@server:~$ sudo zpool status -x
pool 'tank' is suspended

Qué significa: ZFS ha pausado IO para proteger la integridad. Tus aplicaciones seguirán reintentando y empeorarán la situación.

Decisión: detén servicios de alto volumen, aísla el host si es necesario, y trabaja en la recuperación del almacenamiento sin una manada atronadora de peticiones.

Tarea 16: Verifica que el special vdev esté presente en la disposición del pool (auditoría post-recuperación)

cr0x@server:~$ sudo zpool get -H -o property,value ashift,autotrim tank
ashift  12
autotrim on

Qué significa: ashift está fijado en la creación del pool; la descoincidencia puede afectar rendimiento y longevidad del SSD. autotrim ayuda el comportamiento del SSD con el tiempo.

Decisión: mantén autotrim=on para special backed por SSD a menos que tengas una razón específica para no hacerlo. Si ashift está mal, planifica una migración; no intentes “ajustarlo” sobre la marcha.

Tres mini-historias corporativas desde las trincheras

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

Una compañía SaaS mediana desplegó almacenamiento nuevo para una plataforma de contenedores. El ingeniero que hizo el montaje tenía un modelo mental limpio:
vdevs mirror en HDD para capacidad, y una “SSD rápida” para metadata. Había usado L2ARC antes y asumió que special se comportaba igual.
“En el peor de los casos perdemos algo de rendimiento,” dijo al equipo. Sonaba razonable. Nadie dijo nada.

La carga era un clásico mezclador de metadata: capas de imágenes de contenedores, montones de ficheros pequeños de configuración y un sistema CI que descomprimía y borraba árboles todo el día.
La SSD de special rápidamente se volvió caliente—no en ancho de banda, sino en IOPS. También se volvió el dispositivo más importante del pool.
No tenían alertas en sus NVMe porque la plantilla de monitorización estaba construida alrededor del SMART de HDD.

Un viernes, la SSD empezó a lanzar resets. ZFS la marcó como faulted. El pool quedó inaccesible tras un reboot.
Su primera respuesta fue “simplemente importa con fuerza,” porque los vdevs de rust estaban bien y podían ver todos los discos.
La importación no funcionó. Luego lo intentaron otra vez. Y otra vez. Mientras tanto, la automatización seguía intentando montar y arrancar servicios, llenando el host de IO.

Finalmente alguien notó que la configuración del pool incluía un vdev special y que era un punto único de fallo.
La solución no fue ingeniosa: localizaron un SSD idéntico, lo pusieron en una ranura conocida buena y lograron recuperar el dispositivo original lo suficiente como para clonarlo a nivel de bloque.
Ese salvamento les permitió una importación y la oportunidad de mover datos a otro sitio.

La lección del postmortem fue dolorosamente básica: un special vdev no es almacenamiento opcional. Es estructural.
Su suposición (“es como una caché”) les costó un fin de semana y los obligó a mirar qué otros “add-ons rápidos” eran realmente críticos.

Mini-historia 2: La optimización que se volvió en contra

Un organismo financiero tenía un pool ZFS que respaldaba directorios home y muchos archivos pequeños de proyectos. Las quejas de rendimiento eran constantes:
búsquedas lentas, recorrido de directorios lento, indexación IDE lenta. Se culpó al almacenamiento, luego a la red, luego a los endpoints.
Alguien sugirió special vdevs con special_small_blocks=128K en el dataset principal. “Pon todo lo pequeño en SSD, problema resuelto.”

Solucionó las quejas de rendimiento. Por un tiempo.
La indexación fue más rápida, operaciones git mejoraron y la cola de helpdesk bajó. El equipo de almacenamiento declaró el éxito y siguió con otras tareas.
Pero los dispositivos special eran SSDs empresariales pequeños dimensionados para “metadata”, no para “metadata más una montaña de contenido de archivos pequeños.”

Seis meses después, el pool estaba sano pero el vdev special casi lleno. ZFS no explotó inmediatamente, simplemente se volvió incómodo:
las asignaciones se volvieron limitadas, la fragmentación aumentó y algunas operaciones se hicieron de nuevo más lentas.
Entonces un SSD tuvo una ráfaga de errores de media y el resilver tuvo que escribir muchos datos—porque special contenía gran cantidad de bloques de archivos reales.

El resilver tomó más tiempo del esperado y el SSD superviviente fue golpeado duramente. Sobrevivió, pero solo después de un día tenso revisando contadores de error.
Tuvieron suerte. La optimización cambió el modo de fallo de “el dispositivo metadata muere, lo reemplazas rápido” a “special contiene bloques de usuario críticos y recibe escritura intensa durante el resilver.”

La retrospectiva no fue “nunca usar special_small_blocks.” Fue “trátalo como almacenamiento tier-0.”
Si vas a almacenar bloques de datos allí, dimensiona, haz mirror correctamente y monitoriza como si fuera crítico de producción—porque lo es.

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

Una compañía de medios ejecutaba ZFS para cargas mixtas: almacenamiento VM, artefactos de build y muchos assets pequeños.
Su responsable de almacenamiento era decididamente poco romántico sobre el tema. Cada pool tenía un special vdev en mirror, y cada mirror special tenía SSDs del mismo modelo con protección contra pérdida de energía.
Hacían scrubs con horario, probaban restauraciones y tenían un runbook para “reemplazar miembro special” con comandos copy-paste.

Una tarde, un NVMe del mirror special empezó a loguear errores de media.
La monitorización lo captó porque tenían alertas explícitas para métricas de error NVMe y errores de checksum ZFS, no solo “disco está online.”
El on-call no dudó. Aislaron trabajos pesados, reemplazaron la unidad y vigilaron el resilver.

El resilver terminó rápido. Hicieron un scrub. Sin reparaciones. Sin drama.
La mayor parte de la compañía nunca supo que algo pasó, que es el resultado correcto para un incidente de almacenamiento.

Lo mejor: el equipo también había documentado qué datasets usaban special_small_blocks y por qué.
Así que cuando la dirección preguntó “podemos reducir gasto en SSD el próximo trimestre,” no respondieron con vaguedades.
Mostraron qué cargas dependían de special y cómo sería el fallo. Las conversaciones presupuestarias fueron más sencillas porque la realidad ya estaba documentada.

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

1) Síntoma: El pool no importa, los vdevs de rust parecen bien

• Causa raíz: falta un special vdev de un solo disco (la metadata asignada allí es requerida para importar).
• Solución: recupera la ruta del dispositivo faltante (hardware/PCIe/energía), o restaura desde backup/replicación. Si special no tenía mirror, tus opciones son limitadas y feas.

2) Síntoma: Cargas intensivas en ls y stat son dolorosamente lentas, pero las pruebas de throughput están bien

• Causa raíz: special vdev degradado o poco saludable; las lecturas de metadata se reintentan, amplificando la latencia.
• Solución: revisa zpool status -v, zpool iostat -v y logs NVMe; reemplaza el miembro special que falla; haz scrub después.

3) Síntoma: Después del reemplazo, el rendimiento sigue peor que antes

• Causa raíz: special fue eliminado/nunca usado como se esperaba, o la política special_small_blocks cambió y los datos no se reubicaron.
• Solución: confirma propiedades de datasets; entiende que los bloques existentes no se mueven a menos que se reescriban; planifica una migración basada en reescritura (send/recv o recopia) si necesitas repoblar special.

4) Síntoma: El pool se suspende durante carga pico

• Causa raíz: errores severos de IO en special vdev causando que ZFS se proteja; a veces un HBA/backplane fallando empeora el problema.
• Solución: detén el churn de IO, estabiliza el hardware y luego reemplaza dispositivos. No dejes que los servicios sigan reintentando en un pool suspendido.

5) Síntoma: special vdev sigue llenándose inesperadamente

• Causa raíz: special_small_blocks configurado alto en datasets con muchos archivos pequeños a medianos; special ahora almacena datos de usuario significativos.
• Solución: baja special_small_blocks para nuevas asignaciones (no moverá bloques viejos), añade capacidad a special (vdevs en mirror) y planifica una reescritura si debes evacuar.

6) Síntoma: El resilver tarda una eternidad y el pool está lento

• Causa raíz: special contiene gran volumen de bloques pequeños; el resilver es intensivo en metadata/IOPS y compite con producción.
• Solución: programa resilver con carga reducida, asegúrate de que no haya thermal throttling en SSDs y considera mirrors más anchos o dispositivos más rápidos para special.

7) Síntoma: Reemplazaste un disco y ahora otro disco “desapareció”

• Causa raíz: inestabilidad en nombres de dispositivos, ranura equivocada, backplane malo o depender de nombres /dev/nvmeXn1.
• Solución: usa /dev/disk/by-id; verifica cableado/PCIe lanes; evita caos de hotplug sin plan.

Prevención que funciona (y qué es cargo cult)

Mirror para special vdevs. Siempre.

Si recuerdas una cosa: un special vdev de un solo disco hace que todo el pool dependa de ese dispositivo.
Eso no es “un poco arriesgado.” Es un error de diseño.
Hazle mirror, idealmente con dos dispositivos del mismo modelo y clase de endurance. Si tu entorno es realmente crítico, considera mirror a 3 vías.

Elige SSDs como un adulto

La metadata y el I/O de bloques pequeños son intensivos en escritura y sensibles a latencia. Quieres:
protección contra pérdida de energía, latencia predecible bajo carga y endurance que iguale tu churn.
Los SSDs de consumo pueden funcionar en laboratorio y traicionarte en producción a las 2 a.m., que es cuando el hardware expresa sus sentimientos.

Broma #2: SSDs de consumo en duty de special son como becarios con root—a veces brillantes, a veces catastróficos, siempre pasando en el peor momento.

Sé deliberado con special_small_blocks

special_small_blocks es potente. También es la forma más fácil de convertir “dispositivo de metadata” en “contiene bloques de datos de usuario.”
Eso puede ser exactamente lo que quieres para picos de arranque de VM, capas de contenedores o repos con muchos archivos pequeños.
Pero cambia tu planificación de capacidad, comportamiento de resilver y radio de impacto de fallo.

• Si lo configuras: dimensiona special para datos, no solo para metadata.
• Manténlo específico por dataset: no lo apliques por defecto en todo el pool a menos que entiendas cada carga.
• Documenta el motivo: el tú del futuro olvidará y culpará a lo incorrecto.

Monitorea lo que importa (ZFS más NVMe)

Quieres alertas sobre:
errores de checksum ZFS, errores de dispositivo, anomalías en resilver/scrub y errores de integridad media/datos NVMe.
“El disco está online” es una métrica inútil. Los discos pueden estar online y mentir.

Disciplina operativa vence a los héroes

Scrubs programados detectan problemas latentes antes de que un rebuild te obligue a leer todo bajo presión.
Repuestos conocidos y probados reducen la tentación de usar discos reclamados con historial misterioso.
Un runbook reduce la probabilidad de meter el vdev equivocado cuando la adrenalina hace que tus dedos teclean.

Una cita de fiabilidad (idea parafraseada)

Idea parafraseada: la mentalidad operativa de Gene Kranz: sé “duro y competente” en crisis—mantente disciplinado, usa listas de verificación y no improvises hasta empeorar el fallo.

Listas de verificación / plan paso a paso

Checklist A: Cuando special vdev queda DEGRADED (en mirror)

1. Ejecuta zpool status -v; confirma que los errores están en special e identifica token/GUID del dispositivo.
2. Congela cambios riesgosos: detén despliegues, pospone reboots, reduce jobs intensivos en IO.
3. Revisa logs del kernel por resets/timeouts; confirma que no es un problema del controlador/backplane compartido.
4. Valida que tienes el disco de reemplazo correcto y borra etiquetas antiguas si es necesario.
5. Ejecuta zpool replace; monitoriza progreso del resilver y contadores de error.
6. Después del resilver, ejecuta un scrub; verifica “0 errors.”
7. Post-incidente: extrae logs SMART/NVMe, registra el modo de fallo y ajusta umbrales de monitorización.

Checklist B: Cuando special vdev está UNAVAIL y el pool no importa

1. Ejecuta zpool import; identifica dispositivos faltantes y confirma que es special.
2. Detente. No repitas imports forzados. Cada intento puede empeorar el estrés del dispositivo o crear confusión.
3. Trabaja el hardware primero: reseat, mueve a ranura conocida buena, revisa BIOS/errores PCIe, energía, cables/backplane.
4. Si el dispositivo se ve aunque sea intermitente, prioriza la recuperación de datos: clónalo, imagínalo o mantenlo estable el tiempo suficiente para importar.
5. Si special no tenía mirror y el dispositivo está muerto: pivota a backups/replicación. Sé honesto; no prometas magia.
6. Tras la recuperación: reconstruye el diseño del pool. Un special de un solo disco debería ser tratado como “nunca más.”

Checklist C: Después de la recuperación (la parte que los equipos se saltan)

1. Confirma que el pool está ONLINE y el scrub limpio.
2. Verifica special_small_blocks en datasets críticos y documenta la justificación.
3. Auditá la capacidad y el margen de special; planifica expansión antes de que se quede justo.
4. Revisa monitorización: errores ZFS, salud NVMe, throttling por temperatura, eventos PCIe AER.
5. Ejecuta una prueba de restauración o un ejercicio de failover por replicación dentro del mes. Si no lo pruebas, no lo tienes.

Preguntas frecuentes

1) ¿Un special vdev es básicamente lo mismo que L2ARC?

No. L2ARC es caché; perderlo es molesto. Special es almacenamiento autoritativo; perderlo puede impedir la importación o hacer inaccesibles archivos.

2) ¿Un special vdev es básicamente lo mismo que SLOG?

No. SLOG acelera escrituras síncronas para ciertas cargas y puede retirarse con consecuencias limitadas. Special contiene metadata y posiblemente bloques de datos.

3) Si hago mirror de mis vdevs principales con RAIDZ2, ¿sigo necesitando mirror para special?

Sí. La redundancia del pool está limitada por el componente menos redundante y requerido. Un dispositivo special único puede convertirse en el verdadero punto único de fallo.

4) ¿Cuál es el ajuste más seguro para special_small_blocks?

Para muchas cargas mixtas: 0 (solo metadata) es lo más seguro. Si lo configuras, hazlo por dataset y dimensiona special para almacenamiento de datos real.

5) ¿Puedo eliminar un special vdev después de agregarlo?

En la práctica, debes asumir “no” para la planificación operativa. Incluso si tu plataforma soporta ciertos escenarios de eliminación, los bloques asignados allí deben manejarse con seguridad.
Trata el special como parte permanente del diseño del pool.

6) Si un dispositivo special está fallando, ¿debería reiniciar?

No como primer movimiento. Los reboots pueden reordenar nombres de dispositivos, provocar resets adicionales y reducir la posibilidad de una recuperación estable.
Reemplaza el dispositivo en condiciones controladas si es posible.

7) ¿Por qué todo parece bien en benchmarks de throughput pero los usuarios se quejan?

Muchas operaciones visibles para usuarios son intensivas en metadata: recorrido de directorios, llamadas stat, aperturas de archivos pequeños.
Los problemas de special golpean IOPS/latencia primero, no el throughput secuencial.

8) Después de reemplazar special, ¿sigo necesitando un scrub?

Sí. Resilver restaura la redundancia para bloques asignados pero no sustituye una pasada de verificación end-to-end.
Scrub confirma integridad en todo el pool y puede revelar otros dispositivos débiles.

9) ¿Puedo “recuperarme” de perder un special de un solo disco sin backups?

A veces puedes si el dispositivo no está realmente muerto (visibilidad intermitente, rarezas de firmware, problemas de ranura).
Si se fue de verdad y era la única copia, espera pérdida de datos y planifica alrededor de backups/replicación.

10) ¿Cuál es la mejor alerta temprana de que special está en problemas?

Aumento de errores de checksum en special, errores de integridad media/datos NVMe y logs del kernel mostrando timeouts/resets.
Picos de latencia con bajo ancho de banda también son un signo clásico.

Conclusión: próximos pasos que puedes hacer esta semana

El fallo de special vdev es uno de esos incidentes donde la verdad técnica es contundente: si hiciste que la metadata dependiera de un solo dispositivo, hiciste depender todo el pool de él.
La salida no son comandos ingeniosos. Es redundancia, verificación y negarte a tratar a los dispositivos tier-0 como accesorios.

Haz esto

• Auditoría: ejecuta zpool status y confirma que los special vdevs están en mirror en todos lados.
• Revisión de políticas: inventaría special_small_blocks por dataset; decide dónde está justificado y dónde fue accidental.
• Monitorización: alerta sobre errores de checksum ZFS y errores de integridad media/datos NVMe, no solo “online”.
• Práctica: ensaya un reemplazo de miembro special en un pool no productivo; hazlo aburrido.
• Backups/replicación: valida que puedes restaurar o hacer failover sin heroicidades. Si no puedes, arregla eso antes de que otro disco decida retirarse.

El escenario de pesadilla se vuelve sobrevivible cuando tratas a los special vdevs como lo que son: el sistema nervioso del sistema de archivos.
Protégelo, monitorízalo y cuando se convulsione, actúa como si importara.