RE: iSCSI: Implicit Termination of Tasks

[Eddy Quicksall <eddy_quicksall@ivivity.com>]

The way I figured it would work is that the UA would get set and would get
reported when the next command arrives.

Consider this:

connection 0 and 1 are all quite
connection 0 has a command x on the wire
connection 0 is lost
the UA is set
command y comes in connection 1
command y gets the UA or ACA Active

That way the upper layer at the initiator can figure out how to recover.

Is this not the idea?

Eddy

-----Original Message-----
From: dcuddihy@attotech.com [mailto:dcuddihy@attotech.com]
Sent: Thursday, January 09, 2003 3:05 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Implicit Termination of Tasks


David,

Regarding Autosense clearing the CA:

The problem that I have with this is that the CA should get cleared when
the
sense data is reported, not when the sense data is generated.  In this
case, the
autosense cannot be reported (the port is logged out), so the CA may not be
cleared.
It doesn't seem to me that generating a sense data response, even for an
interface
in which autosense is mandatory, implicitly clears a CA.

By the way, there was a question of Request Sense commands enqueued when a
termination
occurs .. my understanding is that the sense data need not be saved for a
subsequent
request sense command if it has been reported via autosense, so the request
sense
returns NO_SENSE.

Regarding FCP handling of port logout and ACA:

For us, ACA is a non-issue-- we don't support it, but it should be cleared
only for the
initiator which generated the log event.  (ACA support seems to be a point
of
contention among SCSI implementers... I know it's in all the specs, but I
have yet
to see it implemented.)

Rev 7A of FCP-2 has a nice chart of how task managment is affected via the
various log
events.  I'm not why it was removed in rev 8, but "FCP-2 Rev 7A (1/1/2001)"
Table 4
might help.

regards,

david




David J Cuddihy
Principal Engineer
ATTO Technology, Inc.
http://www.attotech.com/fcbridge.html
dcuddihy@attotech.com

----------------------------------------------------------------------------
---------------------


----------------------------------------------------------------------------
---------------------

David,

> Forgive me for being confused, but what is the reason for the Check
> Condition being issued?

Good question ...

> Say a target implements a blocking CA, (TST 0 Qerr 0) which would
disallow
> other initiator's tasks from running until the check condition could be
> reported, or another command from the CA'd initiator completes with good
> status.  An internal, non- reported check-condition would cause all other
> initiators' tasks to be blocked until  someone times out and issues a lun
> reset to the device, or a command from the first initiator completed (not
> likely, since that initiator logged out and all its tasks have been
> terminated ).    All this caused by bad behavior on behalf of one
> initiator.

That shouldn't happen.  iSCSI REQUIRES use of Autosense, which will
immediately clear the CA by generating a response to report the sense.
That response gets bit-bucketed as undeliverable for the implicit
termination scenarios in Section 6.5, but its generation clears
the CA.  Not the most obvious thing to do/explain, though ...

> Implicit termination is handled in FCP without the check condition being
> issued... all the tasks from the 'logged out' initiator are terminated,
> reservations cleared, etc.  and a UA is generated for that initiator.
> Every other initiator goes along with no problem, including those sharing
> the lun with the initiator who abruptly logged out.  Seems to work.

That looks like a cleaner way to accomplish this and avoids some of
the confusion over what ASC/ASCQ values to use.  Does FCP also avoid
ACA in this circumstance (assuming that NACA is set to use ACA), and
if so, can you suggest some specific text for iSCSI?

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------