TASK SET FULL Definition(s) in FC-TAPE and SAM-2

gop at us.ibm.com gop at us.ibm.com
Wed Mar 17 06:05:12 PST 1999

* From the T10 Reflector (t10 at symbios.com), posted by:
* gop at us.ibm.com
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

I agree with Gerry's comments except for the last one on how a target
should respond to an initiator that has no outstanding commands and for
some reason also has no resources to accept the command. In that case the
target should return BUSY not TASK SET FULL. The reason is because of how
the initiators respond to those different statuses In the case of receiving
a TASK SET FULL status the initiator should not try to resend the command
until it receives a status from an outstanding  command. So if the
initiator receives a TASK SET FULL when it has no outstanding commands it
may become confused and disorientated. And when that happens most
initiators will do nasty things like reset the bus. On the other hand a
BUSY just tells the initiator to try again later.

That is why any target that goes into a multi-initiator environment should
be designed to handle at least one command from every initiator it knows

Bye for now,
George Penokie

Dept PPV  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880

(1) Regarding your suggestion for supporting TASK SET FULL:

SCSI targets usually have enough resources to accept one untagged command
|from each initiator. The wording you quote was intended to allow an
implementation where such a target wouldn't accept tagged commands at all.
Since a second untagged command from any initiator is an overlapped command
(with its own handling rules), there is no need for such a target to ever
respond with TASK SET FULL. Any target that accepted tagged commands is
likely to run out of queuing resources at some point, so it is required to
support TASK SET FULL.

The SAM wording also may not reflect usage of "immediate" commands, where
apparently no more than one command is outstanding but in reality a large
number of "deferred execution" commands are queued in the target. This type
of target should implement TASK SET FULL status even though SAM wording
doesn't require it.

(2) Regarding situation (a) from your message:

I would expect the target to accept the 2nd initiator's command, disconnect
|from the bus, and queue the command until execution of the first
initiator's command was complete; then execute the 2nd command. One
untagged command can be queued for each initiator, so it should be queued
in this case because resources are available. If the first initiator
doesn't want commands from another initiator to get queued in the middle of
its command stream, it had better RESERVE the target first!!

(3) Regarding your situation (b) from your message:

This seems to describe a target that only supports execution of one command
at a time, or a target that has queued a number of commands for an
initiator where all of the commands are using "immediate" mode. For the
first case (a target that only accepts one command at a time is probably
more than 10 years old) the target would probably respond with BUSY status.
For the second case, TASK SET FULL would be appropriate.

Dave Peterson <dap at nsg0.network.com> on 03/16/99 02:35:37 PM

To:   t10 at Symbios.COM, fc at nsg0.network.com
cc:    (bcc: Gerry Houlder)
Subject:  TASK SET FULL Definition(s) in FC-TAPE and SAM-2

Howdy All,

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.

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.


Dave Peterson                     phone : 612-391-1008
Principal Engineer
StorageTek Network Business Group email: dap at network.com

Content-type: text/html; 
Content-Disposition: attachment; filename="att-1.htm"
Content-transfer-encoding: base64
Content-Description: Internet HTML



* 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 mailing list