ZFS dnodesize=auto: el impulso de metadatos que todos olvidan

Las conversaciones sobre rendimiento de ZFS tienden a orbitar los controles grandes y llamativos: recordsize, vdevs especiales, dispositivos slog, compresión y el eterno “¿deberíamos mirror o RAIDZ?”. Mientras tanto, una de las optimizaciones de metadatos más efectiva y discreta está en un rincón como la rueda de repuesto que olvidaste que tenías: dnodesize=auto.

Si ejecutas cargas con muchos archivos diminutos, atributos extendidos pesados (xattrs), ACLs, o simplemente un flujo implacable de recorridos de directorios, dnodesize=auto puede marcar la diferencia entre “los discos están inactivos pero todo va lento” y “los metadatos son aburridos otra vez”. Este artículo trata de hacer los metadatos aburridos—porque los metadatos aburridos son un regalo que sólo aprecias después de haber recibido una página a las 03:00 por un ls lento.

Tabla de contenidos

• Qué es un dnode (y por qué te importa)
• Qué hace realmente dnodesize=auto
• Por qué todo el mundo olvida este control
• Hechos y contexto histórico para repetir en reuniones
• Qué cargas se benefician (y cuáles no)
• Cómo habilitarlo de forma segura
• Tareas prácticas (comandos + interpretación)
• Guion rápido de diagnóstico
• Tres micro-historias del mundo corporativo
• Errores comunes, síntomas y soluciones
• Listas de verificación / plan paso a paso
• Preguntas frecuentes
• Conclusión

Qué es un dnode (y por qué te importa)

En ZFS, cada archivo, directorio, snapshot y objeto de dataset está descrito por una estructura llamada dnode (abreviatura de “data node”). Piénsalo como la tarjeta de identidad del archivo más su libreta de direcciones: almacena metadatos y punteros a los bloques que contienen el contenido del archivo. Cuando el archivo es pequeño o está cargado de metadatos, el dnode se convierte en el centro de gravedad.

He aquí la consecuencia práctica: si ZFS puede encajar más metadatos útiles dentro del dnode, puede evitar viajes adicionales para obtener “spill blocks” —bloques adicionales que contienen metadatos desbordados que no cupieron. Los spill blocks no son malvados, pero implican E/S extra, presión de caché adicional y latencia añadida—especialmente dolorosa cuando realizas muchas operaciones de metadatos.

La mayoría de incidentes de rendimiento en este área que he atendido tenían una huella común: la E/S de datos se veía bien, pero los recorridos de directorio y los patrones intensivos en stat (piensa: escáneres de backup, runners de CI, capas de contenedores, gestores de paquetes de lenguajes) pasaban de “suficientemente rápidos” a “¿por qué find tarda 20 minutos?”. Eso son metadatos, y el dnode es por donde empiezas.

Un chiste corto, como prometí: los metadatos son como el papeleo de oficina—nadie les dedica tiempo, y aun así determinan cuándo puedes irte a casa.

Qué hace realmente dnodesize=auto

dnodesize es una propiedad de dataset que controla el tamaño de los dnodes almacenados en disco. Históricamente, el tamaño por defecto de dnode era 512 bytes. Eso es suficiente para metadatos básicos y un número limitado de punteros de bloque—adecuado para muchas cargas, pero no ideal cuando metes muchos atributos extendidos, ACLs u otros metadatos “extra” dentro del objeto de archivo.

Cuando estableces dnodesize=auto, ZFS puede usar dnodes más grandes cuando sea necesario (hasta un tamaño máximo soportado, típicamente 16K dependiendo de la implementación y las banderas de características). No infla ciegamente cada objeto; ajusta el tamaño de los dnodes según la demanda de metadatos. El objetivo es reducir (o eliminar) los spill blocks para metadatos que de otro modo no cabrían.

Buffers bonus, xattrs y spill blocks: el meollo

Cada dnode contiene un “bonus buffer”, que es donde ZFS guarda metadatos más allá de los campos básicos—cosas como información ZPL (capa POSIX), ACLs y potencialmente xattrs inline según la configuración.

Si el bonus buffer es demasiado pequeño, ZFS almacena el desbordamiento en un spill block. Los spill blocks son bloques adicionales que deben leerse para acceder a esos metadatos. Ese es el momento en que tu llamada “simple” a stat() se convierte en “stat más E/S aleatoria adicional”. En flash eso aún puede importar; en HDDs puede ser catastrófico bajo concurrencia.

Con dnodesize=auto, el bonus buffer puede ser más grande porque el propio dnode puede ser más grande—por lo que los xattrs/ACLs a menudo pueden vivir ahí mismo. El resultado práctico son menos IOPS consumidos sólo para responder “¿qué es este archivo?”.

Auto vs dnodesize fijo

También puedes establecer dnodesize a valores fijos como 1k, 2k, 4k, etc. Los valores fijos son instrumentos toscos: pueden ayudar, pero también pueden desperdiciar espacio cuando no necesitas el tamaño mayor. auto es el enfoque de “usar más sólo cuando compensa”.

Operativamente, me gusta auto porque es lo más cercano a “quiero buen rendimiento de metadatos sin pagarlo permanentemente en cada objeto”. No es magia, pero es un valor por defecto sensato para cargas mixtas modernas.

Por qué todo el mundo olvida este control

Tres razones:

1. No es llamativo. No verás un gráfico de rendimiento secuencial 2x. Verás menos latencia, menos IOPS gastados, menos bloqueos en tareas con muchos directorios—más difícil de presumir.
2. Está ligado a banderas de características y hábitos de creación de datasets. Muchas organizaciones tienen pools antiguos actualizados “lo justo”, y las propiedades de dataset tienden a fosilizarse.
3. Los problemas de metadatos parecen “el sistema está lento”. La gente persigue CPU, red o el hipervisor. Mientras tanto, el almacenamiento sufre muerte por mil cortes de metadatos.

Segundo chiste corto: cuando alguien dice “es solo metadatos”, esa es tu señal para programar una reunión larga y cancelar tu fin de semana.

Hechos y contexto histórico para repetir en reuniones

• ZFS se diseñó con integridad de extremo a extremo primero. Checksums y copy-on-write no fueron añadidos después; moldearon todo, incluido el diseño de metadatos.
• Los dnodes clásicos eran de 512 bytes. Tenía sentido cuando los discos eran más lentos y las expectativas de metadatos eran más simples; las cargas modernas llevan más equipaje por archivo (ACLs, xattrs, etiquetas, metadatos de contenedores).
• Los atributos extendidos cambiaron el juego. A medida que los sistemas y aplicaciones empezaron a apoyarse en xattrs para etiquetas de seguridad, metadatos de usuario e indexado de apps, los “metadatos” adquirieron verdadera importancia.
• Las ACLs pueden ser grandes y parlanchinas. Las ACLs NFSv4 en especial pueden inflar los metadatos por archivo, convirtiendo los recorridos de directorio en una tormenta de E/S de metadatos.
• Las banderas de características de ZFS desbloquearon mejoras en el formato en disco. Muchos comportamientos “nuevos” (incluido el almacenamiento de metadatos más flexible) dependen de habilitar features a nivel de pool.
• Los metadatos a menudo dominan cargas de archivos pequeños. En buzones de correo, espacios de trabajo CI, registros de paquetes y capas de contenedores, con frecuencia el cuello de botella es “búsquedas y stats”, no las lecturas del payload.
• La presión del ARC puede ser presión de metadatos. El ARC es una caché, pero no es infinita. Metadatos sobredimensionados o demasiados spill blocks pueden hacerlo girar en falso.
• Los equipos de operaciones aprendieron esto a la fuerza. El cambio de la industria de monolitos a microservicios multiplicó árboles de archivos, shards de logs y patrones de “objetos diminutos”—los metadatos se convirtieron en tráfico de producción.

Qué cargas se benefician (y cuáles no)

Buenos candidatos

dnodesize=auto tiende a ayudar cuando tienes:

• Muchos archivos pequeños y actividad frecuente de stat()/readdir() (sistemas de compilación, gestores de paquetes, runners de CI).
• xattrs intensivos (etiquetas de seguridad, etiquetado de aplicaciones, metadatos de backups, flujos de Samba, metadatos de macOS en almacenamiento compartido).
• Entornos con muchas ACLs (ACLs NFSv4, compartidos empresariales con permisos complejos).
• Datasets ricos en snapshots donde los metadatos se referencian y recorren constantemente.

Impacto neutral o limitado

• Archivos grandes secuenciales (video, backups, blobs grandes): la carga está dominada por bloques de datos, no por spills de metadatos.
• Patrones de almacenamiento tipo objeto donde guardas objetos grandes y rara vez enumeras directorios.

Compromisos

El compromiso es directo: los dnodes más grandes pueden aumentar ligeramente la huella de metadatos en disco cuando se usan. Más importante, cambiar dnodesize no reescribe mágicamente los objetos existentes. Afecta a archivos creados recientemente (y a veces a los modificados cuando se reescribe metadato), así que debes tratarlo como una optimización orientada al futuro o planear una migración.

Cómo habilitarlo de forma segura

Reglas de alto nivel que te mantendrán fuera de problemas:

1. Revisa las banderas de features primero. Algunas implementaciones requieren habilitar ciertas features del pool para soportar dnodes más grandes. Si tu pool es antiguo, haz la diligencia aburrida.
2. Habilítalo a nivel de dataset donde importe. No tienes que activarlo en todos lados. Empieza por los puntos calientes de metadatos conocidos.
3. Mide antes y después. Las mejoras en metadatos aparecen en latencia, patrones de IOPS y “cuánto tarda un recorrido de directorio”. Escoge una prueba que puedas repetir.
4. Entiende que no es mayormente retroactivo. Si necesitas que los archivos existentes se beneficien, planifica un copy/rsync, una migración send/receive o una reconstrucción.

Tareas prácticas (comandos + interpretación)

Abajo hay tareas concretas que puedes ejecutar en producción (con cuidado) o en staging (preferible). Cada una incluye qué observar.

Task 1: Identify datasets and current dnodesize

cr0x@server:~$ zfs list -o name,used,avail,mountpoint -r tank
NAME                 USED  AVAIL  MOUNTPOINT
tank                 980G  2.60T  /tank
tank/home            120G  2.60T  /tank/home
tank/ci              220G  2.60T  /tank/ci
tank/shares          410G  2.60T  /tank/shares

cr0x@server:~$ zfs get -o name,property,value,source dnodesize -r tank
NAME        PROPERTY   VALUE  SOURCE
tank        dnodesize  legacy local
tank/home   dnodesize  legacy inherited
tank/ci     dnodesize  legacy inherited
tank/shares dnodesize  legacy inherited

Interpretación: Si ves legacy o un tamaño fijo pequeño en datasets con metadatos pesados, tienes un candidato. “Legacy” a menudo significa “antiguo valor por defecto”.

Task 2: Check pool feature flags status

cr0x@server:~$ zpool get all tank | egrep 'feature@|compatibility'
tank  compatibility  off    default
tank  feature@async_destroy  active  local
tank  feature@spacemap_histogram  active  local
tank  feature@extensible_dataset  active  local

Interpretación: Buscas un conjunto de features relativamente moderno. Los nombres exactos varían por plataforma. Si tu pool muestra muchas features como disabled o estás en un modo de compatibilidad restringido, pausa y evalúa antes de asumir soporte para dnode sizing.

Task 3: Enable dnodesize=auto on a target dataset

cr0x@server:~$ sudo zfs set dnodesize=auto tank/ci
cr0x@server:~$ zfs get dnodesize tank/ci
NAME     PROPERTY   VALUE  SOURCE
tank/ci  dnodesize  auto   local

Interpretación: Esto cambia el comportamiento para objetos nuevos/re-escritos en tank/ci. No reescribirá todo el dataset por sí mismo.

Task 4: Confirm xattr storage mode (SA vs dir)

cr0x@server:~$ zfs get xattr tank/ci
NAME     PROPERTY  VALUE  SOURCE
tank/ci  xattr     sa     inherited

Interpretación: xattr=sa almacena xattrs en el área de “system attribute” (bonus buffer) cuando es posible. Esto combina bien con dnodes más grandes porque puedes guardar más xattrs inline y evitar objetos separados.

Task 5: Inspect ACL mode and inheritance settings

cr0x@server:~$ zfs get acltype,aclinherit,aclmode tank/shares
NAME        PROPERTY    VALUE      SOURCE
tank/shares acltype     nfsv4      local
tank/shares aclinherit  passthrough local
tank/shares aclmode     passthrough local

Interpretación: Las ACLs NFSv4 pueden ser pesadas en metadatos. Si los usuarios se quejan de listados lentos en compartidos con muchas ACLs, el dimensionamiento de dnodes junto con elecciones xattr/SA puede importar.

Task 6: Spot metadata-bound behavior with iostat

cr0x@server:~$ zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         980G  2.60T    950   1200  12.3M  18.1M
  mirror     490G  1.30T    480    610  6.1M   9.0M
    sda         -      -    240    305  3.0M   4.5M
    sdb         -      -    240    305  3.1M   4.5M
  mirror     490G  1.30T    470    590  6.2M   9.1M
    sdc         -      -    235    295  3.1M   4.6M
    sdd         -      -    235    295  3.1M   4.5M

Interpretación: Operaciones altas con ancho de banda modesto a menudo significan I/O pequeño. Eso no prueba un problema de metadatos, pero es un patrón común cuando dominan los recorridos de directorio y la actividad de archivos pequeños.

Task 7: Measure directory walk time (repeatable micro-benchmark)

cr0x@server:~$ time find /tank/ci/workspace -type f -maxdepth 4 -print >/dev/null

real    0m18.442s
user    0m0.312s
sys     0m2.901s

Interpretación: Registra esto antes y después de los cambios sobre árboles de archivos comparables. Si tu tiempo sys es alto y el tiempo de pared está dominado por esperas de I/O, los metadatos son sospechosos.

Task 8: Check ARC pressure and metadata caching signals

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:10   820   140     17    60  43%    20  14%    60  43%   28G   32G
12:01:11   790   180     23    95  53%    15   8%    70  39%   28G   32G
12:01:12   810   210     26   120  57%    10   5%    80  38%   28G   32G

Interpretación: Un aumento de misses durante operaciones intensivas en metadatos puede indicar thrash en el ARC. Menos spill blocks puede reducir el número de bloques de metadatos discretos que necesitas cachear.

Task 9: Verify dataset properties commonly coupled to metadata performance

cr0x@server:~$ zfs get atime,compression,primarycache,secondarycache,logbias tank/ci
NAME     PROPERTY       VALUE     SOURCE
tank/ci  atime          off       local
tank/ci  compression    lz4       inherited
tank/ci  primarycache   all       default
tank/ci  secondarycache all       default
tank/ci  logbias        latency   default

Interpretación: Desactivar atime reduce escrituras de metadatos en árboles de archivos de solo lectura. Mantén primarycache=all salvo que tengas una razón fuerte; el caching sólo de metadatos (metadata) puede ser útil en escenarios con RAM limitada pero no es una recomendación por defecto.

Task 10: Check whether you’re paying for xattr spill the hard way

cr0x@server:~$ getfattr -d -m - /tank/ci/workspace/somefile 2>/dev/null | head
# file: tank/ci/workspace/somefile
user.build_id="9f1c..."
user.origin="pipeline-17"

Interpretación: Esto no muestra el spill directamente, pero confirma que los xattrs están en uso. Si ves uso generalizado de xattrs y operaciones de metadatos lentas, el dimensionamiento de dnodes cobra relevancia.

Task 11: Evaluate small-file metadata behavior with a simple create/stat test

cr0x@server:~$ mkdir -p /tank/ci/.bench
cr0x@server:~$ rm -rf /tank/ci/.bench/*
cr0x@server:~$ time bash -c 'for i in $(seq 1 20000); do echo x > /tank/ci/.bench/f.$i; done'

real    0m24.901s
user    0m2.210s
sys     0m12.884s

cr0x@server:~$ time bash -c 'for i in $(seq 1 20000); do stat /tank/ci/.bench/f.$i >/dev/null; done'

real    0m11.332s
user    0m0.411s
sys     0m2.870s

Interpretación: Es tosco pero útil. Si stat es desproporcionadamente lento, probablemente estés limitado por la obtención de metadatos y el comportamiento de la caché, no por el rendimiento de datos.

Task 12: Confirm property inheritance and prevent accidental drift

cr0x@server:~$ zfs get -s local,inherited dnodesize -r tank | sed -n '1,12p'
NAME      PROPERTY   VALUE  SOURCE
tank      dnodesize  legacy local
tank/ci   dnodesize  auto   local
tank/home dnodesize  legacy inherited

Interpretación: Así detectas el problema de “lo arreglamos una vez pero los nuevos datasets siguen mal”. Si quieres consistencia, ponlo en un dataset padre y haz que lo hereden intencionalmente.

Task 13: Use send/receive to actually apply the new dnode sizing to existing data (migration pattern)

cr0x@server:~$ sudo zfs snapshot -r tank/ci@pre-dnode-mig
cr0x@server:~$ sudo zfs create -o dnodesize=auto -o xattr=sa tank/ci_new
cr0x@server:~$ sudo zfs send -R tank/ci@pre-dnode-mig | sudo zfs receive -F tank/ci_new

Interpretación: Este es el método limpio para “aplicar nuevas propiedades a todo”. Creas un dataset nuevo con las propiedades deseadas y recibes en él. Aún necesitas un plan de corte (mountpoints, servicios, permisos), pero así evitas esperar a que el churn orgánico ocurra.

Task 14: Validate post-change with a targeted metadata-heavy workload

cr0x@server:~$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:~$ time ls -lR /tank/ci/workspace >/dev/null

real    0m42.118s
user    0m0.902s
sys     0m6.331s

Interpretación: Vaciar cachés es disruptivo y no siempre posible en hosts de producción; usa staging si puedes. El objetivo es eliminar la excusa de “ya estaba en caché” y forzar al sistema a mostrar su comportamiento de metadatos en disco.

Guion rápido de diagnóstico

Esto es la “tienes 15 minutos antes de que el comandante del incidente pida una dirección” lista de comprobación. El objetivo es decidir si los metadatos son el cuello de botella y si el dimensionamiento de dnodes/xattrs está en la zona afectada.

Primero: prueba que huele a metadatos

1. Revisa los síntomas: usuarios reportan ls -l lento, find lento, comprobaciones de permisos lentas, pasos de CI lentos como “checkout” o “npm install”, pero las lecturas/escrituras masivas se ven bien.
2. Mira la forma de la E/S: IOPS altos, ancho de banda bajo en zpool iostat.
3. Revisa la latencia: incluso en SSD, los picos de latencia de metadatos aparecen como latencia tail del servicio (p95/p99) en lugar de colapso de throughput.

Segundo: identifica dónde vive la presión de metadatos

1. Encuentra el dataset: ¿qué mount está lento? Asócialo a un dataset con zfs list.
2. Inspecciona propiedades clave: dnodesize, xattr, atime, acltype, primarycache.
3. Comprueba el comportamiento del ARC: si los demand misses suben durante recorridos de directorio, probablemente no estás cacheando lo que crees.

Tercero: decide el nivel de intervención

1. Bajo riesgo: habilitar dnodesize=auto para objetos futuros; establecer/confirmar xattr=sa cuando corresponda; desactivar atime si es seguro.
2. Riesgo medio: migrar el dataset caliente vía send/receive para “reempaquetar” metadatos con nuevas configuraciones.
3. Alto riesgo: cambios en features del pool, cambios en vdevs especiales o shifts arquitectónicos. No hagas esto a mitad de un incidente a menos que te guste escribir postmortems que empiecen con “en un exceso de optimismo”.

Tres micro-historias del mundo corporativo

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

El ticket sonaba como una broma: “ls está lento en el share; copiar archivos grandes está bien.” Ese tipo de frase desencadena dos instintos opuestos: o “no es almacenamiento” porque el throughput va bien, o “definitivamente es almacenamiento” porque ls es básicamente un benchmark de metadatos disfrazado.

El entorno era mixto—algunos clientes Linux, algunos usuarios SMB y un puñado de trabajos de automatización que adoraban recorrer árboles completos varias veces por hora. La suposición que causó el incidente fue simple y común: “los metadatos están en RAM, así que no pueden ser el cuello de botella.” El equipo había dimensionado la RAM para caches de aplicaciones y asumió que ZFS se encargaría del resto.

En realidad, el ARC estaba en churn constante. Cada recorrido de directorio desencadenaba un desfile de lecturas de metadatos, y muchas de esas lecturas traían spill blocks porque los archivos cargaban xattrs y ACLs pesadas. Nada estaba “roto” en el sentido de errores o discos fallando. Era sólo un impuesto que el sistema estaba pagando en silencio—hasta que el uso creció lo suficiente como para convertir ese impuesto en una interrupción.

La solución no fue dramática. Primero, dejaron de culpar a la red. Luego habilitaron dnodesize=auto y validaron xattr=sa en el dataset usado para el share. La mejora inmediata fue modesta porque los objetos existentes seguían con dnodes pequeños. La verdadera ganancia vino después de una migración planificada (send/receive a un dataset nuevo con las propiedades nuevas). Los listados de directorios dejaron de caducar y el incidente se cerró con la causa raíz menos glamorosa imaginable: “ineficiencia en el layout de metadatos.” Lo cual, en mi libro, es un cumplido. Las causas aburridas son las que puedes prevenir.

Micro-historia 2: La optimización que salió mal

Otra organización tenía una obsesión por el rendimiento, del tipo que se consigue cuando cada equipo de producto tiene un dashboard y nadie se pone de acuerdo sobre qué significa “rápido”. Su equipo de almacenamiento hizo un cambio que sonaba razonable: afinar el cache para priorizar metadatos porque “la mayoría de cargas son archivos pequeños.” Pusieron primarycache=metadata en un dataset muy ocupado que albergaba tanto artefactos de compilación de archivos pequeños como imágenes de contenedores de tamaño moderado.

Al principio, pareció un triunfo. El recorrido de directorios se volvió más ágil. Luego las descargas de contenedores empezaron a fallar. La pipeline de builds que antes hacia stream de capas con fluidez comenzó a sufrir latencias tail. La rotación de on-call consiguió una nueva alerta favorita: “registry fetch timed out.”

El problema no fue que el caching sólo de metadatos sea siempre incorrecto; fue que lo aplicaron de forma amplia, sin aislar los tipos de carga. Al expulsar datos del ARC, empujaron más lecturas a disco para las capas de contenedor. El sistema se volvió excelente listando archivos y mediocre leyéndolos—una optimización que resolvió el dolor equivocado para los consumidores equivocados.

La resolución eventual fue doble: revertir primarycache a all para cargas mixtas, y usar dnodesize=auto más xattr=sa para reducir la sobrecarga de metadatos sin dejar sin caché los datos. La lección era vieja pero perenne: no cambies el p95 de un equipo por el outage de otro a menos que puedas nombrar y defender el intercambio.

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

Uno de los equipos de operaciones más sanos que he visto tenía un ritual que parecía casi demasiado simple: cada vez que creaban un dataset top-level nuevo, aplicaban un conjunto base de propiedades—compresión, atime, xattrs, política de ACLs y sí, dnodesize=auto donde era apropiado. No confiaban en el conocimiento tribal. Lo codificaron.

Meses después, llegó un despliegue de seguridad: más etiquetado, más xattrs, más complejidad de ACLs. El mismo tipo de cambio que había derribado otros servicios de archivos en el pasado. Su entorno… en su mayoría se encogió de hombros. Hubo algún crecimiento en el uso de metadatos, pero no hubo un precipicio repentino.

Cuando un share particular mostró operaciones de directorio más lentas, su troubleshooting fue aburrido también: comparar propiedades con la baseline, confirmar comportamiento del ARC e aislar si la ralentización era causada por un patrón del lado del cliente (algunas apps hacen “stat todo dos veces” de forma patológica). No tuvieron que improvisar para retrofitear propiedades de dataset durante un incidente porque los valores por defecto ya eran razonables.

Ese es el valor oculto de dnodesize=auto: no es una perilla de rescate heroica; es una perilla de higiene básica. Convierte ciertas clases de incidentes futuros en “vimos una regresión y avanzamos”, en lugar de “descubrimos que los metadatos tienen física”.

Errores comunes, síntomas y soluciones

Mistake 1: Expecting dnodesize changes to rewrite existing files

Síntoma: Pones dnodesize=auto, vuelves a ejecutar tu carga y nada cambia.

Por qué: Los objetos existentes mantienen su tamaño de dnode actual a menos que los metadatos se reescriban de una manera que asigne un nuevo tamaño de dnode o migres los datos.

Solución: Planifica una migración de dataset (send/receive a un dataset nuevo con las propiedades deseadas) o acepta que los beneficios se acumulan con el tiempo a medida que los archivos cambian.

Mistake 2: Enabling dnodesize=auto without aligning xattr strategy

Síntoma: Aún ves E/S de metadatos pesada y las apps con xattr intensivo siguen lentas.

Por qué: Si los xattrs se almacenan como objetos separados (xattr=dir), todavía estás haciendo búsquedas y lecturas extra incluso con dnodes más grandes.

Solución: Evalúa xattr=sa para el dataset, considerando compatibilidad OS/cliente y el comportamiento de la carga. Aplícalo de forma intencional, no como superstición.

Mistake 3: Applying metadata tuning to mixed workloads indiscriminately

Síntoma: Las operaciones de directorio mejoran pero las lecturas por streaming empeoran; los usuarios se quejan de cosas diferentes después del “arreglo”.

Por qué: Propiedades como primarycache e incluso decisiones de recordsize pueden desplazar el rendimiento entre rutas de metadatos y datos.

Solución: Divide datasets por tipo de carga cuando sea posible. Usa la herramienta aburrida: puntos de montaje separados para personalidades de rendimiento distintas.

Mistake 4: Treating slow ls as “network” by default

Síntoma: Usuarios SMB/NFS ven listados de directorio lentos; los equipos de ops persiguen MTU, DNS y buffers de switch.

Por qué: La petición del cliente desencadena una tormenta de búsquedas de metadatos; la red es sólo el mensajero.

Solución: Correlaciona operaciones del cliente con IOPS del servidor y misses del ARC. Ejecuta un benchmark de recorrido de directorio local al servidor para separar “servidor lento” de “red lenta”.

Mistake 5: Ignoring ACL amplification

Síntoma: Directorios con muchas reglas de permisos son dramáticamente más lentos que directorios similares con permisos más simples.

Por qué: La evaluación y el almacenamiento de ACLs pueden inflar los metadatos, provocando más spill y más lecturas.

Solución: Revisa acltype y el modo de herencia; asegura que el dataset esté configurado para la semántica de ACL esperada. Empáralo con dnodesize=auto para mantener los metadatos de ACL inline cuando sea posible.

Listas de verificación / plan paso a paso

Plan A: Low-risk rollout (new data benefits first)

1. Elige el dataset correcto: Identifica el dataset con los peores síntomas de metadatos (workspace CI, directorios home compartidos, árboles de checkout de código).
2. Captura la configuración actual:

   cr0x@server:~$ zfs get dnodesize,xattr,acltype,atime,compression tank/ci

3. Habilita dnodesize=auto:

   cr0x@server:~$ sudo zfs set dnodesize=auto tank/ci

4. Valida la política de xattr:

   cr0x@server:~$ sudo zfs set xattr=sa tank/ci

5. Confirma la política de atime: Si es seguro para tus apps:

   cr0x@server:~$ sudo zfs set atime=off tank/ci

6. Mide con una prueba repetible: Mantén un benchmark baseline de find/stat y compáralo con el tiempo mientras se crean nuevos objetos.

Plan B: Migration rollout (existing data benefits now)

1. Programa una ventana: Necesitas un plan de corte. No improvises swaps de mountpoints mientras los usuarios escriben.
2. Snapshot del origen:

   cr0x@server:~$ sudo zfs snapshot -r tank/ci@mig-start

3. Crea un dataset destino con las propiedades deseadas:

   cr0x@server:~$ sudo zfs create -o dnodesize=auto -o xattr=sa -o atime=off tank/ci_v2

4. Send/receive:

   cr0x@server:~$ sudo zfs send -R tank/ci@mig-start | sudo zfs receive -F tank/ci_v2

5. Corte: Detén escritores, envío incremental final (si es necesario), remount y reinicia servicios.
6. Validación post-corte: vuelve a ejecutar tus benchmarks de metadatos y vigila patrones ARC/iostat durante el pico de uso.

Plan C: Prevent drift (the practice that keeps paying)

1. Define plantillas de datasets base por carga (propósito general, shares, CI, logs).
2. Haz cumplir vía automatización: provisiona datasets con propiedades explícitas en lugar de heredar defaults desconocidos.
3. Audita regularmente:

   cr0x@server:~$ zfs get -r -o name,property,value,source dnodesize,xattr,atime,acltype tank | head -n 40

Preguntas frecuentes

1) ¿Qué cambia dnodesize=auto en términos sencillos?

Permite a ZFS asignar dnodes más grandes sólo cuando los metadatos de un objeto lo necesitan, de modo que más metadatos puedan vivir inline y se requieran menos spill blocks.

2) ¿Acelerará todo si lo habilito?

No. Se dirige principalmente a patrones intensivos en metadatos: muchos archivos pequeños, muchos xattrs/ACLs y recorridos de directorio. Las lecturas/escrituras secuenciales grandes normalmente no lo notarán.

3) ¿Es seguro habilitarlo en un dataset existente?

En general sí; es un cambio de propiedad de dataset. El principal “truco” es la expectativa: no reescribirá archivos antiguos. La seguridad también depende del soporte de tu plataforma y de las features habilitadas en el pool.

4) ¿Aumenta el uso de espacio?

Potencialmente, para objetos que realmente usan dnodes más grandes. El objetivo de auto es pagar el coste de espacio sólo cuando reduce spill blocks y mejora la eficiencia.

5) ¿Cómo se relaciona esto con xattr=sa?

xattr=sa almacena xattrs en el área de atributos del sistema (bonus buffer) cuando es posible. Dnodes más grandes significan un presupuesto mayor de bonus buffer, lo que puede mantener más xattrs inline y reducir E/S adicional.

6) Si pongo dnodesize=auto, ¿sigo necesitando un vdev especial para metadatos?

Resuelven problemas diferentes. dnodesize=auto reduce E/S de metadatos al encajar más inline y evitar spills. Un vdev especial acelera la E/S de metadatos poniendo metadatos en medios más rápidos. Puedes usar ambos, pero no trates uno como sustituto del otro.

7) ¿Cómo sé si los spill blocks me están perjudicando?

En la práctica: stat y recorridos de directorio lentos, IOPS altos con ancho de banda bajo, misses de ARC en operaciones de metadatos y desaceleración desproporcionada en árboles con xattrs/ACLs. Probar la implicación de spill blocks con precisión puede ser específico de la plataforma, así que trata esto como un ejercicio de correlación más benchmarks controlados.

8) ¿Debería poner dnodesize a un valor fijo mayor en lugar de auto?

Los valores fijos pueden funcionar para datasets especializados donde sabes que los metadatos serán siempre pesados. Para cargas mixtas o inciertas, auto suele ser la mejor opción de “no pagar de más”.

9) ¿Afecta dnodesize=auto a send/receive?

Afecta cómo se organiza el layout de los objetos recién recibidos en el dataset destino, porque las propiedades del destino rigen el comportamiento de asignación. Por eso la migración vía send/receive es una forma práctica de “aplicar” dnode sizing a datos existentes.

10) ¿Cuál es la ganancia más rápida si no puedo migrar?

Habilita dnodesize=auto ahora para que los archivos nuevos se beneficien, asegura que xattr=sa sea apropiado y elimina escrituras de metadatos evitables (como atime=on en árboles calientes). Luego planifica una migración cuando el negocio lo tolere.

Conclusión

dnodesize=auto es una de esas configuraciones de ZFS que parece que no debería importar—hasta que estás del lado equivocado de un muro de metadatos. No hace que los gráficos de throughput sean emocionantes. Hace que los recorridos de directorio dejen de ser un evento de rendimiento. Reduce el impuesto de E/S de xattrs y ACLs. Y en entornos de producción modernos—donde el software adora crear montañas de archivos diminutos y pegar metadatos a todo—eso no es una mejora de nicho. Es estabilidad.

Si recuerdas una sola recomendación operativa: trata los metadatos como una carga de trabajo de primera clase. Configura dnodesize=auto deliberadamente en los datasets que lo merezcan, empáralo con una política coherente de xattr/ACL y mide los resultados con pruebas repetibles. El mejor día para arreglar metadatos fue antes del incidente. El segundo mejor día es antes de que el próximo ls se convierta en tu panel de outage.