some comments on PLDA tapes using Class 3

Charles Monia 237-6757 monia at
Tue Jul 9 12:18:44 PDT 1996

* From the SCSI Reflector, posted by:
* Charles Monia 237-6757 <monia at>
Hi Bill:

Here's my .02

The assumption is that since magtapes have large read ahead/write behind
buffers they don't need to stream commands for performance hence they don't
need to support command queuing.  Since there's no command queuing, the initiator
can't issue the next command until status has been received for one
that's pending. Therefore, there's no need to worry about a break in the
command stream.

As I understand it, however, command queuing is now supported in some tape
drives, so I don't know if the above line of reasoning is still correct. 



Bill Martin wrote:

>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  
>> Date: Tue, 9 Jul 96 00:27:43 EDT
>> From: "Doug Hagerman, 508-841-2145, Flames to NL:  09-Jul-1996 0025"
<hagerman at>
>> To: disk-attach-world at, scsi_world at,
>>         fc-world at
>> Cc: dallas at, monia at,
>>         hagerman at
>> Apparently-To: fibre-channel-ext at, scsi at Symbios.COM,
>>         disk_attach at
>> 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>
>> *
>> 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
>> 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
>> drives!"--Ralph Weber.), and I encourage anyone who IS such an expert to
>> and comment on this subject.
>> I'm assuming that the "large buffer" model is in effect. (That is, every
>> drive guarantees to provide at least 1 MByte of input buffer space, or
>> alternatively, a mechanism is defined for negotiating the size of said
>> 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
>> is started. Also it's agreed that after an error is detected in a READ or
>> command, a READ POSITION command will be used to synchronize the drive's
>> 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
>> same READ POSITION command. This is acceptable because there is no media
>> movement associated with this command. This also applies to any other
>> that does not move the media. Hopefully all commands can be classified into
>> 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

* Charles Monia Storage Architecture Group                         *
* Digital Equipment, Shrewsbury MA   Internet: monia at   *
* Tel: (508) 841-6757    X400: c=US; a=MCI; o=Digital; ou=SHR      *
* Fax: (508) 841-6100                                              *

More information about the T10 mailing list