info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Fehler beim Beschreiben eines Bandes (NetBSD, LTO-2)
3 views
Skip to first unread message
Volker Englisch
Oct 25, 2021, 8:58:07 AM10/25/21
to
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...
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
Oct 25, 2021, 9:39:10 AM10/25/21
to
Volker Englisch wrote:
>
> 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.
SCSI Sense-Key und ASC kommen vom Laufwerk, d.h. es sollte nichts mit
>
> 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.
dem Host-System zu tun haben.
> Gehe ich recht in der Annahme, dass das Laufwerk dabei ist, das
> Zeitliche zu segnen?
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?
> PS: Bitte Followup-To dahin setzen wohin es am bessten passt...
Betriebssystem aussieht.
Volker Englisch
Oct 25, 2021, 12:58:07 PM10/25/21
to
Michael Bäuerle schrieb am Mo., 25 Okt. 2021 um 13:38 GMT:
> Volker Englisch wrote:
>>
>> 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.
>
> SCSI Sense-Key und ASC kommen vom Laufwerk, d.h. es sollte nichts mit
> dem Host-System zu tun haben.
>
>> 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
Hier ist es laut /var/log/messages ein HP, Ultrium 2-SCSI, S65D
> Volker Englisch wrote:
>>
>> 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.
>
> SCSI Sense-Key und ASC kommen vom Laufwerk, d.h. es sollte nichts mit
> dem Host-System zu tun haben.
>
>> 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.
> 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?
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...
Marcel Mueller
Oct 25, 2021, 4:33:24 PM10/25/21
to
Am 25.10.21 um 14:41 schrieb Volker Englisch:
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.
> PS: Bitte Followup-To dahin setzen wohin es am bessten passt...
Hmm, ich denke d.c.h.l.misc passt.
Marcel
> 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
>
> Gehe ich recht in der Annahme, dass das Laufwerk dabei ist, das
> Zeitliche zu segnen?
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.
> PS: Bitte Followup-To dahin setzen wohin es am bessten passt...
Marcel
Volker Englisch
Oct 26, 2021, 10:28:07 AM10/26/21
to
Am 25.10.2021 um 22:33 schrieb Marcel Mueller:
> Am 25.10.21 um 14:41 schrieb 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.
Wie gesagt, bis vergangenen Sonntag lief die Sicherung auf diesem Gerät
> Am 25.10.21 um 14:41 schrieb 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.
noch einwandfrei. Ich werde mal sehen, ob ich noch einen älteren
Terminator finde und diesen ausprobieren.
Heute hatte ich die sagenhafte Idee, das Bandlaufwerk probehalber mit
Nullen zu fluten:
dd if=/dev/zero of=/dev/st0
worauf der Kernel meinte:
10240-byte tape record is too big for 2048-byte user buffer
Incorrect Length Indicator Set
Wo und wie kann man den user-buffer denn beeinflussen?
Nächster Versuch: dd if=/dev/zero of=/dev/rst0 bs=10k
ergibt nach etwa 17 Minuten Laufzeit:
dd: /dev/rst0: Ein/Ausgabefehler
12497+0 records in
12496+0 records out
127959040 bytes transferred in 823.214 secs (155430 bytes/sec)
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 ;)
Marcel Mueller
Oct 26, 2021, 12:45:05 PM10/26/21
to
Am 26.10.21 um 15:57 schrieb Volker Englisch:
sein. Ich nehme meist 1M.
Spannend wäre noch zu wissen, ob die Hardwarekompression aktiviert ist.
Mit selbiger ist Nullen schreiben irgendwie unspannend.
> ergibt nach etwa 17 Minuten Laufzeit:
>
> 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
> 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.
> ergibt nach etwa 17 Minuten Laufzeit:
>
> dd: /dev/rst0: Ein/Ausgabefehler
> 12497+0 records in
> 12496+0 records out
> 127959040 bytes transferred in 823.214 secs (155430 bytes/sec)
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 ;)
Ich muss nochmal gucken, ob ich noch ein anderes (langes) SCSI-Kabel habe.
Marcel
Michael Bäuerle
Oct 26, 2021, 2:29:54 PM10/26/21
to
Volker Englisch wrote:
> Michael Bäuerle schrieb am Mo., 25 Okt. 2021 um 13:38 GMT:
> >
> > [...]
> Michael Bäuerle schrieb am Mo., 25 Okt. 2021 um 13:38 GMT:
> >
> > 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...
Dann hat das Laufwerk wohl wirklich den Geist aufgegeben.
> > 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...
Volker Englisch
Oct 27, 2021, 4:28:08 PM10/27/21
to
Volker Englisch
Oct 27, 2021, 4:28:08 PM10/27/21
to
Marcel Mueller schrieb am Di., 26 Okt. 2021 um 16:45 GMT:
> Am 26.10.21 um 15:57 schrieb Volker Englisch:
>> 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
> Am 26.10.21 um 15:57 schrieb Volker Englisch:
>> 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.
half nur noch der Netzschalter :(
> Spannend wäre noch zu wissen, ob die Hardwarekompression aktiviert ist.
> Mit selbiger ist Nullen schreiben irgendwie unspannend.
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!
0 new messages