Forcer la mise à jour de la somme de contrôle sur zfs?

J'ai récemment changé la checksumpropriété de l'un de mes systèmes de fichiers zfs non dupliqués sha256de on(fletcher4) pour mieux prendre en charge l'envoi de vapeurs de réplication dupliquées, comme dans cette commande zfs send -DR -I _starting-snaphot_ _ending-snapshot_.

Cependant, la page de manuel zfs a ceci à dire sur send -D:

Cet indicateur peut être utilisé quelle que soit la propriété dedup de l'ensemble de données, mais les performances seront bien meilleures si le système de fichiers utilise une somme de contrôle compatible avec la déduplication (par exemple, sha256).

La page de manuel zfs indique également ceci à propos de la checksumpropriété:

La modification de cette propriété affecte uniquement les données nouvellement écrites.

Je n'ai aucune envie de faire confiance à fletcher4. Le compromis est que, contrairement à SHA256, fletcher4 n'est pas une fonction de hachage pseudo-aléatoire et ne peut donc pas faire confiance pour ne pas entrer en collision. Il ne convient donc pour la déduplication que lorsqu'il est combiné avec l'option «vérifier», qui détecte et résout les collisions de hachage.

Comment puis-je mettre à jour les sommes de contrôle du système de fichiers, de préférence sans déconnecter le système?

zfs zfsonlinux

— 84104
source

Pour modifier les propriétés (que ce soit la compression, la déduplication ou la somme de contrôle) des données déjà écrites, l'approche zfs consiste à exécuter les données via une zfs send | zfs receiveséquence. De toute évidence, vous n'avez pas besoin de déconnecter le système pour cela, mais vous aurez besoin

suffisamment de ressources dans votre zpool / sur le système pour contenir deux copies dédupliquées de l'ensemble de données en question
temps d'arrêt de l'ensemble de données, car vous devrez soit le détruire, soit le renommer dans la procédure
assez de temps et de patience pour terminer l'opération

Comme vous utilisez déjà la déduplication pour le zpool, l'exécution d'un zfs send | zfs receiveavec la destination sur le même pool que la source n'utiliserait que l'espace requis pour les blocs de métadonnées nouvellement écrits. Mais préparez-vous à ce que la copie prenne un certain temps - la déduplication peut être extrêmement lente, surtout si vous n'avez pas assez de RAM pour contenir toute la table de déduplication dans la RAM.

Il est évident que vous devrez interrompre toutes les opérations d'écriture pour créer la copie finale faisant autorité de l'ensemble de données, mais vous pourriez minimiser le temps d'arrêt en copiant d'abord un instantané, en arrêtant toutes les écritures et en faisant incrémentiel zfs send -i | zfs receivecomme étape finale.

— le-wabbit
source

Il n'est pas du tout clair pour moi de mettre à zfs receivejour les métadonnées d'un système de fichiers. Il me semble qu'il serait beaucoup plus rapide de simplement prendre les métadonnées telles quelles. Cependant, cela peut être impossible en raison du bloc de la somme de contrôle, plutôt que de la nature du niveau du fichier. Dans ce cas zfs send | zfs receive, constituerait une base acceptable pour une solution.

— 84104

zfs envoyer | zfs recv modifiera efficacement toutes les métadonnées (choix de compression, choix de somme de contrôle, choix de déduplication). zfs send crée un objet que vous ingérez ensuite à l'aide de zfs recv, ce qui l'écrit à peu près comme s'il s'agissait de nouvelles données. Cependant - je pense que vous pouvez avoir une idée fausse au sujet de zfs send | recv en ce qui concerne la déduplication. zfs send -D tente de dédupliquer les données / dans le flux lui-même /, sans conserver la déduplication existante des données de l'ensemble de données source. C'est pourquoi il n'est pas nécessaire que le côté recv ait également la déduplication activée sur l'ensemble de données de destination.

— Nex7

Pour expliquer davantage - il n'y a actuellement aucun moyen d'envoyer zfs | recv des données dédupliquées de telle manière que tout ce qui passe à travers le câble est une seule copie des données dédupliquées et des entrées de table de déduplication associées. Pas même si la source et la destination sont synchronisées et que vous n'envoyez rien de plus qu'un instantané incrémentiel. ZFS continue de gonfler les données d'envoi jusqu'à leur taille maximale si les données qu'il contient s'avèrent non déduplicables / dans la portée du flux lui-même /. Vous pouvez avoir des données qui sont facilement dédupliquées dans le POOL DDT, mais en tant que petit objet d'envoi, être complètement non déduplicable.

— Nex7