Fundamentos de ZFS: Lo que realmente obtienes en la práctica (y cuándo ganan ext4/XFS)

diciembre 16, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 15

¿Te fue útil?

ZFS tiene una reputación: o bien es el sistema de archivos que salva tu carrera, o bien es el que silenciosamente se come tu RAM mientras tu base de datos llora. Ambas historias pueden ser ciertas. ZFS no es un “sistema de archivos” en el sentido estrecho; es un sistema de almacenamiento que trata discos, redundancia, caché e integridad de datos como un único problema de diseño. Por eso puede parecer mágico cuando encaja —y terco cuando no lo hace.

Esta es la visión operativa: lo que ZFS realmente te aporta en hardware real con modos de fallo reales, cómo interrogarlo con comandos que usarás a las 2 a.m., y los casos honestos donde ext4 o XFS son simplemente la herramienta adecuada. Si buscas religión, estás en la sala equivocada. Si buscas mantener los datos correctos y la latencia aburrida, sigue leyendo.

Tabla de contenidos

1) Qué es realmente ZFS (y por qué se comporta distinto)
2) Lo que realmente obtienes en la práctica
3) Cuándo ganan ext4/XFS (y por qué eso no es herejía)
4) Datos interesantes y contexto histórico
5) Tareas prácticas: comandos que realmente ejecutarás
6) Guía de diagnóstico rápido (encuentra el cuello de botella rápido)
7) Tres micro-historias del mundo corporativo
8) Errores comunes: síntomas y correcciones
9) Listas de verificación / plan paso a paso
10) Preguntas frecuentes
Conclusión

1) Qué es realmente ZFS (y por qué se comporta distinto)

Con ext4 o XFS, normalmente tienes un dispositivo de bloques (quizá un volumen RAID, quizá LVM) y un sistema de archivos encima. ZFS invierte la pila: controla el “RAID”, la gestión de volúmenes y el sistema de archivos, así que puede aplicar integridad de extremo a extremo. Por eso ZFS habla más de pools, vdevs y datasets que de “particiones”.

Modelo central en una frase

Un pool de ZFS (zpool) está compuesto por uno o más vdevs (dispositivos virtuales). Un vdev puede ser un espejo, un grupo RAIDZ, un disco único (por favor, no lo hagas), o un dispositivo de propósito especial. ZFS stripea datos a través de vdevs, no a través de discos dentro de un vdev. Esa distinción importa cuando amplías capacidad o rendimiento: añadir vdevs aumenta el rendimiento; cambiar el tipo de un vdev… no es realmente algo que se haga.

Copy-on-write es la característica detrás de las características

ZFS usa copy-on-write (CoW). Cuando modificas un bloque, escribe un bloque nuevo en otro lugar y luego actualiza los punteros de metadatos para referenciarlo. Esto hace que los snapshots sean baratos (son solo punteros antiguos) y reduce mucho la probabilidad de escrituras parciales que produzcan inconsistencia. Pero también significa que la fragmentación se comporta de forma diferente, y la semántica de escrituras síncronas es una variable de rendimiento de primera clase.

Checksums de extremo a extremo: la parte que no notas hasta que ocurre

Cada bloque tiene una suma de verificación almacenada en sus metadatos padre. Las lecturas verifican checksums; las reparaciones ocurren automáticamente si existe redundancia. No es “paranoia por bitrot”. Es higiene básica en un mundo donde discos, controladores, firmware y cables ocasionalmente mienten.

Chiste #1: ZFS es como un detector de humo: la mayoría de las veces lo notas cuando está chillando, y entonces estás muy contento de que estuviera instalado.

2) Lo que realmente obtienes en la práctica

2.1 Integridad de datos que puedes operacionalizar

La promesa honesta: ZFS detecta corrupción silenciosa que otras pilas pueden servir a tu aplicación como “datos válidos”. Lo hace con checksums en cada bloque y auto-reparación cuando existe redundancia (mirror/RAIDZ). En la práctica, operacionalizas esto mediante scrubs, que recorren el pool y verifican todo.

Qué cambia en tus operaciones diarias:

Puedes programar un scrub y tratar los errores de checksum como una señal accionable en lugar de una historia fantasmal.
Puedes demostrar que una copia de seguridad es consistente a nivel de almacenamiento, no solo que “terminó”.
Puedes reemplazar discos inestables de forma proactiva porque ZFS te dirá que está reparando, no solo fallando.

2.2 Snapshots lo suficientemente rápidos como para ser aburridos

Los snapshots de ZFS son casi instantáneos porque son marcadores de metadatos. En la práctica, esto cambia tu postura operativa: puedes hacer snapshot antes de cambios riesgosos, tomar snapshots frecuentemente para recuperación ante ransomware y mantener retenciones cortas sin sudar por picos de I/O.

La trampa es sutil: los snapshots son baratos de crear, no gratuitos de mantener. Si mantienes miles y luego haces muchas sobreescrituras aleatorias, tus metadatos y el perfil de fragmentación cambian. ZFS seguirá funcionando; tu SLO de latencia quizá no.

2.3 Compresión que normalmente ayuda más de lo que perjudica

La compresión moderna de ZFS (comúnmente lz4) es una de esas raras características que es tanto eficiente como útil. A menudo obtienes mayor rendimiento efectivo porque mueves menos bytes desde el disco. Para muchas cargas, es un almuerzo gratis—excepto que no es gratis; se “paga” en CPU, que quizá ya tengas escasa.

En la práctica: habilita compression=lz4 en la mayoría de datasets por defecto salvo que tengas una razón medida para no hacerlo (p. ej., medios ya comprimidos, appliances con CPU limitado).

2.4 Controles a nivel de dataset: cuotas, reservas y almacenamiento multi-tenant sensato

Los datasets de ZFS te dan propiedades por árbol: compresión, recordsize, atime, cuotas, reservas, horarios de snapshots, puntos de montaje. Aquí es donde ZFS se siente como una plataforma de almacenamiento en lugar de “un sistema de archivos”. En sistemas corporativos, esto suele ser la diferencia entre “caos en servidores NFS compartidos” y “servicio de almacenamiento predecible”.

2.5 Replicación predecible con send/receive

zfs send/zfs receive son un regalo práctico. Replican snapshots como streams, y los incrementales pueden ser eficientes. Cuando está bien implementado, no es solo backup: es una vía de reconstrucción, una estrategia de migración y un mecanismo de DR que puedes probar sin heroísmos.

2.6 De dónde vienen las sorpresas de rendimiento

ZFS puede ser extremadamente rápido, pero es sensible a los patrones de carga y a la configuración. La sorpresa más común en producción son las escrituras síncronas: si tu carga usa mucho fsync() (bases de datos, NFS, imágenes de VM), ZFS lo respetará. Sin un SLOG adecuado (y protección ante pérdida de energía adecuada), eso puede convertirse en picos de latencia que parecen “ZFS es lento”. No es lento; es honesto.

Chiste #2: ZFS no pierde tus datos—simplemente te obliga a enfrentar tus supuestos, lo cual es en cierto modo peor.

3) Cuándo ganan ext4/XFS (y por qué eso no es herejía)

3.1 Cuando la simplicidad es tu SLO

ext4 es el Toyota Corolla de los sistemas de archivos Linux: no es emocionante, pero arranca cada mañana. Si tu pila de almacenamiento ya tiene redundancia y garantías de integridad (buen controlador RAID con caché + BBU, SAN empresarial con checksums, almacenamiento de bloque en la nube con garantías de integridad), ext4 puede ser la opción correcta porque tiene menos piezas móviles y menos perillas para ajustar mal.

XFS es igualmente “aburrido en el buen sentido”, especialmente para ficheros grandes, I/O paralelo y ciertas cargas con metadatos pesados donde sus grupos de asignación escalan bien.

3.2 Cuando no puedes permitirte los efectos secundarios de CoW

Copy-on-write cambia el patrón de escritura. Para algunas cargas—especialmente las que reescriben bloques en sitio esperando localidad estable—CoW puede crear fragmentación y amplificación de lectura con el tiempo. Puedes mitigar, puedes ajustar, puedes diseñar alrededor. Pero si quieres “escribir bytes en sitio y mantener localidad”, XFS/ext4 pueden ofrecer un comportamiento a largo plazo más predecible.

3.3 Cuando necesitas la mínima sobrecarga

Los checksums, metadatos y funciones de ZFS cuestan algo. A menudo recuperas ese coste (compresión, menos corrupciones, snapshots más fáciles). Pero para sistemas extremadamente lean—appliances embebidos, VMs mínimas, o entornos donde la RAM es preciosa—ext4 puede ganar simplemente porque la memoria y la huella de CPU son pequeñas y fáciles de razonar.

3.4 Cuando tu equipo operativo no está preparado para ZFS

Esto no es un ataque; es realidad. ZFS es operativo-amigable una vez que lo conoces, pero requiere entender layout de vdev, ashift, scrubs, gestión de snapshots y el ARC. Si no tienes gente que asuma esos detalles, ext4/XFS reducen la superficie para errores sutiles.

3.5 Cuando necesitas patrones de crecimiento online que ZFS no ofrece

La expansión en ZFS es por vdev. A menudo puedes crecer un mirror reemplazando discos por otros mayores y dejar que resilver lo haga, o añadir nuevos vdevs para expandir el pool. Pero no puedes, trivialmente, “convertir RAIDZ1 a RAIDZ2” después de creado, y reequilibrar datos entre vdevs no es como un reshape tradicional de RAID. Si tu realidad de compras exige reshapes frecuentes y torpes, ext4/XFS sobre LVM/MDRAID puede encajar mejor.

4) Datos interesantes y contexto histórico (corto, concreto)

ZFS fue diseñado en Sun Microsystems a mediados de los 2000 como parte de Solaris para reemplazar la separación “gestor de volúmenes + sistema de archivos” y reducir el riesgo de corrupción.
Su reclamación de “sistema de archivos de 128 bits” es principalmente una forma de decir “no nos vamos a quedar sin espacio pronto”, no una promesa de que conectarás discos del tamaño de Júpiter.
Los checksums de extremo a extremo de ZFS fueron una reacción directa a la corrupción silenciosa en pilas de almacenamiento reales—no por rayos cósmicos teóricos, sino por fallos ordinarios de hardware y firmware.
Los snapshots CoW se volvieron una herramienta práctica de operaciones en ZFS años antes de que “snapshotting” fuese corriente en plataformas de VM y contenedores.
ZFS popularizó la idea de que la compresión puede ser una característica de rendimiento, no solo un truco de capacidad—porque reducir I/O puede ser más rápido que mover bytes crudos.
OpenZFS evolucionó como una implementación abierta multiplataforma; en Linux se convirtió en el estándar de facto para uso de ZFS pese a restricciones de licencia que lo mantienen fuera del árbol del kernel.
RAIDZ no es “RAID5/6 con marca”. Los detalles de implementación (ancho de stripe variable, punteros de bloque) hacen que su comportamiento sea distinto—especialmente bajo escrituras parciales.
Los scrubs de ZFS no son lo mismo que las “consistency checks” de RAID. Verifican checksums de extremo a extremo y pueden reparar con redundancia.
El ARC (Adaptive Replacement Cache) es más que una caché de páginas; es una caché gestionada por ZFS con políticas que pueden ajustarse y observarse.

5) Tareas prácticas: comandos que realmente ejecutarás

Todos los ejemplos asumen Linux con OpenZFS instalado. Sustituye nombres de pool/dataset según corresponda. Tras cada comando, te diré qué significa la salida operativamente, no académicamente.

Tarea 1: Inventario de pools y salud básica

cr0x@server:~$ sudo zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  7.25T  3.10T  4.15T        -         -    12%    42%  1.00x  ONLINE  -

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Interpretación: FRAG es una pista, no un veredicto; pero si sube y el rendimiento empeora, lo correlacionarás con la carga. status -x es tu comprobación rápida de “¿hay algo ardiendo?”.

Tarea 2: Obtener la historia detallada durante un problema

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 04:12:55 with 0 errors on Sun Dec 22 03:10:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       ONLINE       0     0     0

errors: No known data errors

Interpretación: Los contadores READ/WRITE/CKSUM te dicen si estás ante un disco moribundo, un cable/controlador inestable o corrupción en disco. “Scrub repaired” distinto de cero no es caos automático, pero es un ticket.

Tarea 3: Ver datasets y dónde se fue el espacio

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint
NAME              USED  AVAIL  REFER  MOUNTPOINT
tank             3.10T  3.92T   192K  /tank
tank/home         420G  3.92T   410G  /home
tank/vm           1.90T  3.92T  1.20T /tank/vm
tank/backups      780G  3.92T   120G  /tank/backups

Interpretación: USED incluye snapshots y descendientes. REFER es “datos vivos en este dataset”. Si USED es enorme y REFER moderado, los snapshots son el probable culpable.

Tarea 4: Encontrar rápidamente el bloat por snapshots

cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer,creation -s used | tail -n 5
tank/vm@auto-2025-12-24-0100    120G  1.20T  Wed Dec 24 01:00 2025
tank/vm@auto-2025-12-23-0100    118G  1.19T  Tue Dec 23 01:00 2025
tank/vm@auto-2025-12-22-0100    111G  1.18T  Mon Dec 22 01:00 2025
tank/vm@auto-2025-12-21-0100    109G  1.18T  Sun Dec 21 01:00 2025
tank/vm@auto-2025-12-20-0100    103G  1.17T  Sat Dec 20 01:00 2025

Interpretación: Ese used es “bloques únicos retenidos por el snapshot”. Si crece diariamente, tu tasa de churn es alta (imágenes VM, bases de datos). Planea la retención en consecuencia.

Tarea 5: Comprobar propiedades clave que afectan el rendimiento

cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,compression,atime,sync,logbias tank/vm
NAME     PROPERTY     VALUE
tank/vm  atime        off
tank/vm  compression  lz4
tank/vm  logbias      latency
tank/vm  recordsize   128K
tank/vm  sync         standard

Interpretación: recordsize debería coincidir con tu tamaño dominante de I/O para archivos (bases de datos suelen preferir 16K/8K, imágenes de VM a menudo 16K/64K según). sync y logbias deciden cómo ZFS trata cargas síncronas.

Tarea 6: Habilitar compresión de forma segura en un dataset

cr0x@server:~$ sudo zfs set compression=lz4 tank/home
cr0x@server:~$ sudo zfs get -o name,property,value compression tank/home
NAME       PROPERTY     VALUE
tank/home  compression  lz4

Interpretación: Esto afecta a los bloques escritos de nuevo. No reescribirá datos antiguos salvo que los copies/reescribas. Operativamente, es bueno: puedes habilitarlo sin una migración grande.

Tarea 7: Medir si la compresión realmente ayuda

cr0x@server:~$ sudo zfs get -o name,property,value compressratio,logicalused,used tank/home
NAME       PROPERTY     VALUE
tank/home  compressratio 1.42x
tank/home  logicalused   580G
tank/home  used          420G

Interpretación: Si compressratio ronda 1.00x en un dataset lleno de datos ya comprimidos, estás gastando CPU para nada. Si está en 1.3x+ en datasets de propósito general, suele ser una ganancia neta.

Tarea 8: Ejecutar y monitorizar un scrub

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 24 02:10:11 2025
        1.25T scanned at 1.10G/s, 410G issued at 360M/s, 3.10T total
        0B repaired, 13.2% done, 0:02:41 to go

Interpretación: “scanned” vs “issued” te dice cuánto se está leyendo realmente vs traversal de metadatos. Si los scrubs tardan una eternidad, puedes estar limitado por IOPS o lidiando con discos lentos/SMR.

Tarea 9: Reemplazar un disco fallado en un mirror (el caso común)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       FAULTED     12     0     3  too many errors

cr0x@server:~$ sudo zpool replace tank ata-SAMSUNG_SSD_2 /dev/disk/by-id/ata-SAMSUNG_SSD_NEW
cr0x@server:~$ sudo zpool status tank
  scan: resilver in progress since Wed Dec 24 03:01:10 2025
        210G scanned at 2.5G/s, 88G issued at 1.0G/s, 3.10T total
        88G resilvered, 2.8% done, 0:49:12 to go

Interpretación: Reemplazar usando /dev/disk/by-id evita la ruleta de nombres de dispositivo después de reinicios. Monitoriza la velocidad de resilver; si va lento, tu pool está ocupado o un miembro está enfermo.

Tarea 10: Confirmar ashift (alineación de tamaño de sector) antes de diseñar un pool

cr0x@server:~$ sudo zdb -C tank | grep -E "ashift|vdev_tree" -n | head
35:            ashift: 12
36:            asize: 7998634579968

Interpretación: ashift=12 significa sectores de 4K. Equivocarse con ashift es un impuesto permanente. Si terminas con ashift=9 en dispositivos modernos 4K/8K, puedes pagarlo siempre en amplificación de escritura.

Tarea 11: Observar el comportamiento del ARC (¿la RAM ayuda o falta?)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep "size|c_max|hit|miss" | head
hits                            1802345678
misses                           234567890
size                            17179869184
c_max                           25769803776

Interpretación: Una alta tasa de aciertos suele significar que las lecturas se sirven desde RAM. Si los misses suben durante el acceso al working set, estás limitado por RAM o tu patrón de acceso es demasiado grande/aleatorio para cachear eficazmente.

Tarea 12: Vigilar I/O y latencia del pool en tiempo real

cr0x@server:~$ sudo zpool iostat -v tank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        3.10T  4.15T    820   1600   210M   380M
  mirror-0  3.10T  4.15T    410    800   105M   190M
    sda         -      -    205    400  52.5M  95.0M
    sdb         -      -    205    400  52.5M  95.0M

Interpretación: Si un solo disco hace trabajo desproporcionado en un mirror, sospecha errores, peculiaridades de firmware o un dispositivo silenciosamente más lento. Si las operaciones son altas pero el ancho de banda bajo, estás limitado por IOPS (aleatorio). Si el ancho de banda es alto pero las ops moderadas, estás en streaming.

Tarea 13: Crear un dataset para una base de datos y poner valores sensatos

cr0x@server:~$ sudo zfs create tank/pg
cr0x@server:~$ sudo zfs set atime=off compression=lz4 recordsize=16K tank/pg
cr0x@server:~$ sudo zfs get -o name,property,value atime,compression,recordsize tank/pg
NAME     PROPERTY     VALUE
tank/pg  atime        off
tank/pg  compression  lz4
tank/pg  recordsize   16K

Interpretación: Esto no es “la única afinación para bases de datos”, pero es un inicio razonable: recordsize más pequeño para páginas DB, sin churn por atime, compresión activada.

Tarea 14: Snapshot y rollback seguro (cuando vas a hacer algo arriesgado)

cr0x@server:~$ sudo zfs snapshot tank/home@pre-upgrade
cr0x@server:~$ sudo zfs list -t snapshot tank/home
NAME                     USED  AVAIL  REFER  MOUNTPOINT
tank/home@pre-upgrade       0      -   410G  -

cr0x@server:~$ sudo zfs rollback tank/home@pre-upgrade

Interpretación: El snapshot es instantáneo. El rollback es rápido pero destructivo respecto a cambios posteriores al snapshot. En la práctica: snapshot, cambia, valida y luego conserva o destruye el snapshot según resultados.

Tarea 15: Replicar con send/receive (incremental)

cr0x@server:~$ sudo zfs snapshot tank/home@daily-1
cr0x@server:~$ sudo zfs snapshot tank/home@daily-2

cr0x@server:~$ sudo zfs send -i tank/home@daily-1 tank/home@daily-2 | sudo zfs receive -u backup/home
cr0x@server:~$ sudo zfs list -t snapshot backup/home | tail -n 2
backup/home@daily-1          0      -   410G  -
backup/home@daily-2          0      -   412G  -

Interpretación: Los streams incrementales significan que mueves solo cambios. El -u lo mantiene desmontado hasta que estés listo. Operativamente: puedes probar restauraciones sin perturbar puntos de montaje de producción.

6) Guía de diagnóstico rápido (encuentra el cuello de botella rápido)

Esta es la secuencia de “no aletees”. El objetivo es decidir si tu problema es hardware, diseño del pool, ruta de escrituras síncronas, memoria/caché o tu carga.

Paso 1: ¿El pool está sano o estás midiendo un sistema degradado?

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Si no está sano: deja la afinación de rendimiento. Reemplaza el dispositivo fallido, resuelve errores de cableado/controlador y deja que el resilver termine. El rendimiento durante un resilver no es la línea base; es modo emergencia.

Paso 2: ¿El pool está sin espacio o muy fragmentado?

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag,health
NAME  SIZE  ALLOC  FREE  CAP  FRAG  HEALTH
tank  7.25T  6.70T  550G  92%   61%  ONLINE

Interpretación: Pools por encima de ~80–85% de capacidad suelen sufrir. Esto no es fallo moral; es realidad del asignador. Si CAP es alto y las escrituras son lentas, liberar espacio es lo primero a arreglar.

Paso 3: ¿Estás limitado por escrituras síncronas (latencia de fsync)?

cr0x@server:~$ sudo zpool iostat -v tank 1

Interpretación: Busca ops de escritura altas con bajo ancho de banda y alta latencia en el sistema. Si tu app hace escrituras síncronas y no tienes un SLOG adecuado, ZFS esperará a almacenamiento estable. En pools HDD eso puede ser brutal.

Paso 4: ¿El ARC ayuda o falta RAM?

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep "hits|misses|size|c_max" | head

Interpretación: Si tu working set encaja y la tasa de aciertos es buena, las lecturas deberían ser rápidas. Si dominan los misses y tu carga es lectora, quizá necesites más RAM—o aceptar que tu patrón no es cacheable.

Paso 5: ¿Es un único vdev el limitador?

cr0x@server:~$ sudo zpool iostat -v tank 1

Interpretación: ZFS stripea entre vdevs, así que el rendimiento a menudo escala con el número de vdevs. Un RAIDZ único es una unidad de rendimiento. Si construiste “un RAIDZ2 gigante” y esperabas que se comporte como “muchos discos en IOPS”, aquí llega la realidad.

Paso 6: ¿Snapshots y churn están impulsando la amplificación de escritura?

cr0x@server:~$ sudo zfs list -t snapshot -o name,used -s used | tail

Interpretación: Espacio único grande en snapshots más una carga de reescritura intensa significa que el pool está constantemente asignando bloques nuevos. Eso puede parecer “colapso del rendimiento de escritura aleatoria” cuando el verdadero problema es la política de retención vs tasa de churn.

7) Tres micro-historias del mundo corporativo (plausibles, técnicamente exactas)

Micro-historia A: Un incidente causado por una suposición equivocada (ZFS no es caché de controlador RAID)

Una compañía migró un clúster PostgreSQL desde un SAN hacia un par de servidores de almacenamiento local. El SAN antiguo tenía caché de escritura con batería; la base de datos disfrutaba de fsync() de baja latencia y no se preocupaba por ello. Los nuevos servidores se montaron con HDDs en RAIDZ2 y “no necesitábamos extras porque ZFS es inteligente”.

El fin de semana de migración fue bien hasta el lunes cuando volvió el tráfico de clientes y la latencia de commit pasó de “aceptable” a “la app hace timeouts”. El monitor mostraba CPU mayormente inacta, discos no saturados en ancho de banda, y aún así la base de datos se atascaba. Caso clásico: el sistema estaba limitado por escrituras síncronas. Cada commit de transacción quería almacenamiento estable, y el almacenamiento estable en un pool RAIDZ HDD sin dispositivo de log dedicado significa esperar la latencia rotacional y la contabilidad de paridad.

La suposición errónea fue sutil: “ZFS tiene un ZIL, así que es como tener caché de escritura”. El ZIL es un mecanismo para corrección, no un acelerador mágico. Sin un SLOG diseñado para escrituras síncronas de baja latencia (y con protección ante pérdida de energía), ZFS simplemente hace lo seguro, pero despacio.

La solución no fue heroica. Añadieron NVMe empresariales en espejo como SLOG, validaron que los dispositivos tenían protección real ante pérdida de energía y revertieron un ajuste mal aconsejado: alguien había puesto sync=disabled durante pruebas y asumió que “estaba bien” porque nada se cayó. Tras el cambio, la base de datos volvió a latencia de commit predecible, y el postmortem tuvo una moraleja simple: “La corrección es un requisito de rendimiento”.

Micro-historia B: Una optimización que salió mal (recordsize e imágenes VM)

Otro entorno ejecutaba un clúster de virtualización privado con docenas de imágenes VM muy activas en ZFS. Un ingeniero leyó una guía de tuning y decidió “bloques más grandes = más rápido”, y puso recordsize=1M en el dataset de VM. El benchmark en un sistema quieto se veía genial para lecturas secuenciales. Todos celebraron y siguieron.

Dos meses después, las quejas de latencia aparecieron como malas hierbas. No constantes, sino picos: una VM “se congelaba” brevemente bajo carga de escritura aleatoria. El pool no estaba lleno, no había discos fallando, ARC parecía sano. El problema era el patrón de escritura: las imágenes VM hacen muchas escrituras pequeñas aleatorias. Con un recordsize muy grande, pequeñas sobreescrituras pueden provocar comportamiento read-modify-write y aumentar la amplificación de escritura. Añade snapshots (porque se retenían más de la cuenta), y CoW implicó aún más asignaciones nuevas.

Revirtieron el dataset a un recordsize más razonable (comúnmente 16K o 64K según el hipervisor y el patrón del invitado), recortaron la retención de snapshots y los picos desaparecieron en gran medida. La lección no fue “nunca afinar”. Fue “nunca afinar en una sola dimensión”. CoW + recordsize + retención de snapshots es un problema de tres cuerpos, y la producción siempre encuentra la órbita inestable.

La acción del postmortem que realmente importó: cualquier “optimización” de rendimiento requería una prueba representativa de la carga (mezcla de escritura aleatoria, churn de snapshots y concurrencia) y un plan de rollback. Nadie quedó prohibido de ajustar; simplemente dejaron de hacerlo como ritual nocturno.

Micro-historia C: Una práctica aburrida pero correcta que salvó el día (scrubs + by-id + repuestos)

La interrupción más cara que no tuve fue evitada por un recordatorio en el calendario. Un equipo ejecutaba mirrors ZFS para un servicio de archivos crítico. Nada exótico: buenos discos, carga moderada, crecimiento estable. La práctica era aburrida: scrubs mensuales, alertas en errores de checksum y reemplazo de discos por IDs persistentes en lugar de nombres /dev/sdX.

Un mes, un scrub reportó un pequeño pero no nulo número de bytes reparados en un miembro del mirror. No había reportes de usuarios, ni alarmas SMART, nada obvio. La alerta abrió un ticket porque la regla era simple: las reparaciones de checksum significan que algo mintió. Revisaron logs, vieron resets intermitentes de enlace en una bahía concreta, volvieron a asentar el disco, reemplazaron un cable sospechoso y cambiaron el disco en horario laboral.

Dos semanas después, otro disco en el mismo mirror empezó a lanzar errores de lectura severos. Si la corrupción silenciosa anterior no se hubiera encontrado y tratado, habrían estado a un mal día de perder bloques que no pudieron reconstruir. En cambio, fue un reemplazo rutinario sin drama.

Nada de lo que salvó fue glamuroso. Nadie “heroizó” una recuperación a las 3 a.m. El sistema siguió siendo aburrido porque hicieron las cosas aburridas: scrubs, alertas significativas e higiene de hardware. En producción, lo aburrido es una característica.

8) Errores comunes (síntomas específicos y correcciones)

Error 1: Construir un gran vdev RAIDZ y esperar alta IOPS

Síntoma: Gran throughput secuencial, latencia de I/O aleatorio terrible bajo carga; VMs o bases de datos se sienten “atascadas”.

Por qué: Un vdev RAIDZ se comporta como una sola unidad de IOPS en muchos patrones; el trabajo de paridad y el conteo de discos no multiplican mágicamente las IOPS aleatorias.

Corrección: Usa mirrors para cargas con alta IOPS, o múltiples vdevs RAIDZ (más vdevs = más paralelismo). Si rediseñar no es posible, aisla cargas, reduce la presión síncrona y sé realista respecto a IOPS.

Error 2: Poner `sync=disabled` para “arreglar rendimiento”

Síntoma: El rendimiento mejora, pero después de un corte de energía o crash, la base de datos o el sistema de archivos VM está corrupto o faltan transacciones recientes.

Por qué: Le dijiste a ZFS que mintiera a las aplicaciones sobre durabilidad.

Corrección: Poner sync=standard (por defecto) y abordar el problema real: añade un SLOG en espejo con protección ante pérdida de energía si necesitas escrituras síncronas de baja latencia.

Error 3: Ashift incorrecto en la creación del pool

Síntoma: Rendimiento de escritura inexplicablemente malo; escrituras pequeñas causan escrituras grandes en dispositivo; vida útil de SSD cae más rápido de lo esperado.

Por qué: Desajuste de alineación de sectores causa amplificación de escritura. No puedes cambiar ashift después.

Corrección: Recrea el pool correctamente (a menudo ashift=12 o 13 según dispositivos). Si no puedes, pagas el impuesto.

Error 4: Dejar el pool al límite (demasiado lleno)

Síntoma: Todo se vuelve más lento con el tiempo; scrubs/resilvers tardan más; operaciones de metadatos se sienten lentas.

Por qué: El asignador tiene menos opciones; la fragmentación y la amplificación de escritura aumentan.

Corrección: Mantén margen de espacio libre. Añade capacidad (nuevos vdevs), reduce retención o mueve datos fríos fuera. Trata 80% como umbral de planificación, no como ley rígida.

Error 5: Acaparamiento de snapshots sin conciencia del churn

Síntoma: “Borramos datos pero el espacio no volvió”, además de deriva en rendimiento.

Por qué: Los snapshots conservan bloques antiguos referenciados. Churn intenso + retención larga = presión de espacio y fragmentación.

Corrección: Audita snapshots, implementa políticas de retención por dataset y alinea la frecuencia de snapshots con objetivos de recuperación, no con sensaciones.

Error 6: Mezclar dispositivos lentos y rápidos de forma que amplifiques lo más lento

Síntoma: Picos de latencia aleatorios; un disco muestra alta utilización mientras otros están inactivos.

Por qué: Los mirrors son tan rápidos como el miembro más lento para muchas operaciones; vdevs heterogéneos complican la predictibilidad.

Corrección: Mantén miembros de vdev emparejados. Si debes mezclar, hazlo intencionalmente (p. ej., vdev especial para metadatos) y monitoriza cuidadosamente.

Error 7: Tratar discos SMR como HDDs normales

Síntoma: Resilvers y scrubs tardan una eternidad; rendimiento de escritura colapsa bajo carga sostenida.

Por qué: El comportamiento de escritura SMR puede ser devastador para los patrones de reconstrucción de ZFS.

Corrección: Evita SMR para pools ZFS que necesiten reconstrucciones predecibles. Si estás atrapado, reduce carga durante resilver y reevalúa el diseño de redundancia.

9) Listas de verificación / plan paso a paso

Lista de diseño (antes de crear el pool)

Clasifica la carga: mayormente secuencial (backup/media), mayormente aleatoria (VMs/DB), mixta (home dirs), síncrona (bases de datos/NFS).
Elige tipo de vdev según IOPS: mirrors para IOPS; RAIDZ para capacidad/throughput con menos expectativas de IOPS.
Decide ashift desde el principio: asume sectores 4K+; verifica y crea el pool en consecuencia. Trátalo como irreversible.
Planifica margen: planificación de capacidad para mantenerte fuera de la zona del 90%.
Decide política de snapshots: frecuencia y retención por dataset, no una sola política para todo.
Decide estrategia síncrona: si tienes cargas síncronas, planifica SLOG (en espejo, PLP) o acepta latencia.

Plan de despliegue (primera semana en producción)

Crea datasets por carga (VMs, DBs, home, backups) en lugar de un monolito.
Pon propiedades base: compression=lz4, atime=off donde corresponda, recordsize por carga.
Implementa monitorización: salud de zpool status, resultados de scrub, errores de checksum, capacidad y tendencias de duración de scrubs.
Programa scrubs en ventanas de baja carga, pero no los trates como opcionales.
Prueba rollback de snapshots en datos no críticos para que el equipo tenga memoria muscular.
Prueba restauración con zfs send/receive, no solo la creación de backups.

Lista de cambios (antes de “optimizar”)

Declara la hipótesis: qué métrica mejora y por qué.
Mide la línea base con concurrencia y patrones de I/O representativos de producción.
Cambia una perilla a la vez: recordsize, sync, vdev especial, etc.
Define criterios de rollback y ensaya los pasos de reversión.
Observa al menos un ciclo comercial si la carga es cíclica.

10) Preguntas frecuentes

Q1: ¿Es ZFS “más seguro” que ext4/XFS?

A: ZFS ofrece checksums de extremo a extremo y auto-reparación con redundancia. ext4/XFS generalmente confían en la capa de dispositivo subyacente para la integridad. Si te importa la detección y reparación de corrupción silenciosa, ZFS tiene una ventaja real.

Q2: ¿Necesito RAM ECC para ZFS?

A: ECC es altamente recomendado para cualquier sistema de almacenamiento serio, ZFS o no. ZFS detecta bien la corrupción a nivel de disco, pero no puede arreglar datos dañados en RAM antes de ser checksummados. Muchos corren sin ECC; menos duermen tranquilos haciéndolo.

Q3: ¿ZFS siempre necesita “mucha RAM”?

A: ZFS usará RAM para ARC, y más RAM suele mejorar el rendimiento de lectura. Pero no es un requisito estricto para la corrección. La verdadera pregunta es si tu carga se beneficia de caché. Si el working set no cabe, la RAM ayuda menos y ext4/XFS pueden sentirse similares.

Q4: ¿Debo habilitar deduplicación?

A: Generalmente no en producción de propósito general. Dedup puede ser caro en RAM y crear acantilados de rendimiento si está infra-provisionado. Si tienes un caso medido y estrecho (muchas imágenes VM idénticas) y lo has probado, quizá. Si no, usa compresión primero.

Q5: ¿Cuál es la diferencia entre ZIL y SLOG?

A: El ZIL es el intent log en disco usado para manejar de forma segura escrituras síncronas. Un SLOG es un dispositivo separado donde ZFS puede colocar ese log para acelerar escrituras síncronas. Sin SLOG, el ZIL vive en los dispositivos principales del pool.

Q6: ¿Cuándo es aceptable `sync=disabled`?

A: Casi nunca para algo que te importaría perder. Puede ser aceptable para datos temporales desechables o ciertos pipelines de ingestión donde la app ya tolera pérdida. Si no estás absolutamente seguro, trátalo como “inseguro”.

Q7: ¿Los snapshots reemplazan backups?

A: No. Los snapshots ayudan a recuperarte rápidamente de errores lógicos en el mismo sistema. Las copias de seguridad protegen contra pérdida del pool, pérdida del sitio y errores administrativos que borran tanto datos como snapshots. Usa snapshots como una capa, no como sustituto.

Q8: ¿Por qué mi pool se vuelve más lento a medida que se llena?

A: Al reducirse el espacio libre, ZFS tiene menos regiones contiguas para asignar, lo que puede aumentar fragmentación y trabajo de metadatos. Además, CoW implica encontrar continuamente nuevos sitios para escribir bloques. Mantén margen y planifica expansiones de capacidad.

Q9: ¿ext4/XFS también tienen checksums?

A: Tienen checksums para algunas estructuras de metadatos (journals, etc.) según características. ZFS checksums datos y metadatos de extremo a extremo y valida en lectura. Es un nivel de cobertura distinto.

Q10: Si ZFS es tan bueno, ¿por qué no lo usa todo el mundo?

A: Porque los trade-offs son reales: huella de memoria, superficie de ajuste, comportamiento CoW y la necesidad de experiencia operativa. Además, algunos entornos ya obtienen los beneficios en otro nivel (características del SAN, garantías del almacenamiento en la nube), haciendo que ext4/XFS sean la opción más simple y segura.

Conclusión

ZFS es lo que eliges cuando quieres que la capa de almacenamiento se comporte como un adulto: verifica lo que lee, puede reparar lo que encuentra, hace los snapshots rutinarios y te da primitivas limpias para replicación. En la práctica, cambia los tipos de fallos que ves: menos corrupciones misteriosas, más límites de rendimiento honestos y más momentos de “podemos retroceder”.

ext4 y XFS todavía ganan muchos días. Ganan cuando necesitas simplicidad, cuando tu historia de integridad se maneja en otro lugar, cuando tu equipo quiere menos perillas y cuando el comportamiento de escritura in-place predecible importa más que snapshots y checksums de extremo a extremo. La mejor elección no es la que tiene más funciones; es la que hace que tu sistema de producción sea aburrido en las formas específicas que tu negocio necesita.