RE: iSCSI: Implicit Termination of Tasks

[Black_David@emc.com]

Mallikarjun,

> I disagree with your suggestion.
> 
> I believe that cases a, b and c (as written) are necessary and sufficient 
> cases for generating an internal CHECK CONDITION because
> our intent is to deliver on the promise of "ordering in the face of errors
> on one I_T nexus", *not* to gurantee the creation of cross-initiator ACA
> based on TST and QErr bit settings - simply because there are no iSCSI
> ordering guarantees involved across independent I_T nexuses.

While I understand the intent, the problem is that CHECK CONDITION is
a SCSI mechanism that SAM-2 now defines to have cross-I_T nexus
(cross-session) side effects in some cases - iSCSI cannot disregard
those side effects because they're inconvenient, and hence if CHECK
CONDITION is used with implicit task termination, it ought to be
used consistently.

> IOW, iSCSI spec today takes the position that the first three cases 
> are of potential interest to SCSI layer in view of iSCSI's ordering
> guarantee while the last case (d) is an iSCSI dynamic that has no
> bearing on the ordering guarantee.  I think that's a very reasonable
> position.

The problem with this is that CHECK CONDITION is of interest to the
SCSI layer by definition, and the potential cross-I_T nexus side
effects make case (d) relevant to SCSI in a way that it was not earlier.

I have a problem when the answer to:
	"When iSCSI loses or tears down connectivity, do implicitly
	terminated tasks generate CHECK CONDITION and its potential
	cross-I_T nexus side effects?"
is:
	"It depends on how the connection was torn down or lost."
because to my mind that's much worse than "yes" or "no".
While it may have no bearing on the ordering guarantee, the different
results for the TST=0 case will be a major surprise, especially if ACA
is in use.

FWIW, the cross-nexus side effects were added to SAM-2 in the relatively
recent past - as SAM-2 was when much of the work on iSCSI was done, the
current state of iSCSI would be fine as there would have been no way
to determine whether the internal CHECK CONDITION was generated in
case (d) once the I_T nexus (iSCSI session) vanished.  T10 decided
to change that situation, and we need to cope with this consequence.

> On a related separate topic, the current ASC/ASCQ value specification 
> for the implicit termination in the iSCSI spec is quite limiting as Eddy
> pointed out - I surprisingly overlooked the "array only" qualifier 
> when I originally
> suggested it.....  I suggest that we change it to the following - 
> 
> 00/06  DTLPWRSOMCAEBK  I/O PROCESS TERMINATED

I have a note in to Rob Elliott asking the scope of the current ASC/ASCQ
value can be expanded.  Let's make sure that it can't be before making
this sort of annoying minor change at this stage.

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
----------------------------------------------------