ZFS: cuándo añadir un vdev especial (y cuándo es mala idea)

Qué es realmente un vdev especial (y qué no es)

En ZFS, un vdev especial es una clase de vdev dedicada donde ZFS puede almacenar metadatos (y opcionalmente bloques de datos pequeños)
en dispositivos más rápidos—normalmente SSD o NVMe—mientras que los datos principales de la pool permanecen en discos más lentos y de mayor capacidad.
Piensa: directorios, bloques indirectos, dnodes, punteros de bloque, mapas de espacio, cierta metadata de asignación y (según configuración) bloques de ficheros pequeños.

El objetivo no es ancho de banda mágico. Es la latencia y las IOPS donde ZFS las necesita más:
cargas de trabajo con mucho metadata, con muchas instantáneas, muchos ficheros pequeños, mucho recorrido del sistema de archivos y almacenamiento de VM con IO aleatorio pequeño.

Qué no es

• No es L2ARC. L2ARC es una caché de lectura y puede eliminarse en cualquier momento sin perder la pool. El vdev especial alberga bloques autoritativos.
• No es un SLOG. Un SLOG es para el registro de intención de escritura síncrona (ZIL). Acelera escrituras síncronas pero no almacena metadata normal permanentemente.
• No es un “botón de rendimiento gratis”. Estás moviendo estructuras críticas a una clase de dispositivo que debe ser fiable y redundante.

Aquí va la verdad incómoda: si añades un vdev especial y muere, puedes perder la pool. No “algo de metadata.” La pool.
Por eso el diseño de vdev especial está más cerca del diseño del dispositivo de arranque que del diseño de un dispositivo de caché.

Primera broma corta: Un vdev especial es como darle espresso a ZFS—genial hasta que te das cuenta de que la cafetería solo tiene una toma de corriente.

Datos interesantes y contexto histórico

• ZFS nació a mediados de los 2000 en Sun Microsystems con un enfoque implacable en la integridad de extremo a extremo: checksums, copy-on-write, autocuración.
  Ese diseño convierte la corrección de metadatos en una prioridad absoluta—así que el rendimiento de metadatos importa.
• Los vdevs especiales llegaron después (no en las primeras versiones de ZFS) como respuesta a un problema moderno previsible:
  los discos giratorios crecieron mucho, pero sus IOPS aleatorias no lo hicieron.
• “Metadata-only en SSD” existía antes del vdev especial de ZFS como idea arquitectónica; sistemas de archivos y pilas de almacenamiento han separado durante tiempo
  las rutas de metadata caliente de los datos fríos. ZFS simplemente lo hizo administrativamente limpio.
• La opción de “small blocks” cambió las reglas. Una vez que permites bloques de datos pequeños en el vdev especial,
  no solo aceleras los recorridos de directorio—mueves datos de usuario reales a esos dispositivos.
• Los dnodes se volvieron más configurables. Características como dnodes más grandes mejoraron la eficiencia de metadata (especialmente para atributos extendidos, ACLs y ficheros pequeños),
  pero también aumentaron la importancia de dónde viven los dnodes—el vdev especial puede ayudar mucho aquí.
• Operaciones con muchas instantáneas son operaciones intensivas en metadata. Clones, listar snapshots, enumeración de datasets y planificación de send/receive
  golpean metadata y bloques indirectos en patrones que adoran baja latencia.
• NVMe no solo añadió velocidad; cambió los modos de fallo. Los dispositivos rápidos suelen ser menos indulgentes: fallos de firmware, estrangulamiento térmico, pérdida de energía inesperada
  y muerte súbita sin las advertencias “corteses” que obtienes de SMART en HDD.
• Las matrices empresariales hacen lo mismo en silencio usando tiering y caching de metadata. El vdev especial es la versión DIY, con consecuencias DIY.

Una cita operativa (idea parafraseada): “La esperanza no es una estrategia.” — atribuida a menudo a ingenieros en culturas de fiabilidad; el punto es:
diseña el vdev especial como si esperases que falle.

Cuándo un vdev especial es la jugada correcta

1) Tu carga está limitada por metadata, no por ancho de banda

Si tu pool mueve muchos MB/s pero se atasca en operaciones—listados de directorios, creación de ficheros, tormentas de chmod/chown, gestión de snapshots—
a menudo estás limitado por lecturas/escrituras aleatorias de metadata. Los HDD son malos en esto. No “un poco peor.” Órdenes de magnitud peor.

El vdev especial ayuda porque ZFS ya no tiene que leer metadata desde la capa más lenta. Puede mantener la metadata en dispositivos de baja latencia
y reducir el número de seeks aleatorios en discos giratorios. Sigues teniendo HDD para lecturas/escrituras secuenciales de gran tamaño, que es lo suyo.

2) Tienes muchos ficheros pequeños (o pequeños bloques) y puedes restringir qué se mueve

Con la propiedad special_small_blocks, ZFS puede colocar datos cuyo tamaño sea menor que un umbral en el vdev especial.
Esto puede transformar el rendimiento para:

• Imágenes de VM con IO aleatorio pequeño (especialmente con volblocksize pequeño)
• Árboles de código fuente, repositorios de paquetes, capas de contenedores
• Cargas tipo Maildir (si te gusta sufrir, pero sí)
• Shares NFS/SMB con metadata y ficheros pequeños intensivos

Pero es un arma de doble filo. Si fijas el umbral demasiado alto migrarás silenciosamente una gran fracción de datos de usuario al vdev especial.
Entonces no estás “acelerando metadata,” estás “construyendo una segunda pool que no dimensionaste como una pool.”

3) Snapshots, clones y enumeración de datasets son lentos

Las operaciones con snapshots son una fiesta de punteros. Listar snapshots, mantenerlos, calcular espacio usado y planificar replicación
pueden castigar las rutas de metadata. Si esas tareas dominan tu dolor administrativo, el vdev especial es una palanca seria.

4) Necesitas más latencia rápida que más ancho de banda

En producción, los usuarios no se quejan de que tu pool haga 1.5 GB/s en una prueba secuencial. Se quejan de que “abrir una carpeta tarda 10 segundos.”
El vdev especial es para ese tipo de vergüenza.

5) Puedes permitirte redundancia y cuidado operativo

Si no estás dispuesto a espejar el vdev especial (o usar redundancia equivalente) y a monitorizarlo como un halcón, no lo hagas.
El vdev especial no es para “encontré dos SSD de consumo en un cajón.”

Cuándo es mala idea (y cómo falla)

Crees que puedes “probarlo y quitarlo después”

Eliminar vdevs especiales ha sido históricamente limitado y operativamente delicado. Incluso donde la eliminación existe, no siempre es viable,
no siempre es rápida y no siempre está soportada como querrías bajo presión. Planea como si fuera permanente.

No puedes espejarlo

Un vdev especial de un solo dispositivo es una responsabilidad para toda la pool. Si contiene metadata, la pool depende de él. Lo pierdes y puedes perder la pool.
Si también contiene small blocks, definitivamente estás jugando con munición en vivo.

Estás arreglando el cuello de botella equivocado

Si tu problema real es:

• escrituras síncronas sin un SLOG apropiado
• poca RAM / thrashing del ARC
• recordsize/volblocksize inadecuado para la carga
• CPU sobrecargada haciendo checksums/compression
• problemas de red en NFS/SMB

…un vdev especial no te salvará. Puede incluso enmascarar el problema el tiempo suficiente para empeorarlo después.

Estás usando SSDs/NVMe cuestionables o una ruta de alimentación dudosa

Los dispositivos del vdev especial son golpeados con IO aleatorio pequeño. Además se vuelven críticos para la integridad de la pool.
Los SSDs de consumo con protección contra pérdida de energía débil y firmware optimista no son una buena idea.

Tu pool ya está al límite de capacidad

La llenura del vdev especial no es un fallo suave. Si se llena, las asignaciones de metadata pueden fallar de maneras que son emocionantes en el sentido de “canal de incidentes”.
Si estás ejecutando la pool principal al 85–90% y esperando lo mejor, no estás emocionalmente preparado para un vdev especial.

Segunda broma corta: Añadir un vdev especial no espejado a una pool de producción es como hacer malabares con cuchillos para impresionar a tu gato. El gato sigue sin impresionarse.

Reglas de diseño: redundancia, dimensionamiento y disposición

Regla 1: Espeja el vdev especial (como mínimo)

Trata al vdev especial como “parte de la columna vertebral de la pool.” Espejalo. Si quieres ser aún más conservador, usa espejo 3-vías,
especialmente para pools críticas y con cargas metadata brutales.

RAIDZ para vdev especial es posible, pero los espejos son la elección más común porque dan buen rendimiento de lectura aleatoria
y características de fallo simples. Quieres IOPS y predictibilidad.

Regla 2: Dimensiónalo para el futuro, no para la demo

Sub-dimensionar es la falla clásica. La metadata crece con el número de ficheros, snapshots, clones y patrones de fragmentación—no solo con el tamaño bruto de datos.
Si activas bloques pequeños, el crecimiento se acelera y depende de la carga.

Guía práctica de dimensionamiento (opinada, porque la pediste):

• Vdev especial solo para metadata: empieza pensando en un bajo porcentaje de dígitos únicos del tamaño lógico de la pool, pero valida con números reales.
  Si tu carga es “millones de ficheros pequeños y muchas snapshots,” planifica más grande.
• Metadata + small blocks: plánfalo como una capa real, no como una caché. Si pones special_small_blocks por encima de 0,
  asume que datos de usuario vivirán allí. Dimensiona en consecuencia.
• Mantén margen. Operativamente, evita empujar el vdev especial por encima de ~70–80% en estado estable. No es una ley física; es una ley humana.

Regla 3: Elige dispositivos como si los compraras pensando en fallos, no en benchmarks

Lo que quieres:

• SSD/NVMe empresarial con protección contra pérdida de energía
• latencia consistente bajo carga de escritura
• historial de firmware fiable
• resistencia suficiente para escrituras aleatorias sostenidas

Lo que no quieres:

• NVMe de consumo misterioso que se estrangula térmicamente bajo carga real
• SSDs baratos con pausas dramáticas por garbage collection
• dispositivos que mienten convincentemente vía SMART hasta que dejan de hacerlo

Regla 4: Sé deliberado con special_small_blocks

special_small_blocks es una propiedad de dataset. Eso es bueno: puedes acotarlo.
Enciéndelo para datasets que se beneficien: volúmenes de VM, almacenes de contenedores, shares intensivos en metadata.
Déjalo apagado para archivos grandes donde solo malgasta flash caro en datos fríos.

También entiende la permanencia: los bloques existentes generalmente no se mueven solo porque cambiaste una propiedad.
Las escrituras nuevas siguen la política nueva. Esto importa para migraciones y para “¿por qué no arregló nada?”.

Regla 5: Monitoriza la salud y llenado del vdev especial como si fuera crítico (porque lo es)

Alerta sobre:

• errores de dispositivo, sectores reasignados/errores de medios, errores de checksum
• picos de latencia inusuales
• tendencia rápida de asignación en el vdev especial
• operaciones de metadata de pool que vuelven a hacerse lentas (sucede)

Tareas prácticas: comandos, qué significa la salida y qué decisión tomar

El punto de decidir sobre un vdev especial es la evidencia. Abajo hay tareas prácticas que puedes ejecutar hoy. Cada una tiene:
un comando, un fragmento realista de salida, qué significa y la decisión que tomas.

Task 1: Identificar si ya existe un vdev especial

cr0x@server:~$ 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
        special
          mirror-1                  ONLINE       0     0     0
            nvme0n1                 ONLINE       0     0     0
            nvme1n1                 ONLINE       0     0     0

errors: No known data errors

Significado: La pool ya tiene una clase vdev special, espejada. Bien. Tu siguiente pregunta es “¿qué está almacenando?”

Decisión: Si existe y no está espejado, trátalo como proyecto prioritario de reducción de riesgo.
Si no existe, procede a validar que la metadata es tu cuello de botella antes de añadir uno.

Task 2: Revisar saturación de I/O de la pool vs síntomas de latencia

cr0x@server:~$ zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        42.3T  29.1T    210    180   28.1M  35.7M
  raidz2-0                  42.3T  29.1T    210    180   28.1M  35.7M
    sda                         -      -     32     27   3.9M   4.4M
    sdb                         -      -     34     28   4.0M   4.5M
    sdc                         -      -     36     31   4.1M   4.6M
    sdd                         -      -     33     29   4.0M   4.5M
--------------------------  -----  -----  -----  -----  -----  -----

Significado: El ancho de banda es modesto. Las operaciones son moderadas. Si los usuarios aún ven “listados lentos”, probablemente sea latencia/metadata, no saturación de throughput.

Decisión: Continúa investigando la presión de metadata. Un vdev especial puede ayudar.
Si el ancho de banda u ops están al máximo, puede que necesites más vdevs, un layout distinto o arreglar el comportamiento de escrituras síncronas.

Task 3: Ver propiedades de dataset relacionadas con el comportamiento especial

cr0x@server:~$ zfs get -r special_small_blocks,recordsize,atime,compression tank/data
NAME        PROPERTY              VALUE                  SOURCE
tank/data   special_small_blocks  0                      default
tank/data   recordsize            128K                   default
tank/data   atime                 off                    local
tank/data   compression           zstd                   local

Significado: Los small blocks no se están redirigiendo al vdev especial para este dataset. Solo metadata iría allí (si existe un vdev especial).

Decisión: Si quieres acelerar IO aleatorio pequeño para este dataset (por ejemplo, almacenamiento de VM),
considera habilitar special_small_blocks con cuidado y solo para los datasets que lo benefician.

Task 4: Revisar tamaño y presión del ARC (la metadata suele vivir aquí primero)

cr0x@server:~$ arc_summary | head -n 18
ARC Summary:
    Memory Throttle Count:                    0
    ARC Size:                            62.1 GiB
    Target Size:                         64.0 GiB
    Min Size (Hard Limit):               16.0 GiB
    Max Size (Hard Limit):               64.0 GiB

ARC Misc:
    Deleted:                                1.2 GiB
    Mutex Misses:                           0
    Evict Skips:                            0

ARC Efficiency:
    Cache Hit Ratio:                       86.3%

Significado: El ARC está sano y con buen hit rate. Si las operaciones de metadata siguen lentas, puede que el working set no quepa en ARC
o que tu cuello de botella sea la latencia del disco durante misses de caché.

Decisión: Si el ARC es pequeño respecto a la carga, añade RAM antes de añadir un vdev especial.
Si ARC está sano pero los misses son dolorosos en HDDs, el vdev especial se vuelve más atractivo.

Task 5: Inspeccionar comportamiento de caché metadata-vs-data (ejemplo Linux)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep 'hits|misses|mfu_hits|mru_hits|metadata|demand_data|demand_metadata' | head -n 12
hits                            4    123456789
misses                          4     19654321
demand_data_hits                4     62123456
demand_metadata_hits            4     51234567
demand_data_misses              4      9234567
demand_metadata_misses          4     10419754
mru_hits                        4     31234567
mfu_hits                        4     92222222

Significado: Los misses de metadata son significativos. Justo ahí es donde el vdev especial puede recortar la latencia de cola: cuando la metadata no está cacheada.

Decisión: Si los demand metadata misses son altos y correlacionan con latencia visible por usuarios, el vdev especial probablemente ayudará—después de verificar
que la pool no esté mal ajustada por otras razones.

Task 6: Confirmar asignación en el vdev especial (¿se está llenando?)

cr0x@server:~$ zfs list -o name,used,available,refer,mounted -r tank | head
NAME          USED  AVAIL  REFER  MOUNTED
tank         42.3T  29.1T   192K  yes
tank/data    31.8T  29.1T  31.8T  yes
tank/vm       8.9T  29.1T   8.9T  yes
tank/backup   1.6T  29.1T   1.6T  yes

Significado: Esto no muestra directamente uso del vdev especial. Para eso necesitas vistas de asignación a nivel de pool y a veces estadísticas de dispositivo.

Decisión: Continúa con zdb y chequeos a nivel de pool. Si no puedes cuantificar el crecimiento del vdev especial, estás volando a ciegas.

Task 7: Usar zpool list -v para ver espacio del special

cr0x@server:~$ zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        72.8T  42.3T  30.5T        -         -    18%    58%  1.00x  ONLINE  -
  raidz2-0  72.8T  42.3T  30.5T        -         -    18%    58%
  special   1.82T   612G  1.22T        -         -     9%    33%
    mirror-1 1.82T  612G  1.22T        -         -     9%    33%

Significado: La clase special tiene ~33% usado. Está bien. Si esto se acerca al 80–90%, te diriges hacia un incidente evitable.

Decisión: Si el uso de special está aumentando rápido, planifica expansión temprano (añadir otro vdev special espejado, según tu diseño).
No esperes a que sea “interesante.”

Task 8: Medir operaciones intensivas en metadata directamente

cr0x@server:~$ time ls -U tank/data/bigdir >/dev/null

real    0m8.412s
user    0m0.031s
sys     0m0.402s

Significado: ls tomó 8 segundos solo para enumerar entradas (descartando salida). Eso es latencia clásica de metadata.

Decisión: Correlaciona esto con la latencia de disco y estadísticas del ARC. Si se confirma, el vdev especial es candidato.
Si el listado es rápido pero las apps son lentas, tu cuello de botella está en otra parte.

Task 9: Revisar latencia de dispositivo a nivel OS (ejemplo Linux)

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              32.0    28.0   4096    4608   24.5   3.2    92.0
sdb              33.0    27.0   4120    4512   23.8   3.1    91.5
sdc              34.0    29.0   4180    4620   25.1   3.3    93.2
sdd              31.0    30.0   4012    4700   26.4   3.4    94.1
nvme0n1         120.0    80.0  15360    9216    0.6   0.1    12.0
nvme1n1         118.0    78.0  15040    9152    0.7   0.1    11.5

Significado: Los HDD muestran alto await y %util muy alto. Los NVMe tienen baja latencia y carga ligera.
Si la metadata está en HDDs, aquí viene tu dolor. Si la metadata ya está en special, esto sugiere que puede no estar siendo usada como se espera.

Decisión: Si la latencia de HDD se correlaciona con operaciones de metadata, mueve la metadata a special.
Si special existe pero los HDDs siguen sufriendo, investiga si la metadata realmente está aterrizando allí y si el ARC está thrashing.

Task 10: Verificar ashift y alineación de los dispositivos especiales

cr0x@server:~$ zdb -C tank | egrep 'vdev_tree|type:|path:|ashift' | head -n 30
        vdev_tree:
            type: 'root'
            type: 'raidz'
            ashift: 12
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'mirror'
            ashift: 12
            type: 'disk'
            path: '/dev/disk/by-id/nvme-SAMSUNG_MZ...'
            type: 'disk'
            path: '/dev/disk/by-id/nvme-SAMSUNG_MZ...'

Significado: ashift: 12 (sectores de 4K) es típico. Ashift mezclado o demasiado pequeño puede perjudicar rendimiento y resistencia.

Decisión: Si ashift está mal en dispositivos special (raro pero posible en migraciones), puede que necesites reconstruir ese vdev correctamente.
No ignores la alineación en dispositivos que recibirán IO aleatorio todo el día.

Task 11: Añadir un vdev especial espejado (la operación real)

cr0x@server:~$ sudo zpool add tank special mirror /dev/disk/by-id/nvme-INTEL_SSDPE2KX040T8-part1 /dev/disk/by-id/nvme-INTEL_SSDPE2KX040T8B-part1

cr0x@server:~$ zpool status 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
        special
          mirror-1                                        ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T8-part1                ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T8B-part1               ONLINE       0     0     0

errors: No known data errors

Significado: La clase special existe y está espejada. Las asignaciones de metadata empezarán a usarla.
La metadata existente no necesariamente se reubicará; esto mejora sobre todo las nuevas asignaciones y operaciones donde lecturas de metadata ahora están allí.

Decisión: A continuación, decide si habilitar special_small_blocks para datasets seleccionados.
También configura monitorización del uso y salud del special inmediatamente.

Task 12: Habilitar special_small_blocks para un dataset de VM (acotado e intencional)

cr0x@server:~$ sudo zfs set special_small_blocks=16K tank/vm

cr0x@server:~$ zfs get special_small_blocks tank/vm
NAME     PROPERTY              VALUE  SOURCE
tank/vm  special_small_blocks  16K    local

Significado: Nuevos bloques de datos ≤ 16K en tank/vm irán al vdev especial.
Eso a menudo se ajusta al patrón de IO aleatorio de VM mejor que lanzar todos los bloques allí.

Decisión: Si el uso de special empieza a crecer rápido, baja el umbral o limítalo a menos datasets.
Si la latencia de VM mejora sin que special se llene, has encontrado un buen compromiso.

Task 13: Validar la mejora con una prueba de metadata antes/después

cr0x@server:~$ time find tank/data/bigdir -maxdepth 2 -type f -print >/dev/null

real    0m14.227s
user    0m0.081s
sys     0m0.913s

Significado: Esta es una prueba de recorrido intensiva en metadata. Ejecútala antes y después de añadir el vdev especial (o cambiar propiedades).
El objetivo es evidencia direccional, no perfección.

Decisión: Si no mejora, probablemente no tenías un cuello de botella de metadata—o ARC ya lo absorbía—o el dataset no está usando special como esperabas.
Vuelve al diagnóstico.

Task 14: Revisar contadores de error del special y resultados de scrub

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Feb  4 02:00:26 2026
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
        special
          mirror-1                  ONLINE       0     0     0
            nvme0n1                 ONLINE       0     0     0
            nvme1n1                 ONLINE       0     0     0

errors: No known data errors

Significado: Un scrub limpio y cero errores es lo que quieres, especialmente en dispositivos special.
Unos pocos errores de checksum en special deberían disparar una preocupación real: estás corrompiendo el sistema nervioso de la pool.

Decisión: Si ves errores en special, reemplaza dispositivos agresivamente e investiga cableado/backplane/firmware.
No “monitorices un tiempo.” Ahí es donde terminas restaurando desde backup mientras te explicas con adultos.

Task 15: Confirmar comportamiento de escrituras síncronas (para no atribuir mal la latencia)

cr0x@server:~$ zfs get sync tank/vm
NAME     PROPERTY  VALUE  SOURCE
tank/vm  sync      standard  default

Significado: Las escrituras síncronas no están deshabilitadas por la fuerza. Si tu carga es NFS/VM con escrituras síncronas, un SLOG ausente o débil puede dominar la latencia.

Decisión: Si persigues latencia y tu carga hace muchas escrituras síncronas, evalúa el SLOG por separado.
No uses un vdev especial como substituto de un camino de escrituras síncronas correctamente diseñado.

Task 16: Revisar fragmentación y cómo afecta el churn de metadata

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,cap tank
NAME  SIZE  ALLOC  FREE  FRAG  CAP
tank  72.8T  42.3T  30.5T   18%   58%

Significado: Fragmentación moderada. Alta fragmentación puede aumentar la sobrecarga de metadata y la seekiness en HDDs.

Decisión: Si frag es muy alto y el rendimiento colapsa, el vdev especial puede ayudar pero puede estar tratando síntomas.
Considera reescribir/replicar datasets para recompactar y revisa las políticas de retención de snapshots.

Guía rápida de diagnóstico: encuentra el cuello de botella antes de comprar NVMe

Esta es la secuencia de “deja de discutir y obtén datos”. Ejecútala en orden. El objetivo es clasificar la ralentización en minutos, no días.

Primero: ¿Es latencia de metadata o algo más?

1. Ejecuta una prueba simple de metadata (time ls en un directorio enorme, o find con profundidad limitada). Si es lento, tienes un sospechoso.
2. Revisa la latencia de dispositivos en OS (iostat -x). Si el await de los HDD es alto mientras el throughput es modesto, grita “dolor por IO aleatorio.”
3. Revisa el hit ratio del ARC y los misses de metadata. Si los misses de metadata son significativos y correlacionan con los síntomas, estás en territorio de vdev especial.

Segundo: Confirma que ZFS no te está castigando por escrituras síncronas

1. Revisa la propiedad sync de los datasets.
2. Identifica la carga: NFS con sync, bases de datos, almacenamiento de VM, etc.
3. Busca alta latencia durante escrituras incluso cuando las lecturas están bien. Eso suele ser SLOG o comportamiento de flush del dispositivo subyacente.

Tercero: Valida capacidad/fragmentación y minas operativas

1. Capacidad de pool: si estás por encima de ~80%, arregla eso primero. ZFS bajo presión de capacidad puede comportarse mal.
2. Fragmentación: frag alta + snapshots pesadas puede hacer la metadata más cara.
3. Si ya tienes un vdev especial, revisa su utilización y errores. Un special enfermo puede parecer “rareza aleatoria de la pool.”

Punto de decisión

• Añadir vdev especial si: las ops de metadata son lentas, la latencia de HDD es alta durante esas ops y los misses de metadata del ARC son significativos.
• No añadir vdev especial si: el problema real es el camino de escrituras síncronas, hambre de ARC, CPU o red.

Tres micro-historias corporativas desde el terreno

Incidente: la suposición equivocada (“special es como caché, ¿verdad?”)

Una compañía mediana ejecutaba una pool ZFS que soportaba un sistema CI interno y un repositorio de artefactos. Las quejas de rendimiento eran constantes pero no catastróficas:
los checkouts de jobs eran lentos, las cachés de build se sentían “pegajosas” y las operaciones de directorio eran dolorosas en horas pico.
Un ingeniero propuso añadir un único “SSD rápido” como vdev especial para “cachear metadata.”

La suposición era simple y errónea: que special se comportaba como L2ARC—agradable de tener, seguro de perder. El cambio se hizo en una ventana de mantenimiento.
Mejoró el rendimiento percibido de inmediato. Ese bucle de retroalimentación positiva es peligroso; convence a todos de que el diseño era correcto.

Semanas después el SSD empezó a lanzar errores de medio. No murió de golpe; corrompió lecturas ocasionalmente y registró timeouts.
La pool comenzó a reportar errores de checksum. Luego los servicios empezaron a fallar de maneras poco obvias: accesos aleatorios a ficheros con error, resultados ENOENT extraños
y comportamientos “imposibles” durante operaciones de snapshot.

La recuperación fue fea pero educativa: tuvieron que tratarlo como un fallo que amenazaba la pool, reemplazar el dispositivo urgentemente
y luchar para validar réplicas. El postmortem no fue de culpas. Fue sobre semántica: special no es una caché.
Rediseñaron con un par espejado de SSDs empresariales y añadieron monitorización en contadores de error.

La lección duradera: mejoras de rendimiento que llegan rápido pueden ser el inicio de un desastre lento si tus suposiciones son erróneas.

Optimización que se volvió contra ellos: “subamos special_small_blocks y ganamos para siempre”

Otra organización hospedaba escritorios virtuales y un montón de servicios internos en ZFS. Añadieron un vdev especial espejado y luego se pusieron ambiciosos.
Alguien puso special_small_blocks a un valor grande en el dataset padre porque “el IO pequeño es lento y el flash es rápido.”
Sonó racional en una reunión. Las reuniones hacen eso.

Durante un mes, todos estuvieron felices. Las tormentas de arranque fueron menos dolorosas. La latencia de login mejoró. Los gráficos se veían mejor y la gente dejó de preguntar.
Luego empezaron a sonar las alarmas de capacidad—no en la pool principal, sino en el vdev special.
Fue subiendo lentamente porque más y más datos reales de usuario calificaron como “pequeños.”

El vdev special pasó de “capa de metadata” a “capa de datos caliente” sin que nadie lo admitiera. Una vez que se acercó a alta utilización,
las nuevas asignaciones se vieron constreñidas y el rendimiento se volvió raro: stalls repentinos, colas largas y algunos fallos de asignación durante ventanas ocupadas.
El equipo inicialmente culpó a ZFS, luego al hypervisor, luego a la red (por supuesto).

La solución no fue glamorosa. Bajaron special_small_blocks para la mayoría de datasets, lo dejaron solo para los volúmenes de VM que realmente se beneficiaban,
y expandieron la clase special con otro par espejado. También añadieron una política:
cualquier cambio en special_small_blocks requiere una proyección de capacidad y un plan de rollback.

La lección duradera: mover datos a dispositivos special es fácil. No moverlos de vuelta es la parte que pagas.

Práctica aburrida pero correcta que salvó el día: “espejamos, monitorizamos y practicamos”

Una compañía del sector financiero ejecutaba ZFS para un servicio de ficheros con churn intenso de metadata: millones de ficheros, uso intenso de ACLs y una estricta política de snapshots/replicación.
Su ingeniero de almacenamiento insistió en un vdev special espejado con NVMes empresariales, además de monitorización SMART, scrubs regulares y alertas sobre capacidad de special.
Nadie celebró ese plan. Así sabes que es bueno.

Meses después, uno de los NVMe del espejo special empezó a reportar errores de medio crecientes.
Las alertas saltaron temprano, antes de que la pool mostrara síntomas visibles para usuarios. Programaron un reemplazo acelerado.
Durante el reemplazo, la pool se mantuvo online; la redundancia hizo su trabajo; no se requirió heroísmo.

La revisión post-acción fue aburrida. Consistió en “las alertas funcionaron” y “el procedimiento concordó con la realidad.”
Ese es el mayor cumplido que puedes dar a una práctica operativa.

La lección duradera: el vdev special es seguro cuando lo tratas como infraestructura crítica, no como un accesorio de rendimiento.

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

1) Síntoma: La pool está ONLINE pero las apps ven ENOENT / errores de I/O aleatorios

Causa raíz: El vdev especial está degradado o devolviendo errores; lecturas de metadata fallan o están corruptas.

Solución: Revisa zpool status -v. Reemplaza dispositivos especiales fallando inmediatamente. Scrub. Investiga controlador/backplane/firmware.

2) Síntoma: Añadiste vdev special y nada se aceleró

Causa raíz: La carga no está limitada por metadata (o ARC ya lo oculta), o el dataset no genera metadata nueva en el camino caliente.

Solución: Reejecuta la guía rápida de diagnóstico. Revisa misses de metadata del ARC, await de HDD y dónde se gasta el tiempo (writes síncronas, red, CPU).

3) Síntoma: El vdev special se llena mucho más rápido de lo esperado

Causa raíz: special_small_blocks está habilitado demasiado ampliamente o con un valor muy alto, moviendo bloques de usuario a special.

Solución: Reduce/deshabilita special_small_blocks para datasets generales. Mantenlo solo donde esté justificado. Expande la capacidad de special antes de que llegue a crítico.

4) Síntoma: Después de habilitar special_small_blocks, la resistencia de NVMe da miedo

Causa raíz: Las escrituras de bloques pequeños son intensas; los dispositivos special están recibiendo carga de escritura real, no solo updates de metadata.

Solución: Reduce el umbral. Considera mover datasets con mucha escritura de vuelta a vdevs HDD o incrementa la capacidad espejada special con dispositivos de mayor resistencia.

5) Síntoma: Muy buen rendimiento durante semanas, luego picos repentinos de latencia cola

Causa raíz: Dispositivos special experimentando pausas de GC de firmware, estrangulamiento térmico o cercano a alta utilización causando contención de asignación.

Solución: Revisa temperaturas/latencia NVMe a nivel OS, la tendencia de capacidad del vdev special y considera otro tipo de SSD. Mantén uso de special en banda más segura.

6) Síntoma: “zfs list -t snapshot” es dolorosamente lento

Causa raíz: Recorrido intenso de metadata por snapshots en HDDs; misses de ARC para metadata; posiblemente conteos extremos de snapshots.

Solución: Aquí el vdev special ayuda. También racionaliza la retención de snapshots. Revisa tasas de misses de metadata y considera aumentar RAM.

7) Síntoma: Operaciones de metadata mejoraron, pero latencia de escritura de VM sigue mala

Causa raíz: El camino de escrituras síncronas domina (NFS sync, fsyncs de invitados) y no hay un SLOG apropiado o el flush subyacente es lento.

Solución: Diseña el SLOG apropiadamente (tema aparte), confirma settings de sync y mide la latencia de escritura específica. No culpes a la metadata por dolor de sync.

8) Síntoma: El espejo del vdev special muestra errores de checksum pero los discos “parecen bien”

Causa raíz: A menudo cableado, problemas de PCIe/backplane, inestabilidad de alimentación o bugs de controlador; no siempre la NAND en sí.

Solución: Cambia de ranuras, revisa firmware, revisa alimentación, ejecuta scrubs, reemplaza componentes sospechosos. Trata los errores de checksum como señal real, no ruido.

Listas de verificación / plan paso a paso

Paso a paso: decidir si añadir un vdev especial

1. Demuestra que es metadata.
   Ejecuta una prueba intensiva en metadata (ls/find), y correlaciónala con latencia de HDD (iostat -x) y misses de metadata del ARC.
2. Elimina cuellos de botella no metadata obvios.
   Revisa RAM/ARC, comportamiento de escrituras síncronas, CPU y red.
3. Elige el alcance.
   ¿Solo metadata? ¿O metadata + small blocks en datasets seleccionados? Por defecto metadata-only hasta tener razones.
4. Diseña la redundancia.
   Espejo (mínimo). Preferir SSD/NVMe empresariales. Planifica monitorización.
5. Dimensiona con margen.
   Estima crecimiento con snapshots y conteo de ficheros. No operes special cerca del lleno.
6. Planifica operativamente.
   Ventana de mantenimiento, expectativas de rollback (limitadas), scrub después, umbrales de alerta y runbook de on-call.

Checklist de implementación (haz esto, en este orden)

1. Verifica la identidad de dispositivos vía /dev/disk/by-id/, no adivinando /dev/nvme0n1.
2. Confirma salud de la pool: zpool status -x.
3. Añade vdev special espejado: zpool add pool special mirror ....
4. Verifica que esté presente y ONLINE: zpool status, zpool list -v.
5. Opcionalmente establece special_small_blocks solo en datasets específicos (empieza bajo, 8K–16K, y mide).
6. Scrub pronto después del cambio (y regularmente): zpool scrub, luego revisa resultados.
7. Configura monitorización: uso de special, SMART/errores de medios NVMe, outliers de latencia.
8. Vuelve a ejecutar la misma prueba de metadata y captura antes/después.

Checklist operativo (la parte que evita noches de pager)

• Alerta si la utilización del vdev special cruza un umbral elegido (advertencia ~70%, crítico ~80–85%).
• Alerta sobre cualquier READ/WRITE/CKSUM error en miembros del vdev special.
• Rastrea resistencia NVMe y errores de medios con el tiempo.
• Mantén dispositivos de repuesto o una vía de compra que no implique “urgir desde un marketplace”.
• Practica reemplazo de dispositivo en una pool no productiva si tu equipo no lo ha hecho.

Preguntas frecuentes

1) ¿Un vdev especial acelerará todo?

No. Acelera lo que esté limitado por latencia de metadata (y opcionalmente IO de bloques pequeños). Las lecturas secuenciales de ficheros grandes normalmente no cambiarán mucho.
Si tu problema es escrituras síncronas, presión de ARC, CPU o red, tampoco lo arreglará.

2) ¿Es seguro ejecutar un vdev especial como dispositivo único?

En producción, no. Si contiene metadata, perderlo puede perder la pool. Espejalo como mínimo.
Un vdev special de un solo dispositivo pertenece a laboratorios, demos o entornos que aceptan riesgo catastrófico.

3) ¿Es special lo mismo que L2ARC?

Ni de cerca operativamente. L2ARC es una caché y puede retirarse sin pérdida de datos (solo pierdes contenido de caché).
El vdev special guarda bloques autoritativos. Trátalo como almacenamiento crítico.

4) ¿A cuánto debo poner special_small_blocks?

Empieza conservador y por dataset. 8K o 16K son puntos de partida comunes para IO aleatorio tipo VM.
No lo pongas alto en datasets amplios a menos que hayas dimensionado special como una capa real y aceptes que datos de usuario vivirán allí.

5) ¿Puedo mover metadata existente al vdev special después de añadirlo?

ZFS tiende a colocar nuevas asignaciones según las reglas actuales; no reescribe el mundo automáticamente.
Algunas mejoras llegan de inmediato porque nueva metadata y actividad se desplazan, pero la migración completa suele requerir reescribir datos (por ejemplo, replicación a un nuevo dataset).

6) ¿Cómo sé si estoy limitado por metadata?

Busca listados/traversales lentos, enumeración de snapshots lenta, alto await en HDD con throughput modesto y misses significativos de metadata en ARC.
Si todo eso coincide, probablemente estás limitado por metadata.

7) ¿Añadir un vdev special cambia mi estrategia de backup/replicación?

Debería cambiar tu evaluación de riesgo, no tus fundamentos. Backups y replicación siguen siendo obligatorios.
Pero ahora también debes tratar los dispositivos special como críticos para la pool y asegurar monitorización, repuestos y procedimientos de reemplazo sólidos.

8) ¿Debería añadir un vdev special o simplemente más RAM?

Si el ARC está claramente hambriento, añade RAM primero. La RAM es la capa de metadata más rápida que puedes comprar.
El vdev special ayuda cuando los misses del ARC son inevitables y la latencia de HDD te está matando de todos modos.

9) ¿Un vdev special ayudará shares NFS/SMB?

A menudo sí, especialmente para shares con muchos ficheros pequeños, directorios profundos, checks de ACL y churn intenso de metadata.
Pero si el problema es la red, el comportamiento del cliente o escrituras síncronas, aún necesitas arreglar eso por separado.

10) ¿Cuál es la mayor señal de alarma tras añadir special?

Cualquier error en dispositivos del vdev special, y crecimiento rápido de la asignación special que no previste. Ambos merecen atención inmediata.

Próximos pasos que puedes hacer esta semana

1. Ejecuta la guía rápida de diagnóstico y captura salidas: zpool iostat, iostat -x, estadísticas ARC y un tiempo de recorrido de metadata.
   Si no puedes mostrar evidencia, no estás tomando una decisión de ingeniería—estás tomando una compra.
2. Si estás limitado por metadata, diseña un vdev special espejado usando SSD/NVMe fiables con protección contra pérdida de energía, y dimensiona con margen.
3. Añade el vdev special y monitorízalo inmediatamente. Si no alertas sobre utilización y errores de special, estás a una sorpresa de una noche larga.
4. Habilita special_small_blocks solo donde compense (datasets de VM, almacenes de contenedores), empezando conservador y vigilando el crecimiento de special.
5. Escribe el runbook para fallo de dispositivo special: cómo identificar, cómo reemplazar, cómo verificar mediante scrub y status, y quién recibe el pager.

El vdev special es una de las herramientas de rendimiento “del mundo real” más efectivas en ZFS—porque apunta a la latencia que los humanos realmente perciben.
También es una de las formas más fáciles de convertir una pool resiliente en una frágil si lo tratas como una caché. No lo hagas.