some comments on PLDA tapes using Class 3

Bill Martin wrm at epcot.rose.hp.com
Tue Jul 9 11:28:20 PDT 1996


* From the SCSI Reflector, posted by:
* Bill Martin <wrm at epcot.rose.hp.com>
*
Doug:

I agree with your analysis that class 2 is not necessary.  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?

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  

> Date: Tue, 9 Jul 96 00:27:43 EDT
> From: "Doug Hagerman, 508-841-2145, Flames to NL:  09-Jul-1996 0025" <hagerman at starch.enet.dec.com>
> To: disk-attach-world at us4rmc.pko.dec.com, scsi_world at us4rmc.pko.dec.com,
>         fc-world at us4rmc.pko.dec.com
> Cc: dallas at wasted.enet.dec.com, monia at starch.enet.dec.com,
>         hagerman at starch.enet.dec.com
> Apparently-To: fibre-channel-ext at think.com, scsi at Symbios.COM,
>         disk_attach at dt.wdc.com
> Subject: some comments on PLDA tapes using Class 3
> Sender: owner-scsi at Symbios.COM
> Precedence: bulk
> 
> * From the SCSI Reflector, posted by:
> * "Doug Hagerman, 508-841-2145, Flames to NL:  09-Jul-1996 0025" <hagerman at starch.ENET.dec.com>
> *
> 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.
> 
> 
> Doug Hagerman
> Digital Equipment
> 




More information about the T10 mailing list