Dimensionamiento SLOG en ZFS: cuánto necesitas realmente (no “más grande es mejor”)

Qué hace realmente un SLOG (y qué no hace)

En ZFS, el ZIL (ZFS Intent Log) es el mecanismo que hace seguras las escrituras síncronas. Si una aplicación solicita
que una escritura se confirme (“sync”), ZFS debe poder reproducir esa escritura después de un fallo. Por defecto, ZFS almacena el
ZIL en los discos del pool. Eso funciona, pero puede ser lento porque fuerza I/O de baja latencia, pequeño y con muchas escrituras
en los mismos vdevs que hacen todo lo demás.

Un SLOG (Separate LOG device) es simplemente un lugar externo para poner los registros del ZIL. No guarda tus datos a largo plazo.
No es un L2ARC. No es una palanca mágica de “más IOPS”. Es una forma de convertir la “latencia de escritura síncrona” de “lo que haga tu pool
bajo carga” a “lo que tu SLOG pueda confirmar rápido y de forma segura”.

El modelo mental que no te fallará a las 3 a.m.

Piensa en una escritura síncrona en dos pasos:

1. ZFS recibe la escritura y necesita una promesa durable antes de ACK al cliente.
2. Más tarde ZFS escribe los bloques reales en el pool normal como parte de un commit de grupo de transacciones (TXG).

Con un SLOG, el paso 1 se convierte en “escribir un registro en el SLOG, hacer flush, ACK”. El paso 2 sigue ocurriendo en el pool principal
en el commit del TXG. El SLOG acelera el ACK y lo hace seguro; no acelera la mayor parte de tus escrituras en estado estable.

Si tu carga es mayormente asíncrona (bases de datos configuradas para write-back, copias masivas, ingestión de medios), el SLOG puede
no hacer casi nada. Si tu carga es intensiva en síncrono (NFS, iSCSI con write barriers, imágenes de VM en NFS, bases de datos con durabilidad estricta),
el SLOG puede ser la diferencia entre “bien” y “por favor, dejad de llamarme”.

Una idea parafraseada de Werner Vogels (CTO de Amazon) que encaja con el dimensionamiento del SLOG: todo falla; diseña de modo que la falla sea un evento normal y contenido.
Tu diseño de SLOG debería asumir que el dispositivo morirá, porque eventualmente lo hará.

Datos interesantes y contexto histórico

• ZFS siempre ha tenido un ZIL; el SLOG es opcional. Los primeros adoptantes a menudo culpaban a ZFS por latencia síncrona que en realidad era “discos giratorios siendo discos giratorios”.
• Los commits de TXG son periódicos (comúnmente en el orden de segundos), lo que significa que el ZIL suele ser de corta duración: es una zona de preparación, no almacenamiento.
• “SLOG” es jerga de la comunidad; ZFS habla del “log vdev”. El término se quedó porque a los ingenieros de almacenamiento les encantan los acrónimos como a los gatos las cajas.
• NFS hizo famoso al SLOG porque muchos clientes NFS por defecto usan semánticas síncronas por seguridad, especialmente para datastores de VM y actividad con mucha metadata.
• La protección ante pérdida de energía (PLP) se volvió la característica definitoria de buenos dispositivos SLOG a medida que los SSD se volvieron lo suficientemente rápidos y la “latencia” venció al “rendimiento” como factor limitante.
• Los primeros SSD de consumo mentían (a veces sin intención) sobre el comportamiento de flush; por eso los consejos de SLOG insisten en discos empresariales con PLP.
• Un SLOG suele ser pequeño comparado con el tamaño del pool. En muchos sistemas de producción, decenas de gigabytes ya son generosos.
• Los SLOG espejados se volvieron comunes no porque ZFS no pueda manejar la pérdida de un SLOG (usualmente puede), sino porque los operadores odian el downtime evitable y las alertas aterradoras.
• NVMe cambió la conversación: de “¿podemos hacer tolerables las escrituras síncronas?” a “¿cómo evitamos que un dispositivo rápido oculte un pool lento y sobrecargado?”

Regla de dimensionamiento que sobrevive el contacto con producción

Aquí va la verdad incómoda: el dimensionamiento del SLOG casi nunca es cuestión de capacidad. Es cuestión de latencia,
durabilidad y patrones de escritura. La capacidad es la última casilla, y una pequeña.

Qué es lo que realmente estás dimensionando

El SLOG debe ser lo bastante grande para alojar los registros ZIL pendientes que han sido confirmados a clientes pero aún no se han commitado
en el pool principal. Esos registros se liberan conforme los TXG se sincronizan. En un sistema estable, el ZIL no crece indefinidamente; oscila.

Una fórmula práctica de dimensionamiento se parece a esto:

Capacidad SLOG necesaria ≈ tasa máxima sostenida de escrituras síncronas × peor tiempo hasta sincronización TXG + margen.

“Peor tiempo hasta sincronización TXG” no es solo un valor de configuración; es el tiempo que tu pool tarda en completar con éxito un TXG bajo carga.
Si el pool es lento, fragmentado o sufre una carga patológica, el sync del TXG puede alargarse.

El número con el que la mayoría debería empezar

Para muchas cargas mixtas, empieza con 16–64 GiB de SLOG, espejado si te importa la disponibilidad. Eso no es un meme.
Es porque:

• Los TXG comúnmente se commitean en el orden de unos pocos segundos.
• Muchos sistemas no sostienen escrituras síncronas de varios gigabytes por segundo; eso lo sostienen en modo asíncrono.
• Quieres margen para ráfagas y para “el sync TXG se volvió más lento porque el pool está ocupado”.

Si necesitas más de 64–128 GiB para la capacidad del SLOG, empiezo a sospechar que estás intentando resolver un problema de rendimiento del pool
con un dispositivo de log. Así es como la gente termina comprando un parche caro para una pierna rota.

Broma #1: Un SLOG de 2 TB es como instalar una helipuerto en una canoa—impresionante en la reunión, confuso en el agua.

Cuándo “más grande” es activamente peor

Algunos SSD se vuelven más lentos en escrituras pequeñas sostenidas cuando se quedan sin caché SLC o sus tablas internas de mapeo se estresan.
Un disco de consumo enorme puede verse rápido en un benchmark y luego caerse en picado durante tormentas reales de sync. Mientras tanto, un NVMe empresarial
más pequeño con PLP se mantiene aburridamente consistente. En almacenamiento, “aburrido” es un cumplido.

La latencia es el verdadero presupuesto

A tus clientes no les importa que tu SLOG pueda hacer 3 GB/s en escrituras secuenciales. Las escrituras síncronas suelen ser pequeñas (4–128 KiB),
a menudo aleatorias y condicionadas por semantics de flush / FUA. La métrica que importa es la latencia del percentil 99
en escrituras durables.

Cómo se ve “bueno”

• Excelente: latencia de escritura durable por debajo de 100 microsegundos en un NVMe PLP real bajo carga.
• Bueno: unos cientos de microsegundos hasta ~1 ms, estable.
• Malo: picos de varios milisegundos, especialmente periódicos (se alinearán con el comportamiento TXG y timeouts de clientes).
• Horrible: decenas a cientos de milisegundos cuando el SSD hace GC o miente sobre flush.

Por qué el pool aún importa

El SLOG solo acelera la ruta de ACK. El pool aún tiene que absorber las escrituras reales en la sincronización TXG. Si tu pool no puede
mantener la tasa de escritura promedio, puedes “bufferizar” en el SLOG por un tiempo, pero eventualmente recibirás retropresión.
Los síntomas incluyen latencia síncrona creciente, tiempos de txg_sync en aumento y bloqueos de aplicaciones.

Cargas: cuándo el SLOG ayuda y cuándo es maquillaje

Cargas que a menudo se benefician

• Datastores NFS para virtualización donde el hipervisor emite escrituras síncronas para la seguridad de las VM.
• iSCSI con write barriers o sistemas de archivos invitados que hacen fsync con frecuencia.
• Bases de datos con durabilidad activada (fsync frecuente), especialmente commits pequeños.
• Cargas de archivos con mucha metadata: muchos patrones de create/rename/fsync.

Cargas donde el SLOG suele ser inútil

• Ingesta secuencial grande (medios, backups) que es asíncrona o puede tolerar async.
• Procesos analíticos por lotes donde las escrituras se agrupan y se commitean con poca frecuencia.
• Cualquier cosa con sync=disabled (sí, es rápido; no, no es seguro).

La trampa de “escritura síncrona”: la app decide, no tú

ZFS obedece las semánticas solicitadas. Si el cliente pide sync, ZFS hará sync. Si el cliente no lo pide, ZFS no lo hará.
Por eso dimensionar SLOG sin observar la carga es pura astrología de rendimiento.

Elección de dispositivos: lo que los vendedores no resaltan

No negociables para un verdadero dispositivo SLOG

• Protección ante pérdida de energía (PLP): capacitores o equivalente para que un flush sea realmente durable.
• Latencia consistentemente baja bajo escrituras pequeñas sostenidas: no solo “IOPS pico”.
• Endurance: las tormentas de sync pueden multiplicar la amplificación de escritura; elige en consecuencia.
• Comportamiento correcto de flush/FUA: quieres que el dispositivo respete los write barriers.

Qué clase de capacidad comprar

Compra por latencia y PLP, luego elige una capacidad que cubra tu necesidad calculada con margen. En la práctica:

• Necesidad efectiva 16–64 GiB: un SSD/NVMe empresarial de 100–400 GB suele ser suficiente.
• Alta tasa síncrona o tiempos TXG largos: 400–800 GB da holgura, pero no lo conviertas en un disco-trofeo.
• Almacenamiento multi-tenant sirviendo muchos clientes: considera SLOG NVMe espejado con latencia consistente, no mayor capacidad.

Por qué los SSD de consumo son mala idea (incluso cuando “funcionan”)

El modo de fallo no es solo “se muere”. El modo de fallo es “miente”. Los dispositivos de consumo pueden reconocer una escritura antes de que esté
realmente durable, especialmente ante pérdida de energía. Eso convierte tu SLOG en un truco de confianza: es rápido hasta que lo necesitas.

Espejar o no: matemáticas de fiabilidad y realidad operativa

Perder un dispositivo SLOG normalmente no hace que pierdas el pool. ZFS puede volver a usar el ZIL en-pool.
Pero “normalmente” no consuela cuando administras producción.

El impacto operativo de perder un SLOG varía según la implementación y el entorno:

• El rendimiento puede hundirse de inmediato (las escrituras síncronas vuelven a los discos del pool).
• Puede que necesites reemplazar hardware con presión.
• Algunos equipos optan por tomar una parada para restaurar el perfil de latencia esperado en lugar de seguir en modo degradado.

Mi predeterminada con opinión: espeja el SLOG si este sistema sirve clientes sensibles a la latencia síncrona (NFS para VM, bases de datos, almacenamiento compartido).
El coste incremental suele ser menor que la primera reunión postincidente.

Broma #2: Un SLOG de un solo disco en producción es como una sola tarjeta de acceso para toda la oficina—eficiente hasta que alguien la deja caer en un latte.

Tareas prácticas: comandos, salidas y decisiones

El único dimensionamiento que importa es el que puedes defender con mediciones. Aquí tienes tareas prácticas que puedes ejecutar hoy.
Cada una incluye: un comando, qué significa la salida y la decisión que tomas.

Task 1: Identify whether your pool has a SLOG and its topology

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
        logs
          mirror-1                   ONLINE       0     0     0
            nvme0n1p1                ONLINE       0     0     0
            nvme1n1p1                ONLINE       0     0     0

errors: No known data errors

Significado: Hay un log vdev espejado (SLOG) usando dos particiones NVMe. Bien.
Si no ves una sección logs, estás usando el ZIL en-pool.

Decisión: Si sirves clientes intensivos en síncrono y no hay SLOG, tienes una mejora candidata fuerte.
Si tienes un SLOG no espejado y la disponibilidad importa, planifica un espejo.

Task 2: Check dataset sync settings (the “did someone get clever?” test)

cr0x@server:~$ sudo zfs get -o name,property,value -s local,inherited sync tank/vmstore
NAME         PROPERTY  VALUE
tank/vmstore sync      standard

Significado: standard respeta las peticiones de la aplicación. always fuerza sync (a menudo más lento),
disabled miente a los clientes (rápido, inseguro).

Decisión: Si encuentras sync=disabled en almacenamiento de VM o bases de datos en producción, trátalo como una decisión de aceptación de riesgo,
no como un tweak de rendimiento.

Task 3: Confirm the workload is actually issuing sync writes

cr0x@server:~$ sudo zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                         12.1T  43.7T    210    980  32.1M  88.4M
  raidz2-0                   12.1T  43.7T    210    780  32.1M  61.2M
    sda                          -      -     35    130  5.3M   9.9M
    sdb                          -      -     34    129  5.2M   9.8M
    sdc                          -      -     36    131  5.4M  10.0M
    sdd                          -      -     35    128  5.3M   9.7M
    sde                          -      -     35    131  5.3M  10.0M
    sdf                          -      -     35    131  5.3M  10.0M
logs                             -      -      0    200   0K   27.2M
  mirror-1                       -      -      0    200   0K   27.2M
    nvme0n1p1                    -      -      0    100   0K   13.6M
    nvme1n1p1                    -      -      0    100   0K   13.6M
--------------------------  -----  -----  -----  -----  -----  -----

Significado: Las escrituras están alcanzando el vdev logs. Eso es tráfico síncrono siendo registrado.
Si el ancho de banda del log está cerca de cero mientras los clientes se quejan de latencia, tu carga puede ser mayormente asíncrona o estar limitada en otra parte.

Decisión: Si las operaciones/bw del log son significativas durante la ventana del problema, la latencia del SLOG importa. Si no, deja de obsesionarte con el tamaño del SLOG.

Task 4: Look at per-dataset latency with extended iostat (OpenZFS)

cr0x@server:~$ sudo zpool iostat -r -v tank 1 3
                              capacity     operations     bandwidth    total_wait     disk_wait
pool                        alloc   free   read  write   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  ----- -----   ----- -----
tank                         12.1T  43.7T    220    990  33.0M  90.1M   2ms  24ms     1ms  20ms
  raidz2-0                   12.1T  43.7T    220    790  33.0M  62.0M   3ms  28ms     2ms  23ms
logs                             -      -      0    200   0K   28.1M    -    1ms      -    1ms
--------------------------  -----  -----  -----  -----  -----  -----  ----- -----   ----- -----

Significado: El vdev del log muestra ~1 ms de espera en escritura, mientras que el vdev principal muestra mucho peor. Eso es esperado: el SLOG es rápido, el pool es más lento.
Si la espera de escritura del log es alta, tu SLOG es el cuello de botella para los ACKs síncronos.

Decisión: Si la espera del vdev del log es consistentemente mayor que la tolerancia de tu aplicación, reemplaza el dispositivo SLOG (latencia), no “más capacidad”.

Task 5: Confirm ashift and device alignment (performance hygiene)

cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
34:        vdev_tree:
58:                ashift: 12

Significado: ashift: 12 indica sectores de 4K. La desalineación puede causar amplificación de escritura y picos de latencia.

Decisión: Si ashift es incorrecto para tus dispositivos, planifica una reconstrucción/migración. No puedes “tunear” para salir de un pool desalineado.

Task 6: Validate the SLOG device supports durable writes (PLP hints)

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0n1 | egrep -i 'oncs|vwc|psd|mn'
mn      : INTEL SSDPE2KX040T8
oncs    : 0x001f
vwc     : 0x0001

Significado: vwc indica presencia de Volatile Write Cache. No prueba PLP, pero es una pista útil en la validación de inventario.
La confirmación real viene del conocimiento del modelo y las especificaciones del proveedor—pero al menos puedes detectar desajustes evidentes.

Decisión: Si no puedes establecer confianza en PLP, no uses el dispositivo para SLOG en un sistema donde la corrección importe.

Task 7: Check if TRIM/discard is enabled and behaving (latency stability)

cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  on        local

Significado: TRIM puede ayudar al comportamiento steady-state de SSD, reduciendo los precipicios de latencia a largo plazo.
No es una herramienta de dimensionamiento de SLOG, pero cambia la historia de “se volvió lento semanas después”.

Decisión: Si estás en SSD/NVMe y la plataforma lo soporta, considera autotrim=on tras pruebas.

Task 8: Observe TXG behavior indirectly via ZFS stats (Linux)

cr0x@server:~$ grep -E 'sync|async|txg' /proc/spl/kstat/zfs/txg | head -n 20
1 0 0x01 4 336 64080000 2110536636251
name                            type data
birth                           4    174541
timeout                         4    5
synced                          4    174538
opened                          4    174540

Significado: timeout muestra el intervalo objetivo TXG (a menudo 5s). Si tu pool no puede syncar los TXG rápidamente,
el “intervalo real” se estira, y tu SLOG debe mantener registros por más tiempo.

Decisión: Si el sync TXG se queda atrás en picos, arregla el rendimiento/latencia del pool; no infles solo el SLOG.

Task 9: Capture sync write pressure with a targeted fio test (carefully)

cr0x@server:~$ sudo fio --name=sync4k --directory=/tank/test --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --size=1G --fsync=1 --runtime=20 --time_based --group_reporting
sync4k: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.33
Starting 1 process
sync4k: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=580KiB/s][w=145 IOPS][eta 00m:00s]
sync4k: (groupid=0, jobs=1): err= 0: pid=14219: Fri Dec 26 12:14:21 2025
  write: IOPS=148, BW=594KiB/s (608kB/s)(11.6MiB/20s)
    lat (usec): min=820, max=9980, avg=1420.53, stdev=401.11
    clat percentiles (usec):
     |  1.00th=[  950],  5.00th=[ 1057], 10.00th=[ 1106], 50.00th=[ 1369]
     | 90.00th=[ 1795], 95.00th=[ 1975], 99.00th=[ 2474], 99.90th=[ 5866]

Significado: Esta prueba realiza escrituras pequeñas con fsync. Los percentiles de latencia son lo que importa.
Si el percentil 99 está en varios milisegundos, las VM y bases de datos se sentirán “entrecortadas”.

Decisión: Si la latencia es demasiado alta, revisa primero la latencia y el encolamiento del dispositivo SLOG. Si el SLOG es rápido pero todo sigue lento, el limitador es el pool.

Task 10: Verify the SLOG is actually being used by your dataset path

cr0x@server:~$ sudo zfs get -o name,property,value logbias,recordsize,primarycache tank/vmstore
NAME         PROPERTY      VALUE
tank/vmstore logbias       latency
tank/vmstore recordsize    128K
tank/vmstore primarycache  all

Significado: logbias=latency empuja a ZFS a preferir el SLOG para comportamiento síncrono. throughput puede reducir la dependencia del SLOG en algunos patrones.

Decisión: Para VM/NFS/bases de datos donde la latencia síncrona importa, mantén logbias=latency. No lo trates como un interruptor de “hacer más rápido” sin evidencia.

Task 11: Check for periodic stalls and correlate with system I/O latency

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

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda              5.2   120.1    0.30    9.50      164.3     7.20   58.30     9.10    60.40   0.95  99.1
nvme0n1          0.0    98.0    0.00   12.80       267.0     0.10    1.05     0.00     1.05   0.08   0.9

Significado: Discos giratorios ocupados al ~99% con awaits ~60 ms arrastrarán el tiempo de sync TXG.
NVMe está bien aquí; el vdev del pool es el cuello de botella.

Decisión: Si los discos del pool están saturados, arregla el layout de vdevs, añade vdevs o reduce la amplificación de escritura. Un SLOG más grande no cambiará que sda esté ardiendo.

Task 12: Inspect ARC pressure (to avoid blaming SLOG for memory issues)

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:15:01  3120   210      6   180   5     20   1    10   0   112G   128G
12:15:02  2980   260      9   225   8     25   1    10   0   112G   128G
12:15:03  3410   240      7   210   6     20   1    10   0   112G   128G

Significado: Si ARC está thrashing y los misses suben, puedes estar limitado por lecturas, no por escrituras síncronas.
El SLOG no rescatará una carga limitada por lecturas.

Decisión: Si miss% es alto y la latencia es impulsada por lecturas, ajusta memoria/ARC, añade RAM o revisa recordsize/special vdev.

Task 13: Check ZFS pool properties that influence write behavior

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

Significado: No influye directamente en el dimensionamiento del SLOG, pero indican intención operativa base. autoreplace off es común; solo asegúrate de tener un workflow de reemplazo.

Decisión: Si el comportamiento del pool es inconsistente entre entornos, estandariza. La resolución de problemas de SLOG es más sencilla cuando todo lo demás está en orden.

Task 14: Simulate SLOG removal impact (planned maintenance window)

cr0x@server:~$ sudo zpool remove tank nvme0n1p1
cr0x@server:~$ sudo 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
            sde                      ONLINE       0     0     0
            sdf                      ONLINE       0     0     0
        logs
          nvme1n1p1                  ONLINE       0     0     0

errors: No known data errors

Significado: Eliminaste un lado del espejo; estás corriendo sin espejo. Esta es una forma controlada de probar cuán dependiente eres del SLOG.

Decisión: Si la latencia se vuelve inaceptable con los logs degradados, has probado que el SLOG es crítico y debe espejarse con dispositivos adecuados y alertas.

Guión de diagnóstico rápido

Cuando los usuarios dicen “el almacenamiento está lento”, describen un síntoma. Tu trabajo es encontrar qué subsistema está mintiendo.
Aquí tienes una secuencia rápida de grado producción que encuentra cuellos de botella relacionados con SLOG con rapidez.

1) Confirma que realmente es latencia síncrona

• Comprueba si el dataset afectado lo usan NFS/iSCSI/VMs/bases de datos.
• Ejecuta zpool iostat -v y mira si las escrituras llegan a logs.
• Revisa la propiedad sync del dataset por configuraciones sorpresa.

2) Decide: ¿el SLOG está lento o el pool está lento?

• Si el vdev de logs muestra alta espera de escritura: tu dispositivo SLOG es el factor limitante.
• Si el vdev de logs es rápido pero los discos del pool tienen await/%util altos: tu pool no puede syncar TXGs con rapidez.
• Si ninguno: sospecha del cliente/red, configuraciones NFS o comportamiento de la aplicación (fsync storms).

3) Encuentra periodicidad y correlaciona

• Busca picos cada pocos segundos (ritmo TXG) o minutos (GC de SSD o tareas de snapshot).
• Correlaciona con iostat -x y latencia ZFS zpool iostat -r.

4) Valida la clase de dispositivo SLOG

• Confirma modelo con PLP (inventario + info del controlador).
• Revisa firmware problemático, throttling térmico y problemas del slot PCIe (NVMe puede bajar de velocidad).

5) Solo entonces habla del tamaño

Si no puedes demostrar que el ZIL se llena más allá de la capacidad actual del SLOG entre sincronizaciones TXG, “SLOG más grande” es superstición.
Arregla la latencia, arregla el rendimiento del pool, arregla las semánticas de sync. El tamaño es lo último.

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

1) El datastore de VM se congela 1–5 segundos y luego se recupera

Síntoma: bloqueos periódicos, a menudo alineados con ráfagas de escrituras de metadata.

Causa raíz: el sync TXG tarda demasiado porque los vdevs del pool están saturados; el SLOG solo acelera la ruta de ACK pero no puede arreglar un pool que se está ahogando.

Solución: añade vdevs, pasa a espejos para IOPS, reduce la amplificación de escritura (recordsize, volblocksize, compresión) o separa cargas. Verifica con iostat -x.

2) El SLOG “ayuda” una semana y luego la latencia se vuelve rara

Síntoma: latencia síncrona que crece gradualmente, picos ocasionales feos.

Causa raíz: colapso steady-state de un SSD de consumo (GC, agotamiento de caché SLC), falta de TRIM o throttling térmico.

Solución: reemplaza por dispositivo empresarial con PLP; asegúrate de autotrim=on si procede; monitoriza temperaturas NVMe y estado del enlace PCIe.

3) Fallo del dispositivo SLOG provoca un outage “porque nos asustamos”

Síntoma: el pool permanece online pero el rendimiento cae en picado; ops decide tomar downtime.

Causa raíz: SLOG no espejado sirviendo carga síncrona crítica; la falla fuerza el tráfico síncrono de vuelta al pool.

Solución: espejar el SLOG; mantener dispositivos de repuesto; ensayar el reemplazo; alertar ante degradación del log vdev.

4) “Añadimos un SLOG enorme y nada cambió”

Síntoma: mismo throughput, mismas quejas de latencia.

Causa raíz: la carga es mayormente asíncrona, o el cuello de botella son lecturas, red, CPU o ancho de banda de escritura del pool.

Solución: mide la actividad del vdev log; revisa misses ARC; valida configuraciones NFS/client; perfila el comportamiento fsync de la app antes de cambiar hardware.

5) Inconsistencia de datos tras un evento de pérdida de energía

Síntoma: corrupción a nivel de aplicación o transacciones confirmadas que faltan después de pérdida abrupta de energía.

Causa raíz: dispositivo SLOG sin verdadera protección ante pérdida de energía que reconoce escrituras prematuramente.

Solución: usa solo dispositivos empresariales con PLP; no confíes en “UPS nos salvará” como estrategia de durabilidad; valida la política de semánticas sync.

6) El SLOG es rápido, pero las escrituras síncronas siguen siendo lentas

Síntoma: la latencia del vdev log parece baja, pero los clientes ven tiempos de commit altos.

Causa raíz: aplicación haciendo fsyncs extra, configuraciones NFS servidor/cliente forzando sync, o latencia de red dominando.

Solución: inspecciona opciones de montaje de clientes, exportaciones NFS, perillas de durabilidad de bases de datos; mide la latencia de extremo a extremo y no solo el disco.

Tres mini-historias corporativas desde el campo

Incidente causado por una suposición errónea: “SLOG es una caché de escritura”

Una empresa SaaS mediana usaba ZFS para un clúster de virtualización interno. El equipo de almacenamiento añadió un “NVMe grande y rápido” como SLOG,
porque el documento de compras decía “write cache for ZFS”. Era un disco de consumo, pero las gráficas del benchmark eran hermosas.

El clúster mejoró de inmediato. Los tickets disminuyeron. El equipo declaró victoria y siguió adelante. Dos meses después, un evento de energía afectó a un rack.
El UPS cubrió la mayoría de servidores, pero una cabeza de almacenamiento cayó en frío. Al reiniciar, el pool se importó. No hubo errores obvios de ZFS.
Pero el equipo de bases de datos comenzó a reportar invariantes rotas: transacciones que habían sido reconocidas por los invitados no aparecían.

El postmortem fue brutal porque ZFS “parecía sano”. El fallo fue semántico: el dispositivo SLOG reconocía flushes que no eran realmente durables. ZFS hizo lo que se le pidió; el dispositivo mintió sobre haber hecho lo que afirmaba.

La solución no fue “más grande” ni “más”. Fue aburrida: NVMe PLP para SLOG, espejado, y una política que prohibiera discos de consumo en la ruta de ACK. También dejaron de llamar SLOG “caché” en la documentación interna. Las palabras importan. La palabra equivocada crea el modelo mental equivocado, y el modelo equivocado escribe cheques que tus datos no pueden cobrar.

Optimización que salió mal: forzar sync=always para “usar más el SLOG”

En una gran empresa, un equipo notó que su brillante SLOG casi no mostraba tráfico en horas normales. Alguien concluyó que el SLOG estaba “desperdiciado”
y aplicó sync=always en el dataset NFS principal para justificar el hardware. El cambio se fusionó durante un sprint de “endurecimiento de almacenamiento”
con buenas intenciones y escepticismo insuficiente.

En un día la latencia de respuesta de las aplicaciones se volvió irregular. No catastróficamente lenta—peor. Intermitente. Los equipos persiguieron DNS, luego balanceadores,
luego versiones de kernel, porque las gráficas de almacenamiento se veían “bien” en throughput promedio.

El verdadero problema fue auto infligido: cargas que antes escribían en async (y estaban diseñadas para ello) ahora se forzaron a semánticas sync. El SLOG
aceptó diligentemente una avalancha de commits pequeños, y el pool tuvo que absorberlos en el sync TXG. La latencia de cola aumentó en todo el sistema.
El cambio también incrementó la amplificación de escritura y transformó el desgaste del SSD en un ítem presupuestario.

Revertir a sync=standard estabilizó la latencia inmediatamente. Mantuvieron el SLOG porque ráfagas de metadata NFS y ciertos clientes sí se beneficiaron.
Pero la lección quedó: no fuerces semánticas de durabilidad para “usar lo que compraste”. Haz el sistema correcto primero, luego acelera donde importe.

Práctica aburrida pero correcta que salvó el día: SLOG espejado y reemplazo ensayado

Una firma de servicios financieros usaba NFS respaldado por ZFS para un clúster que procesaba ventanas batch sensibles al tiempo. El diseño de almacenamiento no era glamuroso:
SLOG espejado en SSDs PLP, alertas al on-call y un simulacro trimestral donde practicaban el fallo de un dispositivo de log.

Un trimestre, un dispositivo de log empezó a mostrar errores de medios. El monitoreo alertó. El on-call lo reemplazó en horario laboral sin drama porque lo habían practicado.
El rendimiento apenas se movió porque el log estaba espejado y el dispositivo sobreviviente asumió la carga.

El remate es que nadie fuera de infraestructura lo notó. Ese es el éxito en operaciones: la ausencia de historias.
El equipo aún escribió una nota interna, actualizó el runbook y comprobó versiones de firmware en la flota.

Por eso recomiendo SLOG espejado para producción intensa en síncrono. No porque sea teóricamente obligatorio, sino porque evita momentos de “debimos haberlo hecho”.
El incidente más barato es el que nunca tienes que explicar.

Listas de verificación / plan paso a paso

Paso a paso: dimensionar y desplegar un SLOG correctamente

1. Confirma que la carga es intensiva en síncrono.
   Usa zpool iostat -v durante el pico. Si los logs muestran actividad, estás en territorio SLOG.
2. Mide la latencia aceptable.
   Para VM y workloads de bases de datos, apunta a latencia de escritura durable estable submilisegundo si es posible.
3. Estima la necesidad de capacidad.
   Tasa pico de escrituras síncronas × peor tiempo de sync TXG × margen. Si no conoces la tasa, mídela.
4. Selecciona la clase de dispositivo primero, tamaño después.
   SSD/NVMe empresarial con PLP, latencia consistente, endurance adecuada. Evita partes de consumo en la ruta de ACK.
5. Espejalo para producción.
   Especialmente si el almacenamiento sirve muchos clientes o tienes ventanas de mantenimiento restrictivas.
6. Particiona intencionadamente.
   Usa una partición dedicada para SLOG si es necesario, pero no compartas el dispositivo con cargas aleatorias.
7. Añádelo limpiamente.
   Verifica que zpool status lo muestre bajo logs.
8. Valida la mejora con pruebas síncronas.
   Usa pruebas fio seguras en un dataset no crítico o en una ventana de mantenimiento. Compara latencia cola, no solo promedios.
9. Configura monitoreo para salud y latencia del log vdev.
   Alerta ante errores de dispositivo, degradación y cambios significativos en los tiempos de espera del log vdev.
10. Ensaya el fallo.
    Practica reemplazar un dispositivo de log. Si no puedes hacerlo con calma, no lo has diseñado realmente.

Lista de compras (imprímela antes de que alguien compre un “SSD rápido”)

• PLP: sí, documentado.
• Latencia sostenida en escrituras aleatorias: consistente, no solo benchmarks de ráfaga.
• Endurance apropiada para el volumen esperado de sync.
• Firmware maduro y comportamiento conocido en tu OS/kernel.
• Térmicas: que no hagan throttling en tu chasis.
• Factor de forma e interfaz: NVMe generalmente preferido por latencia; SAS puede estar bien si es consistente.
• Incluye presupuesto para espejo.

Preguntas frecuentes

1) ¿Un SLOG más grande hace ZFS más rápido?

Normalmente no. El tamaño del SLOG rara vez importa una vez que es “lo bastante grande”. La latencia y la durabilidad importan. Si el rendimiento mejora con un SLOG mayor,
a menudo significa que tus sync TXG están tardando demasiado y estás bufferizando más tiempo—no resolviendo la causa raíz.

2) ¿Cómo sé si mi carga está usando el SLOG?

Ejecuta zpool iostat -v durante la carga y verifica si el vdev logs muestra operaciones/ancho de banda de escritura.
Si está cerca de cero, tu carga no está emitiendo muchas escrituras síncronas o no pasan por ese pool.

3) ¿SLOG es lo mismo que L2ARC?

No. L2ARC es una caché de lectura. SLOG es para el ZIL, que trata de que las escrituras reconocidas sobrevivan a un fallo.
Mezclar los dos mentalmente es cómo acabas comprando el hardware equivocado.

4) ¿Qué pasa si el dispositivo SLOG muere?

Normalmente el pool se mantiene online y ZFS vuelve a usar el ZIL en-pool, pero el rendimiento para escrituras síncronas puede caer dramáticamente.
Operativamente, espera alertas y posibles cambios de latencia visibles para los clientes.

5) ¿Debo espejar el SLOG?

Si te importan latencia consistente y disponibilidad para cargas intensivas en síncrono: sí. Si es una caja de laboratorio o un sistema no crítico: tal vez no.
Pero reconoce lo que eliges—riesgo y disrupción, no solo “ahorrar una bahía”.

6) ¿Puedo usar una partición de un NVMe más grande como SLOG?

Sí, pero no compartas el resto de ese NVMe con otras cargas que puedan introducir picos de latencia. La contención anula todo el propósito.
Si particionas, mantén el dispositivo dedicado a roles de ZFS.

7) ¿sync=disabled elimina la necesidad de SLOG?

Elimina las garantías de durabilidad. Puede ser aceptable para datos estrictamente desechables, pero para VMs y bases de datos es una decisión de política
con consecuencias. Trátalo como desabrocharse el cinturón porque el coche es más ligero.

8) ¿Es logbias=throughput más rápido que logbias=latency?

Puede ser, dependiendo de los patrones de escritura, pero no es una ganancia gratis. Para clientes sensibles a la latencia síncrona, latency suele ser el predeterminado correcto.
Cámbialo solo con medición y un plan de reversión.

9) ¿Cuál es un tamaño razonable de SLOG para Proxmox o hosts de VM en NFS?

Comúnmente 16–64 GiB de necesidad efectiva, implementado como un par NVMe PLP espejado de 100–400 GB. Si observas tasas síncronas sostenidas altas
y sync TXG lento, ajusta—pero verifica que no estés enmascarando un cuello de botella del pool.

10) ¿Un SLOG rápido puede ocultar un pool lento?

Brevemente, sí. Puede hacer rápidos los ACKs mientras el pool aún lucha para commitear TXGs. Eventualmente el sistema aplicará retropresión.
Si tu pool está crónicamente saturado, arregla el diseño del pool.

Conclusión: pasos prácticos siguientes

Dimensiona tu SLOG como un operador, no como un coleccionista. Quieres un dispositivo que pueda confirmar escrituras síncronas rápida, correctamente y de forma consistente—
y una capacidad que cubra el estallido entre sincronizaciones TXG con margen. Eso es todo.

Pasos siguientes que realmente mueven la aguja:

1. Mide si las escrituras síncronas son el problema (zpool iostat -v, propiedad sync del dataset, pruebas fio con fsync en una ventana segura).
2. Si las escrituras síncronas son el factor limitante, compra por PLP + estabilidad de latencia, no por tamaño. Espeja si valoras la disponibilidad.
3. Si el sync TXG es lento, deja de buscar SLOGs y rediseña el pool para IOPS/ancho de banda de escritura.
4. Escribe un runbook para fallo del log vdev y prácticalo una vez. Tu yo futuro estará menos cansado.