SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    
    


Home

Last updated: Tue Sep 04 01:04:44 2001
6315 messages in chronological order