Erfahrungswerte Datendurchsatz LTO-Streamer

[Sebastian Suchanek]

Hallo NG,

im Moment bastele ich an (m)einer LTO-Tape-Library herum.
Aktuell ist dort ein LTO4-Laufwerk verbaut, direkt verbunden
mit meinem Server via 4GB/s-FibreChannel. Die
Hardwarekompression im Laufwerk ist aktiviert.
Wenn ich der "speed"-Test[1] von btape aus dem Bacula-Paket
auf das Laufwerk loslasse, bekomme ich, abhängig vom
konkreten Testprogramm, Datendurchsätze zwischen ca. 38MB/s
und ca. 124MB/s. Das alles bei einer Blockgröße von konstant
64512 Bytes.
Was mich nun interessieren würde: Wie sind denn so
einschlägige Erfahrungswerte zu Schreibgeschwindigkeiten von
LTO? Lohnt es sich, hier noch mit der Blockgröße zu spielen,
um nennenswert höhere Durchsatzraten zu bekommen? Wenn ja:
welche Blockgrößen wären empfehlenswert?


TIA,

Sebastian

_____
[1] Wer's nicht kennt: Das Programm beschreibt ein Band mit
verschiedenen Testmustern - nur Nullen, Zufallszahlen, mit
und ohne Bacula-eigener Blockstruktur, verschiedene
Dateigrößen usw. - und misst dabei die Schreibraten. Siehe
z.B. [2]
[2] http://www.bacula.org/5.1.x-manuals/es/problems/problems/Testing_Your_Tape_Drive.html#SECTION00422000000000000000

[Marcel Mueller]

Post by Sebastian Suchanek
im Moment bastele ich an (m)einer LTO-Tape-Library herum.
Aktuell ist dort ein LTO4-Laufwerk verbaut, direkt verbunden
mit meinem Server via 4GB/s-FibreChannel. Die
Hardwarekompression im Laufwerk ist aktiviert.
Wenn ich der "speed"-Test[1] von btape aus dem Bacula-Paket
auf das Laufwerk loslasse, bekomme ich, abhängig vom
konkreten Testprogramm, Datendurchsätze zwischen ca. 38MB/s
und ca. 124MB/s. Das alles bei einer Blockgröße von konstant
64512 Bytes.
Was mich nun interessieren würde: Wie sind denn so
einschlägige Erfahrungswerte zu Schreibgeschwindigkeiten von
LTO?

Ich habe nur LTO 3 und das auch nur an einem uralten U2W
SCSI-Controller, aber so 70 MB/s sind trotzdem Standard. Begrenzend ist
der Controller, sonst wären es vmtl. eher um die 80-100 MB/s.
Also kurzum, das ist bei Dir viel zu wenig.

Was mir so auffällt: die Blockgröße ist sehr klein. Bereits bei DLT
musste man wenigstens mit 256k ran, damit da etwas sinnvolles passiert.
Bei LTO verwende ich 1-2MB.

Post by Sebastian Suchanek
Lohnt es sich, hier noch mit der Blockgröße zu spielen,
welche Blockgrößen wären empfehlenswert?

Ja, s.o.
Manchmal muss man etwas damit herumspielen. Wenn man es übertreibt,
bekommt man I/O-Fehler.


Marcel

[Sebastian Suchanek]

Post by Marcel Mueller

Post by Sebastian Suchanek
im Moment bastele ich an (m)einer LTO-Tape-Library herum.
Aktuell ist dort ein LTO4-Laufwerk verbaut, direkt
verbunden mit meinem Server via 4GB/s-FibreChannel. Die
Hardwarekompression im Laufwerk ist aktiviert.
Wenn ich der "speed"-Test[1] von btape aus dem
Bacula-Paket auf das Laufwerk loslasse, bekomme ich,
abhängig vom konkreten Testprogramm, Datendurchsätze
zwischen ca. 38MB/s und ca. 124MB/s. Das alles bei einer
Blockgröße von konstant 64512 Bytes.
Was mich nun interessieren würde: Wie sind denn so
einschlägige Erfahrungswerte zu Schreibgeschwindigkeiten
von LTO?

Ich habe nur LTO 3 und das auch nur an einem uralten U2W
SCSI-Controller, aber so 70 MB/s sind trotzdem Standard.
Begrenzend ist der Controller, sonst wären es vmtl. eher um
die 80-100 MB/s. Also kurzum, das ist bei Dir viel zu
wenig.
[...]

Danke für den Hinweis. Ich hab's gestern noch mit Blockgrößen
von 1MB und 2MB (mehr kann das Laufwerk nicht) getestet. Das
war in Bacula zwar etwas kniffelig einzustellen, aber das
zumindest einige der synthetischen Benchmarks deutlich
beflügelt: Reines Nullenschreiben mit 4GB Dateigröße erreicht
jetzt Werte um die 240GB/s. Aber breits mit "Bacula block
structure" fällt das auf ~170MB/s (bei kleineren Dateigrößen
noch mehr) und bei diversen Zufallszahlentests auf ganz grob
35MB/s bis über 70MB/s.
Ich will das irgendwann in nächster Zeit nochmal etwas
strukturierter erfassen und aufbereiten...

Aber immerhin sind die Werte größenordnungsmäßig konsistent
zu dem hier:

https://www.bareos.org/en/Whitepapers/articles/Speed_Tuning_of_Tape_Drives.html

(Hatte ich leider erst nach meinem OP hier gefunden.)


Tschüs,

Sebastian

[Dietz Proepper]

Post by Sebastian Suchanek

Post by Marcel Mueller
Ich habe nur LTO 3 und das auch nur an einem uralten U2W
SCSI-Controller, aber so 70 MB/s sind trotzdem Standard.
Begrenzend ist der Controller, sonst wären es vmtl. eher um
die 80-100 MB/s. Also kurzum, das ist bei Dir viel zu
wenig.
[...]

Danke für den Hinweis. Ich hab's gestern noch mit Blockgrößen
von 1MB und 2MB (mehr kann das Laufwerk nicht) getestet. Das
war in Bacula zwar etwas kniffelig einzustellen, aber das

Maximum Block Size = 1290240 ? ;-)

Post by Sebastian Suchanek
zumindest einige der synthetischen Benchmarks deutlich
beflügelt: Reines Nullenschreiben mit 4GB Dateigröße erreicht
jetzt Werte um die 240GB/s.

Ja, das ist der zu erwartende Durchsatz. Vermutlich ist hier dann die
verbindung zum Bandlaufwerk der bottleneck.

Post by Sebastian Suchanek
Aber breits mit "Bacula block
structure" fällt das auf ~170MB/s (bei kleineren Dateigrößen
noch mehr)

Bei kleinen Dateigrößen würde ich vermuten, dass das Dateisystem der
bottleneck ist. Zumindest $hier habe ich bei "normalem" Mix Leseraten um die
200MB/s aus dem Dateisystem, bei vielen kleinen Dateien fällt das gerne mal
auf 10MB/s (jeweils aus "Sicht" von bacula-fd) ab. Tipp, spoolen. Dauert zwar
ein wenig länger, sollte aber für Band bzw. Laufwerk stressfreier sein. Zudem
wird das Zeitfenster für den (clientseitigen Teil des) Backups kürzer.

Post by Sebastian Suchanek
und bei diversen Zufallszahlentests auf ganz grob
35MB/s bis über 70MB/s.

Tipp, probier's mal ohne Kompression. Die versaut Dir hier im Wesentlichen die
Messwerte. Die 35MB/s könnten auch einfach daran liegen, dass das Laufwerk
versucht, nicht-komprimierbares zu komprimieren und dafür sehr lange braucht.

Post by Sebastian Suchanek
Ich will das irgendwann in nächster Zeit nochmal etwas
strukturierter erfassen und aufbereiten...
Aber immerhin sind die Werte größenordnungsmäßig konsistent

https://www.bareos.org/en/Whitepapers/articles/Speed_Tuning_of_Tape_Drives.html

Post by Sebastian Suchanek
(Hatte ich leider erst nach meinem OP hier gefunden.)

Bareos. Grusel.

[Sebastian Suchanek]

Post by Dietz Proepper

Post by Sebastian Suchanek

Post by Marcel Mueller
Ich habe nur LTO 3 und das auch nur an einem uralten U2W
SCSI-Controller, aber so 70 MB/s sind trotzdem Standard.
Begrenzend ist der Controller, sonst wären es vmtl. eher
um die 80-100 MB/s. Also kurzum, das ist bei Dir viel zu
wenig.
[...]

Danke für den Hinweis. Ich hab's gestern noch mit
Blockgrößen von 1MB und 2MB (mehr kann das Laufwerk nicht)
getestet. Das war in Bacula zwar etwas kniffelig
einzustellen, aber das

Maximum Block Size = 1290240 ? ;-)

Das muss man erst 'mal wissen. ;-) Ich hatte zuerst nur "Minimum
Block Size" eingestellt, nicht wissend, dass Bacula bei einer
nicht definierten Maximum Block Size auf den Default von 64k
zurückfällt. Das hat dann zunächst mal nur zu Fehlermeldungen
geführt, dass die Minimum Block Size über der Maximum Block Size
läge.

Post by Dietz Proepper

Post by Sebastian Suchanek
zumindest einige der synthetischen Benchmarks deutlich
beflügelt: Reines Nullenschreiben mit 4GB Dateigröße
erreicht jetzt Werte um die 240GB/s.

Ja, das ist der zu erwartende Durchsatz. Vermutlich ist
hier dann die verbindung zum Bandlaufwerk der bottleneck.

Wie gesagt: Die Verbindung ist ein 4-GB/s-Fibrechannel an dem
das Laufwerk exklusiv hängt. /Da/ sollte eigentlich noch Luft
nach oben sein.

Post by Dietz Proepper

Post by Sebastian Suchanek
Aber breits mit "Bacula block
structure" fällt das auf ~170MB/s (bei kleineren
Dateigrößen noch mehr)

Bei kleinen Dateigrößen würde ich vermuten, dass das
Dateisystem der bottleneck ist.

Ich meinte die (Test)dateien auf dem Band. Im Produkiveinsatz
bin ich mit dem Zeugs noch nicht.

Post by Dietz Proepper
Zumindest $hier habe ich
bei "normalem" Mix Leseraten um die 200MB/s aus dem
Dateisystem, bei vielen kleinen Dateien fällt das gerne mal
auf 10MB/s (jeweils aus "Sicht" von bacula-fd) ab. Tipp,
spoolen.

Ja, sollte ich dann wohl tun. (Für mindestens einen übers
Internet zu sichernden Client wird das ohnehin Pflicht.)
Kann Bacula eigentlich von sich aus spoolen oder muss man da
basteln?

Post by Dietz Proepper
[...]

Post by Sebastian Suchanek
und bei diversen Zufallszahlentests auf ganz grob
35MB/s bis über 70MB/s.

Tipp, probier's mal ohne Kompression.

OK, kommt auf die gedankliche Liste der zu testenden Dinge.

Post by Dietz Proepper
Die versaut Dir hier
im Wesentlichen die Messwerte. Die 35MB/s könnten auch
einfach daran liegen, dass das Laufwerk versucht,
nicht-komprimierbares zu komprimieren und dafür sehr lange
braucht.

Wundern täte mich das aber schon. Die Hardware ist ja kein
Consumer-Geraffel - da würde ich eigentlich erwarten, dass die
eingebaute Logik im Laufwerk schnell genug ist, um zu erkennen,
dass sie nicht komprimieren kann, ohne dabei den Durchsatz
gnadenlos einbrechen zu lassen.

Post by Dietz Proepper
[...]

Post by Sebastian Suchanek
Aber immerhin sind die Werte größenordnungsmäßig

https://www.bareos.org/en/Whitepapers/articles/Speed_Tuning_
of_Tape_Drives.html

Post by Sebastian Suchanek
(Hatte ich leider erst nach meinem OP hier gefunden.)

Bareos. Grusel.

-v, please. Ist doch auch "nur" ein Bacula-Fork...


Tschüs,

Sebastian

[Dietz Proepper]

Post by Sebastian Suchanek

Post by Dietz Proepper
Zumindest $hier habe ich
bei "normalem" Mix Leseraten um die 200MB/s aus dem
Dateisystem, bei vielen kleinen Dateien fällt das gerne mal
auf 10MB/s (jeweils aus "Sicht" von bacula-fd) ab. Tipp,
spoolen.

Ja, sollte ich dann wohl tun. (Für mindestens einen übers
Internet zu sichernden Client wird das ohnehin Pflicht.)
Kann Bacula eigentlich von sich aus spoolen oder muss man da
basteln?

Es kann, man muss es nur aktivieren. Pro device ein spooldir + -größe
festlegen (sd-Config):

Device {
[...]
Maximum Spool Size = 400g
Spool Directory = /var/bacula/spool
}

(mehr als ein device für das gleiche spool directory ist kein Problem)
und dann im Director anschalten:

Job | Schedule {
[...]
SpoolData=yes
}

Post by Sebastian Suchanek

Post by Dietz Proepper
[...]

Post by Sebastian Suchanek
und bei diversen Zufallszahlentests auf ganz grob
35MB/s bis über 70MB/s.

Tipp, probier's mal ohne Kompression.

OK, kommt auf die gedankliche Liste der zu testenden Dinge.

Post by Dietz Proepper
Die versaut Dir hier
im Wesentlichen die Messwerte. Die 35MB/s könnten auch
einfach daran liegen, dass das Laufwerk versucht,
nicht-komprimierbares zu komprimieren und dafür sehr lange
braucht.

Wundern täte mich das aber schon. Die Hardware ist ja kein
Consumer-Geraffel - da würde ich eigentlich erwarten, dass die
eingebaute Logik im Laufwerk schnell genug ist, um zu erkennen,
dass sie nicht komprimieren kann, ohne dabei den Durchsatz
gnadenlos einbrechen zu lassen.

Naja, Gedankenlesen usw. Bei meinen LTOs habe ich's nie explizit gebenchmarkt,
die vorher verwendeten DLTs sind aber bei ungünstigen Daten massiv unter die
rohe, unkomprimierte Rate abgestürzt.

Post by Sebastian Suchanek

Post by Dietz Proepper
Bareos. Grusel.

-v, please. Ist doch auch "nur" ein Bacula-Fork...

Es gab da einiges an Verwerfungen, iirc über Mitnahme von Knowhow etc.

[Sebastian Suchanek]

Post by Dietz Proepper

Post by Sebastian Suchanek

Post by Dietz Proepper
Zumindest $hier habe ich
bei "normalem" Mix Leseraten um die 200MB/s aus dem
Dateisystem, bei vielen kleinen Dateien fällt das gerne
mal auf 10MB/s (jeweils aus "Sicht" von bacula-fd) ab.
Tipp, spoolen.

Ja, sollte ich dann wohl tun. (Für mindestens einen übers
Internet zu sichernden Client wird das ohnehin Pflicht.)
Kann Bacula eigentlich von sich aus spoolen oder muss man
da basteln?

Es kann, man muss es nur aktivieren. Pro device ein

Prima, danke.

Post by Dietz Proepper
[...]

Post by Sebastian Suchanek

Post by Dietz Proepper
Bareos. Grusel.

-v, please. Ist doch auch "nur" ein Bacula-Fork...

Es gab da einiges an Verwerfungen, iirc über Mitnahme von
Knowhow etc.

Man hat sich da wohl verglichen:

https://www.bareos.org/en/faq/copyright_bacula_bareos.html

Davon abgesehen: bis vor ein paar Tagen kannte ich Bareos noch
gar nicht, aber ich habe schon überlegt, ob ich es nicht statt
Bacula nutzen sollte (bevor ich anfange, die Produktivsysteme zu
konfigurieren). Die Linux-Distribution meines geringsten
Misstrauens ist Debian und die sind ja zumindest in der
Vergangenheit IMHO durch eine eher strikte Auslegung der Open-
Source-Thematik aufgefallen. Und wenn Bacula zumindest einige
Software-Teile zu Closed Source macht und auf eingereichte
Patche nicht reagiert (so zumindest die Behauptung von Bareos...

https://www.bareos.org/en/faq/why_fork.html

...), könnte es durchaus sein, dass Debian Bacula irgendwann aus
dem Repository wirft - ähnlich dem Schwenk von MySQL zu MariaDB
als Standard-SQL-DB. Zumindest aktuell sind sowohl Bacula als
auch Bareos im Repository enthalten.
Andererseits scheint wohl zumindest die Migration von Bacula
nach Bareos möglich zu sein...

https://www.bareos.org/en/faq/upgrade_bacula_bareos.html

....sodass es aktuell auch kein Problem wäre, zunächst mit
Bacula zu starten.


Tschüs,

Sebastian

PS: Wegen Wechsel des Themenschwerpunktes XP & f'up2 dcouam.

[Sebastian Suchanek]

Post by Dietz Proepper
[...]
Tipp, probier's mal ohne Kompression. Die versaut Dir hier
im Wesentlichen die Messwerte. Die 35MB/s könnten auch
einfach daran liegen, dass das Laufwerk versucht,
nicht-komprimierbares zu komprimieren und dafür sehr lange
braucht.
[...]

Inzwischen hab' ich's geschafft, ein paar systematische
Messungen zu machen:

https://hirnfasching.de/2018/02/19/geschwindigkeitsmessung-lto-4-laufwerk/

In Kurzfassung: Die Hardware-Kompression hat /keinen/
nennenswert negativen Einfluss auf das Schreiben von
Zufallszahlen.


Tschüs,

Sebastian

[Dietz Proepper]

Post by Sebastian Suchanek

Post by Dietz Proepper
[...]
Tipp, probier's mal ohne Kompression. Die versaut Dir hier
im Wesentlichen die Messwerte. Die 35MB/s könnten auch
einfach daran liegen, dass das Laufwerk versucht,
nicht-komprimierbares zu komprimieren und dafür sehr lange
braucht.
[...]

Inzwischen hab' ich's geschafft, ein paar systematische
https://hirnfasching.de/2018/02/19/geschwindigkeitsmessung-lto-4-laufwerk/

Hübsch.

Post by Sebastian Suchanek
In Kurzfassung: Die Hardware-Kompression hat /keinen/
nennenswert negativen Einfluss auf das Schreiben von
Zufallszahlen.

Mir scheint die Schreibrate bei abgeschalteter Kompression sehr niedrig. Ich
hätte keine 50 MB/s sondern eher 100 MB/s erwartet.

[Sebastian Suchanek]

Post by Dietz Proepper

Post by Sebastian Suchanek

Post by Dietz Proepper
[...]
Tipp, probier's mal ohne Kompression. Die versaut Dir
hier im Wesentlichen die Messwerte. Die 35MB/s könnten
auch einfach daran liegen, dass das Laufwerk versucht,
nicht-komprimierbares zu komprimieren und dafür sehr
lange braucht.
[...]

Inzwischen hab' ich's geschafft, ein paar systematische
https://hirnfasching.de/2018/02/19/geschwindigkeitsmessung-lto-4-laufwerk/

Hübsch.

Danke. :-)
Fürs Protokoll - das LTO-1-Laufwerk habe ich jetzt auch vermessen:

https://hirnfasching.de/2018/02/23/geschwindigkeitsmessung-lto-1-laufwerk/

Post by Dietz Proepper

Post by Sebastian Suchanek
In Kurzfassung: Die Hardware-Kompression hat /keinen/
nennenswert negativen Einfluss auf das Schreiben von
Zufallszahlen.

Mir scheint die Schreibrate bei abgeschalteter Kompression
sehr niedrig. Ich hätte keine 50 MB/s sondern eher 100 MB/s
erwartet.

Auch das LTO-1-Laufwerk ist zu langsam, allerdings "nur" um
~25% (15MB/s Ist statt 20MB/s Soll) statt 33%-50% beim LTO-4
(75MB/s Ist in der Spitze statt 120MB/s Soll).

Da die Laufwerke beide gebraucht gekauft sind: Kann diese
"Lücke" evtl. durch Verschleiß verursacht sein? Wobei ich mir
das eigentlich nicht vorstellen kann, schließlich hat LTO, wie
der Name schon sagt, lineare Aufzeichnungsspuren und nicht das
fehleranfällige Schrägspurverfahren.
An den Bändern selbst sollte es eigentlich nicht liegen: Die
LTO-3- und LTO-4-Band, das ich zum Testen genommen habe,
waren IIRC neu. Das LTO-1-Band war zwar gebraucht (im
LTO-1-Streamer, der in meinem früheren Desktop-PC eingebaut
war), aber mehr als eine Handvoll Schreibvorgänge dürfte auch
das nicht gesehen haben.


Tschüs,

Sebastian

[Marcel Mueller]

Post by Sebastian Suchanek
Danke für den Hinweis. Ich hab's gestern noch mit Blockgrößen
von 1MB und 2MB (mehr kann das Laufwerk nicht) getestet. Das
war in Bacula zwar etwas kniffelig einzustellen, aber das
zumindest einige der synthetischen Benchmarks deutlich
beflügelt: Reines Nullenschreiben mit 4GB Dateigröße erreicht
jetzt Werte um die 240GB/s.

Bei Nullen mit aktivierter Kompression schreibt der praktisch nichts. ;-)

Post by Sebastian Suchanek
Aber breits mit "Bacula block
structure" fällt das auf ~170MB/s (bei kleineren Dateigrößen

Das ist ein vernünftiger Wert für LTO4.

Post by Sebastian Suchanek
noch mehr) und bei diversen Zufallszahlentests auf ganz grob
35MB/s bis über 70MB/s.

Hier ist vermutlich dein Rechner der Engpass. Die Platten werden bei
kleinen Files zu sehr mit dem Zusammensuchen der Daten beschäftigt sein.
Selbst Serverplatten mit 15kUpM kommen da an ihre Grenzen. Und
Zufallszahlen zu erzeugen ist für die CPU erstaunlich aufwändig.

Post by Sebastian Suchanek
Ich will das irgendwann in nächster Zeit nochmal etwas
strukturierter erfassen und aufbereiten...

Nicht nötig. Ich glaube das passt jetzt.

Wenn bei LTO die Datenrate etwas einbricht, ist das übrigens nicht so
schlimm. Die Laufwerke können in gewissen Grenzen mit variabler
"Drehzahl" schreiben ohne gleich anhalten zu müssen.


Marcel

[Goetz Hoffart]

Datendurchsätze zwischen ca. 38MB/s und ca. 124MB/s.

124 ist okay, 38 viel zu wenig. Wahrscheinlich wirst du dann
Stream-Unterbrechungen bekommen, und das Band muss anhalten und
zurückspulen - auf Dauer nicht gut fürs Laufwerk.

LTO-4 muss > 100 MB/s bringen, sonst stimmt was nicht. Ich lasse bei mir
immer ein tar-ball der zu sichernden Daten schreiben, auf Platte, und
schreibe den dann mittels dd auf Tape. Das ist zwar nicht schneller als
direkt auf Tape, da zweimal geschrieben wird, aber die
Bandschreibegeschwindigkeit liegt so bei 140 MB/s - und das Band läuft
kontinuierlich.

Grüße
Götz

[Sebastian Suchanek]

Post by Goetz Hoffart

Datendurchsätze zwischen ca. 38MB/s und ca. 124MB/s.

124 ist okay, 38 viel zu wenig. Wahrscheinlich wirst du
dann Stream-Unterbrechungen bekommen, und das Band muss
anhalten und zurückspulen - auf Dauer nicht gut fürs
Laufwerk.
LTO-4 muss > 100 MB/s bringen, sonst stimmt was nicht. Ich
lasse bei mir immer ein tar-ball der zu sichernden Daten
schreiben, auf Platte, und schreibe den dann mittels dd auf
Tape. Das ist zwar nicht schneller als direkt auf Tape, da
zweimal geschrieben wird, aber die
Bandschreibegeschwindigkeit liegt so bei 140 MB/s - und das
Band läuft kontinuierlich.

Nach dem Vergrößern der Block Size liege ich inzwischen mit den
synthetischen Benchmarks teilweise bei 270MB/s (siehe auch meine
Antwort an Marcel).
Wie das mit echten Nutzdaten aussieht, muss sich zeigen. Die
Geschwindigkeit des "fill"-Tests von btape, der eingelegte Band
einmal komplett vollschreibt, ist mit der Änderung der
Blockgrößer nur von ~42MB/s auf ~47MB/s gestiegen. Welche Daten
dabei zum Testen genommen werden, weiß ich allerdings nicht. Es
werden aber wohl weder reine Nullen noch reine Zufallszahlen
sein, denn zum "fill"-Test gehört auch ein Lesen und
Verifizieren eines (kleinen) Teils der Daten.


Tschüs,

Sebastian

[Dietz Proepper]

Post by Goetz Hoffart

Datendurchsätze zwischen ca. 38MB/s und ca. 124MB/s.

124 ist okay, 38 viel zu wenig. Wahrscheinlich wirst du dann
Stream-Unterbrechungen bekommen, und das Band muss anhalten und
zurückspulen - auf Dauer nicht gut fürs Laufwerk.

124 ist für "mit Kompression" deutlich zu wenig. Nativ sollte LTO-4
(unkomprimiert) so um die 120MB/s bringen.

[Dietz Proepper]

Post by Sebastian Suchanek
Hallo NG,
im Moment bastele ich an (m)einer LTO-Tape-Library herum.

Iirc eine Overland? Hübsche Teile, hier steht auch eine.

Post by Sebastian Suchanek
Aktuell ist dort ein LTO4-Laufwerk verbaut, direkt verbunden
mit meinem Server via 4GB/s-FibreChannel. Die
Hardwarekompression im Laufwerk ist aktiviert.

Empfehlung, lass' die Hardwarekompression aus. Spätestens, wenn Du Deine
Backups (clientseitig) verschlüsselst bringt sie genau garnix mehr.

Post by Sebastian Suchanek
Wenn ich der "speed"-Test[1] von btape aus dem Bacula-Paket
auf das Laufwerk loslasse, bekomme ich, abhängig vom
konkreten Testprogramm, Datendurchsätze zwischen ca. 38MB/s
und ca. 124MB/s. Das alles bei einer Blockgröße von konstant
64512 Bytes.

Die Blockgröße ist definitiv etwas klein. Du solltest sie auf jeden Fall bis
ca. 1MB hoch setzten können.

Post by Sebastian Suchanek
Was mich nun interessieren würde: Wie sind denn so
einschlägige Erfahrungswerte zu Schreibgeschwindigkeiten von
LTO? Lohnt es sich, hier noch mit der Blockgröße zu spielen,
welche Blockgrößen wären empfehlenswert?

$hier bekomme ich aus einem LTO3 ca. 55 MB/s. Das ist nicht ganz optimal,
liegt aber wohl an der FC<->SCSI-Bridge. Bislang hindert mich "works well
enough" daran, hier zu optimieren.

Ich habe allerdings einen anderen, interessanten Effekt. Wenn der Host "hart"
ausfällt (Stromschalter, Kernelpanic), ein Band im Laufwerk und z.B. bacula-sd
das Device offen hat, dann wird nach einem Neustart (des Hosts) zuverlässig
das Bandende nicht gefunden ("Zuverlässig" wie in "nach 30min kein Ergebnis").
Mannigfaltige Experimente mit stinit (buffering, sync/async etc.) ergaben
keinerlei Besserung. Das einzige, was hilft ist, das device explizit zu
schließen.

Ich *vermute* dass aus irgendwelchen Gründen kein eom-Marker geschrieben wird
und deswegen ein mt seod fehlschlägt.

Any idea?

[Sebastian Suchanek]

Post by Dietz Proepper

Post by Sebastian Suchanek
Hallo NG,
im Moment bastele ich an (m)einer LTO-Tape-Library herum.

Iirc eine Overland? Hübsche Teile, hier steht auch eine.

Ja, richtig. Eine alte NEO2000.

Post by Dietz Proepper

Post by Sebastian Suchanek
Aktuell ist dort ein LTO4-Laufwerk verbaut, direkt
verbunden mit meinem Server via 4GB/s-FibreChannel. Die
Hardwarekompression im Laufwerk ist aktiviert.

Empfehlung, lass' die Hardwarekompression aus. Spätestens,
wenn Du Deine Backups (clientseitig) verschlüsselst bringt
sie genau garnix mehr.

OK, danke für den Hinweis. Verschlüsselung ist in der Tat
geplant, damit man die Bänder auch ohne großes Nachdenken "off
site" lagern kann.
Wie sich das auf die Datenraten in den Benchmarks auswirkt, will
ich noch testen - siehe meine Parallelantwort.

Post by Dietz Proepper

Post by Sebastian Suchanek
Wenn ich der "speed"-Test[1] von btape aus dem
Bacula-Paket auf das Laufwerk loslasse, bekomme ich,
abhängig vom konkreten Testprogramm, Datendurchsätze
zwischen ca. 38MB/s und ca. 124MB/s. Das alles bei einer
Blockgröße von konstant 64512 Bytes.

Die Blockgröße ist definitiv etwas klein. Du solltest sie
auf jeden Fall bis ca. 1MB hoch setzten können.
[...]

Ja, das hat geholfen - siehe <***@msgid.suchanek.de>.


Tschüs,

Sebastian

[Dietz Proepper]

Post by Sebastian Suchanek

Post by Dietz Proepper

Post by Sebastian Suchanek
Hallo NG,
im Moment bastele ich an (m)einer LTO-Tape-Library herum.

Iirc eine Overland? Hübsche Teile, hier steht auch eine.

Ja, richtig. Eine alte NEO2000.

Dito, aber mit LTO-3.