GZipで圧縮されたソースパッケージまたはバイナリを見ると、xzよりもgzを優先する理由があるのではないかと思います(2000年までのタイムトラベルを除く)。LZMA圧縮アルゴリズムの節約はかなりのものであり、解凍はそれよりもそれほど悪くはありません。 gzip。
9 に答える
「最小公分母」。節約された余分なスペースが相互運用性を失う価値があることはめったにありません。ほとんどの組み込みLinuxシステムにはgzipがありますが、xzはありません。多くの古いシステムも同様です。業界標準であるGnuTarは、gzipを介し-z
て処理し、bzip2を介して処理するフラグをサポートしていますが、一部の古いシステムはxzのフラグをサポートしていません。つまり、2ステップの操作が必要です(非圧縮の場合を除き、多くの追加のディスクスペースが必要です)。 -の構文を使用します。これは多くの人が知らないことです。)また、組み込みARMから約10MBのファイルシステム全体を解凍するには、約2分かかり、実際には問題ありません。についての手がかりはありませんが-j
-J
.tar
|tar xf -
tar.gz
xz
bzip2
約10〜15分かかります。帯域幅を節約する価値はありません。
究極の答えはアクセシビリティであり、目的の二次的な答えがあります。XZが必ずしもGzipほど適切ではない理由:
組み込みシステムとレガシーシステムでは、XZなどのLZMA/LZMA2アーカイブを解凍するのに十分なメモリが不足している可能性がはるかに高くなります。例として、XZがOpenWrtルーター向けのパッケージから400 KiB(vs. Gzip)を削減できる場合、ルーターに16 MiBのRAMがある場合、わずかなスペースの節約はどのくらいのメリットがありますか?同様の状況は、非常に古いコンピュータシステムでも発生します。32MBのRAMを搭載した古代のSparcStationLXに最新バージョンのBashをダウンロードしてコンパイルすることを考えると、嘲笑されるかもしれませんが、それは起こります。
このようなシステムは通常、プロセッサが低速であり、解凍時間の増加が非常に大きくなる可能性があります。Core i5で解凍するために3秒余分にかかると、200MHzARMコアまたは50MHzmicroSPARCでは非常に長くなる可能性があります。XZやBzip2などのすべての優れた圧縮方法と比較すると、このようなプロセッサではGzip圧縮が非常に高速です。
Gzipは、過去20年間に作成されたすべてのUNIXライクなシステム(およびほぼすべての非UNIXライクなシステム)によってほぼ普遍的にサポートされています。XZの可用性ははるかに制限されています。圧縮は、解凍する機能がなければ役に立ちません。
より高い圧縮には多くの時間がかかります。圧縮率よりも圧縮時間が重要な場合、GzipはXZに勝ります。正直なところ、lzopはGzipよりもはるかに高速であり、それでも問題なく圧縮されるため、可能な限り最速の圧縮を必要とし、Gzipのユビキタスを必要としないアプリケーションは代わりにそれを検討する必要があります。「tar-c*| lzop -1 | socat -u --tcp-connect:192.168.0.101:4444」などのコマンドを使用して、信頼できるLAN接続を介してフォルダーを定期的にすばやくシャッフルします。Gzipは、はるかに遅いリンクでも同様に使用できます(つまり、インターネット上のSSHトンネルを介して今説明したのと同じことを実行します)。
反対に、XZ圧縮が非常に優れている状況があります。
低速リンクを介したデータの送信。Linux 3.7カーネルのソースコードは、Gzip形式よりもXZ形式の方が34MiB小さくなっています。超高速接続の場合、XZを選択すると、ダウンロード時間を1分節約できます。安価なDSL接続または3Gセルラー接続では、ダウンロード時間を1時間以上短縮できます。
バックアップアーカイブの縮小。Apacheのhttpd-2.4.2のソースコードを「gzip-9」と「xz-9e」で圧縮すると、Gzipアーカイブの62.7%のサイズのXZアーカイブが生成されます。現在100GiB相当の.tar.gzアーカイブとして保存しているデータセットに同じ圧縮性が存在する場合、.tar.xzアーカイブに変換すると、バックアップセットからなんと37.3GiBが削減されます。このバックアップデータセット全体をUSB2.0ハードドライブにコピーすると(最大で約30 MiB /秒の転送)、Gzipされたデータは55分かかりますが、XZ圧縮を使用するとバックアップにかかる時間が20分短縮されます。十分なCPUパワーを備えた最新のデスクトップシステムでこれらのバックアップを使用し、1回限りの圧縮速度は深刻な問題ではないと仮定すると、XZ圧縮を使用する方が一般的に理にかなっています。そうしない場合、なぜ余分なデータをシャッフルするのですか?
高度に圧縮可能である可能性のある大量のデータを配布します。前述のように、Linux3.7のソースコードは.tar.xzの場合は67MiB、.tar.gzの場合は101MiBです。非圧縮のソースコードは約542MiBで、ほぼ完全にテキストです。ソースコード(および一般的なテキスト)は、コンテンツの冗長性の量のために通常は高度に圧縮可能ですが、はるかに小さい辞書で動作するGzipのようなコンプレッサーは、辞書のサイズを超える冗長性を利用できません。
最終的には、圧縮サイズ、圧縮/解凍速度、コピー/送信速度(ディスク/ネットワークからのデータの読み取り)、およびコンプレッサー/デコンプレッサーの可用性という4つのトレードオフにすべてフォールバックします。選択は、「このデータで何をする予定ですか?」という質問に大きく依存します。
また、ここで繰り返すことのいくつかを学んだこの関連記事もチェックしてください。
Lzip圧縮ユーティリティの作者から:
Xzは複雑な形式であり、実行可能ファイルの圧縮に部分的に特化しており、独自の形式で拡張できるように設計されています。ここでテストされた4つのコンプレッサーのうち、xzは、「1つのことを実行してそれをうまく実行する」というUnixの概念に異質な唯一の人です。データ共有にはあまり適しておらず、長期的なアーカイブにはまったく適していません。
一般に、フォーマットが複雑になるほど、将来デコードされる可能性は低くなります。しかし、xz形式は、その悪名高い前身のlzma-aloneと同様に、特別にひどく設計されています。Xzは、gzipのほとんどすべての欠陥をコピーしてから、壊れやすい可変長整数のように、さらにいくつかを追加します。1つの可変長整数の任意のバイトのビット7を1ビットフリップするだけで、xzストリーム全体がカードの家のように転倒します。短命の実行可能ファイルを圧縮する以外の目的でxzを使用することはお勧めできません。
私を間違って解釈しないでください。LZMAを発明/発見してくれたIgorPavlovに非常に感謝していますが、xzは、7zipの人気を利用し、gzipとbzip2を不適切または不適切に設計された形式に置き換える彼のフォロワーの3回目の試みです。特に、lzma-aloneのサポートがGNUとLinuxの両方で実装されたことは恥ずべきことです。
1.1GBのLinuxインストールvmdkイメージで独自のベンチマークを実行しました。
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
最大のすべての圧縮レベル、CPU Intel I7 3740QM、メモリ32GB 1600、RAMディスクのソースと宛先
私は通常、ドキュメントなどの通常のファイルをアーカイブするためにrarまたは7zを使用します。
システムファイルをアーカイブするには、file-rollerまたはtarで.tar.gzまたは.tar.xzを使用し、-zまたは-Jオプションと--preserveを使用して、tarでネイティブに圧縮し、アクセス許可を保持します(または.tar.7zまたは.tar.rarを使用できます)
更新:tarは通常のアクセス許可のみを保持し、ACLは保持しないため、プレーンな.7zに加えて、getfaclおよびsefaclを介して手動でアクセス許可とACLをバックアップおよび復元することもできます。これは、ファイルのアーカイブまたはシステムファイルのバックアップの両方に最適なオプションのようです。アクセス許可とACLを保持し、チェックサム、整合性テスト、および暗号化機能を備えていますが、唯一の欠点は、p7zipがどこでも利用できないことです。
正直なところ、トレーニング資料から.xz形式を知ることができます。そのため、テストを行うためにgitリポジトリを使用しました。gitはgit://git.free-electrons.com/training-materials.gitで、3つのトレーニングスライドも編集しました。ディレクトリの合計サイズは91Mで、テキストとバイナリデータが混在しています。
これが私の簡単な結果です。圧縮がはるかに速いという理由だけで、人々はまだtar.gzを好んでいますか?圧縮で得られるメリットがあまりない場合は、個人的にはプレーンタールを使用します。
[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
同じ理由で、Windows(r)の人々は7zipの代わりにzipファイルを使用し、他の形式の代わりにrarを使用する人もいます...またはmp3はaac+の代わりに音楽で使用されます。
それぞれの形式には利点があり、人々はコンピューターを使い始めたときに学んだ解決策に固執するために使用します。これを下位互換性と高速帯域幅+ハードドライブのGBまたはTBのスペースに追加すると、圧縮率を高めることのメリットはそれほど重要ではなくなります。
gzはどこでもサポートされており、移植性に優れています。
xzはより新しく、現在では広くまたは十分にサポートされています。より多くの圧縮オプションを備えたgzipよりも複雑です。
これは、人々が常にxzを使用するとは限らない唯一の理由ではありません。xzは圧縮に非常に長い時間がかかる可能性があり、些細な時間ではないため、優れた結果が得られたとしても、常に選択されるとは限りません。もう1つの弱点は、特に圧縮のために大量のメモリを使用できることです。アイテムを圧縮する時間が長くなるほど、これは指数関数的になり、収穫逓減が発生します。
ただし、私の経験では、大きなバイナリアイテムの圧縮レベル1では、xzはレベル9のzlibよりも短い時間ではるかに小さい結果を生成することがよくあります。これは、zlibと同時に、ファイルを作成できる非常に大きな違いになる場合があります。これは、zlibのファイルの半分のサイズです。
bzip2も同様の状況にありますが、xzにははるかに優れた利点と、全体的に大幅に優れたパフォーマンスを発揮する強力なウィンドウがあります。
また、gzipの重要なポイントの1つは、rsync/zsyncと相互運用できることです。これは、場合によっては帯域幅に関して大きなメリットになる可能性があります。LZMA / bzip2 / xzはrsyncをサポートしておらず、おそらくすぐにはサポートしないでしょう。
LZMAの特徴の1つは、静かな大きな窓を使用していることです。rsync / zsyncに対応させるには、おそらくこのウィンドウを減らす必要があり、圧縮パフォーマンスが低下します。
lz
ええ、私が持っていた考えは、元の質問は「なぜtar.gzはtar.lzよりも一般的であるのか」と言い換えることができるxz
というxz
ことです(ランダムアクセスのようないくつかの素晴らしい機能を提供します)。答えは、人々がそれを使用することに慣れている「勢い」、優れたライブラリサポートなどがあると思います。lzの導入は、xzの成長速度が遅くなることを意味するかもしれません。FWIW...
ただし、そうは言っても、lzはxzよりも解凍が遅いように見え、Brotliのような新しいものが登場するため、人気の観点から何が起こるかは不明です...しかし、野生のFWIWにはいくつかの.lzファイルがあるようです..。。