¿Cuáles son las soluciones disponibles para la deduplicación a nivel de bloque o más detallada?
Los hay basados en archivos, con el enfoque "Copiar en escritura".
Estoy buscando "copiar en escritura" a nivel de bloque, por lo que podría buscar periódicamente bloques comunes o, preferiblemente, partes de archivos, fusionarlos y marcarlos para el uso de CoW. ¿Hay algo como esto disponible o aún es necesario crearlo? No estoy seguro de si la deduplicación de Btrfs es a nivel de bloque/archivo/subparte. Existe LessFS, pero no estoy seguro de qué nivel de deduplicación proporciona. ¿Quizás otra solución?
Respuesta1
En lo que respecta a la deduplicación a nivel de bloque, creo que ZFS es la mejor implementación indiscutible que existe actualmente. Realmente no está diseñado para una optimización posterior, porque su deduplicación (si está activada) está integrada directamente en las funciones de lectura/escritura. Debido a esto, la memoria puede ser un poco costosa bajo carga, al tratar de mantener las partes más relevantes de la tabla de deduplicación en la memoria, pero ZFS es bueno para restringirse a consumir no mucho más del 50% de la memoria, lo que dependiendo de cantidad de memoria instalada, podría parecer bastante arbitraria (50% de 2Gb frente a 50% de 64Gb, especialmente si hay pocas tareas de usuario que necesiten memoria).
Dependiendo de para qué quieras usarlo, tienes algunas opciones:
AbiertoIndianaparece tener algunas buenas opciones de escritorio y servidor, basadas en Solaris
FreeBSD (desde 9.0) tiene integrada una versión bastante avanzada de ZFS (que incluye deduplicación). Una distribución derivada notable de FreeBSD (entonces MonoWall) esNAS4Gratis, lo que hace que crear un NAS sea bastante fácil.
Linux tiene algunas opciones, algunas con desduplicación y otras sin ella. Ya que estás buscando deduplicación, lo más notable que he visto eszfsonlinux. No estoy seguro de cuál es su progreso ni de qué tan estable es su proyecto, pero definitivamente parece prometedor.
En cuanto a cualquier cosa con deduplicación parcial de bloques, hasta ahora no he visto NADA que informe sobre la capacidad de hacerlo.
Respuesta2
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 el contexto que lo rodea ayuda a aclararlo). Btrfs no se ocupa de "bloques" de sistemas de archivos de tamaño fijo, sino de "extensiones" de tamaño variable. (Aunque, de manera confusa, 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 conocen los "bloques" a nivel de disco, que son en sí mismos abstracciones. (Luego también tenemos "almacenamiento a nivel de bloque", que puede tener un significado semánticamente diferente). Es posible que esas descripciones sean un poco incorrectas, no lo suficientemente claras o no sean 100% precisas. (Si necesita claridad y 100% de precisión sobre el tema de los bloques, finja que no lo leyó. Si solo necesita una comprensión aproximada para continuar, entonces debería estar listo). El punto principal de esta respuesta no es Definir perfectamente "bloques", pero 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 a nivel de bloque [ZFS].
No está habilitado de forma predeterminada en ZFS. Activarlo sin suficiente memoria implica un gran impacto en el rendimiento. Además, como anécdota, 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 puedes obtener velocidades de escritura superiores a 40 MB/s. Lo entiendo con tecnología de la era 2008 que ejecuta unidades de la era ~ 2015. Perfectamente aceptable para mí para datos en su mayoría de archivo. El mayor inconveniente de la deduplicación ZFS es que todavía no existe una forma elegante de hacerlo en modo "por lotes/fuera de línea" (o más exactamente, "fuera de banda"), aparte de activar la deduplicación y copiar todo en un nuevo directorio temporal en el mismo sistema de archivos, eliminando los originales y luego moviendo hacia atrás el contenido temporal (ahora deduplicado). (Excepto que eliminar los archivos antiguos podría llevar más tiempo que la operación inicial de copia/descopia). Lo que normalmente hago es esperar hasta tener que rediseñar periódicamente la matriz de todos modos para cambiar el diseño fundamental y copiar de la matriz anterior a la anterior. Nuevo, con deduplicación puesta.
Podría decirse que la deduplicación de Btrfs es un poco más complicada, ya que actualmente sólo hay utilidades de terceros disponibles para hacer el trabajo. (Pero que utilizan API del kernel con buen soporte y/o una opción para cp con buen soporte; y de cualquier manera requieren su propia lógica para determinar duplicados, lo cual se espera que sea totalmente preciso). Sin embargo, un beneficio potencial son esas utilidades. están "fuera de banda". Sin embargo, el costo para la mayoría de las utilidades es que matan el rendimiento mientras lo desgastan, lo que puede tardar 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 dañar mis discos duros durante días, digamos, terminar una vez al año).
Dos soluciones Btrfs que conozco que tratan con "bloques" (pero en otra definición más) en lugar de archivos, sonabejas, yduper.
Bees, por ejemplo, define arbitrariamente un tamaño de "bloque" para sí mismo en la primera ejecución, basándose en la memoria disponible y posiblemente en otros factores. (Aunque probablemente estoy tergiversando su propósito, características, mecanismo y ventajas y desventajas, como no lo uso, solo lo evalué recientemente como una opción).
Se podría decir que Bees es un poco híbrido, ya que está diseñado para ejecutarse continuamente y no golpear los discos con tanta fuerza, aunque técnicamente todavía no está "en banda" como el desduplicado ZFS. Simplemente detecta duplicados a posteriori 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 no pueden desduplicarse porque los "bloques" en los que se encuentran son diferentes.
Tenga en cuenta que incluso las utilidades que realizan específicamente la deduplicación Btrfs a nivel de "archivo" (comoacostarse,dupereliminar,rmlint, y otros), aún pueden satisfacer sus necesidades. 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 Btrfs.extensiones. Cuando un "archivo" vinculado nuevamente cambia, Btrfs solo elimina la duplicación de las extensiones que cambian, a sus propias extensiones únicas. El resto del archivo permanece deduplicado. Así es como los archivos deduplicados de gran tamaño aún pueden divergir como si fueran archivos únicos, pero aun así estar en su mayoría deduplicados.
(Esta es también la razón por la que es tan difícil determinar si un "archivo" tiene un nuevo vínculo o no, porque ese concepto ni siquiera tiene sentido. Todos los archivos de un archivoextensionespueden volver a vincularse a otros niveles iguales, un concepto que tiene sentido, pero coincidentemente es una pregunta particularmente difícil de responder. Es por eso que, a menos que una utilidad de deduplicación Btrfs realice un seguimiento de lo que ya ha deduplicado, no vale la pena intentar "detectar" si un archivo ya ha sido deduplicado. No hay ningún atributo como refcount para inspeccionar. De todos modos, es más fácil simplemente deduplicarlo nuevamente. Por el contrario, determinar si un archivo completo está vinculado a la antigua usanza es trivial. Simplemente verifique el recuento de st_nlink para un inodo determinado).
La falta de "clon de archivos completos" es de hecho una característica intrínseca de todos los sistemas de archivos CoW que admiten instantáneas "gratuitas" y/o deduplicación, y es cierta ya sea que se trate de extensiones Btrfs, bloques ZFS o cualquier otra cosa. Es por eso que cualquiera de las dos probablemente pueda ser una respuesta a su pregunta. (Hay al menos otros tres sistemas de archivos CoW que pueden o están previstos que puedan hacer todo eso, que yo sepa: nilfs2, bcachefs y xfs).
Aunque no mencionaste esto, que yo sepa, ninguna tecnología de deduplicación reconoce el tipo de archivo. En otras palabras, ningún deduplicador sabe omitir los metadatos *.jpg y solo considerar los datos de la imagen comprimida para la deduplicación. Del mismo modo, ninguno de ellos considera los números mágicos de los archivos (al menos para determinar qué considerar para la deduplicación). Esa podría ser una característica excelente, aunque ciertamente requiere actualizaciones de definición constantes y continuas. Y podría ser realmente difícil de diseñar, al mismo tiempo que se tratan los archivos como una colección abstracta M:M de extensiones, bloques, etc.