首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >为什么*.tar.gz仍然比*.tar.xz普遍得多?

为什么*.tar.gz仍然比*.tar.xz普遍得多?
EN

Stack Overflow用户
提问于 2011-06-27 21:05:21
回答 8查看 54K关注 0票数 74

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

EN

回答 8

Stack Overflow用户

回答已采纳

发布于 2011-06-27 21:25:16

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

票数 71
EN

Stack Overflow用户

发布于 2012-12-16 03:50:06

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

  • 嵌入式和遗留系统更有可能缺乏足够的可用内存来解压缩诸如XZ之类的LZMA/LZMA2存档。例如,如果XZ可以将发往OpenWrt路由器的数据包的KiB (vs. Gzip)减少400,那么如果路由器有16 MiB的内存,节省的空间又有什么好处呢?类似的情况出现在非常旧的计算机系统上。
  • 这类系统的处理器速度通常很慢,解压时间增加会非常快。在200 MHz的ARM内核或50 MHz的microSPARC上,在酷睿i5上额外解压3秒可能会非常长。与所有更好的压缩方法(如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可以在速度更慢的链路上使用类似的方法(即,通过互联网上的SSH隧道执行我刚才描述的相同操作)。

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

  • 通过慢速链路发送数据。Linux3.7内核源代码XZ格式比Gzip格式小34 MiB。如果你有一个超快的连接,选择XZ可能意味着节省一分钟的下载时间;在廉价的DSL连接或3G蜂窝连接上,它可以减少一个小时或更多的下载time.
  • Shrinking备份档案。使用" 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/秒的传输)作为this数据将需要55分钟,但XZ压缩将使备份时间缩短20分钟。假设您将在具有充足CPU能力的现代台式机系统上处理这些备份,并且一次性压缩速度不是一个严重问题,那么使用XZ压缩通常更有意义。如果您不需要to?
  • Distributing大量可能高度可压缩的数据,为什么还要处理额外的数据呢?如前所述,Linux3.7的源代码对于.tar.xz是67 MiB,对于.tar.gz是101 MiB;未压缩的源代码大约是542 MiB,并且几乎全是文本。由于内容中的冗余量,源代码(以及一般的文本)通常是高度可压缩的,但像Gzip这样使用小得多的字典运行的压缩器无法利用超出其字典大小的冗余。

最终,这一切都归结为四个方面的权衡:压缩大小、压缩/解压缩速度、复制/传输速度(从磁盘/网络读取数据)和压缩器/解压缩器的可用性。选择高度依赖于“您打算如何处理这些数据?”这一问题。

还有check out this related post,我从中学到了一些我在这里重复的东西。

票数 67
EN

Stack Overflow用户

发布于 2014-09-18 13:01:21

我在1.1 on的Linux安装vmdk镜像上做了自己的基准测试:

代码语言:javascript
复制
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、英特尔I7 3740QM、内存32 on 1600、源和目标内存磁盘上的所有压缩级别

我通常使用rar或7z来归档像文档这样的普通文件。

对于归档系统文件,我使用.tar.gz或.tar.xz by file-roller,或者使用带有-z或-J选项的tar,以及--preserve来使用tar进行本地压缩并保留权限(也可以使用.tar.7z或.tar.rar )

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

票数 13
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/6493270

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档