Fehler beim Beschreiben eines Bandes (NetBSD, LTO-2)

[Volker Englisch]

Hallo!

Plötzlich will mein Bandlaufwerk nicht mehr schreiben. Geschrieben
werden soll mittels TAR ein Backup von ca. 100 recht grossen Dateien (je
ca. 500 MB groß).

Nachdem das Band lange Zeit vor- und zurückgespult wird möchte das
Laufwerk ein Reinigungsband haben, welches es auch bekommt. Beim
nächsten Versuch geschieht dasselbe wieder. Display auf der Console:

st0(mpt0:0:1:0): DEFERRED ERROR, key = 0x3
st0(mpt0:0:1:0): Check Condition on CDB: 0x0a 00 00 28 00 00
SENSE KEY: Media Error
INFO FIELD: 10240
ASC/ASCQ: Write Error

Mit verschiedenen nagelneuen Bändern versucht, ohne Erfolg.

Gehe ich recht in der Annahme, dass das Laufwerk dabei ist, das
Zeitliche zu segnen?

PS: Bitte Followup-To dahin setzen wohin es am bessten passt...

[Michael Bäuerle]

Post by Volker Englisch
Plötzlich will mein Bandlaufwerk nicht mehr schreiben. Geschrieben
werden soll mittels TAR ein Backup von ca. 100 recht grossen Dateien
(je ca. 500 MB groß).
Nachdem das Band lange Zeit vor- und zurückgespult wird möchte das
Laufwerk ein Reinigungsband haben, welches es auch bekommt. Beim
st0(mpt0:0:1:0): DEFERRED ERROR, key = 0x3
st0(mpt0:0:1:0): Check Condition on CDB: 0x0a 00 00 28 00 00
SENSE KEY: Media Error
INFO FIELD: 10240
ASC/ASCQ: Write Error
Mit verschiedenen nagelneuen Bändern versucht, ohne Erfolg.

SCSI Sense-Key und ASC kommen vom Laufwerk, d.h. es sollte nichts mit
dem Host-System zu tun haben.

Post by Volker Englisch
Gehe ich recht in der Annahme, dass das Laufwerk dabei ist, das
Zeitliche zu segnen?

Das ist natürlich möglich, muss aber nicht so sein.
Wir haben folgendes LTO2-Laufwerk von HP im Einsatz:
|
| Vendor: HP Model: Ultrium 2-SCSI Rev: S63D
| Type: Sequential-Access ANSI SCSI revision: 03

und das liefert vergleichbare Fehlermeldungen auch einfach wenn das
Band voll ist. Diese Meldungen sind falsch und irreführend. Wenn man
nicht über das Ende des Band zu schreiben versucht, funktioniert alles
einwandfrei, es ist kein Hardwareproblem.

Selbst wenn das rein rechnerisch nicht der Fall sein dürfte, können
die Daten mehr Platz brauchen. Einmal wegen der Kompression, die
kann bei ungeeigneten Daten auch das Gegenteil bewirken. Und dann
fügen die Laufwerke ggf. auch kurze Leerstellen ein, wenn ihnen der
Puffer leerläuft und sie dadurch nicht anhalten und zurückspulen
müssen.
Unwahrscheinlich, dass das bei deiner Datenmenge schon problematisch
wird, aber ein LTO1-Band wäre nominal immerhin etwa halb voll.

Versuche es mal mit reduzierter Datenmenge, z.B. nur eine Datei auf ein
neues Band schreiben und danach wieder lesen. Führt das bereits zum
gleichen Fehler?

Post by Volker Englisch
PS: Bitte Followup-To dahin setzen wohin es am bessten passt...

Ich habe dchlm gesetzt, weil das nicht nach einem Problem beim
Betriebssystem aussieht.

[Volker Englisch]

Post by Michael Bäuerle

Post by Volker Englisch
Plötzlich will mein Bandlaufwerk nicht mehr schreiben. Geschrieben
werden soll mittels TAR ein Backup von ca. 100 recht grossen Dateien
(je ca. 500 MB groß).
Nachdem das Band lange Zeit vor- und zurückgespult wird möchte das
Laufwerk ein Reinigungsband haben, welches es auch bekommt. Beim
st0(mpt0:0:1:0): DEFERRED ERROR, key = 0x3
st0(mpt0:0:1:0): Check Condition on CDB: 0x0a 00 00 28 00 00
SENSE KEY: Media Error
INFO FIELD: 10240
ASC/ASCQ: Write Error
Mit verschiedenen nagelneuen Bändern versucht, ohne Erfolg.

SCSI Sense-Key und ASC kommen vom Laufwerk, d.h. es sollte nichts mit
dem Host-System zu tun haben.

Post by Volker Englisch
Gehe ich recht in der Annahme, dass das Laufwerk dabei ist, das
Zeitliche zu segnen?

Das ist natürlich möglich, muss aber nicht so sein.
|
| Vendor: HP Model: Ultrium 2-SCSI Rev: S63D
| Type: Sequential-Access ANSI SCSI revision: 03

Hier ist es laut /var/log/messages ein HP, Ultrium 2-SCSI, S65D

Post by Michael Bäuerle
und das liefert vergleichbare Fehlermeldungen auch einfach wenn das
Band voll ist. Diese Meldungen sind falsch und irreführend. Wenn man
nicht über das Ende des Band zu schreiben versucht, funktioniert alles
einwandfrei, es ist kein Hardwareproblem.

Der Fehler kommt leider bereits bei der ersten zu sichernden Datei.

Post by Michael Bäuerle
Versuche es mal mit reduzierter Datenmenge, z.B. nur eine Datei auf ein
neues Band schreiben und danach wieder lesen. Führt das bereits zum
gleichen Fehler?

Nachdem die regulären Backups (mittels dump) bisher immer
funktionierten, habe ich dump mal auf ein kleines Filesystem
losgelassen, bei dem nur sehr wenige Dateien zu sichern sind. War
innerhalb weniger Sekunden fertig. Das Gleiche mit einem großen
Filesystem (aber ohne die eingangs erwähnten "riesigen" Dateien):
Laufwerk rödelt minutenlang hin und zurück und gibt mit dem selben
Fehler dann auf...

[Michael Bäuerle]

Post by Volker Englisch

Post by Michael Bäuerle
[...]
Versuche es mal mit reduzierter Datenmenge, z.B. nur eine Datei auf ein
neues Band schreiben und danach wieder lesen. Führt das bereits zum
gleichen Fehler?

Nachdem die regulären Backups (mittels dump) bisher immer
funktionierten, habe ich dump mal auf ein kleines Filesystem
losgelassen, bei dem nur sehr wenige Dateien zu sichern sind. War
innerhalb weniger Sekunden fertig. Das Gleiche mit einem großen
Laufwerk rödelt minutenlang hin und zurück und gibt mit dem selben
Fehler dann auf...

Dann hat das Laufwerk wohl wirklich den Geist aufgegeben.

[Volker Englisch]

Post by Michael Bäuerle

Post by Volker Englisch

Post by Michael Bäuerle
[...]
Versuche es mal mit reduzierter Datenmenge, z.B. nur eine Datei auf ein
neues Band schreiben und danach wieder lesen. Führt das bereits zum
gleichen Fehler?

Nachdem die regulären Backups (mittels dump) bisher immer
funktionierten, habe ich dump mal auf ein kleines Filesystem
losgelassen, bei dem nur sehr wenige Dateien zu sichern sind. War
innerhalb weniger Sekunden fertig. Das Gleiche mit einem großen
Laufwerk rödelt minutenlang hin und zurück und gibt mit dem selben
Fehler dann auf...

Dann hat das Laufwerk wohl wirklich den Geist aufgegeben.

Sieht so aus. Auch dir danke für Deine Hilfestellung!

[Marcel Mueller]

Post by Volker Englisch
Mit verschiedenen nagelneuen Bändern versucht, ohne Erfolg.
Gehe ich recht in der Annahme, dass das Laufwerk dabei ist, das
Zeitliche zu segnen?

Möglich. Bei mir hat es kürzlich bei komplett identischen Symptomen
allerdings einer LTO3 Library geholfen, den SCSI-Terminator gegen einen
älteren zu tauschen. Der zieht den Bus mangels LVD auf UW-SCSI runter.
Ob es jetzt ursächlich am SCSI-Kabel liegt oder daran dass damit
indirekt auch die Bandgeschwindigkeit runter fährt, habe ich noch nicht
ergründet. Aber damit kann ich wieder ein halbes Tera auf ein Band
schreiben, ohne dass es Fehler gibt. Auch der Smart-Zähler für per Retry
geschriebene Blöcke bleibt nach dem Backup meistens auf 0.

Post by Volker Englisch
PS: Bitte Followup-To dahin setzen wohin es am bessten passt...

Hmm, ich denke d.c.h.l.misc passt.


Marcel

[Marcel Mueller]

Nächster Versuch: dd if=/dev/zero of=/dev/rst0 bs=10k

Viel zu klein. Für DLT mindestens 256k, für LTO darf's auch noch mehr
sein. Ich nehme meist 1M.

Spannend wäre noch zu wissen, ob die Hardwarekompression aktiviert ist.
Mit selbiger ist Nullen schreiben irgendwie unspannend.

dd: /dev/rst0: Ein/Ausgabefehler
12497+0 records in
12496+0 records out
127959040 bytes transferred in 823.214 secs (155430 bytes/sec)

Viel zu langsam. Das liegt an der zu kleinen Blockgröße.
Ein LTO2 müsste eher so um die 30-40MB/s durch schieben.

Den Fehler erklärt das aber nicht.

st0(mpt0:0:1:0): Check Condition on CDB: 0x10 00 00 00 02 00
    SENSE KEY:  Unit Attention
     ASC/ASCQ:  SCSI Bus Reset Occurred
st0(mpt0:0:1:0): DEFERRED ERROR, key = 0x3
st0(mpt0:0:1:0): Check Condition on CDB: 0x1e 00 00 00 00 00
    SENSE KEY:  Media Error
     ASC/ASCQ:  Write Error
Ich habe die Sicherung jetzt mal auf externe Festplatten umgestellt.
Irgendwie ist mein Latein am Ende ;)

Tja, den Fehler bekomme ich auch.
Ich muss nochmal gucken, ob ich noch ein anderes (langes) SCSI-Kabel habe.


Marcel

[Volker Englisch]

Post by Marcel Mueller

Nächster Versuch: dd if=/dev/zero of=/dev/rst0 bs=10k

Viel zu klein. Für DLT mindestens 256k, für LTO darf's auch noch mehr
sein. Ich nehme meist 1M.

Habe es heute abend mit 1M probiert. Das ganze System stand still, es
half nur noch der Netzschalter :(

Post by Marcel Mueller
Spannend wäre noch zu wissen, ob die Hardwarekompression aktiviert ist.
Mit selbiger ist Nullen schreiben irgendwie unspannend.

Natürlich ohne Hardwarekompression...

Ich hab das Laufwerk jetzt ausgebaut, nachdem der Rechner sowieso nicht
mehr regulär zu rebooten war. In Zukunft gibts Backups auf
USB-Festplatten...

Danke für deine Hilfe!