Deduplicación offline en OpenZFS: ¿por fin es práctica?

OpenZFS acaba de ganar una forma mucho más práctica de deduplicar archivos existentes en Linux: la rama master upstream implementa ahora FIDEDUPERANGE usando el block cloning de ZFS. Eso significa que herramientas como duperemove y bees pueden encontrar rangos de archivo idénticos después de escribir los datos y pedir a ZFS que comparta esos bloques sin pagar el coste de memoria tradicional de mantener cada candidato en la tabla de deduplicación de ZFS.

He revisado el commit real de OpenZFS en lugar de fiarme del titular del foro. El cambio se hizo el 20 de agosto de 2026 y es posterior a OpenZFS 2.4.2 estable, que salió en mayo. Por ahora es una función upstream que conviene seguir y probar, y yo no daría por hecho que ya está disponible en un sistema TrueNAS, Proxmox, Debian o Ubuntu en producción.

¿Qué ha cambiado exactamente en la deduplicación de OpenZFS?

OpenZFS implementa ahora la interfaz FIDEDUPERANGE de Linux comparando rangos de archivo y usando el block cloning de ZFS cuando los rangos son idénticos byte a byte. Antes de este cambio, ZFS respondía a esta interfaz con un error de operación no admitida.

FIDEDUPERANGE es una interfaz de sistemas de archivos de Linux que permite a una herramienta de deduplicación en espacio de usuario decir, en la práctica: "estos dos rangos parecen idénticos, ¿puede el sistema de archivos comprobarlo y hacer que compartan almacenamiento?". El sistema de archivos sigue siendo el responsable de verificar que los datos coinciden antes de cambiar las referencias de almacenamiento.

La implementación de OpenZFS hace esa verificación dentro de ZFS. Cuando los punteros de bloque y los checksums fuertes bastan para demostrar la igualdad, puede ahorrarse lecturas innecesarias. Cuando no bastan, lee y compara los datos. Si los rangos coinciden, usa la maquinaria de block cloning que ya existe para que los dos rangos lógicos apunten a bloques físicos compartidos.

El resultado es distinto de una copia normal: los archivos siguen siendo archivos lógicos separados, y si uno cambia más adelante, el comportamiento copy on write preserva el otro.

Es una extensión natural del block cloning de ZFS y un tema útil para cualquiera que siga el diseño de ZFS y almacenamiento, porque cambia el momento en que puedes decidir deduplicar los datos.

¿En qué se diferencia la deduplicación offline de la deduplicación normal de ZFS?

La deduplicación offline ocurre después de que los datos ya se han escrito, mientras que la deduplicación tradicional de ZFS interviene en la ruta de escritura y registra los candidatos en una tabla de deduplicación. Esa diferencia de momento cambia el reparto de recursos.

La deduplicación inline tradicional de ZFS puede ahorrar espacio en cuanto llegan bloques coincidentes, pero tiene fama de metadatos caros. La tabla de deduplicación, que suele llamarse DDT, tiene que registrar las huellas y las referencias de los bloques. Una DDT grande puede consumir mucha memoria y presionar el rendimiento cuando no cabe con holgura en la RAM y la caché.

La nueva ruta de FIDEDUPERANGE no necesita rellenar la DDT tradicional para cada bloque deduplicado. El commit upstream describe de forma explícita el objetivo: compartir los rangos coincidentes mediante block cloning sin el coste de memoria de la tabla de deduplicación.

La deduplicación offline traslada el coste al análisis. Una herramienta como duperemove o bees tiene que identificar los posibles duplicados y después pedir al sistema de archivos que los confirme y los comparta. Eso consume CPU, IO de metadatos y ancho de banda de lectura en el momento en que ejecutas el análisis, en lugar de añadir el mismo tipo de coste de búsqueda global a cada escritura entrante.

Ninguno de los dos modelos es mejor en todos los casos. Si tu carga de trabajo escribe continuamente bloques de copia de seguridad duplicados y reducir el espacio al instante es imprescindible, la deduplicación inline todavía puede tener sentido. Si tienes un árbol de archivos grande donde los duplicados se acumulan con el tiempo y puedes programar el análisis en periodos más tranquilos, la deduplicación offline es mucho más fácil de planificar.

¿Significa esto que la deduplicación de ZFS ya no necesita mucha RAM?

Esta nueva ruta de deduplicación offline evita el coste de memoria de la DDT tradicional para los rangos que deduplica, pero no hace que toda la deduplicación de ZFS salga gratis en memoria. Si activas dedup=on de la forma normal, sigues usando la maquinaria tradicional o la de Fast Dedup y sus estructuras de metadatos.

Esa distinción importa más que cualquier otra cosa aquí, y "OpenZFS arregla el consumo de RAM de la deduplicación" sería un titular engañoso. OpenZFS ha añadido otra vía para compartir espacio que no requiere el mismo diseño de DDT siempre activa.

El proyecto más amplio de Fast Dedup también está mejorando el sistema tradicional. OpenZFS ha añadido funciones como cuotas para la DDT, precarga, un diseño con registro y trabajo de poda para que la deduplicación inline se pueda acotar y gestionar de forma más predecible. Esas mejoras y la deduplicación offline resuelven problemas relacionados desde direcciones distintas.

Yo pensaría en las opciones así:

• La compresión sigue siendo la función de ahorro de espacio por defecto que activaría casi en todas partes.
• El block cloning ahorra espacio cuando el software crea a propósito copias de tipo reflink.
• La deduplicación offline encuentra datos duplicados más tarde y convierte los rangos idénticos en bloques compartidos.
• La deduplicación inline intenta detectar bloques duplicados a medida que se escriben.

Una vez separas esos cuatro mecanismos, es mucho más fácil hablar del diseño de ZFS.

¿Puedo usar hoy la deduplicación offline de OpenZFS?

No deberías dar por hecho que tu paquete estable actual ya la incluye. El commit correspondiente llegó a la rama master de OpenZFS el 20 de agosto de 2026, mientras que OpenZFS 2.4.2 salió el 12 de mayo de 2026.

A 21 de agosto, eso significa que un sistema normal con la versión estable 2.4.2 debe considerarse sin este commit, salvo que su proveedor le haya aplicado el backport. Además, el empaquetado de las distribuciones puede ir por detrás de upstream, y los productos tipo appliance suelen validar los cambios en el sistema de archivos según su propio calendario.

Antes de probar, comprueba la compilación exacta de OpenZFS que trae tu sistema operativo o tu appliance y lee sus notas de versión. En un host Proxmox, eso significa que el kernel y los paquetes ZFS de Proxmox importan más que la existencia de un commit en GitHub. En TrueNAS, lo que importa es el tren de versiones de TrueNAS. En Debian o Ubuntu, la versión del paquete de la distribución.

Si quieres experimentar con código upstream, usa primero datos desechables. Las funciones de un sistema de archivos merecen un listón más alto que las de una aplicación, porque un fallo puede afectar a todo un pool y no a un solo proceso.

Quien ejecute ZFS bajo virtualización también debería separar el cambio de almacenamiento de las actualizaciones del hipervisor. Si ya estás planificando una actualización de Proxmox VE 8 a 9, yo no metería código experimental de OpenZFS master en la misma ventana.

¿Cómo se mantiene seguro FIDEDUPERANGE si un archivo cambia durante la deduplicación?

La implementación de OpenZFS compara y clona los rangos bajo bloqueo, de modo que los bytes que se comparten son los bytes que realmente se compararon. Esto importa porque una herramienta offline puede identificar candidatos en espacio de usuario, pero solo el sistema de archivos puede decidir con seguridad si los rangos en disco siguen siendo idénticos en el momento de deduplicar.

El commit también contempla los rangos que ya están compartidos. En ese caso, OpenZFS puede dar el rango por deduplicado sin reescribir innecesariamente las referencias de bloque.

También me gusta que la operación de deduplicación no cambie el contenido del archivo, así que no tiene por qué comportarse como una escritura normal, y la implementación evita tratarla como una modificación de contenido solo porque las referencias de almacenamiento pasen a ser compartidas.

Por eso importa el soporte nativo del sistema de archivos. Una herramienta en espacio de usuario debería identificar candidatos y pedir al sistema de archivos que haga la operación segura sobre las referencias, en lugar de simular la deduplicación reescribiendo archivos a espaldas de las aplicaciones.

¿Qué cargas de trabajo pueden sacar más partido de la deduplicación offline de ZFS?

La deduplicación offline de ZFS resulta más atractiva cuando ya hay datos duplicados en archivos normales y el análisis se puede programar fuera de la ruta de escritura crítica. Repositorios de copias de seguridad, exportaciones repetidas de imágenes de VM, colecciones de ISO, directorios personales de usuarios, árboles de compilación de software y archivos de contenido son candidatos obvios para probar.

El ahorro real dependerá de la duplicación a nivel de bloque y de rango, del tamaño de bloque de los archivos, de la compresión, del comportamiento del cifrado y de cómo encuentre candidatos el analizador. Un directorio lleno de archivos con nombres parecidos no es necesariamente deduplicable. Un directorio lleno de plantillas de VM idénticas byte a byte probablemente sí.

Las copias de seguridad son un caso interesante, porque las aplicaciones de backup modernas suelen hacer su propia fragmentación, compresión y deduplicación. Aplicar deduplicación del sistema de archivos debajo de un repositorio ya deduplicado puede ahorrar poco y añadir IO de análisis. La prueba útil es cuántos bytes físicos ahorra en ese repositorio una vez descontado el coste del análisis.

Yo mediría cuatro cosas en un laboratorio: bytes ahorrados, duración del análisis, IO de lectura generado y efecto sobre las escrituras posteriores en archivos deduplicados. Si la herramienta ahorra un 3 por ciento de capacidad a cambio de leer 40 TB cada noche, probablemente es un mal negocio. Si ahorra un 35 por ciento de un archivo mayormente estático con un análisis semanal de baja prioridad, la cosa se pone mucho más interesante.

¿Es por fin esta la deduplicación de ZFS que debería usar la mayoría?

Para muchos usuarios que han evitado dedup=on porque no querían una DDT grande y siempre activa, la deduplicación offline es el primer modelo de deduplicación de ZFS que yo consideraría probar en serio. Encaja con la forma en que los administradores ya piensan en las tareas de mantenimiento: encontrar el desperdicio, recuperarlo y devolver el sistema a su trabajo normal.

Aun así, mantendría la compresión por defecto y dejaría desactivada la deduplicación inline salvo que la carga de trabajo demuestre que merece esa complejidad. La nueva ruta offline es atractiva precisamente porque te da otra opción sin obligar a la ruta de escritura a resolver la deduplicación de cada bloque para siempre.

Lo que la frena hoy es la disponibilidad. El código está integrado upstream, pero OpenZFS 2.4.2 estable es anterior. Yo esperaría a la primera versión estable o compilación de un proveedor que incluya el commit, probaría duperemove o bees con una copia de datos reales y tomaría la decisión a partir del ahorro medido.

En ese momento la deduplicación de ZFS se vuelve más interesante para los administradores de almacenamiento corrientes, porque la pregunta pasa de "¿me puedo permitir activar la deduplicación en todo este dataset?" a "¿merece la pena limpiar estos datos duplicados a posteriori?".