Streamer-Problem: Band stockt ständig.

15/07/2008 - 19:53 von Christoph Stracke | Report spam
Hallo liebe Hardwareexperten,

ich habe folgendes sehr merkwürdiges Problem mit meinem Streamer
(Compaq DLT-7000).

Der Streamer schreibt ankommende Daten einwandfrei und befindet sich
beim Schreibvorgang stets im "Streaming-Modus", d.h. er làuft ohne
Unterbrechung durch.

Wenn ich dagegen die Daten wieder auslesen will, so wechselt er bereits
nach wenigen Sekunden in den "Start-Stop-Modus", d.h. er liest ein
Stück, spult kurz zurück, liest wieder, spult wieder zurück usw. Die
resultierenden Daten sind aber einwandfrei, und da der Streamer ja eine
eingebaute Hinterbandkontrolle hat und beim Schreiben nicht stockt, ist
ja auch davon auszugehen, daß das Bandmaterial auch in Ordnung ist.

Die Archivierung geschieht mittels "tar" auf einem Athlon 1000 unter
Ubuntu Hardy (oder vorher: Gutsy). Die CPU-Last ist unter 5% und als
Controller wird ein Adaptec AHA-2940 UW eingesetzt (schon getauscht;
keine Änderung). Das SCSI-Kabel ist ein Flachbandkabel (da ich kein
Rundkabel für das extern betriebene Laufwerk hatte); die Terminierung
geschieht auf Streamer-Seite per Aufsteck-Terminator und auf
Controllerseite hardwareintern. Als Daten werden mpeg- oder mp3-Dateien
benutzt; die hardware-Komprimierung des Streamers ist darum
abgeschaltet (per "mt kompression off").

Das Skurrile: Der Streamer stockt auch, wenn ich nur ein "tar -t"
ausgeben lasse, d.h., wenn ich nur ein Inhaltsverzeichnis anzeigen
lassen will, ohne die Daten zu lesen.

Wenn ich nun aber das ltt (hp StorageWorks library and tape tools)
aufrufe und einen Schreib-/Lesetest mache, streamt das Geràt sowohl beim
Schreiben als auch beim Lesen einwandfrei durch (selbst bei mehreren
GB). Ein Fehler in der SCSI-Kette sollte also ausgeschlossen werden
können.

Ich habe dann mal "star" installiert, das eine Erweiterung von "tar"
darstellt. Star verwendet defaultmàßig einen (in der Größe auch frei
wàhlbaren) Puffer von 8MB. Interessant ist die folgende Ausgabe der
Statistik am Ende:

schnipp-
tonga@sisyphus /tempdata/streamertest $ star -T -fifo -fifostats -x
star: fifo had 13263 puts 126 gets.
star: fifo was 48 times empty and 0 times full.
star: fifo held 2805760 bytes max, size was 8396800 bytes
star: fifo is 0% full (8k), size 8200k.
star: 13263 blocks + 0 bytes (total of 135813120 bytes = 132630.00k).
tonga@sisyphus /tempdata/streamertest $
schnapp-

Wer hàlt die Daten zurück? Warum stoppt der Streamer, wenn er
noch nichtmal den (kleinen) 8MB-Puffer voll kriegt? Habe ich
vielleicht ein tiefsitzendes Hardwareproblem?
Die Frage ist aber, warum das HP-Tool die Daten offensichtlich
einwandfrei lesen kann(?), schließlich muß der ja die selbe Hardware
nutzen ...
Und "tar" bzw. "star" sollten in den vergangenen Jahrzehnten so
ausgereift sein, daß ich hier auch keinen Fehler suchen möchte. ;-)

Ich bin für jede Idee dankbar!

Viele Grüße
Christoph
 

Lesen sie die antworten

#1 usenet
15/07/2008 - 20:20 | Warnen spam
Christoph Stracke wrote:

Und "tar" bzw. "star" sollten in den vergangenen Jahrzehnten so
ausgereift sein, daß ich hier auch keinen Fehler suchen möchte. ;-)



Sollte. Ein Test mit »dump« schadet aber nicht, dann weiss man mehr.

Grüße
Götz
http://www.knubbelmac.de/

Ähnliche fragen