Mejoras en la deduplicación de OpenZFS, pero recomiendan evitar su uso

 (despairlabs.com)
1 puntos por GN⁺ 2024-10-31 | 1 comentarios | Compartir por WhatsApp
  • Fast Dedup de OpenZFS 2.3.0 mejoró mucho frente a la deduplicación anterior, pero sigue siendo una función cuyo costo y condiciones deben evaluarse antes de activarla como si fuera una opción por defecto para usuarios comunes
  • La deduplicación evita reescribir bloques ya almacenados y solo aumenta las referencias, por lo que todos los caminos de escritura y liberación cargan con el costo de consultar y actualizar la dedup table
  • El método anterior tenía una gran carga de memoria e IO por la amplificación de read-modify-write de la tabla basada en ZAP, la live entry list que no podía recuperarse durante la transacción y las unique entry que no daban beneficio
  • Fast Dedup reduce las live entry de 424 bytes a 216 bytes e incorpora dedup log, flush incremental, zpool ddtprune, dedup_table_quota, prefetch de DDT y kstats para que el operador controle mejor los costos
  • En cargas generales puede haber pocos bloques realmente duplicados, y como BRT/block cloning de OpenZFS 2.2 ofrece ahorros parecidos con menor costo, la deduplicación solo conviene usarla con cuidado cuando coinciden grandes volúmenes de datos duplicados y la ausencia de alternativas zero-copy

Funcionamiento básico de la deduplicación en OpenZFS

  • La deduplicación (dedup) es una función de OpenZFS que, antes de escribir datos al disco, omite una nueva escritura si los mismos datos ya existen y agrega una referencia a la copia existente
  • La parte difícil es que debe guardar y consultar continuamente la información necesaria para saber rápido si esos datos ya están en disco y dónde están
  • La estructura que contiene esa información es la dedup table
    • Conceptualmente, es una tabla hash con el checksum de los datos como clave, y la ubicación en disco y el conteo de referencias (refcount) como valor
    • No es dato de usuario, sino dato estructural del pool almacenado como parte del metadata del pool

Costos en las rutas de escritura y liberación

  • Si la deduplicación está desactivada, OpenZFS obtiene espacio del metaslab allocator, coloca el DVA devuelto en el block pointer y escribe los datos
  • Si la deduplicación está activada, primero consulta el checksum en la dedup table
    • Si no existe una entrada, asigna nuevo espacio, escribe los datos y crea una nueva dedup entry con refcount 1
    • Si la entrada existe, copia el DVA existente al block pointer, da por completado el IO de escritura y aumenta el refcount
  • En los bloques asignados por deduplicación se establece el flag D en el block pointer
    • Al liberar, si está el flag D, vuelve a consultar la dedup table y reduce el refcount
    • Si el refcount llega a 0, elimina la dedup entry y libera el espacio real
  • Como toda escritura y liberación pasa por consultas y actualizaciones de la dedup table, para que la deduplicación valga la pena el ahorro real de espacio e IO debe superar el overhead de administrar la tabla

Por qué la deduplicación anterior era mala

  • Amplificación de la dedup table basada en ZAP

    • La dedup table anterior usaba ZAP, el objeto de tabla hash on-disk estándar de OpenZFS
    • ZAP es una estructura genérica que también se usa para directorios, listas de atributos y administración interna, pero no encaja bien para almacenar dedup entry
    • Una dedup entry típica se compone de una clave de 40 bytes y un valor de unos 64 bytes después de comprimir, y en un ZAP block de 32K caben alrededor de 188 entry normales
    • Como OpenZFS no hace escrituras parciales de bloque ni sobrescrituras in-place, incluso actualizar una sola entry obliga a leer el ZAP block completo, modificarlo y volver a escribirlo como un bloque nuevo
    • Como la clave checksum debe ser resistente a colisiones, es poco probable que dos entry arbitrarias queden cerca en el mismo ZAP block, y también es poco probable que varias actualizaciones dentro de una transacción terminen agrupadas en el mismo bloque
    • Si hay suficiente RAM y el ARC puede retener la dedup table, se reduce el costo de lectura, pero de ahí viene la vieja recomendación de que la deduplicación requiere mucha memoria
    • La clase de vdev dedup puede reducir un poco esa exigencia agregando un dedup vdev dedicado, suficientemente grande y rápido, pero a una escala donde la deduplicación tenga sentido sigue necesitando tamaño suficiente para contener toda la tabla y velocidad adecuada

  • Uso de memoria de la live entry list

    • OpenZFS guarda en memoria las dedup entry creadas o modificadas durante una transacción en la live entry list
    • Esta estructura evita que, cuando los mismos datos se escriben varias veces al mismo tiempo, cada hilo de escritura concluya que aún no están en la dedup table y termine escribiéndolos todos de nuevo
    • La búsqueda primero revisa la live entry list
      • Si la entry existe, aumenta el refcount
      • Si no existe, crea una live entry en estado “in progress”, carga la entry real desde ZAP y luego la cambia a “ready”
      • Otros hilos de escritura que lleguen al mismo tiempo esperan hasta que pase a ready
    • Al terminar la transacción, recorre la live entry list y refleja su contenido en el dedup ZAP
    • Cada live entry anterior ocupaba 424 bytes, y esa memoria no era ARC sino kernel slab memory, así que no podía recuperarse cuando el sistema sufría presión de memoria
    • La live entry list se vacía por transacción, pero si en una sola transacción se escriben muchos datos distintos, el pico puede crecer bastante

  • Las unique entry inflan la tabla

    • La deduplicación rastrea todos los bloques almacenados en disco, pero solo hay beneficio real cuando el refcount es mayor que 1
    • Una unique entry con refcount 1 es más bien el costo de esperar que esos mismos datos se vuelvan a escribir algún día
    • La deduplicación se realiza por bloque después del cifrado y la compresión
    • Incluso si los datos originales son iguales, solo se tratan como el mismo bloque si también coinciden el método de compresión, la clave de cifrado y hasta la alineación dentro del archivo
    • En cargas de propósito general suele haber pocos bloques “realmente iguales”, así que el costo de la deduplicación puede superar fácilmente el beneficio

Mejoras de Fast Dedup

  • Reducción de las live entry

    • Fast Dedup primero reduce el memory footprint de la live entry list
    • Convierte flags con tipos numéricos grandes de ddt_entry_t en bitfields y simplifica los campos de sincronización
    • El estado de 40 bytes que solo se usa al escribir por primera vez un bloque deduplicado o cuando hace falta un repair write se separa en un objeto IO state independiente
    • El valor anterior de una dedup entry incluía cuatro physical entry y ocupaba 256 bytes
    • Cada physical entry contenía tres DVA de 128 bits, el refcount y el birth transaction id
    • La cuarta entry es un rastro de la antigua función dedupditto; OpenZFS moderno solo admite leerla, no escribir nuevas
    • Cuando cambia copies= y se necesitan más DVA, Fast Dedup ya no mantiene la variante previa como una entry separada, sino que asigna solo las copias extra necesarias y las agrega a la dedup entry existente
    • El valor de entry en la nueva Fast Dedup table se reduce de 256 bytes a 72 bytes
    • Cada entry en la live list baja de 424 bytes a 216 bytes

  • Introducción del dedup log

    • En el método anterior, al final de la transacción la live entry list se reflejaba directamente en el dedup ZAP, y eso generaba costo de actualización a nivel de bloque aunque las otras 187 entry alrededor casi siempre no tuvieran relación
    • Fast Dedup agrega un dedup log basándose en la observación de que los bloques creados o duplicados recientemente tienen mayor probabilidad de volver a deduplicarse o liberarse
    • Al final de la transacción, los cambios de la live entry no se escriben directo al ZAP, sino que se registran en el log
      • El log on-disk es necesario para la seguridad ante fallos
      • El log in-memory se mantiene para búsquedas rápidas
    • El orden de búsqueda pasa a ser live entry list, in-memory log y luego dedup ZAP
    • El log on-disk se usa al importar el pool para reconstruir el in-memory log

  • Flush incremental del log

    • Si, como en el diseño inicial, el log se vaciara de golpe al ZAP cuando creciera demasiado, incluso con apenas unos miles de entry podrían producirse pausas largas
    • Fast Dedup usa incremental flushing, que refleja una parte del log en el ZAP en cada transacción
    • La cantidad que se vacía se ajusta comparándola con el tiempo consumido por el IO real
      • En periodos ocupados escribe menos
      • En periodos tranquilos escribe más
      • Si el in-memory log crece y genera presión de memoria, el flush puede acelerarse
    • Para mantener el log on-disk como append-only y al mismo tiempo vaciarlo sin detener todo el sistema, usa dos logs
      • Uno es el active log que recibe cambios nuevos
      • El otro es el flushing log que se refleja en el ZAP
      • Cuando el flushing log queda vacío, el on-disk log se pone en cero y ambos intercambian funciones
    • En un pool scan como scrub o resilver, como el dedup log no tiene una noción estable de ubicación, al solicitar el escaneo se acelera el flushing del log para reflejarlo por completo en el dedup ZAP y luego se escanea con el método tradicional

Gestión de unique entry y funciones operativas

  • zpool ddtprune elimina parte de las unique entry de la dedup table del pool
    • Puede especificarse por age o por percentage
    • El criterio por age encaja especialmente bien en cargas donde los datos usados recientemente tienen más probabilidad de volver a deduplicarse
  • Si más adelante se copia un bloque cuya dedup entry fue eliminada por pruning, ya no se deduplicará con el bloque anterior y se asignará un bloque nuevo
    • Aun así, si un unique block viejo de repente se copia varias veces, puede formarse un conjunto de varias referencias a un mismo bloque nuevo
  • La propiedad de pool dedup_table_quota limita el tamaño máximo de la dedup table
    • Si crear una nueva entry supera el límite, no se crea la entry y la operación se procesa como una escritura normal sin deduplicación
    • También puede usarse para evitar que, al llenarse un dedicated dedup device, el exceso termine desbordándose al dispositivo principal
  • zpool prefetch -t ddt precarga la dedup table en el ARC
    • Puede ayudar al rendimiento justo después de importar el pool
    • También sigue siendo útil con Fast Dedup, porque aún se necesitan accesos al ZAP al consultar entry que no están en el log y al hacer flush
  • También se agregaron nuevos kstats y tuneables
    • Linux: /proc/spl/kstat/zfs/<pool>/ddt_stats_<checksum>
    • FreeBSD: kstat.zfs.<pool>.misc.ddt_stats_<checksum>
    • Tuneable en Linux: /sys/modules/zfs/parameters/zfs_dedup_log_*
    • Tuneable en FreeBSD: vfs.zfs.dedup.log_*
  • Las herramientas existentes con conocimiento de dedup, como zpool status -D, zdb -D y zdb -S, también se actualizaron para entender la nueva estructura

Compatibilidad con la dedup table anterior

  • La mayor parte de Fast Dedup requiere cambios en el on-disk format, así que no puede aplicarse tal cual a la dedup table anterior
  • En la tabla anterior sí pueden funcionar las funciones que no requieren cambiar el formato on-disk
    • dedup_table_quota
    • zpool prefetch -t ddt
    • Búsqueda y conteo de hits de ddt_stats_*
    • ZAP shrink
  • Hacer que el dedup log funcione también con la tabla tradicional sigue siendo una tarea relativamente straightforward
    • Sin embargo, no se obtendrían las ventajas de las live/log entry más pequeñas
  • En la tabla anterior, a zpool ddtprune solo se le puede agregar con facilidad el modo de “percentage of uniques”
    • El modo por age requiere datos del nuevo formato de entry, así que no es posible con el formato anterior
  • Actualmente no existe una función para convertir la tabla anterior al formato nuevo
    • En casos simples donde copies= nunca cambió, sería posible crear un nuevo ZAP y convertir/copiar las entry existentes
    • La conversión online es compleja porque requiere búsquedas o escrituras simultáneas en el ZAP viejo y el nuevo
    • La conversión offline es más sencilla, pero obliga a dejar el pool offline
    • Si hubo cambios en copies= y varias variantes tienen refcount, una conversión completa puede ser imposible
  • Sí funciona enviar un dataset deduplicado a otro pool nuevo que admita la nueva deduplicación

“Mejoró, pero ¿por qué no conviene activarla?”

  • Fast Dedup reduce el overhead frente a la deduplicación anterior y puede ser útil en más casos marginales
  • Pero la deduplicación sigue siendo un problema de equilibrio entre throughput de IO, uso de memoria y tamaño de la dedup table
  • En cargas de propósito general puede haber muy pocos bloques susceptibles de deduplicarse
  • En el pool de ejemplo de una laptop, el resultado simulado de DDT con zdb -S casi no mostró beneficio por deduplicación
    • De 11.7M entry, la mayoría tenía refcount 1 y eran unique entry
    • La cantidad de entry realmente deduplicables era, en la práctica, nivel error de redondeo frente al total
    • Aparecía como dedup = 1.00
  • En estos casos, activar dedup solo agrega presión de IO y memoria sin obtener casi nada a cambio

Cuando BRT/block cloning es mejor

  • Desde OpenZFS 2.2 existe BRT, es decir, block cloning o reflinks
  • La dedup table es una estructura para responder “¿estos datos ya están en disco?” sin contexto alguno
  • En sistemas modernos, a veces las operaciones de copia pueden comunicarle al storage stack que realmente son una copia
    • copy_file_range() en archivos de Linux y FreeBSD
    • copyfile() en macOS
    • FSCTL_SRV_COPYCHUNK en Windows
    • También hay funciones similares en NFS, CIFS, drivers de dispositivos de bloque del sistema operativo, SCSI EXTENDED COPY, NVMe Copy, etc.
  • Si el programa cliente y las capas intermedias transmiten esa señal de copy offload, OpenZFS puede simplemente aumentar el refcount en el BRT
  • BRT no paga costo si el bloque no fue clonado, y cuando sí lo fue, cada entry ocupa 16 bytes
  • En el pool de ejemplo, BRT mostró used 292M; saved 309M; ratio 2.05x
  • El ahorro bruto fue un poco menor y de nivel parecido al de la simulación de dedup, pero sin el gran costo de rastrear todos los bloques no clonados

Criterios prácticos

  • Fast Dedup mejora los tres ejes clásicos de la deduplicación tradicional: IO throughput, memory usage y dedup table size
  • También reduce el costo catastrófico cuando falla y agrega herramientas para que el operador limite y limpie la tabla
  • Aun así, para obtener beneficio las condiciones deben estar muy claras
    • El volumen de datos debe ser muy grande
    • Debe haber muchas copias del mismo dato
    • No debe ser posible usar otras opciones zero-copy de OpenZFS, como block cloning o snapshot clone
  • Si la carga permite que el cliente dé una señal clara de “quiero copiar esto”, block cloning puede ofrecer un beneficio grande con un costo mucho menor

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-31
Opiniones de Hacker News

  • Sería bueno tener deduplicación offline o deduplicación diferida, que no obligue a bajar por completo el pool pero que tampoco se ejecute de inmediato.
    Al activar la deduplicación, el hecho de que cada escritura y cada liberación requieran consultar y escribir en la tabla de deduplicación parece, en la mayoría de los casos, un enfoque equivocado. Cuando escribo datos, quiero que termine lo antes posible aunque use más espacio en disco; por eso no guardo los archivos en los que estoy trabajando dentro de un archivo 7zip. Sería bueno que, más adelante, cuando el sistema esté ocioso, ZFS encuentre datos duplicados y recupere espacio con algo como BRT; parece que incluso podría hacerse como parte de un scrub normal.

    • La deduplicación diferida/offline requiere reescritura de punteros de bloque, y como ZFS no es realmente un sistema CAS, es difícil que alguna vez tenga una reescritura de BP adecuada.
      La ubicación física se incluye en el hash dentro del árbol de hashes de Merkle, así que para mover una ubicación física hay que reescribir todos los nodos internos hasta el nodo que se quiere cambiar, lo cual es demasiado costoso. Un mejor diseño habría sido dividir todos los nodos que contienen punteros de bloque en dos partes: una con solo el puntero lógico de bloque, que sí se incluye en el hash del árbol, y otra que, como una caché, contenga solo la ubicación física correspondiente a ese puntero lógico, pero que no se incluya en el hash del árbol de Merkle. Así, la reescritura de BP solo tendría que reescribir bloques que no pertenecen al árbol de Merkle. Con la estructura actual es difícil obtener la función deseada en ZFS, aunque quizá sea posible un rodeo: si al leer aparece una discrepancia de hash, buscar el bloque en la tabla de deduplicación usando el hash del puntero y reasignar el bloque deduplicado. El costo sería más o menos una lectura inútil, así que no es tan malo, pero cuando la reescritura de BP es imposible suelen aparecer parches de este tipo.
    • Este método es igual a la metodología de deduplicación de Windows. La usé bastante y, si el hardware era suficiente, en general me dejó satisfecho.
      Consume mucha RAM y E/S, pero se puede programar y limitar el “groveler”. Eso sí, en la época de Windows 2012 R2 sufrí una corrupción que se comió datos por un bug.
    • Esto también se puede hacer con un detector offline de archivos duplicados.
      Por ejemplo, existen jdupes o duperemove. Envié PR tanto a ZFS como a duperemove para que soportaran las llamadas al sistema necesarias. La revisión del lado de ZFS tardó mucho, y me di cuenta de que había olvidado por completo cerrar el tema, así que tengo que retomarlo.
    • En ZFS, la capacidad de cambiar snapshots existentes es extremadamente limitada, incluso si se hace de una forma que preserve los datos por completo. Por eso estaría bien tener una función así, pero si estabas esperando Block Pointer Rewrite, ya te habrías muerto hace mucho.
    • Lo bueno de la deduplicación inline es que, si el hash del bloque ya existe, no hace falta escribir realmente ese bloque.
      En varias situaciones puede reducir mucho la E/S de escritura. En algunos arreglos de almacenamiento con deduplicación existe incluso una extensión en la que, si se copia un archivo entre dos VM, no se copia el dato real, sino que solo se incrementa el contador de referencias del bloque original. Para el sistema operativo parece una velocidad de escritura absurda de TB/s, y es bastante genial.

  • La afirmación de que “el problema fundamental de la deduplicación tradicional es que este overhead es tan grande que resulta difícil recuperarlo salvo en cargas de trabajo raras y específicas” suena bastante extraña.
    He trabajado con arreglos de Pure y Dell/EMC, y en cargas de trabajo de VMWare normalmente veíamos al menos un ahorro de 3:1 con deduplicación/compresión. Guardar una sola copia de la imagen base de una VM funciona muy bien. Incluso en servidores syslog, la deduplicación/compresión funcionaba bien y llegué a ver ahorros de 6:1. La eficacia de la deduplicación depende mucho del tamaño de bloque usado para el hash, y cuanto más pequeño, mejor. A medida que el bloque se reduce, la probabilidad de que aparezcan bloques coincidentes crece rápidamente; por experiencia, mi tamaño de bloque preferido es 4KB.

    • Las imágenes de VM son información con muchísima redundancia, como cuando las unidades C de imágenes de Windows Server son casi iguales, mientras que el texto original usó como ejemplo el contenido de su propia laptop.
      Además, parece estar mezclando dos funciones distintas: compresión y deduplicación. En ZFS se puede activar la compresión en el pool, y casi siempre vale la pena, pero la deduplicación puede dejarse desactivada.
    • Las imágenes base de VM sí son una carga de trabajo rara y específica, y uno de los pocos casos en los que la deduplicación tiene sentido.
      Dicho eso, si alojas VM sobre un sistema de archivos ZFS, probablemente estés usando una estrategia mejor, como clones a nivel de bloque o de sistema de archivos. No hacerlo equivale a renunciar a uno de los diferenciadores clave de ZFS en ese entorno. En un servidor de archivos de propósito general o en un escritorio/laptop personal, normalmente hay muy pocos bloques duplicados y el overhead no se justifica. Los backups pueden o no funcionar, según cómo estén implementados y si se cifran antes de llegar a la capa del sistema de archivos. La compresión es un tema completamente distinto, y la práctica recomendada actual en ZFS es activarla por defecto para casi todas las cargas de trabajo. Hoy en día el costo de CPU es tan pequeño que ni vale la pena mencionarlo, y más allá del ahorro de espacio, la reducción de E/S puede ser considerable. Para un almacén de logs típico, por experiencia, se pueden lograr ahorros mucho mejores que 6:1.
    • No lo probé personalmente, pero una cifra muy citada sobre la antigua deduplicación de ZFS es que requiere 5GB de RAM por cada 1TB de disco.
      Si hoy 1TB de disco cuesta unos 15 dólares y 5GB de RAM de servidor unos 25 dólares, hace falta una tasa de deduplicación de 3:1 solo para llegar al punto de equilibrio. Si los datos encajan bien, quizá se pueda sobrevivir con 1GB por TB, pero con mala suerte ni 5GB serán suficientes. Por eso el artículo decía que la deduplicación de ZFS tiene un pequeño sweet spot donde los datos tienen que encajar justo, y esa es la razón por la que a la mayoría no le importa. Otros sistemas de archivos suelen preferir la deduplicación offline, que normalmente tiene mejor economía.
    • Las VM tienen beneficios conocidos de deduplicación, así que ahí puede ser efectiva. Pero ZFS no es solo una SAN empresarial, sino un sistema de archivos de propósito general, y muchos usuarios de ZFS no ejecutan VM.
      Decir que la deduplicación/compresión funciona bien en syslog merece más detalle: deduplicación y compresión no son lo mismo. En el mundo del almacenamiento empresarial suelen agruparse, pero probablemente los logs se beneficien de la compresión, no de la deduplicación, y ZFS ya tenía compresión desde el principio.
    • Obviamente tiene sentido no tener varias copias profundas de una imagen base de VM, pero en ZFS la deduplicación no es el método adecuado.
      En su lugar, si clonas la imagen base, casi no ocupa espacio antes de los cambios. Esto se debe a la naturaleza copy-on-write de ZFS. La deduplicación de ZFS intenta encontrar copias existentes de los datos que se escriben en el volumen. Para algunos usos, como almacenes de imágenes de contenedores, puede tener bastante sentido, pero si ya sabes desde el principio que un dataset es clon de otro, es muy ineficiente.

  • Antes usábamos ampliamente la deduplicación de ZFS y obtuvimos grandes beneficios. El uso concreto era almacenamiento para clústeres de VMWare, con cientos de VM Linux y Windows cuyo contenido era en gran medida igual. Esto fue antes de Docker

    • Veo varios casos aquí de uso de deduplicación en VM, pero me parece que sería mucho más eficiente implementarlo en el hipervisor que en el sistema de archivos
    • Totalmente de acuerdo. Hace poco recibí una nueva laptop de trabajo con el zfs “experimental” de Ubuntu, y usar deduplicación en el nix store ayudó muchísimo

  • Me entusiasma mucho la deduplicación rápida. Durante años quise usar deduplicación de ZFS para mis datos de ArchiveBox, y con la deduplicación rápida parece que por fin será posible archivar millones de URL en una sola colección y dejar que el sistema de archivos se encargue de la compresión global
    En los datos de archivo se repiten en miles de snapshots cosas como jquery.min.js, bootstrap.min.css e imágenes de logos. Otras herramientas comprimen dentro de un solo rastreo y generan archivos wacz o warc.gz, pero no parece que ninguna herramienta haya intentado comprimir atravesando la base de datos completa de todos los snapshots tomados hasta ahora. También me da curiosidad si alguien ha probado un enfoque de deduplicación probabilística usando algo como un Bloom filter para no guardar completa la tabla hash de deduplicación global. Se agrupan, por ejemplo, unos 100 hashes de bloques en buckets, y se guarda una representación ultracomprimida en el Bloom filter. Al escribir, se consulta en el Bloom filter el hash del bloque que se va a escribir y, si se detecta un posible acierto de deduplicación, se recorren directamente los 100 bloques de ese bucket para buscar un hash idéntico. En teoría, se podrían tener capas de Bloom filters con distinta resolución y bajar dinámicamente a disco los filtros de alta resolución cuando haya mucha presión de memoria. Si la precisión del Bloom filter se deja como un parámetro ajustable, se podría elegir la preferencia entre tiempo de CPU/overhead y proporción de bytes ahorrados

    • Incluso con este cambio, la deduplicación de ZFS sigue estando basada en alineación de bloques, así que si los recursos web repetidos no están siempre en el mismo offset dentro del archivo WARC, probablemente no encaje bien
      dm-vdo se comporta igual. En su lugar, podría convenir más usar compresión solid que observe rangos largos, descomprimir los archivos WARC en una estructura equivalente a un directorio, o un sistema FUSE basado en chunking definido por contenido, si existe. Tal vez Seafile haga eso
    • Entiendo el caso de uso, pero en la mayoría de los casos, y en especial en este, creo que sería mucho mejor implementarlo del lado del cliente
      Si miras el estándar WARC, ya existe una forma de deduplicación basada en hashes, que guarda la primera copia y luego usa punteros. Por eso es un ejemplo exacto de un caso donde la deduplicación a nivel de sistema de archivos no es muy buena
    • El caso de uso es un poco distinto, pero si no conoces zbackup, creo que te va a gustar

  • Me pregunto por qué les cuesta tanto hacer que esto funcione bien reduciendo el uso de RAM. Los appliances de almacenamiento comerciales ya lo hacían desde hace al menos unos 10 años, incluso en sistemas con “poca” RAM en comparación con la capacidad de discos conectada
    Me parece que bastaría con guardar las huellas digitales en una base de datos y recorrerla de noche corrigiendo los punteros de bloques

    • “Corregir los punteros de bloques” es precisamente la razón. Por varios motivos, ZFS no tiene la capacidad de reescritura de punteros de bloques
      Es una función solicitada desde hace mucho y, si existiera, también permitiría desfragmentar. He pensado que podría resolverse con algo de costo en velocidad usando indirección de punteros de bloques, como en memoria virtual, pero no soy desarrollador de ZFS y seguramente se me escapa algo. http://eworldproblems.mbaynton.com/posts/2014/zfs-block-poin... / https://github.com/openzfs/zfs/issues/3582
    • Corregir punteros de bloques es precisamente lo único que ZFS no quería hacer
    • También está la opción de usar DragonFlyBSD y Hammer2. Hammer2 admite deduplicación en línea y fuera de línea, y en muchos aspectos es muy parecido a ZFS
      La gran desventaja es que no tiene un protocolo de transferencia de archivos que use RDMA. Escuché que también hay una rama experimental para poder ejecutar Hammer2 en FreeBSD. Pero FreeBSD tampoco tiene soporte para RDMA. En FreeBSD 15, Chelsio patrocinó soporte de destino e iniciador NVMe-oF, aunque parece que solo para TCP

  • Puedes usar cp --reflink=auto
    Obtienes deduplicación a nivel de archivo. Este comando realiza una copia ligera y, como con los clones de ZFS a nivel de archivo, los bloques de datos solo se copian cuando se modifican. No es un enlace duro, es una copia. El mismo método debería funcionar en otros sistemas de archivos transaccionales copy-on-write que admitan reflink

  • De verdad quería usar ZFS, pero todos los datos obviamente tienen que estar cifrados. Sin embargo, el uso se volvió mucho más complicado de lo esperado, y cuando las cosas se enredan me sorprendió ver que mucha gente simplemente no cifra sus datos
    Incluso Proxmox tiene “Enterprise” en su sitio web, así que esperaba que soportara cifrado en la instalación predeterminada, pero si intentas usarlo con cifrado pierdes funciones importantes. También hay que revisar bien el issue tracker. Hay varias cosas sorprendentes que no esperaría encontrar en un sistema de archivos de producción

    • La mejor forma de cifrar ZFS es poner ZFS sin cifrar encima de un volumen cifrado, por ejemplo un volumen LUKS. El “cifrado” de ZFS deja demasiadas cosas en texto claro como para dar confianza

  • Me gustaría que, como sistema de archivos, tuviera una API completamente distinta. La superficie de API de los sistemas de archivos en todos los sistemas operativos es un desastre total atrapado por la retrocompatibilidad

    • Internamente, ZFS es esencialmente un almacén de objetos. Hubo trabajos para exponerlo como una API de almacén de objetos, pero lamentablemente parece que no llegaron a nada
      Intenté encontrar la presentación, pero no pude. Creí haberla visto en la Developer Summit, pero parece que no
    • ¿Por qué es un desastre y con qué se podría reemplazar? ¿Una API tipo AWS S3 sería una mejora?

  • Olvídate de la deduplicación y usa compresión de ZFS; tiene una relación costo-beneficio mucho mejor

    • La excepción sería si tu dataset ya son archivos multimedia muy comprimidos
      En general, durante tareas con rsync también suelo desactivar la compresión para archivos de video grandes. La compresión ayuda poco o nada en almacenamiento o transferencia, pero consume RAM y CPU. La deduplicación es buena para imágenes de sistemas operativos de Virtual Machines, porque la mayor parte del costo de almacenamiento está en la imagen base repetida

  • La deduplicación de propósito general suena bien en teoría, pero en la práctica muchas veces no resulta. IPFS usa fragmentos de tamaño variable y hash rolling para deduplicar datos como rsync, pero en la práctica no logra marcar una diferencia y solo añade complejidad innecesaria