iSCSI: "kicker" reservation problem

[Black_David@emc.com]

In the midst of the ISID discussion, Jim Hafner tossed in the following:

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

And then pointed out that leaving the ISID as currently specified would
be an easy way to accommodate this functionality.

After further thought, I agree that this is easy, but believe that it is
the wrong design approach because it'll make the current ISID allocation
problems significantly worse.  The reasoning starts by observing that
while SCSI makes reservations, it doesn't "own" them in that it has no
idea what the intended purpose of the reservation is - that knowledge
exists only in some "application" (e.g., backup, cluster) above SCSI.

If the proposed language is adopted to allow reservations to be shared
across target ports, but be bound to initiator ports, the identities
of the initiator ports have to be visible to the "application" so that
it can control SCSI behavior with respect to reservations.  For iSCSI,
I think this leads to applications needing to be involved in ISID selection.
Consider an application that opens a new iSCSI session to a different SCSI
port on an iSCSI Target to which a session is already open.  How does
iSCSI know whether to reuse the same ISID as the existing session (so
that reservations can span the sessions) or use a new ISID (so they don't)?
The answer is that iSCSI does not have the information required to answer
that question - it has to be passed down from the "application" which is
the only entity that knows what the intended result is.  The upshot is that
the ISID coordination problem has just expanded in scope from multiple
iSCSI implementations (e.g., HBAs) to also include multiple "applications"
above SCSI - this is not a good thing.  For the sake of simplicity, I think
that if ISID remains, it should not be used for this sort of reservation
scope control.

In practice, I think
the problem is more fundamental -- the proposed T10 language appears to
be at odds with iSCSI's notion of dynamically created session endpoints
that span hardware interfaces.  At best, T10 is probably looking towards
Fibre Channel in which session endpoints are static hardware interfaces.
The easiest way to get back in line with T10 would be to forbid iSCSI
sessions from spanning network interfaces, and then use the IP address
of the network interface as the SCSI Initiator Port Name, but that would
be a significant change from the approach we've been pursuing to date.
Alternatively, we could invent yet another software name for the SCSI
Initiator Port that exists primarily to cope with this new notion of
reservation scope, but I tend to agree with Jim Hafner's concern that
this makes the mapping of SAM-2 SCSI Port concepts to iSCSI less
believable/tenable/etc.

There doesn't appear to be a good solution here.

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