Hängt die Geschwindigkeit des ZFS-Snapshot-Rollbacks von der Anzahl der Dateien ab?

Ich habe eine 10-Gbit-Verbindung zwischen zwei Hosts getestet, um eine 10-GB-Datei von Host1 lesen und mit Netcat auf Host2 schreiben zu können, wobei die Geschwindigkeit 410 MB / s betrug.

Wenn ich ZFS erneut mit Netcat über dieselbe dedizierte 10-Gbit-Verbindung sende / empfange, erhalte ich nur 70 MB / s. Der Schnappschuss betrug 2,5 TB mit 15 Millionen Dateien.

Frage

Was könnte der Grund für diese Verlangsamung sein? Ist der Engpass, dass das Rollback eines Snapshots mit so vielen Dateien viel Zeit in Anspruch nimmt, oder hat die Anzahl der Dateien keinen Einfluss auf die ZFS-Rollback-Geschwindigkeit?

Aktualisieren

Der 10-GB-Dateiübertragungstest mit 410 MB / s simuliert vermutlich ein ZFS-Senden / Empfangen mit Rollback. Mit dieser Annahme bin ich sehr überrascht, dass ich so unterschiedliche Geschwindigkeiten sehe. Ich verwende die Geschwindigkeit für den Vergleich zwischen den beiden Tests, sodass ich keine 2,5-TB-Datei mit zufälligen Daten generieren muss.

Ich verstehe also nicht, warum "Datei von Host1 lesen, mit Netcat übertragen, Datei auf Host2 schreiben" viel schneller ist als "ZFS-Snapshot von Host1 senden, mit Netcat übertragen, ZFS empfangen / Rollback auf Host2".

Vielleicht wäre eine andere Möglichkeit, dasselbe zu fragen ,:?

Wenn ich zwei gleich große 2,5-TB-Snapshots habe, wobei Snapshot1 1 Datei und Snapshot2 15 Millionen Dateien enthält. Wird die Zeit für zfs receivebeide gleich sein? Oder wird einer schneller sein als der andere?

Die Anzahl der Dateien und Verzeichnisse, die an einem zfs send / recv-Stream beteiligt sind, sollte keinen direkten Einfluss auf die Übertragungsgeschwindigkeit haben. Indirekt könnte dies der Fall sein, da es normalerweise richtig ist zu sagen, dass die "Verteilung" des Datasets auf Ihre Festplatten mit mehr Verzeichnissen / Dateien höher ist, abhängig von der Arbeitslast, die sie generiert hat. Dies ist wichtig, da es für eine Festplatte weitaus einfacher ist, einen sequentiellen Lesevorgang durchzuführen als einen zufälligen Lesevorgang. Wenn sich der betreffende Stream auf Ihren Festplatten befindet, handelt es sich eher um einen zufälligen Lesevorgang als um einen sequentiellen Lesevorgang.

Nach meinem Verständnis sind in Dateien auf ZFS-Dateisystemen (nicht auf zvols) ZFS-Metadaten enthalten. Ich habe keine direkten Nummern, aber ich wäre nicht überrascht, wenn einer einzelnen 2,5-TB-Datei insgesamt deutlich weniger Metadatenblöcke zugeordnet wären als 2,5 TB mit 15 Millionen Dateien. Diese (möglicherweise vielen) zusätzlichen Metadatenblöcke fügen mehr Daten hinzu, die gelesen werden müssen, wodurch mehr Datenträger gelesen (und möglicherweise gesucht) wird. Ja, es ist wahrscheinlich, dass indirekt ein Sendestream, der aus 15 Millionen Dateien besteht, langsamer erstellt werden kann als einer, der aus einer einzelnen Datei derselben Größe besteht (insbesondere, wenn diese eine Datei auf einmal als sequentielles Schreiben erstellt wurde). auf einem Pool mit viel zusammenhängendem freien Platz zu der Zeit).

Es kommt sehr häufig vor, dass ZFS-Sende- / Empfangs-Streams, die ungepuffert gesendet werden, eine sehr fleckige Leistung aufweisen. Manchmal scheinen sie recht schnell zu verfallen und fallen dann möglicherweise für längere Zeit auf fast nichts. Das Verhalten wurde in verschiedenen Foren im Internet beschrieben und bis zu einem gewissen Grad sogar analysiert, sodass ich nicht darauf eingehen werde. Das allgemeine Problem besteht darin, dass ZFS zwar einige Anstrengungen unternehmen kann und sollte, um den internen Workflow effizienter zu gestalten, eine schnelle Lösung für viele Probleme jedoch darin besteht, einen Puffer auf der Sende- und Empfangsseite einzuführen. Das häufigste Werkzeug hierfür ist 'mbuffer'.

Wenn Sie Ihren zfs-Sendevorgang durch mbuffer vor netcat (und erneut durch mbuffer vor zfs recv) leiten, sollten Sie eine deutliche Verbesserung feststellen, wenn das zugrunde liegende Problem darin besteht, dass das Hinzufügen eines Puffers hilfreich sein kann. Alasdair hat eine knappe Beschreibung in seinem Blog - ich habe momentan nichts zu diesem Thema veröffentlicht, daher verweise ich Sie auf seine: http://blogs.everycity.co.uk/ alasdair / 2010/07 / using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive /

Der Grund für den großen Geschwindigkeitsunterschied liegt darin, dass das Übertragen einer Datei und eines Schnappschusses nicht verglichen werden kann. Eine Datei ist eine sequentielle E / A und ein Snapshot ist eine zufällige E / A, da sie die Blöcke enthält, die sich geändert haben.