some comments on PLDA tapes using Class 3

Charles Monia 237-6757 monia at AM.SHRMSG.SHR.mts.dec.com
Tue Jul 9 08:12:04 PDT 1996


* From the SCSI Reflector, posted by:
* Charles Monia 237-6757 <monia at AM.SHRMSG.SHR.mts.dec.com>
*
Hi Doug:

Your proposal assumes that tape position is a reliable indicator of whether or
not the timeout was caused by a transport error. Is that generally the case?

In any event, it's probably a good idea for the initiator to issue a REQUEST
SENSE before doing anything else.

Comments?

Charles


>960708
>tape-comments.doc
>
>Here are some additional comments on the tape model as it has been discussed
>recently.
>
>Obviously there is a bit of an argument as to whether error recovery should be
>done at the command level or at the interconnect transport level, but here I
>assume that we're still trying to use SCSI command level recovery. Also note
>that I'm not a tape expert ("Doug, you obviously don't know anything about tape
>drives!"--Ralph Weber.), and I encourage anyone who IS such an expert to review
>and comment on this subject.
>
>I'm assuming that the "large buffer" model is in effect. (That is, every tape
>drive guarantees to provide at least 1 MByte of input buffer space, or
>alternatively, a mechanism is defined for negotiating the size of said buffer.
>Also, every SCSI READ or WRITE command is guaranteed to specify less than 1
>MByte (or the negotiated amount) of data.) Using these rules, all the
>interconnect-related activity can be completed before any tape media activity
>is started. Also it's agreed that after an error is detected in a READ or WRITE
>command, a READ POSITION command will be used to synchronize the drive's idea
>of the media position with the driver's idea of the media position.
>
>Here are some cases that can occur:
>
>case                    what the          result of         next
>                        initiator         READ POSITION     initiator
>                        sees              command           action
>=====================================================================
>
>1. Command and data     success status    NA                send
>get to target, and status                                   next
>is returned successfully                                    command
>
>2. Failure in command   failure status    result is OLD     re-send
>or data, and status                       value of          command
>is returned successfully                  position
>
>3. Command gets lost    command           result is OLD     re-send
>on the way to target    times out         value of          command
>                                          position
>
>4. Command and data     command           result is NEW     send next
>succeed, but status     times out         (i.e. expected)   command
>gets lost on the way                      value of
>back to initiator                         position
>
>5. Failure in command   command           result is OLD     re-send
>or data, and status     times out         value of          command
>gets lost on the way                      position
>back to initiator
>
>Since the same action is taken by the initiator in every case where the OLD
>value of the media position is returned from the READ POSITION command, the
>decision process used by the initiator is simple.
>
>It is possible that the READ POSITION command may fail. In this case the
>initiator waits until the READ POSITION command times out, then re-issues the
>same READ POSITION command. This is acceptable because there is no media
>movement associated with this command. This also applies to any other command
>that does not move the media. Hopefully all commands can be classified into two
>cases. First are those that do not move the media, and it is assumed that all
>of these may also be re-issued in case of failure (i.e. there is no harm in
>issuing the same command multiple times). Second are those that do move the
>media, and they will all be handled using the rules discussed for the READ and
>WRITE commands. A list of these two types of commands should be added to the
>tape section of PLDA.
>
>Up to this point I do not see a need for Class 2 for tapes using PLDA.
>
>





More information about the T10 mailing list