Der geneigte, langjährige Leser meines Blogs erinnert sich vielleicht daran, dass bei mir schon seit vielen Jahren eine Tapelibrary, genauer eine Overland NEO2000, herumoxydiert. Nachdem nun inzwischen auch schon wieder seit fast einem Jahr mein neuer Heimserver läuft und damit auch geeignete Hardware zu beschicken der Library existiert, möchte ich die Library nun endlich in den „Produktivbetrieb” nehmen. Völlig tatenlos sind die Jahre dennoch nicht vorüber gegangen, denn ich habe zusätzlich zum bestehenden LTO-1-Laufwerk (mit klassischem SCSI-Anschluss) noch ein zusätzliches LTO-4-Laufwerk mit Fibre-Channel-Anschluss nachgerüstet. Damit ich keine zwei unterschiedlichen und damit unnötig stromfressenden Controller im Server brauche, habe ich auch eine Fibre-Channel-Bridge (eine auf Overland umgelabelte ATTO FibreBridge 2390C) in die Library eingebaut. Beides hängt nun an einem zweikanaligen Fibre-Channel-Hostadapter „Emulex LPe11002″ mit jeweils 4-GB/s-Links – die FibreBridge mit daran angeschlossener Controller-Card der Library sowie dem LTO-1-Laufwerk an einem Kanal und das LTO-4-Laufwerk am anderen Kanal.
Da als zukünftige Backupsoftware Bacula zum Einsatz kommen soll, habe ich zunächst einige Tests durchgeführt, ob die Hardware (alles gebraucht gekauft…) überhaupt ordnungsgemäß funktioniert und von Bacula angesteuert werden kann. Dabei ist mir aufgefallen, dass die Schreibgeschwindigkeit überraschend niedrig war, deutlich niedriger als die Nennwerte für LTO-4. Eine dazu gestartete Diskussion in de.comp.hardware.laufwerke.misc führte recht schnell zu dem Hinweis, die Blockgröße anzupassen. Streamer werden unter Linux als Blockdevice gehandhabt, d. h. Daten werden blockweise geschrieben und gelesen. Bacula arbeitet dabei standardmäßig mit einer eher geringen Blockgröße von 64 kB, die sich über den Parameter „maximum blocksize” in der Konfigurationsdatei des Bacula Storage Daemons einstellen lässt. Das habe ich getan und einige Geschwindigkeitstests durchgeführt.
Zum Testen und Messen habe ich das btape-Tool von Bacula verwendet. Dessen „speed”-Kommando führt standardmäßig vier verschiedene Testfälle aus:
- Schreiben von ausschließlich Nullen
- Schreiben von Zufallszahlen
- Schreiben von Nullen „with bacula block structure“
- Schreiben von Zufallszahlen „with bacula block structure“
Dabei wird jeder Testfall mit drei verschiedenen Dateigrößen (1 GB, 2 GB und 4 GB) auf dem Streamer getestet. Zusätzlich wird jede Kombination aus Testfall und Dateigröße mit jeweils drei Testdurchläufen hintereinander durchgeführt, sodass sich in Summe 4 × 3 × 3 = 36 einzelne Messwerte ergeben. Für die folgenden Graphen habe ich jeweils den Mittelwert aus den drei Ergebnissen einer Testfall/Dateigrößen-Kombination ermittelt und aufgetragen. Die Fehlerbalken stellen die Standardabweichungen innerhalb dieser Dreiergruppen dar. Diese Messreihen habe ich außerdem für sechs verschiedene Blockgrößen-Einstellungen (64 kB, 128 kB, 256 kB, 512 kB, 1 MB und 2 MB – wobei letzteres das Maximum des Laufwerks ist) wiederholt.
LTO-4-Band mit Hardwarekompression
Kommen wir damit zu den Messergebnissen, zunächst mit aktivierter Hardwarekompression des Laufwerks.
Wie man sieht, schwanken die Schreibraten von Testfall zu Testfall erheblich. Um das besser vergleichen zu können, hier noch ein Graph für die verschiedenen Testfälle, jeweils mit 4 GB großen Dateien auf dem Streamer:
LTO-4-Band ohne Hardwarekompression
Angesichts der doch relativ niedrigen Schreibraten für die Tests mit Zufallszahlen – LTO-4 hat eine maximale Schreibrate unkomprimierter Daten von 120 MB/s – kam in der oben genannten Usenet-Diskussion die Vermutung auf, dass die Hardware-Kompression des Laufwerks die nicht komprimierbaren Zufallszahlen zu langsam verarbeiten und damit den Schreibprozess ausbremsen könnte. Um diesem Verdacht nachzugehen, habe ich die Hardware-Kompression ausgeschaltet und erneut gemessen. (Da die Web-Administrations-Oberfläche der Library an dieser Stelle anscheinend einen Bug hat, konnte ich die Kompression übrigens nur über die Linux-Konsole mittels mt -f /dev/st0 compression 0 deaktivieren.) Der besseren Übersicht halber sind hier nur zwei Vergleichsgraphen mit ausgewählten Testfällen dargestellt, einmal für 1 GB und einmal für 4 GB große Dateien:
Wie man sieht, brechen die Schreibraten für reine Nullen dramatisch ein (soweit wenig verwunderlich) und liegen nur Minimal über den Schreibraten für Zufallswerte, wobei sich letztere praktisch nicht zwischen den Fällen mit und ohne Hardwarekompression unterscheiden. Das bringt mich zu dem Schluss, dass diese ganz grob über den Daumen 50 MB/s wohl so etwas wie die „natürliche” Schreibrate dieses Laufwerks sind. Denn wäre zum Beispiel die Quelle der Zufallszahlen (/dev/random?) ein signifikanter Flaschenhals, hätten zumindest die Schreibraten für reine Nullen im unkomprimierten Modus des Laufwerks deutlich höher liegen müssen. Auch die Fibre-Channel-Anbindung – die mit 4 GB/s auch mehr als ausreichend sein sollte – kann in diesem Fall nicht der begrenzende Faktor sein, denn bei aktivierter Hardwarekompression und ausschließlich Nullen liegt die Schreibrate ja um den Faktor 5–6 höher. Die Schlussfolgerung daraus lautet für mich, die Hardwarekompression auf jeden Fall aktiviert zu lassen. Denn schaden tut sie offensichtlich nicht, kann aber bei „günstigen” Daten ganz erheblich nützen.
LTO-3-Band
Da ich neben LTO-4-Bändern auch noch eine ganze Menge LTO-3-Bänder herumliegen habe, habe ich mir die Frage gestellt, wie die sich wohl im LTO-4-Laufwerk schlagen. (LTO-4-Laufwerke können schließlich auch LTO-3-Bänder lesen und schreiben.) Angesichts der weiter oben vorgestellten Ergebnisse habe ich hier direkt auf Messungen mit abgeschalteter Hardwarekompression verzichtet. Außerdem zeige hier ebenfalls nur einige ausgewählte Ergebnisse, welche die generelle Tendenz gut wiedergeben:
Abgesehen von dem etwas merkwürdigen Einbruch bei der Kombination aus 256 kB Blockgröße und 1 GB Dateigröße (wobei sich diese geringe Blockgröße wegen der damit verbundenen geringen Schreibrate ohnehin von selbst verbietet) liegen die Schreibraten auf das LTO-3-Band nahezu gleichauf mit denen auf das LTO-4-Band. Das bedeutet für mich, dass die LTO-3-Bänder abgesehen von der geringeren Kapazität (400 MB statt 800 MB unkomprimiert) eigentlich keine Nachteile gegenüber LTO-4-Bändern haben, sodass ich auch die noch vorhandenen LTO-3-Bänder problemlos mitbenutzen kann.
Was demnächst noch ansteht, ist ein Test des oben erwähnten LTO-1-Laufwerks.