À chaque fois que je vois des paquets sources ou des fichiers binaires compressés avec GZip, je me demande s’il existe encore des raisons de privilégier gz au lieu de xz (voyage dans le temps jusqu’en 2000), les économies de l’algorithme de compression LZMA sont substantielles et les décompressions ne sont pas pires que la précédente. gzip.
Réponses
Trop de publicités?
"Plus Petit Dénominateur Commun". L'espace supplémentaire enregistré est rarement la peine de l'interopérabilité. La plupart des systèmes Linux embarqué ont gzip, mais pas xz. De nombreux vieux système. Gnu Tar, qui est le standard de l'industrie prend en charge les drapeaux -z traiter via gzip, et -j passant par bzip2, mais certains anciens systèmes ne prennent pas en charge l' -J drapeau pour xzen ce sens qu'elle nécessite 2 étapes de l'opération (et beaucoup de supplémentaire d'espace disque non compressé .tar , sauf si vous utilisez la syntaxe de l' |tar xf - - dont beaucoup de gens ne le savent pas. Aussi, la décompression du système de fichiers complet de certains 10MO d' tar.gz sur les BRAS prend environ 2 minutes et n'est pas vraiment un problème. Aucune idée sur xz mais bzip2 prend environ 10 à 15 minutes. Certainement pas la peine de la largeur de bande enregistrée.
De toute façon, l'actuel "alternative moderne" où vous sacrifier de la puissance CPU en faveur de l'espace disque (...ce qui est encore rarement un accueil de commerce de la bande passante et d'espace disque sont bon marché, et les gens déteste quand les systèmes de stagner en raison de certaines mises à jour de l'exécution en arrière plan) - est - bzip2.
Jody Lee Bruchon
Points
450
La réponse ultime est de l'accessibilité, avec un secondaire de répondre de but. Raisons pour lesquelles XZ n'est pas nécessairement approprié comme Gzip:
Embarqués et les systèmes traditionnels, sont beaucoup plus probablement d'un manque de suffisamment de mémoire disponible pour décompresser LZMA/LZMA2 archives tel que XZ. Par exemple, si XZ peut se raser 400 KiB (vs Gzip) hors d'un paquet destiné à un routeur OpenWrt, à quoi bon le mineur de l'espace d'épargne si le routeur dispose de 16 mo de RAM? Une situation similaire s'affiche avec des très vieux systèmes informatiques. On peut se moquer de la pensée de télécharger et de compiler la dernière version de Bash sur un ancien SparcStation LX avec 32 mo de RAM, mais ça arrive.
De tels systèmes ont généralement des processeurs lents, et la décompression des augmentations de temps peut être très élevé. Trois secondes de plus pour décompresser sur votre Core i5 peut être extrêmement long sur un 200 MHz de BRAS de noyau ou de 50 MHz microSPARC. La compression Gzip est extrêmement rapide sur ces processeurs par rapport à tous les meilleures méthodes de compression tel que XZ ou même Bzip2.
Gzip est à peu près universellement pris en charge par chaque système de type UNIX (et presque tous les non-UNIX-like trop) créés durant les deux dernières décennies. XZ disponibilité est beaucoup plus limitée. La Compression est inutile sans la possibilité de décompresser.
Taux de compression plus prend beaucoup de temps. Si le temps de compression est plus important que le ratio de compression Gzip beats XZ. Honnêtement, lzop est beaucoup plus rapide que Gzip et encore comprime bon, alors les applications qui ont besoin de la manière la plus rapide de compression possible et ne nécessitent pas de Gzip de l'ubiquité devrait se pencher sur cette place. J'ai régulièrement shuffle dossiers rapidement à travers une confiance connexion LAN avec des commandes comme "tar-c * | lzop -1 | socat -u - tcp-connect:192.168.0.101:4444" et Gzip pourrait être utilisé de la même façon sur une beaucoup plus lente lien (c'est à dire faire la même chose que je viens de décrire à travers un tunnel SSH sur Internet).
Maintenant, sur le revers de la médaille, il y a des situations où la compression XZ est largement supérieur:
L'envoi de données sur des liaisons lentes. Le Linux 3.7 le code source du noyau est de 34 MiB de plus petite XZ format que dans Gzip format. Si vous avez une super connexion rapide, le choix XZ pourrait permettre de sauver une minute de temps de téléchargement; sur un bon marché d'une connexion DSL ou un lien cellulaire 3G, il peut raser une heure ou plus sur le temps de téléchargement.
Rétrécissement des archives de sauvegarde. Compresser le code source d'Apache httpd-2.4.2 avec "gzip-9" vs "xz -9e" donne une XZ archive qui est de 62,7%, la taille de l'archive Gzip. Si le même compressibilité existe dans un ensemble de données vous actuellement magasin 100 GiB peine de .tar.gz des archives, de convertir pour .le goudron.xz archives voudrais couper un énorme 37.3 GiB hors du jeu de sauvegarde. La copie de cette sauvegarde complète de l'ensemble de données d'un disque dur USB 2.0 (plafonnait autour de 30 Mo/sec transferts) comme Format de données permettrait de prendre de 55 minutes, mais la compression XZ ferait la sauvegarde prendre 20 minutes de moins. En supposant que vous allez travailler avec ces sauvegardes sur un système de bureau moderne avec beaucoup de puissance CPU et la seule fois la vitesse de compression n'est pas un problème grave, à l'aide de la compression XZ fait généralement plus de sens. Pourquoi déplacer les données supplémentaires si vous n'avez pas besoin d'?
La distribution de grandes quantités de données qui peuvent être hautement compressible. Comme mentionné précédemment, Linux 3.7 code source est de 67 MiB .le goudron.xz et 101 MiB .tar.gz; la non compressé code source est d'environ 542 MiB et est presque entièrement 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 compresseurs comme Gzip qui fonctionnent avec un plus petit dictionnaire n'arrivons pas à tirer parti de la redondance qui va au-delà de leur taille du dictionnaire.
En fin de compte, tout revient à une quatre-voies compromis: taille compressée, la compression/décompression de vitesse, copier/vitesse de transmission (de la lecture des données à partir du disque/réseau), et de la disponibilité du compresseur/décompresseur. La sélection est très dépendante de la question "qu'allez-vous faire avec ces données?"
Aussi découvrez ce poste à partir de laquelle j'ai appris certaines choses, je le répète ici.
Ali AlipourR
Points
120
J'ai fait de mon propre point de référence sur 1,1 GO d'installation de Linux vmdk image:
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, PROCESSEUR Intel I7 3740QM, Mémoire 32 GO 1600, de source et de destination sur le disque RAM
Je l'utilise Généralement rar ou 7z, pour l'archivage des fichiers normaux comme des documents.
et pour l'archivage des fichiers système que j'utilise .tar.gz ou .le goudron.xz par file-roller ou de goudron avec -z ou -J options avec --preserve pour compresser de manière native avec du goudron et de préserver les permissions (aussi bien .le goudron.7z ou .tar.rar peut être utilisé)
mise à jour: comme le goudron seulement pour préserver la normale des autorisations et de ne pas les Acl de toute façon, aussi simple .7z, plus de sauvegarde et de restauration des autorisations et les Acl manuellement par l'intermédiaire de getfacl et sefacl peut être utilisé, qui semble être la meilleure option pour les deux archivage de fichiers ou des fichiers système de sauvegarde, car il devra préserver les permissions et les Acl, a la somme de contrôle, de test d'intégrité et la fonctionnalité de cryptage, seul inconvénient, c'est que p7zip n'est pas disponible partout
wujj123456
Points
451
Honnêtement, je viens de faire connaître .xz format à partir d'un matériel de formation. Donc j'ai simplement utilisé son repo git de faire un test. Le git git://git.gratuit-électrons.com/formation-matériaux.git, et j'ai aussi compilé les trois diapositives de formation. La taille totale du répertoire est 91M, avec un mélange de texte et de données binaires.
Voici mon résultat rapide. Peut-être les gens toujours en faveur tar.gz tout simplement parce que c'est beaucoup plus rapide pour compresser? Personnellement, j'ai même utiliser du goudron quand il n'y a pas beaucoup d'avantages 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
woliveirajr
Points
4297
Pour la même raison, les utilisateurs de Windows (r) utilisent des fichiers zip au lieu de 7zip, et certains utilisent encore le format rar au lieu d’autres formats ... Ou le format mp3 est utilisé dans la musique, au lieu du format aac +, etc.
Chaque format a ses avantages et les gens s’en tiennent à une solution qu’ils ont apprise en commençant à utiliser un ordinateur. Ajoutez à cela la compatibilité ascendante et la bande passante rapide + Go ou To d'espace sur les disques durs, et les avantages d'une compression plus importante ne seront pas aussi pertinents.
