Deduplicación a nivel de partición

¿Cuáles son las soluciones disponibles para nivel de bloque o deduplicación más detallada?

Hay archivos basados ​​en el enfoque "Copiar en escritura".

Estoy buscando "copiar y escribir" en el nivel de bloque, por lo que periódicamente podría buscar bloques comunes o, preferiblemente, partes de archivos, fusionarlos y marcar la manera de uso de CoW. ¿Hay algo como esto disponible o aún necesita ser creado? No estoy seguro de si la deduplicación Btrfs es de nivel de bloque / archivo / subparte. Hay LessFS, pero no estoy seguro de qué nivel de deduplicación proporciona. Tal vez otra solución?

A medida que avanza la deduplicación a nivel de bloque, creo que ZFS es la mejor implementación indiscutible actualmente. Realmente no está diseñado para la optimización posterior al hecho, porque su deduplicación (si está activada) está integrada directamente en las funciones de lectura / escritura. Debido a esto, puede ser un poco costoso la memoria bajo carga, al tratar de mantener las porciones más relevantes de la tabla de deduplicación en la memoria, pero ZFS es bueno para restringirse a consumir no más del 50% de la memoria, lo que depende de la cantidad de memoria instalada puede parecer bastante arbitraria (50% de 2 Gb frente a 50% de 64 Gb, especialmente si pocas tareas de usuario necesitan memoria).

Dependiendo de lo que esté buscando usar, tiene algunas opciones:

OpenIndiana parece tener algunas buenas opciones de escritorio y servidor, basadas en Solaris

FreeBSD (desde 9.0) tiene una versión bastante avanzada de ZFS (que incluye deduplicación) incorporada. Una distribución derivada de FreeBSD notable (entonces MonoWall) es NAS4Free , lo que hace que hacer un NAS sea bastante fácil.

Linux tiene algunas opciones, algunas con dedup, otras sin ellas. Como estás buscando dedup, lo más notable que he visto es zfsonlinux . No estoy seguro de cuál es su progreso o cuán estable es su proyecto, pero definitivamente parece prometedor.

En cuanto a cualquier cosa con deduplicación de bloque parcial, hasta ahora no he visto NADA que informe sobre la capacidad de hacerlo.

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.