Améliorations de la déduplication d’OpenZFS : son usage reste déconseillé

• Fast Dedup d’OpenZFS 2.3.0 s’est nettement amélioré par rapport à l’ancienne déduplication, mais cela reste une fonctionnalité dont les coûts et les conditions doivent être soigneusement évalués avant qu’un utilisateur ordinaire ne l’active comme s’il s’agissait d’un réglage par défaut
• La déduplication évite de réécrire des blocs déjà stockés et se contente d’augmenter leurs références ; cela ajoute donc un coût de consultation et de mise à jour de la dedup table sur tous les chemins d’écriture et de libération
• L’ancienne approche entraînait une forte pression mémoire et IO à cause de l’amplification read-modify-write des tables basées sur ZAP, de la live entry list impossible à récupérer pendant une transaction, et des unique entries sans bénéfice
• Fast Dedup réduit les live entries de 424 à 216 octets, et donne aux administrateurs un meilleur contrôle des coûts grâce au dedup log, au flush progressif, à zpool ddtprune, à dedup_table_quota, au préchargement DDT et aux kstats
• Sur les workloads courants, il peut y avoir peu de blocs réellement dupliqués ; comme le BRT/block cloning d’OpenZFS 2.2 offre des économies similaires à moindre coût, la déduplication ne vaut d’être utilisée avec prudence que lorsque des données massivement dupliquées coexistent avec l’absence d’alternative zero-copy

---

Fonctionnement de base de la déduplication OpenZFS

• La déduplication (dedup) est une fonctionnalité par laquelle OpenZFS, avant d’écrire des données sur disque, saute la nouvelle écriture si les mêmes données existent déjà et ajoute une référence à la copie existante
• La difficulté consiste à conserver et consulter en permanence les informations permettant de savoir rapidement « si c’est déjà sur le disque » et « où cela se trouve »
• La structure qui contient ces informations est la dedup table
  • Conceptuellement, c’est une table de hachage dont la clé est le checksum des données, et dont les valeurs sont l’emplacement sur disque et le nombre de références (refcount)
  • Ce ne sont pas des données utilisateur, mais des données structurelles du pool stockées comme une partie des métadonnées du pool

Coûts ajoutés aux chemins d’écriture et de libération

• Quand la déduplication est désactivée, OpenZFS alloue de l’espace via le metaslab allocator, place le DVA renvoyé dans le block pointer, puis écrit les données
• Quand la déduplication est activée, il commence par rechercher le checksum dans la dedup table
  • S’il n’y a pas d’entrée, il alloue un nouvel espace, écrit les données, puis crée une nouvelle dedup entry avec un refcount de 1
  • S’il y a une entrée, il copie le DVA existant dans le block pointer, considère l’IO d’écriture comme terminée, puis incrémente le refcount
• Pour les blocs alloués via la déduplication, le flag D est défini dans le block pointer
  • Lors de la libération, si le flag D est présent, la dedup table est consultée à nouveau et le refcount est décrémenté
  • Lorsque le refcount atteint 0, la dedup entry est supprimée et l’espace réel est libéré
• Comme toutes les écritures et libérations passent par une consultation et une mise à jour de la dedup table, la déduplication n’est utile que si les économies réelles d’espace et d’IO dépassent l’overhead de gestion de la table

Pourquoi l’ancienne déduplication posait problème

• Amplification de la dedup table basée sur ZAP

  • L’ancienne dedup table utilisait ZAP, l’objet standard de table de hachage on-disk d’OpenZFS
  • ZAP est une structure générique aussi utilisée pour les répertoires, les listes d’attributs et la gestion interne, mais elle n’est pas bien adaptée au stockage des dedup entries
  • Une dedup entry typique se compose d’une clé de 40 octets et d’une valeur d’environ 64 octets après compression ; un bloc ZAP de 32K contient environ 188 entrées normales
  • Comme OpenZFS ne fait ni écritures partielles de blocs ni écrasements en place, la mise à jour d’une seule entrée impose de lire et modifier tout le bloc ZAP, puis de le réécrire dans un nouveau bloc
  • Les clés de checksum doivent fortement résister aux collisions ; il est donc peu probable que deux entrées quelconques soient placées près l’une de l’autre dans le même bloc ZAP, et peu probable aussi que plusieurs mises à jour d’une transaction se concentrent dans le même bloc
  • Si la RAM est suffisante et que l’ARC conserve en permanence la dedup table, le coût de lecture diminue, mais c’est ce qui a fait naître l’ancienne recommandation selon laquelle la déduplication demande beaucoup de mémoire
  • La classe de vdev dedup peut réduire légèrement les besoins mémoire en ajoutant un dedicated dedup vdev suffisamment grand et rapide, mais à une échelle où la déduplication a du sens, il doit être assez grand pour contenir toute la table et assez performant

• Utilisation mémoire de la live entry list

  • OpenZFS conserve en mémoire, dans la live entry list, les dedup entries créées ou modifiées pendant une transaction
  • Cette structure sert à éviter que, lorsque les mêmes données sont écrites plusieurs fois au même moment, chaque thread d’écriture conclue qu’elles ne sont pas encore dans la dedup table et les écrive toutes comme nouvelles
  • La recherche vérifie d’abord la live entry list
    • Si l’entrée s’y trouve, le refcount est incrémenté
    • Sinon, une live entry en état « in progress » est créée, l’entrée réelle est lue depuis ZAP, puis elle passe à l’état « ready »
    • Les autres threads d’écriture qui y accèdent simultanément attendent qu’elle soit ready
  • À la fin de la transaction, la live entry list est parcourue pour répercuter son contenu dans le ZAP de déduplication
  • Une live entry existante faisait 424 octets, et cette mémoire n’est pas dans l’ARC mais dans la kernel slab memory, donc elle ne peut pas être récupérée lorsque le système subit une pression mémoire
  • La live entry list est vidée à chaque transaction, mais si beaucoup de données différentes sont écrites dans une même transaction, son pic peut devenir important

• Les unique entries gonflent la table

  • La déduplication suit tous les blocs stockés sur disque, mais le bénéfice réel n’apparaît que lorsque le refcount est supérieur à 1
  • Une unique entry avec un refcount de 1 représente surtout un coût payé dans l’espoir que les mêmes données soient réécrites un jour
  • La déduplication est effectuée au niveau bloc après chiffrement et compression
  • Même avec les mêmes données d’origine, il faut que la méthode de compression, la clé de chiffrement et jusqu’à l’alignement dans le fichier correspondent pour que le bloc soit considéré comme identique
  • Dans les workloads généralistes, les blocs « réellement identiques » sont rares, si bien que le coût de la déduplication dépasse facilement ses bénéfices

Améliorations de Fast Dedup

• Réduction des live entries

  • Fast Dedup commence par réduire la footprint mémoire de la live entry list
  • Les grands flags de type numérique de ddt_entry_t sont remplacés par des bitfields, et les champs de synchronisation sont simplifiés
  • Les 40 octets d’état utilisés uniquement lors de la première écriture d’un bloc de données dédupliqué ou lorsqu’un repair write est nécessaire sont séparés dans un objet d’état IO distinct
  • L’ancienne valeur de dedup entry faisait 256 octets et incluait quatre physical entries
  • Chaque physical entry contient trois DVA 128 bits, un refcount et un birth transaction id
  • La quatrième entrée est une trace de l’ancienne fonctionnalité dedupditto, qu’OpenZFS moderne prend en charge en lecture seulement et n’écrit plus nouvellement
  • Fast Dedup, lorsque copies= change et que davantage de DVA sont nécessaires, ne conserve pas l’ancienne variant comme une entrée séparée ; il alloue seulement les copies supplémentaires nécessaires et les ajoute à la dedup entry existante
  • La valeur d’entrée de la nouvelle Fast Dedup table passe de 256 octets à 72 octets
  • Une entrée de la live list passe de 424 octets à 216 octets

• Introduction du dedup log

  • L’ancienne méthode répercutait directement la live entry list dans le ZAP de déduplication à la fin de la transaction, ce qui entraînait des mises à jour au niveau du bloc même lorsque les 187 entrées voisines étaient pour la plupart sans rapport
  • Fast Dedup ajoute un dedup log en partant de l’observation que les blocs récemment créés ou dédupliqués ont plus de chances d’être à nouveau dédupliqués ou libérés
  • À la fin d’une transaction, les modifications de live entries ne sont pas écrites directement dans ZAP, mais enregistrées dans le log
    • Le log on-disk est nécessaire pour la crash safety
    • Le log in-memory est conservé pour accélérer les recherches
  • L’ordre de recherche devient : live entry list, log in-memory, puis ZAP de déduplication
  • Le log on-disk sert à restaurer le log in-memory lors de l’import du pool

• Flush progressif du log

  • Avec l’approche initiale, si le log était flushé vers ZAP d’un seul coup lorsqu’il devenait trop gros, quelques milliers d’entrées pouvaient déjà provoquer une longue pause
  • Fast Dedup utilise un incremental flushing qui répercute une partie du log dans ZAP à chaque transaction
  • Le volume flushé est ajusté en le comparant au temps réellement consommé par l’IO
    • Il écrit moins pendant les périodes chargées, et davantage pendant les périodes calmes
    • Si le log in-memory grossit et crée une pression mémoire, le flush peut être accéléré
  • Pour conserver le log on-disk en append-only tout en le vidant sans interruption globale, deux logs sont utilisés
    • L’un est l’active log qui reçoit les nouvelles modifications
    • L’autre est le flushing log répercuté dans ZAP
    • Lorsque le flushing log est vide, le log on-disk est remis à zéro et les rôles des deux logs sont échangés
  • Lors d’un scan de pool comme un scrub ou un resilver, le dedup log n’ayant pas de notion stable de position, le log flushing est accéléré à la demande du scan afin que tout soit répercuté dans le ZAP de déduplication, puis le scan se déroule selon l’ancienne méthode

Gestion des unique entries et fonctions d’exploitation

• zpool ddtprune supprime certaines unique entries de la dedup table du pool
  • Il peut être paramétré selon un âge ou un pourcentage
  • Le critère d’âge convient particulièrement bien aux workloads où les données récemment utilisées ont plus de chances d’être à nouveau dupliquées
• Si un bloc dont la dedup entry a été supprimée par pruning est copié ultérieurement, il ne sera pas dédupliqué avec le bloc existant et sera alloué comme nouveau bloc
  • Toutefois, si un ancien unique block est soudain copié plusieurs fois, plusieurs références vers un nouveau bloc peuvent apparaître
• La propriété de pool dedup_table_quota limite la taille maximale de la dedup table
  • Si la création d’une nouvelle entrée dépasse la limite, aucune entrée n’est créée et l’écriture est traitée comme une écriture non dédupliquée classique
  • Elle peut être utilisée avec un dedicated dedup device pour éviter qu’il déborde vers le main device lorsqu’il est plein
• zpool prefetch -t ddt précharge la dedup table dans l’ARC
  • Cela peut améliorer les performances juste après l’import d’un pool
  • C’est aussi utile avec Fast Dedup, car les recherches d’entrées absentes du log et le flush nécessitent toujours d’accéder à ZAP
• De nouveaux kstats et tuneables ont aussi été ajoutés
  • Linux : /proc/spl/kstat/zfs/<pool>/ddt_stats_<checksum>
  • FreeBSD : kstat.zfs.<pool>.misc.ddt_stats_<checksum>
  • Tuneable Linux : /sys/modules/zfs/parameters/zfs_dedup_log_*
  • Tuneable FreeBSD : vfs.zfs.dedup.log_*
• Les outils existants compatibles avec la déduplication, comme zpool status -D, zdb -D et zdb -S, ont aussi été mis à jour pour comprendre la nouvelle structure

Compatibilité avec les anciennes dedup tables

• La majeure partie de Fast Dedup nécessite une modification de l’on-disk format, et ne s’applique donc pas telle quelle aux dedup tables existantes
• Même avec l’ancien format de table, certaines fonctions qui ne nécessitent pas de modification du format on-disk peuvent fonctionner
  • dedup_table_quota
  • zpool prefetch -t ddt
  • Consultation de ddt_stats_* et hit count
  • ZAP shrink
• Faire fonctionner le dedup log avec les tables traditionnelles reste une tâche relativement straightforward
  • En revanche, les avantages des live/log entries plus petites ne seraient pas obtenus
• Pour zpool ddtprune, seul le mode « percentage of uniques » est facile à ajouter aux anciennes tables
  • Le mode par âge nécessite des données du nouveau format d’entrée, et n’est donc pas possible avec l’ancien format
• Il n’existe actuellement aucune fonctionnalité permettant de convertir une ancienne table vers le nouveau format
  • Dans les cas simples où copies= n’a jamais changé, il serait possible de créer un nouveau ZAP, puis de convertir et copier les entrées existantes
  • Une conversion online est complexe, car elle nécessite de consulter ou d’écrire simultanément dans l’ancien et le nouveau ZAP
  • Une conversion offline est plus simple, mais impose de mettre le pool offline
  • Si un changement de copies= a produit plusieurs variants avec des refcounts, une conversion complète peut être impossible
• L’envoi d’un dataset dédupliqué vers un autre pool compatible avec la nouvelle déduplication fonctionne

« C’est mieux, mais pourquoi ne faut-il pas l’activer ? »

• Fast Dedup réduit l’overhead par rapport à l’ancienne version et peut donc être utile dans davantage de situations marginales
• Mais la déduplication reste une question d’équilibre entre débit IO, usage mémoire et taille de la dedup table
• Dans les workloads généralistes, les blocs susceptibles d’être dupliqués peuvent être extrêmement rares
• Le résultat de DDT simulée via zdb -S sur un pool de laptop d’exemple montrait un bénéfice de déduplication quasi nul
  • La plupart des 11,7 M d’entrées étaient des unique entries avec un refcount de 1
  • Le nombre d’entrées réellement déduplicables était de l’ordre de l’erreur d’arrondi par rapport au total
  • Le résultat affichait dedup = 1.00
• Dans ce cas, activer la déduplication n’apporte presque rien et ajoute seulement de la pression IO et mémoire

Quand BRT/block cloning est préférable

• Depuis OpenZFS 2.2, il existe BRT, c’est-à-dire le block cloning ou les reflinks
• La dedup table est une structure permettant de déterminer, sans contexte, « si ces données sont déjà sur le disque »
• Sur les systèmes modernes, une opération de copie peut parfois être transmise comme telle à la storage stack
  • copy_file_range() sur les systèmes de fichiers Linux et FreeBSD
  • copyfile() sur macOS
  • FSCTL_SRV_COPYCHUNK sur Windows
  • Des fonctions similaires existent aussi dans NFS, CIFS, les pilotes de block device de l’OS, SCSI EXTENDED COPY, NVMe Copy, etc.
• Si le programme client et les couches intermédiaires transmettent le signal de copy offload, OpenZFS peut simplement incrémenter le refcount dans BRT
• BRT n’entraîne aucun coût si les blocs ne sont pas clonés, et une entrée fait 16 octets lorsqu’ils le sont
• Sur le pool d’exemple, BRT affichait used 292M; saved 309M; ratio 2.05x
• L’économie brute était un peu inférieure et d’un ordre similaire à celle de la simulation de déduplication, mais sans le coût important consistant à suivre tous les blocs non clonés

Critères pratiques de décision

• Fast Dedup améliore les trois axes de la déduplication traditionnelle : débit IO, usage mémoire et taille de la dedup table
• Les coûts catastrophiques en cas d’échec sont aussi réduits, et les administrateurs disposent désormais d’outils pour limiter et nettoyer la table
• Malgré cela, les conditions pour en tirer bénéfice sont claires
  • Le volume de données doit être très important
  • Les mêmes données doivent être copiées en grand nombre
  • Il ne doit pas être possible d’utiliser d’autres options zero-copy d’OpenZFS, comme le block cloning ou les snapshot clones
• Pour les workloads où le client peut envoyer un signal explicite demandant de « copier », le block cloning peut apporter de gros bénéfices à moindre coût

[GN⁺]

Avis sur Hacker News

• Ce serait bien d’avoir une déduplication hors ligne, ou une déduplication différée qui ne nécessite pas de démonter entièrement le pool, mais ne s’exécute pas immédiatement
  Quand on active la déduplication, chaque écriture et chaque libération nécessitent une consultation et une écriture dans la table de déduplication, ce qui semble être une mauvaise approche dans la plupart des cas. Lorsqu’on écrit des données, on veut que cela se termine le plus vite possible, quitte à utiliser plus d’espace disque ; c’est pour cela qu’on ne stocke pas les fichiers sur lesquels on travaille dans une archive 7zip. Plus tard, quand le système est inactif, ce serait bien que ZFS trouve les données dupliquées et récupère l’espace avec quelque chose comme BRT ; cela pourrait aussi faire partie d’un scrub classique

  • La déduplication différée/hors ligne nécessite une réécriture des pointeurs de blocs, mais ZFS n’étant pas un vrai système CAS, il sera difficile d’obtenir un jour une véritable réécriture correcte des BP
    L’emplacement physique est haché dans l’arbre de hachage de Merkle, donc déplacer l’emplacement physique impose de réécrire tous les nœuds internes menant au nœud que l’on veut modifier, ce qui coûte beaucoup trop cher. Une meilleure conception aurait consisté à diviser tous les nœuds contenant un pointeur de bloc en deux parties : une partie avec uniquement un pointeur de bloc logique, hachée dans l’arbre, et une partie qui ne contiendrait que l’emplacement physique correspondant à ce pointeur logique, comme un cache, sans être hachée dans l’arbre de Merkle. Ainsi, une réécriture de BP ne nécessiterait de réécrire que les blocs qui ne font pas partie de l’arbre de Merkle. Avec la structure actuelle, il est difficile d’obtenir la fonctionnalité souhaitée dans ZFS, mais on pourrait peut-être la contourner ainsi : en cas de non-correspondance de hachage à la lecture, chercher le bloc dans la table de déduplication à partir du hachage du pointeur, puis réallouer le bloc dédupliqué. Le coût serait à peu près une lecture inutile, ce qui n’est pas si mauvais ; mais quand la réécriture de BP est impossible, on se retrouve généralement avec ce genre de rustines
  • Cette approche correspond à la méthodologie de déduplication Windows. Je l’ai beaucoup utilisée et, avec suffisamment de matériel, elle était globalement satisfaisante
    Elle consomme beaucoup de RAM et d’E/S, mais le « groveler » peut être planifié et limité. Cela dit, à l’époque de Windows 2012 R2, j’ai subi une corruption destructrice de données à cause d’un bug
  • On peut aussi faire cela avec un détecteur de fichiers dupliqués hors ligne
    Par exemple jdupes ou duperemove. J’ai envoyé des PR côté ZFS et côté duperemove pour prendre en charge les appels système nécessaires. La revue côté ZFS a pris longtemps, puis je me suis rendu compte que j’avais complètement oublié de finaliser le travail ; il faut que je m’en réoccupe
  • Dans ZFS, la capacité à modifier des snapshots existants est extrêmement limitée, même si les données sont entièrement préservées. Une telle fonction serait donc appréciable, mais si l’on attendait Block Pointer Rewrite, on serait déjà mort depuis longtemps
  • L’avantage de la déduplication inline, c’est que si le hachage du bloc existe déjà, il n’est pas nécessaire d’écrire réellement ce bloc
    Dans plusieurs situations, cela peut réduire fortement les E/S d’écriture. Certaines baies de stockage avec déduplication vont plus loin : lorsqu’on copie un fichier entre deux VM, les données réelles ne sont pas copiées, seul le compteur de références du bloc d’origine est incrémenté. Côté système d’exploitation, cela ressemble à des vitesses d’écriture absurdes en To/s, et c’est assez impressionnant

• L’affirmation selon laquelle « le problème fondamental de la déduplication traditionnelle est que cet overhead est si important qu’il est difficile à amortir, sauf pour des charges de travail rares et spécifiques » paraît assez étrange
  J’ai travaillé avec des baies Pure et Dell/EMC, et sur des charges VMWare, on obtenait généralement au moins 3:1 d’économie grâce à la déduplication/compression. Le fait de ne stocker qu’une seule copie d’une image VM de base fonctionne très bien. Même sur des serveurs syslog, j’ai vu des gains de 6:1 grâce à la déduplication/compression. L’efficacité de la déduplication dépend fortement de la taille des blocs hachés, et plus ils sont petits, mieux c’est. Plus les blocs diminuent, plus la probabilité d’obtenir des blocs identiques augmente rapidement ; d’après mon expérience, la taille de bloc que je préfère est 4 Ko

  • Les images VM sont des informations très redondantes, comme les disques C des images Windows Server qui sont presque identiques, alors que l’article prenait pour exemple le contenu d’un ordinateur portable personnel
    Il semble aussi mélanger deux fonctions différentes, la compression et la déduplication. Dans ZFS, on peut activer la compression sur un pool, ce qui vaut presque toujours le coup, tout en laissant la déduplication désactivée
  • Les images VM de base relèvent bien d’une charge de travail rare et spécifique, et font partie des rares cas où la déduplication a du sens
    Cela dit, si l’on héberge des VM sur un système de fichiers ZFS, on utilise probablement de meilleures stratégies, comme des clones au niveau des blocs ou du système de fichiers. Ne pas le faire revient à abandonner l’un des principaux différenciateurs de ZFS dans cet environnement. Pour un serveur de fichiers généraliste ou un poste/portable personnel, il y a généralement très peu de blocs dupliqués, et l’overhead ne vaut pas le coup. Pour les sauvegardes, cela peut fonctionner ou non selon l’implémentation et selon que le chiffrement intervient avant la couche du système de fichiers. La compression est une tout autre histoire, et la bonne pratique actuelle avec ZFS est de l’activer par défaut pour presque toutes les charges de travail. Aujourd’hui, le coût CPU est à peine notable et, indépendamment des économies d’espace, la réduction des E/S peut être importante. Pour un stockage de logs classique, d’après mon expérience, on peut obtenir des gains bien meilleurs que 6:1
  • Je ne l’ai pas vérifié moi-même, mais le chiffre souvent cité pour l’ancienne déduplication ZFS est qu’il faut 5 Go de RAM par To de disque
    Si l’on considère qu’aujourd’hui 1 To de disque coûte environ 15 dollars et 5 Go de RAM serveur environ 25 dollars, il faut déjà un taux de déduplication de 3:1 rien que pour atteindre le seuil de rentabilité. Si les données s’y prêtent bien, on peut peut-être s’en sortir avec 1 Go par To, mais avec moins de chance, même 5 Go peuvent ne pas suffire. C’est pourquoi l’article dit que la déduplication ZFS a un petit sweet spot où les données doivent parfaitement convenir, et c’est la raison pour laquelle la plupart des gens ne s’en préoccupent pas. Les autres systèmes de fichiers préfèrent généralement la déduplication hors ligne, dont l’économie est meilleure
  • Les VM sont un cas où les bénéfices de la déduplication sont connus, donc elle peut y être efficace. Mais ZFS n’est pas seulement un SAN d’entreprise : c’est un système de fichiers généraliste, et beaucoup d’utilisateurs de ZFS ne font pas tourner de VM
    Dire que la déduplication/compression fonctionne bien pour syslog mérite d’être nuancé : la déduplication et la compression ne sont pas la même chose. Dans le monde du stockage d’entreprise, elles sont souvent regroupées, mais les logs bénéficient probablement de la compression, pas de la déduplication, et ZFS dispose de la compression depuis l’origine
  • Il est évidemment logique de ne pas garder plusieurs copies profondes d’une image VM de base, mais dans ZFS, la déduplication n’est pas la bonne méthode
    Il vaut mieux cloner l’image de base : avant modification, cela ne consomme presque pas d’espace. C’est grâce à la nature copy-on-write de ZFS. La déduplication ZFS cherche à trouver des copies existantes des données écrites sur le volume. Pour certains usages, comme un dépôt d’images de conteneurs, cela peut avoir pas mal de sens ; mais si l’on sait déjà dès le départ qu’un dataset est un clone d’un autre, c’est très inefficace

• Autrefois, on utilisait largement la déduplication ZFS et on en tirait un grand bénéfice. L’usage concret était du stockage pour des clusters VMWare, avec des centaines de VM Linux et Windows dont le contenu était globalement identique. C’était avant Docker.

  • On voit ici plusieurs cas d’utilisation de la déduplication pour des VM, mais j’ai l’impression qu’il serait beaucoup plus efficace de l’implémenter au niveau de l’hyperviseur plutôt qu’au niveau du système de fichiers.
  • Je suis d’accord. J’ai récemment reçu un nouveau portable de travail avec le ZFS « experimental » d’Ubuntu, et utiliser la déduplication sur le nix store s’est révélé vraiment très utile.

• J’attends beaucoup de la déduplication rapide. Depuis des années, j’ai envie d’utiliser la déduplication ZFS pour mes données ArchiveBox ; grâce à la déduplication rapide, il semble enfin possible d’archiver des millions d’URL dans une seule collection et de laisser le système de fichiers gérer la compression globale.
  Dans les données d’archive, des éléments comme jquery.min.js, bootstrap.min.css ou des images de logo se retrouvent répétés dans des milliers de snapshots. D’autres outils compressent au sein d’un crawl pour produire des fichiers wacz ou warc.gz, mais aucun outil ne semble avoir tenté jusqu’ici de compresser à travers toute la base de données de tous les snapshots réalisés. Je me demande aussi si quelqu’un a déjà essayé une approche de déduplication probabiliste, avec quelque chose comme un Bloom filter, pour éviter de stocker telle quelle toute la table de hachage de déduplication. On regrouperait environ 100 hachages de blocs par bucket, et on stockerait une représentation ultra-compressée dans le Bloom filter. Lors de l’écriture, on interrogerait le Bloom filter avec le hachage du bloc à écrire ; si une possible correspondance de déduplication était détectée, on parcourrait directement les 100 blocs du bucket correspondant pour chercher un hachage identique. En théorie, on pourrait avoir plusieurs niveaux de Bloom filters à différentes résolutions et, en cas de forte pression mémoire, décharger dynamiquement les filtres haute résolution sur disque. En faisant de la précision du Bloom filter un paramètre réglable, on pourrait choisir ses préférences entre temps CPU/surcharge et ratio d’octets économisés.

  • Même avec ce changement, la déduplication ZFS reste fondée sur l’alignement des blocs ; si les ressources web répétées ne se trouvent pas toujours au même offset dans une archive WARC, ça ne fonctionnera probablement pas très bien.
    dm-vdo fonctionne de la même façon. À la place, il vaudrait peut-être mieux utiliser une compression solid qui examine de longues plages, extraire les fichiers WARC dans une structure proche d’un répertoire, ou utiliser un système FUSE fondé sur le content-defined chunking, s’il en existe un. Seafile fait peut-être cela.
  • Je comprends l’usage, mais dans la plupart des cas, et surtout dans celui-ci, il me semble que ce serait bien mieux de l’implémenter côté client.
    En regardant le standard WARC, il existe déjà un mécanisme de déduplication basé sur des hachages, qui utilise des pointeurs après le premier enregistrement. C’est donc exactement le genre de cas où la déduplication au niveau du système de fichiers n’est pas très adaptée.
  • L’usage est un peu différent, mais si tu ne connais pas zbackup, ça pourrait te plaire.

• Je me demande pourquoi il est si difficile de faire fonctionner correctement tout ça en réduisant l’usage de RAM. Les appliances de stockage commerciales y parviennent depuis au moins une dizaine d’années, même avec des systèmes disposant de “peu” de RAM par rapport à la capacité disque attachée.
  On pourrait simplement stocker les empreintes dans une base de données et parcourir le tout la nuit pour corriger les pointeurs de blocs, non ?

  • « Corriger les pointeurs de blocs », c’est justement la raison. Pour plusieurs raisons, ZFS n’a pas la capacité de réécrire les pointeurs de blocs.
    C’est une fonctionnalité demandée depuis longtemps ; si elle devenait possible, on pourrait aussi faire de la défragmentation. Je me suis demandé si une indirection des pointeurs de blocs, façon mémoire virtuelle, ne pourrait pas résoudre le problème au prix d’un léger coût en vitesse, mais je ne suis pas développeur ZFS et il y a sûrement quelque chose qui m’échappe. http://eworldproblems.mbaynton.com/posts/2014/zfs-block-poin... / https://github.com/openzfs/zfs/issues/3582
  • Corriger les pointeurs de blocs, c’est précisément la chose que ZFS ne voulait pas faire.
  • Il y a aussi la possibilité d’utiliser DragonFlyBSD et Hammer2. Hammer2 prend en charge la déduplication en ligne et hors ligne et ressemble beaucoup à ZFS à bien des égards.
    Son gros défaut est l’absence de protocole de transfert de fichiers utilisant RDMA. J’ai entendu dire qu’il existe aussi une branche expérimentale pour faire tourner Hammer2 sur FreeBSD. Mais FreeBSD ne prend pas non plus en charge RDMA. Dans FreeBSD 15, Chelsio a sponsorisé la prise en charge de cibles et d’initiateurs NVMe-oF, mais cela semble ne concerner que TCP.

• Il suffit d’utiliser cp --reflink=auto.
  On obtient une déduplication au niveau des fichiers. Cette commande effectue une copie légère ; comme avec un clone ZFS au niveau fichier, les blocs de données ne sont copiés que lorsqu’ils sont modifiés. Ce n’est pas un lien dur, mais une copie. La même approche devrait fonctionner avec d’autres systèmes de fichiers transactionnels en copy-on-write prenant en charge reflink.

• Je voulais vraiment utiliser ZFS, mais toutes les données devraient évidemment être chiffrées. Or son utilisation devient beaucoup plus complexe que prévu, et j’ai été surpris de voir que, quand les choses se compliquent, beaucoup de gens se contentent de ne pas chiffrer leurs données.
  Même Proxmox, avec “Enterprise” affiché sur son site web, m’a fait penser que le chiffrement serait pris en charge dans l’installation par défaut ; mais lorsqu’on veut l’utiliser avec le chiffrement, on perd des fonctionnalités importantes. Il faut absolument consulter aussi le gestionnaire d’issues. On y trouve quelques surprises qu’on ne s’attendrait pas à voir dans un système de fichiers de production.

  • La meilleure manière de chiffrer ZFS est de placer un ZFS non chiffré au-dessus d’un volume chiffré, par exemple un volume LUKS. Le “chiffrement” de ZFS laisse trop de choses en clair pour être rassurant.

• J’aimerais qu’il existe une API totalement différente pour les systèmes de fichiers. La surface d’API des systèmes de fichiers de tous les systèmes d’exploitation est un bazar complet, piégé par la rétrocompatibilité.

  • En interne, ZFS est fondamentalement un stockage objet. Il y a eu des travaux pour l’exposer via une API de stockage objet, mais malheureusement cela ne semble avoir mené nulle part.
    J’ai essayé de retrouver la présentation, sans succès. Je pensais l’avoir vue au Developer Summit, mais peut-être pas.
  • Pourquoi est-ce un bazar, et par quoi pourrait-on le remplacer ? Une API à la AWS S3 serait-elle une amélioration ?

• Oublie la déduplication : utiliser la compression ZFS offre un bien meilleur rapport coût/bénéfice.

  • Sauf si le dataset est composé de fichiers multimédias déjà fortement compressés.
    En général, même pendant les tâches rsync, on désactive souvent la compression pour les gros fichiers vidéo. La compression est peu efficace, voire inutile, pour le stockage ou le transfert, tout en consommant de la RAM et du CPU. La déduplication est utile pour les images d’OS de machines virtuelles, car la majeure partie du coût de stockage provient d’images de base répétées.

• La déduplication généraliste paraît séduisante en théorie, mais en pratique elle fonctionne souvent mal. IPFS utilise, comme rsync, des fragments de taille variable et des hash roulants pour dédupliquer les données, mais dans les faits cela ne change rien et ne fait qu’ajouter inutilement de la complexité