TASK SET FULL Definition(s) in FC-TAPE and SAM-2
Joseph C. Nemeth
jnemeth at concentric.net
Wed Mar 17 11:22:08 PST 1999
* From the T10 Reflector (t10 at symbios.com), posted by:
* "Joseph C. Nemeth" <jnemeth at concentric.net>
A couple of comments/questions.
First, I've been looking around trying to find the FC-TAPE draft
specification, and I can't find it. Where did this end up?
Second, there's something I don't understand about the QUEUE FULL handling,
and command retries in general. With parallel SCSI, the initiator and
target are locked into a rigid phase sequence handshake, such that the
initiator is guaranteed to receive the QUEUE FULL status before it is free
to issue the next command. Therefore, on receiving QUEUE FULL status, the
initiator can simply hold up its own queue, and retry the command when it
receives status from some previously queued command.
Unless something has changed, FC Class 3 has no reliable handshake
mechanism for informing the initiator that the command has been received,
so "queuing commands" on the part of the initiator consists of simply
spewing out command IUs. An initiator that is issuing queued command IUs
may not receive QUEUE FULL status from the target until after it has
already issued subsequent command IUs, *some of which may be accepted by
the target* as the target's queues clear. Therefore, retrying the command
that received QUEUE FULL status results in out-of-order delivery of
commands to the target. Note that out-of-order delivery will occur even if
all of the commands are sent with the Ordered Queue flag. Therefore, the
proper recovery mechanism for a Class 3 initiator is to not only queue up
the affected command for retry, but also all subsequent commands that it
has already issued (whether accepted by the target or not), AND to issue an
ABORT to the target for all the commands that were sent after the command
that resulted in the QUEUE FULL status, hoping that the target hasn't
already started altering the state of the media in response to those
accepted-out-of-order requests. For rewritable disk devices, whether the
media is altered is perhaps irrelevant. For sequential or non-rewritable
devices, the media has probably just been ruined.
So is this discussion of QUEUE FULL/BUSY/retry taking place in the context
of FC Class 2 and/or command acknowledgement ONLY?
At 09:40 AM 3/17/99 , Bob Snively wrote:
>Realistically, after placing my answers in the section below, I believe
>that tagged queueing must be supported by FC-TAPE compliant initiators,
>since only such initiators will do anything intelligent with
>QUEUE FULL (TASK SET FULL). Typically, their action is to retry
>infrequently and in addition to retry whenever a task is completed from
>that logical unit.
>Then the "cleaner" TASK SET FULL behavior can replace the present
>proper SCSI behavior of "vendor specific" or "OVERLAPPED COMMANDS ATTEMPTED."
>See my notes below.
>> FC-TAPE currently states in clause 9.2 for TASK SET FULL:
>> - TASK SET FULL (if Tagged Queuing is used or ULP resources are
>> SAM-2r10 states in clause 5.2:
>> TASK SET FULL. This status shall be implemented if the logical unit
>> supports the creation
>> of tagged tasks (see 4.9). This status shall be returned when the
>> logical unit receives a
>> command and does not have enough resources to enter the associated task
>> in the task set.
>> SAM-2r10 states in clause 4.8:
>> A Task Set is composed of zero or more Untagged Tasks or a combination
>> of zero or more
>> Tagged Tasks and zero or more Untagged Tasks.
>> So it seems to me TASK SET FULL should be implemented regardless.
>> Another issue: what is the proper SCSI Status to return if:
>> a) the lun does not support tagged tasks, is processing a command
>> received from one Initiator (has no reservation active), has enough
>> resources to receive another command and enter it into the Task Set,
>> and receives another command from a different Initiator.
>> My preference would be a BUSY.
>The answer here is VENDOR SPECIFIC. BUSY is correct if there are no
>resources and the device does not know how to juggle two tasks. In
>an FC-AL device, this will be very unlikely, since juggling two or more
>exchanges is normal. As a result, the proper behavior is probably
>to accept and execute the new command in its turn. That is very
>bad behavior by a tape applications, which is why we have made
>reservations a requirement in tape drives.
>> b) the lun does not support tagged tasks, is processing a command
>> received from one Initiator (has no reservation active), does not have
>> enough resources to receive another command and enter it into the
>> Task Set, and receives another command from a different Initiator.
>> I would expect a TASK SET FULL.
>There is a CHECK CONDITION ASC/ASCQ assigned for this behavior:
> ASC/ASCQ 48/00 OVERLAPPED COMMANDS ATTEMPTED
>The check condition is provided by either command and the other is
Joseph C. Nemeth Precision Algorithms (970) 226-5427
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com
More information about the T10