Su pregunta es un poco confusa debido al término "bloques", que es una palabra muy sobrecargada cuando se trata de discos y sistemas de archivos. (Pero su contexto circundante ayuda a aclarar). Btrfs no trata con "bloques" del sistema de archivos de tamaño fijo, trata con "extensiones" de tamaño variable. (Aunque, confusamente, también define zonas de bloques de tamaño variable). ZFS trata con "bloques" del sistema de archivos, en parte o principalmente porque hacerlo presenta problemas significativamente más fáciles de resolver. Tanto Btrfs como ZFS son conscientes de los "bloques" a nivel de disco, que son abstracciones. (Entonces también tenemos "almacenamiento a nivel de bloque", que puede ser un significado semánticamente diferente). Podría tener esas descripciones un poco apagadas, no lo suficientemente claras o no 100% precisas. (Si necesita claridad y 100% de precisión en el tema de los bloques, finge que no leíste eso. Si solo necesita una comprensión aproximada para continuar, entonces debería estar listo para comenzar.) El punto principal de esta respuesta no es definir perfectamente "bloques", sino la discusión a continuación, que está mucho más en mi timonera.
Como escribió @killermist, ZFS admite de forma nativa la deduplicación de nivel de bloque [ZFS].
No está habilitado por defecto en ZFS. Encenderlo sin suficiente memoria implica un gran impacto en el rendimiento. Además, anecdóticamente, ZFS necesita una cantidad considerable más que la regla general recomendada de "1 gb de RAM por 1 tb de almacenamiento", para que quepa toda la tabla hash en la RAM. Pero aun así, dependiendo del hardware, aún puede obtener más de 40 MB / s de velocidad de escritura. Lo entiendo en la tecnología de la era de 2008 funcionando ~ unidades de la era de 2015. Perfectamente aceptable para mí para la mayoría de los datos de archivo. El mayor inconveniente de la deduplicación de ZFS es que todavía no hay una manera elegante de hacerlo en modo "por lotes / fuera de línea" (o más exactamente "fuera de banda"), aparte de activar la deduplicación, copiar todo en un nuevo directorio temporal en el mismo sistema de archivos, eliminando los originales, luego moviendo los contenidos temporales (ahora deduplicados) de regreso.
La deduplicación de Btrfs es posiblemente un poco más esquemática, con solo utilidades de terceros actualmente disponibles para hacer el trabajo. (Pero que usan API de kernel bien soportadas, y / o una opción bien soportada para cp; y de cualquier manera requieren su propia lógica para determinar duplicados, lo que uno espera sea exacto). Sin embargo, un beneficio potencial son esas utilidades están "fuera de banda". Sin embargo, el costo para la mayoría de las empresas de servicios públicos es que matan el rendimiento al tiempo que martillan, lo que puede llevar horas, días e incluso semanas en completarse. (Personalmente, prefiero lidiar con un rendimiento de escritura siempre más lento de la deduplicación ZFS en banda, que martillar mis discos duros durante días, por ejemplo, terminar una vez al año).
Conozco dos soluciones de Btrfs que tratan con "bloques" (pero en otra definición) en lugar de archivos, son abejas y dduper .
Las abejas, por ejemplo, definen arbitrariamente un tamaño de "bloque" para sí mismo en la primera ejecución, según la memoria disponible y posiblemente otros factores. (Aunque probablemente estoy tergiversando su propósito, características, mecanismo y pros / contras, ya que no lo uso, solo lo evalué recientemente como una opción).
Se puede decir que Bees es ligeramente híbrido, ya que está diseñado para funcionar continuamente y no golpear los discos con tanta fuerza, aunque técnicamente no es "en banda" como ZFS dedup. Simplemente recoge duplicados después del hecho e intenta deduplicarlos con un ligero toque. Trabajar con un tamaño de bloque definido arbitrariamente significa que, por diseño, se ajustará a la tabla hash en la RAM. El inconveniente (presumiblemente) es que puede haber extensiones en un "bloque" que sean iguales, pero las abejas pueden no deducir porque los "bloques" en los que se encuentran son diferentes.
Tenga en cuenta que incluso las utilidades que realizan específicamente la deduplicación de Btrfs a nivel de "archivo" (como bedup , duperemove , rmlint y otras), aún pueden satisfacer sus requisitos. No puedo estar seguro, pero parece que lo harían. Esto se debe a que incluso un comando "cp --reflink = always" no está realmente deduplicando "archivos". Está deduplicando las extensiones de Btrfs . Cuando cambia un "archivo" vinculado, Btrfs solo desduplica las extensiones que cambian, a sus propias extensiones únicas. El resto del archivo permanece deduplicado. Así es como los archivos deduplicados grandes aún pueden divergir como si fueran sus propios archivos únicos, pero aún se pueden deduplicar en su mayoría.
(Esta es también la razón por la que es tan difícil determinar si un "archivo" se vuelve a vincular o no, porque ese concepto ni siquiera tiene sentido. Todas las extensiones de un archivo se pueden vincular a otras extensiones iguales, un concepto que sí tiene sentido, pero coincidentemente es una pregunta particularmente difícil de responder. Por eso, a menos que una utilidad de deduplicación de Btrfs haga un seguimiento de lo que ya ha deduplicado, no vale la pena intentar "detectar" si un archivo ya ha sido deduplicado. No hay un atributo como el recuento para inspeccionar. Es más fácil deduplicarlo nuevamente de todos modos. Por el contrario, determinar si un archivo completo está vinculado de la manera tradicional, es trivial. Simplemente verifique el recuento st_nlink para un inodo dado).
La falta de "clonación de archivos completos" es, de hecho, una característica intrínseca de todos los sistemas de archivos de CoW que admiten instantáneas y / o deduplicaciones "gratuitas", y es cierto si se trata de extensiones Btrfs, bloques ZFS o algo más. Es por eso que cualquiera de los dos puede ser una respuesta a su pregunta. (Hay al menos otros tres sistemas de archivos CoW que pueden o están planeados para poder hacer todo eso, que yo sepa: nilfs2, bcachefs y xfs).
Aunque no mencionó esto, no hay tecnología de deduplicación que yo sepa, es consciente del tipo de archivo. En otras palabras, ningún deduplicador sabe omitir los metadatos * .jpg y solo considera los datos de la imagen comprimida para la deduplicación. Del mismo modo, ninguno de ellos considera los números mágicos del archivo (al menos para determinar qué considerar para la deduplicación). Esa podría ser una característica excelente, aunque ciertamente requiere actualizaciones constantes y continuas de definición. Y podría ser realmente difícil de diseñar, al mismo tiempo que trata los archivos como una colección abstracta M: M de extensiones, bloques, etc.