看手册
http://lzip.nongnu.org/manual/tarlz_manual.html

Keeping the alignment between tar members and lzip members has two advantages. It adds an indexed lzip layer on top of the tar archive, making it possible to decode the archive safely in parallel. It also minimizes the amount of data lost in case of corruption.

【 在 Dieken 的大作中提到: 】
: http://lzip.nongnu.org/tarlz.html
: 没看到有索引。
: :
--
修改:poocp FROM 118.122.107.*
FROM 118.122.107.*

https://git.progress-linux.org/users/daniel.baumann/debian/packages/tarlz/tree/

此 index 非彼 index, tarlz 没有 zip, dar 那样的文件名到文件偏移量的索引，要解压某个文件或者目录，需要从头到尾遍历。

【 在 poocp 的大作中提到: 】
: 而且你不试试的吗，我展开12GB的日志压缩包用时2秒，前提是这个压缩包必须是tarlz生成的。用tar打包为.tar然后再用lzip或plzip压缩成.tar.lz这种组合是不行的。
: 压缩用最大压缩参数9，其余直接默认参数就行，压缩速度比xz快，因为多线程做得更好，CPU占用率高。
: tarlz -9f 2020.tar.lz 2020
: ...................
--
FROM 61.48.62.*

确实比tar+lzip强，但会卡在IO上。

【 在 poocp 的大作中提到: 】
: tarlz会用尽处理器所有线程做并发，从头到尾也是很快的。
:
--
FROM 221.222.21.*

知道 lzip 的人很少，即使它是 gnu 首推的。即使 lzip 说 xz 很烂，Debian repo还是用 gz+xz，没有lz。即使 zstd 已经碾压 gz, bz2，依然 zstd 远不普及。

还有个 dar，做了那么多年，名气小的可怜。

tarlz 在文件很少，压缩数据很少时不是问题，但如果有几十万文件，几个TB的备份时，没有文件名索引是很悲剧的，这种场景并不是捏造，日志备份，文件系统备份，数据库备份是很典型的。

【 在 poocp 的大作中提到: 】
: 压缩程序这类应用就这么有趣，有了接近100比1的压缩比，解压带宽别说爆掉磁盘和闪存IO，只要CPU核够多，爆掉总线带宽也不是难事。
: 总之瓶颈从解压或者索引已经转移到IO了，解缩程序本身已经不构成瓶颈，tarlz是很成功的多核应用。
:
--
FROM 61.48.62.*

看了下tarlz的文档，的确和tar+lzip不一样，它是在产生的.tar.lzip文件上补充了tar包不存在的元数据，并且还能保证和原有lzip实现的兼容性。

【 在 Dieken (风催草低 - 明月何尝不照人) 的大作中提到: 】
: 知道 lzip 的人很少，即使它是 gnu 首推的。即使 lzip 说 xz 很烂，Debian repo还是用 gz+xz，没有lz。即使 zstd 已经碾压 gz, bz2，依然 zstd 远不普及。
: 还有个 dar，做了那么多年，名气小的可怜。
: tarlz 在文件很少，压缩数据很少时不是问题，但如果有几十万文件，几个TB的备份时，没有文件名索引是很悲剧的，这种场景并不是捏造，日志备份，文件系统备份，数据库备份是很典型的。
: ...................
--
FROM 103.90.178.*