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

From: "Spry, Andy" <[email-masked]>
Date: Mon, 9 Feb 2004 13:00:51 -0600

Bill,

Thanks for your reply.  I added a couple of clarification points below.

Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, February 09, 2004 12:29 PM
> To: Spry, Andy
> Cc: [email-masked]
> Subject: Re: [Ips] Sequencing of UA and I/O from aborted 
> tasks in Clear
> Task Set, an d LUN Reset
> 
> 
> On Mon, 9 Feb 2004, Spry, Andy wrote:
> 
> > 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?
> 
> 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.
> 

This is what we were considering to help with the sequence issue.  I'll
check the referenced section for relavence.  However, doesn't this only
apply to the case where TAS=1?  The wording in section 5.7.3 would seem to
indicate that holding the commands in abayance as "dormant" only applies to
that option.  

> > 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.
> 
> 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.
> 
> > 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.
> 
> 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. :-)
> 

I think that there could still be an issue.  Yes the last I/O on the task
being aborted is allegiant to the connection on which that task arrived.
However, the unit attention is being returned as a response to the first
command arriving after all commands in the task set have been cleaned up.
This task does not need to arrive on the same connection as the last task
being aborted from that initiator.  If the aborted task arrived on a slow
connection but the subsequent task which receives the UA arrives on a faster
connection, there is not guarentee that the UA response won't get back to
the initiator first.  

For normal I/O this would not be a problem.  But for a UA indicating that
the target has cleared a task set or performed a LUN reset, all resources
for that command and its preceeding commands can be released.  If the last
I/O is still completing on the slower connection, does the initaitor pull
the resources before the I/O had completed. 

Or is this race condition aleviated by the fact that the I/O phase is
completed by agreement between the iniator and target  before the command is
enabled on the target?

> > 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.
> 
> See above. I think exact task semantics enter in and resolve 
> your concern.
> 
> Take care,
> 
> Bill
>

---

From: [email-masked]
Date: Mon, 9 Feb 2004 13:16:54 -0800 (PST)

> indicate that holding the commands in abayance as "dormant" only applies to

I think you can always hold tasks in "dormant" state if it helps you
perform a CLEAR TASK SET.

More importantly, I think with TST=0, when you clear the task set, the
other tasks are GONE. No orderly command shutdown, no status reporting.

I think that because if a task is aborted and status is returned,
regardless of TST's value, I'd expect to get a task aborted status. We
should never permit the case of non-abort status if the task was aborted,
no?

Does the list agree with the above? Or in the TST=0 case, should a command
be completed with GOOD status and just report an underrun?

> connection, there is not guarentee that the UA response won't get back to

I think something Julian stated comes into play here. Not only does the
target have to await sending status, but it has to await receiving status
comfirmation.

Thus the abort won't be over until the commands are done.

Take care,

Bill

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