Re comments from Bill Martin
Doug Hagerman, 508-841-2145, Flames to NL: 09-Jul-1996 1501
hagerman at starch.enet.dec.com
Tue Jul 9 12:14:11 PDT 1996
* From the SCSI Reflector, posted by:
* "Doug Hagerman, 508-841-2145, Flames to NL: 09-Jul-1996 1501" <hagerman at starch.ENET.dec.com>
*
Hi Bill.
>I agree with your analysis that class 2 is not necessary.
Good; that makes at least two of us. :*)
>The issues are
>when you have a stream of commands that execute before you do the read
>position. If a command is lost and another command is issued that assumes
>the previous command completed successfully. In this case you do not get
>the old value or the expected new value. This is the situation where the
>first command is a reposition command to the drive, and the second command
>is a write command to the drive. You must wait for an acknowledge of the
>first command before the second command may be issued. These commands may
>not be streamed. Does this mean that you may never stream commands to a
>tape drive. If so, what is the performance impact, if any?
I think I need to capture in writing something that was mentioned at one
point in some meeting or another. The READ POSITION reports the position
as it "will be" after the previous commands complete. So if an initiator has
a list of WRITE commands to send, it sends each one and waits for the status
back from each. However, the drive may decide to wait until two or three
commands (and data) have been completely received, and their status returned,
before beginning to move the media.
If at some point a command is lost, the initiator sends
a READ POSITION and the target returns what the position will be after
the most recently issued previous command completes. Thus you can do
a REPOSITION command, which falls into the "causes media movement" class,
then after the status is successfully returned you can immediately issue
the next WRITE command, even if the tape hasn't started to move yet.
The current proposal is a two step process: 1.) get the data to the
drive successfully, 2.) write the data to the media.
If a media access failure occurs that can't be recovered by the drive,
the drive issues a deferred error. This, of course, screws up everything.
However, my understanding is that if this happens then the cartridge is
probably unusable anyway, and so everything needs to be restarted at a much
higher level than this.
The discussion of deferred errors hasn't been held yet, although perhaps
we're getting close to it...
Doug Hagerman
Digital Equipment
>Bill Martin
>
> Hewlett-Packard, Networked Computing Div Ph: 916-785-4517
> 8000 Foothills Blvd, MS 5601 Fax: 916-785-2875
> Roseville, CA 95747-5601 email: wrm at core.rose.hp.com
>
More information about the T10
mailing list