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.