ZFS 快照回滚的速度是否取决于文件数量？

Question

我已经测试了两台主机之间的 10Gbit 连接，以便能够从 host1 读取 10GB 文件并使用 netcat 将其写入 host2，其速度为 410MB/s。

当我通过相同的专用 10Gbit 连接使用 netcat 再次进行 ZFS 发送/接收时，我只能获得 70MB/s。快照为 2.5TB，包含 1500 万个文件。

题

这种放缓的原因可能是什么？瓶颈是回滚这么多文件的快照需要很多时间，还是文件数量不受ZFS回滚速度的影响？

更新

10GB 文件传输测试，我得到了 410MB/s，我想模拟了带回滚的 ZFS 发送/接收。因此，根据这个假设，我看到如此不同的速度让我感到非常惊讶。我使用速度来比较两个测试，所以我不必用随机数据生成 2.5TB 文件。

所以我不明白为什么“从主机 1 读取文件，使用 netcat 传输，将文件写入主机 2”比“zfs 从主机 1 发送快照，使用 netcat 传输，主机 2 上的 ZFS 接收/回滚”要快得多。

也许另一种问同样的方法是？：

如果我有两个相同大小的 2.5TB 快照，其中快照 1 包含 1 个文件，快照 2 包含 1500 万个文件。zfs receive他们两个的时间会一样吗？或者一个会比另一个更快？

Answer 1

zfs 发送/接收流中涉及的文件和目录的数量应该对其传输速度没有直接影响。间接地，它可能，因为通常说数据集在磁盘上的“传播”会随着目录/文件的增加而更高，这取决于生成它们的工作负载。这很重要，因为硬盘进行顺序读取比随机读取容易得多——如果有问题的流遍布整个磁盘，那么随机读取工作负载将比顺序读取工作负载更多。

此外，据我所知，ZFS 文件系统（而不是 zvol）上的文件涉及 ZFS 元数据；我没有直接数字，但对于一个 2.5 TB 的文件，总的来说，与其相关的元数据块明显少于 2.5 TB 的 1500 万个文件，我对此并不感到惊讶。这些（可能很多）额外的元数据块将添加更多必须读取的数据，从而进行更多的磁盘读取（和潜在的查找）。所以是的，很可能间接地，由 1500 万个文件组成的发送流的创建速度可能比由相同大小的单个文件组成的发送流慢（特别是如果一个文件是一次性创建的，作为顺序写入，在当时有大量连续可用空间的游泳池上）。

无缓冲发送的 ZFS 发送/接收流具有非常参差不齐的性能是很常见的 - 有时它们似乎运行得非常快，然后可能在很长一段时间内几乎为零。网上各种论坛已经对这种行为进行了一定程度的描述甚至分析，在此不再赘述。一般的结论是，虽然 ZFS 可以而且应该做一些工作来使其在内部成为更高效的工作流程，但对许多问题的“快速修复”是在发送端和接收端引入缓冲区。为此，最常用的工具是“mbuffer”。

通过在 netcat 之前通过 mbuffer 管道发送 zfs（并在 zfs recv 之前再次通过 mbuffer），如果潜在问题是添加缓冲区可以帮助解决的问题，您应该会看到显着的改进。Alasdair 在他的博客上有一篇简短的文章——我目前没有关于这个主题的任何内容，所以我会指向他的：http : //blogs.everycity.co.uk/ alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

Answer 2

速度差异较大的原因是传输文件和快照无法进行比较。文件是顺序 I/O，快照是随机 I/O，因为它包含已更改的块。