[2471] in linux-scsi channel archive
Re: SCSI Tape driver
daemon@ATHENA.MIT.EDU (Michael Weller)
Tue Sep 16 12:34:33 1997
Date: Tue, 16 Sep 1997 17:22:25 +0200 (MESZ)
From: Michael Weller <eowmob@exp-math.uni-essen.de>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Ricky Beam <root@defiant.interpath.net>,
Sameer Anja <sameer@securities.com>, linux-scsi@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.95.970916085947.1079A-100000@chaos.analogic.com>
[I rerouted this to linux-scsi where it IMHO belongs]
On Tue, 16 Sep 1997, Richard B. Johnson wrote:
> On Tue, 16 Sep 1997, Ricky Beam wrote:
>
> > Letting the chips fall where they may, I quote Sameer Anja:
> > >yes...I have seen a similar thing happening here too with my tape.
> > >-Sameer
> > ...
> > >On Mon, 15 Sep 1997, Richard B. Johnson wrote:
> > >> Date: Mon, 15 Sep 1997 10:33:34 -0400 (EDT)
> > >> From: Richard B. Johnson <root@chaos.analogic.com>
> > >> To: Linux kernel <linux-kernel@vger.rutgers.edu>
> > >> Subject: SCSI Tape driver
> > ...
> > >> Sep 15 10:10:32 chaos kernel: st0: Error with sense data:
> > >> Current error st09:00: sns = f0 3
> > >> Sep 15 10:10:32 chaos kernel: ASC=31 ASCQ= 0
> > >> Sep 15 10:10:32 chaos kernel: Raw sense data:
> > >> 0xf0 0x00 0x03 0x00 0x00 0x02 0xec 0x0a 0x00 0x00
> > >> 0x00 0x00 0x31 0x00 0x00 0x00
> >
> > Consulting the SCSI2 standard, the drive has signaled a medium error further
> > specifying that the medium format is corrupted:
[...]
> After this error, the tape user, i.e., tar, etc., has closed the fd. There
> isn't anybody accessing the tape anymore. Who would the "Unit attention"
> go to?
The st driver in the kernel.
> The tape gets changed. Open has still not got called because nobody
> is accessing the tape. Therefore nobody "knows" that the tape has been
> changed, even though the drive "remembers".
And it suffices that the drive "remembers".
> Several hours/days/months later, open is called by a new tape user.
> Is this user going to get errors reported during a previous tape
> session? Or is this user going to get a Unit attention "error" when,
> in fact, no error for a completely new session, with a completely new
> tape, has occurred.
Yes, this is how "Unit attention" works. Next time the device is accessed,
it returns a "Unit attention" condition. The st driver queries the
device's state, finds out the "Unit attention" was caused by a Media
change and clears it's state. This is how Media change detection works
under linux for removable SCSI-disks (MOs, say).
However, not all device generate "Unit attention" conditions properly.
Some devices can be configured to report "Unit attention" asynchronously.
Again, only some device support it, and I found that many SCSI cards don't
like it too, and I doubt that the linux SCSI adapter drivers will be
amused when a device contacts them about some asynchronous "Unit
attention" condition.
So, as far as the SCSI tapes support it (and I've no clue how many tapes
do), the simple (synchronous) "Unit attention" scheme is just THE
solution. However, problems remain with regards to st as a module
(will probably always assume an error free tape upon module load) and
powercycling/unplugging the tape (will not know the error was reset/tape
changed while device turned off) (however, the (read: some) device might
be able to signal UNIT ATTENTION always at power up).
So, in an ideal world it works. In real life I see still some problems
with this. Actually, st already rewinds the tape when it thinks it is in
an 'unsafe, unpositioned' state (like after being reinserted). I'd say it
should reset all internal errors when it does that, similarly after each
rewind/retension it should reset the state. Maybe always when it reaches
BOT. (but probably rewind/retension is the only way to do it when in such
an error condition.). Vice versa, when a tape device which is considered
broken is (re)opened, it should be rewound first.
I'm wondering though, if this is a real good thing to do. In case the tape
signalled an error, wouldn't you want to be able to backspace a bit and
reread the erroneous data. I'm not familiar with the current driver, but
does it check the kind of error and remember only things which cannot
be retried? This would result in not remembering the error condition but
just retrying each time the device is accessed (even without a reopen),
which I consider to be the right thing in case of media errors for tapes.
> I think that a tape can only be "changed", while a fd is open. Whatever
> happens when the tape-drive is not in-use, i.e., physically changing the
> media, etc., should (logically) be ignored. In other words, a new open
> should do whatever is neccessary to remove all previous history of the
> drive's use.
UGH! NO! You must be able to position your tape using mt and/or using
several backup commands (say: tar) on the non rewinding tape device
(except of the last command issued). All this will result in several
open/close transitions. You may not like it and I see you have a point,
but under Unix tapes are just not mounted (and locked) during their usage
period as filesystems are. So you must keep the position of the
tape and settings like blocksize, media format, compression state.
I can only imagine a reset of the drivers state (except media format,
compression state) whenever the tape is rewound explicitly (maybe, but
only maybe, when implicitly, that is backspacing bit by bit until the
beginning is reached).
Michael.
(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@spi.power.uni-essen.de instead.)
