为什么 * . tar.gz 仍然比 * . tar.xz 更常见？

每当我看到一些用 GZip 压缩的源代码包或二进制文件时，我想知道是否仍然有理由支持 gz 而不是 xz (不包括到2000年的时间旅行) ，LZMA 压缩算法的节省是巨大的，解压缩并不比 GZip 差多少。

57817 次浏览
小开
最佳答案

“最小公分母”。节省的额外空间很少抵得上互操作性的损失。大多数嵌入式 Linux 系统都有 gzip，但是没有 xz。还有很多旧系统。Gnu Tar 是行业标准，它支持标志 -z通过 Gzip,进行处理，支持 -j通过 Bzip2进行处理，但是一些老系统不支持 -j0的 -J标志，这意味着它需要两步操作(对于未压缩的 .tar，需要大量额外的磁盘空间，除非你使用 |tar xf -的语法——很多人不知道这一点)此外，从嵌入式 ARM 上的 tar.gz解压缩大约10MB 的完整文件系统需要大约2分钟，这并不是一个真正的问题。没有关于 xz的线索，但 bzip2大约需要10-15分钟。绝对不值得节省带宽。

小开

出于同样的原因，Windows (r)中的人们使用 zip 文件而不是7zip，有些人仍然使用 rar 而不是其他格式... ... 或者在音乐中使用 mp3而不是 aac + ，等等。

每种格式都有其优点，人们习惯于坚持使用他们在开始使用计算机时学到的解决方案。再加上向下兼容和快速带宽 + GB 或 TB 的硬盘空间，更大压缩的好处就不那么重要了。

小开

说实话，我只是想知道。Xz 格式的培训材料。所以我只是用它的 git 回购做了一个测试。Git 是 git:// git.free-electrons.com/training-materials.git ，我还编辑了三张培训幻灯片。目录的总大小为91M，混合了文本和二进制数据。

这是我的快速结果。也许人们仍然喜欢 tar.gz 仅仅是因为它压缩起来更快？我个人甚至在压缩没有太多好处的时候使用普通的 tar。

[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
小开

最终的答案是可访问性，第二个答案是目的性。XZ 不一定像 Gzip 那样适合的原因:

  • 嵌入式系统和遗留系统更有可能缺乏足够的可用内存来解压缩 LZMA/LZMA2归档文件，例如 XZ。例如，如果 XZ 可以从一个打包到 OpenWrt 路由器的包中削减400 KiB (相对于 Gzip) ，那么如果路由器有16 MiB 的 RAM，那么这个小小的空间节省又有什么用呢？类似的情况出现在非常古老的计算机系统中。人们可能会嘲笑在一个拥有32MB 内存的老式 SparcStation LX 上下载和编译最新版本的 Bash，但这种情况确实发生了。

  • 这样的系统通常具有较慢的处理器，解压缩时间的增加可能非常快。对于200MHz ARM 核心或50MHz microSPARC 来说，在 Core i5上额外减压三秒钟可能会非常长。与所有更好的压缩方法(如 XZ 或甚至 Bzip2)相比，Gzip 压缩在这类处理器上的速度非常快。

  • 过去20年中创建的每个类 UNIX 系统(以及几乎所有非类 UNIX 系统)都普遍支持 Gzip。XZ 的可用性要有限得多。没有减压的能力，压缩是无用的。

  • 更高的压缩要花很多时间。如果压缩时间比压缩比更重要，那么 Gzip 胜过 XZ。老实说，lzop 比 Gzip 快得多，而且压缩效果还不错，所以那些需要尽可能快的压缩速度并且不需要 Gzip 无处不在的应用程序应该考虑这一点。我经常使用诸如“ tar-c * | lzop -1 | socat-u-tcp-connect: 192.168.0.101:4444”之类的命令在可信的局域网连接上快速移动文件夹，Gzip 也可以在速度慢得多的链接上使用类似的命令(例如，我刚才通过 Internet 上的 SSH 隧道做同样的事情)。

现在，在另一方面，有些情况下 XZ 压缩是非常优越的:

  • 通过慢速链接发送数据。Linux 3.7内核的源代码在 xZ 格式下比 Gzip 格式小34 MiB。如果你有一个超级快速的连接，选择 XZ 可能意味着节省一分钟的下载时间; 在一个便宜的 DSL 连接或3G 蜂窝连接，它可以节省一个小时或更多的下载时间。

  • Shrinking backup archives. Compressing the source code for Apache's httpd-2.4.2 with "gzip-9" vs. "xz -9e" yields an XZ archive that is 62.7% the size of the Gzip archive. If the same compressibility exists in a data set you currently store as 100 GiB worth of .tar.gz archives, converting to .tar.xz archives would cut a whopping 37.3 GiB off of the backup set. Copying this entire backup data set to a USB 2.0 hard drive (maxing out around 30 MiB/sec transfers) as Gzipped data would take 55 minutes, but XZ compression would make the backup take 20 minutes less. Assuming you'll be working with these backups on a modern desktop system with plenty of CPU power and the one-time-only compression speed isn't a serious problem, using XZ compression generally makes more sense. Why shuffle around extra data if you don't need to?

  • 分发可能高度可压缩的大量数据。如前所述，Linux 3.7的源代码是67 MiB。和101MiB。未压缩的源代码大约是542MiB，几乎全部是文本。由于内容中存在大量的冗余，源代码(以及一般的文本)通常是高度可压缩的，但是像 Gzip 这样使用小得多的字典的压缩器不能利用超出字典大小的冗余。

Ultimately, it all falls back to a four-way tradeoff: compressed size, compression/decompression speed, copying/transmission speed (reading the data from disk/network), and availability of the compressor/decompressor. The selection is highly dependent on the question "what are you planning to do with this data?"

也是从 看看这篇相关的文章中我学到了一些我在这里重复的东西。

小开

我在1.1 GB 的 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 英特尔 I73740QM，内存32 GB 1600，源和目的地的 RAM 磁盘

I Generally use rar or 7z for archiving normal files like documents.
以及存档我使用的系统文件。或。通过 file-roller 或 tar with-z 或-J 选项以及—— keep 来使用 tar 进行本机压缩并保留权限(也可以选择使用。焦油7Z 或。可以使用 tar.rar)

update: as tar only preserve normal permissions and not ACLs anyway, also plain .7z plus backup and restoring permissions and ACLs manually via getfacl and sefacl can be used which seems to be best option for both file archiving or system files backup because it will full preserve permissions and ACLs, has checksum, integrity test and encryption capability, only downside is that p7zip is not available everywhere

小开

Gzip 的另一个重要特点是它可以与 Rsync/zsync互操作。在某些情况下，这可能对带宽带来巨大的好处。LZMA/bzip2/xz 不支持 rsync，可能不会很快支持它。
LZMA 的特点之一是采用安静的大窗口。为了使它的 Rsync/zsync友好，我们可能需要减少这个窗口，这将降低它的压缩性能。

小开

Gz 在任何地方都受到支持，并且有利于可移植性。

Xz 比较新，现在已经得到了广泛或良好的支持，它比 gzip 更复杂，有更多的压缩选项。

这不是人们不总是使用 xz 的唯一原因。Xz 可能需要很长的时间来压缩，而不是一个微不足道的时间量，所以即使它可以产生更好的结果，也不一定总是选择它。另一个缺点是它可能使用大量内存，特别是用于压缩。你越想压缩一个项目，所需的时间就越长，这个报酬递减是指数级的。

然而，根据我的经验，对于大型二进制项，在压缩级别1，xz 通常可以在比级别9的 zlib 更短的时间内产生更小的结果。这有时可能是一个非常显著的差异，与 zlib 同时，xz 可以创建一个只有 zlib 文件一半大小的文件。

Bzip2处于类似的情况，但是 xz 具有非常优越的优势和强大的窗口，在这个窗口中它的各方面性能都明显更好。

小开

来自 Lzip 压缩实用程序的作者:

Xz 具有复杂的格式，部分专门用于压缩 可执行文件，并设计为由专有格式扩展 四个压缩器在这里测试，xz 是唯一一个外来的 Unix “做好一件事”的概念 appropriate for data sharing, and not appropriate at all for long-term 存档。

一般来说，格式越复杂，可能性就越小 但是 xz 格式，就像它臭名昭著的 前身 lzma-alone，是特别糟糕的设计。 Xz 几乎复制 所有 gzip 的缺陷，然后添加一些更多的，如易碎 可变长度的整数。只需在任意字节的第7位进行一次位翻转 一个可变长度的整数，整个 xz 流就会崩溃 就像纸牌搭成的房子。使用 xz 除了 不建议压缩短命的可执行文件。

不要误解我的意思，我非常感谢伊戈尔 · 巴甫洛夫 发明/发现 LZMA，但 xz 是他的第三次尝试 followers to take advantage of the popularity of 7zip and replace gzip 和 bzip2，其格式不适当或设计糟糕, it is shameful that support for lzma-alone was implemented in both GNU 和 Linux。

http://www.nongnu.org/lzip/lzip_benchmark.html

小开

是的，我的想法是，最初的问题可以被放置为“为什么 tar.gz 比 tar.lz 更常见”(因为 lz似乎压缩 slightly better比 xz，xz是一个不好的归档选择 说，虽然确实提供了一些很好的功能，如随机访问)。我想答案是人们习惯于使用“动力”，有很好的库支持，等等。Lz 的引入可能意味着 xz 现在增长不那么快了，FWIW..。

然而，也就是说，lz 出现在 慢慢减压比 xz，和有新的东西在地平线上像布罗特利，所以还不清楚会发生什么在流行方面... 但我似乎有几个。LZ 文件在野外 FWIW..。


提交答案