Déduplication au niveau de la partition

Quelles sont les solutions disponibles pour le niveau de bloc ou la déduplication plus détaillée?

Il existe des fichiers - avec l'approche "Copy-On-Write".

Je suis à la recherche de "copie sur écriture" au niveau du bloc, afin que je puisse périodiquement rechercher des blocs communs, ou - de préférence - des parties de fichiers, les fusionner et marquer pour l'utilisation de CoW. Existe-t-il quelque chose comme ça ou faut-il encore le créer? Je ne sais pas si la déduplication Btrfs est au niveau bloc / fichier / sous-partie? Il existe LessFS, mais je ne sais pas quel niveau de déduplication offre-t-il? Peut-être une autre solution?

En ce qui concerne la déduplication au niveau des blocs, je pense que ZFS est la meilleure implémentation incontestée actuellement. Il n'est vraiment pas conçu pour une optimisation après coup, car sa déduplication (si elle est activée) est intégrée directement dans les fonctions de lecture / écriture. Pour cette raison, la mémoire peut être un peu chère sous charge, en essayant de conserver les parties les plus pertinentes de la table de déduplication en mémoire, mais ZFS est bon à se limiter à consommer pas plus de 50% de mémoire, ce qui, selon la quantité de mémoire installée, peut sembler assez arbitraire (50% de 2 Go contre 50% de 64 Go, surtout s'il y a peu ou pas de tâches utilisateur nécessitant de la mémoire).

Selon ce que vous cherchez à utiliser, vous avez plusieurs options:

OpenIndiana semble avoir de bonnes options de bureau et de serveur, basées sur Solaris

FreeBSD (depuis 9.0) a une version assez avancée de ZFS (qui inclut la déduplication) intégrée. Une distribution dérivée notable de FreeBSD (alors MonoWall) est NAS4Free , ce qui rend la création d'un NAS assez facile.

Linux a quelques options, certaines avec déduplication, d'autres sans. Puisque vous recherchez la déduplication, le plus notable que j'ai vu est zfsonlinux . Je ne suis pas sûr de leurs progrès, ni de la stabilité de leur projet, mais cela semble définitivement prometteur.

En ce qui concerne tout ce qui a une déduplication partielle de blocs, je n'ai jusqu'à présent rien vu qui rapporte une capacité à le faire.

Votre question est un peu déroutante en raison du terme "blocs", qui est un mot très surchargé en ce qui concerne les disques et les systèmes de fichiers. (Mais votre contexte environnant aide à clarifier.) Btrfs ne traite pas des "blocs" de système de fichiers de taille fixe, il traite des "étendues" de taille variable. (Bien que, de manière confuse, elle définisse également des zones de bloc de taille variable.) ZFS traite des "blocs" de système de fichiers, en partie ou principalement parce que cela présente des problèmes beaucoup plus faciles à résoudre. Btrfs et ZFS connaissent tous deux les "blocs" au niveau du disque, qui sont eux-mêmes des abstractions. (Ensuite, nous avons également le "stockage au niveau du bloc", qui peut avoir une signification sémantiquement différente.) Je pourrais avoir ces descriptions un peu décalées, pas assez claires ou pas exactes à 100%. (Si vous avez besoin de clarté et de précision à 100% sur le sujet des blocs, faites comme si vous n'aviez pas lu ça. Si vous avez juste besoin d'une compréhension approximative pour continuer, alors vous devriez être prêt à partir.) Le point principal de cette réponse n'est pas de définir parfaitement les "blocs", mais la discussion ci-dessous, qui est beaucoup plus dans ma timonerie.

Comme l'a écrit @killermist, ZFS prend en charge nativement la déduplication au niveau des blocs [ZFS].

Il n'est pas activé par défaut dans ZFS. L'activer sans suffisamment de mémoire implique un coup dur pour les performances. De plus, pour l'anecdote, ZFS a besoin d'une bonne quantité de plus que la règle de base recommandée "1 Go de RAM par 1 To de stockage", pour s'adapter à l'intégralité de la table de hachage dans la RAM. Mais même ainsi, selon le matériel, vous pouvez toujours atteindre des vitesses d'écriture de 40 Mo / s. J'obtiens cela sur la technologie de l'ère 2008 exécutant des disques de l'ère 2015. Parfaitement acceptable pour moi pour la plupart des données d'archives. Le plus gros inconvénient de la déduplication ZFS, c'est qu'il n'y a pas encore de manière élégante de le faire en mode "batch / offline" (ou plus précisément "hors bande"), autre que d'activer la déduplication, de tout copier sur un nouveau répertoire temporaire sur le même système de fichiers, en supprimant les originaux, puis en reculant le contenu temporaire (désormais dédupliqué).

La déduplication de Btrfs est sans doute un peu plus sommaire, avec seulement des utilitaires tiers actuellement disponibles pour faire le travail. (Mais qui utilisent soit des API de noyau bien prises en charge, et / ou une option bien prise en charge pour cp; et de toute façon nécessitant leur propre logique pour déterminer les doublons, ce qui, nous l'espérons, est précis.) Un avantage potentiel est cependant ces utilitaires sont "hors bande". Le coût pour la plupart des utilitaires, cependant, est qu'ils tuent les performances tout en martelant - ce qui peut prendre des heures, des jours, voire des semaines. (Personnellement, je préfère gérer les performances d'écriture toujours plus lentes de la déduplication ZFS intrabande que de marteler mes disques durs pendant des jours, disons, une fois par an.)

Deux solutions Btrfs que je connais qui traitent des "blocs" (mais dans une autre définition encore) plutôt que des fichiers, sont les abeilles et dduper .

Les abeilles, par exemple, définissent arbitrairement une taille de "bloc" pour elles-mêmes lors de la première exécution, en fonction de la mémoire disponible et éventuellement d'autres facteurs. (Bien que je déforme probablement son objectif, ses fonctionnalités, son mécanisme et ses avantages / inconvénients, puisque je ne l'utilise pas, je ne l'ai évalué que récemment en option.)

Les abeilles sont sans doute légèrement hybrides, car elles sont conçues pour fonctionner en continu, et ne martèlent pas les disques aussi durement - bien qu'elles ne soient toujours pas techniquement "en bande" comme la déduplication ZFS. Il récupère simplement les doublons après coup et essaie de les dédupliquer avec une légère touche. Travailler avec une taille de bloc définie arbitrairement signifie que, par conception, il s'adaptera à la table de hachage dans la RAM. L'inconvénient (vraisemblablement) est qu'il peut y avoir des étendues dans un "bloc" qui sont les mêmes, mais les abeilles ne peuvent pas se dédoubler parce que les "blocs" dans lesquels elles se trouvent sont autrement différents.

Gardez à l'esprit que même les utilitaires qui effectuent spécifiquement la déduplication Btrfs de niveau "fichier" (comme bedup , duperemove , rmlint et autres) peuvent toujours répondre à vos besoins. Je ne peux pas en être sûr, mais il semble qu'ils le feraient. C'est parce que même une commande "cp --reflink = always" ne déduplique pas vraiment les "fichiers". Il déduplique les extensions Btrfs . Lorsqu'un "fichier" redistribué change, Btrfs ne déduplique que les extensions qui changent, à leurs propres extensions uniques. Le reste du fichier reste dédupliqué. C'est ainsi que les gros fichiers dédupliqués peuvent toujours diverger comme si leurs propres fichiers étaient uniques, mais toujours majoritairement dédupliqués.

(C'est aussi pourquoi il est si difficile de déterminer si un "fichier" est redéfini ou non, car ce concept n'a même pas vraiment de sens. Toutes les étendues d'un fichier peuvent elles-mêmes être redéfinies vers d'autres mêmes étendues, un concept qui ne logique, mais c'est une question particulièrement difficile à répondre. C'est pourquoi, à moins qu'un utilitaire de déduplication Btrfs ne garde la trace de ce qu'il a déjà dédupliqué, cela ne vaut pas la peine d'essayer de "détecter" si un fichier a déjà été dédupliqué. Il n'y a aucun attribut tel que refcount à inspecter. Il est plus facile de le dédupliquer à nouveau de toute façon. En revanche, déterminer si un fichier entier est lié en dur à l'ancienne, est trivial. Vérifiez simplement le nombre st_nlink pour un inode donné.)

L'absence de "clone de fichier entier" est en fait une caractéristique intrinsèque de tous les systèmes de fichiers CoW qui prennent en charge les instantanés et / ou la déduplication "gratuits", et il est vrai qu'il s'agisse d'extensions Btrfs, de blocs ZFS ou d'autre chose. C'est pourquoi l'un ou l'autre peut probablement être une réponse à votre question. (Il y a au moins trois autres systèmes de fichiers CoW qui peuvent ou sont prévus pour pouvoir faire tout cela, que je sache: nilfs2, bcachefs et xfs.)

Bien que vous n'ayez pas mentionné cela, aucune technologie de déduplication à ma connaissance n'est compatible avec le type de fichier. En d'autres termes, aucun dédoublonneur ne sait ignorer les métadonnées * .jpg et ne considérer que les données d'image compressées pour la déduplication. De même, aucun d'entre eux ne considère les nombres magiques des fichiers (au moins pour déterminer ce qu'il faut considérer pour la déduplication). Cela pourrait être une fonctionnalité mortelle - bien que nécessitant certainement des mises à jour constantes et continues de la définition. Et pourrait être très difficile à concevoir, tout en traitant les fichiers comme une collection abstraite M: M d'extensions, de blocs, etc.