[5179] in linux-scsi channel archive
Scsi NS20 tape errors
daemon@ATHENA.MIT.EDU (Adrian Lawrence)
Thu Nov 19 09:37:28 1998
To: linux-scsi@vger.rutgers.edu
Date: Thu, 19 Nov 1998 00:27:09 +0000 (GMT)
From: Adrian Lawrence <adrian.lawrence@computing-services.oxford.ac.uk>
I have just acquired an Aiwa TD-20001 NS20 scsi tape drive, and although Tim
Jones has mentioned this model on the linux-tape mailing list, I suspect that
I am one of the few pioneers on Linux. Until this evening, it had been
performing magnificently, writing (and simultaneously verifying) compressed
data to tape at over 1.28 Mbytes/sec. I obtained that figure just from elapsed
time and the number of (compressed) blocks written to tape as reported by
mt tell.
But I have now had a failure, and am reporting it here both as a service to
the linux community, and in the hope that one of the scsi/tape experts can
throw some light on the nature of the problem. I do have some of the scsi
documents on line, but so far I have had no opportunity to find the relevant
parts.
I had successfully written 3 tar archives to one cartridge. I tried to
add another. I inserted the cartridge in the drive; used "mt retens"
and then "mt -f /dev/ntape fsf 3; mt -f /dev/ntape tell". It reported the
correct block number (2494423 as it happens, so the tape had 1.19 Gbyte in the
3 existing files).
I then attempted to add a further file using tar along the lines:
tar -c -p -V "blah" -f /dev/tape *
And I got an error message of something like IO error on /dev/st0. More to
the point, the kernel log included:-
kernel: st0: Error with sense data: Current error st09:00:
sense key Illegal Request
I do not recall exactly what I did after that, but retried, and used
mt to examine and reposition. There are several more syslog messages
such as:-
kernel: st0: Error with sense data: Current error st09:00: sense key
Illegal Request
st0: Error on write filemark.
kernel: st0: Error with sense data: Current error st09:00: sense key
Illegal Request
Later on,
kernel: Additional sense indicates Write append error
although I may have tried to write an explicit eof with mt in an attempt
to "block off" a section of tape, and then append a tar archive afterwards.
I was just experimenting at that point...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I then removed the offending cartridge, and inserted a fresh one. As I type,
the tar archive is being written to that new tape, and no errors thus far.
Thus it would seem to be a transient problem. But I now have a damaged
tape. Of course, it may just be a defective media (I hope some experts here
can tell me whether that is consistent with the error messages). The tape
was made by Imation which in my experience with other tape technologies is
a very reliable manufacturer. Or maybe some dirt on the head now cleared?
Thus far, I have not cleaned the heads. Amazingly, the "instructions" with the
manual make no mention of maintenance at all. I guess that an "NS dry cleaning
tape" is the right choice. Anyone know? But the drive has only run for maybe
3 hours total since new, so the heads should be clean. Unless the new tapes
have been shedding manufacturing debris... :-(
Is anyone in a position to comment on the failure mechanisms for NS20 tapes?
When I first looked into the NS technology, I seem to remember that there are
servo bursts at the begining and end of each track which are used to align
the heads. Presumably if these are damaged, there is not much hope of
recovering the tape. Or can an NS20 drive rewrite these? {Since I can
read the original tar archives, at least some of these bursts are intact?}
Since this message is already far too long, I will stop here with a quick
summary:
Kernel 2.0.36, mt-st-0.5b, Adaptec AIC7xxx driver version: 5.1.4/3.2.4
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: AIWA Model: TD-20001 Rev: 0159
Type: Sequential-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
Vendor: IBM Model: DDRS-34560W Rev: S97B
Type: Direct-Access ANSI SCSI revision: 02
Device using Narrow/Sync transfers at <---- tape drive
10.0 MByte/sec, offset 7
Device Negotiation Settings
Period Offset Bus Width
User 012 015 0
Goal 012 015 0
Current 025 007 0
Total transfers 61837 (3 read;61834 written)
blks(512) rd=6; blks(512) wr=3710040
Questions:
~~~~~~~~~~
1) This is a new drive. Is this any evidence for "bad scsi behaviour"?
2) Could there be a driver bug in 2.0.36 scsi handling? This is a single
P II system.
3) Any chance of recovering that tape?
... etc
Thanks for any help!
ael
--
Adrian Lawrence.
adrian.lawrence@oucs.ox.ac.uk. or adrian.lawrence@comlab.ox.ac.uk
MicroProcessor Unit | Computing Laboratory,
13, Banbury Road, | Wolfson Building,
Oxford. OX2 6NN. | Parks Road, Oxford.
UK. | OX1 3QD. UK.
Voice: (+44)-1865-273274, Fax: (+44)-1865-273275
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
