RE: iSCSI: Implicit Termination of Tasks

["David J. Brown" <david.brown@trebia.com>]

I don't understand why the generation of CHECK CONDITIONs is immaterial when
a session is closed.  When a check condition generates a CA or ACA, it can
affect tasks from other initiators, too.  Look at the TST and QErr bits in
the Control mode page.

If the TST bit, in the Control mode page, is zero and the QErr data field,
in the same mode page, contains 01b, then a check condition causes all tasks
from all initiators to be aborted.

If TST is zero and QErr is not 01b, then all tasks from other initiators are
temporarily blocked by a CA or ACA.  The situation in which an ACA was
generated and the session was closed is particularly problematic, because
the initiator that caused the ACA is gone.  One of the other initiators
would need to reset the unit, or send a PERSISTENT RESERVE OUT, to clear the
ACA.

It wouldn't have done any harm to make the last paragraph of 6.5 apply to
clause (d), namely session closure.  It certainly would have been helped if
the paragraph referred to CA and ACA explicitly.  Such a statement would
have made clear the underlying assumption, namely that a check condition
never affects other initiators, as long as the target implements autosense.

Bottom line: If I understand the SAM and SPC specs correctly, the current
draft of the iSCSI spec is incorrect.  Clause (d) of 6.5 should cause the
tasks to be terminated with a check condition, just like clauses (a), (b),
and (c).  The check condition is visible externally in two situations:

1.  Closing a session will cause tasks from other sessions to be aborted, if
QErr contains 01b and TST contains 0.
2.  Closing a session will cause tasks from other sessions to be blocked, if
QErr contains 00b (or 011b) and TST contains 0 and any of the terminated
commands had the NACA bit set.

dj


-----Original Message-----
From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Tuesday, January 07, 2003 8:52 AM
To: 'Mallikarjun C.'; ips@ece.cmu.edu
Subject: RE: iSCSI: Implicit Termination of Tasks


If it never makes it back to the initiator, then it is an implementation
issue. As long as the target maintains all ordering requirements (iSCSI out
of order commands and SCSI queued commands), all should be well and there
would be no requirement imposed in the spec to implement this.

If would be better to have just given the paragraph below as an
implementation note. As long as we all understand what your intent was, then
we should be OK (and you have now explained that).

Thanks

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Monday, January 06, 2003 9:15 PM
To: Eddy_Quicksall@iVivity.com; ips@ece.cmu.edu
Subject: Re: iSCSI: Implicit Termination of Tasks


Eddy,

iSCSI's design goal was to ensure command ordering
even in the face of errors - ultimately, we wanted the SCSI
execution ordering to be correct while running on iSCSI.
This should be able to be guaranteed by the iSCSI targets,
while initiators may/may not employ command ordering.

For this to happen, iSCSI must both maintain its delivery
ordering, and require SCSI CHECK CONDITIONs to
be locally triggered on the target on iSCSI exception
conditions such as connection terminations.  The CHECK
CONDITION would then cause the ACA/persistent-UA to
be invoked if so desired by the initiator.

This is not "a method of implementing", it's required behavior
to meet iSCSI's architectural guarantee of command ordering.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com


----- Original Message -----
From: "Eddy Quicksall" <Eddy_Quicksall@iVivity.com>
To: "'Mallikarjun C.'" <cbm@rose.hp.com>; <ips@ece.cmu.edu>
Sent: Monday, January 06, 2003 12:46 PM
Subject: RE: iSCSI: Implicit Termination of Tasks


> Yes, I noticed my typo of "two" vs. "three" but too late.
>
> Below you say that the ordering is iSCSI ordering but section 6.5 is
saying
> SCSI ordering (queued commands is SCSI). So, that leaves me a little
> confused as to what this paragraph is trying to say, especially when
the
> "status is never communicated back ... to the initiator".
>
> I'm probably mis-understanding something. It appears as though this is
just
> a method of implementing within the target.
>
> Eddy
>
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Monday, January 06, 2003 3:12 PM
> To: Eddy_Quicksall@ivivity.com; ips@ece.cmu.edu
> Subject: Re: iSCSI: Implicit Termination of Tasks
>
>
> Comments below.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
> ----- Original Message -----
> From: "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
> To: <ips@ece.cmu.edu>
> Sent: Monday, January 06, 2003 5:16 AM
> Subject: iSCSI: Implicit Termination of Tasks
>
>
> > There are two sections titled Implicit Termination of Tasks but they
> are
> > slightly different. Which is correct?
>
> Both are correct and consistent.
>
> >
> > Section 6.5 lists 4 items but section 10.14.5 only lists two.
>
> I'm seeing three in 10.14.5.....
>
> Even though 6.5 lists all the four cases, it makes it clear that the
> check condition is to be employed only for three cases - and
> only those three are listed by 10.14.5.  Perhaps the text could have
> been a little bit more explicit about this distinction.
>
> >
> > If 6.5 is correct, why is item D not included in the unit attention?
> SAM-3
> > says:
>
> It's not so much a SAM issue.  The issue we considered was how to
ensure
> iSCSI-standard ordered delivery of commands in the face of errors.
The
> ordered delivery of commands does not make sense for case (d) - that
of
> creating a new session - ordering is not guaranteed anyway across
> sessions.
>
>