Lecturas solo de metadatos en ZFS: cómo el vdev especial cambia las reglas

Qué significan realmente las “lecturas solo de metadatos” en ZFS

“Lecturas solo de metadatos” es como se llama cuando la carga de trabajo de tu aplicación parece leer archivos, pero ZFS está leyendo mayormente
las estructuras que describen los archivos. Piensa en recorridos de directorios, comprobaciones de permisos, contabilidad tipo inode,
árboles de snapshots y los punteros de bloque que llevan a los datos reales.

En términos de ZFS, esto está dominado por bloques como:

• Bloques indirectos (punteros de bloque que describen dónde viven los datos).
• Dnodes (los metadatos de objetos: tipo, tamaño, punteros de bloque, bonus buffer).
• Objetos ZAP (almacenes nombre/valor usados intensamente para directorios y propiedades).
• Space maps / metaslabs (contabilidad de asignación; pueden aparecer en patrones patológicos de asignación).
• DDT si dedup está habilitado (más sobre eso: por favor no, a menos que realmente lo necesites).

Una carga de trabajo pesada en metadatos puede tener “MB/s” miserables mientras satura presupuestos de IOPS y latencia. La pool parece inactiva para quienes
sólo monitorizan throughput. Mientras tanto, tu aplicación ve “almacenamiento lento” porque cada búsqueda de metadatos es una lectura aleatoria y las lecturas aleatorias
en HDD son básicamente una negociación con la física.

El secreto sucio: muchas cargas de trabajo de “lectura” son en realidad cargas de búsqueda. Un farm de compilación haciendo millones de stat en archivos pequeños.
Un servidor de correo recorriendo directorios. Una plataforma de contenedores enumerando capas. Software de backup que hace un escaneo previo de todo lo que tienes antes de leer un byte.
Estas son tareas de metadatos que de vez en cuando leen datos.

Una cita que vale la pena pegar en el monitor, como idea para recordar:
parafraseando la idea: Todo falla; lo que importa es construir sistemas que fallen de forma predecible y se recuperen rápido.
— John Allspaw

Los vdevs especiales son una forma de hacer los modos de fallo de metadatos menos dramáticos: menor latencia, menos timeouts, menos reintentos, menos incidentes en cascada.
Pero sólo si respetas lo que son.

Vdev especial: qué es y qué no es

Un vdev especial es una clase de asignación en OpenZFS. Es un lugar donde ZFS puede almacenar ciertas categorías de bloques,
normalmente metadatos y (opcionalmente) bloques de archivos “pequeños”, en una clase de vdev más rápida que la pool principal.

La verdad operativa más importante: un vdev especial no es una caché. No es L2ARC. No es un “quizá pongamos algo ahí y si se rompe nos encogemos de hombros”.
Si se pierde un vdev especial, típicamente se pierde la pool, porque esos bloques son parte de la estructura en disco autorizada de la pool.

Estás moviendo órganos críticos del sistema de archivos a otro medio. Trátalo como mover el WAL de una base de datos a otro disco: puede ser brillante, y puede ser fatal.

Qué va a special por defecto

Con un vdev especial presente, ZFS asignará metadata allí por defecto (sujeto a detalles de implementación y espacio disponible). Eso incluye dnodes,
bloques indirectos, estructuras de directorio (ZAP) y otros objetos de metadatos.

Qué puede ir a special si lo pides

La propiedad del dataset special_small_blocks te permite empujar bloques de datos de archivos pequeños a special también.
Ese es el mando que convierte “acelerador de metadatos” en “acelerador de E/S pequeñas”.

Aquí es donde la gente se emociona y luego es despedida. Cubriremos cómo hacerlo sin la segunda parte.

Broma #1: Los vdevs especiales son como el espresso—cambian la vida en la dosis correcta, y una idea terrible si sigues “optimizando” hasta las 3 a.m.

Cómo el vdev especial cambia la ruta de lectura

Sin vdev especial, las lecturas de metadatos se comportan como cualquier otra lectura: ZFS recorre punteros, recupera bloques de los mismos vdevs que contienen datos,
y depende en gran medida de ARC para evitar golpes repetidos en disco. ARC ayuda, pero una caché fría, un conjunto de trabajo sobredimensionado o un escaneo agresivo pueden
expulsar metadatos y forzar I/O real.

Con vdev especial, los bloques que describen el sistema de archivos se colocan en una clase de vdev que típicamente es SSD o NVMe. El resultado:

• I/O aleatorio de metadatos cambia de búsquedas en HDD a lecturas en SSD.
• Colapso de latencia: no solo menor latencia media, sino menos latencias extremas terribles.
• Mayor concurrencia efectiva: operaciones que antes se serializaban por el movimiento del cabezal del disco se paralelizan.
• ARC se vuelve más efectivo: metadatos traídos rápido reducen el tiempo de espera y mejoran el calentamiento de la caché.

La matización importante: el vdev especial no elimina mágicamente el I/O de metadatos. Lo hace lo suficientemente barato como para que deje de dominar.
Tu cuello de botella puede moverse entonces a otro sitio: CPU (compresión), red, bloqueos en la aplicación o los vdevs de datos principales.
Eso es un buen problema. Al menos es honesto.

Lecturas solo de metadatos en producción

Algunos patrones que producen “principalmente lecturas de metadatos”:

• Grandes recorridos de directorios: repetidos readdir(), stat(), comprobaciones de permisos.
• Datasets con muchos snapshots: listar snapshots, clones y send con coste de recorrido elevado.
• Verificación de backups: operaciones de “comparar lista de archivos” que tocan todo.
• Desempaquetado de imágenes de contenedores: muchos archivos pequeños, muchas actualizaciones y búsquedas de metadatos.
• Sistemas de build: archivos diminutos, muchas comprobaciones de existencia, churn de metadatos.

Hechos e historia que importan en producción

Algunos puntos de contexto que te ayudan a razonar sobre vdevs especiales y comportamiento de metadatos, sin convertir tu revisión de incidentes en un seminario de posgrado:

1. ZFS fue diseñado para integridad de extremo a extremo: los metadatos no son opcionales; perderlos significa que no puedes interpretar los bloques de datos con seguridad.
2. ARC precede a “vdev especial” como característica mainstream: el ajuste temprano del rendimiento en ZFS se apoyaba en RAM y diseño, no en clases de asignación.
3. L2ARC llegó antes que vdev especial: L2ARC es una caché y puede perderse; vdev especial es almacenamiento y no puede perderse sin consecuencias.
4. La idea de “metadatos en SSD” existía mucho antes en almacenamiento: sistemas de archivos y arrays han usado NVRAM/SSD espejados para mapas y diarios durante décadas.
5. Las clases de asignación de OpenZFS maduraron con el tiempo: los conjuntos de características iniciales fueron conservadores; los despliegues modernos usan vdevs especiales rutinariamente para cargas mixtas.
6. Las tablas de dedup (DDT) son metadatos en esteroides: cuando dedup está habilitado, el DDT puede dominar lecturas aleatorias y uso de memoria.
7. Los bloques indirectos pueden ser una gran fracción del I/O: especialmente con archivos grandes y lecturas aleatorias, puedes quedar limitado por el seguimiento de punteros.
8. Los vdevs especiales cambiaron el “problema de archivos pequeños”: empujar bloques de archivos diminutos a SSD suele ser la diferencia entre “bien” y “por qué ls tarda segundos?”.

El titular: vdev especial no es una característica de juguete. Es ZFS reconociendo que la latencia de metadatos suele ser el verdadero enemigo, y que añadir más HDDs es una forma triste de cardio.

Cuándo el vdev especial es una gran ganancia (y cuándo es inútil)

Escenarios de gran ganancia

• Millones de archivos pequeños donde el recorrido de directorios y los stats dominan.
• Anfitriones de virtualización o contenedores con muchos archivos de configuración pequeños y consultas frecuentes.
• Destinos de backup donde las fases de escaneo/verificación son el cuello de botella.
• Datasets con muchos snapshots donde el coste de recorrer metadatos aparece en operaciones send/list.
• Pools con dedup habilitado (otra vez: solo si realmente lo necesitas) donde las lecturas del DDT dominan; special puede ayudar, pero la RAM sigue importando más.

Escenarios inútiles o marginales

• Cargas de streaming que leen archivos grandes y contiguos (media, archivos). Tu cuello de botella es el ancho de banda secuencial, no los metadatos.
• ARC ya contiene el conjunto de trabajo. Si todos los metadatos están residentes, special no mostrará ganancias dramáticas.
• Cargas dominadas por escrituras síncronas. Eso es territorio de SLOG, no de vdev especial.

Dónde la gente predice mal la ganancia

La suposición equivocada clásica es “nuestra pool es lenta porque los HDD son lentos, así que los SSD lo arreglarán”. A veces cierto. A menudo falso.
Si tu dolor es latencia en lecturas aleatorias de metadatos, vdev especial es una solución quirúrgica.
Si tu dolor es “estamos limitados por CPU en la compresión” o “la app hace una operación a la vez”, entonces el vdev especial principalmente hace que las gráficas se vean mejor.

Diseñar distribuciones sensatas de vdev especial

Aquí está la postura de diseño que te mantiene empleado: espeja el vdev especial. Si no puedes permitir redundancia para ello,
no puedes permitir la característica.

Reglas de redundancia que no se doblan

• Usa mirrors para vdevs especiales en la mayoría de entornos. Existen special vdevs en RAIDZ, pero los mirrors mantienen baja latencia y dominios de fallo claros.
• Iguala o excede la postura de fiabilidad de la pool. Si tus vdevs de datos son RAIDZ2, tu vdev especial no debería ser un único SSD “porque es enterprise”.
• Planifica la resistencia al desgaste. Los metadatos pueden escribir mucho bajo churn. Elige SSDs con endurance real, no “lo que estaba en oferta”.

Tamaño: la parte que todos adivinan mal

Subdimensiona special y alcanzarás 80–90% de uso, la asignación se vuelve limitada y el rendimiento se vuelve raro de formas no obvias.
Sobredimensionarlo y desperdicias dinero, pero también compras paz operativa: espacio para crecer, margen para reequilibrar, menos precipicios.

Guía práctica de dimensionamiento:

• Vdev especial solo para metadatos: hiéralo generosamente para que se mantenga cómodamente por debajo de ~70% usado en estado estable.
• Metadatos + pequeños bloques: asume que se convierte en una capa caliente. Dimensiónalo como dimensionarías un dataset real, porque efectivamente lo es.
• Entornos con muchos snapshots: los metadatos crecen con el historial. Presupuéstalo. “Borramos snapshots después” no es una estrategia; es un cuento para dormir.

special_small_blocks: un cuchillo afilado

Ajustar special_small_blocks a un valor no nulo significa que cualquier bloque con ese tamaño o menor se asigna a special.
Si lo pones a 128K en un dataset con recordsize=128K, felicitaciones: acabas de decirle a ZFS que ponga básicamente todos los datos en special. La gente hace esto por accidente. Luego aprende nuevas sensaciones.

Un enfoque conservador:

• Empieza con 0 (solo metadatos), mide, y luego considera 16K o 32K para cargas con archivos pequeños.
• Úsalo por dataset, no como “optimización” a nivel de pool. Tus imágenes de VM no lo necesitan; tu árbol de código puede sí.
• Documentalo. El tú del futuro es un extraño que culpará al tú del presente.

Broma #2: Poner special_small_blocks=128K en un dataset concurrido es como poner toda tu oficina en el Wi‑Fi de invitados porque “probó ser más rápido”.

Tareas prácticas: comandos, significado de la salida y decisiones

Estas son las comprobaciones diarias que separan “leí sobre vdevs especiales” de “puedo operarlos a las 2 a.m. sin improvisar”.
Cada tarea incluye un comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Confirmar el layout de la pool y la presencia de la clase special

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
        special
          mirror-1                  ONLINE       0     0     0
            nvme0n1p1               ONLINE       0     0     0
            nvme1n1p1               ONLINE       0     0     0

errors: No known data errors

Significado: Existe una sección special y está en mirror. Bien. Si no ves special, no tienes uno.

Decisión: Si falta special y los metadatos son un cuello de botella, planifica añadir uno. Si está presente pero en disco único, trátalo como un bug de fiabilidad.

Task 2: Verificar estadísticas de clase de asignación (¿los bytes realmente están ahí?)

cr0x@server:~$ sudo zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        109T  72.4T  36.6T        -         -    18%    66%  1.00x  ONLINE  -
  raidz2-0  109T  70.9T  38.1T        -         -    18%    65%      -  ONLINE
  special   3.64T  1.52T  2.12T        -         -     9%    41%      -  ONLINE

Significado: Special tiene asignación. Si está cerca de cero mientras esperas metadatos allí, algo anda mal (no había special al crear, o los bloques preceden su creación).

Decisión: Si special está infrautilizado pero debería usarse, comprueba propiedades del dataset y considera si los datos existentes necesitan reescribirse/migrarse para beneficiarse.

Task 3: Comprobar ajustes del dataset que controlan la colocación de bloques

cr0x@server:~$ sudo zfs get -o name,property,value -s local,received special_small_blocks,recordsize,atime,compression tank/projects
NAME           PROPERTY              VALUE
tank/projects  special_small_blocks  32K
tank/projects  recordsize            128K
tank/projects  atime                 off
tank/projects  compression           zstd

Significado: Este dataset enviará bloques ≤32K a special. Con recordsize=128K, solo archivos/bloques realmente pequeños irán allí.

Decisión: Si special se llena demasiado rápido, baja o restablece special_small_blocks. Si la latencia de metadatos sigue mala, considera subirlo con cautela.

Task 4: Averiguar si tu “lectura lenta” es metadatos (vista de estadísticas ARC)

cr0x@server:~$ sudo arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:01   560    90     16    40   44    22   24    28   31   64G   96G
12:01:02   610   110     18    55   50    24   22    31   28   64G   96G
12:01:03   590   105     17    52   50    25   24    28   27   64G   96G
12:01:04   605   120     20    62   52    28   23    30   25   64G   96G
12:01:05   575   115     20    60   52    27   23    28   24   64G   96G

Significado: Altas fallas de metadatos (dmis/mmis) indican que los metadatos no se mantienen en ARC y se están recuperando desde disco/special.

Decisión: Si la tasa de fallos de metadatos es alta y la latencia duele, special ayuda. Si special existe, verifica que no esté saturado o mal dimensionado.

Task 5: Medir latencia a nivel vdev durante una “tormenta de metadatos”

cr0x@server:~$ sudo zpool iostat -v tank 1 3
                 capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        72.4T  36.6T    820    190  18.2M  4.5M
  raidz2-0  70.9T  38.1T    260    160   6.1M  4.0M
    sda         -      -     45     26   1.1M   700K
    sdb         -      -     43     25   1.0M   680K
    sdc         -      -     44     27   1.1M   710K
    sdd         -      -     42     26   1.0M   690K
    sde         -      -     44     28   1.1M   720K
    sdf         -      -     42     28   1.0M   720K
  special   1.52T  2.12T    560     30  12.1M   520K
    mirror-1     -      -    560     30  12.1M   520K
      nvme0n1p1  -      -    280     15   6.0M   260K
      nvme1n1p1  -      -    280     15   6.1M   260K

Significado: Las lecturas están golpeando mucho a special. Eso es esperado si hay metadatos/bloques pequeños allí.

Decisión: Si special está haciendo el trabajo y la latencia es buena, estás ganando. Si special está al límite y lento, has movido el cuello de botella a los SSDs.

Task 6: Comprobar salud del vdev especial y contadores de errores

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 07:21:10 with 0 errors on Sun Dec 22 03:10:11 2025
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
        ...
        special
          mirror-1    ONLINE       0     0     0
            nvme0n1p1 ONLINE       0     0     0
            nvme1n1p1 ONLINE       0     0     0

errors: No known data errors

Significado: Limpio. Si ves errores en special, trátalo como un incidente de fiabilidad urgente, no como un “problema de rendimiento”.

Decisión: Reemplaza dispositivos special que fallen inmediatamente. Un mirror special degradado es una cuenta atrás hacia la caída de la pool.

Task 7: Identificar si los metadatos saturan igualmente los vdevs principales (encolamiento)

cr0x@server:~$ iostat -x 1 2
Linux 6.6.0 (server) 	12/26/2025 	_x86_64_	(32 CPU)

Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
sda              35.0  22.0  1100.0  680.0  28.5   3.2   98.0
sdb              34.0  23.0  1050.0  690.0  27.8   3.1   97.5
nvme0n1          290.0  18.0  6200.0  260.0   1.1   0.3   22.0
nvme1n1          295.0  17.0  6300.0  260.0   1.0   0.3   21.0

Significado: Los HDDs están cerca del 100% de utilización con alto await, mientras NVMe tiene margen. O bien los metadatos siguen golpeando HDDs,
o la carga es intensiva en datos.

Decisión: Si special existe, verifica special_small_blocks y confirma la colocación de metadatos. Si no, planifica special o reduce el churn de metadatos.

Task 8: Verificar ashift y alineación de sectores en dispositivos special

cr0x@server:~$ sudo zdb -C tank | sed -n '1,80p'
MOS Configuration:
        version: 5000
        name: 'tank'
        vdev_children: 2
        vdev_tree:
            type: 'root'
            id: 0
            guid: 1234567890
            children[0]:
                type: 'raidz'
                ashift: 12
                ...
            children[1]:
                type: 'mirror'
                ashift: 12
                is_special: 1
                ...

Significado: ashift: 12 (sectores 4K) en special. Bien. Un ashift incorrecto puede desperdiciar espacio y dañar el rendimiento.

Decisión: Si ashift está mal, no puedes “tunear” para solucionarlo. Planifica una migración o reconstrucción para corregirlo.

Task 9: Comprobar cuán lleno está special (y actuar antes de que duela)

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag tank
NAME  SIZE   ALLOC  FREE   CAP  FRAG
tank  109T   72.4T  36.6T  66%  18%

Significado: Esto es a nivel de pool. No muestra llenado de special por sí mismo; usa zpool list -v como en la Task 2.

Decisión: Si la clase special se acerca al ~70–80% usado, planifica expansión temprano. No esperes a “está lleno” porque entonces tus opciones se vuelven estúpidas.

Task 10: Ver qué datasets son intensivos en metadatos (conteo de snapshots como pista)

cr0x@server:~$ sudo zfs list -t snapshot -o name -S creation tank/projects | head
NAME
tank/projects@auto-2025-12-26-0000
tank/projects@auto-2025-12-25-0000
tank/projects@auto-2025-12-24-0000
tank/projects@auto-2025-12-23-0000
tank/projects@auto-2025-12-22-0000
tank/projects@auto-2025-12-21-0000
tank/projects@auto-2025-12-20-0000
tank/projects@auto-2025-12-19-0000
tank/projects@auto-2025-12-18-0000

Significado: El volumen de snapshots es un multiplicador de metadatos. Más snapshots a menudo significa más coste de recorrido de metadatos.

Decisión: Si las tormentas de metadatos coinciden con churn de snapshots, ajusta la retención, el calendario o mueve la presión de metadatos de ese dataset a special.

Task 11: Comprobar impacto de scrub/resilver en special

cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 01:20:44 2025
        9.21T scanned at 1.05G/s, 1.90T issued at 222M/s, 72.4T total
        0B repaired, 2.62% done, 3 days 17:12:00 to go

Significado: El scrub recorre metadatos extensamente. Si tu special es el hogar de metadatos, el comportamiento y la latencia del scrub pueden cambiar (a menudo para mejor).

Decisión: Si el scrub aplasta la latencia de producción, prográmalo fuera de horas punta, limita su impacto (según plataforma) y asegúrate de que los mirrors special no estén infra-provisionados.

Task 12: Confirmar que tu “capa rápida” no se está usando como amplificador de escrituras

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'percentage|data units|media|error'
Percentage Used:                    7%
Data Units Written:                 18,442,119
Data Units Read:                    21,104,553
Media and Data Integrity Errors:    0
Error Information Log Entries:      0

Significado: El desgaste es medible. El churn de metadatos más datos de bloques pequeños puede consumir la endurance de SSDs consumer.

Decisión: Si “Percentage Used” sube rápido, cambia la clase de SSD, reduce el churn de metadatos o deja de empujar bloques pequeños a special.

Task 13: Validar qué hay realmente en special (inferencias de alto nivel vía asignación)

cr0x@server:~$ sudo zfs get -r -o name,property,value special_small_blocks tank | head -n 12
NAME                 PROPERTY              VALUE
tank                 special_small_blocks  0
tank/projects        special_small_blocks  32K
tank/vm              special_small_blocks  0
tank/backups         special_small_blocks  0
tank/containers      special_small_blocks  16K

Significado: Solo algunos datasets envían bloques pequeños a special. Eso es sano: uso dirigido en lugar de apostar pool-wide.

Decisión: Manténlo dirigido. Si todo está en 128K “por rendimiento”, estás a punto de construir un vdev special muy caro.

Task 14: Detectar comportamiento de la aplicación impulsado por metadatos (pista a nivel syscall)

cr0x@server:~$ sudo strace -f -tt -p $(pgrep -n rsync) -e trace=newfstatat,getdents64,openat -c
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 58.41    0.723601          12     59041       112 newfstatat
 31.22    0.386926          14     26874           getdents64
 10.37    0.128504          10     12245        45 openat
------ ----------- ----------- --------- --------- ----------------
100.00    1.238?                   98160       157 total

Significado: La app pasa la mayoría de llamadas en stat y enumeración de directorios. Eso son metadatos. Tu cuello de botella probablemente sea I/O de metadatos y latencia.

Decisión: Prioriza vdev special y ajuste de metadatos sobre “más discos” o “recordsize más grande”. La carga no pide ancho de banda.

Guion rápido de diagnóstico

Cuando alguien dice “el almacenamiento está lento”, no tienes tiempo para danza interpretativa. Necesitas un camino de triaje rápido que reduzca el cuello de botella
a: ARC, vdev special, vdevs principales, CPU o la aplicación haciendo algo desafortunado.

Primero: determina si está dominado por metadatos

• Comprueba patrones de syscalls (muestreo con strace) y descripción de la carga: muchas stat(), readdir(), listado de snapshots, escaneos.
• Revisa fallos de ARC (Task 4). Las tasas de fallo de metadatos son la señal.
• Revisa throughput vs latencia: MB/s bajos con IOPS altos suele ser metadatos o lecturas aleatorias pequeñas.

Segundo: identifica qué clase de vdev está sirviendo lecturas

• Usa zpool iostat -v (Task 5) durante la ralentización.
• Si las lecturas golpean special, confirma latencia y salud del SSD.
• Si las lecturas golpean HDDs, o los metadatos no están en special (o bloques previos no se reescribieron), o la carga es intensiva en datos.

Tercero: decide si estás limitado por presión de capacidad, encolamiento o configuración

• Comprueba asignación y capacidad de special (Task 2). Un special demasiado lleno es un precipicio de rendimiento.
• Revisa encolamiento de dispositivos (iostat -x, Task 7). Alto await en SSD sugiere saturación o contención.
• Verifica palancas del dataset (special_small_blocks, recordsize, compression) (Task 3).
• Comprueba si hay un scrub/resilver en curso (Task 11).

La salida de este guion debería ser una sola frase que puedas decir en Slack sin que te asen:
“Estamos limitados por fallos de metadatos y las lecturas están golpeando HDDs; special no está llevando metadatos para este dataset”
o
“Special está saturado y al 85% usado; necesitamos expandirlo y dejar de empujar bloques de 32K allí para ese trabajo de backup.”

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

1) “Añadimos special y nada se aceleró.”

Síntomas: El recorrido de directorios sigue lento; los HDDs muestran presión de lectura aleatoria; special muestra poca actividad de lectura.

Causa raíz: Los bloques de metadatos/datos existentes no se movieron. Special afecta nuevas asignaciones; los bloques antiguos permanecen donde se escribieron.

Solución: Para datasets donde importa, reescribe datos (por ejemplo, send/receive a un dataset nuevo, o copia-then-swap) para que metadatos/bloques pequeños se reasignen a special.

2) “Special está lleno y ahora todo se siente embrujado.”

Síntomas: Picos de latencia, rarezas en la asignación, rendimiento impredecible; alertas sobre capacidad.

Causa raíz: Vdev special subdimensionado, a menudo combinado con ajustes agresivos de special_small_blocks.

Solución: Añadir mirrors a special (expandir la clase de asignación) o migrar datos a una pool más grande. Reducir special_small_blocks en datasets que no lo necesiten.

3) “Usamos un único SSD ‘enterprise’ para special. Falló. Ahora aprendemos procedimientos de restauración.”

Síntomas: Pool ha fallado o no se importa; falta dispositivo special; pánico.

Causa raíz: Sin redundancia para una clase de vdev que almacena bloques requeridos.

Solución: Siempre espeja special. Si ya está roto, restaura desde backup o intenta recuperación profesional—no esperes milagros.

4) “Pusimos special_small_blocks demasiado alto y construimos por accidente una pool toda SSD cara.”

Síntomas: La asignación de special sube rápido; el desgaste de SSD aumenta; los HDDs están inusualmente inactivos; las reuniones de presupuesto se vuelven tensas.

Causa raíz: Umbral ajustado cerca del recordsize (o la carga escribe muchos bloques pequeños), por lo que la mayoría de datos aterrizan en special.

Solución: Reduce el umbral por dataset, y migra/reescribe si necesitas sacar datos existentes de special. Monitoriza llenado de special y endurance de SSD.

5) “El rendimiento mejoró, luego se hundió durante el scrub.”

Síntomas: Picos de latencia e IO wait durante el scrub; timeouts de aplicaciones; special muestra intensa actividad de lectura.

Causa raíz: El scrub es intensivo en metadatos; special es ahora la ruta caliente y puede estar infra-provisionado, o el scrub coincide con horas pico.

Solución: Programa scrubs fuera de pico, ajusta comportamiento de scrub donde sea posible y asegúrate de que los mirrors special tengan suficiente IOPS y endurance.

6) “Pensamos que special reemplaza SLOG.”

Síntomas: Rendimiento de escrituras síncronas en NFS/VM sigue mal; cargas fsync-heavy sin cambio.

Causa raíz: Vdev special apunta a metadatos/bloques pequeños. SLOG (log separado) acelera escrituras síncronas al hospedar el ZIL.

Solución: Añade un dispositivo SLOG apropiado (espejado para cargas serias) y verifica el comportamiento de sync. Mantén roles separados.

Tres mini-historias corporativas desde el terreno

Incidente causado por una suposición errónea: “Es una caché, ¿no?”

Una empresa mediana corría una pool ZFS para directorios home y artefactos de CI. Habían oído que “vdev especial hace rápidos los metadatos” y
compraron una sola NVMe de gama alta. La agregaron como special. El rendimiento mejoró de inmediato: los listados de directorios dejaron de fallar,
los escaneos de CI fueron más rápidos y todos celebraron.

Meses después, la NVMe empezó a lanzar errores de media. El sistema siguió funcionando porque el dispositivo no murió de golpe; solo se volvió raro.
Aparecieron errores de checksum ocasionales, luego más. Alguien lo trató como “corrupción de caché” y programó un reemplazo “en la próxima ventana de mantenimiento”.

La ventana de reemplazo llegó después de que el dispositivo desapareciera completamente. La pool no se pudo importar limpiamente. El “acelerador de metadatos” había
estado alojando metadatos requeridos. Sus vdevs de datos estaban bien; simplemente no podían recorrer las estructuras del sistema de archivos sin los bloques faltantes.

La recuperación fue exactamente tan divertida como te imaginas: restaurar desde backups, rehidratar artefactos de CI, reconstruir máquinas de desarrolladores, responder preguntas
incómodas sobre por qué un único SSD era punto único de fallo. La acción postmortem no fue “tener cuidado”, fue “espejar special o no lo uses”.

Optimización que salió mal: el ajuste “turbo” de special_small_blocks

Otra organización corría una carga mixta: repositorios de código, registros de contenedores e imágenes de VM. Desplegaron un vdev special espejado y lograron
una mejora sólida en tareas pesadas en metadatos. Luego alguien decidió “rematar el trabajo” y puso special_small_blocks=128K en algunos datasets porque “casi todo I/O es pequeño de todos modos”.

Al principio se veía bien. Las gráficas de latencia mejoraron. El equipo declaró la victoria y siguió adelante.
El problema apareció lentamente: la asignación de special subió más rápido de lo esperado y los indicadores de desgaste en los SSDs aumentaron de forma que no coincidía con su modelo mental.

El retroceso fue sutil: los datasets tenían recordsize=128K y una carga que reescribía archivos frecuentemente.
Habían creado efectivamente una capa SSD que alojaba no solo metadatos, sino una gran fracción de bloques de datos. El vdev special se convirtió en la nueva limitación de capacidad.
Luego se convirtió en el nuevo cuello de botella de rendimiento, porque hacía tanto metadatos como mucho I/O de datos.

La solución fue dolorosa pero clara: bajaron special_small_blocks a 16K para los datasets que se beneficiaban, lo dejaron en 0 para el resto, y migraron los datasets afectados
vía send/receive para reasignar bloques con sensatez. Costó tiempo, pero reemplazó un desastre incipiente por un sistema estable.

Práctica aburrida pero correcta que salvó el día: presupuestos de capacidad y desgaste

Una firma financiera usaba ZFS para logs analíticos y archivos de cumplimiento. Fueron conservadores: vdev special espejado, special_small_blocks conservador solo en algunos datasets de “archivos diminutos”,
scrubs semanales y una regla de monitorización estricta: alertar al 60% y 70% uso en special, además de umbrales de desgaste de SSD.

Un trimestre, una nueva versión de aplicación aumentó dramáticamente el número de archivos. Nada obvio: no mucho aumento en bytes totales, solo una avalancha de objetos pequeños y snapshots.
La pool principal todavía tenía espacio libre. Pero la asignación en special subió semana tras semana.

Porque vigilaban special por separado, lo detectaron temprano. Añadieron otro par de vdevs special espejados durante una ventana de cambio normal y ajustaron la retención de un calendario de snapshots.
Sin caída, sin drama, sin “por qué la pool está offline”.

Lo más impresionante es que nadie escribió un hilo heroico en Slack sobre ello. Ese es el punto. Operaciones debe ser aburrido. Esto es como compras aburridas: presupuestos, umbrales y la negativa a tratar almacenamiento crítico como un experimento.

Listas de verificación / plan paso a paso

Paso a paso: decidir si necesitas un vdev special

1. Caracteriza la carga: ¿está dominada por enumeración de archivos, stats, snapshots, archivos diminutos o búsquedas dedup?
2. Mide el comportamiento de ARC: ¿son significativos los fallos de metadatos durante la ralentización?
3. Mide encolamiento de dispositivos: ¿están los HDDs saturados con latencia de lectura aleatoria mientras el throughput es bajo?
4. Confirma que no persigues el cuello de botella equivocado: compresión con CPU, escrituras sync, o app monohilo.
5. Decide el alcance: aceleración de metadatos a nivel de pool vs aceleración de bloques pequeños por dataset.

Paso a paso: implementar vdev special de forma segura

1. Elige dispositivos: SSD/NVMe espejados con endurance apropiada para churn de metadatos.
2. Planifica redundancia: mirror mínimo; considera política de hot spare según tu contexto operativo.
3. Añade vdev special: valida con zpool status y zpool list -v.
4. Mantén special_small_blocks en 0 inicialmente: consigue primero la ganancia “solo metadatos”.
5. Mide de nuevo: verifica que las lecturas se desplacen y la latencia mejore.
6. Activa special_small_blocks selectivamente: empieza pequeño (16K/32K), solo en datasets con dolor por archivos pequeños.
7. Documenta: propiedades del dataset y la razón en tu registro de cambios.

Paso a paso: evitar precipicios de capacidad

1. Monitorea la asignación de special usando zpool list -v.
2. Alerta temprano: trata 70% como “planifica expansión”, no como “pánico”.
3. Vigila desgaste de SSD: métricas SMART y logs de errores.
4. Sé honesto sobre snapshots: el crecimiento de snapshots es crecimiento de metadatos; fija retención que puedas permitirte.
5. Tener un plan de migración: si debes cambiar la colocación significativamente, planifica send/receive o reescritura controlada.

Preguntas frecuentes

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

No. L2ARC es una caché de lectura y puede perderse sin perder la pool. Vdev special almacena bloques reales (metadatos y opcionalmente datos pequeños).
Pierdes eso y puedes perder la pool.

2) ¿Añadir un vdev special mueve metadatos existentes automáticamente?

En general, no. Afecta a nuevas asignaciones. Los bloques existentes permanecen donde están a menos que reescribas/migres datos para que ZFS asigne de nuevo.

3) ¿Puedo usar un único SSD para special si es “enterprise grade”?

Puedes. También puedes ejecutar producción sin backups. En ambos casos, eliges drama. Espeja el vdev special.

4) ¿Cuál es un valor inicial seguro para special_small_blocks?

Empieza en 0 (solo metadatos). Si tienes una carga probada de archivos pequeños, prueba 16K o 32K en ese dataset, y luego vigila asignación de special y desgaste de SSD.

5) ¿En qué se diferencia SLOG de vdev special?

SLOG acelera escrituras síncronas al alojar el log de intención ZIL. Vdev special acelera lecturas/escrituras de metadatos y opcionalmente bloques pequeños.
Resuelven problemas distintos y a menudo se usan juntos en entornos serios.

6) ¿El vdev special hará que los scrubs sean más rápidos?

A menudo mejora el comportamiento del scrub porque los scrubs leen metadatos intensivamente. Pero si tu special está infra-provisionado o saturado, el scrub puede competir con lecturas de producción en los mismos SSDs.

7) ¿Puede ayudar special vdev con dedup?

Puede ayudar porque las búsquedas del DDT son tipo metadatos y sensibles a latencia. Pero dedup sigue dominado por necesidades de memoria y comportamiento de lookup.
Special no sustituye tener suficiente RAM y un diseño de dedup correcto.

8) ¿Qué pasa si special se llena?

Mejor escenario: el rendimiento se degrada y la asignación se comporta de forma diferente mientras ZFS intenta lidiar. Peor escenario: fallos de asignación y caos operativo.
Trata la capacidad de special como un recurso de primera clase con alertas tempranas y plan de expansión.

9) ¿Necesito vdev special en una pool totalmente NVMe?

A veces aún es útil, pero la ganancia es menor porque metadatos y datos ya tienen baja latencia. Puede ayudar a aislar metadatos de lecturas masivas, pero mide primero—no lo uses por imitación.

10) ¿Cómo sé si mi ralentización es “metadatos” versus “datos”?

Busca throughput bajo con alto número de operaciones, altos fallos de metadatos en ARC y perfiles de syscalls dominados por stat() y lecturas de directorio.
Luego confirma qué clase de vdev está sirviendo lecturas vía zpool iostat -v.

Conclusión: próximos pasos prácticos

El vdev special es una de las raras características de ZFS que puede sentirse como hacer trampa: de repente el sistema de archivos deja de discutir con la física durante
tormentas de metadatos. Pero solo es trampa si pagas el precio a priori: redundancia, dimensionamiento y disciplina con
special_small_blocks.

Próximos pasos que mejoran sistemas reales de forma fiable:

• Demuestra que son metadatos con datos de fallos de ARC y iostat a nivel de vdev durante la ventana del incidente.
• Si despliegas special, espejalo y móntoréalo como si pudiera tumbarte la pool—porque puede.
• Empieza solo metadatos, luego habilita selectivamente colocación de bloques pequeños donde la carga lo justifique.
• Presupuesta el crecimiento: snapshots, conteo de archivos y churn expandirán metadatos con el tiempo.
• Manténlo aburrido: alertas en umbrales sensatos, scrubs programados, desgaste controlado y cambios documentados.

Si haces esto bien, pasarás menos tiempo explicando por qué “ls” está lento y más tiempo haciendo el tipo de trabajo que te promueve:
sistemas predecibles, incidentes predecibles, recuperación predecible.