Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Erfahrungswerte Datendurchsatz LTO-Streamer
33 views
Skip to first unread message
Sebastian Suchanek
Feb 2, 2018, 12:23:02 PM2/2/18
to
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
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
Feb 2, 2018, 12:38:19 PM2/2/18
to
On 02.02.18 18.23, Sebastian Suchanek wrote:
> 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
> 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?
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.
> 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?
Manchmal muss man etwas damit herumspielen. Wenn man es übertreibt,
bekommt man I/O-Fehler.
Marcel
Goetz Hoffart
Feb 2, 2018, 3:27:01 PM2/2/18
to
Sebastian Suchanek <sebastian...@gmx.de> wrote:
> Datendurchsätze zwischen ca. 38MB/s und ca. 124MB/s.
124 ist okay, 38 viel zu wenig. Wahrscheinlich wirst du dann
> Datendurchsätze zwischen ca. 38MB/s und ca. 124MB/s.
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
--
http://www.knubbelmac.de/
Sebastian Suchanek
Feb 3, 2018, 5:48:09 AM2/3/18
to
Thus spoke Goetz Hoffart:
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
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
Sebastian Suchanek
Feb 3, 2018, 5:48:11 AM2/3/18
to
Thus spoke Marcel Mueller:
> On 02.02.18 18.23, Sebastian Suchanek wrote:
>> 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
> On 02.02.18 18.23, Sebastian Suchanek wrote:
>> 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
Feb 3, 2018, 5:50:02 AM2/3/18
to
Sebastian Suchanek wrote:
> Hallo NG,
>
> im Moment bastele ich an (m)einer LTO-Tape-Library herum.
Iirc eine Overland? Hübsche Teile, hier steht auch eine.
> 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.
Backups (clientseitig) verschlüsselst bringt sie genau garnix mehr.
> 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.
ca. 1MB hoch setzten können.
> 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?
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?
Dietz Proepper
Feb 3, 2018, 5:55:03 AM2/3/18
to
Goetz Hoffart wrote:
> Sebastian Suchanek <sebastian...@gmx.de> wrote:
>
>> 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
> Sebastian Suchanek <sebastian...@gmx.de> wrote:
>
>> 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.
(unkomprimiert) so um die 120MB/s bringen.
Dietz Proepper
Feb 3, 2018, 6:10:03 AM2/3/18
to
Sebastian Suchanek wrote:
> Thus spoke Marcel Mueller:
> 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.
> 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.
> 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.
> 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.)
Bareos. Grusel.
> Thus spoke 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 ? ;-)
>> 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.
verbindung zum Bandlaufwerk der bottleneck.
> Aber breits mit "Bacula block
> structure" fällt das auf ~170MB/s (bei kleineren Dateigrößen
> noch mehr)
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.
> und bei diversen Zufallszahlentests auf ganz grob
> 35MB/s bis über 70MB/s.
Messwerte. Die 35MB/s könnten auch einfach daran liegen, dass das Laufwerk
versucht, nicht-komprimierbares zu komprimieren und dafür sehr lange braucht.
> 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.)
Sebastian Suchanek
Feb 3, 2018, 10:50:18 AM2/3/18
to
Thus spoke Dietz Proepper:
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.
>> 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.
>> 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.
> 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?
> [...]
> 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.
> [...]
Tschüs,
Sebastian
> Sebastian Suchanek wrote:
>> Thus spoke 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
>> Thus spoke 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 ? ;-)
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.
>> 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.
das Laufwerk exklusiv hängt. /Da/ sollte eigentlich noch Luft
nach oben sein.
>> 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.
bin ich mit dem Zeugs noch nicht.
> 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.
Internet zu sichernden Client wird das ohnehin Pflicht.)
Kann Bacula eigentlich von sich aus spoolen oder muss man da
basteln?
> [...]
>> 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.
>> 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.
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.
> [...]
>> 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.)
>
> Bareos. Grusel.
-v, please. Ist doch auch "nur" ein Bacula-Fork...
>> 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.)
>
> Bareos. Grusel.
Tschüs,
Sebastian
Sebastian Suchanek
Feb 3, 2018, 10:50:19 AM2/3/18
to
Thus spoke Dietz Proepper:
>> 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.
>> 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 <p5479g...@msgid.suchanek.de>.
Tschüs,
Sebastian
> Sebastian Suchanek wrote:
>
>> 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.
>
>> Hallo NG,
>>
>> im Moment bastele ich an (m)einer LTO-Tape-Library herum.
>
> Iirc eine Overland? Hübsche Teile, hier steht auch eine.
>> 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.
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.
>> 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 <p5479g...@msgid.suchanek.de>.
Tschüs,
Sebastian
Dietz Proepper
Feb 3, 2018, 11:20:03 AM2/3/18
to
Sebastian Suchanek wrote:
> Thus spoke Dietz Proepper:
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
die vorher verwendeten DLTs sind aber bei ungünstigen Daten massiv unter die
rohe, unkomprimierte Rate abgestürzt.
>> Bareos. Grusel.
>
> -v, please. Ist doch auch "nur" ein Bacula-Fork...
Es gab da einiges an Verwerfungen, iirc über Mitnahme von Knowhow etc.
> Thus spoke 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
>> 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?
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
}
>> [...]
>>> 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.
>> 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,
>> [...]
>>> 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.
>> 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.
die vorher verwendeten DLTs sind aber bei ungünstigen Daten massiv unter die
rohe, unkomprimierte Rate abgestürzt.
>> Bareos. Grusel.
>
> -v, please. Ist doch auch "nur" ein Bacula-Fork...
Dietz Proepper
Feb 3, 2018, 11:20:03 AM2/3/18
to
Sebastian Suchanek wrote:
> Thus spoke Dietz Proepper:
>> Sebastian Suchanek wrote:
>>
>>> 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.
> Thus spoke Dietz Proepper:
>> Sebastian Suchanek wrote:
>>
>>> 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.
Marcel Mueller
Feb 3, 2018, 12:07:00 PM2/3/18
to
On 03.02.18 11.43, Sebastian Suchanek wrote:
> 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. ;-)
> 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.
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.
> Ich will das irgendwann in nächster Zeit nochmal etwas
> strukturierter erfassen und aufbereiten...
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
Sebastian Suchanek
Feb 4, 2018, 5:51:48 PM2/4/18
to
Thus spoke Dietz Proepper:
> [...]
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.
--
X-Post, FollowUp-To de.comp.os.unix.apps.misc
> Sebastian Suchanek wrote:
>> Thus spoke 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):
Prima, danke.
>> Thus spoke 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):
> [...]
>>> 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:
>>
>> -v, please. Ist doch auch "nur" ein Bacula-Fork...
>
> Es gab da einiges an Verwerfungen, iirc über Mitnahme von
> Knowhow etc.
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.
--
X-Post, FollowUp-To de.comp.os.unix.apps.misc
Sebastian Suchanek
Feb 19, 2018, 1:49:33 PM2/19/18
to
Thus spoke Dietz Proepper:
> [...]
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
> [...]
> 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.
> [...]
> 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
Feb 19, 2018, 4:45:03 PM2/19/18
to
Sebastian Suchanek wrote:
> Thus spoke 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/
Hübsch.
> Thus spoke 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.
hätte keine 50 MB/s sondern eher 100 MB/s erwartet.
Sebastian Suchanek
Feb 23, 2018, 4:47:28 PM2/23/18
to
Thus spoke Dietz Proepper:
Fürs Protokoll - das LTO-1-Laufwerk habe ich jetzt auch vermessen:
https://hirnfasching.de/2018/02/23/geschwindigkeitsmessung-lto-1-laufwerk/
>> 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
> Sebastian Suchanek wrote:
>> Thus spoke 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/
>
> Hübsch.
Danke. :-)
>> Thus spoke 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/
>
> Hübsch.
Fürs Protokoll - das LTO-1-Laufwerk habe ich jetzt auch vermessen:
https://hirnfasching.de/2018/02/23/geschwindigkeitsmessung-lto-1-laufwerk/
>> 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.
~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
0 new messages