Das Lesen von ZFS-Momentaufnahmen vom Band ist langsam

538
chew socks

Ich habe meinen zfs-Schnappschuss mit dem Band gesichert

zfs send tank/vertex@2017-01-20 | pv -cCTrbB 1g | pigz -c | pv -cCTrbB 1g | dd of=/dev/nst0 bs=1M

und lesen Sie es dann mit

dd if=/dev/nst0 bs=1M | pv -c | gzip -dc | ztreamdump

und es geht mit einer Spitzengeschwindigkeit von 39 MiB/s, die viel langsamer ist als die 77 MiB/s, bei der es geschrieben wurde.

EDIT: Ich habe gerade versucht, das Band mit zu füllen dd if=/dev/urandom of=/dev/nst0 bs=1M count=1kund konnte es dann wieder lesen 99 MiB/s.

1
Was passiert, wenn Sie nur Rohdaten vom Band lesen? (zB nur die DD zu einer Datei). Wenn das schnell ist, was passiert, wenn Sie "pv" aus der Pipe entfernen? Nur um Dinge in kleine und überprüfbare Teile zu zerlegen. Hennes vor 7 Jahren 1
@Hennes Danke für den Vorschlag! Ich habe es einfach in beide Richtungen ausprobiert (rohes "dd" mit und ohne "pv") und die Ergebnisse waren dieselben wie im ursprünglichen Fall. chew socks vor 7 Jahren 0
Ich weiß nicht, ob das der Fall ist, aber Sie verwenden "pigz" zum Komprimieren und "gzip" zum Dekomprimieren. Ersteres kann viele CPU-Kerne verwenden. "man pigz" sagt, "Dekompression kann nicht parallelisiert werden". Vielleicht ist das dein Engpass. Überprüfen Sie die CPU-Auslastung sowohl beim Schreiben als auch beim Lesen. Vergleiche mit dem ersten Befehl, bei dem "pigz" durch "gzip" ersetzt wird. Das ist (noch) keine Antwort, weil ich nur vermute. Kamil Maciorowski vor 7 Jahren 2
@KamilMaciorowski Sie haben recht, ein potenzieller Engpass, außer dass die Dekomprimierung "gzip" viel schneller ist als die Komprimierung. Indem wir Hannes Vorschlag folgen, können wir das Kompressionsprogramm aus dem Test herausnehmen. chew socks vor 7 Jahren 0
Siehe oben, ich habe den Test gerade mit zufälligen Eingabedaten anstelle von Daten aus einem ZFS-Dateisystem versucht und konnte ihn mit voller Geschwindigkeit lesen. chew socks vor 7 Jahren 0
`gzip` Dekompression ist viel schneller als die Komprimierung - richtig. Bei genügend Prozessoren kann die 'pigz'-Komprimierung mit der' gzip'-Dekomprimierung gewinnen, vor allem, wenn Sie nicht mit -9` zum Komprimieren arbeiten. Ich weiß nicht, wie viele Kerne Sie insgesamt haben. Um die Dekompressionsgeschwindigkeit zu messen, legen Sie einen großen Block (den Anfang) Ihres Archivs in den Speicher (wie `/ dev / shm`) und dann` pv chunk | gzip -dc> / dev / null`. Kamil Maciorowski vor 7 Jahren 0
Welche Lesegeschwindigkeit erzielen Sie, wenn Sie am Ende den `ztreamdump` weglassen? Werfen Sie die dekomprimierten Daten einfach nach / dev / null und teilen Sie uns mit, welche Lesegeschwindigkeiten Sie dann erhalten. Dies würde uns sagen, ob ztreamdump die zusätzliche Zeit benötigt, um die Daten zu verarbeiten, denen es zugeführt wird. a CVn vor 7 Jahren 0
@ MichaelKjörling Ich habe ungerade Ergebnisse. `dd if = / dev / nst0 bs = 1M | pv> / dev / null` ergab am Anfang des Bandes 50 MiB / s und unmittelbar danach 36 MiB / s. Danach wurden dieselben Daten, jedoch verschlüsselt, um sicherzustellen, dass sie nicht komprimierbar waren. chew socks vor 7 Jahren 1
Ich habe ein nerviges Gefühl, dass es eine schlechte PCI-Karte sein könnte. Das würde die weniger einfachen Dinge erklären, die ich gesehen habe. chew socks vor 7 Jahren 0

1 Antwort auf die Frage

1
Riux

Ich hatte ähnliche Probleme. 1) Verwenden Sie für beide Tests dasselbe Band?

Ich werde versuchen, eine lange Antwort zu geben, da ich diese Informationen auf LTO-Bändern gefunden habe. Dies ist eine der guten Referenzen für Laufwerk- / Bandabfragen von IBM, die von Oracle gehostet werden: GA32-0450-07 .

Meine Antwort: Einige LTO-Bänder sind alt-neu (neu und vor einigen Jahren hergestellt, aber nie verwendet), bereits verwendet und als neu zertifiziert oder neu gekennzeichnet (neu, aber nicht ausreichend während des Transports / der Lagerung gelagert). Darüber hinaus erwähnen einige Anbieter möglicherweise keine Rezertifizierung und werben lediglich als neues Band.

Fujitsu hat 50 erneut zertifizierte Bänder ausprobiert, 16 von ihnen hatten "unzulässig hohe Lese-, Schreib- und Servofehlerraten, die wahrscheinlich auf übermäßigen Verschleiß und Kantenschäden durch falsche Handhabung oder falsch ausgerichtetes Bandlaufwerk zurückzuführen sind".

Um zu überprüfen, wie viele Lese- und Ladevorgänge das Band hatte oder Lese- und Schreibfehler, verwenden Sie sg_logs -a /dev/st0Abschnitt 30h. Es werden viele nützliche Informationen ausgegeben!

Ich glaube, dass es möglich ist, den RFID-Chip auf dem Band zu überschreiben. Darin werden alle Informationen protokolliert. Aber wenn du dein neues verbrennst ? Band (schreibe / lese volles Band) und überprüfe es zurück und es ( sg_logs) hat Fehler, du weißt, dass dein Band nicht in gutem Zustand ist.

Tipp für neue Bänder: Erstellen Sie eine große zufällige Datei mit der Größe des LTO-Bands und die Prüfsumme sha512, schreiben Sie sie auf Band, lesen Sie sie vom Band zurück, prüfen Sie, ob die Prüfsumme noch in Ordnung ist, und lesen Sie die Lese- / Schreibgeschwindigkeit. Vergleichen Sie die Fehlerprotokolle auf Laufwerk / Band vor und nach. Vergiss nicht zu benutzen mbuffer! Wenn alles gut ist, können Sie Ihr Band in Produktion bringen. Burn-In wird auf neuem HD verwendet, Blackblaze und deren Definition von Burn-In überprüfen: "Dies erfordert, dass jeder Block auf jedem Laufwerk gelesen und geprüft wird".

Überwachen Sie diese Zahlen (von sg_logs) und wenn ein Band hohe Fehler aufweist, müssen Sie die Gesamtzahl der geschriebenen Daten / Bandgröße> 250 oder die Ladezählung gegen 3000 ersetzen.

Sie könnten immer noch eine Kopie der Daten darauf lassen, aber bestimmte alte Bänder (used-ebay) von mir lesen nur bei 5-30 MB / s zurück, da das Laufwerk zu viele Fehler aufweist, um korrigiert zu werden (Schreiben ist immer noch volle Geschwindigkeit). Aber sie funktioniert immer noch und wird sie in 20-30 Jahren überprüfen müssen, um zu sehen, ob sie noch lesbar sind. LTO-Bänder werden mit Reed-Solomon-Code codiert, sodass Fehler behoben werden können. Einige verwendete Bänder stammen aus umfangreichen Sicherungsbibliotheken und wurden einige Jahre lang einmal pro Woche oder einmal täglich geschrieben. Sie sollten sie also nur überprüfen, um sicherzustellen, dass Sie Ihren Daten vertrauen können. Wenn Sie unternehmenskritische Backups erstellen, können Sie sie direkt von HP oder einem anderen offiziellen Anbieter beziehen. Wenn es sich nur um Gelegenheitsgegenstände handelt und Sie einige Male auf verschiedenen billigen Bändern kopiert werden können, kann es sich lohnen, LTO-Bänder zu verwenden, um $$$ zu sparen. Dann wieder,echtes neues Band.

Lebenserwartung von LTO von HPe : "Im offiziellen Text heißt es:" Ultrium-Medien sind für 1 Million Pässe oder 260 vollständige Backups zertifiziert und haben eine 30-jährige Archivierungsdauer. "

Es scheint jedoch so, als würden Sie in der Lage sein, ein Band fast ein ganzes Jahr täglich zu sichern, bevor Sie Medienfehler sehen. "

Verwandte Probleme