我testing了两台主机之间的10Gbit连接，以便能够从host1读取10GB文件，并使用netcat将其写入host2，速度为410MB / s。
当我通过同一个专用的10Gbit连接与netcat再次发送/接收时，我只能获得70MB / s。 快照是2.5TB，有1500万个文件。
题
这种放缓的原因是什么？ 使用这么多文件回滚快照需要花费很多时间，还是文件数量不受ZFS回滚速度的影响？
更新
10GB的文件传输testing，我得到了410MB / s的，我想模拟一个ZFS发送/接收与回滚。 所以有了这个假设，我很惊讶，我看到如此不同的速度。 我正在使用两个testing之间的比较速度，所以我不必生成随机数据2.5TB文件。
所以我不明白为什么“从host1读取文件，使用netcat传输，写入文件到host2”要比“zfs从host1发送快照，使用netcat传输，在host2上使用ZFS接收/回滚”快得多。
也许另一种方式来问同样的事情会是？
如果我有两个相同大小的2,5TB快照，其中snapshot1包含1个文件，snapshot2包含1500万个文件。 两个zfs receive的时间是一样的吗？ 或者会比另一个更快？
涉及zfs send / recvstream的文件和目录的数量不应该直接影响其传输速度。 间接地说，这可能是因为通常情况下，数据集在磁盘上的“传播”会随着更多的目录/文件而变得更高，这取决于生成它们的工作量。 这很重要，因为硬盘比顺序读取要容易得多，而且如果所涉及的数据stream遍布在磁盘上，那么随机读取的工作量将比顺序的多得多。
此外，我的理解是ZFS文件系统（而不是zvols）上涉及到ZFS元数据。 我没有直接的数字，但对于单个2.5TB的文件，总的来说，与2.5TB和1500万个文件相关的元数据块要less得多，我不会感到惊讶。 这些（可能很多）额外的元数据块将会添加更多的必须被读取的数据，因此更多的磁盘读取（和潜在的查找）正在进行。 所以是的，很可能间接地，包含1500万个文件的发送stream可能比包含相同大小单个文件的发送stream慢（特别是如果一个文件是一次性创build的，作为顺序写入，在当时有充足的连续可用空间的游泳池）。
ZFS发送/ recvstream非缓冲发送非常常见，性能非常差，有时它们看起来很快，然后在很长一段时间内几乎没有任何变化。 这个行为在互联网上的各种论坛上已经有所描述甚至有所分析，所以我不会介入。 总的来说，ZFS可以而且应该做一些内部更高效的工作stream程，而对于许多问题的“快速解决”就是在发送和接收端引入一个缓冲区。 为此，最常用的工具是“mbuffer”。
通过在netcat（通过zfs recv之前再次通过mbuffer）之前通过pipe道将zfs发送到mbuffer，如果潜在的问题是添加缓冲区可以帮助的话，您应该看到明显的改进。 阿拉斯代尔在他的博客上写了一篇简短的文章 – 目前我还没有发表关于这个话题的任何内容，所以我会告诉你他的： http : //blogs.everycity.co.uk/阿拉斯代尔/ 2010/07 /使用-mbuffer对加速慢，ZFS-发送-ZFS-接收/
速度差别很大的原因是因为传输文件和快照是无法比较的。 文件是顺序I / O，快照是随机I / O，因为它包含已更改的块。