SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: ISIDs and multi-session reservations



    Change of subject line to pick up just Jim's "kicker":
    
    > Now comes a slight kicker!  There is proposed language for SCSI that would
    > allow a device server to associate a reservation with a SCSI initiator
    port
    > *independent of the SCSI target port*, so I could have a path from one
    SCSI
    > Initiator port through each SCSI target port and the reservation state
    > would be equivalent over all the paths (sort of I_*_L nexus).  This new
    > language is based on one fundamental principle, that is, that the SCSI
    > initiator port has a world wide unique persistent intrinsic NAME on which
    > to base the unambiguous recognition of that SCSI Initiator Port
    independent
    > of the target port.  In other words, with a name, the device server can
    > recognize the same initiator port through any of its target ports and so
    > grant equivalent access rights.   Remove the name from iSCSI's SCSI
    > Initiator Port (which you are effectively doing no matter how you look at
    > it), and you can not take advantage of this proposal's new functionality.
    
    That's definitely a kicker, because it requires a persistent name for
    the SCSI Initiator Port - this whole "no ISID" adventure is predicated
    in part on not needing that.
    
    > This is the kind of functionality that many people not intimate with SCSI
    > assumed was already there (and in fact there were assumptions that
    > reservations went so far as to span initiator ports).   Unfortunately,
    > that's not the model in SCSI. This pending proposal is an attempt to get
    to
    > that functionality defined within the parameters defined by SAM-2.
    
    And it makes sense if one assumes that the SCSI Initiator Port is a
    physical entity (essentially an interface/adapter).  With iSCSI making that
    a dynamic software entity, things get peculiar ...
    
    > Note that with the initiator generated ISID as part of the SCSI Initiator
    > Port Name (it's intrinsic), we had the ability to reuse that same ISID for
    > each target portal group (without problem) and get this equivalent
    > reservation state across all those target portal groups (aka, SCSI Target
    > Ports).
    
    ... and this looks peculiar.  The peculiarity is that what we currently
    view as implementation-internal decisions on which ISIDs are used on what
    sessions to various target portal groups now carry semantics that are
    visible
    above iSCSI - in essence the equality or inequality of ISID values across
    sessions to different target portal groups controls how reservations
    behave across those sessions.  Without ISIDs, this ability goes away.
    
    > I don't know if that is too much of a monkey wrench in the works, but it
    > bothers me some.
    
    It sure looks like a monkey wrench to me.  I'm concerned that this could
    lead to things like cluster software wanting to control ISID usage in order
    to get the "right" behavior of reservations across sessions.  My immediate
    reaction is to throw "lazy evaluation" at this problem - something like a
    new text key that cluster software (or the like) passes down to tell
    iSCSI which connections need to have this reservation sharing property
    (and iSCSI passes it to the target in a text command).  Before delving
    into this "lazy evaluation" idea, is anyone else concerned about this
    cluster software scenario, or have I gone off into left field (again)?
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    


Home

Last updated: Mon Sep 10 12:17:06 2001
6492 messages in chronological order