Pourquoi * .tar.gz est-il toujours beaucoup plus courant que * .tar.xz?
Chaque fois que je vois des paquets source ou des binaires compressés avec GZip, je me demande s'il y a encore des raisons de privilégier gz par rapport à xz (hors voyage dans le temps jusqu'en 2000), les économies de l'algorithme de compression LZMA sont substantielles et la décompression n'est pas d'une ampleur pire que gzip.
"Dénominateur commun le plus bas". L'espace supplémentaire économisé vaut rarement la perte d'interopérabilité. La plupart des systèmes Linux embarqués ont gzip, mais pas xz. Beaucoup d'anciens systèmes aussi. Gnu Tar qui est la norme de l'industrie prend en charge les drapeaux -z Pour traiter via gzip, et -j Pour traiter via bzip2, mais certains anciens systèmes ne prend pas en charge l'indicateur -J pour xz, ce qui signifie qu'il nécessite une opération en 2 étapes (et beaucoup d'espace disque supplémentaire pour .tar non compressé, sauf si vous utilisez la syntaxe de |tar xf - - que beaucoup de gens ne connaissent pas.) De plus, la décompression du système de fichiers complet de quelque 10 Mo de tar.gz Sur le ARM prend environ 2 minutes et n'est pas vraiment un problème. Aucune idée de xz mais bzip2 prend environ 10-15 minutes. Ne vaut certainement pas la bande passante économisée.
La réponse ultime est l'accessibilité, avec une réponse secondaire de but. Raisons pour lesquelles XZ n'est pas nécessairement aussi approprié que Gzip:
Les systèmes intégrés et hérités sont beaucoup plus susceptibles de manquer de mémoire disponible suffisante pour décompresser les archives LZMA/LZMA2 telles que XZ. Par exemple, si XZ peut réduire de 400 Ko (par rapport à Gzip) un package destiné à un routeur OpenWrt, à quoi servent les économies d'espace mineures si le routeur a 16 Mo de RAM? Une situation similaire apparaît avec des systèmes informatiques très anciens. On pourrait se moquer de l'idée de télécharger et de compiler la dernière version de Bash sur une ancienne SparcStation LX avec 32 Mo de RAM, mais cela arrive.
De tels systèmes ont généralement des processeurs lents et les augmentations de temps de décompression peuvent être très élevées. Trois secondes supplémentaires pour décompresser sur votre Core i5 peuvent être très longues sur un 200 MHz ARM core ou un microSPARC 50 MHz. La compression Gzip est extrêmement rapide sur ces processeurs par rapport à toutes les meilleures méthodes de compression telles que comme XZ ou même Bzip2.
Gzip est à peu près universellement pris en charge par tous les systèmes de type UNIX (et presque tous les systèmes non UNIX également) créés au cours des deux dernières décennies. La disponibilité de XZ est beaucoup plus limitée. La compression est inutile sans la capacité de la décompresser.
Une compression plus élevée prend beaucoup de temps. Si le temps de compression est plus important que le taux de compression, Gzip bat XZ. Honnêtement, lzop est beaucoup plus rapide que Gzip et compresse toujours bien, donc les applications qui ont besoin de la compression la plus rapide possible et qui ne nécessitent pas l'ubiquité de Gzip devraient plutôt y penser. Je mélange régulièrement les dossiers rapidement sur une connexion LAN de confiance avec des commandes telles que "tar -c * | lzop -1 | socat -u - tcp-connect: 192.168.0.101: 4444" et Gzip pourrait être utilisé de la même manière sur une liaison beaucoup plus lente ( c'est-à-dire faire la même chose que je viens de décrire via un tunnel SSH sur Internet).
Maintenant, d'un autre côté, il existe des situations où la compression XZ est largement supérieure:
Envoi de données sur des liaisons lentes. Le code source du noyau Linux 3.7 est 34 Mo plus petit au format XZ qu'au format Gzip. Si vous avez une connexion super rapide, choisir XZ pourrait signifier économiser une minute de temps de téléchargement; sur une connexion DSL bon marché ou une connexion cellulaire 3G, cela pourrait réduire d'une heure ou plus le temps de téléchargement.
Rétrécissement des archives de sauvegarde. La compression du code source pour httpd-2.4.2 d'Apache avec "gzip-9" contre "xz -9e" donne une archive XZ qui est de 62,7% la taille de l'archive Gzip. Si la même compressibilité existe dans un ensemble de données que vous stockez actuellement en tant que 100 GiB valeur d'archives .tar.gz, la conversion en archives .tar.xz réduirait la somme énorme de 37,3 GiB hors du jeu de sauvegarde. La copie de tout le jeu de données de sauvegarde sur un disque dur USB 2.0 (maximum environ 30 Mio/sec de transfert) car les données Gzippées prendraient 55 minutes, mais la compression XZ rendrait la sauvegarde prendre 20 minutes En supposant que vous travaillerez avec ces sauvegardes sur un système de bureau moderne avec beaucoup de puissance CPU et la vitesse de compression unique n'est pas un problème grave, l'utilisation de la compression XZ est généralement plus logique. Pourquoi mélanger autour de données supplémentaires si vous n'en avez pas besoin?
Distribution de grandes quantités de données pouvant être hautement compressibles. Comme mentionné précédemment, le code source de Linux 3.7 est de 67 Mio pour .tar.xz et 101 Mio pour .tar.gz; le code source non compressé est d'environ 542 Mio et est presque entièrement en texte. Le code source (et le texte en général) est généralement très compressible en raison de la quantité de redondance dans le contenu, mais les compresseurs comme Gzip qui fonctionnent avec un dictionnaire beaucoup plus petit ne profitent pas d'une redondance qui dépasse la taille de leur dictionnaire.
En fin de compte, tout revient à un compromis à quatre voies: taille compressée, vitesse de compression/décompression, vitesse de copie/transmission (lecture des données à partir du disque/réseau) et disponibilité du compresseur/décompresseur. La sélection dépend fortement de la question "que comptez-vous faire de ces données?"
Aussi consultez ce post à partir duquel j'ai appris certaines des choses que je répète ici.
J'ai fait mon propre benchmark sur une image vmdk d'installation Linux de 1,1 Go:
rar =260MB comp= 85s decomp= 5s
7z(p7z)=269MB comp= 98s decomp=15s
tar.xz =288MB comp=400s decomp=30s
tar.bz2=382MB comp= 91s decomp=70s
tar.gz =421MB comp=181s decomp= 5s
tous les niveaux de compression sur max, CPU Intel I7 3740QM, mémoire 32 Go 1600, source et destination sur RAM disque
J'utilise généralement rar ou 7z pour l'archivage de fichiers normaux comme des documents.
et pour l'archivage des fichiers système, j'utilise .tar.gz ou .tar.xz par file-roller ou tar avec les options -z ou -J ainsi que --preserve pour compresser nativement avec tar et conserver les autorisations (également alternativement .tar.7z ou .tar.rar peuvent être utilisés)
mise à jour: comme tar ne conserve que les autorisations normales et non les listes de contrôle d'accès de toute façon, également les autorisations de sauvegarde et de restauration simples et. préserver les autorisations et les listes de contrôle d'accès, a une somme de contrôle, un test d'intégrité et une capacité de cryptage, le seul inconvénient est que p7Zip n'est pas disponible partout
De l'auteur de l'utilitaire de compression Lzip:
Xz a un format complexe, partiellement spécialisé dans la compression d'exécutables et conçu pour être étendu par des formats propriétaires. Des quatre compresseurs testés ici, xz est le seul étranger au concept Unix de "faire une chose et bien le faire". C'est le moins approprié pour le partage de données, et pas du tout approprié pour l'archivage à long terme.
En général, plus le format est complexe, moins il est probable qu'il puisse être décodé à l'avenir. Mais le format xz, tout comme son infâme prédécesseur lzma seul, est spécialement mal conçu. Xz copie presque tous les défauts de gzip, puis en ajoute d'autres, comme les fragiles entiers de longueur variable. Un seul bit-flip dans le bit 7 de n'importe quel octet d'un entier de longueur variable et le flux xz entier s'écroule comme un château de cartes. L'utilisation de xz pour autre chose que la compression d'exécutables de courte durée n'est pas recommandée.
Ne m'interprète pas mal. Je suis très reconnaissant à Igor Pavlov d'avoir inventé/découvert LZMA, mais xz est la troisième tentative de ses followers pour profiter de la popularité de 7Zip et remplacer gzip et bzip2 par des formats inappropriés ou mal conçus. En particulier, il est honteux que le support de lzma seul ait été implémenté à la fois dans GNU et Linux.
Honnêtement, je viens de découvrir le format .xz à partir d'un matériel de formation. J'ai donc utilisé son git repo pour faire un test. Le git est git: //git.free-electrons.com/training-materials.git, et j'ai également compilé les trois diapositives de formation. La taille totale du répertoire est de 91 Mo, avec un mélange de texte et de données binaires.
Voici mon résultat rapide. Peut-être que les gens préfèrent encore tar.gz simplement parce qu'il est beaucoup plus rapide à compresser? Personnellement, j'utilise même du goudron brut lorsqu'il n'y a pas beaucoup d'avantages à gagner en compression.
[02:49:32]wujj@WuJJ-PC-Linux /tmp $ time tar czf test.tgz training-materials/
real 0m3.371s
user 0m3.208s
sys 0m0.128s
[02:49:46]wujj@WuJJ-PC-Linux /tmp $ time tar cJf test.txz training-materials/
real 0m34.557s
user 0m33.930s
sys 0m0.372s
[02:50:31]wujj@WuJJ-PC-Linux /tmp $ time tar cf test.tar training-materials/
real 0m0.117s
user 0m0.020s
sys 0m0.092s
[02:51:03]wujj@WuJJ-PC-Linux /tmp $ ll test*
-rw-rw-r-- 1 wujj wujj 91944960 2012-07-09 02:51 test.tar
-rw-rw-r-- 1 wujj wujj 69042586 2012-07-09 02:49 test.tgz
-rw-rw-r-- 1 wujj wujj 60609224 2012-07-09 02:50 test.txz
[02:56:03]wujj@WuJJ-PC-Linux /tmp $ time tar xzf test.tgz
real 0m0.719s
user 0m0.536s
sys 0m0.144s
[02:56:24]wujj@WuJJ-PC-Linux /tmp $ time tar xf test.tar
real 0m0.189s
user 0m0.004s
sys 0m0.108s
[02:56:33]wujj@WuJJ-PC-Linux /tmp $ time tar xJf test.txz
real 0m3.116s
user 0m2.612s
sys 0m0.184s
Pour la même raison, les utilisateurs de Windows (r) utilisent des fichiers Zip au lieu de 7Zip, et certains utilisent encore rar au lieu d'autres formats ... Ou mp3 est utilisé dans la musique, au lieu de aac +, et ainsi de suite.
Chaque format a ses avantages et les gens utilisent pour s'en tenir à une solution qu'ils ont apprise lorsqu'ils ont commencé à utiliser un ordinateur. Ajoutez ceci à la compatibilité descendante et à la bande passante rapide + Go ou TB d'espace sur les disques durs, et les avantages d'une plus grande compression ne seront pas si pertinents.
gz est pris en charge partout et bon pour la portabilité.
xz est plus récent et désormais aussi largement ou bien pris en charge. Il est plus complexe que gzip avec plus d'options de compression.
Ce n'est pas la seule raison pour laquelle les gens n'utilisent pas toujours xz. xz peut prendre un temps très long à compresser, pas un temps insignifiant donc même s'il peut produire des résultats supérieurs, il ne sera pas toujours choisi. Une autre faiblesse est qu'il peut utiliser beaucoup de mémoire, notamment pour la compression. Plus vous voulez compresser un élément, plus il prend de temps, ce qui est exponentiel avec des rendements décroissants.
Cependant, au niveau de compression 1 pour les gros éléments binaires selon mon expérience, xz peut souvent produire des résultats beaucoup plus petits en moins de temps que zlib au niveau 9. Cela peut parfois être une différence très importante, en même temps que zlib, xz peut créer un fichier c'est la moitié de la taille du fichier de zlib.
bzip2 est dans une situation similaire, mais xz a des avantages bien supérieurs et une fenêtre solide où il fonctionne nettement mieux tout au long.
Un autre point important pour gzip est qu'il est interopérable avec rsync/zsync. Cela pourrait être un énorme avantage en ce qui concerne la bande passante dans certains cas. LZMA/bzip2/xz ne prend pas en charge rsync et ne le prendra probablement pas de sitôt.
L'une des caractéristiques du LZMA est qu'il utilise une grande fenêtre silencieuse. Pour le rendre rsync/zsync convivial, nous aurions probablement besoin de réduire cette fenêtre, ce qui dégraderait ses performances de compression.
Oui, la pensée que j'avais était que la question d'origine pouvait être reposée ces jours-ci comme "pourquoi tar.gz est-il plus courant que tar.lz" (puisque lz semble compresser légèrement mieux que xz, xz est dit pour être un mauvais choix pour l'archivage, bien qu'il offre quelques fonctionnalités intéressantes comme l'accès aléatoire). Je suppose que la réponse est "l'élan" que les gens ont l'habitude de l'utiliser, il y a un bon support de bibliothèque, etc. etc. L'introduction de lz peut signifier que xz augmentera moins vite maintenant, aussi, FWIW ...
Cependant, cela étant dit, lz semble décompresser plus lentement que xz, et il y a de nouvelles choses à l'horizon comme Brotli, donc on ne sait pas ce qui se passera en termes de popularité ... mais j'ai l'air de quelques-uns Fichiers .lz dans le FWIW sauvage ...