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

时间：2011-06-27 13:05:21

标签： zip compression lzma xz

每当我看到一些使用GZip压缩的源包或二进制文件时，我想知道是否还有理由支持gz超过xz（不包括到2000年的时间旅行），LZMA压缩算法的节省是巨大的，并且解压缩不是比gzip更差。

9 个答案:

答案 0 :(得分：65)

最终的答案是可访问性，目的是次要答案。 XZ不一定像Gzip那样合适的原因：

  • 嵌入式和遗留系统更有可能缺乏足够的可用内存来解压缩LZMA / LZMA2档案，例如XZ。例如，如果XZ可以从发往OpenWrt路由器的软件包中削减400 KiB（相对于Gzip），那么如果路由器具有16 MiB的RAM，那么节省的空间有多大呢？类似的情况出现在很老的计算机系统中。人们可能会嘲笑在具有32MB RAM的古老SparcStation LX上下载和编译最新版Bash的想法，但它确实发生了。

  • 此类系统通常具有较慢的处理器，并且减压时间增加可能非常高。在200 MHz ARM内核或50 MHz microSPARC上，Core i5上的三分钟额外解压缩时间可能会非常长。与所有更好的压缩方法（如XZ甚至Bzip2）相比，Gzip压缩在这些处理器上的速度非常快。

  • Gzip在过去二十年中创建的每个类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内核源代码的XZ格式比Gzip格式小34 MiB。如果你有超快的连接，选择XZ可能意味着节省一分钟的下载时间;在廉价的DSL连接或3G蜂窝连接上，它可以减少一个小时或更长的下载时间。

  • 缩小备份档案。使用“gzip-9”与“xz -9e”压缩Apache的httpd-2.4.2的源代码会产生一个XZ存档，其大小为Gzip存档的62.7％。如果数据集中存在相同的可压缩性，您当前存储为100 GiB值的.tar.gz存档，转换为.tar.xz存档将会使备份集减少37.3 GiB。将整个备份数据集复制到USB 2.0硬盘驱动器（最大约30 MiB /秒传输），因为Gzip压缩数据需要55分钟，但XZ压缩会使备份时间减少20分钟。假设您将在具有充足CPU功率的现代桌面系统上使用这些备份，并且一次性压缩速度不是一个严重的问题，使用XZ压缩通常更有意义。如果您不需要，为什么要在附加数据上进行随机播放？

  • 分发可能高度可压缩的大量数据。如前所述，Linux 3.7源代码为.tar.xz为67 MiB，.tar.gz为101 MiB;未压缩的源代码大约是542 MiB，几乎完全是文本。源代码（和一般文本）通常是高度可压缩的，因为内容中的冗余量很大，但是像Gzip这样的压缩器使用小得多的字典操作不会利用超出字典大小的冗余。 / p>

最终，这一切都回归到四方面的权衡：压缩大小，压缩/解压缩速度，复制/传输速度（从磁盘/网络读取数据）以及压缩器/解压缩器的可用性。选择高度依赖于“您打算如何处理这些数据？”这个问题。

同样check out this related post我从中学到了一些我在这里重复的事情。

答案 1 :(得分：61)

“最低公分母”。节省的额外空间很少值得失去互操作性。大多数嵌入式Linux系统都有gzip，但不是xz。许多旧系统也是如此。作为行业标准的Gnu Tar支持标记-z通过 gzip，和-j处理以通过 bzip2 处理，但是一些旧系统不会t支持 xz 的-J标志，这意味着它需要两步操作（以及未压缩.tar的大量额外磁盘空间，除非您使用{{1}的语法 - 许多人不知道的。）另外，在嵌入式ARM上从|tar xf -解压缩大约10MB的完整文件系统需要大约2分钟，并不是真正的问题。没有关于tar.gz的线索，但xz需要大约10-15分钟。绝对不值得节省带宽。

答案 2 :(得分：11)

我在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来存档文件等普通文件 对于归档系统文件，我使用.tar.gz或.tar.xz by file-roller或tar使用-z或-J选项以及--preserve使用tar本地压缩并保留权限（或者.tar.7z或.tar.rar可以用）

更新：因为tar只保留普通权限而不保留ACL，所以也可以使用普通.7z加上备份和恢复权限以及通过getfacl和sefacl手动恢复ACL，这似乎是文件归档或系统文件备份的最佳选择，因为它将完全保留权限和ACL，具有校验和，完整性测试和加密功能，唯一的缺点是p7zip无处可用

答案 3 :(得分：10)

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

  

Xz具有复杂的格式，部分专门用于压缩   可执行文件，旨在通过专有格式进行扩展。的   在这里测试了四个压缩器，xz是唯一一个与Unix不同的压缩器   “做一件事，做得好”的概念。它少了   适合于数据共享，并且根本不适合长期使用   归档。

     

通常，格式越复杂，它就越不可能   将来要解码。但xz格式，就像它臭名昭着   前身lzma-alone，设计特别糟糕。 Xz几乎复制了   gzip的所有缺陷然后再添加一些，比如脆弱   变长整数。在任何字节的第7位只有一位翻转   一个可变长度的整数和整个xz流来翻滚   像一个纸牌屋。使用xz以外的任何东西   压缩短期可执行文件是不可取的。

     

不要误解我的意思。我非常感谢Igor Pavlov   发明/发现LZMA，但xz是他的第三次尝试   追随者利用7zip的普及并取代gzip   和bzip2格式不合适或设计不当。特别是，   在GNU中实现对lzma-alone的支持是可耻的   和Linux。

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

答案 4 :(得分：8)

老实说，我只是从培训材料中了解.xz格式。所以我只是用它的git repo来做测试。 git是git：//git.free-electrons.com/training-materials.git，我还编写了三张培训幻灯片。总目录大小为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

答案 5 :(得分：3)

出于同样的原因，Windows（r）中的人使用zip文件而不是7zip，有些人仍然使用rar而不是其他格式......或者mp3用于音乐，而不是aac +，依此类推。

每种格式都有它的好处，人们习惯于坚持使用计算机时学到的解决方案。将其添加到硬盘驱动器的向后兼容性和快速带宽+ GB或TB空间中，更大压缩的好处将不再相关。

答案 6 :(得分：3)

gz在任何地方都受支持，并且便于携带。

xz更新，现在广泛或得到很好的支持。它比gzip更复杂，具有更多压缩选项。

这不是人们可能永远不会使用xz的唯一原因。 xz可能需要很长时间才能压缩，而不是很少的时间，所以即使它可以产生出色的结果，也可能并不总是被选中。另一个缺点是它可以使用大量内存，尤其是压缩。您想要压缩项目所需的时间越长，这将是指数递减的指数。

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

bzip2处于类似的情况，但xz具有更优越的优势和强大的窗口，它在整个过程中表现明显更好。

答案 7 :(得分：1)

gzip的另一个重点是它可与 rsync / zsync 互操作。对于带宽情况，这可能是巨大的好处。 LZMA / bzip2 / xz不支持rsync，很可能不会很快支持它 LZMA的一个特点是它使用安静的大窗户。为了使 rsync / zsync 友好，我们可能需要减少此窗口，这会降低其压缩性能。

答案 8 :(得分：1)

是的，我的想法是原来的问题可能会被搁置，因为“为什么tar.gz比tar.lz更常见”（因为lz似乎压缩slightly better而不是{{} 1}}，xz said是归档的不良选择，但确实提供了一些不错的功能，如随机访问）。我想答案是人们习惯使用它的“动力”，有很好的图书馆支持等等。 lz的引入可能意味着现在xz的增长速度会降低，FWIW ......

然而，话虽如此，lz似乎decompress slower而不是xz，并且像Brotli一样有新的东西在地平线上，因此不清楚在受欢迎程度方面会发生什么......但我似乎有一些。野外FWIW中的lz文件...

相关问题
最新问题