DDS4-Laufwerk Fehler beim Schreiben

[Volker Englisch]

Hallo NG,

neuerdings "zickt" mein Bandlaufwerk etwas. Während es beim Einlesen
keine Probleme gibt, geht das Schreiben irgendwann schief. Irgendwann
heisst, es geht relativ lange gut, bis plötzlich der Fehler auftritt:

Jan 2 16:23:55 rsli kernel: sa0 at ahc0 bus 0 target 3 lun 0
Jan 2 16:23:55 rsli kernel: sa0: <HP C5683A C111> Removable Sequential Access SCSI-2 device
Jan 2 16:23:55 rsli kernel: sa0: 10.000MB/s transfers (10.000MHz, offset 15)
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): WRITE FILEMARKS(6). CDB: 10 0 0 0 2 0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): CAM Status: SCSI Status Error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): SCSI Status: Check Condition
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): MEDIUM ERROR asc:3b,0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Sequential positioning error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Retries Exhausted
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): failed to write terminating filemark(s)

Das OS ist FreeBSD, ich bin mir aber nicht sicher, ob das Problem OS-
abhängig ist. Was kann man gegen den Fehler machen? Reinigungsband und
mehrere andere ganz neue Bänder habe ich probiert, hat nichts gebracht.
Laufwerk hinüber?

V*

[Michael Baeuerle]

Post by Volker Englisch
neuerdings "zickt" mein Bandlaufwerk etwas. Während es beim Einlesen
keine Probleme gibt, geht das Schreiben irgendwann schief. Irgendwann
Jan 2 16:23:55 rsli kernel: sa0 at ahc0 bus 0 target 3 lun 0
Jan 2 16:23:55 rsli kernel: sa0: <HP C5683A C111> Removable Sequential Access SCSI-2 device
Jan 2 16:23:55 rsli kernel: sa0: 10.000MB/s transfers (10.000MHz, offset 15)
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): WRITE FILEMARKS(6). CDB: 10 0 0 0 2 0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): CAM Status: SCSI Status Error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): SCSI Status: Check Condition
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): MEDIUM ERROR asc:3b,0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Sequential positioning error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Retries Exhausted
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): failed to write terminating filemark(s)
Das OS ist FreeBSD, ich bin mir aber nicht sicher, ob das Problem OS-
abhängig ist.

Ist es in diesem Fall nicht. Hier hat das Laufwerk den Befehl
WRITE FILEMARKS abgebrochen mit:

Status : 02h (CHECK CONDITION)

Anschließend wurde der Befehl REQUEST SENSE ausgeführt und diese
Informationen vom Laufwerk geliefert:

Sense Key : 03h (MEDIUM ERROR)
Sense Code: 3Bh/00h (SEQUENTIAL POSITIONING ERROR)

Der Fehler wurde also nicht vom OS, sondern vom Laufwerk diagnostiziert.
Zu SCSI-Status und -Fehlercodes siehe:
<http://www.t10.org/lists/2status.htm>
<http://www.t10.org/lists/2sensekey.htm>
<http://www.t10.org/lists/asc-num.htm>

Post by Volker Englisch
Was kann man gegen den Fehler machen? Reinigungsband und
mehrere andere ganz neue Bänder habe ich probiert, hat nichts gebracht.
Laufwerk hinüber?

Sieht so aus. Reinigungsband mehrmals hintereinander hilft manchmal
temporär, aber zuverlässig laufen wird das vermutlich nicht mehr.

Ich würde es aber erstmal nicht weiter quälen bis getestet ist, dass
das neue Laufwerk die vorhandenen Medien ebenfalls noch lesen kann.

[Volker Englisch]

Michael Baeuerle schrieb...

Post by Michael Baeuerle

Post by Volker Englisch
neuerdings "zickt" mein Bandlaufwerk etwas. Während es beim Einlesen
keine Probleme gibt, geht das Schreiben irgendwann schief. Irgendwann
Jan 2 16:23:55 rsli kernel: sa0 at ahc0 bus 0 target 3 lun 0
Jan 2 16:23:55 rsli kernel: sa0: <HP C5683A C111> Removable Sequential Access SCSI-2 device
Jan 2 16:23:55 rsli kernel: sa0: 10.000MB/s transfers (10.000MHz, offset 15)
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): WRITE FILEMARKS(6). CDB: 10 0 0 0 2 0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): CAM Status: SCSI Status Error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): SCSI Status: Check Condition
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): MEDIUM ERROR asc:3b,0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Sequential positioning error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Retries Exhausted
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): failed to write terminating filemark(s)
Was kann man gegen den Fehler machen? Reinigungsband und
mehrere andere ganz neue Bänder habe ich probiert, hat nichts gebracht.
Laufwerk hinüber?

Sieht so aus. Reinigungsband mehrmals hintereinander hilft manchmal
temporär, aber zuverlässig laufen wird das vermutlich nicht mehr.

Danke für die Erläuterungen. Das Reinigungsband habe ich fünf mal
laufen lassen, hat leider nichts gebracht. Mich wundert nur, warum der
Fehler erst relativ spät auftritt, also erst mitten im Backup.

Post by Michael Baeuerle
Ich würde es aber erstmal nicht weiter quälen bis getestet ist, dass
das neue Laufwerk die vorhandenen Medien ebenfalls noch lesen kann.

Ich habe noch ein passendes zweites Laufwerk auf einem Ersatzrechner,
mit dem habe ich die Kompatibilität für den Fall eines Super-Gaus
getestet. Ein Umbau in den laufenden Rechner wäre somit möglich.

Inzwischen habe ich ein externes DLT8000-Laufwerk an der Maschine
hängen. Diese Technologie ist doch etwas zuverlässiger, daher werde ich
wahrscheinlich ein internes DLT- oder gleich LTO-Laufwerk beschaffen.
Wobei, für LTO werde ich wohl eine SCSI-Karte benötigen, die Ultra-2
kann...

[Michael Baeuerle]

Post by Volker Englisch
Michael Baeuerle schrieb...

Post by Michael Baeuerle

Post by Volker Englisch
neuerdings "zickt" mein Bandlaufwerk etwas. Während es beim Einlesen
keine Probleme gibt, geht das Schreiben irgendwann schief. Irgendwann
Jan 2 16:23:55 rsli kernel: sa0 at ahc0 bus 0 target 3 lun 0
Jan 2 16:23:55 rsli kernel: sa0: <HP C5683A C111> Removable Sequential Access SCSI-2 device
Jan 2 16:23:55 rsli kernel: sa0: 10.000MB/s transfers (10.000MHz, offset 15)
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): WRITE FILEMARKS(6). CDB: 10 0 0 0 2 0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): CAM Status: SCSI Status Error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): SCSI Status: Check Condition
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): MEDIUM ERROR asc:3b,0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Sequential positioning error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Retries Exhausted
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): failed to write terminating filemark(s)
Was kann man gegen den Fehler machen? Reinigungsband und
mehrere andere ganz neue Bänder habe ich probiert, hat nichts gebracht.
Laufwerk hinüber?

Sieht so aus. Reinigungsband mehrmals hintereinander hilft manchmal
temporär, aber zuverlässig laufen wird das vermutlich nicht mehr.

Danke für die Erläuterungen. Das Reinigungsband habe ich fünf mal
laufen lassen, hat leider nichts gebracht. Mich wundert nur, warum der
Fehler erst relativ spät auftritt, also erst mitten im Backup.

Der Fehler trat beim schreiben einer Filemark auf. Vielleicht setzt
das Laufwerk da andere Maßstäbe an als für normale Daten (die ja mit
Redundanz geschrieben werden), weniger Retry-Versuche oder was auch
immer.

Post by Volker Englisch

Post by Michael Baeuerle
Ich würde es aber erstmal nicht weiter quälen bis getestet ist, dass
das neue Laufwerk die vorhandenen Medien ebenfalls noch lesen kann.

Ich habe noch ein passendes zweites Laufwerk auf einem Ersatzrechner,
mit dem habe ich die Kompatibilität für den Fall eines Super-Gaus
getestet. Ein Umbau in den laufenden Rechner wäre somit möglich.
Inzwischen habe ich ein externes DLT8000-Laufwerk an der Maschine
hängen. Diese Technologie ist doch etwas zuverlässiger,

Nicht nur "etwas", das ist eine andere Liga.

Post by Volker Englisch
daher werde ich
wahrscheinlich ein internes DLT- oder gleich LTO-Laufwerk beschaffen.

Zumindest LTO-1 war noch richtig "bodenständig" und hat noch keine PRML-
Codierung verwendet.

Post by Volker Englisch
Wobei, für LTO werde ich wohl eine SCSI-Karte benötigen, die Ultra-2
kann...

Das hier ist ein HP LTO-2 Laufwerk (HH):
|
| scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
| <Adaptec aic7890/91 Ultra2 SCSI adapter>
| aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
|
| Vendor: HP Model: Ultrium 2-SCSI Rev: S63D
| Type: Sequential-Access ANSI SCSI revision: 03
| target2:0:3: Beginning Domain Validation
| target2:0:3: wide asynchronous
| target2:0:3: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 64)
| target2:0:3: Domain Validation skipping write tests
| target2:0:3: Ending Domain Validation

Das unterstützt den Fast40-Transfermodus auf 16Bit-Busbreite. Wenn
man Wikipedia glauben darf liegt die maximale Transferrate für LTO-2
(ohne Kompression) bei 40MByte/s, das wäre also mit Fast20 auch noch
machbar (zumindest wenn das Laufwerk den Bus für sich allein hätte).

Ansonsten kann man es auch mit LTO-1 Medien betreiben, um es damit
etwas "auszubremsen". Alle LTO-Laufwerke können auch auf Medien
der Vorgängergeneration schreiben.

Die Laufwerke können zum Teil auch runterbremsen, d.h. langsamer
schreiben ohne anhalten zu müssen, wenn nicht genug Daten ankommen.

[Volker Englisch]

Michael Baeuerle schrieb...

Post by Michael Baeuerle

Post by Volker Englisch
daher werde ich
wahrscheinlich ein internes DLT- oder gleich LTO-Laufwerk beschaffen.

Zumindest LTO-1 war noch richtig "bodenständig" und hat noch keine PRML-
Codierung verwendet.

Post by Volker Englisch
Wobei, für LTO werde ich wohl eine SCSI-Karte benötigen, die Ultra-2
kann...

|
| scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
| <Adaptec aic7890/91 Ultra2 SCSI adapter>
| aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs

| ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xb000-0xb0ff mem 0xea000000-0xea000fff irq 21 at device 13.0 on pci2
| ahc0: [ITHREAD]
| aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs

Das wird wohl für LTO-2 nicht reichen :-(

V*

[Michael Baeuerle]

Post by Volker Englisch
Michael Baeuerle schrieb...

Post by Michael Baeuerle

Post by Volker Englisch
daher werde ich
wahrscheinlich ein internes DLT- oder gleich LTO-Laufwerk beschaffen.

Zumindest LTO-1 war noch richtig "bodenständig" und hat noch keine PRML-
Codierung verwendet.

Post by Volker Englisch
Wobei, für LTO werde ich wohl eine SCSI-Karte benötigen, die Ultra-2
kann...

|
| scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
| <Adaptec aic7890/91 Ultra2 SCSI adapter>
| aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs

| ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xb000-0xb0ff mem 0xea000000-0xea000fff irq 21 at device 13.0 on pci2
| ahc0: [ITHREAD]
| aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs
Das wird wohl für LTO-2 nicht reichen :-(

Ja, ein AIC7880 wäre da schon ein bisschen mickrig ...
Aber passende HAs mit parallelem SCSI-Interface müsstest du eigentlich
quasi umsonst hinterhergeworfen bekommen.
Du brauchst ja Host-seitig gerade kein PCIe - dafür waren die selten,
für paralleles PCI gab es die aber massenweise.

Sonst halt doch das alte DLT, das ist ja passend langsam.

[Marcel Mueller]

On 07.02.16 18.08, Volker Englisch wrote:
[Schreibfehler]

Post by Volker Englisch
Das OS ist FreeBSD, ich bin mir aber nicht sicher, ob das Problem OS-
abhängig ist. Was kann man gegen den Fehler machen? Reinigungsband und
mehrere andere ganz neue Bänder habe ich probiert, hat nichts gebracht.
Laufwerk hinüber?

Ich würde sagen ja. DDS Krankheit ist doch, dass die Köpfe nach einigen
Runden aufgeben. Reinigung kann helfen, wenn es nur Dreck ist. Bei viel
genutzten Laufwerken ist aber eher der Kopf abgeschliffen.
Was mich etwas irritiert ist, dass es beim Schreiben der Positionsmarken
passiert. Ich hatte selber nie DDS bzw. Schrägspur (wegen der
Zuverlässigkeit), aber AFAIK ist dafür ein eigener, weniger
empfindlicher Kopf zuständig. Das lässt noch etwas hoffen, dass
Zähneputzen reicht.
Kann das Laufwerk denn die eigenen Aufzeichnungen noch zuverlässig
lesen, oder gibt es da auch Fehler?


Marcel

[Juergen P. Meier]

Post by Marcel Mueller
Kann das Laufwerk denn die eigenen Aufzeichnungen noch zuverlässig
lesen, oder gibt es da auch Fehler?

Du erwartest, dass jemand der DDS fuer Backup misbraucht nach
stundenlangem quetschen der paar Gigabytes auf eine Musikkasette
noch Zeit damit verschwendet das ganze nochmal zum verifizieren
einzulesen?

DDS-Schraegspursysteme mit normalen kompakten Laufwerken koennen
das geschriebene nach Abschluss des Schreibvorgangs nicht in einem
eigenen Lesevorgang zur Verifikation einlesen. Das geht nicht mit nur
einem Zylinderkopftraeger.

Und nein, das sofortige Lesen noch in der selben Spur waehrend des
Schreibens ist *KEINE* Verifikation. War es nie und *JEDER* der sich
darauf verlassen hat, hat irgendwann genau diese Lektion gelernt.

Was naemlich bei der DDS-"inline-verification" konzeptionell nicht
verifiziert werden kann ist die korrekte Positionierung des Lesekopfes,
weil dieser konstruktionsbedingt genau hinter dem Schreibkopf liegt und
beim Schreiben deswegen automatisch bereits richtig in der Spur liegt.

Neben Pferden habe ich vor Jahren oft genug DDS-Laufwerke gesehen, die
beim Write+Verify "Alles OK!!11elf" riefen, beim Leseversuch dann
aber "Ich kann die Spur nicht finden!" kotzten.

[Marcel Mueller]

Post by Juergen P. Meier
Du erwartest, dass jemand der DDS fuer Backup misbraucht nach
stundenlangem quetschen der paar Gigabytes auf eine Musikkasette
noch Zeit damit verschwendet das ganze nochmal zum verifizieren
einzulesen?

Ja, ab und an sollte man das mal testen. Vor allem bei DDS.

Post by Juergen P. Meier
DDS-Schraegspursysteme mit normalen kompakten Laufwerken koennen
das geschriebene nach Abschluss des Schreibvorgangs nicht in einem
eigenen Lesevorgang zur Verifikation einlesen. Das geht nicht mit nur
einem Zylinderkopftraeger.

Weiß ich. Deswegen hatte ich ja DLT und jetzt eine LTO-Library. Die
bekommt man mit vertretbarem Aufwand nicht kurz. Und Fehler gibt es da
wenn dann beim Schreiben. Lesen geht eigentlich immer. (Wie damals bei
den MOs, da war's genauso.)

Post by Juergen P. Meier
Und nein, das sofortige Lesen noch in der selben Spur waehrend des
Schreibens ist *KEINE* Verifikation. War es nie und *JEDER* der sich
darauf verlassen hat, hat irgendwann genau diese Lektion gelernt.
Was naemlich bei der DDS-"inline-verification" konzeptionell nicht
verifiziert werden kann ist die korrekte Positionierung des Lesekopfes,
weil dieser konstruktionsbedingt genau hinter dem Schreibkopf liegt und
beim Schreiben deswegen automatisch bereits richtig in der Spur liegt.
Neben Pferden habe ich vor Jahren oft genug DDS-Laufwerke gesehen, die
beim Write+Verify "Alles OK!!11elf" riefen, beim Leseversuch dann
aber "Ich kann die Spur nicht finden!" kotzten.

Is ja gut. Nicht aufregen. Ich hol schon mal das Sogo. :-)


Marcel

[Volker Englisch]

Juergen P. Meier schrieb...

Post by Juergen P. Meier

Post by Marcel Mueller
Kann das Laufwerk denn die eigenen Aufzeichnungen noch zuverlässig
lesen, oder gibt es da auch Fehler?

Du erwartest, dass jemand der DDS fuer Backup misbraucht nach
stundenlangem quetschen der paar Gigabytes auf eine Musikkasette
noch Zeit damit verschwendet das ganze nochmal zum verifizieren
einzulesen?

Doch, der tat das :-) Oder zählt ein Rewind und anschliessendes Testen
auf Lesbarkeit nicht dazu?

[Juergen P. Meier]

Post by Volker Englisch
Juergen P. Meier schrieb...

Post by Juergen P. Meier

Post by Marcel Mueller
Kann das Laufwerk denn die eigenen Aufzeichnungen noch zuverlässig
lesen, oder gibt es da auch Fehler?

Du erwartest, dass jemand der DDS fuer Backup misbraucht nach
stundenlangem quetschen der paar Gigabytes auf eine Musikkasette
noch Zeit damit verschwendet das ganze nochmal zum verifizieren
einzulesen?

Doch, der tat das :-) Oder zählt ein Rewind und anschliessendes Testen
auf Lesbarkeit nicht dazu?

Doch, tut es. Hobbyisten haben zu viel Zeit :)

Aber immerhin hat er jetzt was ordentliches (DLT), damit kann er
wieder gluecklich sein.

[Volker Englisch]

Juergen P. Meier schrieb...

Post by Juergen P. Meier

Post by Volker Englisch
Juergen P. Meier schrieb...

Post by Juergen P. Meier

Post by Marcel Mueller
Kann das Laufwerk denn die eigenen Aufzeichnungen noch zuverlässig
lesen, oder gibt es da auch Fehler?

Du erwartest, dass jemand der DDS fuer Backup misbraucht nach
stundenlangem quetschen der paar Gigabytes auf eine Musikkasette
noch Zeit damit verschwendet das ganze nochmal zum verifizieren
einzulesen?

Doch, der tat das :-) Oder zählt ein Rewind und anschliessendes Testen
auf Lesbarkeit nicht dazu?

Doch, tut es. Hobbyisten haben zu viel Zeit :)

Ach wo :) Sowas läuft des Nächtens automatisch...

Post by Juergen P. Meier
Aber immerhin hat er jetzt was ordentliches (DLT), damit kann er
wieder gluecklich sein.

Er ist glücklich 8-)

[Volker Englisch]

Marcel Mueller schrieb...

Post by Marcel Mueller
[Schreibfehler]

Post by Volker Englisch
Das OS ist FreeBSD, ich bin mir aber nicht sicher, ob das Problem OS-
abhängig ist. Was kann man gegen den Fehler machen? Reinigungsband und
mehrere andere ganz neue Bänder habe ich probiert, hat nichts gebracht.
Laufwerk hinüber?

Ich würde sagen ja.

Hab ich befürchtet.

Post by Marcel Mueller
Kann das Laufwerk denn die eigenen Aufzeichnungen noch zuverlässig
lesen, oder gibt es da auch Fehler?

Ja. Ich habe ein paar Backups mal probehalber zurückgesichert, die
liefen problemlos durch.

[Juergen P. Meier]

Volker Englisch <***@rsli.de>:

Urgh, DDS ist helical-scan Audio-Tape das fuer Datenspeicherung
misbraucht wurde. DDS4 ist der versuch mit viel zu hohen Datendichten
wenigstens ein paar dutzend Gigabyte auf eine Kasette zu stopfen, auf
Kosten der Interoperabiliaet.

Zuverlaessig ist anders.

Post by Volker Englisch
neuerdings "zickt" mein Bandlaufwerk etwas. Während es beim Einlesen
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): CAM Status: SCSI Status Error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): SCSI Status: Check Condition
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): MEDIUM ERROR asc:3b,0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Sequential positioning error
Das OS ist FreeBSD, ich bin mir aber nicht sicher, ob das Problem OS-
abhängig ist. Was kann man gegen den Fehler machen? Reinigungsband und

Ist es wohl nicht, der Fehler wird vom Laufwerk gemeldet.

Post by Volker Englisch
mehrere andere ganz neue Bänder habe ich probiert, hat nichts gebracht.
Laufwerk hinüber?

Ich wuerde auf abgenutzte Gummirollen tippen (wenn das Laufwerk das
Band nicht mehr praeziese genug ueber den schraeg stehenden
Schreib-Lesekopfzylinder positioieren kann, dann kann das diesen
Fehler verursachen), oder aber Verschmutzung

1.) Bandlaufwerk Reinigen. Das haettest du sowieso regelmaessig machen
muessen (siehe Handbuch), also wirst du auch ein Reinigungstape haben.

Falls du kein Reinigungs-tape hast und auch nicht regelmaessig damit
gereinigt hast, dann selbst schuld[tm]. Wenn die Ablagerungen zu dick
sind, hilft dir jetzt kein Reinigungsband mehr, dann musst du es
zerlegen. Viel Spass beim wiederzusammenbauen.

2.) Bandlaufwerk oeffnen und alle Teile pruefen (insb. jede Form
von Gummirolle auf Verschleiss pruefen und ggf. ersetzen) und nach
Anleitung reinigen.

Wenn das nichts hilft, neues Laufwerk und neue Baender* kaufen.

(fuer DDS4 wirst du kaum Garantie haben).

DDS4 ist (zu recht) beruechtigt dafuer wegen extrem kleiner Toleranzen
bei den Aufzeichungsstreifen und Fertigungsvariationen bei den
Zylindern eine starke Bindung zwischen Tape und dem Laufwerk, mit dem
es beschrieben wurde zu erzeugen. Ich habe schon viele
moechtegern-Backupper daran verzweifeln gesehen, wie sie versuchten
ihre wertvollen Backupbaender nach einem Laufwerkausfall mit einem
anderen Laufwerk fehlerfrei zu lesen. So viele Traenen der
Verzweiflung... Danke, mit deinem Posting hast du schoene Erinnerungen
an Schadenfreude aus laengst vergangene Zeiten* geweckt ;)

*Als meine Kollegen und Bekannten noch mit DDS gespielt haben.

[Volker Englisch]

Juergen P. Meier schrieb...

Post by Juergen P. Meier
Urgh, DDS ist helical-scan Audio-Tape das fuer Datenspeicherung
misbraucht wurde. DDS4 ist der versuch mit viel zu hohen Datendichten
wenigstens ein paar dutzend Gigabyte auf eine Kasette zu stopfen, auf
Kosten der Interoperabiliaet.

Ich weiß :-(

Post by Juergen P. Meier

Post by Volker Englisch
neuerdings "zickt" mein Bandlaufwerk etwas. Während es beim Einlesen
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): CAM Status: SCSI Status Error
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): SCSI Status: Check Condition
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): MEDIUM ERROR asc:3b,0
Feb 6 20:57:20 rsli kernel: (sa0:ahc0:0:3:0): Sequential positioning error

1.) Bandlaufwerk Reinigen. Das haettest du sowieso regelmaessig machen
muessen (siehe Handbuch), also wirst du auch ein Reinigungstape haben.

Habe ich gemacht, hat nichts (mehr) gebracht.

Post by Juergen P. Meier
2.) Bandlaufwerk oeffnen und alle Teile pruefen (insb. jede Form
von Gummirolle auf Verschleiss pruefen und ggf. ersetzen) und nach
Anleitung reinigen.

Dazu werden meine feinmotorischen Fähigkeiten kaum ausreichen...

Post by Juergen P. Meier
Wenn das nichts hilft, neues Laufwerk und neue Baender* kaufen.

Ich habe in der Zwischenzeit ein noch vorhandenes externes
DLT8000-Laufwerk angeschlossen und sichere im Moment über dieses.

Post by Juergen P. Meier
DDS4 ist (zu recht) beruechtigt dafuer wegen extrem kleiner Toleranzen
bei den Aufzeichungsstreifen und Fertigungsvariationen bei den
Zylindern eine starke Bindung zwischen Tape und dem Laufwerk, mit dem
es beschrieben wurde zu erzeugen. Ich habe schon viele
moechtegern-Backupper daran verzweifeln gesehen, wie sie versuchten
ihre wertvollen Backupbaender nach einem Laufwerkausfall mit einem
anderen Laufwerk fehlerfrei zu lesen. So viele Traenen der
Verzweiflung... Danke, mit deinem Posting hast du schoene Erinnerungen
an Schadenfreude aus laengst vergangene Zeiten* geweckt ;)

:-) Eigentlich wusste ich ja über die Unzulänglichkeiten von DDS
Bescheid, aber es hat doch rund 15 Jahre relativ problemlos
funktioniert ;-)

[Marcel Mueller]

Post by Volker Englisch
Ich habe in der Zwischenzeit ein noch vorhandenes externes
DLT8000-Laufwerk angeschlossen und sichere im Moment über dieses.

Das würde ich behalten. Geht genauso viel drauf, ist wesentlich robuster
und auch doppelt so schnell.

Post by Volker Englisch
:-) Eigentlich wusste ich ja über die Unzulänglichkeiten von DDS
Bescheid, aber es hat doch rund 15 Jahre relativ problemlos
funktioniert ;-)

Alles eine Frage des Nutzungsprofils. Wenn die für's tägliche Backup
automatisch laufen, überleben die Laufwerke kaum das zweite Jahr. Wenn
man privat nur alle paar Wochen mal ein paar Bänder durch schiebt und
selbige auch nicht 50-mal bespielt, geht das schon.


Marcel

[Volker Englisch]

Marcel Mueller schrieb...

Post by Marcel Mueller

Post by Volker Englisch
Ich habe in der Zwischenzeit ein noch vorhandenes externes
DLT8000-Laufwerk angeschlossen und sichere im Moment über dieses.

Das würde ich behalten. Geht genauso viel drauf, ist wesentlich robuster
und auch doppelt so schnell.

Nicht doppelt so viel? Auf den DDS4-Medien steht 20 GB unkomprimiert,
auf den DLTs 40 GB.

Post by Marcel Mueller

Post by Volker Englisch
:-) Eigentlich wusste ich ja über die Unzulänglichkeiten von DDS
Bescheid, aber es hat doch rund 15 Jahre relativ problemlos
funktioniert ;-)

Alles eine Frage des Nutzungsprofils. Wenn die für's tägliche Backup
automatisch laufen, überleben die Laufwerke kaum das zweite Jahr. Wenn
man privat nur alle paar Wochen mal ein paar Bänder durch schiebt und
selbige auch nicht 50-mal bespielt, geht das schon.

Ich sichere bisher 1 mal pro Woche, am 1. WE je Monat zwei Bänder, die
restlichen Wochen rotieren monatlich durch und wurden entsprechend auch
öfter mal ersetzt. Sobald ich mit den DLTs auch mehr als 1 Band pro WE
brauche, mache ich mir über differentielle Backups Gedanken...

V*

[Marcel Mueller]

Post by Volker Englisch
Marcel Mueller schrieb...

Post by Marcel Mueller

Post by Volker Englisch
Ich habe in der Zwischenzeit ein noch vorhandenes externes
DLT8000-Laufwerk angeschlossen und sichere im Moment über dieses.

Das würde ich behalten. Geht genauso viel drauf, ist wesentlich robuster
und auch doppelt so schnell.

Nicht doppelt so viel? Auf den DDS4-Medien steht 20 GB unkomprimiert,
auf den DLTs 40 GB.

Oops, nicht aufgepasst. Ich dachte die hätten auch netto 40. Ein Grund
mehr zu wechseln.

Post by Volker Englisch
Ich sichere bisher 1 mal pro Woche, am 1. WE je Monat zwei Bänder, die
restlichen Wochen rotieren monatlich durch und wurden entsprechend auch
öfter mal ersetzt. Sobald ich mit den DLTs auch mehr als 1 Band pro WE
brauche, mache ich mir über differentielle Backups Gedanken...

Gebrauchte LTO-3 Libraries gehen öfters zweistellig über den Tisch.
(Deutlich billiger als das darin enthaltene Laufwerk einzeln.)
Also wenn man Platz im Keller hat... Da gehen ein paar Tera drauf. Und
1/3 Tera die Stunde ist auch schon ganz zügig.


Marcel