some comments on PLDA tapes using Class 3
Charles Monia 237-6757
monia at AM.SHRMSG.SHR.mts.dec.com
Tue Jul 9 12:18:44 PDT 1996
* From the SCSI Reflector, posted by:
* Charles Monia 237-6757 <monia at AM.SHRMSG.SHR.mts.dec.com>
*
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.
Comments?
Charles
Bill Martin wrote:
>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
>>
>
********************************************************************
* Charles Monia Storage Architecture Group *
* Digital Equipment, Shrewsbury MA Internet: monia at shr.dec.com *
* Tel: (508) 841-6757 X400: c=US; a=MCI; o=Digital; ou=SHR *
* Fax: (508) 841-6100 *
********************************************************************
More information about the T10
mailing list