ZFS SLOG: Cuándo un dispositivo de registro ayuda, cuándo es inútil, cuándo es peligroso

octubre 18, 2025 • febrero 3, 2026 • Lectura: 34 min • Views: 10

¿Te fue útil?

Hay dos tipos de problemas de rendimiento en ZFS: los que puedes arreglar con arquitectura y los que intentas arreglar comprando hardware a las 2 a.m. Un Separate Log device (SLOG) vive justo en esa línea. Para la carga de trabajo adecuada, convierte “¿por qué cada fsync tarda una eternidad?” en “ah, ahora está bien.” Para la carga equivocada, es un pisapapeles sofisticado que añade nuevos modos de fallo.

Esta es una guía de campo escrita desde la perspectiva de quienes realmente reciben llamadas de incidente: qué es SLOG, qué no es, las “trampas” que queman equipos y los comandos que ejecutarás cuando el gráfico se eleve en vertical. Hablaremos de semánticas sync, latencia, protección contra pérdida de energía y cómo saber si vas a mejorar las cosas—o empeorarlas de forma emocionante.

Qué es realmente un SLOG (y por qué existe)

Pongamos el vocabulario en claro, porque “SLOG” es uno de esos términos que se usan como si fuera un botón turbo.

ZIL es el ZFS Intent Log. Existe en cada pool ZFS. No es un dispositivo separado por defecto. Es un mecanismo: cuando una aplicación pide una escritura síncrona, ZFS debe confirmar que la escritura es duradera (o sobrevivirá a una pérdida de energía) antes de reconocerla. ZFS logra esto escribiendo un registro de la operación en el ZIL, y luego incorporando ese cambio en las estructuras principales en disco durante los commits normales de transaction group (TXG).

SLOG es un Separate LOG device: un vdev dedicado donde ZFS almacena registros del ZIL en lugar de usar los discos principales del pool. El objetivo es la latencia. Los discos rotacionales (e incluso muchas SSD) son terribles en escrituras síncronas pequeñas y de baja latencia cuando están ocupados en otras cosas. Un buen dispositivo SLOG puede reconocer rápidamente las escrituras síncronas y dejar que los vdevs principales absorban el trabajo a granel de forma asíncrona.

Aquí está la trampa: SLOG solo ayuda las escrituras síncronas. Si tu carga es principalmente escrituras asíncronas—buffering de bases de datos, ingestión por streaming, copias secuenciales grandes, trabajos de backup—SLOG no puede hacer nada, porque ZFS no estaba esperando en el ZIL en primer lugar.

Una cosa más: un dispositivo SLOG no es una caché de escritura en el sentido que muchos entienden. El SLOG no “retiene todas las escrituras.” Mantiene una ventana rodante de operaciones sync reconocidas recientemente, típicamente segundos de actividad, hasta que se confirman en el pool propiamente dicho. Si el sistema se cae, ZFS reproduce esos registros del ZIL al importar el pool. Si el SLOG miente sobre durabilidad, tendrás que hacer arqueología de datos.

Broma #1 (obligatoria y merecida): Comprar un SLOG para una carga asíncrona es como instalar una salida de emergencia en una piscina—técnicamente impresionante, operativamente irrelevante.

Datos interesantes y breve historia

Puntos cortos y concretos que te ayudan a razonar sobre lo que estás tocando:

ZFS nació en una era de “mentiras sobre el orden de escritura”. Las pilas de almacenamiento históricamente reconocían escrituras antes de que fueran realmente duraderas; ZIL existe para dar semántica correcta a las aplicaciones que lo exigen.
El ZIL no es un journal de un sistema de archivos journaled. Está más cerca de un intent log para las operaciones síncronas recientes, no un journal completo que rehaga todo el estado del sistema de archivos.
SLOG se volvió un tema común cuando se popularizaron las exportaciones NFS. Los clientes NFS (especialmente para VMs) a menudo emiten muchas escrituras sync o las fuerzan mediante opciones de montaje/export, convirtiendo la latencia en un problema crítico.
Las primeras SSD eran rápidas pero deshonestas. Muchas SSD de consumo reconocían flushes rápido pero no persistían datos de forma segura durante pérdida de energía; por eso la protección contra pérdida de energía (PLP) se convirtió en la prueba de fuego para SLOG.
El timing de los TXG lo determina todo. ZFS agrupa cambios en transaction groups; el intervalo de commit por defecto (a menudo alrededor de 5 segundos) explica por qué el SLOG no necesita ser grande.
Evolucionaron tipos de vdev especiales. ZFS incorporó roles de vdev dedicados (log, cache, special, dedup). SLOG es uno de los roles “separados” más antiguos y también uno de los más malentendidos.
Algunos proveedores enviaron “SLOG-en-una-caja”. Los appliances de almacenamiento comercializaron NVRAM dedicada o dispositivos de log espejados porque el reconocimiento de baja latencia vende bien a compradores de VM y bases de datos.
“sync=disabled” es la letra escarlata de los postmortems. Los equipos siguen redescubriendo que el rendimiento que “ganaste” mintiendo a las aplicaciones puede convertirse en pérdida de datos que no puedes explicar a los auditores.

Cuándo un SLOG ayuda, cuándo es inútil, cuándo es peligroso

Cuándo un SLOG ayuda

Un SLOG ayuda cuando tu cuello de botella es la latencia de escrituras síncronas. No el throughput. No las IOPS de lectura. No las matemáticas de RAIDZ. La latencia de operaciones que deben confirmarse antes de que el llamador continúe.

Casos clásicos:

NFS para virtualización (discos de VM sobre NFS). Los sistemas de archivos de los invitados llaman a fsync. Los hipervisores pueden ser propensos a sync. El resultado es una lluvia constante de pequeñas escrituras síncronas.
Bases de datos configuradas para durabilidad fuerte (o que explícitamente llaman a fsync en commit). Si la base de datos está en ZFS y el dataset es intensivo en sync, un buen SLOG puede reducir picos de latencia en commits.
Aplicaciones que usan O_DSYNC / O_SYNC o llamadas frecuentes a fsync (loggers que realmente importan, colas de mensajes, algunos sistemas CI que hacen operaciones de archivos paranoicas).
Cargas dominadas por pequeñas escrituras aleatorias síncronas donde tus vdevs principales son HDDs o SSD ocupadas y no pueden ofrecer latencia baja y consistente.

Lo que notarás cuando SLOG sea la solución adecuada: el sistema no está “lento por todas partes”. Está lento específicamente en puntos sync. La CPU va bien. El ARC va bien. Las lecturas van bien. Pero las transacciones se detienen. Los percentiles de latencia se ven feos. Los usuarios describen “tartamudeos” más que lentitud constante.

Cuándo un SLOG es inútil

SLOG es inútil cuando tu carga es mayormente asíncrona, o cuando el verdadero cuello de botella está en otro lugar.

Escrituras secuenciales a granel (backups, ingestión de medios, copias de archivos grandes). ZFS almacenará en memoria y hará flush en TXGs; SLOG no está en la ruta crítica.
Cargas centradas en lectura. SLOG no tiene nada que ver con lecturas. Eso es ARC/L2ARC y distribución de vdev.
Compresión, checksumming o cifrado limitados por CPU. Si estás saturando núcleos con zstd o AES, un SLOG no los desatascará.
NFS/SMB limitado por red. Si tus NICs están saturadas, un SLOG es una forma muy cara de seguir saturado.
Pools que ya tienen muy baja latencia (mirrors todos NVMe con amplio margen). A veces el pool ya es más rápido que la cadencia sync de tu app; añadir un log device añade complejidad sin beneficio.

Un patrón común de fallo: alguien ve “latencia de escritura” y asume SLOG. Pero las escrituras son async, o la latencia viene de presión de TXG por restricciones de memoria, o de un disco lento en un vdev RAIDZ. SLOG no arregla la física; solo cambia dónde caen los registros sync.

Cuándo un SLOG es peligroso

SLOG se vuelve peligroso cuando se convierte en un punto único de fallo para escrituras síncronas reconocidas o cuando te tienta a mentir sobre la durabilidad.

Situaciones de riesgo:

Usar una SSD de consumo sin PLP como SLOG. Puede reconocer un flush y luego perder los últimos segundos de escrituras en pérdida de energía. ZFS reproducirá fielmente lo que tenga; la parte faltante es tu problema.
Usar un SLOG de un solo disco en un sistema donde la pérdida del log es inaceptable. Si el dispositivo SLOG muere perdiendo registros ZIL en vuelo, puedes perder las escrituras síncronas que ya se habían reconocido a los clientes.
Mal uso de ajustes sync (p. ej., sync=disabled) para “recuperar rendimiento”. Esto es menos “peligroso” y más “eventualmente limitante para tu carrera”.
Exceso de confianza en SLOG espejado. El mirroring protege contra fallos de dispositivo, pero no añade protección contra pérdida de energía ni corrige un comportamiento de flush defectuoso del firmware.
Añadir SLOG para enmascarar un pool subdimensionado. Si tus vdevs principales no pueden seguir el ritmo de los commits TXG, el SLOG puede reducir la latencia aparente mientras empuja al pool hacia un backlog. Ese backlog termina como un precipicio.

Broma #2: Un SLOG sin protección contra pérdida de energía es como un paracaídas hecho de encaje—elegante, ligero, y lo último que quieres descubrir es que es “principalmente decorativo”.

Cómo funcionan realmente ZIL, SLOG, TXGs y las escrituras síncronas

Para operar con confianza SLOG, necesitas el modelo mental. Aquí está el que sobrevive a los incidentes.

Escrituras async: el camino feliz

La mayoría de las escrituras son asíncronas. La app escribe; el SO entrega datos a ZFS; ZFS pone los cambios en memoria (ARC y otras estructuras en memoria) y más tarde los vacía a disco como parte del commit de un transaction group. ZFS agrupa trabajo para ser eficiente: menos seeks, más escrituras en streaming, mejor compresión, mejor checksumming, mejor throughput general.

Para escrituras async, el reconocimiento no requiere almacenamiento durable. Por eso SLOG es irrelevante: ZFS no está esperando una escritura ZIL para que la aplicación continúe.

Escrituras sync: “Necesito que esto sobreviva a un crash”

Las escrituras síncronas (u operaciones que requieren commit síncrono) son diferentes. La app dice “no me digas que está escrito hasta que sea seguro.” ZFS debe proporcionar un punto de persistencia. No puede esperar un commit TXG completo por cada fsync—el rendimiento sería terrible—así que escribe un registro en el ZIL describiendo los cambios. Una vez que el registro ZIL está de forma segura en almacenamiento estable, ZFS puede reconocer la operación síncrona.

Más tarde, cuando el TXG se confirma, los bloques reales se escriben en sus ubicaciones finales en el pool y los registros ZIL correspondientes quedan obsoletos. El ZIL no es un log permanente; es un libro de promesas a corto plazo.

Dónde vive el ZIL sin un SLOG

Sin un dispositivo de log separado, el ZIL vive en los vdevs principales del pool. Eso significa que las escrituras síncronas compiten con todo lo demás: escrituras normales, lecturas, scrubs, resilvers, trabajo de metadatos. En discos giratorios, esto suele ser catastrófico para la latencia: la cabeza busca para escribir un pequeño registro, luego vuelve a la secuencia de trabajo y acabas de introducir I/O aleatorio en medio de un pipeline secuencial.

Qué cambia un SLOG

Añadir un SLOG mueve las escrituras del ZIL a un dispositivo dedicado, típicamente de baja latencia. Ahora las escrituras síncronas golpean el SLOG, se reconocen rápidamente y el pool principal continúa con el batching de TXG mayormente sin perturbaciones. El pool todavía debe escribir eventualmente los datos reales durante los commits TXG. SLOG no elimina la carga de escritura subyacente; desacopla la latencia de reconocimiento del throughput de commit a granel.

Por qué el tamaño de SLOG suele ser pequeño

Los registros del ZIL solo necesitan cubrir la ventana entre un reconocimiento sync y el siguiente commit TXG exitoso que incluya los datos correspondientes. En estado estable, esto son segundos, no horas. Por eso la mayoría de dispositivos SLOG pueden ser pequeños en capacidad pero deben ser excelentes en latencia y seguridad frente a pérdida de energía.

Qué pasa en un crash o pérdida de energía

Si el sistema se cae, ZFS importa el pool y reproduce los registros del ZIL para devolver el sistema de archivos a un estado consistente con respecto a las operaciones sync reconocidas. Si el dispositivo SLOG retuvo esos registros y está presente y consistente, obtienes corrección y un pequeño retraso en la importación dependiendo de cuánto haya que reproducir.

Si el dispositivo SLOG falta o está muerto, el comportamiento depende de qué exactamente pasó y cómo falló el vdev de log. Mejor caso: ZFS puede apoyarse en el pool y no pierdes escrituras sync reconocidas porque ya habían sido comprometidas (o el dispositivo falló limpiamente). Peor caso: tus clientes escucharon “tus datos están seguros” y no lo están. Por eso los dispositivos SLOG deben tratarse como componentes de durabilidad, no como juguetes de rendimiento.

Dos perillas que verás: `sync` y `logbias`

sync es una propiedad del dataset que afecta cómo ZFS trata las peticiones para comportamiento síncrono. Tiene valores como standard (por defecto), always y disabled. Estos no cambian lo que la app solicita; cambian cómo ZFS responde. Si colocas sync=disabled, estás eligiendo mentir a las aplicaciones que solicitaron durabilidad.

logbias es una propiedad de dataset que puede ser latency (por defecto) o throughput. Influye en cómo ZFS usa el log para ciertas cargas. Cambiarla mal puede anular un SLOG o desplazar trabajo de formas inesperadas. No es un interruptor mágico para “hacer SLOG más rápido”; es una pista sobre qué valoras.

Qué hace que un dispositivo SLOG sea bueno (y qué lo hace malo)

Los requisitos reales: consistencia de latencia y durabilidad honesta

Un buen dispositivo SLOG tiene:

Baja latencia para escrituras pequeñas síncronas (especialmente con alta variabilidad en profundidad de cola).
Protección contra pérdida de energía (PLP) para que las escrituras reconocidas sobrevivan a una pérdida abrupta de energía.
Comportamiento correcto de flush/FUA. ZFS depende de que el dispositivo respete correctamente barreras/flushes.
Resistencia suficiente para cargas sostenidas de escrituras síncronas.
Rendimiento predecible bajo estrés (garbage collection y throttling térmico son los asesinos silenciosos de “rinde bien en benchmarks”).

Un dispositivo SLOG malo suele ser “rápido en papel” pero carece de PLP o tiene firmware que trata el flush como una sugerencia. NVMe de consumo puede ser extremadamente rápido para escrituras asíncronas y aún así ser arriesgado para la durabilidad sync si usa cachés de escritura volátiles sin protección. La ruta SLOG es alérgica a las mentiras.

Espejar el SLOG: cuándo importa

Si no puedes tolerar perder escrituras síncronas reconocidas por la falla de un único dispositivo, espeja el SLOG. Esto es común en entornos corporativos donde las exportaciones NFS sostienen datastores de VM y un registro perdido se convierte en una historia de corrupción del sistema de archivos de la VM.

El mirroring no es opcional “por si acaso” si la expectativa del negocio es “las escrituras sync son seguras.” Es parte de hacer que el dispositivo de log sea tan fiable como el resto de tu diseño de almacenamiento.

Pero no confundas espejado con seguro

Dos dispositivos inseguros espejados crean una forma redundante de estar equivocados. Si ambos dispositivos reconocen flushes sin persistencia, puedes perder datos el doble de confiablemente. La propiedad no negociable es la protección contra pérdida de energía y el orden correcto de escrituras.

No gastes de más en capacidad

La capacidad del SLOG rara vez es el factor limitante. Lo que importa es el rendimiento y la seguridad. Si compras un NVMe “gaming” de 2 TB como dispositivo de log, compraste caro lo incorrecto. Una SSD empresarial más pequeña con PLP suele ser la respuesta correcta.

La colocación y la topología importan

Poner el SLOG detrás de un HBA inestable, un expander ya saturado o un controlador con trucos de caché de escritura puede borrar sus beneficios. El SLOG está en la ruta sync; la ruta sync necesita ser aburrida y determinista.

Tareas prácticas: comandos, salidas y cómo interpretarlas

Estos son los comandos que realmente ejecutas cuando alguien dice “ZFS está lento” y necesitas probar qué parte está lenta. Cada tarea incluye un comando y qué buscar. Ajusta nombres de pool/dataset a tu entorno.

Tarea 1: Confirmar si existe un SLOG y cómo está configurado

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:32:10 with 0 errors on Wed Dec 18 03:12:20 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-HDD_A               ONLINE       0     0     0
            ata-HDD_B               ONLINE       0     0     0
        logs
          mirror-1                  ONLINE       0     0     0
            nvme-INTEL_SLOG_A       ONLINE       0     0     0
            nvme-INTEL_SLOG_B       ONLINE       0     0     0

errors: No known data errors

Interpretación: Busca una sección logs. Si falta, no tienes un vdev de log separado. Si existe, anota si está espejado. También observa si el vdev de log muestra errores; un SLOG enfermo es un riesgo de corrección.

Tarea 2: Verificar el comportamiento sync del dataset (la propiedad más importante)

cr0x@server:~$ sudo zfs get -o name,property,value,source sync tank/vmstore
NAME          PROPERTY  VALUE     SOURCE
tank/vmstore  sync      standard  default

Interpretación: standard significa que ZFS respeta las solicitudes sync de la aplicación. always fuerza semánticas sync (más duradero, a menudo más lento). disabled es el modo “rápido y frágil”.

Tarea 3: Comprobar `logbias` porque cambia el comportamiento del log

cr0x@server:~$ sudo zfs get -o name,property,value,source logbias tank/vmstore
NAME          PROPERTY  VALUE    SOURCE
tank/vmstore  logbias   latency  default

Interpretación: latency suele ser correcto para cargas VM y bases de datos. throughput puede reducir el logging en algunos casos pero aumentar latencia sync o cambiar patrones. Trata cambios aquí como cambios en producción, porque lo son.

Tarea 4: Identificar si los clientes fuerzan sync (común con NFS)

cr0x@server:~$ sudo zfs get -o name,property,value,source sync tank/nfs
NAME      PROPERTY  VALUE     SOURCE
tank/nfs  sync      standard  local

Interpretación: Si ves sync=always en un dataset NFS, espera fuerte dependencia del SLOG. Si ves sync=disabled, espera que el informe postmortem incluya la palabra “corrupción”.

Tarea 5: Ver el I/O de ZFS en tiempo real y comprobar si el dispositivo de log está activo

cr0x@server:~$ sudo zpool iostat -v tank 1
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        1.20T  2.40T     50    900  3.2M  85.0M
  mirror-0                  1.20T  2.40T     50    520  3.2M  42.0M
    ata-HDD_A               -      -         25    260  1.6M  21.0M
    ata-HDD_B               -      -         25    260  1.6M  21.0M
logs                          -      -        0    380    0  14.0M
  mirror-1                    -      -        0    380    0  14.0M
    nvme-INTEL_SLOG_A         -      -        0    190    0   7.0M
    nvme-INTEL_SLOG_B         -      -        0    190    0   7.0M
--------------------------  -----  -----  -----  -----  -----  -----

Interpretación: Si tu carga es intensiva en sync, deberías ver operaciones de escritura en el vdev logs. Si logs muestra cero mientras las apps se quejan de latencia fsync, puede que no estés tratando con escrituras sync—o el dataset no está usando el SLOG como piensas.

Tarea 6: Comprobar latencia global del pool y comportamiento por vdev (detecta el disco lento)

cr0x@server:~$ sudo zpool iostat -v -l tank 5
                              capacity     operations     bandwidth    total_wait  disk_wait
pool                        alloc   free   read  write   read  write    ---------  ---------
tank                        1.20T  2.40T     80   1100  5.1M  95.0M      18ms       12ms
  mirror-0                  1.20T  2.40T     80    650  5.1M  48.0M      22ms       16ms
    ata-HDD_A               -      -         40    325  2.6M  24.0M      18ms       12ms
    ata-HDD_B               -      -         40    325  2.6M  24.0M      27ms       20ms
logs                          -      -        0    450    0  18.0M       1ms        1ms
  mirror-1                    -      -        0    450    0  18.0M       1ms        1ms
    nvme-INTEL_SLOG_A         -      -        0    225    0   9.0M       1ms        1ms
    nvme-INTEL_SLOG_B         -      -        0    225    0   9.0M       1ms        1ms

Interpretación: Esto muestra tiempo de espera. Si un disco tiene disk_wait significativamente mayor, puede arrastrar el vdev y el pool. Un SLOG no arreglará un vdev enfermo que no puede confirmar TXGs con suficiente rapidez.

Tarea 7: Confirmar si se generan escrituras sync en absoluto (micro-prueba rápida con fsync)

cr0x@server:~$ cd /tank/vmstore
cr0x@server:/tank/vmstore$ sudo bash -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:/tank/vmstore$ /usr/bin/time -f "elapsed=%e sec" bash -c 'dd if=/dev/zero of=./fsync.test bs=4k count=4096 conv=fdatasync'
4096+0 records in
4096+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.42 s, 40.0 MB/s
elapsed=0.42 sec

Interpretación: conv=fdatasync fuerza un sync al final. Ejecuta esto con y sin SLOG (o en un host comparable). Si no ves mejora, o bien el pool ya es rápido en sync, o estás limitado por otro recurso (CPU, red, presión de TXG).

Tarea 8: Observar comportamiento de TXG y buscar presión en commits (Linux OpenZFS)

cr0x@server:~$ grep -E "txg|zil" /proc/spl/kstat/zfs/arcstats | head
txg_sync                       4    0
txg_quiesce                    4    0
txg_wait_synced                4    0
zil_commit                     4    0

Interpretación: Los contadores varían por versión, pero si ves mucho tiempo esperando a que TXGs se sincronicen (o commits ZIL), tu problema puede ser “el pool no puede vaciar lo suficientemente rápido”, no “falta SLOG”. En producción, usa tu pipeline de telemetría normal; esta es la vista “estoy en la caja ahora mismo”.

Tarea 9: Comprobar si el dispositivo de log es realmente rápido en flushes (salud básica del dispositivo)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,25p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       INTEL SSDPED1D280GA
Serial Number:                      BTKA1234567F280G
Firmware Version:                   EDF1470C
NVMe Version:                       1.3
...
Critical Warning:                   0x00
Temperature:                        36 Celsius
Available Spare:                    100%
Percentage Used:                    2%
Data Units Written:                 134,221 [68.7 GB]

Interpretación: Buscas un dispositivo sano con bajo desgaste de medio. El SLOG puede soportar presión continua de escritura; los dispositivos de consumo pueden desgastarse rápido en entornos intensivos en sync.

Tarea 10: Añadir un SLOG espejado de forma segura (ejemplo)

cr0x@server:~$ sudo zpool add tank log mirror /dev/disk/by-id/nvme-INTEL_SLOG_A /dev/disk/by-id/nvme-INTEL_SLOG_B
cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-HDD_A               ONLINE       0     0     0
            ata-HDD_B               ONLINE       0     0     0
        logs
          mirror-1                  ONLINE       0     0     0
            nvme-INTEL_SLOG_A       ONLINE       0     0     0
            nvme-INTEL_SLOG_B       ONLINE       0     0     0

Interpretación: Usa rutas de dispositivo estables (/dev/disk/by-id) para que un reinicio no reordene nombres. Después de añadirlo, vigila zpool iostat para confirmar que la carga lo usa.

Tarea 11: Quitar un SLOG (y cómo se ve “seguro”)

cr0x@server:~$ sudo zpool remove tank mirror-1
cr0x@server:~$ sudo zpool status tank | sed -n '1,35p'
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-HDD_A               ONLINE       0     0     0
            ata-HDD_B               ONLINE       0     0     0

errors: No known data errors

Interpretación: Quitar el vdev de log está soportado en OpenZFS moderno. Hazlo en una ventana calmada; vigila la latencia de clientes. Si el rendimiento colapsa, has confirmado que la carga es sensible a sync.

Tarea 12: Identificar “tormentas de sync” desde NFS o cargas VM

cr0x@server:~$ sudo nfsstat -s | sed -n '1,25p'
Server rpc stats:
calls      badcalls   badfmt     badauth    badclnt
214748     0          0          0          0

Server nfs v4:
null       compound
0          198322

Server nfs v3:
null       getattr    setattr    lookup     access     readlink
0          4123       1882       22091      7851       0
read       write      create     mkdir      symlink    mknod
70221      88011      312        12         0          0
commit     remove     rename     link       readdir    readdirplus
65002      401        33         0          112        909

Interpretación: Muchas llamadas NFS commit pueden correlacionar con presión sync. Combina esto con zpool iostat para ver si el SLOG absorbe escrituras de log o si los vdevs principales reciben el impacto.

Tarea 13: Validar si el dataset está forzando sync accidentalmente

cr0x@server:~$ sudo zfs get -r -o name,property,value,source sync tank | sed -n '1,30p'
NAME            PROPERTY  VALUE     SOURCE
tank            sync      standard  default
tank/nfs        sync      always    local
tank/vmstore    sync      standard  default
tank/backups    sync      standard  default

Interpretación: Un dataset con sync=always puede dominar el rendimiento percibido del pool. A veces está bien; a veces es una copia cargo-culted de un post de foro de hace años.

Tarea 14: Detectar un pool que se queda atrás en commits TXG (retropresión clásica)

cr0x@server:~$ sudo zpool iostat tank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        1.20T  2.40T     40   2200  2.4M  240M
tank        1.20T  2.40T     35   2400  2.1M  260M
tank        1.20T  2.40T     38   2600  2.3M  280M

Interpretación: Alto bandwidth de escritura sostenido no es inherentemente malo, pero si las aplicaciones se bloquean en sync mientras el bandwidth es alto, puede indicar que los TXGs tardan más en sincronizarse (presión de datos sucios) y te estás acercando al punto donde ZFS debe limitar. Un SLOG puede ocultar el inicio de este problema mientras el pool acumula trabajo silenciosamente.

Guía rápida de diagnóstico

Esta es la secuencia “tengo 10 minutos antes de que la llamada de incidente se convierta en un ritual de culpas”. Estás tratando de responder a una pregunta: ¿Es el cuello de botella la latencia sync, o es otra cosa?

Primero: determina si la carga es intensiva en sync

Comprueba propiedades del dataset: zfs get sync,logbias <dataset>.
Observa la actividad del vdev de log: zpool iostat -v <pool> 1. Si el vdev de log está inactivo durante el “dolor sync”, el SLOG no está en la ruta.
Busca comportamiento del cliente (llamadas NFS commit, tasas de fsync de bases de datos, patrones de almacenamiento VM). Si no puedes observar la app, al menos observa el lado servidor: estadísticas NFS, iostat, latencia.

Segundo: si es intensiva en sync, decide si el SLOG es el cuello de botella

Usa latencia por vdev: zpool iostat -v -l <pool> 5. Si el vdev de log tiene espera mayor de lo esperado, no está haciendo su trabajo.
Comprueba salud y errores del dispositivo: zpool status -v y smartctl.
Confirma que el dispositivo de log no esté detrás de un path más lento (lanzaderas PCIe compartidas, HBA saturado, multipath mal configurado).

Tercero: si SLOG parece bien, la ruta de commit del pool probablemente es el cuello de botella

Comprueba latencia de vdevs principales en zpool iostat -l. Un HDD lento, una SSD moribunda o un vdev en resilver dominarán.
Busca trabajo en segundo plano: scrub, resilver, snapshots pesados, send/recv, saturación de CPU por compresión/cifrado.
Comprueba presión de memoria: si la máquina tiene poca RAM o ARC está limitado, ZFS puede alcanzar límites de datos sucios y aplicar throttling severo.

Cuarto: decide qué cambiar (orden de prioridad)

Si es intensiva en sync y no hay SLOG: añade un SLOG PLP espejado adecuado.
Si es intensiva en sync y hay SLOG pero es de consumo: reemplázalo.
Si la ruta de commit es lenta: arregla la topología de vdev, retira el disco lento, añade mirrors, reduce el ancho de RAIDZ para cargas IOPS, o escala horizontalmente.
Si el problema es “alguien forzó sync en todas partes”: ajusta propiedades del dataset/export/app con una postura clara sobre durabilidad.

Tres micro-historias del mundo corporativo

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

El ticket estaba redactado cortésmente: “Corrupción intermitente del sistema de archivos de VM en eventos de pérdida de energía.” El equipo de almacenamiento reaccionó a la defensiva—nadie disfruta que le digan que su plataforma está comiendo datos—pero el patrón era demasiado limpio. Solo ocurría tras un reinicio repentino de los PDU de un rack durante pruebas de mantenimiento. Los reinicios normales estaban bien.

El entorno era un datastore NFS respaldado por ZFS para un clúster hipervisor. Tenían un dispositivo SLOG y estaban orgullosos de ello. “Compramos NVMe, es rápido,” dijeron, que es la primera frase de muchos postmortems. El SLOG era un NVMe de consumo único porque “es solo un log.” El pool era mirrors de HDD, respetable para capacidad y mayormente bueno para throughput, pero la latencia sync era su punto doloroso, así que SLOG parecía la palanca correcta.

Tras algunas reproducciones y un silencio incómodo, la lección emergió: el NVMe reconocía flushes rápido pero no persistía de forma fiable los últimos momentos de escrituras durante una pérdida abrupta de energía. Los hipervisores habían recibido la promesa de que “tus commits están seguros,” porque NFS y los sistemas de archivos invitados dependen de esa promesa. Luego la caja perdió energía. Al importar, ZFS reprodujo lo que tenía en el log. Lo que no tenía era el último fragmento que el dispositivo había fingido que era durable.

La solución no fue heroica. Reemplazaron el SLOG por un dispositivo empresarial con PLP y lo espejaron, porque no querían un único componente que fuera el eje del “ups”. También dejaron de decir “es solo un log.” En ZFS, el log es parte de tu contrato de durabilidad.

Lo que cambió operativamente fue más importante que el hardware: documentaron qué significaba “sync safe” para sus exportaciones NFS, añadieron simulación de fallo de energía a sus pruebas de aceptación y escribieron una entrada de runbook que empezaba con “Confirmar SLOG tiene PLP.” Los incidentes de corrupción cesaron, y lo único que perdieron fue la ilusión de que las piezas de rendimiento pueden tratarse como accesorios.

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

Una aplicación relacionada con finanzas tenía ráfagas periódicas: fin de mes, fin de trimestre, fin de año—la trinidad sagrada de “¿por qué va lento hoy?” Corría en VMs sobre NFS respaldado por ZFS. Durante las ráfagas, la latencia se disparaba y la app hacía timeouts. Alguien descubrió que poner sync=disabled hacía que los gráficos se vieran preciosos. Lo implementaron rápidamente porque el negocio gritaba y el cambio era reversible. En justicia, funcionó. También sembró una mina.

El revés llegó semanas después en forma de “reiniciamos tras updates de kernel y faltan los últimos minutos de transacciones de la app.” No corruptas. No parcialmente escritas. Simplemente faltaban. La base de datos había emitido escrituras sync en commit, el almacenamiento mintió y el universo cobró la deuda en el siguiente límite de crash.

El equipo intentó argumentar que era aceptable porque la ventana faltante era pequeña. Pero la definición de “pequeña” del negocio es “ninguna,” especialmente cuando hay auditores. Más sutilmente, se dieron cuenta de que habían entrenado al equipo de aplicaciones a asumir “el almacenamiento ahora es rápido,” así que aumentaron concurrencia y redujeron retries. Cuando volvieron a las semánticas correctas de sync, el precipicio de rendimiento fue más empinado que antes porque otros perillas se habían movido en el ínterin.

La solución a largo plazo fue aburrida: un SLOG real, espejado, con PLP, dimensionado adecuadamente, más cambios en la app para agrupar commits más inteligentemente. También establecieron SLOs explícitos para latencia de commit y midieron tasas de fsync para que “sync” dejara de ser una propiedad mística.

La lección operativa: si “optimizas” cambiando la corrección, no optimizaste; pediste prestado tiempo a interés variable. ZFS te permite hacerlo. ZFS también te permite explicarlo después.

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

Se estaba expandiendo un clúster de almacenamiento. Nada dramático: añadir estantes, añadir vdevs, reequilibrar cargas con el tiempo. El equipo tenía un ritual: después de cualquier cambio de hardware, ejecutaban una suite de verificación corta—chequeos de estado del pool, una sonda de latencia de escritura sync y una carga de cliente simulada que producía un flujo constante de operaciones fsync. Tomaba 20 minutos y todos se quejaban hasta el día en que importó.

Durante la expansión, la latencia sync se duplicó silenciosamente. No lo suficiente para disparar alertas inmediatamente, pero sí para aparecer como picos en la cola tail en operaciones VM. La suite aburrida de verificación lo detectó. El equipo comparó resultados con su línea base y vio que el vdev de log ahora mostraba mayores tiempos de espera de lo habitual.

El culpable no era ZFS en absoluto. Una actualización de firmware en el backplane PCIe del nuevo servidor había cambiado la negociación de enlace, y la ranura NVMe destinada al SLOG funcionaba a un ancho de lanes reducido. El SLOG seguía “rápido” en pruebas de throughput, porque los números secuenciales se ven bien, pero su latencia bajo cargas de flush se degradó, que es lo único por lo que SLOG está pagado.

Mudaron los dispositivos SLOG a otras ranuras, confirmaron ancho de lanes, volvieron a ejecutar la prueba de latencia y los picos tail desaparecieron. Sin outage, sin impacto al cliente, sin llamada de incidente. El único artefacto visible fue una línea en el registro del cambio: “Corregido ancho de lanes NVMe; restaurada línea base de latencia sync.”

Esto es lo que la competencia parece en producción: no heroísmos, sino pequeñas pruebas que evitan que aprendas sobre negociación PCIe mediante mensajes enfadados en Slack.

Errores comunes, síntomas y soluciones

Esta sección está escrita en el lenguaje de los síntomas, porque así es como te encuentras con SLOG en la vida real.

Error 1: Añadir un SLOG esperando escrituras a granel más rápidas

Síntomas: Sin mejora notable; los trabajos de backup siguen lentos; el throughput secuencial sin cambios; el vdev de log muestra actividad mínima.

Por qué: La carga es async. SLOG solo acelera los reconocimientos de escrituras sync.

Solución: Quita el SLOG si añade riesgo sin beneficio, o consérvalo solo si tienes cargas sync que no has medido aún. Optimiza layout de vdev, recordsize, compresión o la red si la carga es I/O a granel.

Error 2: Usar una SSD/NVMe de consumo sin PLP como SLOG

Síntomas: Corrupción rara pero catastrófica o transacciones faltantes tras pérdida repentina de energía; reinicios limpios bien; import tras crash a veces más lento; inconsistencias post-crash.

Por qué: El dispositivo reconoce escrituras y flushes que no son realmente persistentes.

Solución: Reemplaza por un dispositivo empresarial con PLP y comportamiento de flush probado. Espeja si necesitas disponibilidad y reducir la probabilidad de pérdida de log por fallo de dispositivo.

Error 3: SLOG de disco único para una carga que trata sync como sagrada

Síntomas: Tras la falla del SLOG, los clientes ven errores I/O o experimentan un cambio disruptivo en rendimiento; exposición al riesgo alrededor de escrituras reconocidas; ansiedad durante reemplazos de dispositivo.

Por qué: El dispositivo de log ahora forma parte de la ruta de durabilidad; un punto único de fallo es una apuesta.

Solución: Espeja el SLOG. Mantén repuestos. Prueba procedimientos de reemplazo. Si espejar no es posible, replantea si la carga debe estar en esta arquitectura.

Error 4: Poner `sync=disabled` para que los gráficos se vean verdes

Síntomas: Mejora de rendimiento seguida de datos faltantes/corruptos tras crash; los auditores se interesan por tus planes de fin de semana.

Por qué: Le dijiste a ZFS que reconozca escrituras sync sin hacerlas duraderas.

Solución: Ajusta a sync=standard (o always si se requiere). Añade un SLOG apropiado y/o cambia el comportamiento de la app (batching, group commit) para reducir la frecuencia de fsync.

Error 5: Tratar SLOG como una “caché” y sobredimensionarlo

Síntomas: Sin beneficio de gran capacidad SLOG; presupuesto gastado sin reducción medible de latencia.

Por qué: SLOG guarda una ventana corta de registros ZIL, no todas las escrituras.

Solución: Dimensiona para latencia y seguridad, no para capacidad. Gasta en calidad (PLP, endurance), no en terabytes.

Error 6: Ignorar la capacidad del pool para confirmar TXGs

Síntomas: Latencia sync mejora inicialmente con SLOG, luego el sistema sufre paradas periódicas; el throughput parece bien pero las apps hacen timeouts; “todo se congela cada pocos segundos.”

Por qué: El SLOG desacopla el reconocimiento pero no la necesidad eventual de confirmar datos en el pool. Si el pool no puede seguir, aplicará throttling.

Solución: Mejora rendimiento de escritura del pool (más vdevs, mirrors, discos más rápidos), reduce amplificación de escritura (recordsize, compresión) o reduce presión de carga. SLOG no sustituye un throughput de commit adecuado.

Error 7: Confundir L2ARC con SLOG

Síntomas: “Añadimos un SLOG y las lecturas siguen lentas.”

Por qué: SLOG es para reconocimientos de escritura síncrona. L2ARC es una caché de lectura secundaria. Problemas distintos, herramientas distintas.

Solución: Si las lecturas son lentas, investiga ratio de aciertos ARC, propiedades del dataset, IOPS de lectura por vdev y posiblemente L2ARC. No compres un dispositivo de log para un problema de lectura.

Listas de verificación / plan paso a paso

Lista: Decidir si necesitas un SLOG en absoluto

Medir intensidad sync: Identifica apps intensivas en fsync (bases de datos, VM/NFS) y si realmente están limitadas por latencia sync.
Observar actividad del log: Si ya tienes un SLOG, verifica que se use. Si no lo tienes, estima el beneficio potencial midiendo latencia fsync ahora.
Descartar cuellos obvios: Saturación de red, saturación de CPU, un scrub/resilver o un disco fallando pueden dominar los síntomas.
Decidir postura de durabilidad: Confirma que necesitas semánticas sync correctas. Si no, documenta explícitamente; no corras inseguro por accidente.

Lista: Elegir el dispositivo SLOG correcto

PLP es obligatorio: Elige dispositivos con protección contra pérdida de energía y firmware empresarial.
Prefiere baja latencia sobre gran capacidad: Tu objetivo es latencia de flush rápida y consistente.
Comprueba endurance: Cargas sync pueden escribir continuamente; asegúrate de que TBW/DWPD sea apropiado.
Evita acantilados de rendimiento: Prueba bajo carga sostenida; vigila throttling térmico o picos de garbage collection.
Espeja si la corrección importa: Particularmente para datastores VM NFS y bases de datos críticas.

Plan paso a paso: Añadir un SLOG de forma segura en producción

Base line primero: Captura percentiles de latencia desde tu monitorización y ejecuta una pequeña prueba fsync en el dataset.
Confirma rutas de dispositivo: Identifica dispositivos de log vía /dev/disk/by-id para evitar renombrados.
Añade log espejado: Usa zpool add POOL log mirror DEV1 DEV2.
Valida uso: Durante la carga sync, verifica escrituras en el vdev log con zpool iostat -v.
Re-baseline: Ejecuta la misma prueba fsync; compara distribuciones de latencia, no solo promedios.
Documenta el contrato: Registra que “las escrituras sync son duraderas y están protegidas por SLOG PLP espejado,” y anota procedimientos de reemplazo.

Plan paso a paso: Si sospechas que SLOG te perjudica

Comprueba errores: zpool status -v y estadísticas SMART.
Comprueba latencia del log: zpool iostat -v -l POOL 5. Si la espera del log es alta, tienes un problema.
Considera remoción temporal: En una ventana controlada, zpool remove POOL LOGVDEV y mide comportamiento. Esto es diagnóstico, no un plan permanente.
Reemplaza por hardware adecuado: Si confirmas que SLOG es el cuello de botella, cámbialo por un dispositivo diseñado para cargas sync.

Preguntas frecuentes

1) ¿Añadir un SLOG hace que las escrituras ZFS sean más rápidas?

Sólo las escrituras síncronas. Mejora la latencia de operaciones que deben reconocerse como durables (fsync, O_SYNC, patrones NFS con muchos commits). No aumenta por sí mismo el throughput de escrituras asíncronas a granel.

2) ¿SLOG es lo mismo que ZIL?

No. ZIL es el mecanismo y existe en cada pool. SLOG es un dispositivo separado donde se almacenan registros ZIL para mejorar la latencia de escrituras síncronas.

3) ¿Qué tamaño debería tener un SLOG?

Usualmente pequeño. Estás almacenando una ventana rodante corta de intentos sync hasta que los TXGs cometan. El tamaño rara vez es la limitación; la latencia y la seguridad sí lo son.

4) ¿Debería espejar mi SLOG?

Si te importa no perder escrituras sync reconocidas por la falla de un único dispositivo, sí. Para datastores VM sobre NFS y bases de datos críticas, SLOG espejado es una elección común “correcta por diseño”.

5) ¿Puede un SLOG reducir la amplificación de escritura en el pool principal?

No realmente. Cambia dónde se registra la intención sync, no la cantidad de datos que el pool debe escribir eventualmente. Puede hacer que el patrón I/O del pool sea menos caótico al eliminar pequeñas escrituras sync de los vdevs principales, lo que indirectamente ayuda, pero no elimina la carga.

6) ¿Cuál es la diferencia entre SLOG y L2ARC?

SLOG acelera reconocimientos de escrituras síncronas. L2ARC es una caché de lectura secundaria. Confundirlos es común y caro.

7) ¿Es `sync=disabled` aceptable alguna vez?

Sólo si estás dispuesto a perder transacciones recientes en crash y lo has aceptado explícitamente (y documentado). Muchos workloads “scratch” internos pueden vivir con eso. La mayoría de bases de datos de producción y datastores VM no deberían.

8) ¿Por qué empeoró mi rendimiento tras añadir un SLOG?

Causas comunes: el dispositivo de log tiene mala latencia de flush, se está limitando térmicamente, está detrás de un path de controlador restringido, o la carga no era sync y solo añadiste sobrecarga/complicación. Mide latencia del vdev de log con zpool iostat -l y valida que las escrituras sync realmente lo estén usando.

9) ¿Puedo particionar un dispositivo y usar parte como SLOG?

Técnicamente posible, pero operacionalmente arriesgado a menos que seas disciplinado. Dispositivos compartidos pueden crear contención y acoplamiento de fallos. La ruta sync quiere aislamiento y predictibilidad.

10) ¿Qué ajustes de dataset suelen ir con un SLOG para VM/NFS?

Usualmente sync=standard (o always si tu entorno lo requiere) y logbias=latency. El resto depende de la carga: recordsize, compresión, atime y ajustes de export NFS importan, pero no son específicos de SLOG.

Conclusión

Un ZFS SLOG es uno de esos componentes que parece una mejora simple hasta que entiendes qué está mejorando: un límite de corrección. Cuando tu carga es intensiva en sync, un SLOG adecuado puede ser transformador, especialmente para virtualización respaldada por NFS y bases de datos con muchos commits. Cuando tu carga es async, es peso muerto. Y cuando eliges el dispositivo equivocado—o usas el dispositivo correcto de la forma equivocada—se convierte en una forma elegante de transformar “tuning de rendimiento de almacenamiento” en “conversación sobre recuperación de datos”.

La regla operativa es simple: mide primero, optimiza lo correcto y trata el dispositivo de log como parte de tu historia de durabilidad, no como una misión secundaria. Si haces eso, SLOG es aburrido en el mejor sentido: silenciosamente hace rápidas las escrituras sync, y no pasa nada emocionante.