ZFS vs btrfs: Dónde btrfs resulta agradable y dónde duele

Mi postura: qué despliego dónde

Si necesitas comportamiento predecible bajo carga, semántica de recuperación poco emocionante, y puedes tolerar la visión de que “ZFS es
una pila de almacenamiento, no sólo un sistema de archivos”: elige ZFS.

Si necesitas integración estrecha con Linux, snapshots de la raíz fáciles, iteración rápida, y estás dispuesto a conocer los modos de fallo de btrfs:
btrfs es realmente agradable—especialmente para estaciones de trabajo, máquinas de compilación y algunos servicios de nodo único con buenas copias de seguridad.

Si estás pensando “usaré btrfs RAID5/6 porque está integrado y es conveniente”, no lo hagas. Usa mdraid por debajo, o usa ZFS, o
usa RAID por hardware si debes (y aceptas los tradeoffs). btrfs RAID5/6 ha mejorado con los años pero aún tiene suficientes matices
como para tratarlo como medicina experimental: solo con consentimiento informado y una segunda opinión.

Hechos interesantes y contexto histórico (lo que explica los bordes afilados actuales)

• ZFS comenzó en Sun Microsystems como un gestor de volúmenes integrado + sistema de archivos, diseñado para acabar con la corrupción silenciosa y los dolores del “RAID write hole”.
• btrfs fue creado en Oracle como un sistema de archivos de nueva generación para Linux con pooling, snapshots y checksumming, buscando metas similares pero dentro del ecosistema Linux.
• ZFS on Linux se convirtió en OpenZFS, un proyecto multiplataforma que estandarizó características y comportamiento en illumos, Linux y más.
• btrfs se integró en el kernel de Linux y evolucionó en público, lo cual es excelente para disponibilidad pero también significa que heredas versiones del kernel + herramientas como parte de la realidad operativa.
• Copy-on-write es el ingrediente común, pero los transaction groups de ZFS y los B-trees y estrategias de asignación de btrfs conducen a distintos patrones de fragmentación y latencia.
• ZFS tiene reputación sólida por las semánticas de scrub/resilver, incluyendo la “reparación por redundancia” que es directa cuando los mirrors/RAIDZ están configurados correctamente.
• btrfs RAID1 no es “RAID1 de dos discos” en el sentido clásico; es “dos copias a través de dispositivos” a nivel de chunk, y esa diferencia importa para capacidad y expectativas de fallo.
• La licencia de ZFS (CDDL) lo mantuvo fuera del kernel de Linux, lo que impacta decisiones de empaquetado e integración en empresas.
• btrfs send/receive maduró junto a flujos de trabajo basados en snapshots (piensa: despliegues del SO casi inmutables y rollback rápidos), por eso algunas distros lo prefieren para sistemas raíz.

Modelos mentales que evitan malas decisiones

1) ZFS quiere controlar la historia del dispositivo de bloques

ZFS espera ver discos (o particiones) y manejar redundancia, decisiones de caché e integridad de extremo a extremo. Puedes superponerlo
sobre RAID por hardware, pero estás eligiendo cegar a ZFS respecto al comportamiento de fallo del disco individual y te complicas la vida
cuando algo se vuelve raro. Las mejores características de ZFS aparecen cuando ZFS tiene visibilidad real.

2) btrfs quiere ser “el sistema de archivos de Linux que hace mucho”

btrfs está en el kernel, se integra bien con las herramientas de systemd, los instaladores de distritos y los flujos de snapshots de sistemas raíz. También
es más feliz siendo tratado como un sistema de archivos primero. La gestión de volúmenes es poderosa, pero no siempre es el lugar donde quieres tomar riesgos.

3) Ambos son CoW; ambos pueden castigar la “sobreescritura aleatoria a escala”

Las bases de datos, imágenes de VM y cargas con muchos logs pueden disparar amplificación de escritura y fragmentación en cualquier sistema CoW. ZFS tiene perillas
como recordsize, logbias, vdevs especiales, y una historia madura de ARC/L2ARC. btrfs tiene opciones de compresión,
opciones de montaje y la habilidad de desactivar CoW por archivo (chattr +C). Ninguno te da un almuerzo gratis.

Una idea parafraseada de John Allspaw: la confiabilidad viene de tratar las operaciones como un problema de diseño, no como una lucha contra incendios.

Dónde btrfs resulta agradable

Snapshots del sistema raíz que no parecen un experimento

btrfs es fantástico cuando tu SO es un conjunto de subvolúmenes y los snapshots forman parte de la vida diaria. ¿Rollback después de una actualización fallida?
Fácil. ¿Crear un entorno de prueba disposable haciendo snapshot de @home o de un árbol de compilación? Fácil.

Las distros que adoptan btrfs no lo hacen por novedad. Quieren actualizaciones algo atómicas y rollbacks rápidos sin añadir un gestor de volúmenes separado. En el mundo real,
“puedo revertir rápido” es una característica de uptime.

Send/receive directo para muchos flujos de trabajo

btrfs send/receive es una primitiva de replicación práctica. Para destinos de backup, entornos de laboratorio o configuraciones de “enviar snapshots a otra caja”,
es accesible y suficientemente rápido. Puedes integrarlo en timers, mantener la retención simple y seguir con tu vida.

Redimensionado y gestión de dispositivos en línea sin repensar toda la pila

Añadir un disco, quitar un disco, convertir perfiles (por ejemplo, single → RAID1), redimensionar filesystems en línea—btrfs te da herramientas para
esto sin obligarte a una capa LVM separada. Es conveniente cuando gestionas flotas de nodos pequeños que cambian de forma.

Compresión que suele “valer la pena”

La compresión transparente (especialmente zstd) es una superpotencia silenciosa. Puede reducir I/O de escritura y estirar la resistencia de SSDs. En cargas mixtas,
a menudo es una ganancia neta. En medios ya comprimidos, es solo CPU desperdiciada—mide, no supongas.

Subvolúmenes útiles operativamente

Los subvolúmenes se comportan como filesystems separados para snapshots y cuotas, pero comparten el mismo pool. Eso facilita aislar políticas de retención: mantener snapshots agresivos para @,
menos agresivos para @var, y tratar directorios de alta rotación por separado.

Broma #1: los subvolúmenes de btrfs te hacen sentir organizado—hasta que te das cuenta de que tu política de retención de snapshots es una exhibición de museo.

Dónde btrfs duele (y por qué)

Agotamiento de espacio de metadata: “no queda espacio” mientras df dice que estás bien

btrfs asigna espacio en chunks para datos y metadata. Puedes tener mucho espacio de datos libre y aun así estar paralizado porque
los chunks de metadata están llenos o mal distribuidos entre dispositivos. Los síntomas son brutales: escrituras fallan, snapshots fallan, a veces los borrados fallan.
Se siente como una broma pesada.

La solución suele ser una combinación de liberar snapshots, ejecutar un balance selectivo y a veces convertir perfiles de metadata.
La prevención es monitorizar btrfs filesystem df y mantener margen.

Balance es una herramienta de mantenimiento, no un botón mágico para desfragmentar la vida

Un balance reescribe chunks. Eso puede ser caro y arruinar el rendimiento si lo ejecutas en el momento equivocado o con los filtros equivocados.
A veces es necesario para arreglar la distribución de espacio o aplicar cambios de perfil. Trata el balance como un instrumento quirúrgico, no como una escoba.

Las semánticas RAID pueden sorprender a quienes aprendieron RAID en 2005

RAID1 de btrfs es replicación basada en chunks, no necesariamente un espejo simétrico de “mitad de capacidad” en todas las condiciones de fallo. RAID10 tiene
sus propias realidades de layout. Y RAID5/6 es el área donde debes tener extrema cautela: ahí aparecen casos límite y caminos de recuperación complicados y donde “funcionó en pruebas” puede convertirse en “por qué scrub encuentra errores no corregibles”.

Fragmentación y amplificación CoW: las imágenes de VM y bases de datos suelen sufrir

CoW es genial hasta que sobrescribes archivos grandes en el lugar una y otra vez (imágenes QCOW2, archivos de bases de datos, buzones de correo). btrfs puede manejarlo,
pero a menudo necesitas optar por desactivar CoW para rutas específicas, escoger las opciones de montaje correctas y evitar snapshotear ciegamente archivos de alta rotación.

Las herramientas de recuperación están mejorando, pero aún pueden sentirse como espeleología

Cuando btrfs está sano, es agradable. Cuando no lo está, pasarás tiempo con advertencias de btrfs check, modos de rescate y decisiones muy cuidadosas sobre si intentar reparación offline.
Las herramientas existen, pero la curva de confianza del operador es más pronunciada.

Broma #2: “no queda espacio en el dispositivo” en btrfs a veces significa “hay espacio, pero está en metadata, y la metadata es emocional”.

Dónde ZFS gana, sin ambages

Modelo de integridad predecible: checksums, scrub, auto-reparación (cuando hay redundancia)

La fama de ZFS es el checksumming de extremo a extremo con reparación automática desde la redundancia. Scrub es de primera clase. Cuando un disco miente o un cable falla,
ZFS tiene más probabilidad de decirte claramente qué pasó y qué hizo al respecto.

Claridad operativa: pools, vdevs y reglas que puedes enseñar

ZFS te obliga a pensar en vdevs. Eso suena molesto hasta que estás de guardia. El modelo es consistente: los mirrors son mirrors, RAIDZ es RAIDZ,
y no puedes “más o menos” diseñar un layout. Esa rigidez previene muchos desastres creativos.

ARC/L2ARC y SLOG son maduros y ampliamente entendidos

El caché de ZFS no es magia, pero es coherente. El dimensionamiento de ARC, los vdevs especiales para metadata/bloques pequeños y los dispositivos de intent log separados
tienen mucho folclore operativo detrás—lo que es otra forma de decir que mucha gente ya cometió esos errores por ti.

La replicación es aburrida en el buen sentido

zfs send/receive está probado en batalla. Los streams incrementales son fiables. Los casos límite son conocidos. Si construyes una estrategia de snapshots y
una política de retención, tiende a seguir funcionando hasta que cambies algo grande (como recordsize o la estrategia de cifrado) sin pensarlo.

El tradeoff: ZFS es más pesado y más “tipo pila de almacenamiento”

ZFS tiene apetito de memoria, una historia de empaquetado distinta en Linux y preferencia fuerte por gestionar los discos él mismo. A cambio, obtienes
un sistema que se comporta de manera predecible si lo tratas correctamente. ZFS no recompensa la improvisación.

Ajuste de rendimiento: las palancas que realmente importan

El encaje de la carga vence a las microoptimizaciónes

Empieza por el patrón de acceso. ¿Escrituras secuenciales grandes? ¿Escrituras aleatorias sincrónicas? ¿Millones de archivos pequeños? ¿Imágenes de VM?
Tu elección de sistema de archivos y ajustes debe coincidir con la realidad. Si no conoces la realidad, mídela primero. Adivinar es la forma de terminar “optimizando” la capa equivocada.

Perillas de btrfs que cambian resultados

• Compresión: compress=zstd suele ser una ganancia; prueba la sobrecarga CPU. Para cargas sensibles a latencia, considera compress=zstd:1.
• NOCOW para archivos de sobreescritura caliente: establece chattr +C en directorios para imágenes de VM/bases de datos (y asegúrate de que ningún snapshot dependa de la semántica CoW allí).
• Autodefrag: ayuda en algunas cargas de escritura aleatoria pequeña; puede perjudicar en I/O secuencial grande. Úsalo con moderación y valida.
• Caché de espacio/árbol de espacio libre: los kernels modernos manejan esto mejor; versiones de herramientas desajustadas pueden crear rarezas tras upgrades.

Perillas de ZFS que cambian resultados

• recordsize: ajusta al workload. Archivos grandes quieren recordsize mayor; bases de datos suelen querer bloques más pequeños.
• compresión: lz4 es la “sana por defecto”; a veces zstd vale la pena si está soportado y hay CPU disponible.
• comportamiento sync: no desactives sync writes para “ir rápido” a menos que estés cómodo perdiendo datos que creías seguros.
• special vdev: puede transformar cargas ricas en metadata, pero también es un compromiso de diseño: perderlo puede costar el pool.

Una nota sobre SSDs, TRIM y amplificación de escritura

Ambas pilas necesitan un comportamiento sensato de discard/TRIM. Ser demasiado agresivo puede dañar la latencia; no tenerlo puede degradar el rendimiento a largo plazo.
Para ZFS, el trim periódico y la calidad del firmware del dispositivo importan. Para btrfs, la opción de montaje discard frente a fstrim periódico es una elección de ajuste que debes medir en tu hardware.

Tareas prácticas con comandos, salidas y decisiones (12+)

Estos son movimientos reales de operador: qué ejecutas, qué esperas ver y qué decisión tomas después. Mezclaré ZFS y btrfs para que puedas comparar la “forma” de las operaciones.

Task 1: btrfs health check at a glance

cr0x@server:~$ sudo btrfs filesystem show
Label: 'rootfs'  uuid: 6d3b3fe1-0a9e-4e8d-9bf0-73a55c6a8f2f
	Total devices 2 FS bytes used 412.31GiB
	devid    1 size 931.51GiB used 520.00GiB path /dev/nvme0n1p2
	devid    2 size 931.51GiB used 520.00GiB path /dev/nvme1n1p2

Qué significa: dispositivos, tamaños y “used” a nivel de asignación de chunks, no es lo mismo que df.

Decisión: si “used” está cerca del tamaño del dispositivo, estás saturado de chunks; planifica balance/liberación de espacio antes de hacer cambios.

Task 2: btrfs data vs metadata usage (the classic trap detector)

cr0x@server:~$ sudo btrfs filesystem df /
Data, RAID1: total=480.00GiB, used=402.10GiB
Metadata, RAID1: total=16.00GiB, used=15.72GiB
System, RAID1: total=32.00MiB, used=16.00KiB

Qué significa: la metadata está casi llena. Así es como obtienes “ENOSPC” con espacio de datos libre.

Decisión: para el amor de Dios, detén la creación continua de snapshots, borra snapshots antiguos y luego ejecuta un balance dirigido para metadata (no uno completo).

Task 3: targeted btrfs balance for metadata pressure

cr0x@server:~$ sudo btrfs balance start -musage=50 /
Done, had to relocate 12 out of 32 chunks

Qué significa: relocó chunks de metadata que estaban usados en menos del 50%, consolidando y liberando espacio de chunk.

Decisión: vuelve a comprobar btrfs filesystem df. Si sigue justo, repite con un umbral mayor o aborda el número de snapshots y la rotación de archivos pequeños.

Task 4: btrfs scrub status and what “corrected” implies

cr0x@server:~$ sudo btrfs scrub status /
UUID:             6d3b3fe1-0a9e-4e8d-9bf0-73a55c6a8f2f
Scrub started:    Sat Dec 21 02:11:03 2025
Status:           finished
Duration:         0:32:44
Total to scrub:   410.23GiB
Rate:             213.45MiB/s
Error summary:    read=0, csum=2, verify=0, corrected=2, uncorrectable=0

Qué significa: los checksums no coincidieron dos veces y la redundancia lo reparó.

Decisión: trata los errores corregidos como una señal de hardware. Revisa SMART, cableado/backplane y logs del kernel; no te limites a celebrar y seguir.

Task 5: btrfs device stats (persistent counters)

cr0x@server:~$ sudo btrfs device stats /
[/dev/nvme0n1p2].write_io_errs   0
[/dev/nvme0n1p2].read_io_errs    0
[/dev/nvme0n1p2].flush_io_errs   0
[/dev/nvme0n1p2].corruption_errs 2
[/dev/nvme0n1p2].generation_errs 0
[/dev/nvme1n1p2].write_io_errs   0
[/dev/nvme1n1p2].read_io_errs    0
[/dev/nvme1n1p2].flush_io_errs   0
[/dev/nvme1n1p2].corruption_errs 0
[/dev/nvme1n1p2].generation_errs 0

Qué significa: ocurrieron errores de corrupción en un camino de dispositivo.

Decisión: ejecuta pruebas SMART extendidas e inspecciona dmesg por resets NVMe; planifica un reemplazo proactivo si se repite.

Task 6: Disable CoW for a directory holding VM images (btrfs)

cr0x@server:~$ sudo mkdir -p /var/lib/libvirt/images
cr0x@server:~$ sudo chattr +C /var/lib/libvirt/images
cr0x@server:~$ lsattr -d /var/lib/libvirt/images
---------------C------ /var/lib/libvirt/images

Qué significa: los archivos nuevos creados en ese directorio serán NOCOW, reduciendo fragmentación para imágenes con muchas sobreescrituras.

Decisión: haz esto antes de crear los archivos grandes; los archivos existentes no se reescribirán mágicamente. Además:
no hagas snapshots de esas imágenes esperando eficiencia basada en CoW.

Task 7: btrfs list subvolumes and decide snapshot retention

cr0x@server:~$ sudo btrfs subvolume list -t /
ID 256 gen 19234 top level 5 path @
ID 257 gen 19233 top level 5 path @home
ID 890 gen 19110 top level 256 path .snapshots/2025-12-01
ID 891 gen 19140 top level 256 path .snapshots/2025-12-02
ID 892 gen 19170 top level 256 path .snapshots/2025-12-03

Qué significa: los snapshots se acumulan rápido; cada uno fija extents y puede aumentar la presión de metadata.

Decisión: establece una retención que puedas defender (diario por 7–14 días, semanal por unas semanas), y hazla cumplir.

Task 8: ZFS pool health and error triage

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear'.
  scan: scrub repaired 0B in 0 days 00:41:12 with 0 errors on Sat Dec 21 03:02:11 2025
config:

	NAME                         STATE     READ WRITE CKSUM
	tank                         ONLINE       0     0     0
	  mirror-0                   ONLINE       0     0     0
	    ata-SAMSUNG_SSD1         ONLINE       0     0     1
	    ata-SAMSUNG_SSD2         ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
/tank/vmstore/qemu/win10.qcow2

Qué significa: ZFS detectó un error de checksum asociado a una ruta de archivo. Eso es oro para la respuesta a incidentes.

Decisión: restaura/repara el archivo afectado desde backup; ejecuta SMART en el disco con incrementos de CKSUM; considera reemplazarlo.

Task 9: ZFS dataset properties that commonly explain performance

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

Qué significa: estos ajustes suelen marcar la diferencia entre “bien” y “por qué mis VMs tartamudean”.

Decisión: para imágenes de VM, considera recordsize más pequeño y posiblemente logbias=throughput según el patrón de sync; cambia sólo midiendo.

Task 10: ZFS ARC pressure check

cr0x@server:~$ sudo arcstat -f time,read,miss,arcsz,c
    time  read  miss   arcsz      c
03:12:01   842    71   19.2G   24.0G
03:12:02   901    88   19.2G   24.0G
03:12:03   877    92   19.2G   24.0G

Qué significa: tamaño ARC (~19G) vs objetivo (~24G), misses en ascenso. Si los misses son altos bajo carga estable, puedes estar corto de RAM.

Decisión: añade RAM o ajusta workload/propiedades del dataset; no añadas L2ARC a lo loco sin entender el working set.

Task 11: ZFS scrub and what to do with results

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Sat Dec 21 03:20:10 2025
	12.3G scanned at 1.02G/s, 1.4G issued at 118M/s, 480G total
	0B repaired, 0.29% done, 1:17:44 to go
config:

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    sda     ONLINE       0     0     0
	    sdb     ONLINE       0     0     0

errors: No known data errors

Qué significa: el scrub está en progreso; las líneas clave para integridad son “repaired” y “errors”.

Decisión: si ves reparaciones o errores CKSUM, correlaciona con SMART y planifica reemplazo de dispositivo; si está limpio, sube a la capa superior.

Task 12: btrfs: detect whether free space is fragmented across chunks

cr0x@server:~$ sudo btrfs filesystem usage -T /
Overall:
    Device size:                   1.82TiB
    Device allocated:              1.04TiB
    Device unallocated:          816.00GiB
    Device missing:                  0.00B
    Used:                        824.20GiB
    Free (estimated):            496.10GiB      (min: 248.05GiB)
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:               512.00MiB      (used: 0.00B)

Qué significa: “Free (estimated)” vs “min” muestra incertidumbre debido a la asignación de chunks; “min” es el número conservador.

Decisión: dimensiona tu margen de seguridad usando “min”, no la estimación optimista, especialmente antes de grandes operaciones de snapshot.

Task 13: ZFS: identify which dataset is consuming space and snapshots

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,usedbysnapshots -S used
NAME                USED  AVAIL  REFER  USEDBYSNAPSHOTS
tank                3.21T  5.07T   192K            0B
tank/vmstore        1.84T  5.07T  1.02T          820G
tank/backups        1.12T  5.07T  1.10T          18G
tank/home           256G  5.07T   241G          15G

Qué significa: los snapshots están fijando 820G en tank/vmstore.

Decisión: ajusta la retención de snapshots o excluye datasets de VM de alta rotación de cronogramas agresivos de snapshots; considera la frecuencia de replicación por separado.

Task 14: btrfs: replace a failing device (conceptual “do it before it dies” move)

cr0x@server:~$ sudo btrfs replace start /dev/nvme1n1p2 /dev/nvme2n1p2 /
Started on Sat Dec 21 03:40:11 2025, estimated time: 2:10:00
cr0x@server:~$ sudo btrfs replace status /
Status: finished

Qué significa: btrfs copió datos al dispositivo de reemplazo en línea.

Decisión: tras la finalización, verifica que el scrub esté limpio, y luego remueve el dispositivo antiguo limpiamente si aún está presente.

Guía rápida de diagnóstico: encuentra el cuello de botella antes de “tunar” nada

Primero: decide si esto es capacidad/metadata, integridad o latencia

• Si las escrituras fallan (no queda espacio) pero df parece bien: sospecha agotamiento de chunks de metadata en btrfs o snapshots que fijan espacio.
• Si las apps ven corrupción o errores de checksum: sospecha dispositivo, controlador, cableado, firmware o comportamiento ante pérdida de energía.
• Si hay picos de latencia pero el throughput está bien: sospecha escrituras sync, fragmentación o misses de caché.

Segundo: comprueba la verdad propia de la capa de almacenamiento

Para btrfs: btrfs filesystem df, btrfs filesystem usage -T, btrfs scrub status y los logs del kernel.
Para ZFS: zpool status -v, zpool iostat -v 1 y propiedades de datasets.

Tercero: aísla si estás limitado por CPU, RAM o los dispositivos

• Alta iowait + baja utilización de disco: muchas veces encolamiento, firmware, problemas de controlador o latencia sync.
• Alta CPU en kswapd o presión de memoria: dimensionamiento del ARC de ZFS o escasez general de RAM.
• Un dispositivo saturado: asignación/balance desigual de btrfs, o un cuello de botella de diseño de ZFS vdev (un disco lento envenena la latencia de un mirror/RAIDZ).

Cuarto: solo entonces afina

Afinar sin diagnosticar es cómo accidentalmente conviertes una situación recuperable en un fin de semana. Establece la restricción, ajusta una variable y mide otra vez.

Errores comunes: síntoma → causa raíz → arreglo

1) “No queda espacio en el dispositivo” pero hay cientos de GiB libres

Síntoma: la creación de snapshots falla, las escrituras fallan, los borrados fallan de forma intermitente.

Causa raíz: chunks de metadata de btrfs llenos; espacio libre atrapado en chunks de datos o mal distribuido entre dispositivos.

Arreglo: borra snapshots, detén la churn, ejecuta btrfs balance start -musage=50 (o similar), y monitoriza btrfs filesystem df. Mantén margen.

2) “Scrub corrigió errores” es ignorado

Síntoma: errores ocasionales corregidos durante scrub; el sistema parece bien por lo demás.

Causa raíz: inestabilidad del dispositivo o del path: NVMe inestable, cableado, HBA, backplane o bugs de firmware.

Arreglo: trata los errores corregidos como advertencia temprana. Ejecuta pruebas SMART, revisa dmesg, considera reemplazo proactivo.

3) el rendimiento de btrfs cae después de un periodo con muchos snapshots

Síntoma: la latencia de escritura aleatoria aumenta, las operaciones de metadata se vuelven lentas, los tiempos de commit suben.

Causa raíz: fragmentación + extents fijadas por muchos snapshots, más la sobrecarga de metadata.

Arreglo: recorta la retención de snapshots; separa datos de alta rotación en directorios NOCOW o subvolúmenes separados que no se snapshoteen con frecuencia.

4) ZFS “optimizado” desactivando sync, y luego pérdida de datos tras un evento de energía

Síntoma: la carga es rápida; tras un fallo o pérdida de energía, la base de datos o la imagen de VM se corrompe.

Causa raíz: sync=disabled (o la app confiando en fsync) rompió las suposiciones de durabilidad.

Arreglo: establece sync=standard (o always cuando proceda), usa un SLOG apropiado si la latencia sync es el problema.

5) suponer que “btrfs RAID1 significa puedo perder cualquier disco en cualquier momento”

Síntoma: la pérdida de un dispositivo causa datos faltantes o fallo de montaje en ciertas situaciones de perfil/layout.

Causa raíz: malentender la replicación basada en chunks y la asignación; mezclar tamaños de dispositivo o condiciones de casi lleno reduce la flexibilidad.

Arreglo: valida escenarios de fallo, mantén espacio libre, usa dispositivos homogéneos cuando sea posible, y prueba los flujos de trabajo de reemplazo/retirada antes de necesitarlos.

6) pool ZFS diseñado con un único vdev RAIDZ ancho para I/O aleatorio

Síntoma: IOPS aleatorios terribles comparado con expectativas.

Causa raíz: el vdev es la unidad de IOPS; un RAIDZ grande tiene IOPS limitados en comparación con múltiples mirrors.

Arreglo: para workloads con muchas IOPS, prefiere vdevs mirror (mirrors en stripe) o más vdevs; no esperes que el ancho de RAIDZ cree IOPS.

Tres micro-historias corporativas (anonimizadas, plausibles y dolorosamente familiares)

Historia 1: El incidente causado por una suposición equivocada

Una compañía SaaS mediana migró agentes de compilación a btrfs porque los snapshots facilitaban la limpieza. Cada compilación corría en un snapshot desechable,
luego hacía rollback. Al equipo le encantó. El almacenamiento se mantenía limpio. Las compilaciones fueron más rápidas.

Entonces el clúster de compilación empezó a fallar con “no queda espacio en el dispositivo”. df -h mostraba cientos de gigabytes libres. El on-call
supuso que era un problema de overlay de contenedores y reinició un montón de agentes, lo que ayudó exactamente cero por ciento.

La suposición equivocada: “espacio libre es espacio libre”. En btrfs, la asignación de metadata puede ser tu límite real. Tenían gran número de archivos pequeños,
más retención agresiva de snapshots “por si acaso”, y los chunks de metadata en RAID1 estaban saturados.

La solución no fue heroica. Borraron snapshots antiguos, ejecutaron un balance dirigido de metadata y redujeron la frecuencia de snapshots. Además separaron caches de artefactos
de compilación en un subvolumen que no se snapshoteba. El clúster volvió a ser aburrido.

La lección: btrfs es amigable hasta que lo tratas como ext4 con superpoderes. No lo es. Vigila la metadata como un recurso de primera clase, porque lo es.

Historia 2: La optimización que salió mal

Una empresa del ámbito financiero usaba ZFS para almacenamiento de VMs. Alguien notó latencia en escrituras sync y propuso el arreglo clásico: “temporalmente” poner
sync=disabled en el dataset de las VMs. Los gráficos mejoraron inmediatamente. Se chocaron las manos. Se creó un ticket para “revisarlo después.”
El ticket vivió una larga y significativa vida en el backlog.

Unas semanas después, ocurrió un incidente de energía—nada dramático, solo un reinicio de PDU que tardó más de lo esperado. Varias VMs volvieron con archivos corruptos.
Una base de datos arrancó pero tenía inconsistencias silenciosas de datos que aparecieron como errores de aplicación, que es lo peor: parece un bug de software.

Tras el incidente, descubrieron que el almacenamiento había sido configurado para mentir. Las aplicaciones hacían lo correcto (fsync),
y la capa de almacenamiento se encogía de hombros.

El trabajo de corrección fue caro: restaurar desde backups, validar datos y reconstruir confianza. La solución de rendimiento real fue aburrida:
un dispositivo SLOG pequeño y fiable para datasets con muchas escrituras sync, y ajustar recordsize para las cargas de VM. La latencia mejoró sin apostar la durabilidad.

La lección: las “victorias” de rendimiento que cambian semánticas de durabilidad no son optimizaciones. Son apuestas. Los sistemas de producción recuerdan tus apuestas.

Historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía vinculada a la salud ejecutaba un clúster ZFS con una rutina estricta: scrubs semanales, alertas por cualquier incremento de checksum,
y una política que decía “los errores corregidos requieren un ticket.” La gente puso los ojos en blanco porque la mayoría de semanas no pasaba nada.

Un scrub reportó un pequeño número de errores corregidos en un solo disco de un vdev mirror. El sistema siguió online; los usuarios no notaron nada.
El on-call abrió el ticket requerido y programó una ventana de mantenimiento para reemplazar el disco.

Durante el reemplazo encontraron que el disco tenía atributos SMART en el límite y resets intermitentes de enlace en los logs. No estaba muerto, solo poco confiable.
Una semana después, un disco similar en otro chasis falló por completo. Como habían reemplazado el “disco advertencia” temprano,
evitaron un escenario de doble fallo que podría haber requerido una larga restauración.

Mientras tanto, sus backups y replicaciones se verificaban mensualmente con ejercicios de restauración. Cuando la dirección preguntó por qué necesitaban “todo este procedimiento extra”,
la respuesta fue simple: porque el día que lo necesites es el día que no puedes negociar por él.

La lección: scrubs, alertas y políticas disciplinadas de reemplazo son aburridas. Aburrido es el sonido del uptime.

Listas de verificación / plan paso a paso

Elegir entre ZFS y btrfs (checklist de decisión)

1. Define el dominio de fallo: nodo único, o multi-nodo con replicación? Si nodo único y alto impacto: inclínate por ZFS.
2. Define la carga: imágenes de VM, bases de datos o CI con muchos archivos pequeños? Planifica el comportamiento CoW explícitamente.
3. Decide la redundancia: mirrors/RAIDZ vs perfiles btrfs vs mdraid bajo btrfs. Evita btrfs RAID5/6 en entornos serios.
4. Define la política de snapshots: retención, frecuencia y dónde están prohibidos los snapshots (bases de datos/VMs sin plan).
5. Planifica la monitorización: resultados de scrub, errores de checksum, uso de metadata (btrfs), salud del pool (ZFS), SMART en todas partes.
6. Practica flujos de reemplazo: reemplaza un disco en un entorno de pruebas. Cronométralo. Documenta. Haz que sea aburrido.

Base operativa btrfs (semanal/mensual)

1. Scrub semanal (escalonado entre hosts).
2. Chequeo semanal: btrfs filesystem df y btrfs filesystem usage -T para presión de metadata.
3. Retención de snapshots aplicada con un tope rígido.
4. Trimestral: prueba el flujo btrfs replace en staging.

Base operativa ZFS (semanal/mensual)

1. Scrubs regulares (a menudo mensual para pools grandes, semanal para hardware más propenso a fallos).
2. Alertar por cualquier incremento CKSUM en zpool status y cualquier “permanent errors” con rutas de archivos.
3. Snapshots + replicación con ejercicios periódicos de restauración.
4. Política de capacidad: no mantengas pools al límite; guarda margen para resilver y fragmentación.

Preguntas frecuentes

1) ¿btrfs está “listo para producción”?

Para muchos usos, sí: disco único, RAID1/10, filesystems raíz, flujos de trabajo basados en snapshots y destinos de backup. Pero “listo para producción”
depende de si tu equipo entiende el comportamiento de metadata, balance y las limitaciones del perfil RAID elegido.

2) ¿ZFS siempre es más seguro que btrfs?

ZFS tiene una reputación más larga por integridad y recuperación predecible, especialmente con redundancia. Pero la seguridad también depende del hardware,
monitorización, disciplina operativa y no “optimizar” a costa de la durabilidad.

3) ¿Debo usar btrfs RAID5/6?

Si necesitas fiabilidad aburrida, evítalo. Usa ZFS RAIDZ, o usa mdraid (5/6) con un filesystem más simple, o rediseña con mirrors.
La conveniencia no es una característica durante una reconstrucción.

4) ¿Por qué btrfs muestra estimaciones de espacio libre con “min”?

Porque la asignación en chunks y los perfiles afectan cuánto espacio es realmente usable para nuevas asignaciones. El valor conservador “min” es
el que debes confiar para planificación de seguridad.

5) ¿Se puede usar ZFS como sistema raíz en Linux?

Sí, pero depende del soporte de la distro, integración con initramfs y empaquetado. Operativamente es factible, pero btrfs suele sentirse más nativo
para workflows de snapshots de raíz en Linux.

6) ¿Cuál es la forma más rápida de mejorar el rendimiento de VMs en btrfs?

Coloca las imágenes de VM en directorios NOCOW (configura antes de crear los archivos), evita snapshotearlas agresivamente y valida con métricas de latencia.
También revisa compresión y autodefrag; pueden ayudar o perjudicar según el patrón de acceso.

7) ¿Cuál es la forma más rápida de mejorar el rendimiento de VMs en ZFS?

Usa mirrors para IOPS, ajusta propiedades del dataset apropiadamente (recordsize, compresión), mantén el comportamiento sync correcto y añade un SLOG solo
si tienes latencia real de escrituras sync y un dispositivo en el que confíes.

8) ¿Sigo necesitando backups si tengo snapshots?

Sí. Los snapshots no son backups; viven en el mismo dominio de fallo. Tanto ZFS como btrfs hacen factible la replicación basada en snapshots—
úsala y verifica restauraciones.

9) ¿Cuánto espacio libre debo mantener?

Más del que quieres. Para btrfs, el margen reduce crisis de metadata y posibilita balance/relocation. Para ZFS, el margen mejora rendimiento y seguridad en resilver.
Mantenerlo “caliente” convierte tareas de mantenimiento en incidentes.

10) ¿Cuál es más fácil de operar con un equipo pequeño?

Si el equipo es Linux-first y quiere snapshots raíz y herramientas simples: btrfs puede ser más fácil. Si el equipo quiere un modelo estricto y
semánticas de recuperación predecibles: ZFS tiende a reducir sorpresas, a costa de aprender su vocabulario.

Próximos pasos (conclusión práctica)

Elige ZFS cuando quieras que la pila de almacenamiento se comporte como un adulto: señales de fallo claras, defaults de integridad fuertes y un diseño que
fuerza buena arquitectura. Elige btrfs cuando quieras flujos de snapshots nativos de Linux, subvolúmenes flexibles y estés dispuesto a monitorizar metadata
y tratar balance/scrub como cuidado rutinario.

Luego haz el trabajo poco glamuroso:

• Escribe tu política de retención de snapshots. Aplícala automáticamente.
• Programa scrubs. Alerta por errores corregidos. Trátalos como humo de hardware.
• Practica reemplazo de discos en una caja no crítica. Cronométralo. Documenta.
• Para puntos dolorosos de CoW (VMs, bases de datos), haz un plan explícito: directorios NOCOW en btrfs, ajuste de datasets y diseño de vdevs en ZFS.
• Realiza un ejercicio de restauración. Si no puedes restaurar, no tienes un backup—tienes un deseo.

El almacenamiento es donde el optimismo viene a jubilarse. Configúralo para que sea aburrido, y te pagará permitiéndote dormir.