iSCSI: SAM and iSCSI - some issues

["Jim Hafner" <hafner@almaden.ibm.com>]

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