Cuando aparece una nueva versión de OpenZFS muchos administradores se preguntan si merece la pena actualizar ya o esperar a que el polvo se asiente. Con OpenZFS 2.4 la duda es todavía más interesante, porque llega con cambios profundos en rendimiento, nuevas herramientas de administración y algún que otro debate en la comunidad sobre el uso de candidatos de lanzamiento en sistemas en producción.

Novedades generales de OpenZFS 2.4

OpenZFS 2.4 se presenta como una versión de carácter estable y bastante ambiciosa pensada tanto para entornos Linux como FreeBSD. En el momento de su etiquetado definitivo, el proyecto ya destacaba que el objetivo era seguir impulsando la madurez del sistema de archivos y gestor de volúmenes sin perder de vista la compatibilidad con kernels recientes y la seguridad de los datos.

En esta versión se consolidan muchas funciones que se venían cocinando desde la rama 2.3 y sus revisiones intermedias: mejoras de rendimiento en la capa de cifrado, nuevas herramientas de administración como zfs rewrite, capacidades de cuota más flexibles, y cambios internos pensados para reducir la fragmentación, optimizar la deduplicación y pulir aspectos complejos como la gestión de gang blocks o el comportamiento con discos problemáticos.

La comunidad también ha prestado especial atención a la integración con kernels modernos. En Linux se declara soporte desde 4.18 hasta las ramas LTS recientes (incluyendo el kernel 6.18 en el momento de la salida estable de 2.4), mientras que en FreeBSD se cubren versiones desde la 13.3 en adelante, incluyendo 14.0 y las ramas más nuevas que se están preparando como 15.0.

Soporte de plataformas y compatibilidad de kernel con OpenZFS 2.4

Uno de los pilares de OpenZFS 2.4 es su amplia compatibilidad de plataformas. Para muchos administradores esto es clave, porque permite ir subiendo de versión de sistema operativo sin perder las funciones que se esperan de ZFS.

En el lado de Linux, OpenZFS 2.4 indica compatibilidad con kernels que van desde la versión 4.18 hasta la serie 6.18 estable. Esto cubre desde distribuciones empresariales conservadoras hasta entornos muy actualizados que van a la última con el kernel. Entre medias entra todo el espectro habitual: LTS usadas en servidores, kernels personalizados y versiones que adoptan proyectos como CentOS Stream o equivalentes.

En FreeBSD, la nueva versión soporta desde FreeBSD 13.3 en adelante, incluyendo 14.0 y versiones posteriores que ya se vislumbran, como la futura 15.0. Este rango amplio garantiza que tanto sistemas ya en producción como despliegues de nueva generación puedan seguir tirando de OpenZFS sin necesidad de parches raros o soluciones a medida.

Detrás de esta compatibilidad hay un trabajo continuado que ya se dejaba ver en la serie OpenZFS 2.3.x, donde actualizaciones como la 2.3.4 ampliaban el soporte de kernel hasta 6.16 y consolidaban parches que habían empezado a aparecer en RC anteriores. OpenZFS 2.4 recoge ese testigo y da un paso más, alineándose con kernels recientes y mejorando la vida a quienes actualizan su stack base con relativa frecuencia.

Quotas y nuevas capacidades de gestión de espacio

Entre las novedades más prácticas para el administrador están las mejoras en el sistema de cuotas predeterminadas. OpenZFS 2.4 introduce la posibilidad de definir cuotas por defecto para usuarios, grupos y proyectos, de modo que se pueda controlar el consumo de espacio de manera más homogénea sin tener que configurar cada caso a mano.

Esta función permite, por ejemplo, establecer una cuota base para todos los usuarios que se creen en un determinado dataset, o marcar límites de proyecto que se apliquen automáticamente cuando se asignan nuevos recursos. Es una herramienta muy útil en entornos multiusuario, hosting, laboratorios y cualquier escenario en el que se quiera evitar que un despiste acabe llenando el pool entero.

El soporte de cuotas predeterminadas no sustituye a las cuotas específicas que ya existían, sino que las complementa. El administrador puede definir una política global y luego refinarla con excepciones para determinados usuarios o grupos que necesiten más (o menos) espacio. Todo ello se gestiona con las herramientas habituales de ZFS, manteniendo el mismo modelo de propiedades que ya se conoce.

IO directo, IO sin caché y comportamiento con escrituras desalineadas

En el terreno del rendimiento, OpenZFS 2.4 trae un cambio muy interesante en la gestión de entrada/salida directa. Hasta ahora, el uso de IO directo en algunas situaciones podía chocar con la alineación de las escrituras y generar rutas de código poco óptimas. La nueva versión introduce un mecanismo para que, cuando el IO directo no se puede aplicar de forma ideal, se recurra a un modo de IO sin caché ligero específicamente diseñado para este tipo de escenarios.

¿Qué significa esto en la práctica? Que las escrituras que no encajan bien con las alineaciones esperadas dejan de ser un caso patológico y pasan a gestionarse con una ruta optimizada dentro de ZFS. Se reduce la sobrecarga, se evitan algunos cuellos de botella y se consigue un comportamiento más predecible, sobre todo en entornos donde conviven aplicaciones que usan IO directo con otras que no.

Este cambio es especialmente útil en cargas de trabajo exigentes en las que se busca exprimir el rendimiento de almacenamiento sin renunciar a las garantías de integridad que ofrece ZFS. Al tener un fallback específicamente diseñado, OpenZFS se adapta mejor a la realidad de muchas aplicaciones que no siempre respetan la alineación ideal de las operaciones.

Unified allocation throttling y reducción de fragmentación en OpenZFS 2.4

Otro de los cambios profundos que llegan con OpenZFS 2.4 es la introducción de un nuevo algoritmo de unified allocation throttling. Detrás de este nombre hay un mecanismo orientado a reducir la fragmentación de los dispositivos virtuales (vdevs) y a mejorar la forma en que se reparten las escrituras cuando el sistema está bajo presión.

Hasta ahora, la asignación de bloques en situaciones de carga elevada podía terminar generando patrones de distribución que, con el tiempo, favorecían la fragmentación de los vdev. Con el algoritmo unificado se pretende harmonizar el ritmo de asignación, de forma que el pool mantenga una estructura más ordenada y se reduzcan las penalizaciones de rendimiento cuando el espacio empieza a escasear o cuando la mezcla de tamaños de bloques es muy variada.

Este tipo de cambios son menos vistosos que un nuevo comando, pero resultan muy valiosos en despliegues de largo recorrido, donde un pool va creciendo, se reequilibra, se añaden vdevs y se ejecutan operaciones de mantenimiento a lo largo de años. Al mejorar el control de la asignación, OpenZFS 2.4 contribuye a mantener un comportamiento más estable en el tiempo, incluso cuando el sistema se utiliza de forma intensa.

Mejoras de cifrado con AVX2 y AES-GCM

En el apartado de seguridad y rendimiento, OpenZFS 2.4 incluye una serie de optimizaciones en el uso de AVX2 para AES-GCM. En cristiano: se ha afinado la implementación de cifrado para aprovechar mejor las capacidades de los procesadores modernos que cuentan con estas instrucciones vectoriales avanzadas.

El resultado es un cifrado más rápido sin sacrificar las garantías criptográficas, lo que se nota especialmente en sistemas que manejan grandes volúmenes de datos encriptados o en entornos donde se realizan muchas operaciones simultáneas sobre datasets protegidos. Al reducir la sobrecarga de CPU asociada al cifrado, se pueden atender más peticiones o dedicar más recursos a otras tareas de sistema.

En la práctica, los administradores pueden seguir confiando en las funciones de cifrado nativo de ZFS para proteger datos sensibles sin que el impacto en rendimiento sea tan acusado como en generaciones anteriores. No es que el cifrado pase a ser “gratis”, pero sí se vuelve más asumible en cargas donde antes era un cuello de botella claro.

ZIL en vdevs especiales y mejoras en special_small_blocks

OpenZFS 2.4 también aporta novedades en lo relativo a los vdevs especiales, aquellos dispositivos pensados para almacenar determinados tipos de datos (como metadatos, bloques pequeños o tablas de deduplicación) en medios más rápidos, normalmente SSD o NVMe.

Por un lado, ahora es posible permitir que el ZIL (ZFS Intent Log) resida en vdevs especiales cuando estos están disponibles. Esto facilita concentrar las escrituras síncronas en dispositivos de baja latencia, mejorando el tiempo de respuesta de aplicaciones que dependen de operaciones sync intensivas, como bases de datos o sistemas de mensajería con persistencia fuerte.

Por otro lado, se amplía el comportamiento de la propiedad special_small_blocks para que las escrituras de ZVOL puedan aterrizar también en los vdev especiales, no solo ciertos bloques de archivos regulares. Además, se relaja la restricción de que el valor tenga que ser una potencia de dos, de modo que el administrador puede elegir tamaños más finos adaptados a su carga real en lugar de limitarse a opciones rígidas.

Combinadas, estas mejoras permiten diseñar arquitecturas de almacenamiento donde los datos más críticos (metadatos, bloques pequeños, ZIL, tablas de deduplicación, etc.) se sitúan en medios más rápidos, mientras que el grueso de los datos sigue en discos más económicos. Todo ello con una flexibilidad mucho mayor a la hora de definir qué se considera “pequeño” y qué no.

zfs rewrite y zfs rewrite -P: reubicar datos de forma eficiente

La serie 2.3 ya trajo una de las funciones más llamativas de los últimos tiempos: el subcomando zfs rewrite. OpenZFS 2.4 da una vuelta más de tuerca a esta herramienta incorporando la variante zfs rewrite -P, que añade nuevas posibilidades a la hora de reubicar datos dentro de un pool.

El comando zfs rewrite permite “reescribir” el contenido de un archivo o conjunto de datos sin cambiar su significado lógico, pero recolocándolo físicamente en otras zonas y con diferentes propiedades internas. Con él se puede modificar, por ejemplo, el algoritmo de compresión, el tipo de checksum, si se aplica deduplicación, el número de copias o incluso el dispositivo preferente, sin necesidad de copiar los datos a espacio de usuario y volver a escribirlos.

Esto tiene varias ventajas claras: se reduce el tráfico de I/O respecto al clásico “copiar y renombrar”, se minimiza el golpe sobre la caché y se evitan ventanas largas de tiempo en las que los datos se están moviendo a través de herramientas externas. Además, como no hay cambio lógico de contenido, no se altera el mtime ni otras propiedades visibles desde el punto de vista del usuario, lo que hace que muchas aplicaciones ni se enteren de la operación.

La opción zfs rewrite -P añade la posibilidad de conservar el tiempo de nacimiento lógico de los bloques siempre que sea posible, lo que ayuda a minimizar el tamaño de los flujos de replicación incremental. Al mantener esa información estable, los send/receive posteriores pueden identificar mejor qué ha cambiado de verdad y qué no, reduciendo la cantidad de datos que hay que mover entre sistemas.

Otra ventaja importante es que el proceso de reescritura se protege con range locks normales, de modo que se puede ejecutar en paralelo con cargas de trabajo reales sin bloquear el sistema más de la cuenta. En datasets con sync=always el beneficio es aún mayor, porque al no haber modificación lógica de datos no se fuerzan escrituras adicionales en el ZIL, evitando un coste extra en operaciones síncronas.

Nuevas opciones de administración en OpenZFS 2.4: -a|–all, scrub por rangos y prefetch BRT

OpenZFS 2.4 también pule y amplía el arsenal de herramientas de administración con varias opciones muy útiles para el día a día. Una de ellas es la incorporación de la opción -a|–all en comandos que realizan tareas de mantenimiento sobre pools, como scrub, trim o inicialización.

Con esta opción es posible lanzar una operación que afecte a todos los pools importados de una sola vez, en lugar de tener que ir recorriendo cada uno manualmente. Esto simplifica mucho la vida en servidores que gestionan múltiples pools, reduciendo errores humanos y facilitando automatizaciones más sencillas.

Además, se introduce la posibilidad de lanzar un zpool scrub acotado a rangos temporales concretos mediante las opciones -S -E. Esta funcionalidad es muy apreciada cuando se quiere revisar solo una ventana de tiempo en la que se sospecha de problemas, o cuando se desea repartir el coste de un scrub a lo largo de varias ejecuciones parciales para no impactar demasiado en el rendimiento global.

Otra novedad relevante es la incorporación de zpool prefetch -t brt para precargar en memoria la Block Reference Table (tabla de clonación de bloques). Con ello se explota mejor la funcionalidad de clonación de bloques introducida en versiones anteriores, reduciendo latencias al acceder a estructuras internas que participan en esta característica.

Permisos, herramientas renombradas y mejoras en dedup y block cloning

Dentro de las pequeñas grandes cosas que pulen la experiencia, OpenZFS 2.4 añade un nuevo permiso send:encrypted, pensado para controlar de forma más granular quién puede realizar envíos de datos cifrados. Esto encaja muy bien con equipos donde hay separación de responsabilidades entre quienes gestionan snapshots, quienes se ocupan de la replicación y quienes tienen acceso a las claves de cifrado.

También se renombraron utilidades tradicionales como arc_summary y arcstat, que pasan a llamarse zarcsummary y zarcstat. Este cambio ayuda a evitar conflictos de nombres y deja más claro que se trata de herramientas asociadas a ZFS, algo útil en sistemas con múltiples componentes que exponen comandos similares.

A nivel interno, la serie 2.4 acumula nuevas optimizaciones y correcciones tanto en la deduplicación como en la clonación de bloques. Se afinan estructuras de datos, se corrigen casos límite y se buscan mejores patrones de acceso para que el impacto en memoria y CPU sea más razonable. No son cambios que el usuario vea directamente, pero se notan en comportamientos más estables y en menos sorpresas bajo cargas complicadas.

Gang blocks, ashift, child vdevs lentos y topologías especiales

OpenZFS 2.4 incorpora además una batería de mejoras y arreglos sobre los gang blocks, una característica interna del sistema pensada para lidiar con bloques que no pueden ser ubicados de forma convencional. Aunque la mayoría de usuarios no interactúa directamente con ellos, cualquier fallo en esta parte del código puede tener consecuencias serias, así que las múltiples correcciones y optimizaciones incluidas son una buena noticia para la robustez general del sistema.

En paralelo, se ha seguido refinando el manejo de ashift, el parámetro que define la unidad mínima de asignación alineada con el tamaño físico de los sectores del dispositivo. Una mejor gestión de ashift reduce la posibilidad de escribir más datos de los necesarios en discos con sectores grandes y ayuda a mantener el rendimiento en niveles aceptables durante toda la vida útil del pool.

Otra novedad interesante es la capacidad de hacer que vdevs hijos que se comportan de manera anormalmente lenta puedan “quedarse en el banquillo” de forma temporal. En lugar de arrastrar el rendimiento de todo el conjunto, el sistema puede dejar de depender de ellos durante un tiempo, lo que resulta muy útil cuando hay discos empezando a fallar, unidades con problemas intermitentes o entornos con hardware desigual.

Por último, se han relajado las restricciones de topología en los vdev especiales y de deduplicación, lo que da más margen a la hora de diseñar pools con configuraciones avanzadas. De este modo se puede combinar mejor el uso de dispositivos rápidos para metadatos, dedup tables, ZIL y otros elementos sensibles sin chocar con limitaciones demasiado rígidas en la definición del layout.

OpenZFS 2.3.4: mantenimiento, zfs rewrite inicial y consolidación

Para entender bien el salto que supone 2.4, conviene echar un vistazo rápido a OpenZFS 2.3.4, una versión de mantenimiento que apareció poco antes y que sentó parte de las bases de lo que luego se ha consolidado en la nueva rama principal.

La 2.3.4 llegó dos meses después de la 2.3.3 con un enfoque muy marcado en robustez y compatibilidad. Amplió el soporte de kernel Linux hasta la versión 6.16, manteniendo el mínimo en 4.18, y confirmó la compatibilidad con FreeBSD desde la 13.3 en adelante, incluyendo el futuro 15.0. Es decir, ya se estaba preparando el terreno para convivir con sistemas base modernos sin dejar atrás la estabilidad.

En esta revisión puntual se estrenó la versión inicial del comando zfs rewrite, pensado precisamente para reubicar datos sin cambiar su contenido lógico y sin recurrir a estrategias más pesadas como copiar/renombrar o send/receive con renombrado de datasets. El objetivo era ofrecer una herramienta capaz de reequilibrar un pool tras añadir vdevs, reducir la fragmentación de archivos escritos de forma aleatoria o aplicar nuevas propiedades de almacenamiento a datos ya existentes.

Frente a las alternativas tradicionales, zfs rewrite resulta más rápido porque evita el viaje de los datos al espacio de usuario. En datasets con sync=always, además, mejora los tiempos porque al no modificarse los datos a nivel lógico no se disparan escrituras adicionales en el ZIL. Todo ello sin tocar mtime ni otros metadatos visibles para las aplicaciones, lo que minimiza el impacto sobre el software que corre por encima.

La 2.3.4 también aportaba diversos ajustes específicos para FreeBSD, mejoras de empaquetado y un conjunto de correcciones menores que pulían rincones del código. No era una versión destinada a introducir cambios disruptivos, sino a darle una vuelta de tuerca a la estabilidad antes de dar el salto a la rama 2.4 con un paquete más grande de novedades.

RC1, RC2, RC4 de OpenZFS 2.4: pruebas, feedback y debate en la comunidad

Antes de que la serie 2.4 se declarase estable, el proyecto publicó varias release candidates (RC1, RC2, RC4) con el objetivo de que usuarios avanzados y desarrolladores pudieran probarlas y reportar problemas. Estas versiones candidatas ya incluían prácticamente todo el conjunto de funcionalidades que hemos comentado: cuotas por defecto, IO sin caché como fallback, unified allocation throttling, mejoras de cifrado, ZIL en vdevs especiales, extensiones de special_small_blocks, nuevos permisos, renombrado de herramientas y un largo etcétera.

En las notas de RC1 y RC2 se insistía en la importancia de que la comunidad probara las builds y enviara feedback a través de GitHub, incluyendo comandos para listar fácilmente los cambios respecto a la rama de referencia (con combinaciones de git cherry que comparaban zfs-2.3-release con las distintas RC). El mensaje era claro: se buscaba sacudir el código en entornos reales antes de poner la etiqueta de “estable”.

Sin embargo, la aparición de una RC concreta (por ejemplo, 2.4.0-RC4) integrada en una versión de FreeBSD marcada como RELEASE, como la 15.0, levantó algunas cejas. Algunos usuarios se preguntaban por qué se había decidido incluir una release candidate de OpenZFS en una versión considerada estable del sistema operativo en lugar de recurrir a una rama anterior ya consolidada. Esta elección generó cierto malestar en quienes prefieren que el sistema de archivos sobre el que descansan sus datos se base estrictamente en versiones finales.

Las dudas giraban en torno a la durabilidad de esa decisión: si alguien instala FreeBSD 15.0 con OpenZFS 2.4.0-RC4 y luego no sigue la rama -CURRENT, existe la preocupación de quedarse “atascado” durante varios meses con una RC hasta que llegue una revisión menor o un nuevo punto de la serie. También se planteaba el temor a que futuros lanzamientos como 15.1 volvieran a integrar otra RC (por ejemplo, un hipotético 2.4.1-RC3) en lugar de una versión ya final.

Detrás de este debate hay diferentes maneras de entender qué debe significar “release candidate” en un contexto tan sensible como un sistema de archivos. Para algunas personas, una RC es ya prácticamente una versión estable, solo pendiente de pulir pequeños detalles. Para otras, en cambio, se trata de código que no debería usarse de base en un sistema marcado como RELEASE y que convendría reservar para quien sigue de cerca las ramas de desarrollo.

En cualquier caso, los RC cumplieron su misión de campo de pruebas: permitieron detectar fallos, ajustar detalles y llegar a la etiqueta “2.4 estable” con mucha más confianza. Quienes valoran la seguridad por encima de todo siguen teniendo la opción de permanecer en ramas anteriores como 2.3.x hasta que consideren que la 2.4 ha demostrado suficiente madurez en producción.

Todo lo que aporta OpenZFS 2.4 se apoya en la solidez que el proyecto ha ido ganando con la serie 2.3 y sus actualizaciones de mantenimiento, combinando mejoras de compatibilidad de kernel, nuevas herramientas como zfs rewrite, ajustes en deduplicación y block cloning, optimizaciones de cifrado, cambios internos en gang blocks y ashift, y un abanico de nuevas opciones de administración. Aunque haya surgido cierta controversia con el uso de versiones candidatas en algunos sistemas operativos, el conjunto de la versión estable 2.4 ofrece un salto de calidad importante para quien quiera sacar más partido a ZFS en Linux y FreeBSD sin renunciar a las garantías de integridad y resiliencia de siempre.