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
*
--0__=Mt9MIHIfAb3INDsg3gPPppBdTMLsYloBox24SHmiNndjVBeCjlb6aMY6
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
about.

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
unavailable)

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.

Comments?

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





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

PEhUTUw+DQpIb3dkeSBBbGwsDQoNCjxQPkZDLVRBUEUmbmJzcDtjdXJyZW50bHkgc3RhdGVzIGlu
IGNsYXVzZSA5LjIgZm9yIFRBU0sgU0VUJm5ic3A7RlVMTDoNCg0KPFA+LSBUQVNLIFNFVCZuYnNw
O0ZVTEwgKGlmIFRhZ2dlZCBRdWV1aW5nIGlzIHVzZWQgb3IgVUxQIHJlc291cmNlcyBhcmUNCnVu
YXZhaWxhYmxlKQ0KDQo8UD5TQU0tMnIxMCBzdGF0ZXMgaW4gY2xhdXNlIDUuMjoNCg0KPFA+VEFT
SyZuYnNwO1NFVCZuYnNwO0ZVTEwuIFRoaXMgc3RhdHVzIHNoYWxsIGJlIGltcGxlbWVudGVkIGlm
IHRoZSBsb2dpY2FsDQp1bml0IHN1cHBvcnRzIHRoZSBjcmVhdGlvbg0KPEJSPm9mIHRhZ2dlZCB0
YXNrcyAoc2VlIDQuOSkuIFRoaXMgc3RhdHVzIHNoYWxsIGJlIHJldHVybmVkIHdoZW4gdGhlIGxv
Z2ljYWwNCnVuaXQgcmVjZWl2ZXMgYQ0KPEJSPmNvbW1hbmQgYW5kIGRvZXMgbm90IGhhdmUgZW5v
dWdoIHJlc291cmNlcyB0byBlbnRlciB0aGUgYXNzb2NpYXRlZA0KdGFzayBpbiB0aGUgdGFzayBz
ZXQuDQoNCjxQPlNBTS0ycjEwIHN0YXRlcyBpbiBjbGF1c2UgNC44Og0KDQo8UD5BIFRhc2sgU2V0
IGlzIGNvbXBvc2VkIG9mIHplcm8gb3IgbW9yZSBVbnRhZ2dlZCBUYXNrcyBvciBhIGNvbWJpbmF0
aW9uDQpvZiB6ZXJvIG9yIG1vcmUNCjxCUj5UYWdnZWQgVGFza3MgYW5kIHplcm8gb3IgbW9yZSBV
bnRhZ2dlZCBUYXNrcy4NCg0KPFA+U28gaXQgc2VlbXMgdG8gbWUgVEFTSyZuYnNwO1NFVCZuYnNw
O0ZVTEwgc2hvdWxkIGJlIGltcGxlbWVudGVkIHJlZ2FyZGxlc3MuDQoNCjxQPkFub3RoZXIgaXNz
dWU6IHdoYXQgaXMgdGhlIHByb3BlciBTQ1NJIFN0YXR1cyB0byByZXR1cm4gaWY6DQoNCjxQPmEp
IHRoZSBsdW4gZG9lcyBub3Qgc3VwcG9ydCB0YWdnZWQgdGFza3MsIGlzIHByb2Nlc3NpbmcgYSBj
b21tYW5kIHJlY2VpdmVkDQpmcm9tIG9uZSBJbml0aWF0b3IgKGhhcyBubyByZXNlcnZhdGlvbiBh
Y3RpdmUpLCBoYXMgZW5vdWdoIHJlc291cmNlcyB0bw0KcmVjZWl2ZSBhbm90aGVyIGNvbW1hbmQg
YW5kIGVudGVyIGl0IGludG8gdGhlIFRhc2sgU2V0LA0KPEJSPmFuZCByZWNlaXZlcyBhbm90aGVy
IGNvbW1hbmQgZnJvbSBhIGRpZmZlcmVudCBJbml0aWF0b3IuDQoNCjxQPk15IHByZWZlcmVuY2Ug
d291bGQgYmUgYSBCVVNZLg0KDQo8UD5iKSB0aGUgbHVuIGRvZXMgbm90IHN1cHBvcnQgdGFnZ2Vk
IHRhc2tzLCBpcyBwcm9jZXNzaW5nIGEgY29tbWFuZCByZWNlaXZlZA0KZnJvbSBvbmUgSW5pdGlh
dG9yIChoYXMgbm8gcmVzZXJ2YXRpb24gYWN0aXZlKSwgZG9lcyBub3QgaGF2ZSBlbm91Z2ggcmVz
b3VyY2VzDQp0byByZWNlaXZlIGFub3RoZXIgY29tbWFuZCBhbmQgZW50ZXIgaXQgaW50byB0aGUN
CjxCUj5UYXNrIFNldCwmbmJzcDsgYW5kIHJlY2VpdmVzIGFub3RoZXIgY29tbWFuZCBmcm9tIGEg
ZGlmZmVyZW50IEluaXRpYXRvci4NCg0KPFA+SSB3b3VsZCBleHBlY3QgYSBUQVNLIFNFVCZuYnNw
O0ZVTEwuDQoNCjxQPkNvbW1lbnRzPw0KPFBSRT4tLSZuYnNwOw0KPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KRGF2ZSBQ
ZXRlcnNvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBwaG9uZSA6IDYxMi0zOTEtMTAwOA0KUHJpbmNpcGFsIEVuZ2luZWVyJm5i
c3A7DQpTdG9yYWdlVGVrIE5ldHdvcmsgQnVzaW5lc3MgR3JvdXAgZW1haWw6IGRhcEBuZXR3b3Jr
LmNvbTwvUFJFPg0KJm5ic3A7PC9IVE1MPg0KDQo=

--0__=Mt9MIHIfAb3INDsg3gPPppBdTMLsYloBox24SHmiNndjVBeCjlb6aMY6--

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