Linked commands comment, FCP-2

Bob Snively Bob.Snively at EBay.Sun.COM
Mon Mar 27 08:13:00 PST 2000

* From the T10 Reflector (t10 at, posted by:
* Bob Snively <Bob.Snively at EBay.Sun.COM>

Whil all that you say is correct, it is incomplete because it does not
consider the actual execution of a task as a current task.

I absolutely agree that when a command with the link bit on ends with
the appropriate Intermediate Status that a new command will be
presented to the device to continue the IO Process and the task.

However, to the best of my knowledge, and consistent with the search I
made, there is absolutely no rule that says that you cannot disconnect
after that command is transmitted.

There is absolutely no rule that requires an enabled command to be the
only enabled command.

There is absolutely no rule that requires an enabled task that has
links to retain the state of current task at the expense of other tasks
with the appropriate task attributes.

The result of that lack of rules is that tasks can be interleaved anywhere
during the execution of a task composed of linked commands, just like tasks
can be interleaved in the unlinked case.  The only guarantee you get out
of linking is that the commands within the link will be executed in
precise order.  No ordering with respect to other commands outside the
link can be expected.

The blind continuation of the linked task that you seem to expect is
required only if the linked commands have the head of queue or ordered
attribute, but is not required if the simple queue attribute is present.

As a side-effect of this, BUSY status can appear in a set of linked commands.
I would also expect that RESERVATION CONFLICT might appear.

I think that would justify my interpretation of the solution to comment 10.


>>In its comment number 10 (1.10 of T10/00-150r1.pdf), Crossroads spoke of
>>breaking links with busy.  This led to a lot of discussion and a requirement
>>that I verify some SAM-2 information.  My version 02 of the referenced
>>shows the results of my analysis of SAM-2, revision 13:
>>  10 (T): 4.2 Par 7
>> This paragraph does not appear to allow breaking linking by presentation 
>> of an error or busy status.
>>  Response:
>> The concern is accepted, although some work remains on the resolution.
>> At the meeting of March 6, 2000, the following partial resolutions were 
>> agreed upon:
>> The first two sentences of the offending paragraph will be corrected to 
>> include the possible case for breaking a command link.
>> There is an implication that linked commands are indivisible. After 
>> careful review of SAM-2, I find no evidence that linked commands must be 
>> executed without allowing other tasks to enter the enabled and current 
>> states.
>From SCSI-2:
>A link bit of one indicates that the initiator requests a continuation of the
>I/O process and that the target should enter
>the command phase upon successful completion of the current command.
>An I/O process may contain multiple commands linked together. Upon
>completing a
>linked command successfully,
>the target automatically proceeds to the next linked command for the I/O
>process. All commands in a series of linked
>commands are addressed to the same nexus and are part of a single I/O process.
>These state that the linked commands form a single task or single I/O process,
>and therefore should be indivisible.
>> There was some discussion about whether or not linked commands can be 
>> ended by a BUSY status. SAM-2 indicates that linking can be broken by 
>> BUSY status. 
>From a contrarian point of view, my comment was based on the words to that
>effect from SAM-2. However, from the above, I am strongly inclined to the
>of view that the target should never present Busy or Queue Full following an
>Intermediate, as the task is already underway, and won't be entered into the
>task set.
>> Wording from SAM-2, pdf page 68, concerning Intermediate Status will be 
>> incorporated as appropriate.
>>* For T10 Reflector information, send a message with
>>* 'info t10' (no quotes) in the message body to majordomo at

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list