Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h09Iv4I03491
	for ips-outgoing; Thu, 9 Jan 2003 13:57:04 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.corp.emc.com (mxic1.isus.emc.com [168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h09Iv1W03485
	for <ips@ece.cmu.edu>; Thu, 9 Jan 2003 13:57:02 -0500 (EST)
Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <ZF4D34Y2>; Thu, 9 Jan 2003 13:56:30 -0500
Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C720@corpmx14.us.dg.com>
From: Black_David@emc.com
To: dcuddihy@attotech.com, ips@ece.cmu.edu
Subject: RE: iSCSI: Implicit Termination of Tasks
Date: Thu, 9 Jan 2003 13:56:07 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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
----------------------------------------------------
