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

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 21 May 2001 15:58:50 -0700

> 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

---

From: Santosh Rao <[email-masked]>
Date: Mon, 21 May 2001 17:39:20 -0700

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:

>  Since
> SCSI layer mechanism. 

A fixed port identifier of some form is a basic O.S. requirement to be
able to persistently bind the LUNs it sees to some form of device files.
This binding is based on either a physical port identifier or name (ex :
pSCSI target id, FC nport_id, FC port WWN) or in the case of logical
service delivery ports like iSCSI to a logical port identifier such as
the ISID.

A fixed address usage is not only for persistent reservation semantics.
The host O.S. SCSI stacks need *something* that allows them to
persistently bind device files to the same LUNs on each reboot. The ISID
is one form of achieving this. 

> Seems like this will force all kinds of layering
> violations into iSCSI.

Not clear why this is so. Consider the ISID as a logical port identifier
that id considered as a SCSI transport layer endpoint.

Regards,
Santosh