ZFS usando NVMe como SLOG: cuándo es perfecto y cuándo es excesivo

SLOG en una frase (y por qué importa esa frase)

Un SLOG es un dispositivo dedicado para los registros ZIL de ZFS que acelera las escrituras síncronas al confirmar la intención rápida y de forma segura, sin esperar al pool principal.

Léelo otra vez y subraya “síncronas”. Si tu carga es mayoritariamente escrituras asíncronas, lecturas o está limitada por CPU, un SLOG NVMe es un placebo caro. Si tu carga está dominada por latencia de escrituras síncronas (NFS con sync, datastores ESXi, algunas bases de datos, ciertas cargas de VM), un buen SLOG es como un truco.

Además: ZFS ya tiene un ZIL incluso sin un SLOG. Por defecto el ZIL vive en los discos del pool. Añadir un SLOG no “activa el registro”; reubica la parte caliente del camino de escritura síncrona hacia algo más rápido (y, idealmente, más seguro).

Qué acelera realmente el SLOG (y qué nunca lo hará)

El camino de escritura síncrona en lenguaje sencillo

Cuando una aplicación hace una escritura síncrona, está pidiendo una promesa al stack de almacenamiento: “Si dices ‘hecho’, estos datos sobrevivirán a un fallo”.
ZFS cumple esa promesa escribiendo un pequeño registro que describe la escritura (la “intención”) en el ZIL, y luego reconoce la escritura a la aplicación.
Más tarde, durante el siguiente transaction group (TXG) sync, ZFS escribe los bloques reales en el pool principal y libera las entradas del ZIL.

Sin SLOG, esas escrituras al ZIL golpean los mismos vdevs que guardan tus datos. Con un SLOG, esas escrituras van al dispositivo de logs en su lugar, que puede tener una latencia dramáticamente menor que un RAIDZ de HDDs o incluso SSDs SATA.

Lo que ayuda un SLOG

• Latencia de escritura síncrona: lo que los clientes sienten como “mi VM va lenta” o “NFS se siente pegajoso”.
• IOPS de escrituras síncronas: especialmente operaciones muchas y pequeñas con fsync intensivo.
• Contención en los vdevs del pool: mover el tráfico del ZIL puede reducir la presión de escrituras aleatorias en el pool principal durante ráfagas con muchas sincronizaciones.

Lo que no ayuda un SLOG

• Lecturas (eso es ARC, L2ARC y el layout de tus vdevs).
• Escrituras asíncronas (ZFS las bufferiza en RAM y vacía por TXG; SLOG no está en ese camino crítico).
• Rendimiento secuencial (eso depende principalmente del ancho de banda de los vdevs).
• Cargas limitadas por CPU (checksum, compresión, cifrado o simplemente un host sobrecargado).

Una verdad seca: un SLOG no puede mejorar un diseño de pool malo. Puede hacer las escrituras síncronas menos miserables mientras planeas un layout mejor.

Broma #1: Comprar un SLOG para una carga asíncrona es como instalar un turbo en un coche aparcado. Es hardware impresionante, y aún así no va a ningún sitio.

Cuándo NVMe como SLOG es perfecto

1) Exports NFS donde los clientes exigen semántica sync

Muchos clientes NFS (y administradores) insisten en escrituras seguras, y NFS a menudo se usa para soportar cosas alérgicas a la pérdida de datos: datastores de VM, almacenes de artefactos de build, directorios home con “mi editor hace fsync”, etc.
Si tu export está configurado como sync (o el comportamiento del cliente efectivamente fuerza sync), la latencia de confirmar esos registros ZIL es la experiencia del usuario.

Este es el triunfo canónico del SLOG: un pool de HDDs (o un RAIDZ de SSDs) sirviendo NFS con tráfico constante de fsync. Pon un NVMe de baja latencia con protección contra pérdida de energía (PLP) delante de eso, y notarás la diferencia.

2) Almacenamiento para virtualización con muchas escrituras síncronas pequeñas

Las plataformas VM y los sistemas de archivos invitados generan escrituras síncronas más a menudo de lo que piensas. Journaling, actualizaciones de metadata, vaciados de bases de datos dentro de VMs, comportamiento del SO invitado y ajustes de durabilidad a nivel de aplicación se acumulan.
Un buen SLOG puede convertir “latencia de escrituras síncronas aleatorias de 8K de 10–20ms” en “sub-milisegundos a pocos milisegundos”, que es la diferencia entre “aceptable” y “por qué se congela la interfaz”.

3) Bases de datos que realmente dependen de fsync()

Algunas cargas de bases de datos están dominadas por la latencia de commit duradero. Si la base de datos está correctamente configurada para requerir durabilidad (y quieres eso), estás en terreno síncrono.
Un SLOG rápido y seguro puede reducir la varianza de latencia de commit—la varianza es lo que causa picos de cola y paradas visibles por el usuario.

4) Tienes un pool principal lento que no puedes rehacer aún

A veces heredas un pool que es “RAIDZ2 en HDD nearline” porque alguien optimizó por coste por TB y olvidó que la latencia también cuesta.
Un SLOG NVMe puede ser un vendaje táctico: reduce el dolor para consumidores síncronos mientras planificas la reparación real (más vdevs, mirrors, special vdevs o una arquitectura distinta).

5) Necesitas durabilidad predecible bajo carga

Los mejores dispositivos SLOG no son solo rápidos; son consistentes. El rendimiento de escrituras síncronas trata tanto de latencia de cola como de latencia media.
Los SSDs commodity pueden verse bien hasta que golpean una recolección de basura interna o un cliff de escritura, y entonces tu “escritura durable” de repente toma 50ms. Los usuarios lo notan.

Cuándo el SLOG es exagerado

1) Tu carga es mayoritariamente escrituras asíncronas

Copias de archivos, ingestión de medios, backups que fluyen secuencialmente, escrituras de object storage por lotes, pipelines analíticos que bufferizan—estas normalmente no bloquean en commits síncronos.
ZFS absorberá mucho de eso en ARC y volcará en los límites de TXG. Un SLOG no entra en la sala.

2) En realidad estás limitado por lecturas o metadata

La clásica mala diagnosis: “el almacenamiento es lento” cuando el cuello de botella son fallos de caché, pocos vdevs o metadata dispersa en HDDs.
Puede que necesites más mirrors, un special vdev para metadata/bloques pequeños, más RAM para ARC o mejor ajuste de recordsize. Ninguno de esos es un SLOG.

3) Puedes (y deberías) arreglar el requisito de sync en su lugar

A veces la medida correcta es política, no hardware: ¿realmente necesitas sync en ese dataset? ¿Estás exportando NFS con sync porque “siempre se ha hecho así”, mientras los datos no son críticos y ya están replicados?
Si puedes tolerar una pequeña ventana de pérdida tras un crash, configurar sync=disabled en el dataset adecuado te dará una mejora mayor que cualquier SLOG. También aumenta el riesgo. No lo hagas a la ligera.

4) No tienes protección contra pérdida de energía, así que eres “rápido pero mentiroso”

El trabajo entero de un SLOG es hacer que las escrituras síncronas sean seguras. Si tu dispositivo miente sobre flushes, o pierde datos en un corte de energía, puedes terminar reconociendo escrituras durables que nunca existieron. Eso no es un bug de rendimiento. Es corrupción con buen marketing.

5) Tu pool ya es lo suficientemente rápido para sync

Si estás en mirrors totalmente SSD con latencia sólida y tu cuello de botella de escrituras síncronas ya es pequeño, la ganancia marginal de un SLOG puede ser difícil de justificar.
Mide primero. Si p99 sync lat está ya en los pocos milisegundos y la carga no se queja, tienes mejores sitios para gastar tu presupuesto de complejidad.

Hechos e historia interesantes que cambian decisiones

1. ZFS nació en Sun a mediados de los 2000 con un foco explícito en integridad end-to-end: checksums, copy-on-write y semántica transaccional no fueron ideas secundarias.
2. El ZIL existe en cada pool tanto si añades un SLOG como si no. La parte “separada” es opcional; el intent log no lo es.
3. Las escrituras al SLOG suelen ser de corta duración: las entradas del ZIL son material de replay para crashes, no un journal a largo plazo como el de ext4. Se descartan tras el commit del TXG.
4. Las primeras guías “SSD como log” provinieron de la era en que los pools eran HDD y los SSD eran caros; la diferencia de rendimiento para escrituras síncronas era masiva y obvia.
5. La protección ante pérdida de energía (PLP) se convirtió en la línea divisoria entre “un SSD consumer parece bien” y “un SSD enterprise es aburridamente correcto”. La corrección del ZIL depende del comportamiento honesto de flush.
6. El SLOG no necesita gran capacidad porque solo necesita mantener una pequeña ventana de escrituras síncronas pendientes—típicamente segundos—hasta el commit del TXG.
7. Espejar un SLOG es sobre disponibilidad, no velocidad: si el SLOG muere, el pool puede seguir funcionando, pero pierdes el camino rápido para escrituras síncronas (y puedes tener una ventana de riesgo durante el reemplazo).
8. NVMe cambió la conversación haciendo la baja latencia accesible, pero también facilitó comprar el dispositivo equivocado: NVMe consumer es rápido, pero PLP y latencia consistente son lo difícil.
9. El “sync=disabled” de ZFS es famoso porque puede hacer que los benchmarks luzcan heroicos mientras cambia silenciosamente las garantías de durabilidad. No es gratis; es un contrato distinto.

Requisitos de hardware: latencia, PLP, resistencia y por qué “rápido” no es suficiente

La latencia vence al throughput

El rendimiento del SLOG se trata de qué tan rápido el dispositivo puede confirmar pequeñas escrituras y flusharlas de forma segura. Te importan:
baja latencia de escritura, baja latencia de flush y latencia de cola estable. Un dispositivo que hace 7GB/s en escrituras secuenciales pero se queda bloqueado en flush es un mal SLOG.

La protección contra pérdida de energía (PLP) es innegociable para cargas síncronas serias

Con escrituras síncronas, la aplicación apuesta sus datos a que tu stack de almacenamiento dice la verdad. PLP ayuda a asegurar que los datos reconocidos como durables sobrevivan un corte de energía repentino.
En SSDs empresariales, eso suele respaldarse con condensadores y firmware diseñado para volcar buffers volátiles a NAND.

¿Puedes usar un NVMe consumer como SLOG? Sí. ¿Deberías hacerlo para cargas síncronas críticas para el negocio? No, salvo que estés cómodo explicando al equipo de respuesta a incidentes por qué un “commit durable” se evaporó. Usa la herramienta correcta.

La resistencia importa, pero menos de lo que la gente teme

Las escrituras al SLOG pueden ser intensivas, pero el volumen total depende de cuánto tráfico de escrituras síncronas generes realmente. El asesino no son los bytes totales; es la tasa sostenida de escritura más los flushes, más el peor comportamiento bajo carga continua.
Aun así: elige un dispositivo con resistencia real, no una ganga que esté a un bug de firmware de una mala semana.

Factor de forma y conectividad importan operacionalmente

U.2/U.3 o M.2 empresarial con refrigeración y monitorización adecuadas es más fácil de operar en producción que un stick consumer enterrado bajo una GPU.
También considera hot-swap y cómo lo reemplazarás a las 2 a.m. sin convertir “reemplazo de dispositivo de logs” en “ventana de mantenimiento del host”.

Cita (idea parafraseada), Werner Vogels: Diseñas sistemas asumiendo que las cosas fallan; la fiabilidad viene de esperar fallos y recuperarse rápido.

Dimensionamiento, espejado y opciones de topología

¿De qué tamaño debe ser un SLOG?

Más pequeño de lo que piensas. El SLOG solo necesita absorber la cantidad máxima de escrituras síncronas pendientes entre los TXG sync.
El timeout por defecto de TXG suele ser alrededor de 5 segundos. Incluso si tienes cientos de MB/s de escrituras síncronas, el espacio necesario no es enorme.
En la práctica, 8–32GB de espacio efectivo de log suele ser suficiente; la gente despliega 100–400GB porque eso es lo que trae el SSD, no porque ZFS lo necesite.

Pero no lo dejes demasiado justo. Deja margen para picos, y recuerda que el rendimiento puede degradarse si el dispositivo está casi lleno o muy fragmentado internamente.

Espeja el SLOG cuando el downtime o el riesgo sean caros

Un SLOG único es un punto único de fallo de rendimiento. Si muere, tu pool sigue, pero las escrituras síncronas vuelven a los vdevs principales y la latencia puede dispararse.
Espejar el SLOG mantiene el camino rápido vivo ante la falla de un dispositivo y reduce el drama de “lo reemplazamos y todo va lento hasta que resilveriza”.

No confundas “log vdev” con “special vdev”

El SLOG es para ZIL (registros de intención síncrona). Un special vdev es para metadata y bloques pequeños (y puede cambiar el juego en pools HDD con mucho I/O de metadata).
Resuelven problemas distintos. Comprar un SLOG cuando necesitabas un special vdev es un clásico error caro.

Particionar un dispositivo para SLOG es posible—a menudo una mala costumbre

Sí, puedes particionar un NVMe y usar una pequeña porción como SLOG. No, no deberías hacerlo a la ligera en producción.
Mezclar cargas en el mismo dispositivo aumenta la varianza y complica los dominios de fallo. Si debes hacerlo, aísla mediante dispositivos separados y mantiene el comportamiento del SLOG predecible.

Broma #2: Particionar un único NVMe consumer en “SLOG + L2ARC + swap” es el equivalente en almacenamiento a usar un paracaídas para dos personas—creativo, pero el aterrizaje se pone raro.

Tareas prácticas: comandos, salidas y decisiones

Estos son los chequeos que hago cuando alguien dice “añadimos un SLOG y nada cambió”, o “las escrituras síncronas nos están matando”, o “¿es este NVMe seguro como dispositivo de logs?”.
Cada tarea incluye un comando, salida de ejemplo, qué significa y qué decisión tomar.

Tarea 1: Confirmar si siquiera tienes un SLOG (y cuál es)

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
        logs
          nvme0n1p1                 ONLINE       0     0     0

errors: No known data errors

Qué significa: Tienes un vdev de logs (logs) en nvme0n1p1.

Decisión: Si el dispositivo de logs no aparece listado, no tienes un SLOG. Si aparece pero no está espejado, decide si aceptar un fallo de rendimiento es aceptable.

Tarea 2: Comprobar ajustes de sync del dataset (el contrato de la carga)

cr0x@server:~$ zfs get -r sync tank/vmstore
NAME          PROPERTY  VALUE  SOURCE
tank/vmstore  sync      standard  local

Qué significa: El comportamiento sync es el por defecto (“honrar las solicitudes sync de la aplicación”).

Decisión: Si esto dice disabled, tu SLOG probablemente no hará mucho porque has dicho a ZFS que ignore la semántica sync. Si dice always, estás forzando más escrituras en la ruta SLOG—quizá intencionalmente, quizá no.

Tarea 3: Ver cómo está configurado el export NFS (sync vs async)

cr0x@server:~$ cat /etc/exports
/tank/vmstore 10.10.0.0/24(rw,sync,no_subtree_check)
/tank/media   10.10.0.0/24(rw,async,no_subtree_check)

Qué significa: vmstore es sync (SLOG relevante). media es async (SLOG mayormente irrelevante).

Decisión: Enfoca el esfuerzo de SLOG donde se requiere sync. No “optimices” exports async con un SLOG y luego te preguntes por qué nada cambió.

Tarea 4: Ver si la carga está generando escrituras síncronas

cr0x@server:~$ arcstat.py 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:10:01   222    12      5     2    1    10    4     0    0   42G   64G
12:10:02   240    14      5     3    1    11    4     0    0   42G   64G
12:10:03   230    11      4     2    1     9    4     0    0   42G   64G

Qué significa: Esto muestra comportamiento de ARC, no escrituras síncronas directamente—pero te indica si estás limitado por lecturas y con muchos fallos de caché.

Decisión: Si la queja es “lecturas lentas”, deja de hablar de SLOG y empieza a hablar de layout de vdev, dimensionado de ARC y quizá special vdevs.

Tarea 5: Observar latencia de ZFS y ver si las escrituras son el problema

cr0x@server:~$ zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        20.1T  10.4T    120    980  1.2M  38.4M
  raidz2-0  20.1T  10.4T    120    840  1.2M  32.1M
    sda         -      -     30    210   310K  8.1M
    sdb         -      -     28    205   295K  8.0M
    sdc         -      -     31    212   305K  8.0M
    sdd         -      -     31    213   310K  8.0M
logs            -      -      0    140      0  6.3M
  nvme0n1p1     -      -      0    140      0  6.3M

Qué significa: Ves escrituras al dispositivo de logs. Eso sugiere fuertemente que hay actividad síncrona.

Decisión: Si las escrituras a logs son cero mientras los usuarios se quejan de “latencia sync”, puede que realmente no estés haciendo escrituras síncronas, o que sync esté deshabilitado en algún sitio. Revisa el comportamiento del cliente/aplicación.

Tarea 6: Revisar estadísticas ZIL/SLOG vía kstats (Linux OpenZFS)

cr0x@server:~$ sudo kstat -p | egrep 'zfs:0:zil|zfs:0:vdev_log' | head
zfs:0:zil:zil_commit_count                           184229
zfs:0:zil:zil_commit_writer_count                     182910
zfs:0:zil:zil_commit_wait_count                        1319
zfs:0:zil:zil_itx_count                              920114
zfs:0:vdev_log:vdev_log_write_bytes               12899323904

Qué significa: Están ocurriendo commits; algunos tuvieron que esperar. Los bytes de log no son triviales.

Decisión: Si los contadores de espera de commit suben bajo carga, estás golpeando la latencia del dispositivo de logs o contención. Considera un SLOG mejor o espejarlo, y revisa si hay throttling o sobrecalentamiento del dispositivo.

Tarea 7: Verificar que el dispositivo NVMe tenga pistas de PLP e identificar el modelo

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0 | egrep 'mn|vid|oacs|oncs|vwc'
mn      : INTEL SSDPE2KX040T8
vid     : 0x8086
oacs    : 0x17
oncs    : 0x5f
vwc     : 0x01

Qué significa: Has identificado el modelo exacto; vwc indica información sobre volatile write cache (no garantiza PLP, pero es una pista).

Decisión: Si no puedes identificar el modelo o es un drive consumer con comportamiento PLP poco claro, no lo uses como SLOG para cargas sync críticas. Usa un drive enterprise con comportamiento de pérdida de energía conocido.

Tarea 8: Revisar salud NVMe y contadores de error

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 43 C
available_spare                     : 100%
percentage_used                     : 2%
data_units_written                  : 184,992
media_errors                        : 0
num_err_log_entries                 : 0

Qué significa: Saludable, desgaste bajo, sin errores de media.

Decisión: Si critical_warning es distinto de cero, las temperaturas son altas o los logs de error suben, trata el SLOG como sospechoso. Reemplaza tempranamente; es más barato que perseguir latencia fantasma.

Tarea 9: Comprobar si el NVMe está estrangulándose térmicamente (asesino silencioso de latencia)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep 'temperature|critical_warning'
critical_warning                    : 0x00
temperature                         : 72 C

Qué significa: 72°C coquetea con la zona de throttling para muchos drives, dependiendo del modelo y flujo de aire.

Decisión: Si ves temperaturas altas durante incidentes, arregla la refrigeración antes de comprar un “drive más rápido”. Un NVMe en throttling es un NVMe lento con mejor PR.

Tarea 10: Validar que el dispositivo de logs está siendo usado realmente para I/O síncrono

cr0x@server:~$ sudo zdb -C tank | egrep -A2 'log'
        log
            type: 'disk'
            id: 2
            guid: 12759911906639365414

Qué significa: La configuración del pool incluye un vdev de log.

Decisión: Si esperabas un vdev de log pero no lo ves, puede que lo añadieras al pool equivocado, o que falló y fue removido. Corrige la configuración antes de afinar cualquier otra cosa.

Tarea 11: Medir la latencia de escritura síncrona directamente con una prueba controlada (usar con cuidado)

cr0x@server:~$ fio --name=syncwrite --filename=/tank/vmstore/fio.test --rw=write --bs=8k --iodepth=1 --numjobs=1 --direct=1 --fsync=1 --size=512m --runtime=20 --time_based --group_reporting
syncwrite: (groupid=0, jobs=1): err= 0: pid=1337: Sat Dec 16 12:10:55 2025
  write: IOPS=1450, BW=11.3MiB/s (11.8MB/s)(226MiB/20002msec)
    clat (usec): min=190, max=14200, avg=640.12, stdev=410.50

Qué significa: Este es un patrón intensivo en sync (fsync=1). Latencia promedio de commit ~0.64ms con algunos picos de cola.

Decisión: Si la latencia son varios milisegundos en un NVMe SLOG, investiga el dispositivo y la ruta (link PCIe, throttling, contención). Si son decenas de milisegundos, puedes estar recurriendo al pool o el dispositivo está mal comportado.

Tarea 12: Confirmar comportamiento TXG y presión de datos sucios (por qué puede estar atascando sync)

cr0x@server:~$ cat /proc/spl/kstat/zfs/txgs
217 5 0x01 184 4608 2401924197 836746120 0 0

Qué significa: Estadísticas TXG presentes; en algunos sistemas parsearás campos para timing y backlog con herramientas. La clave es: el TXG syncing no debería estar perpetuamente atrasado.

Decisión: Si el TXG sync está constantemente sobrecargado, tu pool está limitado por escritura o infra-dimensionado. Un SLOG ayuda con el reconocimiento sync, pero no incrementa mágicamente la capacidad del pool para finalmente cometer los datos.

Tarea 13: Ver si tu pool está constreñido por pocos vdevs (matemáticas de IOPS)

cr0x@server:~$ zpool list -v tank
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank       30.5T  20.1T  10.4T        -         -    22%    65%  1.00x  ONLINE  -
  raidz2-0 30.5T  20.1T  10.4T        -         -    22%    65%      -  ONLINE  -

Qué significa: Un vdev RAIDZ. Eso suele ser excelente para capacidad, no para IOPS.

Decisión: Si tu carga es intensiva en I/O aleatorio, especialmente almacenamiento de VM, la corrección podría ser más vdevs (mirrored stripes) en lugar de un SLOG.

Tarea 14: Confirmar ashift y alineación (prevenir latencia auto-infligida)

cr0x@server:~$ zdb -C tank | egrep 'ashift'
                    ashift: 12

Qué significa: Alineación a 4K (ashift=12) que generalmente es correcta para discos modernos y SSDs.

Decisión: Si ves ashift: 9 en discos 4K, puedes tener amplificación de escritura patológica y latencia. Eso es una reparación a nivel de rebuild, no un arreglo de SLOG.

Guion de diagnóstico rápido

Cuando alguien grita “el almacenamiento está lento” y tienes 20 minutos antes de la siguiente escalación, esta es la forma más rápida de determinar si el SLOG es relevante.

Primero: determina si el dolor es latencia de escritura síncrona

• Revisa sync del dataset y ajustes de protocolo (NFS/SMB/iSCSI). Si sync no está en juego, el SLOG no es el héroe.
• Busca evidencia de actividad del dispositivo de logs (zpool iostat -v mostrando escrituras bajo logs).
• Si es posible, ejecuta una pequeña prueba controlada de fio sync en el dataset (no lo hagas en un sistema frágil en plena carga).

Segundo: valida que el dispositivo SLOG no sea el cuello de botella

• Salud NVMe (nvme smart-log) y temperatura. El throttling produce latencia de cola “misteriosa”.
• kstats para espera de commits ZIL: ¿suben cuando hay picos de latencia?
• Confirma que el vdev de logs esté ONLINE y no haya sido silenciosamente faulted/removido.

Tercero: si el sync está bien, busca el verdadero cuello de botella

• Tasa de fallos de lectura: ¿ARC thrash o lecturas reales de disco?
• Layout del pool: pocos vdevs o RAIDZ para cargas VM es reincidente.
• CPU saturada: cifrado/compresión/checksum con cores saturados puede fingir “discos lentos”.
• Red: la latencia NFS con frecuencia reside en la NIC/MTU/interrupciones, no en el pool.

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

1) “Añadimos un NVMe SLOG y nada mejoró.”

Síntomas: Los benchmarks cambian poco; los usuarios siguen quejándose; zpool iostat muestra escrituras mínimas en logs.

Causa raíz: La carga no está dominada por escrituras síncronas (o sync está deshabilitado, o los clientes no emiten sync).

Solución: Verifica con zfs get sync, opciones de export NFS y una prueba sync-heavy con fio. Si está limitado por lecturas/metadata, considera ARC/special vdev/cambios de layout de vdev.

2) “La latencia mejoró en promedio, pero p99 sigue terrible.”

Síntomas: La latencia media baja; quedan stalls ocasionales de varios 10ms.

Causa raíz: Throttling NVMe, garbage collection interno, peculiaridades de firmware o contención por compartir el dispositivo.

Solución: Revisa temperatura, logs del controlador y evita colocalizar L2ARC/swap/otras cargas en el mismo dispositivo. Usa un SSD enterprise con latencia consistente.

3) “Después de que el SLOG murió, todo fue inutilizable.”

Síntomas: El pool sigue ONLINE pero los clientes síncronos avanzan a paso de tortuga; la recuperación requirió intercambio hardware de emergencia.

Causa raíz: La falla de un dispositivo de log único eliminó la ruta síncrona de baja latencia; el pool principal no puede manejar las IOPS de escrituras síncronas.

Solución: Espeja el SLOG. También afronta la capacidad de escritura aleatoria del pool si está fundamentalmente desajustada a la carga.

4) “Usamos un NVMe consumer, y tras un evento de energía tuvimos corrupción rara.”

Síntomas: Inconsistencias a nivel de aplicación, anomalías en recuperación de bases de datos, a veces sin errores ZFS obvios.

Causa raíz: El dispositivo reconoció flushes sin persistencia real (sin PLP, caché volátil, comportamiento de firmware).

Solución: Usa un dispositivo enterprise con PLP para SLOG. Asegura energía estable (UPS) y prefiere SLOG espejado si la carga es crítica.

5) “Forzamos sync=always en todas partes y ahora va más lento.”

Síntomas: Throughput de escritura baja; latencia aumenta; SLOG muestra actividad intensa.

Causa raíz: Convertiste tráfico asíncrono en síncrono y sobrecargaste la ruta de commits.

Solución: Usa sync=always solo donde sea estrictamente necesario. Mantén standard por defecto para datasets de propósito general.

6) “Espejamos el SLOG y esperábamos duplicar rendimiento.”

Síntomas: Sin mejora; a veces ligeramente peor.

Causa raíz: Los mirrors son para redundancia; cada escritura ZIL debe confirmarse en ambos dispositivos.

Solución: Espeja por disponibilidad y seguridad de la ruta rápida. Si necesitas más rendimiento, necesitas un perfil de latencia de dispositivo mejor o una arquitectura distinta.

Tres micro-historias corporativas del mundo real

Incidente causado por una suposición equivocada: “SLOG hace todo más rápido”

Una empresa SaaS mediana operaba un clúster NFS con ZFS para artefactos de CI y capas de imágenes de contenedor. El equipo de almacenamiento oyó “NVMe hace ZFS rápido” e instaló un brillante dispositivo de logs en cada filer.
El incidente que intentaban resolver eran jobs de build que hacían timeout en horas pico.

Tras el cambio, nada mejoró. Las gráficas no se movían. El equipo de build seguía con timeouts, y ahora el equipo de almacenamiento debía defender una compra que no movió la aguja.
Un ingeniero senior finalmente hizo una pregunta ruda: “¿Estamos siquiera limitados por escrituras síncronas?”

Revisaron los exports. La ruta de artefactos estaba montada con ajustes que favorecían throughput y aceptaban cierto riesgo; el cuello de botella real eran lecturas de metadata y recorridos de directorio en un pool construido con grandes vdevs RAIDZ de HDDs.
La solución no fue más dispositivos de log. Fue una combinación de añadir un special vdev para metadata/bloques pequeños y replantear recordsize para los caminos calientes.
El SLOG no estaba equivocado. Simplemente era irrelevante. La suposición errónea fue tratar “dispositivo rápido” como un hechizo universal de rendimiento.

Optimización que salió mal: “Usemos un NVMe consumer barato como SLOG”

Una renovación impulsada por finanzas aterrizó en una compañía que alojaba cargas multi-tenant sobre ZFS via iSCSI. El equipo quería menor latencia de commit para unas bases de datos muy charlatanas.
Alguien propuso un NVMe consumer como SLOG: “Es rápido y solo es para logs. Estará bien.”

Estuvo bien—hasta el primer incidente de energía real. No un apagón dramático, solo un parpadeo: un reinicio de PDU durante trabajo rutinario. Los sistemas volvieron. ZFS importó pools limpiamente. No hubo gritos.
Una semana después, un tenant abrió un ticket: estado de aplicación inconsistente. Luego otro.

La investigación fue dolorosa porque nada parecía obviamente roto. El pool estaba healthy. Los scrubs limpios. El problema olía a “commits durables que no fueron durables”, que es el tipo más desagradable de misterio.
Finalmente correlacionaron los primeros reportes con el parpadeo de energía y el modelo NVMe consumer usado para SLOG.

El cambio final fue aburrido: reemplazar SLOGs por drives enterprise con PLP, espejarlos y dejar de tratar las semánticas de flush como opcionales.
El rendimiento se mantuvo bien y, más importante, las promesas del sistema coincidieron con la realidad. La optimización falló porque optimizó la métrica mala: coste inicial sobre corrección.

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

Una empresa regulada operaba un appliance ZFS sirviendo NFS a virtualización y algunas bases de datos internas. Tenían un SLOG espejado en SSDs enterprise con PLP.
Nadie lo celebraba. Simplemente estaba ahí, comiendo escrituras síncronas en silencio.

Una tarde, un dispositivo SLOG empezó a registrar errores de media. El sistema de monitorización lo señaló, y el SRE de guardia hizo lo menos heroico imaginable: siguió el runbook.
Confirmaron que el pool seguía usando un log espejado, verificaron que el dispositivo restante estaba sano y programaron el reemplazo ese mismo día.

Durante el reemplazo, nada notable ocurrió para los clientes. La latencia no subió. No hubo ventana de cambio de emergencia.
El equipo cambió el dispositivo, lo re-adicionó al log espejado y observó cómo la resilverización completó rápido porque el vdev de log era pequeño y el proceso estaba bien entendido.

La moraleja no es “siempre espejar el SLOG”. Es que los sistemas en producción te recompensan por disciplina aburrida: redundancia donde importa, monitorización específica y procedimientos ensayados para no aprender comandos ZFS durante un incidente.

Listas de verificación / plan paso a paso

Paso a paso: decidir si necesitas un SLOG

1. Identifica cargas: ¿NFS para VMs? ¿bases de datos? ¿directorios home? ¿backups secuenciales?
2. Confirma comportamiento sync: dataset sync, opciones de export NFS, ajustes de durabilidad de la aplicación.
3. Mide: prueba sync-heavy con fio en un dataset de staging; compara latencia p95/p99 con y sin SLOG si es posible.
4. Revisa diseño del pool: si es un RAIDZ único sirviendo I/O de VM, arregla eso de forma prioritaria.
5. Decide tolerancia al riesgo: si los datos deben ser seguros, no planifiques alrededor de sync=disabled.

Paso a paso: desplegar un NVMe SLOG de forma sensata

1. Elige hardware con PLP y latencia estable. Trata “enterprise” como requisito, no como vibe.
2. Prefiere espejado si la estabilidad de rendimiento importa durante fallos de dispositivo.
3. Instala con refrigeración: el throttling NVMe es un outage de rendimiento con gabardina.
4. Añade el vdev de log durante una ventana controlada y verifica su uso bajo carga real.
5. Monitoriza: temperaturas, logs de errores y comportamiento de espera de commits ZIL.

Paso a paso: hábitos operativos seguros

1. Mantén los dispositivos SLOG de propósito único.
2. Registra modelo/firmware de los dispositivos en tu inventario.
3. Prueba fallos: simula la remoción en una ventana de mantenimiento y confirma que la degradación de rendimiento es aceptable.
4. Tén un runbook de reemplazo que incluya cómo volver a añadir logs espejados y verificar el estado del pool.

Acciones ZFS comunes para gestión de SLOG

Estas son operativamente comunes, pero hazlas con cuidado: eliminar logs puede cambiar el rendimiento instantáneamente bajo carga.

Añadir un SLOG espejado

cr0x@server:~$ sudo zpool add tank log mirror /dev/nvme0n1p1 /dev/nvme1n1p1

Qué significa: Añade un vdev de log espejado; las escrituras ZIL confirman en ambos dispositivos.

Decisión: Úsalo cuando necesites que la ruta sync rápida sobreviva a la falla de un dispositivo.

Eliminar un vdev de log existente

cr0x@server:~$ sudo zpool remove tank nvme0n1p1

Qué significa: Elimina el dispositivo de logs (si removable en tu versión/config ZFS). Las escrituras síncronas volverán al ZIL en-pool.

Decisión: Haz esto solo cuando estés seguro de que el pool puede manejar la carga sync o durante una ventana de mantenimiento controlada.

Preguntas frecuentes

1) ¿SLOG es lo mismo que ZIL?

No. El ZIL es el mecanismo de intent log en disco usado para escrituras síncronas. Un SLOG es un dispositivo separado que puede guardar registros ZIL para que confirmen más rápido.

2) ¿Añadir un SLOG acelerará mis shares SMB?

A veces, pero solo si la carga es muy dependiente de escrituras síncronas y SMB está configurado/usa semánticas de durabilidad. Mide. No asumas. Los problemas de SMB suelen ser metadata, oplocks o problemas de red/CPU.

3) ¿Puedo usar cualquier NVMe como SLOG?

Puedes, pero no deberías para datos críticos a menos que tenga protección contra pérdida de energía y comportamiento de flush consistente.
“Rápido” no es el requisito; “rápido y honesto ante pérdida de energía” sí lo es.

4) ¿Debería espejar el SLOG?

Si perder el SLOG causaría un incidente de rendimiento visible (y suele ocurrir para NFS+VM), entonces espejalo.
Si es una caja de laboratorio y toleras un cliff de rendimiento al fallar, un único dispositivo puede ser aceptable.

5) ¿Cómo sé si mis clientes están emitiendo escrituras síncronas?

Lo infieres por comportamiento: actividad de escritura en el dispositivo de logs, estadísticas de commit ZIL, ajustes de la aplicación y pruebas controladas (fio con fsync).
El enfoque honesto: mide bajo carga similar a producción y comprueba si la latencia se correlaciona con commits ZIL.

6) ¿SLOG ayuda con scrubs o resilvers del pool?

No. Scrubs y resilvers son sobre leer y reconstruir datos. SLOG es para reconocer escrituras síncronas rápidamente.

7) ¿Cuál es la relación entre SLOG y L2ARC?

Completamente diferente: L2ARC es una extensión de caché de lectura; SLOG es un acelerador de escrituras síncronas.
La gente compra ambos cuando está desesperada. Solo uno podría ser relevante. A veces ninguno.

8) ¿Es sync=disabled seguro si tengo un UPS?

Un UPS reduce la probabilidad de pérdida de energía súbita, pero no elimina kernel panics, resets de controladora o bugs de firmware.
sync=disabled cambia las semánticas de durabilidad. Úsalo solo cuando los datos sean descartables o estén protegidos en otro lugar, y hayas aceptado el riesgo explícitamente.

9) ¿Cuánto importa la capacidad del SLOG?

Usualmente no mucho. Lo que importa es latencia, comportamiento de flush y consistencia. La capacidad solo debe cubrir la ventana de escrituras síncronas pendientes más margen.

10) Si tengo un pool espejo totalmente SSD, ¿aún necesito SLOG?

A menudo no, porque la latencia sync del pool puede ser ya buena. Pero si sirves NFS/iSCSI sensibles a la latencia y ves cuellos de botella en commit sync, un SLOG aún puede ayudar.
Mide primero; no compres hardware por costumbre.

Conclusión: pasos prácticos siguientes

NVMe como SLOG es perfecto cuando tienes presión real de escrituras síncronas y necesitas acknowledgements durables con latencia baja y predecible.
Es excesivo cuando tu carga es asíncrona, limitada por lecturas, bound por metadata o simplemente sufre por un layout de pool que no puede hacer IOPS aleatorios.

Pasos siguientes que realmente cambian resultados:

1. Prueba que sync es el cuello de botella: revisa settings de dataset/export, observa escrituras en logs, ejecuta una prueba sync-heavy con fio.
2. Valida tu dispositivo SLOG: capaz de PLP, sano, frío y consistente. Si es consumer-grade, trátalo como decisión de riesgo, no como detalle técnico.
3. Diseña para fallos: espeja el SLOG si la estabilidad de rendimiento importa, y practica el reemplazo.
4. Arregla el pool si ese es el problema: más vdevs, mirrors para IOPS, special vdev para metadata y suficiente RAM para ARC suelen vencer a “un gadget más”.

Si haces esto en orden, o conseguirás la mejora de SLOG que esperabas—o te ahorrarás comprar una solución muy rápida para el problema equivocado.