RE: iSCSI: response to second login (with same ISID)

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

> I'd vote for (2) for the following reasons :
> 
> a) It is possible for initiators to use the ISID as a scheme to
> establish persistence of their O.S. device files. In doing so,
> initiators would attempt to obtain the same ISID for a given 
> session to
> a given target ports across boots. (and rightly so, for 
> enabling targets
> to track persistent reservation like properties, etc).
> 
> In the event where the initiator went through a non-orderly shutdown
> which did not close all sessions, it would attempt to re-login on
> re-boot with the same ISID. If the target rejected this re-login, per
> (1) (citing an invalid ISID), the initiator would no longer be able to
> maintain persistence of the session to an ISID.
> 
> b) Using (2) allows the hosts to hint to the target that the previous
> session is now stale and thus triggers clean-up of stale session
> resources.

This seems to me to provide another example why ISID should *not* be used
for persistent reservation re-establishment.  It's ambiguous whether this is
a case of "defective initiator" or "initiator trying to re-claim persistent
reservations" and there is no way for iSCSI to resolve this question.  Since
persistent reservations are SCSI layer things, lets try to find a way to
keep their implementation from forcing unnecessary limitations at the iSCSI
layer.  The use of init. name+ISID+target name for identifying persistent
reservations needs further discussion before we allow it to creep into iSCSI
protocol rules.  I've very uncomfortable with treating ISID like a fixed
address just because SCSI persistent reservations don't have a sufficient
SCSI layer mechanism.  Seems like this will force all kinds of layering
violations into iSCSI.

Marj