scheinbar problem beim löschen von tape

[arvidflow]

um ein tape zu löschen soll man es zurückspulen und dann löschen. das habe ich getan und heraus kommt folgendes:


bus:/var/www# mt -f /dev/nst1 rewind
bus:/var/www# mt -f /dev/nst1 erase
mt: /dev/nst1: rmtioctl failed: Input/output error
bus:/var/www# mt -f /dev/nst1 status
drive type = 114
drive status = 1140851200
sense key error = 0
residue count = 0
file number = 0
block number = 0

offensichtlich liegt ein I/O-error vor, aber das band ist trotzdem leer, wie man an der statusmeldung erkennen kann? heißt das, dass alles in ordnung ist oder muss ich fehlersuche betreiben? was könnte das problem sein?

[HBtux]

- Band kaputt - schon mal ein anderen Band versucht?
- Streamer wieder mal reinigen (Reinigungsband)
- beim Band ist der Schreibschutz gesetzt (jetzt aber nicht aufregen - ich frage einfach mal alles ab....)

[arvidflow]

ich hab ein band, das hab ich eben ausgepackt und der schreibschutz ist auch nicht drin. ich hab es eben kontrolliert. wie es um die sauberkeit steht kann ich nicht sagen, es sieht aber nicht so aus, als sei da irgendwas faul.

[HBtux]

Wie es um die sauberkeit steht kann ich nicht sagen, es sieht aber nicht so aus, als sei da irgendwas faul.
Kannst Du Dich noch daran erinnern, wann Du das letzte Mal ein Reinigungsband eingelegt hattest....?
Ich tippe zwar auch nicht ausschließlich darauf, ich hatte aber schon oft genug Probleme mit Tapes gehabt,
bei denen man die Probleme auf die mangelnde Reinigung des Streamer zurückführen konnte....

Kannst Du das Band denn zurückspulen und dann ganz normal beschreiben....?

[arvidflow]

hm, das ist eine gute frage. zu anfang habe ich versucht aus testzwecken lediglich eine textdatei auf das band zu schreiben. die paar KB waren schnell geschrieben und konnten auch wieder hergestellt werden. ich habe das wie folgt getan:


tar -czf /dev/nst0 /nfs
cd /recover && mt -f /dev/nst0 rewind && tar -xzf /dev/nst0 nfs

resultat ist, dass nachdem die daten auf das band geschrieben wurden, diese wieder erfolgreich vom band in den ordner /recover transferiert worden sind.
gestern habe ich das ganze dann mit "richtigen daten" probiert. ich hab also ein backup von snapshots von 5 virtuellen maschinen angestoßen. mein problem ist nun, dass ich nicht sehen kann, ob dieser job bereits beendet wurde oder nicht. fakt ist, dass das band bsw. wie folgt reagiert:


tapeinfo -f /dev/nst1
cannot open SCSI device '/dev/nst1' - Device or resource busy

ich habe das gestern so stehen lassen, weil ich dachte es liegt evtl daran, dass das netzwerk zu langsam ist und der job wirklich so lange dauert. da diese meldung jedoch heute morgen immer noch da ist, wundert mich das ganze schon ein wenig.

________________________________
edit:
ich habe mich nun noch mal in den serverraum begeben und mal geschaut was das tape da eigentlich macht. es macht nichts. die aktivitätsleuchte ist nicht aktiv und die errorleuchte auch nicht. wenn ich mir aber ansehe wie die auslastung des servers ist muss ich feststellen, dass diese seit ewiger zeit konstant bei ca. 60-70% liegt.

[bla!zilla]

Ja wenn das Device noch beschäftigt ist, bzw. von einem anderen Prozess blockiert wird, kann tapeinfo dir nichts dazu sagen. Wenn du /dev/st0 verwendest, sparst du dir das Zurückspulen nach dem Backup. /dev/nst0 macht nur dann Sinn, wenn du mehrere Backups auf ein Band schreiben willst.

[pibi]

tar -czf /dev/nst0 /nfs
cd /recover && mt -f /dev/nst0 rewind && tar -xzf /dev/nst0 nfs


tapeinfo -f /dev/nst1
cannot open SCSI device '/dev/nst1' - Device or resource busy
nst0 oder nst1? Oder ist es nur ein Tippfehler?

Gruss Pit.

[arvidflow]

ist nur ein scheibfehler. es ist immer nst1. nst0 habe ich auch, am ende werden dann beie genutzt, aber ich denke mal es macht keinen unterschied. sind nur 2, weil es wohl so 1,3TB daten sein werden, die gesichert werden sollen. das passt auf 2 tapes a 800GB
ich hab übrigens rausgefunden warum das nicht ging. das netzwerk war zu lahm. ich hab versucht das mit 5MBit/s zu ziehen. das hätte tage gedauert. ich hab es also abgebrochen und baue jetzt das netzwerk um. dabei hab ich schon wieder ein blödes problem...naja.
/dev/st0 gibt es bei mir übrigens nicht. (?)

[HBtux]

/dev/st0 deutet auf einen Streamer hin, der automatisch zurückgespult wird...

/dev/nst0 deutet auf einen Streamer hin, der nicht automatisch zurückgespult wird.....


Mit dem hängenden Backup-Job hätte ich fast noch auf ggf. eine fehlerhafte SCSI-Terminierung getippt.....
Kann natürlich auch an den Daten über das Netz liegen...

Ich würde den Streamer mal mit lokal gespeicherten Daten stressen.....
Dann stellt sich raus, ob er wirklich richtig läuft.

[bla!zilla]

Versuchst du da ein LTO-3 über LAN zu befeuern?!?! Beschreib deine Umgebung mal etwas genauer, ich kenne mich ein wenig mit Backup aus.

[arvidflow]

richtig stress habe ich dem laufwerk (ja, LTO-3) bisher unter verwendung lokal gespeicherter daten nicht gemacht, habe aber eine kleine datei erfolgreich auf tape geschrieben und wieder hergestellt. das prinzipielle funktioniert also.
ich habe nun mal ne kleine skizze gemacht, die die die umgebung, die ich hier grad aufbaue, mit beispielhafter nomenklatur beschreibt.
nexenta stellt via nfs ein großes volumen mit den zu sichernden daten zur verfügung. mein debian backupsystem mountet dieses laufwerk lokal und soll nun die beinhalteten daten auf ein tape schieben. das ist eigentlich schon alles. wie man sieht gibt es jetzt eine direkte (virtuelle) netzwerkverbindung zwischen nexenta und debian. debian sieht also 2 netzwerkkarten. eine virtuelle, die an ein netzwerk angeschlossen ist, an dem sonst nur noch das nexenta hengt (10GBit) und eine andere, die an das physikalische interne netz angeschlossen ist. die erstgenannte hat demnach als einziges ziel die einbindung der nfs-freigabe von nexenta. über das andere netz soll unter anderem ein apache, sshd und ein mailserver laufen. der mailserver dient hierbei aber ausschließlich dafür eine möglichkeit zu haben dem admin die logfiles zuschicken zu können. alle genannten sachen funktionieren bereits, jedoch hab ich grad noch ein problem sei ich die neue netzwerkkarte hab. als ich die virtuelle netzwerkkarte "eingebaut" habe, wurde die dann komischerweise zu eth0 und die ehemals eth0 heißende zu eth1. seitdem gibt es da probleme. ich muss es irgendwie schaffen eth0 wieder im orginal herzustellen und eth1 als virtuelles netzwerk zu haben. ich denke dann wird alles wieder funktionieren. ein tip hierzu wäre auch sehr nützlich.
lg

[bla!zilla]

Gehe ich Recht in der Annahme, dass du das LTO in den Gast durchschleifst? Was für ein Controller ist da drin? Wie ist das RAID System angebunden? Pro LTO ein eigener Controller?

[arvidflow]

die probleme mit dem netzwerk hab ich in den griff bekommen.
ja genau ich schleife direkt durch. jedes laufwerk hat nen eigenen controller. hier ein paar infos zur hardware:


bus:~# tapeinfo -f /dev/st0
Product Type: Tape Drive
Vendor ID: 'HP '
Product ID: 'Ultrium 3-SCSI '
Revision: 'G54D'
Attached Changer API: No
SerialNumber: 'HU10650KNN'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x42
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 200448
Partition 0 Size in Kbytes: 200448
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0

bus:~# tapeinfo -f /dev/st1
Product Type: Tape Drive
Vendor ID: 'QUANTUM '
Product ID: 'ULTRIUM 3 '
Revision: '1974'
Attached Changer API: No
SerialNumber: 'PW0741AME50093'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x44
BlockSize: 512
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 310463
Partition 0 Size in Kbytes: 410150
ActivePartition: 0
EarlyWarningSize: 0

wie man sieht hab ich doch ein stx und nicht nur nstx. das ist mir bisher noch nicht aufgefallen.


bus:~# ls /dev/*st[0-1]
/dev/nst0 /dev/nst1 /dev/st0 /dev/st1

[HBtux]

richtig stress habe ich dem laufwerk (ja, LTO-3) bisher unter verwendung lokal gespeicherter daten nicht gemacht, habe aber eine kleine datei erfolgreich auf tape geschrieben und wieder hergestellt. das prinzipielle funktioniert also.
Ich würde aber trotzdem mal richtig große Mengen an Daten auf Band schreiben.
Gerade mit SCSI tauchen da ggf. auch mal Bus-Fehler auf, die Du mit einer kleinen Text-Datei von einen kByte nicht unbedingt merkst.....

[arvidflow]

gut, diesen test hab ich nun auch gemacht. kein problem. ich hab ne 700mb datei genommen.

[bla!zilla]

Wie ist das 1 TB Ding angebunden.

Ganz ehrlich: Deine Umgebung ist sowas von unsupported und mit möglichen Fehlerquellen gespickt, ich würde mich kaum trauen das produktiv zu betreiben. Direkt angeschlossene Bandlaufwerke in Gastsystemen sind nicht supported. Kann gehen, muss nicht. Daher könnte das schon der Grund sein, warum das so langsam ist. Ein LTO über LAN füttern zu wollen, halte ich für sehr optimistisch. Zudem wirst du es kaum schaffen per TAR einen konstanten Datenstrom an das Laufwerk zu liefern.

Wie schnell waren die 700 MB auf Band?

[arvidflow]

2minuten.
..du hast recht. diese erfahrung musste ich machen. bisher war mir das noch nicht so klar. wir haben uns nun entschieden debian anstelle des esx direkt auf die hardware zu installieren. und ohne nexenta auszukommen. die nfs freigeban kann ich ohne weiteres auch mit debian herstellen. außerdem sind dann die laufwerke und die platten nicht mehr virtualsiert. ichgehe davon aus, dass es die performance um einiges steigert. der server, auf dem das passieren wird war wohl auc nciht wirklich der geeignetste für diese virtualsisierung.

[bla!zilla]

Wow, knapp 6 MB/s bei einem Laufwerk, was auch 200 MB/ schafft und sich bei weniger als 20 MB/s sehr, sehr unwohl fühlt. Da solltest du dringend was machen, sonst ist das Ding in einem Jahr hinüber.