Re: [OT] Wer kennt sich mit LTO oder Bändern im allgemeinen aus?
Heiko Schlittermann <hs@schlittermann.de> wrote:
> Sven Hartge <sven@svenhartge.de> (Thu Aug 11 14:59:45 2011):
>> Heiko Schlittermann <hs@schlittermann.de> wrote:
>>> ich habe hier für mich erstmal unerklärliche Effekte mit einem
>>> LTO-2-Laufwerk und dessen Bändern. Da ich die Liste nicht nerven
>>> möchte, die Bitte um Antwort per PM (Reply-to ist gesetzt und
>>> hoffentlich nicht vom Mailman vermurkst).
>> Ich halte die Diskussion für die Liste dennoch interessant, da ich
>> ähnliche Probleme auch hatte und zumindest das Archiv nur davon
>> profitieren kann.
> Deine Antwort hier war bisher die einzige.
>>> Die Kernfrage wäre: warum bekomme ich nur 156GiB auf ein Band, das
>>> mit native 200GB verkauft wird?
>> LTO-Laufwerke haben die Eigenschaft, dass sie Leerblöcke schreiben,
>> wenn sie die Daten nicht schnell genug erhalten, um nicht Stoppen,
>> Rückspulen und Neustarten zu müssen (sog. Show-Shining).
Shoe-Shining heißt das natürlich. War der Muscle-Memory wieder schneller
als die Korrektur im Hirn.
> Wenn ich mit
> dd if=/dev/zero ibs=1M of=/dev/nst0 obs=64k
> schreibe, gehe ich mal davon aus, daß die Daten schnell genug generiert
> werden. Das Interface halte ich auch für schnell genug (U320 SCSI-Karte
> in einem PCIe-Slot auf einer zeitgemäßen Hardware).
> Kompression mit
> mt compression 0
> ausgeschaltet, *nachdem* das Band eingelegt wurde. Außerdem meine
> ich, daß ich deutlich mehr als 200G draufbekommen müsste, wenn aus
> Versehen die Compression doch noch an ist.
Wenn du nur 0en schreibst: absolut. Dann solltest du _mindestens_ 200GB
drauf bekommen, wahrscheinlich eher 400GB wg. maximaler
Komprimierbarkeit.
Du schreibst oben mit 64k-Blöcken. Was passiert, wenn du das auf
4MB-Blöcke erhöhst?
>> Ich lege hierzu meist einfach ein leeres 200GB-Image an, packe ein
>> cryptfs drauf und schreibe das mit Nullen voll. Dadurch entsteht sehr
>> schnell eine große Menge an pseudo-zufälligen Werten, die nicht
>> komprimierbar sind und sehr sehr viel schneller geht, wie die Daten
>> aus /dev/urandom zu ziehen.
> Gut, ich hatte ein großes File mit Daten aus „urandom“, aber da es
> dann als File da liegt, hatte ich (ebenso wie bei Deiner Lösung)
> Bedenken, daß die Daten von der Platte nicht schnell genug kommen,
> jedenfalls wollte ich das als Ursache sicher ausschließen.
Natürlich.
Mit welcher Software sicherst du eigentlich?
Mit Bacula? Wenn ja, hast du mal mittels btape das Laufwerk getestet und
einmal mit dem Tool das Band komplett gefüllt?
>> Wenn der dd-Test erfolgreich ist, dann gibt es ein Problem mit der
>> Backup-Software.
> Und wenn er nicht erfolgreich ist? Wahrscheinlich mit dem Laufwerk
> selbst.
Oder mit den Bändern.
> Die Schreibrate schwankt zwischen 25MB/s und 9MB/s, liegt im Mittel dann
> bei knapp 20MB/s. (Gemessen mit DD, dem ich alle 10s ein USR1-Signal
> geschickt habe.)
Laut https://secure.wikimedia.org/wikipedia/en/wiki/Linear_Tape-Open
liegt die maximale Rate bei LTO2 bei 40MB/s, also bei maximaler
Komprimierbarkeit. 20MB/s im Schnitt bei normalen Daten wären dann also
durchaus OK.
> Auf einem anderen Band habe ich im Mittel nur 9MB/s geschafft!
Das ist allerdings unterirdisch. Irgendwelche komischen Geräusche dabei,
vor allem häufiges Umspulen?
S°
--
Sigmentation fault. Core dumped.
Reply to: