iSCSI: ISIDs and multi-session reservations

[Black_David@emc.com]

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
---------------------------------------------------