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

Question

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

Answer 1

最终的答案是可访问性,目的是次要答案.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这样的压缩器使用小得多的字典操作不会利用超出字典大小的冗余.

最终,这一切都回归到四方面的权衡:压缩大小,压缩/解压缩速度,复制/传输速度(从磁盘/网络读取数据),以及压缩器/解压缩器的可用性.选择高度依赖于"你打算用这些数据做什么？"的问题.

另请查看这篇相关文章,从中我学到了一些我在这里重复的内容.

Answer 2

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

Answer 3

我在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无处不在

Answer 4

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

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

通常,格式越复杂,将来解码的可能性就越小.但xz格式,就像它臭名昭着的前任lzma一样,特别糟糕的设计.Xz几乎复制了gzip的所有缺陷,然后添加了更多,比如脆弱的可变长度整数.在一个可变长度整数的任何字节的第7位中只有一位翻转,整个xz流像纸牌屋一样翻滚.除了压缩短期可执行文件之外的任何其他操作都不建议使用xz.

不要误解我.我非常感谢Igor Pavlov发明/发现LZMA,但xz是他的追随者第三次尝试利用7zip的流行并用不合适或设计糟糕的格式替换gzip和bzip2.特别是,在GNU和Linux中都实现了对lzma-alone的支持是可耻的.

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

Answer 5

老实说,我只是从培训材料中了解.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