Journal Enlarge your ZFS pool

Posté par  (site web personnel) .
Étiquettes : aucune
12
3
nov.
2009
Cher Journal,

Alors qu'on supposait que ZFS is dying en même temps que BSD (voir journaux récents), voilà juste l'annonce d'une fonction de déduplication dans ZFS :

http://blogs.sun.com/bonwick/entry/zfs_dedup

Je vous fais une traduction rapide et approximative.
«
La déduplication consiste en l'élimination des copies de données. Elle se fait généralement soit niveau d'un fichier, d'un bloc ou de l'octets. Les morceaux de données -- fichiers, blocs ou octets donc -- sont hachées pour identifier les morceaux de manière unique.

Ces morceaux de données sont stockées dans une table qui pointe vers l'endroit de stockage et un compteur de références. Quand des copies des données sont à nouveau stockées, la déduplication incrémente seulement le compteur de références sur les données existentes au lieu d'allouer un nouvel espace de stockage.

Quand les données sont hautement dupliquées, ce qui est typique de serveurs de sauvegardes, d'image de machine virtuelles ou bien de dépots de code sources ; la déduplication peut réduire la consommation de l'espace de stockage d'un facteur multiple.

...

ZFS fourni une déduplication au niveau du bloc parce que c'est la granularité la plus fine ayant un sens pour un système de stockage.
»

Voilà je vous laisse lire l'article si vous voulez en savoir plus.
C'est chouette non ?

  • # ZFS fsck

    Posté par  (site web personnel) . Évalué à 6.

    http://www.osnews.com/story/22423/Should_ZFS_Have_a_fsck_Too(...)

    Un autre article sur ZFS qui expliquer pourquoi ce dernier ne possede pas de fsck et pourquoi c'était(est) une ereur.

    • [^] # Re: ZFS fsck

      Posté par  (site web personnel) . Évalué à 6.

      Et le pire c'est que ce n'est pas à cause d'un problème de ZFS lui-même, mais bien à cause de certain disques bas de gamme qui "mentent" à propos de leur utilisation du cache en écriture. Ce qui fait que ZFS pense faire un Copy On Write propre, alors que physiquement sur le disque ce n'est pas immédiatement le cas.
      Je n'irais pas jusqu'à dire que l'absence de fsck dans ZFS est une erreur, mais au vu des pratiques de certains constructeurs de disques, le fsck est une nécessité pour pallier à ce genre de problème qui est uniquement dû à du mauvais matériel.

      • [^] # Re: ZFS fsck

        Posté par  . Évalué à 5.

        Tu as des marques/modèles des disques durs en question ?
        Il n'y a pas une multitude de constructeurs aujourd'hui (Seagate, WD, Hitachi, Samsung, Maxtor racheté par je sais plus qui et ?), et vu que sur le plan des perfs, ils se valent à peu près, idem sur le plan de la fiabilité (comprendre que ça dépend des modèles/séries...), il serait intéressant d'avoir d'autres critères de choix.

    • [^] # Re: ZFS fsck

      Posté par  (Mastodon) . Évalué à 3.

      Ce n'est pas parce que Pobrecito Hablador, an anonymous open source hobbyist, a décidé de perdre quelques minutes de son lundi pour pondre un article sur osnews que ça invalide l'argument de sun et des spécialistes dans le domaines des filesystems qui l'ont développés.

      Ayant vécu l'expérience d'un zpool zfs d'environ 20TB corrompu (en l'occurence à cause d'un bug sur les driver sata + disque qui pète + bug zfs sur une vieille release), je peux te dire que le fsck aurait de toute façon été un vrai cauchemard et ne m'aurait pas assuré d'avoir des données consitantes. Au final récupérer les données à partir d'un backup, ou mieux dans mon cas depuis une machine redondante distante est une bien meilleure solution.

      Donc personnellement, même ayant vécu un cas de théoriquement imposible, je ne vois pas vraiment l'intérêt d'un fsck. De toute manière si tu n'as pas de backups valides et restorables rapidement, ni de redondance dans tes machines et espaces de stockages, c'est que tu t'en fous de tes données. Donc je ne vois pas ce que le fsck t'apportes de plus.

      • [^] # Re: ZFS fsck

        Posté par  . Évalué à 1.

        Vas dire ça à ovh, ils ont été obligés de patcher zfs pour récuperer le FS.
        Celui ci était corrompu (biensûr la réponse de sun a été que c'était impossible) et pas de fsck...

        (ça doit être encore sur travaux.ovh.com)

        • [^] # Re: ZFS fsck

          Posté par  . Évalué à 5.

          ils avaient pas de sauvegardes ? [:kiki]

        • [^] # Re: ZFS fsck

          Posté par  (Mastodon) . Évalué à 2.

          s'ils ont récupéré le pool après patch du code zfs dans opensolaris ou solaris, c'est que le problème venait des binaires zfs pas du pool, donc que le pool n'était pas corrompu mais juste qu'on n'arrivait pas à accéder aux données normalement.

          S'il était vraiment corrompu, le patching du code aurait juste évité d'avoir de nouvelle corruptions mais n'aurait pas pu récupérer des données.

          Enfin j'aimerais voir le détail du problème, mais fouiller dans travaux.ovh.com alors qu'il n'y a pas d'outil de recherche, ça ne m'amuse guère :)

    • [^] # Re: ZFS fsck

      Posté par  . Évalué à 7.

      oui non c'est très caca en fait comme article.

      l'auteur semble croire qu'un fsck lui permettrait de systématiquement sauver ses fesses parce bah euh sous ext3fs et autres, le fsck correspondant lui a déjà sauvé ses fesses une paire de fois. du coup, pendant tout l'article il se contente de réclamer un fsck sans même trop savoir ce qu'il y aura dedans. il faut un fsck parce que... parce que... parce que ! il en faut un, c'est tout !

      il a l'air de le considérer comme un outil magique, un mot magique en fait, un peu comme madame Michu avec les antivirus qui va forcément les arrêter TOUS. "plus rien ne va m'arriver maintenant puisque j'ai un antivirus !"

      alors oui un outil de diagnostic et récupération de données dédié à ZFS ça servira toujours à quelque chose, oui des fois il y aura des métadonnées incohérentes ici ou là et cet outil permettra de limiter la casse là où ZFS aura jeté l'éponge (à raison) ET où les vilains utilisateurs n'auront pas de sauvegardes décentes. des fois on pourra même sauver le filesystem et le garder en production parce que les trois fichiers perdus étaient des fichiers temporaires sans importance et que tout le reste est cohérent... et des fois, non.

  • # Ou pour du mail !

    Posté par  . Évalué à 4.

    Un mail avec fichier attaché envoyé à tout le personnel de la boite ? Un seul mail stocké !

    Vive ZFS

    • [^] # Re: Ou pour du mail !

      Posté par  (site web personnel) . Évalué à -1.

      L'en tête n'est pas le même... Le champ "Envelope-to" change pour chaque destinataire.

      Bref, c'est une belle idée mais je ne sais pas ce qu'elle fait réellement gagner en pratique.

      • [^] # Re: Ou pour du mail !

        Posté par  (site web personnel) . Évalué à 1.

        Et bien de ce que j'ai compris de l'article du blog cité, la fonction "dedup" en mode block serait quand même dans ce cas très efficace. En effet le corps du mail et l'éventuelle pièce jointe étant identiques, les blocks correspondants ne seraient pas dupliqués.

        J'ai hâte que Pawel Jakub Dawidek porte cette fonction de ZFS sous FreeBSD du coup ;)

        Allez il ne reste plus que la crypto, le fsck et l'outil de défrag, et ZFS sera le système de fichiers ultime.

        • [^] # Re: Ou pour du mail !

          Posté par  . Évalué à 4.

          La taille de l'en-tête n'étant pas identique (un seul octet suffit), toute la suite est décalée. Donc le hachage n'est pas identique. Donc pas de déduplication.

          La déduplication "basique" au niveau des bloc ne sert que dans des cas réduits. Les sauvegardes de multiples machines par exemple. Et même dans ces cas, il est mieux d'avoir une déduplication plus fine. Ca coûte juste cher en temps machine et en espace disque pour stocker les clefs :-)

          • [^] # Re: Ou pour du mail !

            Posté par  (site web personnel) . Évalué à 2.

            Je me trompe peut-être mais ce comportement n'existe-il pas plutôt dans le cas de la déduplication en mode fichier ? Et que justement le mode bloc est utile dans le cas de petites différences entre de gros fichiers ?

            • [^] # Re: Ou pour du mail !

              Posté par  (site web personnel) . Évalué à 2.

              Après avoir relu l'article donné en lien il semble plutôt que pour les e-mails avec pièces jointes ce soit la déduplication niveau "octet" qui soit efficace. Mais elle semble aussi la plus gourmande en ressources.

      • [^] # Re: Ou pour du mail !

        Posté par  (Mastodon) . Évalué à 1.

        dedup par block. Il n'y aura que les blocs correspondants à l'enveloppe qui seront dupliqués, le corps du message lui ne sera stocké qu'une fois.

        • [^] # Re: Ou pour du mail !

          Posté par  (site web personnel) . Évalué à 3.

          Un mail est un mail, il n'y a qu'un seul fichier qui est répartis sur 1 ou plusieurs blocs. Le fichier commence par l'en tête et celui-ci sera différent pour chaque personne. Ensuite, comme dis plus haut, le décalage se poursuit pour tous les block suivants, qu'il y ait des pièces jointes ou pas.

          • [^] # Re: Ou pour du mail !

            Posté par  (site web personnel) . Évalué à 3.

            Un mail est transféré de cette façon.
            Après, pour le stockage, c'est très variable: 1 mail un fichier dans un maildir, une grosse mailbox, une base de données... et si quelqu'un veut optimiser pour un système de stockage comme présenté, on pourrais avoir un stockage séparé en-têtes/contenu, alors la redondance bloc aurait toute son utilité.

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # Collisions

    Posté par  (site web personnel) . Évalué à 3.

    Avec une telle utilisation des hashs, est-ce qu'on ne risque pas d'avoir des collisions? La conséquence serait catastrophique...

    • [^] # Re: Collisions

      Posté par  . Évalué à 2.

      L'article dit que la probabilité de collision est de 2^-256 ~= 0.00000000000000000000000000000000000000000000000000000000000000000000000000001

      • [^] # Re: Collisions

        Posté par  (Mastodon) . Évalué à 4.

        et pour des données sensibles, on peut ajouter l'option verify qui va le comparer avec au moins la première itération (la seule donc logiquement) du bloc en question déjà présent. Il y'a bien sûr un overhead mais ça c'est normal.

        • [^] # Re: Collisions

          Posté par  (site web personnel) . Évalué à 2.

          Pourquoi ne pas avoir mis cette option par défaut ?

          L'overhead sur quelque chose qui arrive une fois sur 2^256, c'est acceptable.

          Par contre si on compare 2^-256 au nombre de blocks de tous les fs en zfs dans le monde, alors le risque qu'une personne dans le monde ait des collisions n'est pas négligeable.

          Je trouve ça dommage de prendre un tel risque pour un désagrément aussi minime.

          • [^] # Re: Collisions

            Posté par  (Mastodon) . Évalué à 3.

            Pourquoi ne pas avoir mis cette option par défaut ?

            euh...la déduplication elle-même est désactivée par défaut.

            Quand tu te pose la question d'appliquer la déduplication sur un filesystem, tu va pas juste t'amuser à faire un zfs set dedup=on et attendre de voir ce qu'il se passe. En général tu lis la doc. Et la tu tomberas tout de suite sur les options possibles. Personnellement, je ne vois pas vraiment ou est le risque de rater ce point important.

            D'autre part, pour l'instant c'est juste du code sur un svn, ce code n'a pas encore été inclus dans une release ou build officielle de opensolaris, et encore moins de solaris. Beaucoup d'eau pourra avoir coulé sous les ponts entre temps.

            • [^] # Re: Collisions

              Posté par  . Évalué à 4.

              euh...la déduplication elle-même est désactivée par défaut. Oui, bien vu. C'est moins effrayant comme ça.

              Cependant, pourquoi ne pas le mettre par défaut quand la déduplication est activée ?

              Je sais bien que tu te dis que : Quand tu te pose la question d'appliquer la déduplication sur un filesystem, tu va pas juste t'amuser à faire un zfs set dedup=on et attendre de voir ce qu'il se passe. En général tu lis la doc. Et la tu tomberas tout de suite sur les options possibles. Personnellement, je ne vois pas vraiment ou est le risque de rater ce point important.
              Ça c'est dans un cadre idéal.

              Dans la vraie vie, toutes les entreprises ne voient pas à long terme et imposent des deadlines style « ça doit être fait pour hier ».

              Un exemple anodin
              « Dev : Le repo svn est plein, on ne peux plus commiter.
              - Admin : Forcément, on n'a pas fait de tests de métrologie avant et vous avez augmenté votre consommation de façon exponentielle. Et le budget pour racheter des disques nous a été refusé
              - N+1 ben vous avez qu'à utiliser la déduplication j'ai vu ça sur 01 informatique, ça a l'air bien. Il faut que ce soit près dans la journée pour ne pas bloquer la prochaine mise en production de notre produit phare. »

              Ça marche aussi pour les particuliers. Quand l'ami d'un ami dira que c'est de la balle dedup parce qu'on gagne plein de place, l'ami en question pourra très bien chercher dedup sur un forum et mettre ça en place sans regarder la doc (pas la peine de la lire, l'ami en question lui a expliqué alors il connait bien).

              Des exemples de ce style, on peut les multiplier à l'envi. C'est sûr, on peut critiquer le N+1 ou l'ami idiot. Mais ça ne coute rien de mettre cette option par défaut et de proposer une option pour le désactiver uniquement à destination des personnes qui lisent la doc avec la mention « attention n'activez cette option que si vous savez ce que vous faites ».

              C'est comme ça que ça fonctionne d'habitude il me semble, et ça me parait bien plus sûr.

              • [^] # Re: Collisions

                Posté par  (Mastodon) . Évalué à 1.

                Ça c'est dans un cadre idéal.

                Dans la vraie vie, toutes les entreprises ne voient pas à long terme et imposent des deadlines style « ça doit être fait pour hier ».

                Un exemple anodin
                « Dev : Le repo svn est plein, on ne peux plus commiter.
                - Admin : Forcément, on n'a pas fait de tests de métrologie avant et vous avez augmenté votre consommation de façon exponentielle. Et le budget pour racheter des disques nous a été refusé
                - N+1 ben vous avez qu'à utiliser la déduplication j'ai vu ça sur 01 informatique, ça a l'air bien. Il faut que ce soit près dans la journée pour ne pas bloquer la prochaine mise en production de notre produit phare. »

                Dans la vrai vie, si tu travailles bien tu sais dire non à ton chef. En tout cas c'est comme ça que je fais et on ne m'a jamais viré parce que je ne voulais pas utiliser une techno non testée sans avoir lu la doc ni testé un minimum.

                (pis en général, même sans pousser le capacity planning à fond, on surveille ses FS et on n'apprends pas au dernier moment que le repo svn est plein)

          • [^] # Re: Collisions

            Posté par  . Évalué à 6.

            Par contre si on compare 2^-256 au nombre de blocks de tous les fs en zfs dans le monde, alors le risque qu'une personne dans le monde ait des collisions n'est pas négligeable.

            Si. Et heureusement pour tous les utilisateurs de cryptographie dans le monde (256 bits, la taille de clef recommandée... ). Les cryptologues estiment qu'une quantité de données de 2^64 bits est difficilement atteignable par quiconque actuellement, ça laisse du temps !

            Une autre raison est la suivante : il y a environ 10^77 atomes dans l'univers, soit 2^255. Comme la Terre représente une partie infime de l'univers (il y a environ 10^50 atomes dans la Terre, 10^27 fois moins ! ), on a encore de la marge !

            (notons toutefois qu'une fonction de hachage sur 256 bits aura des collisions sitôt 2^128 blocs utilisés et non pas 2^256, à cause du paradoxe des anniversaires)

      • [^] # Re: Collisions

        Posté par  . Évalué à 7.

        Sur deux morceaux spécifiques pris isoléments. Sur tout un disque, il faut tenir compte du Paradoxe_des_anniversaires je pense.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # Dans linux aussi (avec le patch vserver).

    Posté par  . Évalué à 3.

    Il y a ça dans linux aussi, intégré au patch linux-vserver.org

    Des hash sont calculé par un script qui fait des liens physiques , des attributs sont placés pour gérer la modification (casser le lien symbolique).

    Plus d'infos:
    man chattr
    http://linuxfr.org/~alenvers/28224.html
    http://linux-vserver.org/Paper#Unification

  • # Ça à l’air bien…

    Posté par  . Évalué à 2.

    pourtant, je me pose une question pratique.
    Supposons qu’il me reste 8Go sur une partition, que pour faire de l’édition vidéo, je copie un film de 5Go, car je veux garder l’original. Tous les blocs sont identique, donc place restante : 8Go. Sur ma copie, j’insère quelques incrustes. Il me reste 7.5Go (je ne touche pas à l’ensemble du film).
    Maintenant je télécharge les dernières séquences depuis mon caméscope pour 4Go. Il me reste 3.5Go.
    Maintenant, si je veux remettre un © sur l’ensemble de mon film il va me manquer 1Go, alors que j’altère juste un fichier déjà existant.

    $ df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/super 25G 45G 10G 145% /home

    Y-a-t-il que moi qui soit choqué ?

    • [^] # Re: Ça à l’air bien…

      Posté par  (site web personnel) . Évalué à 3.

      Y-a-t-il que moi qui soit choqué ?

      Oui :-)
      C'est pas nouveau ce genre de choses, sous Unix on utilise en général des fichiers « à trou ». Tu n'as pas la garantie qu'un fichier tienne sur le disque. Bien sûr cela peut poser des problèmes.

      $ df -h
      Filesystem Size Used Avail Capacity Mounted on
      tank/home 24G 14G 11G 56% /home

      $ dd if=/dev/zero of=big bs=1 count=0 seek=100G
      $ ls -lah big
      -rw-r--r-- 1 patrick patrick 100G 3 nov 14:08 big

      $ df -h
      Filesystem Size Used Avail Capacity Mounted on
      tank/home 24G 14G 11G 56% /home

      les pixels au peuple !

      • [^] # Re: Ça à l’air bien…

        Posté par  . Évalué à 1.

        Soit, mais dans mon exemple il s’agit bien d’un fichier « sans trou », que j’ai volontairement pas « hard linké ».

        • [^] # Re: Ça à l’air bien…

          Posté par  (site web personnel) . Évalué à 3.

          Soit, mais dans mon exemple il s’agit bien d’un fichier « sans trou », que j’ai volontairement pas « hard linké ».

          D'accord, mais la problématique est la même : tu n'as pas un 'filesystem full' tout de suite à la copie du fichier. Mais plus tard, à l'utilisation. Et oui ça pose problème.

          Je ne connais pas de solution pour ça à part avoir de la place disque disponible. Mais est-ce un réel problème si d'un autre coté et statistiquement tu gagnes de la place de stockage ?

          Tu peux avoir ce genre de gag avec des snapshots aussi, si tu modifies un fichier, il faut stocker les données d'origines dans le snapshot et les données écrites dans le fichier. Si tu n'as pas la place pour le faire ça ne marche pas, et la dessus df ne t'aidera pas plus.

          Perso ça me choque pas plus que ça. J'ai toujours pensé que l'espace disque dispo est une approximation. D'ailleurs, qui n'est pas tombé comme un con en manque d'inode alors qu'il y a plein de place sur le disque ?

          les pixels au peuple !

          • [^] # Re: Ça à l’air bien…

            Posté par  . Évalué à 5.

            Je comprends bien l’intérêt, ce qui me gène, c’est la prédictibilité.

            C’est un peu comme la stratégie d’allocation mémoire de Linux.

            man malloc
            « BOGUES

            Par défaut, Linux suit une stratégie d'allocation optimiste. Ceci signifie que lorsque malloc () renvoie une valeur non-NULL, il n'y a aucune garantie que la mémoire soit véritablement disponible. C'est vraiment un bogue craignos. Dans le cas où le système manque de mémoire, un ou plusieurs processus seront tués par l'infâme exterminateur de gestion mémoire. Dans le cas où Linux est utilisé dans des circonstances où il n'est pas souhaitable de perdre soudainement des processus lancés aléatoirement, et si de plus la version du noyau est suffisamment récente, on peut désactiver ce comportement en utilisant une commande du style : # echo 2 > /proc/sys/vm/overcommit_memory Voir également les fichiers vm/overcommit-accounting et sysctl/vm.txt dans le répertoire de la documentation du noyau.  »

            J’ai eu le problème en entreprise, où sur un serveur de session avec 16Go de RAM, les éditeurs de code, session était killé aléatoirement. L’admin n’a jamais voulu faire la manip décrite.

            Ce que j’aime pas c’est le côté loto des choses.

  • # déduplication

    Posté par  . Évalué à 5.

    j'allais proposer le terme factorisation à la place de Déduplication qui me semble correspondre assez bien au concept, et en vérifiant avant de poster, je me rend compte que bien que wikipedia soit d'accord sur le principe, apparemment ça a l'air d'etre un terme qui se répand (mais que je ne connaissais pas)

    http://fr.wikipedia.org/wiki/Déduplication (peux pas faire mieux comme lien, désolé)

    déduplication (également appelée factorisation ou stockage d'instance unique)

    (en tout cas, il n'est pas dans le dico linuxfr)

  • # Wow

    Posté par  . Évalué à 6.

    Classe, vraiment.
    Ca c'est une chouette fonctionnalité pour un FS. Vraiment.
    Au boulot ,nous utilisons la deduplication pour nos backups (c'est la ou ca marche le mieux) et on arrive a des gains de place de l'ordre de 400 a 500% (oui oui, ca prend 5 a 6x moins de place qu'un stockage sans dedup).
    Certains arrivent a des gains de 20x !

    Bref, la dedup, c'est bon, mangez en...

    En tout cas, une techno comme celle la est une tuerie pour le Libre.

    • [^] # Re: Wow

      Posté par  (site web personnel) . Évalué à 2.

      J'utilise moi aussi backuppc et les gains sont très faible ;-( Enfin, j'en conclue que mes chercheurs cherchent et que pas grand monde copie sur le voisin !

      Sinon, je ne vois pas l'intérêt d'avoir des backup complet et incrémentaux dans backuppc. Cela prends du temps pour rien. Pourquoi ne pas avoir que des backup incrémentaux et mettre à jour la dernière version comme version complète.

      • [^] # Re: Wow

        Posté par  . Évalué à 1.

        Je n'utilise pas backuppc... :)

        Sinon, pour info, la technique de transformer une incrementale en complete s'appelle "faire une sauvegarde synthetique". Du moins, c'est le nom le plus communement utilisé pour cela (chaque editeur a bien entendu son petit terme marketing a 3 Francs 6 sous).

        Quoiqu'il en soit, la deduplication, c'est pas la meme chose que faire une incrementale. Ca va beaucoup plus loin et c'est beaucoup plus puissant.

        • [^] # Re: Wow

          Posté par  (site web personnel) . Évalué à 1.

          Backuppc et rsnapshot, comme autre exemple, font déjà la deduplication au niveau fichier en faisant un usage intensif des hardlinks...

          Pour ces deux outils de sauvegardes (vers disques) il est probable que la déduplication au niveau block de ZFS n'apporte pas grand chose (sauf dans le cas où on aurait plein de fichiers qui commencent pareil, mais finissent autrement).

          • [^] # Re: Wow

            Posté par  . Évalué à 1.

            Non, la "deduplication" au niveau fichier est tres loin d'etre aussi performant que la dedup au niveau bloc.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.