Cleared Cmd Notification

Mark_Heath at notes.seagate.com Mark_Heath at notes.seagate.com
Thu Dec 9 12:10:17 PST 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* Mark_Heath at notes.seagate.com
*

> Seems it would be cleaner if the rule was a target should return all I/Os
> with the new status before giving Task Mgmt Response.  This gives the host a
> clean spot to know when to cleanup (via ABTS) any straggler I/Os).  However,
> this doesn't apply to parallel SCSI because there the "Task Mgmt Response"
> is going bus free, so by definition you have I/Os coming back with 'Command
> Cleared' status AFTER the "Task Mgmt Response".  To make the SCSI model
> consistent it seems one should not have an additional rule for FCP.

The target can't release the Task Identifier associated with a task until all
services related to that task have completed.  Therefore, the Task Identifier
can't be released until Command Cleared notification is sent.  In parallel SCSI,
this may create some confusion due to the fact that the Task Mgmt Response must
come before the Command Cleared notification.  For example, consider the
following example:

   1.  An initiator creates a task with tag 33.
   2.  The initiator then sends an Abort Task message for tag 33.
   3.  The target returns the Task Mgmt Response by going bus free.
   4.  The initiator tries to send a new task with tag 33.  This creates
       an overlapped command conditon because the "old" task 33 still exists,
       and will continue to exist until the target gets around to sending
       the Command Cleared notification.

The initiator could avoid this specific problem (i.e. the overlapped commands
problem) if it were smart enough to wait for the Command Cleared notification
|from all of its commands that are getting aborted.  However, the initiator has
no way of knowing when the target has completed the abort of tasks created by
*other* initiators when sending a Clear Task Set, Logical Unit Reset, or Target
Reset task management function.  More generally, the initiator has no way of
knowing when a task management function is *really* complete.  This seems
particularly nasty for Logical Unit Reset and Target Reset.  (The initiator will
probably want to know when the reset is complete!)

Does this bother any of the initiator implementors out there?


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




More information about the T10 mailing list