Si ejecutas ZFS en producción el tiempo suficiente, eventualmente conocerás al villano de la historia: las escrituras síncronas. Son la razón por la que tu datastore NFS se siente “misteriosamente” lento, tu plataforma de VM se queda colgada durante una hora de máxima actividad o tu base de datos exige un presupuesto de latencia que parece imposible de comprar con más discos.
El héroe al que la gente recurre es un dispositivo SLOG: un SSD dedicado a manejar el write intent log de ZFS (ZIL). Pero aquí viene el giro: la característica más importante de un SSD para SLOG no es el rendimiento sostenido, ni siquiera la latencia bruta. Es la protección contra pérdida de energía (PLP). Sin ella, estás instalando un accesorio de rendimiento que puede convertirse en un problema de durabilidad. En otras palabras: puedes acelerar las cosas, pero también aumentar la probabilidad de perder datos en un mal día.
Qué es un SLOG (y qué no es)
Pongamos la terminología en claro, porque la mitad de los debates sobre SLOG en internet son en realidad discusiones sobre qué problema estamos resolviendo.
ZIL es el ZFS Intent Log. Existe para satisfacer la semántica de escrituras síncronas: cuando una aplicación pide una escritura que debe ser duradera antes de continuar, ZFS necesita un lugar para confirmar esa intención rápidamente, incluso si el pool principal es lento (piensa en RAIDZ con HDD). Si el sistema se cae antes de que esas escrituras se confirmen en el pool principal, ZFS puede reproducir el intent log al importar el pool.
SLOG es un dispositivo de log separado, un vdev dedicado para almacenar el ZIL en medios rápidos. En la práctica, un SLOG es principalmente un reductor de latencia para escrituras síncronas. No acelera tus escrituras secuenciales masivas. No mejora mágicamente las cargas async. No arregla un pool que ya está saturado en lecturas aleatorias. Hace una cosa muy bien: ofrece a las escrituras sync una pista de aterrizaje corta, rápida y fiable.
La sorpresa más común: el SLOG no es una “caché de escritura” en el sentido habitual. ZFS sigue escribiendo los datos en el pool principal. El SLOG es donde el sistema escribe la información de la transacción y (para escrituras síncronas) los bloques de datos necesarios para satisfacer la durabilidad hasta que se vacíen al pool. Por eso los requisitos de capacidad del SLOG suelen ser modestos y por qué “rápido + seguro” vence a “grande”.
Broma #1: Un SLOG sin protección contra pérdida de energía es como un paracaídas empaquetado por alguien que “por lo general lo hace bien”. Técnicamente es un paracaídas, emocionalmente una sugerencia.
Por qué la protección contra pérdida de energía es innegociable para el SLOG
La protección contra pérdida de energía (PLP) es la capacidad de un SSD para mantener seguras las escrituras en vuelo cuando se va la corriente: típicamente mediante condensadores a bordo que proporcionan la energía suficiente para vaciar los buffers volátiles DRAM a NAND. Muchos SSD de consumo tienen caché de escritura volátil y pueden confirmar escrituras antes de que esas escrituras sean realmente seguras en el medio persistente.
Eso es aceptable en muchos escenarios de escritorio porque el sistema de archivos o la aplicación puede no depender de un orden estricto y durabilidad inmediata. ZFS SLOG es lo opuesto. ZFS usa el log para cumplir una promesa: “sí, esa escritura síncrona es duradera ahora”. Si tu SSD miente—confirma la finalización pero pierde energía antes de que los datos sean realmente persistentes—puedes acabar con registros de intent log faltantes o corruptos. En el mejor de los casos, pierdes unos segundos de escrituras sync confirmadas (ya inaceptable para las aplicaciones que solicitaron sync). En el peor, generas un lío de replay que incrementa el tiempo de recuperación o provoca inconsistencias a nivel de aplicación.
En términos SRE: si tu objetivo de nivel de servicio incluye “las transacciones confirmadas sobreviven a un fallo”, el dispositivo de log no debe convertir una pérdida de energía en pérdida silenciosa de datos. PLP no trata primero de rendimiento; trata de legitimar el rendimiento que ganas.
También hay una razón menos obvia: un SSD sin PLP puede fallar de una manera que parece “picos de latencia aleatorios”. Bajo fluctuaciones de energía o fallos del controlador, la unidad puede forzar vaciados de caché o reintentos, arrastrando la latencia hasta rangos de milisegundos a segundos. Las escrituras sync de ZFS son sensibles a la latencia. A tus usuarios no les importa que la latencia media sea buena si el percentil 99.9 es “por qué se congeló mi VM”.
Lo que PLP no garantiza: no hace la unidad inmortal, no previene bugs de firmware y no te protege de kernel panics. Aborda específicamente el problema “se fue la energía mientras los datos estaban en buffers volátiles”. Esa es una clase de fallo importante en centros de datos y sucursales por igual.
Cómo ZIL/SLOG realmente funciona: la versión de ingeniería
ZFS agrupa escrituras en transaction groups (TXGs). Para escrituras asíncronas, ZFS puede absorber datos en memoria (ARC) y luego volcarlos al disco cuando el TXG se sincroniza. Para escrituras síncronas, ZFS debe asegurar que la escritura sea estable antes de reconocerla al llamador. Ahí entra el ZIL.
Cuando una aplicación emite una escritura sync, ZFS registra suficiente información en el ZIL para reproducir esa escritura tras un fallo. Este registro puede incluir los datos en sí según el tamaño de la escritura y la configuración. El ZIL se escribe de forma secuencial en estilo log, lo que favorece a dispositivos de baja latencia. En un pool sin log separado, estas escrituras acaban dispersas por los vdevs principales, que pueden ser HDDs con latencia de fsync miserable.
Con un SLOG dedicado, ZFS escribe estos registros de log en el vdev SLOG en lugar de esparcirlos por el pool. Más tarde, cuando ocurre el siguiente commit de TXG, el pool principal recibe los datos reales y las entradas del ZIL quedan obsoletas. El SLOG no es un hogar permanente; es un área de staging temporal para hacer prácticas las semánticas sync.
Dos consecuencias operativas importan:
- El SLOG está en la ruta de reconocimiento de las escrituras síncronas. Si es lento, tus clientes son lentos.
- El SLOG debe ser fiable ante pérdida de energía. Si miente, rompe la promesa.
Otra sutileza: ZFS ya tiene garantías de orden. Un SLOG con caches volátiles que ignoren flushes o reordenen escrituras puede violar supuestos. Los SSD empresariales con PLP suelen estar diseñados para respetar barreras de escritura y semánticas de flush; los SSD de consumo a veces optimizan eso para benchmarks.
Datos interesantes y contexto histórico
El almacenamiento no se repite exactamente, pero rima. Algunos puntos de contexto que te ayudarán a tomar mejores decisiones sobre SLOG:
- ZFS se originó en Sun Microsystems a mediados de los 2000, cuando los discos eran enormes y lentos y la RAM era cara; su diseño transaccional asumía que los fallos ocurren y la recuperación debe ser determinista.
- El ZIL existe incluso sin un SLOG. La gente a veces piensa “sin SLOG no hay ZIL”, pero ZFS siempre tiene un intent log—por defecto vive en el pool.
- La protección contra pérdida de energía en SSDs lleva tiempo en storage empresarial—es básicamente la versión SSD del “cache de escritura con batería” de los controladores RAID, solo que sin el mantenimiento de baterías.
- Los benchmarks de SSD de consumo a menudo ocultan la parte peligrosa. Muchas pruebas miden throughput bajo potencia estable e ignoran las semánticas de fsync/flush, que es exactamente donde vive la corrección del SLOG.
- NFS convirtió las semánticas sync en problema de todos. Muchos despliegues NFS usan por defecto comportamiento síncrono por seguridad, así que la latencia de fsync del backend de almacenamiento se vuelve visible para el usuario.
- Los primeros SSDs a veces sufrían acantilados de rendimiento bajo cargas sostenidas sync porque su firmware se afinaba para trazas de escritorio, no para workloads de journaling con barreras estrictas.
- La “mentira de la caché de escritura” no es hipotética. La industria tiene una larga historia de dispositivos que confirman escrituras antes de persistirlas—a veces por diseño, a veces por bug, a veces por “optimizar” los flushes.
- El modelo copy-on-write de ZFS significa que no sobrescribe bloques en vivo; escribe bloques nuevos y actualiza metadata. Eso es genial para consistencia, pero también implica que las rutas de escritura sync tienen más trabajo de metadata que un filesystem simplista.
Elegir un SSD para SLOG: qué exigir y qué ignorar
Exigir: protección real contra pérdida de energía
PLP es el titular. En un SSD empresarial, normalmente se describe como power-loss data protection, power-fail protection o capacitor-backed cache flush. Físicamente, a menudo significa arreglos visibles de condensadores en la PCB (especialmente en U.2 / tarjetas PCIe), aunque no siempre. La prueba real es si el dispositivo está diseñado para completar de forma segura las escrituras confirmadas tras una pérdida de energía.
Operativamente, PLP se correlaciona con:
- Latencia consistente y baja para escrituras síncronas
- Respeto a flushes y barreras
- Menos “bloqueos misteriosos” bajo presión
Exigir: baja latencia, no throughput pico
SLOG trata sobre el tiempo de reconocimiento. Las métricas clave son la latencia bajo patrones de escritura sync, especialmente escrituras de bloques pequeños con flushes. Una unidad que haga 7 GB/s secuencial puede aún ofrecer una latencia decepcionante en escrituras 4K sync si su firmware y estrategia de caché no están pensados para ello.
Preferir: resistencia y comportamiento en estado estable
Las escrituras SLOG son pequeñas, frecuentes y repetitivas. Aunque el ZIL es circular y las entradas antiguas se descartan, puedes generar una cantidad sorprendente de write amplification. Busca unidades con buenas calificaciones de endurance y, más importante, comportamiento estable bajo escrituras sostenidas.
Preferir: topología simple y monitorización fuerte
Los dispositivos NVMe suelen dar excelente latencia y buena visibilidad vía SMART/páginas de log. SATA puede funcionar, pero es más fácil encontrar unidades SATA de consumo sin PLP, y la cola de SATA puede ser el cuello de botella con muchos clientes. Usa lo que encaje con tu chasis y tu planificación de dominios de fallo.
Ignorar: gran capacidad
Un SLOG típicamente solo necesita cubrir unos segundos de tráfico sync pico. El dimensionado relevante se basa en tu timeout de TXG y comportamiento de ráfagas, no en “cuánto dato almaceno”. Los SLOG enormes suelen ser señal de comprar por puntos de marketing.
Espejar el SLOG si te importa la disponibilidad
Matiz importante: perder un dispositivo SLOG no suele corromper el pool, pero puede provocar la pérdida de las últimas escrituras sync confirmadas que vivían sólo en el log. Operativamente, un SLOG muerto hace que tu carga sync vuelva al pool principal, lo que puede ser un cliff de rendimiento. Espejar el SLOG es una práctica común “aburrida pero correcta” para la disponibilidad.
Broma #2: Nada te hace apreciar un SLOG espejado como explicarle a un CFO por qué “es seguro” y “es lento” pueden suceder al mismo tiempo.
Desplegar SLOG de forma segura: patrones que sobreviven auditorías y cortes
Entiende primero tu carga sync
Si no tienes escrituras síncronas, un SLOG no ayudará. Muchas pilas de VM y bases de datos generan escrituras sync, pero algunas cargas son mayormente async y no les importará. Mide antes de comprar.
Usa un dispositivo dedicado, no una partición compartida con “otra cosa”
En producción, los dispositivos de log compartidos tienden a convertirse en dolores compartidos. Mezclar SLOG con otros sistemas de archivos, swap o “scratch temporal” es una excelente forma de introducir latencia impredecible.
Espeja por disponibilidad, no por velocidad
Un SLOG espejado no duplica el rendimiento; mejora la resiliencia y puede suavizar la cola cola de latencia cuando un dispositivo empieza a comportarse mal. Si tu plataforma sirve almacenamiento para VMs o bases de datos, eventualemente agradecerás haber espejado.
Manténlo cerca de la CPU y manténlo frío
NVMe detrás de un riser PCIe inestable o en una ranura M.2 sobrecalentada es un experimento de fiabilidad que no querías ejecutar. El throttling térmico aparece como “picos” aleatorios de latencia sync. Pon los dispositivos de log en bahías con flujo de aire adecuado y monitorea temperaturas.
Tareas prácticas: comandos, comprobaciones y qué significa la salida
Estas son tareas operativas reales que puedes ejecutar en un sistema Linux con OpenZFS. Los comandos asumen que tienes acceso root o sudo. Ajusta nombres de pools y rutas de dispositivos.
Tarea 1: Confirma si tu carga realmente hace escrituras síncronas
cr0x@server:~$ zpool iostat -v 1
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 12.3T 5.1T 120 980 8.1M 34.2M
raidz2 12.3T 5.1T 120 980 8.1M 34.2M
sda - - 20 160 1.4M 5.7M
sdb - - 20 160 1.3M 5.8M
...
Interpretación: Esto muestra IO del pool, pero no sync vs async. Es tu primer chequeo “¿pasa algo?”. Si las escrituras son bajas pero los clientes se quejan, la latencia más que el throughput puede ser el problema.
Tarea 2: Revisa la configuración sync de los datasets (la trampa)
cr0x@server:~$ zfs get -r sync tank
NAME PROPERTY VALUE SOURCE
tank sync standard default
tank/vmstore sync standard local
tank/backups sync disabled local
Interpretación: standard respeta las solicitudes sync de la aplicación. disabled le miente a las aplicaciones (mejora rendimiento, riesgo de durabilidad). always fuerza sync y puede aplastar el rendimiento sin un SLOG.
Tarea 3: Comprueba si ya tienes un SLOG configurado
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
mirror-1 ONLINE 0 0 0
nvme0n1 ONLINE 0 0 0
nvme1n1 ONLINE 0 0 0
Interpretación: Busca una sección logs. Si está presente, tienes un SLOG. Si es un dispositivo único, decide si la disponibilidad justifica espejarlo.
Tarea 4: Identifica el modelo real del dispositivo y firmware
cr0x@server:~$ lsblk -d -o NAME,MODEL,SIZE,ROTA,TRAN,SERIAL
NAME MODEL SIZE ROTA TRAN SERIAL
sda ST12000NM0007 10.9T 1 sata ZS0A...
nvme0n1 INTEL SSDPE2KX040T8 3.7T 0 nvme PHM...
Interpretación: Quieres saber qué hay realmente instalado. “Algún SSD” no es una estrategia de inventario.
Tarea 5: Revisa la salud NVMe, incluyendo ciclos de energía y errores de media
cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning : 0x00
temperature : 41 C
available_spare : 100%
percentage_used : 3%
data_units_written : 184,221,991
media_errors : 0
num_err_log_entries : 0
power_cycles : 27
power_on_hours : 3912
unsafe_shutdowns : 1
Interpretación: unsafe_shutdowns es una pista sobre eventos de energía. Uno no es para alarmarse; un número creciente sin explicación sí lo es.
Tarea 6: Comprueba si la unidad está haciendo throttling térmico (asesino de latencia)
cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0n1 | grep -i -E 'tnvmcap|mn|fr'
mn : INTEL SSDPE2KX040T8
fr : VDV10131
tnvmcap : 4000787030016
Interpretación: Esto es identificación. Combínalo con la temperatura de SMART y la realidad de flujo de aire de tu chasis. Si tu SLOG se calienta, eventualmente “rindrá” como un dispositivo mucho peor.
Tarea 7: Observa IO del SLOG directamente vía iostat por vdev
cr0x@server:~$ zpool iostat -v tank 1
operations bandwidth
pool read write read write
-------------------------- ---- ----- ---- -----
tank 180 2200 12.1M 95.4M
raidz2-0 180 400 12.1M 18.2M
sda 30 70 2.1M 4.6M
...
logs - 1800 - 77.2M
mirror-1 - 1800 - 77.2M
nvme0n1 - 900 - 38.6M
nvme1n1 - 900 - 38.6M
Interpretación: Si ves muchas operaciones de escritura en logs, tienes tráfico sync real. Si los logs están inactivos, tu cuello de botella está en otro lugar o tus clientes no emiten escrituras sync.
Tarea 8: Revisa propiedades del pool que impactan el comportamiento sync
cr0x@server:~$ zpool get -o name,property,value,source ashift,autotrim,autoreplace,cachefile tank
NAME PROPERTY VALUE SOURCE
tank ashift 12 local
tank autotrim on local
tank autoreplace off default
tank cachefile /etc/zfs/zpool.cache local
Interpretación: No está directamente relacionado con SLOG, pero un ashift desalineado y trim descuidado pueden causar write amplification y latencia impredecible.
Tarea 9: Añadir un SLOG espejado (patrón seguro) a un pool existente
cr0x@server:~$ sudo zpool add tank log mirror /dev/nvme0n1 /dev/nvme1n1
Interpretación: Esto crea un vdev de log espejado. Asegúrate de que estos dispositivos no se usen en otra parte y que sean identificadores estables (rutas by-id son mejores en operaciones reales).
Tarea 10: Eliminar un SLOG correctamente (al desmantelar)
cr0x@server:~$ sudo zpool remove tank nvme0n1
Interpretación: En versiones OpenZFS que lo soportan, puedes eliminar dispositivos de log. Confirma el estado después. No simplemente arranques el dispositivo y “esperes que ZFS lo arregle”. Lo hará, pero aprenderás sobre pools degradados a las 3 a.m.
Tarea 11: Generar una prueba de escritura síncrona que realmente ejercite el SLOG
cr0x@server:~$ sudo zfs create -o sync=standard tank/slogtest
cr0x@server:~$ cd /tank/slogtest
cr0x@server:~$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:~$ /usr/bin/time -f "elapsed=%e sec" dd if=/dev/zero of=./syncfile bs=8k count=20000 oflag=dsync status=none
elapsed=9.84 sec
Interpretación: oflag=dsync fuerza que cada escritura sea síncrona. Esto se acerca a lo que hacen bases de datos y clientes NFS. Compara resultados con y sin SLOG (y bajo carga) para ver si ayuda.
Tarea 12: Verifica que tu SLOG no se esté evitando por la configuración del dataset
cr0x@server:~$ zfs get sync tank/vmstore
NAME PROPERTY VALUE SOURCE
tank/vmstore sync standard local
Interpretación: Si está en disabled, puedes ver gran rendimiento—hasta que pruebes la consistencia tras un fallo. Si está en always, espera mayor utilización del SLOG y asegúrate de que el dispositivo lo soporte.
Tarea 13: Busca latencia extrema en el bloque
cr0x@server:~$ iostat -x 1 /dev/nvme0n1
Linux 6.8.0 (server) 12/25/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
4.12 0.00 2.01 8.55 0.00 85.32
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %util await svctm
nvme0n1 0.00 950.00 0.00 7600.00 0.00 0.00 42.10 0.45 0.08
Interpretación: Para un buen dispositivo SLOG, quieres bajo await bajo carga sync. Si await salta a decenas o cientos de milisegundos, algo va mal: throttling, firmware, errores PCIe o contención.
Tarea 14: Inspecciona logs del kernel por resets NVMe o problemas PCIe
cr0x@server:~$ sudo dmesg -T | grep -i -E 'nvme|pcie|reset|timeout' | tail -n 30
[Thu Dec 25 01:12:44 2025] nvme nvme0: I/O 123 QID 4 timeout, aborting
[Thu Dec 25 01:12:44 2025] nvme nvme0: Abort status: 0x0
[Thu Dec 25 01:12:45 2025] nvme nvme0: resetting controller
Interpretación: Un dispositivo SLOG que ocasionalmente se reinicia se sentirá como “bloqueos aleatorios de fsync”. Esto no es un problema de tuning de ZFS; es estabilidad de hardware/firmware.
Tarea 15: Confirma que el pool está sano y no reintentando errores en silencio
cr0x@server:~$ zpool status -x
all pools are healthy
Interpretación: Si ves errores o vdevs degradados, arregla eso primero. SLOG no salvará un pool que ya está en llamas.
Guía de diagnóstico rápido: encuentra el cuello de botella en minutos
Esta es la secuencia “alguien está gritando en el chat, las VMs van lentas, ¿qué reviso primero?”. Está optimizada para velocidad y señal, no para exhaustividad.
Primero: confirma que tratas con latencia de escrituras síncronas
- Revisa síntomas de los clientes: NFS “server not responding”, stalls en commits de base de datos, IO wait en hypervisor, cargas guest con muchas fsync.
- En el host ZFS, observa IO por vdev:
cr0x@server:~$ zpool iostat -v tank 1Señal: Si
logsmuestra muchas escrituras, estás en territorio de escrituras sync. Si los logs están inactivos, la queja probablemente sea latencia de lectura, CPU, red o saturación de escrituras async.
Segundo: comprueba si el dispositivo SLOG es el limitador
- Observa latencia a nivel de bloque:
cr0x@server:~$ iostat -x 1 /dev/nvme0n1Señal: Un alto
awaiten el dispositivo SLOG se correlaciona directamente con escrituras sync atascadas. - Busca resets/timeouts:
cr0x@server:~$ sudo dmesg -T | grep -i -E 'nvme|timeout|reset' | tailSeñal: Cualquier reset del controlador durante la ventana del incidente es prueba contundente.
- Revisa térmicos y salud:
cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep -i 'temperature|media_errors|unsafe_shutdowns|percentage_used'Señal: Sobrecalentamiento o conteos de error en ascenso son problemas de fiabilidad que se disfrazan de problemas de rendimiento.
Tercero: si el SLOG está bien, revisa contención en pool y sistema
- Saturación del pool:
cr0x@server:~$ zpool iostat -v tank 1Señal: Si los vdevs principales muestran colas/utilización enormes y los logs son moderados, puedes estar limitado por flushes de datos o lecturas.
- CPU y IO wait:
cr0x@server:~$ vmstat 1Señal: Un
wasostenido alto o CPU de sistema alto puede indicar contención amplia. - Red (para NFS/iSCSI):
cr0x@server:~$ ip -s link show dev eth0Señal: Pérdidas, errores o overruns pueden hacer que el almacenamiento parezca lento.
Errores comunes: síntomas y soluciones
Mistake 1: “Cualquier SSD sirve para SLOG”
Síntoma: Gran rendimiento en pruebas ligeras, latencia terrible en cola bajo carga real; escrituras confirmadas ocasionalmente desaparecen tras eventos de energía; historias de recuperación aterradoras.
Solución: Usa un SSD empresarial con PLP. Si no puedes verificar PLP, trata el dispositivo como no-PLP y no lo pongas en la ruta de durabilidad de escrituras sync.
Mistake 2: Usar sync=disabled como “característica de rendimiento”
Síntoma: Todo es rápido hasta que ocurre una interrupción; entonces la base de datos requiere reparación, las VMs tienen sistemas de archivos corruptos o la aplicación ve commits “exitosos” que nunca llegaron al disco.
Solución: Vuelve los datasets a sync=standard (o mantenlos en standard y añade un SLOG adecuado). Si un proveedor requiere sync=disabled, trátalo como una aceptación de riesgo, no como una perilla de tuning.
Mistake 3: Sobredimensionar el SLOG y malinterpretar expectativas
Síntoma: Compraste un SSD enorme y no viste mejora.
Solución: El éxito del SLOG depende de la latencia y la corrección, no de la capacidad. Mide latencia de escrituras sync; dimensiona para segundos de tráfico sync pico, no para terabytes.
Mistake 4: Dispositivo SLOG único en una plataforma que no tolera sorpresas
Síntoma: Un SSD muere y de repente NFS/VM storage se vuelve inutilizable o pierdes las últimas escrituras sync confirmadas justo antes del fallo.
Solución: Espeja el SLOG. Es un seguro barato comparado con el tiempo de incidente y la confianza de los interesados.
Mistake 5: Poner el SLOG en una ranura M.2 con restricción térmica
Síntoma: El rendimiento es excelente durante 5–15 minutos, luego la latencia de fsync salta; el host “se siente” embrujado.
Solución: Mueve el SLOG a una bahía con refrigeración adecuada o añade disipadores/flujo de aire. Monitorea temperaturas. La estabilidad térmica es rendimiento.
Mistake 6: Confundir SLOG con L2ARC o “special vdev”
Síntoma: Añadiste dispositivos y nada mejoró, o lo equivocado mejoró.
Solución: SLOG ayuda escrituras sync. L2ARC ayuda lecturas (y por lo general no críticas en latencia salvo que el working set sea enorme). Special vdev ayuda metadata y bloques pequeños (y puede ser peligroso si no está espejado). Elige según el cuello de botella, no por sensaciones.
Listas de verificación / plan paso a paso
Plan paso a paso: decidir si necesitas un SLOG
- Identifica el tipo de carga. ¿NFS para VMs? ¿Bases de datos? ¿iSCSI? Estos suelen importar por semánticas sync.
- Mide el dolor de escrituras sync actual. Usa
zpool iostat -v 1y una prueba dirigida condd ... oflag=dsyncen un dataset representativo. - Confirma propiedades del dataset. Asegura
sync=standardsalvo que aceptes explícitamente el riesgo dedisabled. - Si hay escrituras sync presentes y lentas, planea un SLOG. No compres hardware hasta confirmar la ruta.
Plan paso a paso: seleccionar un SSD para SLOG
- Reclama PLP. Si no puedes validar PLP, consídéralo ausente.
- Prioriza consistencia de latencia. Unidades orientadas a cargas mixtas o uso en datacenter suelen comportarse mejor.
- Planifica endurance. Especialmente para clusters NFS/VM ocupados donde las escrituras sync son constantes.
- Prefiere NVMe cuando sea posible. SATA puede funcionar, pero NVMe suele ganar en manejo de colas y latencia.
- Planea espejado para disponibilidad. Un dispositivo mejora rendimiento; dos es una postura operativa.
Plan paso a paso: desplegar un SLOG espejado de forma segura
- Inventario de dispositivos por rutas estables. Usa
/dev/disk/by-iden lugar de raw/dev/nvme0n1cuando sea posible. - Añade el mirror de log.
cr0x@server:~$ sudo zpool add tank log mirror /dev/disk/by-id/nvme-SSD_A /dev/disk/by-id/nvme-SSD_B - Verifica el estado del pool.
cr0x@server:~$ zpool status -v tank - Prueba carga de escrituras sync. Ejecuta
dd ... oflag=dsynco un generador de carga durante una ventana de mantenimiento. - Configura monitorización. Rastrea errores NVMe, unsafe_shutdowns, temperatura y métricas de latencia.
Tres micro-historias corporativas desde el campo
Micro-historia 1: El incidente causado por una suposición incorrecta
En una empresa mediana con un cluster de virtualización, el equipo de almacenamiento tenía un appliance NFS respaldado por ZFS que “funcionaba bien” durante meses. Alguien propuso añadir un SLOG para mejorar la capacidad de respuesta de las VMs en horas pico. Compras encontró un NVMe de consumo barato con gráficos de benchmark impresionantes. Se puso en producción un viernes, porque por supuesto pasó así.
El rendimiento parecía fantástico. Las gráficas de latencia cayeron. Se envió el correo de éxito. Luego un evento de energía golpeó el edificio—nada dramático, solo una interrupción corta que el UPS debía haber enmascarado, excepto que un pack de baterías estaba pendiente de reemplazo. El host reinició, importó el pool y NFS volvió. Los hypervisors se reconectaron. Todos respiraron aliviados.
En las horas siguientes, unas cuantas VMs empezaron a mostrar corrupción a nivel de aplicación: una base de datos necesitó recuperación, una cola de mensajes tenía entradas confirmadas faltantes y un servidor de archivos tenía huecos en logs que no coincidían con mantenimiento planificado. El equipo inicialmente sospechó de los hypervisors o bugs en los SO guest porque el pool se importó limpio y zpool status parecía bien.
El postmortem finalmente señaló la “mejora” de la semana anterior: el SSD SLOG. La unidad de consumo tenía caché de escritura volátil y no PLP. Bajo la pérdida de energía, confirmó escrituras sync que nunca llegaron a NAND. ZFS hizo lo que pudo en el replay, pero no puede reproducir registros de log que nunca se escribieron realmente. El sistema cumplió el contrato; el dispositivo no.
La solución no fue un sysctl ingenioso. Reemplazaron el device de log por un SSD empresarial con PLP, lo espejaron y añadieron una política: si un dispositivo participa en confirmar durabilidad, debe estar explícitamente valorado para seguridad ante pérdida de energía. Lo embarazoso no fue que el SSD fuera barato—fue la asunción “SSD significa seguro” que no se cuestionó.
Micro-historia 2: La optimización que salió mal
Otra organización ejecutaba ZFS sobre un pool grande de HDDs y servía iSCSI a un conjunto de servidores de aplicaciones. Luchaban con latencia durante jobs batch. Alguien leyó que sync=disabled puede “hacer ZFS rápido” y lo presentó como una optimización reversible. Se aplicó en un dataset crítico con la lógica: “el SAN tiene UPS, y la app reintenta de todas formas”.
Lo que pasó siguiente fue sutil. Los jobs batch se hicieron más rápidos, sí. Tan rápidos que los sistemas aguas arriba aumentaron la concurrencia. La latencia se veía mejor al principio, pero ahora el pool absorbía más escrituras en memoria. Bajo ráfagas intensas, el sistema sufrió presión de memoria y los sync de TXG se volvieron más brutales. La plataforma desarrolló un nuevo patrón: paradas periódicas donde todo se pausaba para ponerse al día.
Entonces llegó la contrapartida: un kernel panic causado por un driver no relacionado. Cuando la máquina reinició, el pool se importó, pero la aplicación descubrió inconsistencias que no debían ser posibles bajo su modelo transaccional. El panic no fue una pérdida de energía, pero tuvo el mismo efecto: la memoria volátil desapareció, y con sync=disabled el almacenamiento había estado mintiendo sobre durabilidad todo el tiempo.
La lección real no fue “nunca cambiar settings”. Fue que la configuración cambió el contrato con la aplicación. Además, las ganancias de rendimiento pueden crear demanda que desplaza los cuellos de botella. Tras revertir a sync=standard y desplegar un SLOG PLP espejado apropiado, recuperaron la mayor parte del beneficio de rendimiento sin invalidar las garantías de durabilidad. El sistema pasó a ser predeciblemente rápido en lugar de ocasionalmente rápido y a veces catastrófico.
He visto ese patrón repetidamente: una optimización riesgosa “funciona” hasta que se vuelve una dependencia. Entonces deja de ser un ajuste; es una decisión de diseño que no documentaste.
Micro-historia 3: La práctica aburrida pero correcta que salvó el día
Una firma de servicios financieros (el tipo que tiene opiniones sobre “durable”) ejecutaba ZFS para NFS home directories y un pequeño cluster de bases de datos. Su SLOG era un par espejado de SSDs SATA empresariales con PLP. Nada emocionante. No nuevo. Pero cuidadosamente elegido: firmware estable, comportamiento conocido, buena endurance.
También hicieron algo poco a la moda: pruebas trimestrales de “tirar el enchufe” en un entorno de laboratorio que replicaba producción. No en el array en producción, sino en el mismo modelo con carga realista. Validaron que tras pérdida abrupta de energía, el pool se importaba limpiamente y las últimas escrituras sync confirmadas se mantenían consistentes a nivel de aplicación. Rastrearon la salud de los discos y reemplazaron SSDs envejecidos según indicadores de desgaste en lugar de esperanza.
Un año, un contratista de mantenimiento cortó por error la energía a la sección equivocada del rack. El UPS sostuvo la mayor parte, pero un PDU dejó caer lo suficiente para reiniciar el storage head. Los clientes se desconectaron. Saltaron alertas. La gente corrió al centro de datos con esa mezcla particular de urgencia y resignación.
El sistema regresó exactamente como indicaban los runbooks. ZFS reprodujo el log, las exportaciones se reanudaron y las aplicaciones se recuperaron sin reparar datos. El incidente siguió siendo caro en atención humana, pero no se convirtió en una crisis de integridad de datos. Más tarde, en la revisión, el equipo se dio cuenta de que la razón por la que estaban tranquilos no fue heroísmo: fue la repetición. Ya habían visto ese modo de fallo en pruebas y ya habían decidido cómo era “correcto”.
La lección es casi irritantemente simple: PLP más espejado más validación convierte “creemos que es seguro” en “sabemos cómo se comporta”. Eso es ingeniería de producción.
Preguntas frecuentes
1) ¿Siempre necesito un SLOG para ZFS?
No. Si tu carga es mayormente escrituras asíncronas (o centrada en lecturas), un SLOG puede no aportar casi nada. El SLOG importa cuando las escrituras sync son una porción significativa de tu presupuesto de latencia: NFS para VMs, bases de datos con patrones fsync-intensivos, algunas pilas iSCSI y cualquier carga que explícitamente solicite durabilidad por escritura.
2) ¿Puedo usar un SSD de consumo viejo como SLOG si lo espejo?
El espejado ayuda en fallos de dispositivo, no en la corrección ante pérdida de energía. Dos discos que pueden mentir sobre durabilidad no son una máquina de la verdad. Espejar unidades sin PLP puede reducir tiempo de inactividad pero no arregla el riesgo fundamental “confirmado pero no persistido”.
3) ¿Qué tamaño debe tener mi SLOG?
Normalmente pequeño. Piensa “segundos de tráfico sync pico”, no “porcentaje del pool”. Muchos sistemas en producción usan SLOGs de decenas de GB hasta algunos cientos de GB, a menudo porque el SSD empresarial adecuado viene en ese tamaño, no porque ZFS lo necesite.
4) ¿Debería poner el SLOG en NVMe o SATA?
NVMe suele ser mejor para latencia y manejo de colas, especialmente con muchos clientes. SATA puede estar bien si es un SSD empresarial con PLP y tu tasa de escrituras sync no es extrema. La clave es latencia baja y consistente bajo escrituras small+flush.
5) ¿Un SLOG ayuda al throughput de escrituras async?
Poco, y a veces nada. Las escrituras async están gobernadas principalmente por el sync de TXG al pool principal, memoria y ancho de banda del pool. SLOG ayuda la ruta de reconocimiento de las escrituras síncronas.
6) ¿Qué tal usar un “special vdev” en lugar de SLOG?
Herramienta distinta. Un special vdev acelera metadata y (opcionalmente) bloques pequeños, ayudando lecturas aleatorias y algunos patrones de escritura. No reemplaza al log de escrituras sync. Además, los special vdevs deben tratarse como críticos (espejarlos) porque perderlos puede ser catastrófico para el pool.
7) Si tengo PLP, ¿sigo necesitando un UPS?
Sí. PLP cubre un problema estrecho: el SSD persiste de forma segura las escrituras confirmadas cuando se va la energía. Un UPS cubre el problema más amplio: mantener todo el sistema estable, prevenir ciclos de fallo repetidos y darte tiempo para un apagado ordenado. Se complementan.
8) ¿Cómo sé si mi SSD realmente tiene PLP?
Confía en la documentación empresarial del proveedor y en la posición del producto, pero verifica operativamente: busca SSDs de clase datacenter con explicit power-loss data protection, revisa diseños con condensadores y evita unidades donde PLP sea vago o ausente. También observa comportamiento: dispositivos sin PLP suelen mostrar rendimiento de flush sospechoso y latencia sync inconsistente. Al final quieres evidencia, no esperanza.
9) ¿ZFS ignora las caches de los discos o fuerza flushes?
ZFS usa flushes y semánticas de orden apropiadas para operaciones síncronas, pero no puede forzar que un dispositivo sea honesto. Si el firmware confirma completitud antes de persistir los datos, el OS no puede hacerlo verdadero retrospectivamente. Por eso PLP importa.
10) ¿Qué sucede si mi SLOG muere?
Si el dispositivo SLOG falla, ZFS normalmente puede continuar con el pool (a menudo en estado degradado o tras eliminar el log), pero puedes perder las últimas escrituras sync confirmadas que solo vivían en el log. El rendimiento probablemente retrocederá a la latencia sync del pool principal, que en pools HDD puede ser brutal. Espejar reduce la probabilidad de que un único fallo SSD se convierta en outage.
Conclusión
Un SLOG no es un accesorio de vanidad para ZFS. Es una solución dirigida a un dolor específico: la latencia de escrituras síncronas. Pero en el momento en que pones un dispositivo en la ruta donde las aplicaciones esperan reconocimiento duradero, has promovido ese dispositivo de “almacenamiento rápido” a “parte de la verdad”.
Por eso la protección contra pérdida de energía es la característica que tu SSD SLOG debe tener. PLP hace que el rendimiento sea honesto. Espeja si la disponibilidad importa. Mantenlo frío. Mide el comportamiento sync antes y después. Y cuando te tiente un disco barato con benchmarks bonitos, recuerda que ZFS es transaccional—tu dispositivo de log debería serlo también.