ZFSスナップショットのロールバックの速度はファイルの数に依存しますか？
2つのホスト間の10Gbit接続をテストして、Host1から10GBのファイルを読み取り、netcatを使用してHost2に書き込むことができるようにしました。速度は410MB/sでした。
同じ専用の10Gbit接続を介してnetcatでZFSを再度送受信すると、70MB /秒しか得られません。スナップショットは2.5TBで、1500万ファイルでした。
質問
この減速の理由は何でしょうか？これだけ多くのファイルを含むスナップショットをロールバックするのに時間がかかるというボトルネックですか、それともファイルの数がZFSロールバック速度に影響を与えないのでしょうか。
更新
410MB /秒で取得した10GBのファイル転送テストは、ロールバックを使用したZFSの送受信をシミュレートしていると思います。ですから、その仮定で、私は非常に異なる速度を見ることに非常に驚いています。 2つのテストの比較に速度を使用しているので、ランダムデータを含む2.5TBファイルを生成する必要はありません。
したがって、「Host1からファイルを読み取り、netcatで転送し、Host2にファイルを書き込む」が、「zfsがHost1からスナップショットを送信し、netcatで転送し、Host2でZFSを受信/ロールバックする」よりもはるかに高速である理由がわかりません。
たぶん同じことを尋ねる別の方法は？：
同じサイズの2,5TBスナップショットが2つある場合、snapshot1には1つのファイルが含まれ、snapshot2には1500万のファイルが含まれます。両方のzfs receiveの時間は同じですか？それとも、一方が他方よりも速いでしょうか？
Zfs send/recvストリームに含まれるファイルとディレクトリの数は、その転送速度に直接影響を与えないはずです。間接的には、ディスク全体のデータセットの「広がり」は、それらを生成したワークロードに応じて、ディレクトリ/ファイルが多いほど高くなると言うのが通常は正しいためです。これは重要です。ハードディスクはランダム読み取りよりもシーケンシャル読み取りを実行する方がはるかに簡単です。問題のストリームがディスク全体にある場合は、シーケンシャルよりもランダム読み取りのワークロードがはるかに多くなります。
さらに、（zvolではなく）ZFSファイルシステム上のファイルにZFSメタデータが含まれていることを理解しています。直接の番号はありませんが、1つの2.5 TBファイルに関連付けられているメタデータブロックが、1500万でいっぱいの2.5 TBよりも大幅に少ないことは驚くことではありません。ファイル。これらの（潜在的に多くの）追加のメタデータブロックは、読み取る必要のあるデータを追加するため、より多くのディスク読み取り（および潜在的にシーク）が実行されます。そうです、間接的に、1500万ファイルで構成される送信ストリームは、同じサイズの単一ファイルで構成される送信ストリームよりも作成に時間がかかる可能性があります（特に、その1つのファイルが順次書き込みとして一度に作成された場合、当時、連続した空きスペースがたくさんあるプールで）。
バッファなしで送信されるZFSsend/recvストリームのパフォーマンスが非常に不安定になることは非常に一般的です。場合によっては、非常に速く進行しているように見え、その後、潜在的に長期間にわたってほとんどゼロになります。この動作は、インターネット上のさまざまなフォーラムで説明され、ある程度分析されているため、ここでは説明しません。一般的なポイントは、ZFSは内部でより効率的なワークフローにするためにいくつかの作業を行うことができ、行う必要がありますが、多くの問題の「迅速な修正」は、送信側と受信側にバッファーを導入することです。このため、最も一般的なツールは「mbuffer」です。
Zfs送信をnetcatの前にmbufferを介して（そして再びzfs recvの前にmbufferを介して）パイプすることにより、根本的な問題がバッファーの追加が支援できる問題である場合、著しい改善が見られるはずです。 Alasdairのブログには、簡潔な記述があります。現時点では、このトピックについて何も公開されていないので、彼のことを紹介します。 http：//blogs.everycity。 co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/