Introducción a ZFS#

Quienes conocen mi comunidad saben que mi sitio anterior de blog desapareció porque el servidor fue migrado a ZFS.

Recuerdo que el blog antiguo no describía qué es ZFS, así que hoy analizaré con cuidado qué es ZFS y por qué elegí usarlo en mi servidor principal.

Estructura#

ZFS fue desarrollado originalmente por Sun Microsystems para Solaris como un sistema de archivos y gestor de volúmenes. Actualmente se mantiene como el proyecto OpenZFS y sigue evolucionando en plataformas como Linux.

Tradicionalmente, podemos pensar en un sistema de archivos como un bibliotecario que sabe dónde está cada libro en los estantes, pero no sabe nada sobre el contenido de los libros ni sobre la estructura de los estantes.

Si las páginas se pegan (corrupción de datos) o el estante se derrumba (falla de hardware), este bibliotecario puede quedar impotente.

Sin embargo, ZFS (Zettabyte File System) cambia completamente este modelo. Es más bien una combinación de arquitecto, bibliotecario y encuadernador: un experto todo en uno.

ZFS no solo sabe la ubicación de los datos, sino que también entiende la disposición estructural del almacenamiento físico subyacente (discos) y verifica continuamente la integridad de cada página de datos (bloques).

A diferencia de la pila de almacenamiento tradicional, donde RAID, la gestión de volúmenes y los sistemas de archivos se superponen en capas separadas, ZFS integra el controlador RAID, el gestor de volúmenes y el sistema de archivos en uno solo, proporcionando un pool de almacenamiento unificado para gestionar los datos.

Esta integración significa que el sistema operativo se comunica directamente con el pool de almacenamiento de ZFS, evitando ineficiencias y riesgos ocasionados por el aislamiento de información entre capas en pilas tradicionales.

La arquitectura de almacenamiento de ZFS puede verse como una pirámide de tres capas:

1. Discos Físicos: La capa más baja, es decir, el hardware real del servidor, como HDD (discos duros) o SSD (unidades de estado sólido).
2. vdev (Dispositivo Virtual): El bloque de construcción básico de ZFS, compuesto por uno o más discos físicos. Define cómo se organizan los datos y la redundancia. Un vdev puede ser un disco único, un grupo en espejo o un arreglo RAID-Z.
3. zpool (Pool de Almacenamiento): El contenedor de almacenamiento de más alto nivel, compuesto por uno o más vdevs. Una vez creado un zpool, su espacio total puede compartirse entre todos los sistemas de archivos (llamados datasets en ZFS) sin necesidad de particiones predefinidas.

Seguridad#

Toda la redundancia y tolerancia a fallos se implementa a nivel de vdev. El tipo de vdev elegido determina directamente el rendimiento, la capacidad utilizable y la seguridad de los datos del pool.

• Stripe/Disco Único: El vdev más simple, que puede ser un solo disco o varios discos formando un stripe sin redundancia (similar a RAID 0). Maximiza el rendimiento y la capacidad, pero no tiene tolerancia a fallos. La falla de un solo disco causa la pérdida del vdev.
• Espejo (Mirror): Similar a RAID 1. Cada disco en el vdev almacena copias idénticas de los datos. Un espejo de dos vías puede sobrevivir a la falla de un disco; mientras uno quede sano, no se pierde información. Los espejos de ZFS son más flexibles que RAID 1 tradicional, ya que permiten espejos de tres o más vías. El rendimiento de escritura equivale al de un solo disco, mientras que la lectura escala con el número de discos, siendo excelente para cargas de alto IOPS.
• RAID-Z: La alternativa innovadora de ZFS al RAID de paridad (como RAID 5 y RAID 6). RAID 5 tradicional sufre del “write hole”, donde una caída durante escritura puede desincronizar datos y paridad. ZFS lo evita con su mecanismo Copy-on-Write (CoW), que asegura operaciones atómicas escribiendo nuevas franjas en lugar de sobrescribir las antiguas. RAID-Z tiene tres niveles:
  • RAID-Z1: Similar a RAID 5, con una unidad de paridad; sobrevive a la falla de un disco.
  • RAID-Z2: Similar a RAID 6, con dos unidades de paridad; sobrevive a la falla de dos discos.
  • RAID-Z3: Triple paridad; sobrevive a la falla de tres discos, ofreciendo redundancia extremadamente alta.

Copy-on-Write (CoW)#

En los sistemas de archivos tradicionales, al modificar un archivo, se sobrescriben directamente los bloques antiguos. Si ocurre una interrupción (como corte de energía), los datos viejos pueden quedar a medio sobrescribir y los nuevos incompletos, causando corrupción.

ZFS funciona diferente. Nunca sobrescribe datos activos. En su lugar, cuando modifica un bloque:

1. Los datos nuevos se escriben en una ubicación libre del disco.
2. El puntero de metadatos padre se actualiza para referirse al nuevo bloque.
3. Esta actualización es atómica: o se completa por completo o no ocurre.

Esto garantiza que el sistema de archivos siempre esté consistente. Si se corta la energía, los datos antiguos permanecen intactos. Al reiniciar, ZFS descarta transacciones incompletas y vuelve al último estado consistente. Por ello, ZFS no necesita herramientas como fsck.

Snapshots#

Los snapshots son una de las aplicaciones más poderosas del CoW. Un snapshot es una copia de solo lectura de un sistema de archivos o volumen en un momento específico.

Crearlos no duplica datos; solo congela el árbol de metadatos. Como CoW asegura que los bloques viejos no se sobrescriben, los snapshots simplemente los referencian. Se crean al instante y ocupan espacio mínimo al inicio. Solo cuando los datos cambian, el snapshot empieza a consumir espacio, ya que los bloques antiguos deben retenerse.

El espacio ocupado por los snapshots equivale al total de bloques modificados o eliminados en el sistema activo pero que aún están referenciados por snapshots.

Nunca Confiar#

La filosofía de ZFS es “nunca confíes en el hardware”. Asume que memoria, cables, controladores o discos pueden fallar en cualquier momento, por lo que implementa protección de integridad de extremo a extremo.

De Extremo a Extremo#

El mecanismo central de protección de ZFS son las sumas de verificación. Cada bloque tiene una (por defecto Fletcher4 optimizada, o SHA-256). Al leer, ZFS recalcula y compara. Si no coinciden, detecta corrupción.

Estas sumas se almacenan en los punteros de bloques padres, formando un árbol de Merkle. Esto crea una “cadena de confianza” desde los bloques de datos hasta el “uber block” raíz. A diferencia de otros sistemas que guardan la suma junto al dato (riesgo de corrupción simultánea), ZFS las guarda aparte, dificultando ocultar errores.

Autorreparación#

Más allá de detectar errores, ZFS puede autorrepararse. Si encuentra corrupción y hay redundancia (mirror o RAID-Z), ZFS obtiene los datos correctos de la copia sana, los entrega a la aplicación y repara el bloque dañado en disco.

Para riesgos como la pudrición de bits, ZFS ofrece scrubbing. El comando zpool scrub escanea todos los bloques, verifica sumas y repara lo necesario. Es crucial ejecutar scrubbing regularmente (ej. mensual). Sin redundancia, solo puede detectar corrupción, no repararla.

Rendimiento#

ZFS integra cachés y registros avanzados para optimizar cargas de trabajo.

Lectura#

Las lecturas dependen de la Adaptive Replacement Cache (ARC) en memoria. ARC rastrea tanto datos “recientes” como “frecuentes”, equilibrando espacio para mayor tasa de aciertos. Por defecto, ZFS usa hasta el 50% de la RAM como ARC. Como la memoria acelera mucho el almacenamiento, aumentar RAM es la mejor mejora de rendimiento.

L2ARC (Nivel 2 ARC) añade caché en SSD para datos expulsados de ARC. Sin embargo, requiere RAM para índices, así que un L2ARC muy grande puede perjudicar. Regla: primero aumenta RAM; usa L2ARC solo si está al límite y las tasas de acierto siguen bajas.

Escritura#

ZFS distingue entre escrituras asincrónicas y sincrónicas:

• Asincrónicas: La mayoría (copias de archivos, etc.). Los datos van a ARC y la app recibe “listo” al instante. Después, ZFS los vacía en grupos de transacción. Muy rápidas, pero riesgo de perder datos recientes en apagones.
• Sincrónicas: Necesarias en bases de datos, NFS, etc. Deben persistir antes de confirmar. ZFS usa el ZFS Intent Log (ZIL) para registrarlas.
• SLOG (Dispositivo de Log Separado): Por defecto, ZIL vive en los discos del pool. En cargas pesadas sincrónicas, puede ser un cuello de botella. Un SLOG dedicado (SSD/NVMe/Optane) mejora mucho el rendimiento al almacenar ahí el ZIL.

Importante: SLOG solo beneficia escrituras sincrónicas. Para cargas hogareñas o de medios (asincrónicas), es inútil y un desperdicio.

Alternativas#

A pesar de su potencia, ZFS no es la única opción. Existen otros sistemas abiertos y comerciales con ventajas y desventajas.

Función	ZFS	Btrfs	LVM + ext4/XFS
Arquitectura	Unificada	Unificada	En capas
Integridad de datos	Checksums de extremo a extremo	Checksums por bloque	Ninguna
Autorreparación	Sí (con redundancia)	Sí (con redundancia)	No
Estabilidad RAID	Excelente (RAID-Z1/2/3)	Buena (mirror/RAID10); RAID5/6 inestable	Excelente (vía mdadm)
Snapshots	Eficientes	Eficientes	Ineficientes
Expansión del pool	Rígida (agregar vdevs, no discos)	Flexible	Flexible
Uso de recursos	Alto	Medio-bajo	Bajo
Integración kernel	Fuera del árbol	Nativa	Nativa

(Tabla por Gemini 2.5 Pro)

O,

Función	ZFS (OpenZFS)	Btrfs	XFS	Ext4 + LVM
Snapshots	Nativos, eficientes	Nativos, por subvolúmenes	No soportado (requiere LVM)	No soportado (requiere LVM)
Checksums	Extremo a extremo (datos y metadatos)	Datos/metadatos	Solo metadatos	Solo metadatos
RAID integrado	Sí (RAID-Z1/2/3, mirrors)	Sí (0/1/5/6/10)	No	No
Compresión	Sí (LZ4, Zstd, etc.)	Sí	No	No
Deduplicación	Sí (en tiempo real, consume memoria)	Sí (herramientas offline)	No	No
Gestión volúmenes	Integrada	Parcial	Ninguna	Vía LVM
RAM necesaria	Alta (≥8GB recomendado)	Moderada	Baja	Baja
Rendimiento	Sólido; escrituras aleatorias pequeñas lentas	Bueno; sufre por fragmentación	Excelente para IO masivo	Excelente general
Integridad datos	Muy alta	Alta	Moderada	Moderada
Madurez	Muy madura, probada en empresas	Bastante madura	Muy madura	Muy madura
Complejidad	Alta (curva aprendizaje)	Media	Baja	Media

(Tabla por ChatGPT 5)

Equivalentes comerciales cerrados incluyen:

• Storage Spaces
• Veritas VxVM
• Oracle ASM
• NetApp ONTAP
• Dell PowerScale (antes Isilon OneFS)
• Veritas InfoScale

Conclusión#

Dado que mi servidor principal tiene 96GB de RAM ECC, finalmente elegí la solución ZFS incluida en Proxmox VE (PVE).

Tras una experiencia en la que borré archivos por error y los restauré fácilmente con snapshots, ZFS se convirtió en mi favorito. Así que, si también cuentas con gran memoria, recomiendo mucho probarlo.

Como suelo escribir novelas, algunos párrafos pueden parecer divididos de forma extraña; perdón por ello. Con esto, cerramos una introducción detallada pero amigable a ZFS. ¡Les deseo felices experimentos y nos vemos en el próximo artículo 👋