Subject: [Ips] Sequencing of UA and I/O from aborted tasks in Clear Task Set, an d LUN Reset

From: "Spry, Andy" <[email-masked]>
Date: Mon, 9 Feb 2004 09:31:11 -0600

All,

The recent discussion on which tasks are affected by a clear task set was
informative but did not address this issue.  

I need some clarification on the ordering of responses or unit attention for
tasks on sessions other than the session issuing a Clear Task Set or LUN
Reset TMF.  

When TST is 000b, the task set for a LUN includes tasks from all initiators.
When a Clear Task Set (or LUN Reset) is received the set of tasks already
present in the SCSI layer for the LUN must be aborted.  

The behavior for the initiator that issued the TMF is clearly defined.  All
I/O sequences in progress are completed or terminated before the TMF
response is returned to the initiator.  

However, the timing of notification to other initiators is not as clear.
According to SAM-2 and SAM-3 (5.7.3) the method of notification depends on
the setting of the TAS bit in the Control mode page.  
 
    When TAS is 0, the method of notification is a Unit Attention condition.

        The additional sense code dependent on the action that caused the
task(s) to be aborted.  

    When TAS is 1, each task is aborted with a TASK ABORTED status.  
        A unit attention with the sense code "COMMAND CLEARED BY ANOTHER
INITIATOR" is NOT sent to the initiator.  

The section further states that:  

   "When a logical unit is aborting one or more tasks from a SCSI initiator
port with
    the TASK ABORTED status it should complete all those tasks before
entering additional
    tasks from that SCSI initiator port into the task set"  

Assuming the "point in time" method is used to define the tasks sets for
initiators, how can a race condition between the Unit Attention and the
completion of I/O for tasks being aborted be avoided when the TAS bit is set
to 0?    

Any commands being aborted that are in an I/O phase must be terminated
gracefully if possible.  However, the Unit Attention occurs immediately for
the next command arriving from the initiator.  The Unit Attention response
can be sent back to the initiator while there is still I/O being completed
on the commands being aborted.  

Even if the arrival of the next command which would return the Unit
Attention condition is delayed (as done for the case when TAS is set to 1),
the response and final I/O operations for the last command being aborted may
be traveling on different connections in a session.  In the pathological
case, the unit attention can arrive at the initiator before the final I/O
phase has completed.  

In both these cases, the initiator may free all resources used for I/O
operations that are still not completed by the target.  

When TAS is 1, these issues are resolved because each individual I/O is
explicitly terminated with a TASK ABORTED status.  

Should the iSCSI specification include a clause that encourages or mandates
the use of the TAS=1 setting to resolve this potential race condition
between Unit Attention and the I/O cleanup during task abort?

Does anyone see some error in my reasoning or a different way of resolving
this issue.  

Thanks,
Dr. Andrew J. Spry
LSI Logic Storage Systems, INC

---

From: [email-masked]
Date: Mon, 9 Feb 2004 10:28:40 -0800 (PST)

> completion of I/O for tasks being aborted be avoided when the TAS bit is set

Note: "before entering additional tasks ... into the task set" does not
mean before sending back the UA, it means that no tasks shall enter the
"enabled" state in that time. In SAM-3 this is covered in section 8.4, and
my recolection is it was covered the same in SAM-2.

So you can (and probalby should) have tasks piling up in the "dormant"
state while the abort is happening. And as a task can't return status
until it has entered the "enabled" state (AFAICT), you won't get a
command-related UA until after the aborting has ended.

> on the commands being aborted.

As above, I think that's where you're wrong. The UA does NOT occur
immediately for the next command, as status is returned when the task
ends, which is after the task starts (is "enabled"), which is after the
aborting/clearing happens.

> case, the unit attention can arrive at the initiator before the final I/O

I thought that tasks were allegiant to a connection, and thus the status
travels on the same connection as the I/O ops for a command. If that were
not the case, we'd have this problem for ALL commands, not just aborted
ones. :-)

> Does anyone see some error in my reasoning or a different way of resolving

See above. I think exact task semantics enter in and resolve your concern.

Take care,

Bill

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Julian Satran <[email-masked]>
Date: Tue, 10 Feb 2004 09:18:23 -0800

If the race is to be avoided FCP is in a similar position with iSCSI and 
so is any other networked transport. (connections to different initiators 
follow different paths)
I do not see why iSCSI should say something special when the problem is 
the same for all transports.

Julo

"Spry, Andy" <[email-masked]> 
Sent by: [email-masked]
09/02/2004 07:31

To
[email-masked]
cc

Subject
[Ips] Sequencing of UA and I/O from aborted tasks in Clear Task Set, an d 
LUN Reset

All, 
The recent discussion on which tasks are affected by a clear task set was 
informative but did not address this issue. 
I need some clarification on the ordering of responses or unit attention 
for tasks on sessions other than the session issuing a Clear Task Set or 
LUN Reset TMF. 
When TST is 000b, the task set for a LUN includes tasks from all 
initiators.  When a Clear Task Set (or LUN Reset) is received the set of 
tasks already present in the SCSI layer for the LUN must be aborted. 
The behavior for the initiator that issued the TMF is clearly defined. All 
I/O sequences in progress are completed or terminated before the TMF 
response is returned to the initiator. 
However, the timing of notification to other initiators is not as clear. 
According to SAM-2 and SAM-3 (5.7.3) the method of notification depends on 
the setting of the TAS bit in the Control mode page. 
  
    When TAS is 0, the method of notification is a Unit Attention 
condition. 
        The additional sense code dependent on the action that caused the 
task(s) to be aborted. 
    When TAS is 1, each task is aborted with a TASK ABORTED status. 
        A unit attention with the sense code "COMMAND CLEARED BY ANOTHER 
INITIATOR" is NOT sent to the initiator. 
The section further states that: 
   "When a logical unit is aborting one or more tasks from a SCSI 
initiator port with 
    the TASK ABORTED status it should complete all those tasks before 
entering additional 
    tasks from that SCSI initiator port into the task set" 
Assuming the "point in time" method is used to define the tasks sets for 
initiators, how can a race condition between the Unit Attention and the 
completion of I/O for tasks being aborted be avoided when the TAS bit is 
set to 0? 
Any commands being aborted that are in an I/O phase must be terminated 
gracefully if possible.  However, the Unit Attention occurs immediately 
for the next command arriving from the initiator.  The Unit Attention 
response can be sent back to the initiator while there is still I/O being 
completed on the commands being aborted. 
Even if the arrival of the next command which would return the Unit 
Attention condition is delayed (as done for the case when TAS is set to 
1), the response and final I/O operations for the last command being 
aborted may be traveling on different connections in a session.  In the 
pathological case, the unit attention can arrive at the initiator before 
the final I/O phase has completed. 
In both these cases, the initiator may free all resources used for I/O 
operations that are still not completed by the target. 
When TAS is 1, these issues are resolved because each individual I/O is 
explicitly terminated with a TASK ABORTED status. 
Should the iSCSI specification include a clause that encourages or 
mandates the use of the TAS=1 setting to resolve this potential race 
condition between Unit Attention and the I/O cleanup during task abort?
Does anyone see some error in my reasoning or a different way of resolving 
this issue. 
Thanks, 
Dr. Andrew J. Spry 
LSI Logic Storage Systems, INC