Re: iSCSI: SAM and iSCSI - some issues

["John Hufferd" <hufferd@us.ibm.com>]

Jim,
I agree with your note, but am adding another perhaps confusion item.  This
is the Target Failure/Take-over event.

1. What should be done if the IP address is not taken over, including what
state Must be kept, etc.
2. What should be done if the IP address is taken over but perhaps not all
state is available to the take over node.  What State Must have been made
available, and what state is not required.  Example: the state of the
ExpCmdSN, etc.

I have been wondering about point 2 and what should happen if such state is
not kept, what should the recovery action be?  Perhaps it should blow the
session away and start over, if so, why did it cause the IP take over to
occur, instead of letting the Initiator just establish a new session, as in
point 1?

Anyway, you may or may not think that this event is worth considering in
your nexus state analysis.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com


Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 05/09/2001 12:53:32 PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: SAM and iSCSI - some issues



Folks,

At the interim meeting, I presented a model of how SAM constructs
(particularly those of nexus, SCSI Device and SCSI Port) can map onto the
iSCSI constructs.  I've sent a copy of the presentation to Elizabeth, so I
assume it will get posted somewhere.  In particular,  an iSCSI session maps
neatly to a SCSI nexus.

There were some open issues concerning the SCSI state of a nexus and how
that state gets affected by various events that affect the session.
From the presentation, here is a (probably incomplete) list of the state
information:

* Some nexus state
  - persistent reservations
  - task set
  - mode page settings
  - unit attention conditions
  - ACA  (added at the meeting)
  - access control enrollment state (per spec)
  - alias lists (yet to be approved by T10)

I'd welcome additions to this list.

A major open question is which of these must persist through various
scenarios where the session/nexus gets torn down and then rebuilt.

I see three broad stroked types of "tear down" events:
(a) Initiator does an explicit or implicit logout (e.g., in advance of a
shutdown) but target stays functioning
(b) Target does an explicit or implicit logout (e.g., in advance of a power
cycle or other hard reset event) but the initiator stays functioning
(c) Session collapses because all the connections fail but the initiator
and target both stay functioning.

With each of these (or perhaps at a finer granularity) we need to determine
what state information should be preserved in case the nexus/session gets
rebuilt.  For scenario (c), this might be described under error recovery
models.

Clearly, a persistent reservation should survive target recycles (under the
appropriate APTPL setting).  What this means is that if the target
recycles, the "identified initiator port" will still own the reservation,
and IF the nexus gets rebuilt, the initiator port will be recognized as the
owner of the reservation.

My current pre-thinking is that all the others are volatile enough to be
cleared through all these tear-down events with the exception of access
controls enrollment state.  Without going into too much detail, I think
scenarios (a) and (b) can "de-enroll" and scenario (c) can "pending-enroll"
the state.   [If you're not familar with this part of the spec, its
approved for inclusion in SPC-3, and the main relevant document is
ftp://ftp.t10.org/t10/document.99/99-245r9.pdf.]

I welcome comments about these issues.

In a related thread, Santosh has requested a table analogous to Table 4 of
FCP2 which describes other consequences of events of similar type.  I think
there is overlap in that proposed table and the one I'm suggesting here
(and I support that effort).

Jim Hafner