[5063] in linux-scsi channel archive
Re: Problem with Scsi Tapes
daemon@ATHENA.MIT.EDU (Kai M{kisara)
Sat Nov 7 04:02:08 1998
Date: Sat, 7 Nov 1998 10:58:10 +0200 (EET)
From: Kai M{kisara <makisara@metla.fi>
Reply-To: Kai.Makisara@metla.fi
To: brian@nycrc.net
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <19981107010332.61758@nycrc.net>
On Sat, 7 Nov 1998 brian@nycrc.net wrote:
...
> Anyway, I had such ease with my scsi tape and I remember reading
> in the st.c driver in the kernel source that the driver was generic
> and ANY scsi tape would work. So I bought a less expensive
Any well-behaving (according to the standard) scsi tape should work.
> HP Surestore T4i. This drive uses the Travan TR-4 4.0GB cartridges.
The HP Travan drives have not always been "well-behaving" ;-(
>
> Now I ran it with an adaptec 2940 using the Future domain chip and
> also with an NCR810. When I run tar -cvzf /dev/st0 / the tape
> churns away. However, sometimes the driver hickups and gives me
> errors. I believe they are "invalid sense of raw data" followed
> by some hex numbers. I assume it is having problems with the tape
If you enable verbose SCSI messages in kernel configuration, you get a
translation of the sense data. Otherwise you can look up the meaning of
the numbers from the standard (or ask someone to do it).
> format. Also sometimes when I run tar -tvzf /dev/st0 I get extra
> garbage at the EOT marker and gzip complains about it but says the
> uncompression was OK. I ran the other larger tape drive on the same
You can write and read only complete blocks with tapes. Tar writes
complete blocks but when you gzip this, the result probably is not an
integral number of blocks. The tape driver pads the last block with zeros
and when you read the data, you read also these additional zeros. This is
probably what gunzip complains about.
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
