Compraste un SSD SATA “rápido”, lo añadiste como SLOG de ZFS y esperabas milagros. En lugar de eso obtuviste NFS más lento, latencias variables de VM,
o—peor—un aumento silencioso del riesgo que solo se revela en el primer corte de energía que importa.
Un SLOG no es una caché. No es un botón turbo. Es una promesa que haces a las aplicaciones que dice “esta escritura ya es segura”.
Si mantienes esa promesa con un SSD SATA de consumo, estás apostando la producción a un dispositivo que nunca fue diseñado para ese tipo de juramento.
Qué hace realmente un SLOG (y qué no hace)
ZFS tiene dos conceptos relacionados que la mitología de los foros mezcla: el ZIL (ZFS Intent Log) y el SLOG
(Separate LOG device).
ZIL: el registro de intenciones dentro del pool que existe quieras o no
El ZIL no es una “función extra”. Forma parte de cómo ZFS proporciona semántica POSIX para las escrituras síncronas. Cuando una aplicación
llama a fsync(), usa O_SYNC, o cuando un protocolo exige escrituras estables (hola, NFS), ZFS debe confirmar solo después de que
los datos estén seguros frente a un fallo.
Para escrituras síncronas, ZFS primero escribe registros de transacción en el ZIL. Más tarde, durante el commit del grupo de transacciones (TXG),
los datos se escriben en su ubicación final en el pool. En caso de fallo/reinicio, ZFS reproduce el ZIL para recuperar las últimas escrituras
síncronas confirmadas.
SLOG: reubicar el ZIL en un dispositivo dedicado
Por defecto, el ZIL vive en el pool principal, repartido entre los vdevs de nivel superior. Añadir un SLOG le dice a ZFS: “coloca aquí los
registros del ZIL en su lugar”. El objetivo es reducir la latencia de las escrituras síncronas y suavizar la penalización de
escrituras aleatorias en cargas síncronas.
Solo ayuda si tu carga emite escrituras síncronas. Si tu carga es mayoritariamente asíncrona (escrituras masivas típicas, muchas bases de datos
afinadas para async, almacenamiento de medios), un SLOG es un adorno inútil.
Qué no es un SLOG
- No es un L2ARC. No cachea lecturas.
- No es una caché write-back. No absorbe todas las escrituras; solo acelera los reconocimientos de escrituras síncronas.
- No es una ganga de rendimiento. Un SLOG malo puede empeorar la latencia y aumentar el radio de desastre ante fallos.
El patrón de escritura de un SLOG es brutal: escrituras pequeñas, mayormente secuenciales, sensibles a la latencia y que deben ser durables ahora.
El dispositivo debe respetar flushes. Debe tener protección contra pérdida de energía o una durabilidad equivalente.
Y no debe bloquearse bajo presión sostenida de fsync.
Broma #1: Usar un SSD SATA de consumo como SLOG es como usar una almohada de viaje como casco de moto—suave, optimista y equivocado a toda velocidad.
Por qué un SLOG en SSD SATA suele decepcionar o fallar
El argumento de la mejora barata es seductor: “Tengo un SSD SATA de repuesto. Agrégalo como log. Las escrituras síncronas van brrr.” A veces obtienes
una pequeña ganancia. A menudo obtienes un desastre. He aquí por qué.
1) Los SSD SATA mienten (o al menos, negocian)
El SLOG solo es tan bueno como la capacidad del dispositivo para hacer que las escrituras sean durables a demanda. En términos de ZFS, esto significa
respetar los flushes de caché y no reconocer escrituras hasta que los datos estén en medios no volátiles.
Muchos SSD de consumo tienen cachés volátiles en DRAM y niveles variables de disciplina de firmware respecto a comandos de flush. Algunos son excelentes.
Algunos funcionan “hasta que no”. El peor caso es un disco que reconoce rápido pero pierde los últimos segundos de escrituras ante una pérdida de energía.
Para un SLOG, eso es catastrófico: ZFS reproducirá el ZIL después del reinicio, pero si el SLOG perdió registros de log reconocidos, has creado
una ventana para corrupción silenciosa o inconsistencias a nivel de aplicación.
2) La latencia importa más que el ancho de banda, y SATA es malo con la latencia bajo presión
El rendimiento de escrituras síncronas está dominado por la latencia de cola. Un SLOG que hace 50.000 IOPS en un benchmark pero que ocasionalmente
se pausa por recolección de basura, tareas del firmware o agotamiento de la caché SLC convertirá “rápido” en “esporádico”.
El protocolo y las colas de SATA también son limitados comparados con NVMe. No estás comprando solo rendimiento; estás comprando mejor comportamiento
bajo cargas concurrentes y pesadas en flush.
3) La resistencia y la amplificación de escritura aparecen antes de lo que crees
Un SLOG ve un flujo constante de escrituras pequeñas. ZFS escribe registros de log y luego los descarta tras el commit del TXG.
Ese churn puede producir amplificación de escritura y desgaste constante.
Los discos SATA de consumo suelen tener clasificaciones de resistencia más bajas y rendimiento sostenido débil una vez que su caché pseudo-SLC se agota.
El modo de fallo no siempre es “el disco muere”. A menudo es: la latencia se degrada, luego empiezas a ver timeouts de aplicaciones,
alguien desactiva sync para “arreglarlo”, y ahora estás funcionando sin red de seguridad.
4) El “SLOG barato y único” es un único punto de drama
ZFS puede operar sin un SLOG. Si el dispositivo de log falla, el pool típicamente continúa, pero puede perder las últimas escrituras
síncronas reconocidas (porque solo residían en el SLOG fallido).
Hacer mirror del SLOG elimina esa clase de riesgo, pero entonces tu “mejora barata” necesita dos dispositivos—y aún necesitas que ambos tengan
protección contra pérdida de energía y comportamiento estable ante flush.
5) Puede que ni siquiera tengas un problema de sync
Mucho del dolor de rendimiento en ZFS no es el ZIL. Es ARC insuficiente, tamaño de recordsize inapropiado, vdevs HDD fragmentados,
demasiados patrones de I/O pequeños en RAIDZ, saturación de CPU por checksumming/compresión, o una pila de hipervisor mal configurada para sync.
Añadir un SLOG a un sistema que ya está limitado por IOPS en otra parte es la clásica “herramienta aplicada a la herida equivocada”.
Hechos y contexto histórico que conviene conocer
Algunos puntos concretos—algo de historia, algo de ingeniería—que ayudan a cortar mitos. No son trivia; cambian decisiones.
- ZFS se originó en Sun a mediados de los 2000 con foco explícito en la integridad de datos: checksums end-to-end y copy-on-write no eran características opcionales.
- El ZIL existe incluso sin un SLOG; añadir un dispositivo de log solo lo reubica. La gente que “añade SLOG para escrituras más rápidas” suele malentender esto.
- NFS tradicionalmente trata muchas operaciones como síncronas (o demanda semánticas de almacenamiento estable), por eso la charla sobre SLOG a menudo empieza en entornos con mucho NFS.
- Las primeras eras del SSD hicieron que el comportamiento de flush fuera notoriamente inconsistente; errores de firmware en barreras de escritura y FUA dieron lugar a años de “rápido en benchmark” sorpresas.
- La profundidad de cola y la sobrecarga de protocolo de SATA son limitadas comparadas con NVMe; esto importa sobre todo para patrones paralelos y pesados en flush.
- La protección contra pérdida de energía (PLP) fue históricamente una característica empresarial porque requiere hardware (condensadores) y validación; los discos de consumo a menudo la omiten o implementan medidas parciales.
- Los TXG de ZFS suelen commitearse cada pocos segundos (ajustable), lo que define cuánto tiempo pueden vivir los registros de log antes de eliminarse—escrituras de corta vida y alta rotación.
- “Desactivar sync” se convirtió en un remedio popular en pilas de virtualización porque hace que los benchmarks se vean bien; también convierte la recuperación tras fallo en una escena del crimen.
Modos de fallo: rendimiento, corrección y “parecía estar bien”
Fallo de rendimiento: el SLOG se convierte en el cuello de botella
Cuando añades un SLOG, las operaciones síncronas deben pasar por ese dispositivo de log. Si ese dispositivo tiene mayor latencia que la mejor ruta sync del pool
(por ejemplo, un pool de SSD decentes, o incluso un espejo bien comportado de HDD con comportamiento de caché conocido), puedes hacer que las escrituras
síncronas sean más lentas.
Síntoma clásico: las escrituras regulares del pool están bien, las lecturas están bien, pero cualquier cosa que llame a fsync salta a decenas o cientos de
milisegundos de forma intermitente.
Fallo de corrección: reconocer escrituras que no son realmente durables
El escenario de pesadilla es un disco que devuelve éxito antes de que los datos sean seguros. Con un SLOG, ZFS usa ese “éxito” para decir a las aplicaciones
“tu escritura síncrona es segura”. Si se corta la energía y el disco pierde esos registros reconocidos, ZFS no puede reproducir lo que nunca persistió.
El pool se importará. Incluso puede parecer limpio. Tu aplicación será la que descubra transacciones de último segundo faltantes o corruptas.
La gente pregunta, “¿no protege ZFS contra eso?” ZFS protege contra muchas cosas. No puede hacer honesto a un dispositivo que miente.
Fallo de fiabilidad: el SLOG muere y pierdes las últimas escrituras seguras
Un SLOG no espejado es un único dispositivo entre tú y la pérdida de las escrituras síncronas reconocidas durante la ventana de fallo de ese dispositivo.
Incluso si aceptas el riesgo, la realidad operativa es más fea: cuando un SLOG empieza a fallar, a menudo falla bloqueando I/O,
provocando tormentas de latencia a nivel del sistema. Ahora estás resolviendo problemas en producción mientras la cola del hipervisor se llena.
Fallo operacional: alguien lo “arregla” deshabilitando sync
Aquí es donde suele terminar la mejora barata. Un equipo añade un SLOG SATA, ve peor latencia, cambia sync=disabled en un dataset,
celebra y sin saberlo cambia las semánticas de durabilidad para cada VM o cliente NFS que use ese dataset.
Cita (idea parafraseada) de Werner Vogels: “Todo falla, todo el tiempo—diseña tus sistemas asumiendo esa realidad.”
Guía de diagnóstico rápido
Quieres encontrar el cuello de botella rápido, sin ajustes basados en creencias. Aquí tienes un orden práctico de operaciones.
Primero: demuestra que tienes una carga síncrona
- Revisa las propiedades
syncdel dataset ZFS. - Revisa el comportamiento de la aplicación/protocolo (exportaciones NFS, ajustes del hipervisor, patrones de fsync de bases de datos).
- Ejecuta una prueba controlada de escrituras síncronas y compárala con async.
Segundo: mide la latencia y saturación del SLOG
- Usa
iostatpara ver si el dispositivo de log es el disco más activo durante el problema. - Busca picos en
await/ tiempos de servicio en el SLOG. - Comprueba si el SLOG es un SSD SATA con comportamiento de flush cuestionable o sin PLP.
Tercero: confirma la salud del pool y el comportamiento de los TXG
- Verifica que no haya vdev degradados ni resilvering en curso.
- Comprueba si hay amplificación de escrituras por escrituras pequeñas / mismatch de recordsize.
- Observa los tiempos de commit de TXG y los límites de datos sucios si sospechas bloqueos.
Cuarto: decide si quitar, espejar o reemplazar el SLOG
- Si el SLOG es más lento que el pool: quítalo.
- Si necesitas SLOG para semánticas sync de NFS/VM: reemplázalo por NVMe con PLP o SATA empresarial con condensadores; espeja si la carga importa.
- Si no necesitas aceleración sync: no ejecutes un SLOG “porque sí”.
Tareas prácticas: comandos, salidas y decisiones
Estas son tareas reales que puedes ejecutar en un host Linux usando OpenZFS. Cada una incluye qué significa la salida y qué decisión tomar.
Usa una ventana de prueba si vas a cambiar propiedades; los comandos abajo son principalmente de sólo lectura a menos que se indique lo contrario.
Tarea 1: Identificar si existe un SLOG y cuál es
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
logs
sdz ONLINE 0 0 0
errors: No known data errors
Significado: Hay un vdev de log dedicado (sdz). Ese es tu SLOG.
Decisión: Si sdz es un SSD SATA de consumo, trátalo como sospechoso hasta comprobar lo contrario.
Tarea 2: Confirmar la configuración sync del dataset (y encontrar sobrescrituras “útiles”)
cr0x@server:~$ sudo zfs get -r sync tank
NAME PROPERTY VALUE SOURCE
tank sync standard default
tank/vmstore sync standard local
tank/nfs sync disabled local
Significado: tank/nfs tiene sync=disabled, lo que cambia las semánticas de corrección.
Decisión: Si esto se hizo para “arreglar rendimiento”, trátalo como un riesgo de producción y planifica revertirlo con un SLOG apropiado o un cambio de carga.
Tarea 3: Determinar si el dispositivo de log es SATA y qué modelo es
cr0x@server:~$ lsblk -d -o NAME,ROTA,TRAN,MODEL,SIZE,SERIAL | grep -E 'sdz|nvme'
sdz 0 sata CT500MX500SSD1 465.8G 2219E5A1B2C3
Significado: El SLOG es un SATA Crucial MX500 (SSD de consumo común).
Decisión: Asume que no tiene PLP completa. Planifica validar el comportamiento de flush y la latencia bajo carga sync; considera reemplazarlo por un dispositivo con PLP.
Tarea 4: Comprobar si la unidad declara tener caché de escritura volátil
cr0x@server:~$ sudo hdparm -W /dev/sdz
/dev/sdz:
write-caching = 1 (on)
Significado: La caché de escritura está habilitada. Eso no es automáticamente malo si el disco tiene PLP; es peligroso si no la tiene.
Decisión: Si es un SSD de consumo sin PLP, no lo confíes como dispositivo de durabilidad para reconocimientos síncronos.
Tarea 5: Extraer detalles SMART y buscar pistas sobre protección ante pérdida de energía
cr0x@server:~$ sudo smartctl -a /dev/sdz | sed -n '1,60p'
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.0] (local build)
=== START OF INFORMATION SECTION ===
Model Family: Crucial/Micron MX500 SSDs
Device Model: CT500MX500SSD1
Serial Number: 2219E5A1B2C3
Firmware Version: M3CR046
User Capacity: 500,107,862,016 bytes [500 GB]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.1, 6.0 Gb/s
Local Time is: Thu Dec 26 11:02:41 2025 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Significado: SMART identifica una familia de SSD SATA de consumo. SMART raramente “confirma PLP” directamente en SATA de consumo.
Decisión: Trata la ausencia de soporte PLP explícito como “sin PLP”. Para SLOG, eso te empuja hacia reemplazo o eliminación.
Tarea 6: Comprobar desgaste y errores de medio en el posible SLOG
cr0x@server:~$ sudo smartctl -a /dev/sdz | egrep -i 'Media_Wearout|Percent_Lifetime|Reallocated|Uncorrect|CRC|Wear|Errors'
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
cr0x@server:~$ sudo smartctl -a /dev/sdz | egrep -i 'Reallocated_Sector_Ct|Reported_Uncorrect|UDMA_CRC_Error_Count|Percent_Lifetime_Remain|Power_Loss'
Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
Significado: No hay errores de medio obvios. Eso no significa que sea adecuado como SLOG; solo que no está muriendo ruidosamente.
Decisión: Si ves errores CRC, sospecha de cableado/backplane—arregla eso antes de culpar a ZFS.
Tarea 7: Observar la latencia por disco durante la ventana del incidente
cr0x@server:~$ sudo iostat -x 1
Linux 6.8.0 (server) 12/26/2025 _x86_64_ (32 CPU)
Device r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 2.0 18.0 64.0 980.0 98.0 1.20 22.3 8.1 24.0 1.8 36.0
sdz 0.0 420.0 0.0 2100.0 10.0 12.50 29.8 0.0 29.8 0.2 98.0
Significado: El dispositivo de log sdz está casi saturado con escrituras pequeñas (avgrq-sz ~10KB), y su await es alto.
Decisión: Tu SLOG es el cuello de botella. O lo reemplazas por un dispositivo PLP de baja latencia, lo espejas, o lo quitas para volver al ZIL en-pool.
Tarea 8: Confirmar que las escrituras síncronas están ocurriendo realmente
cr0x@server:~$ sudo zpool iostat -v tank 1
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 4.22T 6.58T 120 980 9.8M 44.1M
raidz2-0 4.22T 6.58T 120 910 9.8M 40.7M
sda - - 20 150 1.7M 6.8M
sdb - - 20 150 1.6M 6.8M
sdc - - 20 150 1.6M 6.8M
sdd - - 20 150 1.6M 6.8M
sde - - 20 155 1.7M 6.8M
sdf - - 20 155 1.6M 6.7M
logs - - 0 70 0K 3.4M
sdz - - 0 70 0K 3.4M
Significado: El vdev de log está recibiendo escrituras activamente. Eso sugiere fuertemente actividad síncrona.
Decisión: Si esperabas async, averigua quién (NFS, hipervisor, app) está forzando sync. Arregla la carga o provisiona un SLOG adecuado.
Tarea 9: Medir latencia sync vs async con fio (con cuidado)
Ejecuta esto en un dataset de prueba, no directamente en rutas de producción a menos que sepas lo que haces.
cr0x@server:~$ sudo fio --name=syncwrite --directory=/tank/test --rw=write --bs=4k --iodepth=1 --numjobs=1 --size=512M --fsync=1 --direct=1
syncwrite: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
...
write: IOPS=620, BW=2480KiB/s (2540kB/s)(512MiB/211498msec)
lat (usec): min=450, max=85000, avg=1600.12, stdev=4100.55
Significado: La latencia de escritura síncrona tiene picos feos en la cola (max 85ms). Eso es lo que sienten los usuarios.
Decisión: Si la latencia máxima es alta y se correlaciona con saturación del SLOG, reemplaza/quita el SLOG en lugar de intentar tunear alrededor.
Tarea 10: Validar si el SLOG está espejado (debería, si importa)
cr0x@server:~$ sudo zpool status tank | sed -n '1,40p'
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
logs
sdz ONLINE 0 0 0
Significado: SLOG de un solo dispositivo. Si falla, corres el riesgo de perder las últimas escrituras síncronas reconocidas.
Decisión: Si a tu negocio le importan esas escrituras (almacenamiento VM, NFS para directorios personales, bases de datos), espeja el SLOG o no uses uno.
Tarea 11: Comprobar si el pool está haciendo resilver/scrub (señal de alerta de rendimiento)
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Thu Dec 26 10:41:01 2025
1.92T scanned at 1.34G/s, 512G issued at 356M/s, 4.22T total
0B repaired, 12.13% done, 02:45:19 to go
config:
...
Significado: Hay un scrub en curso. Eso puede amplificar problemas de latencia, especialmente en pools HDD.
Decisión: Si la queja de rendimiento coincide con scrub/resilver, pausa la caza de tunning y vuelve a probar una vez que termine la carga de mantenimiento.
Tarea 12: Averiguar si el dataset usa bloques pequeños que penalizan RAIDZ
cr0x@server:~$ sudo zfs get recordsize,volblocksize,compression tank/vmstore
NAME PROPERTY VALUE SOURCE
tank/vmstore recordsize 128K local
tank/vmstore volblocksize - -
tank/vmstore compression lz4 local
Significado: Si esto es un dataset de imágenes VM respaldado por ficheros, 128K puede estar bien, pero a menudo quieres bloques más pequeños para patrones
de I/O aleatorio.
Decisión: Si tu problema son escrituras síncronas aleatorias en RAIDZ, considera espejos para cargas VM o ajusta el enfoque de almacenamiento VM—no esperes que un SLOG SATA salve a RAIDZ de la física.
Tarea 13: Verificar si tu SLOG se está usando realmente (no eludido)
cr0x@server:~$ sudo zdb -C tank | sed -n '1,120p'
MOS Configuration:
version: 5000
name: 'tank'
...
vdev_tree:
type: 'root'
id: 0
guid: 12345678901234567890
children[0]:
type: 'raidz'
...
children[1]:
type: 'log'
id: 1
guid: 998877665544332211
children[0]:
type: 'disk'
path: '/dev/disk/by-id/ata-CT500MX500SSD1_2219E5A1B2C3'
Significado: La configuración del pool incluye un vdev de log. ZFS lo usará para escrituras síncronas a menos que esté deshabilitado a nivel de dataset u otras restricciones apliquen.
Decisión: Si esperabas un log espejado pero ves un solo hijo, has encontrado un fallo de diseño, no un knob de tunning.
Tarea 14: Eliminar un SLOG problemático (si decides que hace daño)
Esto cambia el comportamiento. Planifícalo. Comunícalo. Y recuerda: eliminar el SLOG no “apaga” el ZIL; lo mueve de nuevo al pool.
cr0x@server:~$ sudo zpool remove tank sdz
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
errors: No known data errors
Significado: El log dedicado ha desaparecido. Las escrituras síncronas ahora van al ZIL en-pool.
Decisión: Si la latencia mejora de inmediato, el SLOG SATA era tu cuello de botella. El siguiente paso es elegir entre “sin SLOG” o “SLOG PLP espejado adecuado”.
Tarea 15: Si debes tener un SLOG, añádelo como espejo usando IDs de dispositivo estables
cr0x@server:~$ sudo zpool add tank log mirror /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0A /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0B
cr0x@server:~$ sudo zpool status -v tank | sed -n '1,80p'
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
logs
mirror-1 ONLINE 0 0 0
nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0A ONLINE 0 0 0
nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0B ONLINE 0 0 0
errors: No known data errors
Significado: SLOG espejado usando dispositivos NVMe (ejemplo). Ese es el patrón estructural correcto para fiabilidad.
Decisión: Si no puedes permitirte dos dispositivos adecuados, no puedes permitirte un SLOG para cargas síncronas importantes. Funciona sin él.
Tres micro-historias corporativas desde el campo
Micro-historia #1: Un incidente causado por una suposición errónea
Una empresa mediana consolidó unas NAS envejecidas en un servidor ZFS nuevo. Ejecutaban NFS para directorios de usuario y salidas de compilación.
Alguien leyó que “SLOG acelera escrituras” y añadió un SSD SATA de consumo sobrante como dispositivo de log. Hicieron una copia rápida de archivos, no vieron
una regresión obvia y siguieron. A todos les gusta una mejora rápida. A todos les gusta marcar una casilla.
Semanas después, un breve evento de energía golpeó el rack—transferencia de UPS, no un apagón total. El servidor se mantuvo vivo. El SSD SATA no.
Se cayó del bus por un momento y volvió. ZFS no entró en pánico inmediato; el pool siguió en línea. El equipo respiró.
A la mañana siguiente, los desarrolladores se quejaron de fallos de compilación “aleatorios” y artefactos corruptos. Nada estaba consistentemente roto.
Repetir la misma compilación a veces funcionaba. Ese es el peor tipo de fallo: intermitente, erosionador de confianza y difícil de reproducir.
El detalle clave fue la suposición: creyeron que el SLOG era “solo rendimiento”, no semántica de durabilidad. También creyeron que un SSD
es intrínsecamente más seguro que discos giratorios. Pero el SLOG era el único lugar donde vivían esos registros síncronos reconocidos hasta el commit TXG.
Cuando el dispositivo se comportó raro durante una anomalía de energía, algunas escrituras reconocidas nunca llegaron.
La solución no fue heroica. Eliminaron el SLOG, forzaron a los clientes a remount, y detuvieron el patrón de corrupción. Más tarde añadieron un dispositivo
de log espejado y con protección contra pérdida de energía y documentaron por qué existía. La lección quedó porque el incidente fue lo suficientemente doloroso,
y no tan doloroso como para que despidieran a todos.
Micro-historia #2: Una “optimización” que salió mal
Un clúster de virtualización alojaba cargas mixtas: unas pocas bases de datos sensibles a la latencia, muchas VMs de propósito general. El equipo de almacenamiento
vio gráficos con picos periódicos de fsync. Añadieron un SLOG SATA al backend de ZFS esperando aplanar esos picos.
Inicialmente, la latencia mediana mejoró un poco. El equipo celebró. Luego llegó el cierre de mes y el patrón real cambió: muchas transacciones concurrentes pesadas en sync.
El disco SLOG alcanzó sus límites de escritura sostenida, la caché pseudo-SLC se agotó y la latencia de escritura pasó de “mayormente bien” a “variable y a veces horrible”.
Las VMs no solo se ralentizaron; sincronizaron su miseria. Cuando el SLOG se bloqueó, bloqueó los ack síncronos de muchas VMs, provocando que los sistemas invitados encolaran,
provocando timeouts en aplicaciones, reintentos que incrementaron la presión de escritura. Las tormentas de latencia tienen talento para sostenerse a sí mismas.
Alguien propuso el clásico arreglo: desactivar sync en el zvol que respaldaba el almacenamiento VM. Los gráficos mejoraron notablemente.
También convirtió una carga consistente tras fallo en un “buena suerte”. Una semana después, un pánico de host forzó un reinicio.
Una base de datos volvió con errores de recuperación que fueron caros de investigar e imposibles de demostrar totalmente después.
Revirtieron la “optimización”, quitaron el SLOG SATA y más tarde instalaron un SLOG NVMe PLP espejado. La solución real no fue “SSD más rápido”.
Fue latencia estable y semánticas correctas, además de una política clara: nadie desactiva sync sin aceptación formal de riesgo.
Micro-historia #3: La práctica aburrida pero correcta que salvó el día
Otra organización ejecutaba ZFS para NFS e iSCSI con una mezcla de espejos HDD y espejos SSD. Tenían un SLOG—pero estaba espejado, y estaba formado por
discos empresariales con protección contra pérdida de energía. La elección parecía extravagante comparada con un SSD SATA barato. No lo era.
Lo que los diferenciaba no era solo el hardware; era el proceso. Trataban el SLOG como un componente de durabilidad, no como un juguete de rendimiento.
Monitorizaban SMART de desgaste. Realizaban simulacros mensuales de inyección de fallos en ventana de mantenimiento: extraer un dispositivo SLOG,
confirmar que el pool sigue sano, confirmar que el rendimiento sigue aceptable, reemplazar, resilverizar, repetir.
Un día un bug de firmware hizo que un dispositivo SLOG empezara a lanzar errores. La monitorización alertó temprano—antes de que los usuarios se quejaran.
Sacaron el dispositivo limpiamente, lo reemplazaron y siguieron funcionando con la pata restante del espejo. Sin pérdida de datos. Impacto mínimo de latencia.
Un ticket, un swap y listo.
El incidente nunca se convirtió en una historia interna porque nunca fue dramático. Ese es el punto. Lo aburrido es una característica en almacenamiento.
Errores comunes: síntoma → causa raíz → solución
1) Síntoma: “Añadir SLOG hizo NFS más lento”
Causa raíz: El SLOG SATA tiene peor latencia de fsync que la ruta ZIL en-pool, especialmente bajo carga o recolección de basura.
Solución: Quita el SLOG y vuelve a probar; si necesitas SLOG, reemplázalo por un dispositivo PLP de baja latencia (preferiblemente espejado).
2) Síntoma: “Picos de latencia cada pocos minutos”
Causa raíz: Tareas del firmware del SSD, agotamiento de caché SLC, o ráfagas relacionadas con TXG interactuando con un SLOG saturado.
Solución: Observa iostat -x para %util y await del SLOG. Si el SLOG está saturado, reemplázalo o quítalo.
3) Síntoma: “Es rápido en benchmarks, los usuarios siguen quejándose”
Causa raíz: Mediste throughput, pero los usuarios sienten la latencia de cola. Las cargas sync se preocupan por el 1% más lento.
Solución: Usa fio --fsync=1 con iodepth bajo y monitoriza la latencia máxima; resuelve la latencia de cola, no el ancho de banda pico.
4) Síntoma: “Desactivamos sync y todo mejoró”
Causa raíz: Eliminaste el requisito de hacer durables las escrituras antes del ack. El rendimiento “mejora” porque cambiaste el contrato.
Solución: Vuelve a activar sync para datasets que necesiten corrección; despliega un SLOG adecuado o rediseña la carga (por ejemplo, cache local, journaling a nivel de app).
5) Síntoma: “Tras un evento de energía, los datos de la aplicación son inconsistentes”
Causa raíz: El SLOG no PLP perdió escrituras reconocidas, o el disco mintió sobre flush. ZFS no puede reproducir lo que nunca persistió.
Solución: Deja de usar SSD SATA de consumo como SLOG. Usa dispositivos con PLP; espeja el SLOG; revisa UPS y política de caché de escritura.
6) Síntoma: “El pool se importa bien, pero faltan las últimas transacciones”
Causa raíz: Los ack síncronos se hicieron sobre un SLOG que no persistió.
Solución: Trátalo como un incidente de durabilidad. Audita el historial de sync de los datasets y el hardware del SLOG. Reemplaza por espejo PLP y valida procedimientos de recuperación.
7) Síntoma: “El disco SLOG sigue desconectándose del bus SATA”
Causa raíz: Problemas de cableado/backplane, inestabilidad de alimentación, o firmware del SSD de consumo que no soporta patrones sostenidos de flush.
Solución: Arregla la ruta hardware (cables, firmware del HBA, alimentación), y luego deja de usar ese modelo como dispositivo de log. Un SLOG inestable es peor que no tener SLOG.
8) Síntoma: “El desgaste del SLOG sube rápido”
Causa raíz: Alta tasa de escrituras síncronas + amplificación de escritura; la resistencia del consumo es insuficiente.
Solución: Usa discos de resistencia empresarial para el log, dimensiona adecuadamente y monitoriza el desgaste; considera cambios de carga para reducir sync forzado (donde sea seguro).
Broma #2: Desactivar sync para “arreglar” la latencia del SLOG es como quitar el detector de humo porque es demasiado ruidoso.
Listas de verificación / plan paso a paso
Paso a paso: decidir si deberías tener un SLOG
- Lista los consumidores del dataset. ¿NFS? ¿Imágenes VM? ¿Bases de datos? Identifica quién emite escrituras síncronas.
- Revisa propiedades del dataset. Si
sync=disabledestá presente en algún sitio, márcalo como ítem de riesgo. - Mide la latencia de escritura síncrona sin SLOG. Si ya es aceptable, no añadas complejidad.
- Si necesitas SLOG, define el contrato. ¿Aceleras escrituras síncronas por corrección, o estás enmascarando un problema de diseño?
Paso a paso: si ya instalaste un SLOG en SSD SATA
- Identifica el dispositivo y el modelo. Si es de consumo, asume “sin PLP”.
- Comprueba si está espejado. Si no está espejado, documenta el riesgo y prioriza la remediación.
- Observa bajo carga. Vigila
iostat -xyzpool iostat -vdurante periodos sync intensos. - Ejecuta una prueba controlada fio sync. Mide latencia máxima y jitter, no solo IOPS.
- Toma la decisión: quítalo o reemplázalo por dispositivos PLP espejados.
Paso a paso: construir una configuración de SLOG correcta (la que no lamentarás)
- Elige dispositivos diseñados para escrituras durables y baja latencia. PLP es la característica principal; latencia consistente es la oculta.
- Usa dos dispositivos en espejo. Si no puedes, acepta que eliges “riesgo” como característica.
- Usa rutas de dispositivo estables. Prefiere
/dev/disk/by-id/..., no/dev/sdX. - Prueba el failover. Desconecta un dispositivo de log en una ventana de mantenimiento; confirma que el pool sigue sano y que la latencia se mantiene.
- Monitoriza desgaste y errores. Configura alertas para desgaste SMART, errores de medio y reseteos de bus.
Checklist operacional: cosas que documentar para que el tú del futuro no sufra
- Qué datasets requieren semánticas sync y por qué (exportaciones NFS, almacenes VM, volúmenes de base de datos).
- El comportamiento esperado si el SLOG falla (qué riesgo existe, qué alertas se disparan, qué pasos del runbook hay que seguir).
- Cómo eliminar/reemplazar el SLOG de forma segura.
- Quién está autorizado a cambiar propiedades
syncy bajo qué aprobación.
Preguntas frecuentes
1) ¿Un SLOG acelerará todas las escrituras en ZFS?
No. Solo ayuda a las escrituras síncronas. Las escrituras async las esquivan y pasan por el buffering normal del TXG y commit.
2) ¿Cómo sé si mi carga es intensiva en sync?
Observa escrituras pesadas en el vdev de log con zpool iostat -v. Confirma las propiedades sync del dataset.
Para NFS y muchas pilas de VM, asume sync significativo salvo que hayas verificado cliente/servidor.
3) ¿Usar un SSD SATA de consumo como SLOG siempre está mal?
Para experimentación en homelab no crítico, puedes hacerlo. Para producción donde importe la corrección de datos, suele ser la apuesta equivocada.
El riesgo es de durabilidad y picos de latencia, no solo velocidad bruta.
4) ¿Cuál es la diferencia entre ZIL y SLOG?
ZIL es el mecanismo. SLOG es un dispositivo dedicado donde se almacenan los registros del ZIL. Sin SLOG, el ZIL vive en el pool.
5) ¿El SLOG debería estar espejado?
Si te importa que las escrituras síncronas reconocidas sobrevivan a la falla de un dispositivo, sí. Un SLOG único es un único punto donde “esas escrituras se pierden”.
6) Si el SLOG muere, ¿pierdo todo el pool?
Normalmente no; el pool puede seguir funcionando o importarse sin el dispositivo de log dependiendo del momento y la configuración. El peligro real es la pérdida de las últimas escrituras síncronas reconocidas.
7) ¿Por qué no simplemente poner sync=disabled y seguir?
Porque cambias el contrato de almacenamiento. Bases de datos, sistemas de archivos de VM y clientes NFS pueden creer que los datos están seguros cuando no lo están.
Así obtienes “todo parecía bien” seguido de inconsistencia tras un fallo.
8) ¿Qué tamaño necesita un SLOG?
A menudo es más pequeño de lo que la gente piensa. Almacenas registros de log de corta vida hasta el commit TXG. El tamaño ayuda con sobreaprovisionamiento y resistencia,
pero la consistencia de latencia y PLP importan más que la capacidad.
9) ¿NVMe es siempre mejor para SLOG?
NVMe tiende a tener mejores características de latencia y colas, pero “NVMe” no garantiza PLP o comportamiento consistente.
Aún debes escoger modelos conocidos por flushs durables y latencia de cola estable.
10) ¿Podría mi problema ser ARC o RAM, no SLOG?
Sí. Si las lecturas están thrashing y el sistema tiene falta de memoria, todo se ralentiza y atribuirás mal el fallo al log.
Por eso el diagnóstico rápido empieza probando que realmente es un cuello de botella de escrituras síncronas.
Conclusión: pasos siguientes que puedes ejecutar hoy
Un SLOG en SSD SATA resulta tentador porque es barato y fácil. Eso también explica por qué es una fuente fiable de dolor en producción:
cambia las semánticas de durabilidad, concentra la latencia sync en un solo dispositivo y expone las esquinas feas del comportamiento de SSD de consumo.
Pasos prácticos siguientes:
- Ejecuta la guía de diagnóstico rápido. Confirma que tienes un problema de sync antes de comprar hardware o cambiar propiedades.
- Si ya tienes un SLOG SATA de consumo, mídelo. Si está al máximo o es irregular, quítalo y vuelve a probar. No adivines.
- Si necesitas un SLOG para corrección en NFS/VM, hazlo bien. Usa dispositivos con protección contra pérdida de energía y espejados.
- Deja de tratar
sync=disabledcomo un knob de tuning. Trátalo como una aceptación de riesgo que requiere supervisión responsable.
El objetivo no es números de benchmark máximos. El objetivo es latencia estable y semánticas fiables—especialmente el peor día, cuando parpadea la energía,
un disco se comporta mal y tu trabajo es explicar la realidad a quienes esperaban seguridad.