Pourquoi les formats d'archive tar basculent-ils vers la compression xz pour remplacer bzip2 et que dire de gzip?


203

De plus en plus d' tararchives utilisent le xzformat basé sur LZMA2 pour la compression au lieu de la bzip2(bz2)compression traditionnelle . En fait, kernel.org a fait une annonce tardive " Au revoir bzip2 " le 27 décembre 2013 , indiquant que les sources du noyau seraient désormais publiées aux formats tar.gz et tar.xz - et sur la page principale du site Web. ce qui est offert directement est tar.xz.

Existe-t-il des raisons spécifiques expliquant pourquoi cela se produit et quelle est la pertinence de gzipce contexte?

history  gzip  bzip2  xz 

Réponses:


198

Pour la distribution des archives sur Internet, les éléments suivants constituent généralement une priorité:

  1. Taux de compression (c.-à-d. La taille réduite du compresseur pour la production des données);
  2. Temps de décompression (besoins en CPU);
  3. Mémoire de décompression requise; et
  4. Compatibilité (étendue du programme de décompression)

La mémoire de compression et les besoins en ressources processeur ne sont pas très importants, car vous pouvez utiliser une grande machine rapide pour cela, et vous ne devez le faire qu'une seule fois.

Par rapport à bzip2, xz a un meilleur taux de compression et un temps de décompression plus court (meilleur). Cependant, avec les réglages de compression généralement utilisés, il nécessite plus de mémoire pour décompresser [1] et est un peu moins répandu. Gzip utilise moins de mémoire que ce soit.

Ainsi, les archives aux formats gzip et xz sont affichées, ce qui vous permet de choisir:

  • Besoin de décompresser sur une machine avec une mémoire très limitée (<32 Mo): gzip. Donné, pas très probable quand on parle de sources du noyau.
  • Besoin de décompresser un minimum d'outils disponibles: gzip
  • Voulez-vous économiser du temps de téléchargement et / ou de bande passante: xz

Il n'y a pas vraiment de combinaison réaliste de facteurs qui vous amènerait à choisir bzip2. Donc, son élimination progressive.

J'ai examiné les comparaisons de compression dans un article de blog . Je n'ai pas essayé de reproduire les résultats, et je suppose qu'une partie d'entre eux a changé (principalement, je pense, xzs'est améliorée, car c'est la plus récente.)

(Il existe des scénarios spécifiques dans lesquels une bonne implémentation de bzip2 peut être préférable à xz: bzip2 peut compresser un fichier avec beaucoup de zéros et de séquences d'ADN génomique mieux que xz. Les versions les plus récentes de xz ont maintenant un mode de blocage (optionnel) qui permet la récupération de données après le point de corruption et la compression parallèle et la décompression [en théorie]. Auparavant, seul bzip2 les offrait. [2] Cependant, aucun de ceux-ci n'est pertinent pour la distribution du noyau)


1: En taille d'archive, xz -3est autour bzip -9. Ensuite, xz utilise moins de mémoire pour décompresser. Mais xz -9(comme, par exemple, utilisé pour les archives du noyau Linux) utilise beaucoup plus que bzip -9. (Et même xz -0besoin de plus que gzip -9).

2: Modification à l'échelle du système F21: lbzip2 comme implémentation par défaut de bzip2


Avez-vous des commentaires sur le sujet de la tolérance aux pannes ou s'agit-il toujours d'une application complètement en dehors des algorithmes de compression?

1
@ La résilience illuminÉ ne peut être fournie sans sacrifier le taux de compression. C'est un problème orthogonal, et bien que des outils tels que Parchive existent, la gestion des erreurs du noyau pour la distribution de TCP fait tout aussi bien l'affaire.
Tobu

2
@ illuminÉ La tolérance aux pannes (en supposant que vous entendez quelque chose de similaire à par2) n'est généralement pas un problème pour la distribution d'archives sur Internet. Les téléchargements sont supposés suffisamment fiables (et vous pouvez simplement télécharger à nouveau s’il était corrompu). Les hachages et les signatures cryptographiques sont souvent utilisés et ils détectent la corruption ainsi que la falsification. Il existe des compresseurs offrant une plus grande tolérance aux pannes, mais au prix du taux de compression. Personne ne semble trouver le compromis intéressant pour les téléchargements HTTP ou FTP.
derobert

xz utilise MOINS mémoire pour décompresser.
MichalH

@ Mike Est-ce que ça a changé depuis que j'ai écrit ça? En particulier, la note de bas de page 1 explique l'utilisation de la mémoire.
derobert

46

Tout d'abord, cette question n'est pas directement liée à tar. Tar crée simplement une archive non compressée, la compression est ensuite appliquée.

On sait que Gzip est relativement rapide par rapport à LZMA2 et bzip2. Si la vitesse compte gzip(en particulier pour la mise en œuvre multithread pigz), il s'agit souvent d'un bon compromis entre la vitesse de compression et le taux de compression. Bien qu'il existe des alternatives si la vitesse est un problème (par exemple, LZ4).

Cependant, si un taux de compression élevé est souhaité, LZMA2 bat bzip2dans presque tous les aspects. La vitesse de compression est souvent plus lente, mais elle se décomprime beaucoup plus rapidement et fournit un rapport de compression bien meilleur au prix d'une utilisation plus importante de la mémoire.

Il n'y a pas beaucoup de raisons pour utiliser bzip2plus, sauf pour la compatibilité ascendante. De plus, LZMA2 était conçu pour le multithreading et de nombreuses implémentations utilisent par défaut des processeurs multicœurs (malheureusement xz, Linux ne le fait pas encore). Cela a du sens puisque les vitesses d'horloge n'augmenteront plus mais le nombre de cœurs augmentera.

Il existe des bzip2implémentations multithread (par exemple pbzip), mais elles ne sont souvent pas installées par défaut. Notez également que le multithread est bzip2réellement rentable lors de la compression alors que la décompression utilise un seul thread si le fichier a été compressé à l'aide d'un seul thread bzip2, contrairement à LZMA2. Les bzip2variantes parallèles ne peuvent exploiter les processeurs multicœurs que si le fichier a été compressé à l'aide d'une bzip2version parallèle , ce qui n'est souvent pas le cas.


4
Eh bien, certains tars sont une zoption.
tchrist

"speed" donne une réponse confuse, vous devriez vous référer à la vitesse de compression ou à la vitesse de décompression. Ni pixz, ni pbzip2 ni pigz ne sont installés par défaut (ou utilisés par tar sans le drapeau -I), mais pixz et pbzip2 accélèrent la compression et la décompression et pigz n’est utilisé que pour la compression.
Tobu

@Tobu xzsera multithread par défaut, aucune pixzinstallation ne sera nécessaire dans le futur. Sur certaines plates-formes, le xzthreading est déjà pris en charge. Considérant bzip2qu’il est peu probable que le multithread soit jamais utilisé, le format n’ayant pas été conçu pour le multithreading. De plus, la pbzip2décompression n’est accélérée que si le fichier a été compressé, pbzip2ce qui n’est souvent pas le cas.
Marco

1
@Marco Je pense que lbzip2 permet une décompression parallèle des fichiers même s'ils ont été compressés avec une implémentation non parallèle (par exemple, stock bzip2). C'est pourquoi j'utilise lbzip2 sur pbzip2. (Il est possible que cela ait évolué depuis votre commentaire.)
RaveTheTadpole

20

Réponse courte : xz est plus efficace en termes de taux de compression. Cela économise ainsi de l’espace disque et optimise le transfert sur le réseau.
Vous pouvez voir ce repère rapide afin de découvrir la différence par des tests pratiques.


Le lien est cassé.
Flarn2006

19

LZMA2 est un système de compression de bloc alors que gzip ne l’est pas. Cela signifie que LZMA2 se prête au multi-threading. De plus, en cas de corruption dans une archive, vous pouvez généralement récupérer les données de blocs ultérieurs avec LZMA2, mais pas avec gzip. En pratique, vous perdez l'archive entière avec gzip après le bloc corrompu. Avec une archive LZMA2, vous ne perdez que le ou les fichiers affectés par le ou les blocs corrompus. Cela peut être important dans les grandes archives avec plusieurs fichiers.


2
C'est une distinction très utile et importante, en effet!
Leden
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.