Sortie de Gzip 1.6

Posté par . Édité par Nils Ratusznik, Xavier Teyssier et Benoît Sibaud. Modéré par Xavier Claude. Licence CC by-sa
Tags : aucun
46
11
juin
2013
GNU

GNU Gzip est une suite d'utilitaires de (dé)compression de fichiers utilisés par toutes les distributions GNU/Linux et dans divers environnements UNIX. Ce lundi 10 juin est sortie une nouvelle version de Gzip, dénommée gzip-1.6. Cette version apporte les nouvelles fonctionnalités et corrections de bogues suivantes :

  • gzip accepte maintenant l'option --keep (-k), par souci de cohérence avec les outils comme xz, lzip et bzip2. Avec cette option, gzip ne supprime plus le fichier source lors d'une compression ou d'une décompression ;
  • gzip -d ne dysfonctionne plus avec certaines données invalides au format « pack » (problème introduit dans gzip-0.8]) ;
  • lors d'un écrasement, et avec certaines plateformes où il est compilé de façon optimisée, gzip n'agit plus comme si vous aviez tapé « y » lorsque vous tapez « n ». (bogue présent depuis gzip-1.3.6) ;
  • zgrep ne dysfonctionne plus avec des options multi-chiffres comme -15 (équivalente à -C15). Maintenant il passe cette option à grep comme il le fait pour les options à un chiffre (problème vu depuis gzip-1.3.12) ;
  • dorénavant, zmore se comporte plus comme more et est plus portable pour les hôtes POSIX.
  • # Merci

    Posté par . Évalué à  10 .

    J'aurais pensé qu'ils allaient ajouter de quoi faire de la (dé ?)compression en parallèle comme le permet pigz.

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Merci

      Posté par . Évalué à  8 .

      pigz permet seulement la compression parallèle, le gain de temps sur de gros fichier est très important… J'ai mesure un x12 sur un fichier d'1To sur un 32 CPUs la saturation venant de l’accès disque.

      La décompression prend un temps du même ordre de grandeur que gzip.
      Et le format a pour l'instant toujours été compatible.

      • [^] # Re: Merci

        Posté par . Évalué à  4 .

        Il faut comprendre que la décompression ne tire pas de bénéfice du parallélisme, c'est ça ? Cela sature les IO avant le CPU, c'est ça ?

        • [^] # Re: Merci

          Posté par . Évalué à  3 .

          J'ai lu un article récemment sur pigz où il était écrit que la décompression tire des bénéfices du parallélisme du moment que l'archive ait été préalablement compressé dans les mêmes conditions (cad en multi-coeur) (et c'est vrai que pigz en multi-coeur ça déménage…). Mais bon là on parle de gzip non ?

    • [^] # Re: Merci

      Posté par (page perso) . Évalué à  6 .

      quoi faire de la (dé ?)compression en parallèle

      Si le sujet intéresse, un fil sur FreeBSD-hackers (SMP version of tar) décrit assez bien la problématique http://lists.freebsd.org/pipermail/freebsd-hackers/2012-October/040632.html

  • # Déjà un paquet pour FUN PLUG

    Posté par (page perso) . Évalué à  2 .

    Hello,

    Pour ceux qui ont un NAS et qui ont installé Fun Plug dessus (voir fun_plug)

    J'ai déjà compilé un petit paquet pour slacker (ffp 0.7 EABI) : gzip-1.6-arm-1.txz

    Pour ceux qui veulent tester ;)

    Fréd.

    • [^] # Re:Déjàun paquet pour FUN PLUG

      Posté par (page perso) . Évalué à  3 .

      Pour ceux qui ont un NAS et qui ont installé Fun Plug dessus (voir [fun_plug][1])

      Ton lien n'explique pas ce que c'est.

      • [^] # Re:Déjàun paquet pour FUN PLUG

        Posté par (page perso) . Évalué à  4 .

        Oui effectivement…

        Fun_Plug est la possibilité pour la plupart des NAS vendu sur le marché d'exécuter un script au démarrage du serveur avec les droit ROOT.
        ce script est généralement appelé fun_plug et placé à la racine du disque dur.

        de la a été créé ffp un ensemble de script qui ajoute uclibc ainsi que pas mal de librairies et petit programme, notamment telnet et ssh en premier lieu.
        voir ici : ffp

        je maintient un dépot avec les logiciels que j'utilise.
        http://ffp.memiks.fr/pkg (pour les noyaux récent en EABI)
        http://ffp.memiks.fr/pkg/oarm/ (pour les noyaux OABI)

        Fred.

  • # Par rapport à xz ?

    Posté par . Évalué à  3 .

    Et quel est l'intérêt de Gzip par rapport à XZ ?
    La vitesse de compression/décompression ?
    Parce qu'il est le plus répandu (enfin, je suppose) ?

    Merci d'avance.

    • [^] # Re: Par rapport à xz ?

      Posté par (page perso) . Évalué à  1 . Dernière modification : le 11/06/13 à 22:46

      Gzip compresse et décompresse plus vite et en prenant moins de ressources systèmes que XZ, qui est un monstre niveau utilisation mémoire/CPU et qui est surtout bien plus lent que Gzip.

      XZ ne devrait donc être utilisé que lorsque c’est absolument nécessaire (lorsque la taille de l’archive doit vraiment être réduite au minimum). D’ailleurs je me demande si c’était une bonne idée de passer au tar.xz pour les paquets d’Arch Linux (j’ai l’impression que les paquets mettent plus longtemps à s’installer).

      Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Par rapport à xz ?

        Posté par (page perso) . Évalué à  8 .

        Si pour la mémoire, c'est vrai, le temps de décompression est seulement un facteur 2 par rapport à gzip http://pokecraft.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO#Decompression_time

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Par rapport à xz ?

          Posté par (page perso) . Évalué à  3 .

          Ah cool, tu as trouvé le document qui m’a justement appris un peu ce que valais les différents algorithmes de compression/décompression.

          En tout cas un rapport 2 c’est énorme. Ce qui compte c’est que ça compresse bien et rapidement. Gzip est un bon compromis entre lenteur et taux de compression. XZ est dans l’extrême du taux de compression.

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Par rapport à xz ?

            Posté par (page perso) . Évalué à  10 .

            En tout cas un rapport 2 c’est énorme.

            Ça dépend beaucoup ce que tu fais.

            Ce qui compte c’est que ça compresse bien et rapidement.

            Non. Ce qui compte, c'est que ça décompresse bien et rapidement. Pour tout ce qui est distribué, comme les paquets Arch, le temps de compression a peu d'importance, c'est le temps de décompression qui l'est (pour la compression à la volée comme en HTTP ou l'hibernation, c'est autre chose évidemment).

            Un point que ce benchmark ne montre pas (vu qu'il fait tout en ramdisk), c'est le temps gagné en accès disque avec des fichiers plus petits à décompresser (mais c'est peut-être négligeable, je ne sais pas, et ça dépendra énormément du type de disque).

            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Par rapport à xz ?

              Posté par (page perso) . Évalué à  10 .

              Pour compléter, avec une ligne à 2 Mo/s, ce qui fait du 16Mbps, on gagne 17 secondes lors du téléchargement pour en perdre 3,5 lors de la décompression, au final, on est gagnant sur le temps total.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Par rapport à xz ?

                Posté par (page perso) . Évalué à  3 .

                Pour compléter, avec une ligne à 2 Mo/s, ce qui fait du 16Mbps, on gagne 17 secondes lors du téléchargement pour en perdre 3,5 lors de la décompression, au final, on est gagnant sur le temps total.

                J’ai une connexion de merde ET une machine de merde. Je suis sans doute gagnant mais pas de beaucoup… Parce que le 3,5 sorti de nulle part c’est bien joli mais c’est sur quelle machine?

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Par rapport à xz ?

                  Posté par (page perso) . Évalué à  4 .

                  c’est bien joli mais c’est sur quelle machine?

                  C'est précisé dans les conditions de test : Intel Core i5 CPU 750 at 2.67GHz

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                  • [^] # Re: Par rapport à xz ?

                    Posté par (page perso) . Évalué à  2 .

                    Ah tu reprenais le test…

                    Bon je suis toujours largement gagnant mais c’est bien d’avoir des points de repères.

                    Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Par rapport à xz ?

              Posté par (page perso) . Évalué à  2 .

              En tout cas un rapport 2 c’est énorme.

              Ça dépend beaucoup ce que tu fais.

              Ce que je veux dire c’est que lorsque tu en es à pinailler sur l’algorithme de compression c’est que tu dois avoir un/des fichiers d’une taille importante déjà, donc où le temps de compression compte pas mal.

              Non. Ce qui compte, c'est que ça décompresse bien et rapidement.

              J’avais en tête le partage de fichiers par courriel, mettre les pièces jointes une par une c’est juste l’enfer, les limitations de taille de pièces jointes ridicules, etc.

              Un point que ce benchmark ne montre pas (vu qu'il fait tout en ramdisk), c'est le temps gagné en accès disque avec des fichiers plus petits à décompresser (mais c'est peut-être négligeable, je ne sais pas, et ça dépendra énormément du type de disque).

              Ça peut être intéressant sur un disque dur (quoique les disques durs les plus performants…), mais sur un SSD c’est contre-productif (sauf si tu as plus de place dessus! :p).

              Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Par rapport à xz ?

                Posté par (page perso) . Évalué à  4 .

                Ce que je veux dire c’est que lorsque tu en es à pinailler sur l’algorithme de compression c’est que tu dois avoir un/des fichiers d’une taille importante déjà, donc où le temps de compression compte pas mal.

                Là, l'exemple, ce sont les source du noyau (plus de 400Mo quand même). Qu'elles sorte 5 minutes plus tard n'est pas un drame. De plus, ils doivent avoir des machines qui gèrent la publication un peu plus performante qu'un vieil i5.

                J’avais en tête le partage de fichiers par courriel, mettre les pièces jointes une par une c’est juste l’enfer, les limitations de taille de pièces jointes ridicules, etc.

                Oui, pour ça, xz n'est sans doute pas approprié.

                Ça peut être intéressant sur un disque dur (quoique les disques durs les plus performants…), mais sur un SSD c’est contre-productif (sauf si tu as plus de place dessus! :p).

                Même sur un SSD, les accès sont quand même bien plus lent que la mémoire vive. C'est pour ça que je pose la question, ce n'est peut-être pas pertinent.

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: Par rapport à xz ?

                  Posté par . Évalué à  -1 .

                  --- " Même sur un SSD, les accès sont quand même bien plus lent que la mémoire vive. C'est pour ça que je pose la question, ce n'est peut-être pas pertinent. " (…)

                  De toutes les façons même en mémoire vive la compression/décompression est toujours nettement plus lente pour XZ.
                  (Je le vois lorsque je démarre volontairement avec tout en mémoire vive…)

                  Merci pour vos remarques pertinentes dans cette page.

              • [^] # Re: Par rapport à xz ?

                Posté par . Évalué à  6 .

                Ce que je veux dire c’est que lorsque tu en es à pinailler sur l’algorithme de compression c’est que tu dois avoir un/des fichiers d’une taille importante déjà, donc où le temps de compression compte pas mal.

                Il existe des dizaines de cas d'utilisation d'un algo de compression, chaque cas à des critères très différents. Forcément tu vas utiliser le plus adapté au cas d'utilisation.

                Un fichier qui va rester sur disque des mois, je peux faire un effort et bouffer un peu de CPU pour le stocker. Quand je cherche a saturer un lien 10Gb avec une compression en streaming pour un truc qui ne va passer qu'une fois dans le tuyaux mes critères sont opposés. De même quand je créer une archive qui va être téléchargée 10000 fois, ou si le premier fichier que j'ai stocké pour des mois va devoir être lu 10x par jour pendant toute cette période.

                Bref oui, pour un usage personnel tu t'en carre dans 99% des cas. Dès que tu commences à bosser ca vaut le coup de réfléchir un peu tu peux avoir des gains réellement monstrueux.

              • [^] # Re: Par rapport à xz ?

                Posté par (page perso) . Évalué à  6 .

                Ce que je veux dire c’est que lorsque tu en es à pinailler sur l’algorithme de compression c’est que tu dois avoir un/des fichiers d’une taille importante déjà, donc où le temps de compression compte pas mal.

                Pour toi, peut-être.
                Perso, j'ai du CPU à plus savoir qu'en faire, et des TB de fichiers à stocker qui eux me coûtent. Le CPU coûte "rien", les TB à stocker par contre ça coûte. Passer à une compression forte m'apporte plus que le problème de temps de compression. Sur ZFS, passer de LZJB à gsip-9 pourrit un peu mon CPU (mais il est au chômage 90% du temps, ça va) mais m'évite des disques en plus (il y a une réelle différence de compression avec mes fichiers), j'apprécie.

                Tu as un cas, moi j'en ai un autre, merci de ne pas imaginer que ton cas est universel.

                • [^] # Re: Par rapport à xz ?

                  Posté par (page perso) . Évalué à  1 .

                  Ce que je veux dire c’est que lorsque tu en es à pinailler sur l’algorithme de compression c’est que tu dois avoir un/des fichiers d’une taille importante déjà, donc où le temps de compression compte pas mal.

                  des TB de fichiers à stocker

                  Plusieurs To de données, je compte ça comme «une taille importante».

                  Tu as un cas, moi j'en ai un autre, merci de ne pas imaginer que ton cas est universel.

                  Zenitram a encore frappé… :p

                  Écrit en Bépo selon l’orthographe de 1990

                  • [^] # Re: Par rapport à xz ?

                    Posté par (page perso) . Évalué à  2 .

                    Plusieurs To de données, je compte ça comme «une taille importante».

                    Oui, et justement, tu dis "le temps de compression compte pas mal", je te répond "pas forcément".

                    Zenitram a encore frappé… :p

                    Désolé, mais quand on balance une telle affirmation, oui je réagis : non, ton cas que tu veux généraliser (tu n'as mis aucune limitation dans ton affirmation à part la taille importante) ne s'applique pas à tous. Je m'en tamponne du temps de compression (mais LZMA n'est pas dans ZFS, dommage) alors que je suis dans ton critère ("des fichiers d’une taille importante déja").

                    • [^] # Re: Par rapport à xz ?

                      Posté par (page perso) . Évalué à  1 .

                      Ouais je dis n'importe quoi.

                      En fait au début je pensais au cas où tu compressais un grand volume de données d'un coup, et pas le cas où le système de fichier compressait tout.

                      Écrit en Bépo selon l’orthographe de 1990

                      • [^] # Re: Par rapport à xz ?

                        Posté par (page perso) . Évalué à  2 .

                        Mais c'est toujours la même réponse : ça dépend.
                        Je peux très bien accepter 20 heures de compression (merci les snapshots du FS pour avoir un truc "live") si à la fin mon archive est plus petite et que c'est ça qui est important pour moi.

                        • [^] # Re: Par rapport à xz ?

                          Posté par (page perso) . Évalué à  1 .

                          Oui après ça dépend forcément du temps pendant lequel on va le stocker… Encore une fois je suis partie du cas particulier de la compression d’un gros truc pour envoyer un courriel sans le préciser, d’où les malentendus etc. Mais évidemment ça dépend de combien de temps tu vas le stoker, combien de place sur a sur tes disques, combien de temps tu es prêt à passer pour compresser et décompresser…

                          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Par rapport à xz ?

            Posté par (page perso) . Évalué à  1 .

            Ce qui compte c’est que ça compresse bien et rapidement.

            Ce qui compte, ca depend du cas d'utilisation, et il y en a plein de differents.

            Par exemple des gens ont crée zopfli[1], qui permet de créer des fichiers au format gzip, 5% plus petits qu'avec gzip, mais en prenant 100 fois plus de temps à compresser. Et j'espere que ce qui compte pour eux ca n'est pas que ca compresse rapidement.

            [1] https://code.google.com/p/zopfli/

        • [^] # Re: Par rapport à xz ?

          Posté par . Évalué à  10 .

          Il y a des choses amusantes dans ce benchmark.
          En particulier, on voit qu'un xz -1 compresse mieux qu'un gzip -9 (82Mio contre 96 Mio) en étant légèrement plus rapide (32.2s contre 33s). Il faudrait que je fasse quelques essais avec des types de fichiers différents pour voir si c'est systématique.

      • [^] # Re: Par rapport à xz ?

        Posté par . Évalué à  5 .

        Crois moi, quand on a du 512K (voire du 56K), chaque octet compte. Pour le code source, xz est prèsque deux fois plus petit que gzip.
        Avec du 20 Mbits, je veux bien croire qu'on y perde.

        • [^] # Re: Par rapport à xz ?

          Posté par (page perso) . Évalué à  8 .

          Les différents miroirs doivent aussi être content de voir leur bande passante total diminuer.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Par rapport à xz ?

        Posté par . Évalué à  3 .

        1/ XZ consomme beaucoup, je l'ai constaté mais pour chaque octet que l'on doive télécharger, il vaut mieux que le fichier soit le plus petit possible… aussi bien du côté serveur que de notre côté…
        (Bande passante, taille à mobiliser pendant souvent des mois dans le serveur, etc.)

        2/ Pour Arch Linux, oui, ils ont du faire des choix et je comprends leur raison: un maximum de paquets dans un minimum de place.
        Ce qui est cohérent avec la possibilité de rendre la distribution facilement acceptable notamment pour ceux qui ont une petite bande passante.
        Moi même qui utilise une bande passante normale, je n'aime pas toujours lorsque le paquet est trop gros.

        Le choix d'archlinux est comme celui de la distribution slax: mettre un maximum de choses en un minimum de place… (Slax est un live CD)

        Merci pour votre commentaire pertinent.

        • [^] # Re: Par rapport à xz ?

          Posté par (page perso) . Évalué à  3 .

          Est-ce que ArchLinux fait comme pour Fedora à savoir des delta de paquets pour les mises à jours ?
          Ce dispositif permet un gain de temps et de bande passante incroyable (encre 50 et 90% de la mise à jour globale d'économisé suivant les logiciels et les changements apportés).

          • [^] # Re: Par rapport à xz ?

            Posté par . Évalué à  0 . Dernière modification : le 12/06/13 à 00:38

            --- " Est-ce que ArchLinux fait comme pour Fedora à savoir des delta de paquets pour les mises à jours ? " (…)

            Si vous parlez de xdelta3 3.0.7-1 je dirais que oui.

            • [^] # Re: Par rapport à xz ?

              Posté par . Évalué à  1 .

              Dommage que les paquets deb ne gèrent pas encore ça. Ils sont par ailleurs aussi bien (voire legèrement meilleurs) que les rpm.

          • [^] # Re: Par rapport à xz ?

            Posté par (page perso) . Évalué à  1 .

            On en a un.

            Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Par rapport à xz ?

            Posté par . Évalué à  2 .

            Est-ce que ArchLinux fait comme pour Fedora à savoir des delta de paquets pour les mises à jours ?

            On dirait que ça fait longtemps que c'est possible :
            https://wiki.archlinux.org/index.php/Deltup

            Mais ce n'est pas supporté par tous les dépôts Arch :
            https://bugs.archlinux.org/task/18590
            (au vu du nombre de votes, on dirait que c'est important pour pas mal de gens)

            Et ça a récemment été modifié :
            http://archlinux.fr/news/pacman-4-1-dans-core

          • [^] # Re: Par rapport à xz ?

            Posté par . Évalué à  2 .

            Oui, même si j'ai l'impression que le passage au XZ a rendu les mises à jour delta un poil moins intéressantes.
            La dernière fois que j'ai testé, pacman semblait reconstruire les archives puis les compresser en XZ avant de les décompresser à nouveau pour l'installation. Ça tombe mal, car le XZ est plutôt rapide à la décompression mais très lent à la compression. D'ailleurs sur mon netbook les mises à jour delta sont devenues lentes à mourir.
            Cela reste très intéressant pour ceux qui ont une connexion lentes ou des quotas sur la bande passante.

  • # Erreur dans les versions optimisées ?

    Posté par . Évalué à  5 .

    lors d'un écrasement, et avec certaines plateformes où il est compilé de façon optimisée, gzip n'agit plus comme si vous aviez tapé « y » lorsque vous tapez « n ». (bogue présent depuis gzip-1.3.6) ;

    Cette erreur a l'air très croustillante. Serait-il possible d'avoir plus d'explications, en particulier un lien vers le commit corrigeant le problème ?

Suivre le flux des commentaires

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