logbias de ZFS: Latencia frente a rendimiento — Elige lo que realmente necesitas

noviembre 19, 2025 • febrero 3, 2026 • Lectura: 27 min • Views: 8

¿Te fue útil?

ZFS tiene una reputación: integridad a prueba de fallos, valores predeterminados sensatos y los suficientes controles para que puedas salvar tu incidente —o provocarlo. logbias es uno de esos controles. No es glamoroso y no arreglará un pool fundamentalmente lento. Pero puede cambiar por completo la forma de tu rendimiento, especialmente cuando te importan las escrituras síncronas.

Si gestionas bases de datos, almacenamiento de máquinas virtuales, exportaciones NFS o cualquier cosa que use fsync() como si le pagaran por cada llamada, tu verdadera pregunta no es “¿Qué tan rápido es ZFS?” Sino “¿Qué quiero: menor latencia por sincronización o más rendimiento agregado a lo largo del tiempo?” logbias es donde le dices a ZFS lo que realmente necesitas, en lugar de lo que esperas que ocurra.

Qué es realmente `logbias` (y qué no es)

logbias es una propiedad por dataset (o por zvol) que influye en cómo ZFS maneja las escrituras síncronas: si debe usar preferentemente la ruta del ZFS Intent Log (ZIL) para un reconocimiento de baja latencia, o si debe inclinarse a empujar los datos hacia el pool principal de forma más directa para obtener mejor rendimiento agregado.

En la práctica importan dos valores:

logbias=latency (por defecto): prioriza baja latencia para escrituras síncronas; usa la ruta ZIL/SLOG agresivamente.
logbias=throughput: trata de evitar patrones de “escritura doble” y reducir la dependencia del dispositivo de log para escrituras síncronas grandes; empuja más al pool principal cuando sea razonable.

Qué no es:

No es una bandera mágica para “hacer mi pool rápido”. Si tu pool está sobrecargado o tiene un comportamiento de escritura aleatoria terrible, logbias no lo solucionará.
No es lo mismo que sync=disabled. logbias no cambia las garantías de corrección. sync=disabled sí lo hace.
No sustituye a un SLOG adecuado (si tu carga lo necesita), ni a un dimensionado correcto de registros o al ajuste de la base de datos.

Resumen operacional en una frase: logbias trata sobre dónde ZFS prefiere asumir el coste del reconocimiento de escrituras síncronas—en la ruta del log ahora, o en el pool principal pronto—sin engañar a las aplicaciones.

Broma #1: Establecer logbias=throughput sin medir es como “optimizar” una reunión quitando el orden del día: técnicamente más rápida, espiritualmente desastrosa.

Un modelo mental práctico: ZIL, SLOG, TXGs

Si llevas tiempo con ZFS, has oído estos acrónimos como si fueran evidentes. No lo son. Hagamos que sean útiles.

ZIL: el intent log, siempre presente

El ZFS Intent Log (ZIL) existe para un trabajo: asegurar que ZFS pueda reconocer de forma segura las escrituras síncronas. Cuando una aplicación realiza una escritura sync (o llama a fsync()), ZFS debe confirmar suficiente información en almacenamiento estable para que, tras un fallo, pueda reproducir esas operaciones y mantener las garantías a nivel de aplicación.

Importante: el ZIL no es una caché de escritura para todo. Es un registro de transacciones síncronas recientes, y solo se usa para recuperación después de un apagado no limpio. En operación normal, los datos acaban en el pool principal como parte de los commits de grupos de transacción (TXG).

SLOG: un dispositivo separado para el ZIL, opcional pero potente

SLOG es el nombre que usan los operadores para un dispositivo de log separado conectado vía vdev(s) log (por ejemplo, un SSD o NVMe de clase empresarial). Cuando está presente, ZFS escribe los registros ZIL en ese dispositivo en lugar de colocarlos en el pool principal.

Esta es la matiz crítica que provoca tantas discusiones en producción: SLOG trata sobre latencia e IOPS para escrituras síncronas, no sobre acelerar escrituras asíncronas ni aumentar el ancho de banda total del pool para cargas secuenciales.

TXGs: el sistema de agrupamiento que hace a ZFS eficiente

ZFS agrupa modificaciones en TXGs y las confirma periódicamente en disco. La cadencia por defecto está en el orden de segundos (depende de la implementación; el punto operativo es “por lotes”). Este agrupamiento es donde ZFS obtiene gran parte de su rendimiento: puede reordenar, consolidar y escribir de forma eficiente.

Las escrituras síncronas interrumpen la fiesta. ZFS aún quiere agrupar, pero también debe proporcionar un reconocimiento estable. El ZIL/SLOG es el compromiso: “registraré lo suficiente para sobrevivir a un fallo ahora, luego fusionaré todo en el pool principal en un lote razonable más tarde”.

La “escritura doble” que en realidad importa

En muchas cargas intensas en sync, efectivamente escribes los datos dos veces:

Escribir registros de log en el ZIL (en SLOG o en el pool) para poder reconocer la sincronización.
Más tarde, escribir los bloques reales en su ubicación final durante el commit de TXG.

Esto no es “desperdicio”; es cómo ZFS proporciona corrección y rendimiento. Pero significa que tu dispositivo más rápido puede convertirse en tu cuello de botella de una manera muy específica: un SLOG pequeño manejando escrituras síncronas pequeñas puede limitar la tasa de transacciones de toda la aplicación.

Latencia vs rendimiento: qué cambia `logbias`

Aquí está la explicación a nivel operador: ZFS debe decidir cómo manejar las escrituras síncronas, particularmente las grandes. Registrar grandes cantidades de datos en el ZIL puede ser caro y puede crear una segunda corriente de escrituras que el sistema debe absorber más tarde. En esas situaciones puede ser más sensato tratar una “escritura grande síncrona” como “debería llevar esto al pool con prontitud” en lugar de “voy a pasar todo esto por el dispositivo de log”.

logbias es la pista que guía esa decisión.

`logbias=latency` (por defecto): hacer rápido el reconocimiento sync

Cuando tu carga emite escrituras síncronas con frecuencia y le importa el tiempo de respuesta de cada transacción—bases de datos con commits durables, NFS con semántica sync, discos de VM con barreras—la latencia es lo que importa.

Con logbias=latency:

ZFS estará más dispuesto a empujar los datos de escrituras síncronas hacia la ruta ZIL/SLOG.
Si tienes un buen SLOG (baja latencia, protección ante pérdida de energía), a menudo verás una latencia de commit mucho menor.
Tu pool puede mantenerse relativamente tranquilo porque el SLOG absorbe la ráfaga de sync, y el pool se pone al día en las escrituras de TXG.

Qué puede salir mal: si tu SLOG es lento, de consumo, carece de PLP o está conectado por un bus ya saturado, habrás creado un punto único de fallo de rendimiento. El pool puede estar bien; la ruta de reconocimiento sync no.

`logbias=throughput`: reducir la dependencia del log, favorecer el envío al pool

logbias=throughput se usa típicamente para cargas que generan escrituras síncronas pero donde la latencia por escritura es menos importante que el rendimiento total: piensa en escrituras secuenciales grandes marcadas como síncronas por el comportamiento de la aplicación, capas de virtualización o configuraciones conservadoras de exportación.

Con logbias=throughput:

A ZFS se le incentiva a evitar pasar grandes escrituras síncronas por el ZIL, porque eso puede convertirse en “registrarlo ahora, escribirlo de nuevo después” a escala.
El pool principal hace más del trabajo pesado directamente, lo cual puede ser mejor si tu pool es ancho (muchos vdevs) y tu SLOG es un dispositivo relativamente pequeño.

Qué puede salir mal: puedes desplazar el cuello de botella de la latencia del SLOG a la latencia de escritura del pool. Si el pool está formado por discos giratorios lentos, o si ya está fragmentado, o si tienes mucha presión de lectura, empujar más datos sync “directamente al pool” puede aumentar la latencia visible por la aplicación. En otras palabras: obtuviste rendimiento y pagaste por ello en la latencia en cola.

Lo que `logbias` no arregla

Algunos problemas están aguas arriba y se reirán de tus ajustes de propiedad:

Recordsize/volblocksize mal dimensionados para la carga de trabajo.
Invitados VM haciendo escrituras aleatorias pequeñas síncronas a zvols thin-provisioned con compresión desactivada y sin TRIM.
Exportaciones NFS con comportamiento sync que fuerza cada escritura a ser duradera antes de devolverla, combinado con un SLOG mediocre.
Un pool que simplemente se quedó sin cabecera de IOPS.

Broma #2: El SLOG es como el portero de una discoteca—si contratas a alguien lento, no importa qué tan grande sea la pista; nadie entra.

Datos e historia útiles para reuniones

Estos son los puntos cortos y concretos que te ayudan a cortar el tuning cargo-cult en las revisiones de diseño.

ZFS fue diseñado alrededor de semánticas transaccionales, no para “escribir en el lugar inmediatamente”. Los TXGs son fundamentales, no un complemento.
El ZIL existe aun sin un SLOG. Si no añades un vdev de log, los registros ZIL aterrizan en los dispositivos del pool principal.
SLOG solo se usa para escrituras síncronas. Las escrituras asíncronas en streaming no se aceleran de repente por añadir un dispositivo de log.
El ZIL normalmente solo se lee después de un fallo. En operación saludable, los datos del ZIL son “solo escritura” y se descartan tras el commit del TXG.
La protección ante pérdida de energía (PLP) no es una característica de rendimiento; es de corrección. Sin PLP, un reconocimiento “rápido” puede convertirse en “pérdida rápida de datos”.
Muchas pilas de virtualización y almacenamiento en red generan escrituras síncronas de forma conservadora (barreras, flushes, escrituras estables). A veces no es que la app sea paranoica; es la pila.
Las primeras implementaciones de ZFS popularizaron la táctica de “añadir un SSD SLOG”, pero los SSDs de consumo a menudo mentían sobre la durabilidad de flush: los operadores lo aprendieron a la fuerza.
Los dispositivos de log separados pueden replicarse en espejo, porque perder un SLOG durante la operación puede causar un panic/offline del pool en algunas plataformas/configuraciones—la disponibilidad importa.
Latencia y rendimiento pueden moverse en direcciones opuestas cuando cambias la ruta de reconocimiento sync, porque cambias qué dispositivo se convierte en “la puerta”.

Tres micro-historias del mundo corporativo (fallo, contragolpe, salvación)

1) Incidente causado por una suposición errónea: “SLOG hace todo más rápido”

Una empresa mediana ejecutaba un servicio NFS respaldado por ZFS para artefactos de compilación e imágenes VM. Tenían un problema de rendimiento: algunos clientes se quejaban de “pausas aleatorias”. Alguien propuso lo clásico: “Añade un NVMe rápido como SLOG; ZFS volará”. Compras entregó un NVMe de consumo con grandes benchmarks secuenciales y un precio que alegró a Finanzas.

Lo añadieron como un único vdev de log y se fueron a casa. Durante unos días, todo pareció mejor—latencia promedio menor en escrituras NFS, menos tickets. Luego tuvieron un evento de energía: un breve corte, conmutación de UPS, nada dramático. El servidor de almacenamiento volvió, y en minutos el pool estaba en problemas. Los clientes vieron errores de E/S y mounts colgados. La máquina no estaba muerta; era peor: estaba viva y confundida.

La causa raíz fue dolorosamente ordinaria. El NVMe de consumo no proporcionaba protección fiable ante pérdida de energía para las semánticas de flush. Durante el evento de energía, registros de log que se habían reconocido como durables no lo eran realmente. ZFS hizo exactamente lo que debía: se negó a continuar de forma segura cuando la cadena de logs no tenía sentido. El equipo asumió “SSD rápido = buen SLOG”, y la producción estuvo en desacuerdo.

La solución no fue tuning místico. Reemplazaron el SLOG por un dispositivo empresarial con PLP y lo pusieron en espejo. Luego hicieron lo aburrido: documentaron que “SLOG no es una caché; es una promesa”. También añadieron monitorización para detectar latencia y tasas de error del dispositivo de log antes de que se convierta en un incidente del servicio.

2) Optimización que se volvió en contra: “logbias=throughput en todas partes”

Otro entorno: un clúster de virtualización usando zvols para discos de VM sobre iSCSI. El equipo de almacenamiento vio que el SLOG estaba ocupado y algunas VMs tenían un rendimiento de escritura mediocre. Alguien leyó que logbias=throughput puede mejorar el rendimiento para escrituras síncronas grandes y decidió aplicarlo a todo: todos los datasets, todos los zvols, sin excepciones. La ventana de cambio fue pequeña y la motivación comprensible: menos cambios significan menos errores.

A la mañana siguiente, los tickets de helpdesk no eran sobre throughput. Eran sobre “la VM se siente lenta”, “los commits de la base de datos a veces se atoran”, y el que llama la atención: “la API de pagos caduca intermitentemente”. Los gráficos parecían bien en promedios. Las latencias en cola empeoraron.

Lo ocurrido fue arquitectónico. Algunas VMs hacían escrituras secuenciales grandes (trabajos de backup) y de hecho vieron mejor throughput. Pero los vecinos ruidosos no eran el problema. Las cargas sensibles eran bases de datos pequeñas y heavy en sync. Al sesgar fuera de la ruta de log, el sistema empujó más trabajo sync al pool principal. El pool pudo hacerlo, pero no con baja latencia cuando se mezclaba con carga de lectura y actividad periódica de scrub. La latencia de commit aumentó y luego se propagó en timeouts de la aplicación.

Revirtieron selectivamente: logbias=latency para los zvols de base de datos, logbias=throughput para backups y volúmenes de ingestión masiva. Luego establecieron SLOs de rendimiento que rastreaban explícitamente latencia p95/p99 de commit para escrituras síncronas, no solo MB/s. La optimización no era incorrecta; la suposición de que una configuración vale para todas las cargas sí lo fue.

3) Una práctica aburrida pero correcta que salvó el día: “medir latencia sync y espejar el SLOG”

Una entidad de servicios financieros (de las que tratan el almacenamiento como un producto de primera clase) ejecutaba ZFS para un conjunto de clusters PostgreSQL internos. Les habían mordido antes los hardware “rápidos pero endebles”, así que su práctica era casi aburrida: dispositivos SLOG empresariales espejados con PLP, y un panel que seguía métricas relacionadas con ZIL y la latencia de escrituras síncronas.

Una tarde, los equipos de aplicación empezaron a reportar latencia de transacción ligeramente elevada. No fue un outage—solo las señales tempranas que suelen ignorarse hasta que se convierten en un fin de semana. El SRE de guardia revisó el panel y notó un cambio: la latencia de escritura del vdev de log había subido, mientras que la latencia del pool estaba normal. Ese es un olor muy específico.

Revisaron los logs del sistema y vieron errores de medio intermitentes en uno de los dispositivos SLOG. Como el vdev de log estaba en espejo, el pool se mantuvo sano y el servicio siguió arriba. Porque midieron lo correcto (latencia sync), lo detectaron antes de que fuera un incidente. Reemplazaron el dispositivo defectuoso durante horario laboral sin drama, que es el mejor tipo de informe de incidente: el que nadie escribe.

Esta es la parte difícil de vender en reuniones de presupuesto: la práctica aburrida no “aumentó el rendimiento”. Previno que el rendimiento se convirtiera en disponibilidad.

Guion de diagnóstico rápido

Esta es la secuencia “tienes 15 minutos antes de la llamada de escalado”. El objetivo es identificar si tu cuello de botella es la semántica de la aplicación, la ruta de log o el pool principal.

Primero: confirma que realmente estás tratando con escrituras síncronas

Revisa propiedades de dataset/zvol: sync, logbias.
Revisa comportamiento del cliente/protocolo: montajes NFS, ajustes de durabilidad de la base de datos, barreras de VM.
Busca síntomas: alta latencia con bajo throughput, muchas escrituras pequeñas, patrones intensivos en fsync.

Segundo: determina si la ruta de log (SLOG) es la puerta

Si tienes un SLOG, verifica la latencia y errores del vdev de log.
Compara la latencia de commit de la app con la latencia del dispositivo SLOG. Si coinciden, encontraste tu cuello de botella.
Revisa si el SLOG está saturado (IOPS, profundidad de cola) o atascado (latencia de flush).

Tercero: si no es el SLOG, el pool es tu cuello de botella (o la CPU)

Revisa la latencia de escritura y la utilización del pool. Si los vdevs del pool están cerca del 100% ocupados, te quedaste sin capacidad.
Revisa presión de ARC y amplificación de lectura; lecturas intensas pueden robar tiempo a las escrituras.
Revisa compresión, checksumming y sobrecarga de cifrado si la CPU está al máximo.

Punto de decisión

Si la latencia de escrituras síncronas es el problema:

Prefiere logbias=latency con un SLOG adecuado para datasets sensibles a la latencia.
Considera logbias=throughput solo donde la carga sea grande y secuencial y donde escribir más al pool no viole los SLOs de latencia.

Tareas prácticas: comandos, salidas, interpretación

Estas son tareas reales que puedes ejecutar en un sistema típico OpenZFS-on-Linux. Ajusta nombres de pool/dataset para coincidir con tu entorno. El punto no es ejecutar comandos por deporte; es convertir logbias de folklore en una elección medida.

Tarea 1: Inspeccionar `logbias` y `sync` actuales en un dataset

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

Interpretación: Este dataset está explícitamente configurado con logbias=latency. El comportamiento sync es standard (respetar peticiones de la aplicación). Si estás depurando latencia de commit, esta es la línea base que esperas.

Tarea 2: Encontrar dónde está establecido `logbias` en todo el pool

cr0x@server:~$ sudo zfs get -r -o name,property,value,source logbias tank | grep -v default
tank                     logbias   latency     default
tank/db                  logbias   latency     local
tank/backups             logbias   throughput  local

Interpretación: Tienes intención mixta: bases de datos sesgadas a latencia; backups sesgados a throughput. Eso suele ser sano, si realmente difieren las cargas.

Tarea 3: Comprobar si tienes un vdev de log (SLOG) separado

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:11:33 with 0 errors on Sun Dec 22 03:10:01 2025
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
            nvme0n1p2               ONLINE       0     0     0
            nvme1n1p2               ONLINE       0     0     0

Interpretación: Tienes un SLOG en espejo. Esta es una postura sólida para producción en cargas intensas en sync: rendimiento más disponibilidad.

Tarea 4: Observar IO y latencia a nivel de pool

cr0x@server:~$ sudo zpool iostat -v tank 1
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                         3.21T  8.54T    210    460  18.4M  62.1M
  raidz2-0                    3.21T  8.54T    210    460  18.4M  62.1M
    sda                           -      -     35     78  3.1M  10.5M
    sdb                           -      -     37     80  3.3M  10.2M
    sdc                           -      -     34     76  3.0M  10.4M
    sdd                           -      -     35     77  3.1M  10.6M
logs                              -      -      -      -
  mirror-1                        -      -      0    920    0B  12.4M
    nvme0n1p2                     -      -      0    470    0B   6.2M
    nvme1n1p2                     -      -      0    450    0B   6.1M

Interpretación: Muchas escrituras van al vdev de log: fuerte indicio de actividad intensiva en sync. Si las aplicaciones se quejan de latencia, ahora sabes dónde mirar a continuación: latencia del dispositivo de log y comportamiento de flush.

Tarea 5: Extraer estadísticas extendidas de latencia (donde esté soportado)

cr0x@server:~$ sudo zpool iostat -v -l tank 2
                              capacity     operations     bandwidth    total_wait     disk_wait
pool                        alloc   free   read  write   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  ----- -----   ----- -----
tank                         3.21T  8.54T    190    510  16.9M  64.8M   3ms  18ms     2ms  15ms
  raidz2-0                    3.21T  8.54T    190    240  16.9M  52.1M   2ms  22ms     2ms  19ms
logs                              -      -      0   1080    0B  12.7M    -   2ms       -   1ms
  mirror-1                        -      -      0   1080    0B  12.7M    -   2ms       -   1ms

Interpretación: Las escrituras en el vdev de log son de baja latencia (bien). Las escrituras del pool son más lentas (22ms). Si la latencia sync es buena pero el rendimiento es malo, el pool puede ser el límite; si la latencia sync es mala, el log podría ser la puerta. Números así te ayudan a separar ambos.

Tarea 6: Comprobar alineación de recordsize / volblocksize del dataset (a menudo el impuesto oculto)

cr0x@server:~$ sudo zfs get -o name,property,value recordsize tank/db
NAME     PROPERTY    VALUE
tank/db  recordsize  16K

cr0x@server:~$ sudo zfs get -o name,property,value volblocksize tank/vm-001
NAME         PROPERTY     VALUE
tank/vm-001  volblocksize 8K

Interpretación: Las bases de datos suelen comportarse mejor con registros más pequeños (por ejemplo, 8K–16K) dependiendo del tamaño de página y patrón de acceso. Las VMs frecuentemente usan 8K volblocks por defecto en zvols. La desalineación puede amplificar la E/S y empeorar las ráfagas sync sin importar lo que diga logbias.

Tarea 7: Verificar si la carga fuerza sync en la capa ZFS

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

Interpretación: standard es normalmente lo que quieres: respetar las peticiones de la aplicación. Si alguien puso sync=always “por seguridad”, espera más tráfico ZIL. Si alguien puso sync=disabled “por rendimiento”, espera benchmarks más rápidos y reportes de incidentes más creativos.

Tarea 8: Cambiar `logbias` para un dataset específico (alcance seguro)

cr0x@server:~$ sudo zfs set logbias=throughput tank/backups
cr0x@server:~$ sudo zfs get -o name,property,value,source logbias tank/backups
NAME         PROPERTY  VALUE       SOURCE
tank/backups logbias   throughput  local

Interpretación: Este es un cambio de bajo riesgo si el dataset aloja escrituras secuenciales grandes y puedes tolerar mayor latencia por escritura. No hagas esto en el dataset que contiene tus logs de transacción a menos que disfrutes llamadas de emergencia.

Tarea 9: Benchmark de latencia de escritura sync de forma realista

Usa fio si está disponible. Este ejemplo emite escrituras aleatorias de 4K con comportamiento similar a sync mediante fdatasync=1.

cr0x@server:~$ sudo fio --name=sync4k --directory=/tank/dbtest --rw=randwrite --bs=4k \
  --iodepth=1 --numjobs=1 --size=2G --direct=1 --fdatasync=1 --time_based --runtime=60 --group_reporting
sync4k: (groupid=0, jobs=1): err= 0: pid=22190: Tue Dec 24 10:11:09 2025
  write: IOPS=820, BW=3280KiB/s (3359kB/s)(192MiB/60001msec)
    clat (usec): min=500, max=32000, avg=1215.4, stdev=820.1
    lat (usec): min=510, max=32050, avg=1222.0, stdev=822.0

Interpretación: Esto te dice qué siente la aplicación: ~1.2ms de latencia media por finalización, con colas que llegan a 32ms. Si cambias logbias o hardware SLOG y esto no se mueve, estás afinando la capa equivocada.

Tarea 10: Comparar comportamiento con una prueba orientada a throughput

cr0x@server:~$ sudo fio --name=seq128k --directory=/tank/backuptest --rw=write --bs=128k \
  --iodepth=16 --numjobs=4 --size=8G --direct=1 --fsync=0 --time_based --runtime=60 --group_reporting
seq128k: (groupid=0, jobs=4): err= 0: pid=22310: Tue Dec 24 10:13:30 2025
  write: IOPS=2100, BW=262MiB/s (275MB/s)(15.4GiB/60001msec)

Interpretación: Esto es rendimiento asíncrono-ish. El SLOG no importará mucho aquí, y logbias por lo general tampoco a menos que tu pila esté forzando semánticas sync. Si tu “mejora de SLOG” cambió este número, algo más cambió también.

Tarea 11: Identificar si clientes NFS están forzando comportamiento síncrono

cr0x@server:~$ mount | grep nfs
10.0.0.20:/export/vmstore on /mnt/vmstore type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.42)

cr0x@server:~$ nfsstat -m | sed -n '1,6p'
/mnt/vmstore from 10.0.0.20:/export/vmstore
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys

Interpretación: Las opciones de montaje no siempre cuentan toda la historia; las semánticas NFS más los patrones de fsync de la aplicación lo hacen. Pero esto confirma que no estás montado accidentalmente en solo lectura o con rsize/wsize pequeños que hacen que todo parezca lente.

Tarea 12: Revisar estadísticas ZFS para actividad ZIL (Linux)

cr0x@server:~$ awk 'NR==1 || /zil/ {print}' /proc/spl/kstat/zfs/arcstats | head
13 1 0x01 122 4880 167920131122 293229773812
zil_commit_count                         4    189223
zil_commit_writer_count                  4    189223
zil_itx_count                            4    812333
zil_itx_indirect_count                   4    1102

Interpretación: Si las cuentas de commit suben rápidamente durante la ventana del incidente, tienes una carga sync. Correlaciona con la latencia del dispositivo de log. Si los commits son bajos pero la app está lenta, probablemente luchas con otra cosa (saturación del pool, CPU, red, comportamiento del guest).

Tarea 13: Confirmar que tus dispositivos de log no están muriendo silenciosamente

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,25p'
SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    2%
Data Units Written:                 12,345,678
Media and Data Integrity Errors:    0
Error Information Log Entries:      0

Interpretación: Los errores de medio y las entradas de log de error importan más que “porcentaje usado”. Un SLOG es golpeado por escrituras pequeñas y flushes; un dispositivo puede parecer “saludable” hasta que no lo es. Vigila contadores de error y latencia, no solo capacidad.

Tarea 14: Validar dónde vive tu cuello de botella usando `iostat`

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              30.0    75.0   3072   10432   18.5   2.1   98.0
sdb              29.0    76.0   2976   10384   19.0   2.0   97.5
sdc              28.0    74.0   2880   10240   18.9   2.0   97.1
sdd              29.0    75.0   2992   10368   19.2   2.1   98.3
nvme0n1           0.0   480.0      0    6144    1.1   0.2    9.5
nvme1n1           0.0   470.0      0    6016    1.0   0.2    9.2

Interpretación: Los HDDs están al ~98% de utilización. Incluso si tu SLOG es rápido, el pool está saturado, lo que eventualmente se traducirá en comportamiento sync por presión de TXG y en la capacidad de respuesta total del servicio. Si tu “arreglo” fue solo logbias, no sobrevivirá a esta realidad.

Listas de verificación / plan paso a paso

Lista: elegir `logbias` por dataset

Clasifica la carga: ¿Está dominada por escrituras sync pequeñas (commits de BD, operaciones con metadatos), o por escrituras sync grandes y secuenciales (ingest masivo marcado como sync)?
Define la métrica de éxito: latencia p95/p99 para commits, o MB/s para escrituras masivas. Si no puedes nombrarla, no puedes ajustarla.
Verifica si tienes un SLOG real: de nivel empresarial, con PLP, baja latencia; preferiblemente en espejo para disponibilidad.
Configura logbias=latency para datasets sensibles a la latencia: bases de datos, discos VM con muchas operaciones de metadatos, NFS para cargas interactivas.
Configura logbias=throughput para datasets masivos: backups, ingestión de medios, staging de archivos grandes—especialmente cuando las semánticas sync son inevitables.
Benchmark antes y después: usa un benchmark de tipo sync para cargas sync, no una prueba de streaming que ignore fsync.

Plan paso a paso: despliegue seguro en producción

Escoge un dataset con identidad de carga clara y un propietario responsable (alguien que confirme éxito o dolor).
Captura métricas base (latencia sync, IOPS, latencia en cola, utilización del pool, latencia SLOG si existe).
Cambia solo una variable: ajusta logbias (no cambies recordsize, compresión y hardware en la misma ventana).
Observa durante el pico, no solo en la ventana de mantenimiento. Los problemas sync suelen aparecer bajo contención.
Revierte rápido si las latencias en cola empeoran. Ten listo el comando de rollback.
Documenta la razón (qué carga, qué métrica mejoró, qué métrica empeoró). Esto evita la “amnesia de tuning” seis meses después.

Guardarraíles operacionales

Nunca uses sync=disabled como solución de rendimiento en cargas que reclaman requisitos de durabilidad. Si debes, trátalo como una decisión de riesgo deliberada con aprobación.
Espeja los dispositivos SLOG para disponibilidad si tu plataforma y tolerancia al riesgo lo demandan. Perder un dispositivo de log puede convertirse en downtime.
Separa cargas masivas de sensibles a la latencia al menos a nivel de dataset, idealmente a nivel de pool si la contención es severa.

Errores comunes, síntomas, soluciones

Error 1: Suponer que `logbias=throughput` es “más rápido” en general

Síntomas: promedios bien, pero latencias p95/p99 empeoran; bases de datos timeout; VMs “se traban” bajo carga.

Por qué sucede: desplazaste trabajo sync desde un log rápido a un pool ocupado, aumentando la contención y la latencia en cola.

Solución: establece logbias=latency en datasets sensibles a la latencia; mantén throughput solo para datasets masivos. Verifica con benchmarks sync y métricas de cola.

Error 2: Comprar un “SSD rápido” para SLOG sin PLP

Síntomas: problemas intermitentes del pool tras eventos de energía; errores misteriosos de E/S; ZFS se niega a importar correctamente o se queja de la reproducción del log.

Por qué sucede: el dispositivo miente (o es ambiguo) sobre la durabilidad de flush. Los reconocimientos sync se vuelven poco fiables.

Solución: usa dispositivos empresariales con protección ante pérdida de energía; espeja el vdev de log; monitorea logs de error y latencia de los dispositivos.

Error 3: Olvidar que SLOG no ayuda a escrituras asíncronas

Síntomas: añades SLOG y no ves cambio en pruebas de escritura en streaming grandes; la dirección pregunta por qué “gastaste dinero”.

Por qué sucede: tu carga es mayormente asíncrona; el SLOG no está en la ruta caliente.

Solución: mide lo correcto (latencia sync) y valida que la aplicación/protocolo realmente emite escrituras síncronas.

Error 4: Establecer propiedades globales y llamarlo “estandarización”

Síntomas: un equipo está contento, otro está en llamas; gráficos de almacenamiento “parecen” bien pero fallan los SLOs de producto.

Por qué sucede: cargas mixtas requieren políticas mixtas. ZFS te da control por dataset por una razón.

Solución: define clases de carga y aplica propiedades en consecuencia: BD vs backup vs VM vs directorios home.

Error 5: Ignorar la saturación del pool porque “el SLOG es rápido”

Síntomas: latencia sync buena inicialmente, luego degrada con el tiempo; tormentas periódicas durante scrub/resilver; “pausas aleatorias”.

Por qué sucede: los commits TXG aún tienen que aterrizar. Un pool saturado eventualmente se convierte en el problema de todos.

Solución: añade vdevs, rediseña el layout, reduce fragmentación, separa cargas o pasa a medios más rápidos. logbias no puede fabricar IOPS.

Preguntas frecuentes

1) ¿`logbias=throughput` desactiva el ZIL?

No. El ZIL sigue existiendo y ZFS sigue proporcionando semánticas síncronas. logbias influye cómo ZFS prefiere manejar ciertos patrones de escritura sync, especialmente los grandes, pero no elimina las garantías de corrección.

2) Si tengo un SLOG, ¿debería siempre usar `logbias=latency`?

Para cargas sync sensibles a la latencia, sí, suele ser la opción por defecto correcta. Para datasets masivos con escrituras sync grandes, logbias=throughput puede reducir la presión sobre el log y mejorar el rendimiento agregado. La respuesta correcta es “por dataset, por carga, medido”.

3) ¿Añadir un SLOG más rápido mejorará el throughput de mi base de datos?

PUEDE mejorar la tasa de transacciones si la base de datos está limitada por la latencia de fsync() y actualmente estás atascado en escrituras estables lentas. Pero no arreglará malos planes de consulta, RAM insuficiente o un pool saturado. Mide la latencia de commit antes de comprar hardware.

4) ¿Cuál es la diferencia entre ZIL y SLOG en una frase?

ZIL es el mecanismo de intent log que siempre existe; SLOG es un dispositivo separado que opcionalmente provees para que las escrituras ZIL aterricen en un lugar más rápido (y idealmente más seguro) que el pool principal.

5) ¿Es seguro funcionar sin SLOG?

Sí, en el sentido de que la corrección aún se mantiene: los registros ZIL se escribirán en el pool principal. El rendimiento puede sufrir para cargas sync intensivas porque los dispositivos del pool deben manejar la ruta de reconocimiento síncrono.

6) ¿Debería espejar mi SLOG?

Si el servicio importa y el comportamiento de la plataforma hace que la pérdida de un dispositivo de log sea disruptiva, el espejo es la elección sensata. El rendimiento raramente es la razón para espejar; la disponibilidad sí. En producción, la disponibilidad suele ganar.

7) ¿Puede `logbias` arreglar las “pausas aleatorias” de NFS?

A veces. Si las pausas se deben a la latencia del reconocimiento de escrituras síncronas y tu dispositivo de log es el cuello de botella (o falta), ajustar logbias y/o añadir un SLOG adecuado puede ayudar. Si las pausas son por saturación del pool, problemas de red o comportamiento del cliente, no lo hará.

8) ¿Debería usar `sync=disabled` en lugar de tocar `logbias`?

Sólo si estás eligiendo explícitamente arriesgar pérdida de datos en fallo o crash, y los propietarios de la aplicación acuerdan que la durabilidad es opcional. Para la mayoría de sistemas en producción, sync=disabled no es una opción de ajuste; es una decisión de política con consecuencias.

9) ¿Cómo sé si mi aplicación hace escrituras síncronas?

Mira contadores crecientes de commits ZIL, fuerte actividad de escritura en el vdev de log, y benchmarks que cambian drásticamente cuando fuerzas fdatasync/fsync. También revisa ajustes de la aplicación (modos de durabilidad de la BD) y semánticas del protocolo (escrituras estables NFS, barreras de virtualización).

10) Si mi SLOG es rápido, ¿por qué sigue ocupado mi pool?

Porque SLOG solo ayuda a reconocer rápidamente las escrituras síncronas. Los datos aún deben escribirse a su ubicación final durante el commit TXG. Si el pool está subdimensionado, altamente fragmentado o comparte cargas mixtas, puede seguir siendo el cuello de botella a largo plazo.

Conclusión

logbias no es un ajuste de “aumentar rendimiento”. Es una declaración de prioridades. Cuando configuras logbias=latency, estás diciendo: “Me importa cuán rápido reconoces las escrituras sync, y he construido el sistema—especialmente el SLOG—para que eso sea seguro y rápido.” Cuando configuras logbias=throughput, estás diciendo: “Me importa mover datos eficientemente, y estoy dispuesto a cambiar algo de tiempo de respuesta por escritura para evitar convertir la ruta de log en un segundo trabajo.”

Los sistemas que funcionan bien en producción no eligen una sola ideología. Eligen por carga, miden las métricas correctas (incluida la latencia en cola) y mantienen lo aburrido—PLP, espejado, monitorización—como no negociable. Si haces eso, logbias deja de ser una propiedad misteriosa y se convierte en lo que siempre debió ser: una elección deliberada.