从stdin缓冲器中提取焦油时断裂的管道

Question

我正在将LTO-7磁带上的tar存档文件还原到本地安装的网络共享中。如果我直接恢复到共享，它运行非常缓慢(90 MB/s)。当我使用额外的缓冲区时，我的最大吞吐量为280 MB/s。

mbuffer -s 1M -m 2G -i /dev/st0 | tar -xf -
mbuffer: warning: error during output to <stdout>: Broken pipe

请注意，tar存档最初编写时的阻塞因子为2048 (即1MB块大小)。

我猜这意味着tar在接收到所有数据之前就退出了(可能缓冲区暂时变为空，而tar认为数据已经结束了？)。

1. 我怎么才能避开这一切？也就是说，如何确保tar等待从缓冲区接收所有数据？
2. 为什么一开始就需要缓冲呢？连接是10G，目标磁盘是一个非常快的RAID。导致经济放缓的根本原因是什么？

编辑02/07/2020

我在tar命令中添加了阻塞因子，警告就不会出现。

mbuffer -s 1M -m 2G -i /dev/st0 | tar -x -b 2048 -f -

但我仍然想知道，如果没有具体说明，为什么我会收到一个断管警告。

Answer 1

您的错误消息有一个简单的原因:您使用的tar实现没有读取调用exit()的所有数据。

这是由于没有告诉它真正的磁带块大小而造成的(正如您自己已经发现的那样)。

一个典型的磁带，除了QIC墨盒被阻塞和更高的性能，它建议使用大块大小。不建议与其他人交换块大小>126个kB，但是对于备份，可以使用1MB作为块大小。

另一侧的TAR也指定为面向工作块的，默认块大小为10 as。

一个EOF存档的TAR定义是直接在最后一个文件之后的两个零的512个块(这是一个新的tar头的位置)。

在EOF指示之后，归档处理停止，除非这两个零块偶然出现在磁带数据的最后10 kB中，否则会有未读的输入，这就是为什么您会得到一条坏掉的管道消息。

如果使用star，则FIFO在tar中，因此，磁带读取代码和tar存档处理总是对磁带块大小有相同的想法。除了star在速度上更有效这一事实之外，这还避免了并非所有输入数据都是从tar archive消耗的问题。

顺便说一句:对于最优的流，建议使用FIFO缓冲区大小，以最大的磁带速度持续10-30秒的数据。在完全增强star以支持更大的FIFO之前，我建议您调用：

star fs=2000m ...

注意:30年来，-fifo是star的默认设置。还请注意，在Linux上不推荐类似-shm这样的选项，因为这种功能的内存量是有限的。

star绝对比任何其他tar实现都快。但是，请记住，如果您使用的是COW文件系统(如ZFS )，或者您的操作系统具有缓慢的内核缓冲实现，则建议在提取模式下通过-no-fsync快速禁用fsync()调用。这使得star与其他tar实现一样“不可靠”;-)因为无法知道文件在后台存储中是否安全，但这会使ZFS上的提取速度提高4倍，或者传统的文件系统存在糟糕的缓冲区。然而，ZFS没有实现糟糕的缓冲，只是能够以高昂的代价授予特定的文件系统状态。