Re: iSCSI: ISIDs and multi-session reservations

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

David,

I think your "lazy evaluation" idea, along with a couple of other ideas
that have been floating around all boil down to the same thing.  Namely,
adding some additional naming structure between the InitiatorName construct
and the ISID name construct.  I outlined this in another note (to whom I
can't remember).  It was the idea of a "port extension" to the Initiator
Name.  That's static, reported in login (either embedded in the
InitiatorName key-value or separate).  I argued that we'd then have three
places where there are naming constructs, the InitiatorName, the port
extension name and the ISID and I was unsure whether there was any real
value in adding that to the protocol.  I also said that the port extension
name could quite easily be the portal group tag (and then argued that an
implementation could easily embedded that value in the ISID to provide a
simple mechanism for partitioning ISID).

I also agrued that if I can manage coordination of this extra name, then I
can manage ISIDs by similar mechanisms.

However, I'm uncomfortable with the way you outline your suggestion.  The
reason is that you're asking the iSCSI layer to sometimes and artificially
bind some sessions "as if they came from the same SCSI Initiator Port".
And the rest of the time the target is supposed to sort out that sessions
are not from the same SCSI Initiator Port (mostly because they don't have
an naming construct to tell).  You've effectively given a name to some SCSI
Initiator ports and no name to other such ports.  Again, it might work, but
it is certainly a stretch of the modeling ideas of names for SCSI Initiator
Ports.

Jim Hafner


Black_David@emc.com on 09/09/2001 11:16:43 pm

To:   Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  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
---------------------------------------------------