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

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

Santosh,

Yes, that is exactly the context.   No concurrent sessions from the same
iSCSI initiator to the same iSCSI target with the same ISID.

And Yes, the recovery for persistent reservations is exactly the reason for
that rule.

You give valid arguments for option 2.

Jim Hafner


Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 05-21-2001 12:33:43 PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: response to second login (with same ISID)



Jim Hafner wrote:

> The current thinking is that an iSCSI initiator must use a different ISID
> for each session it opens with a specific iSCSI target.

Jim,

Are you referring to multiple concurrent sessions from an initiator node
to a given target port above in saying that different ISIDs must be used
?

In the case where the initiator re-establishes a session to the same
target port after a power cycle, it is desirable to re-use the same
ISID, to allow for tracking of persistent reservation like properties,
correct ? (Just checking to make sure the ISID semantics did'nt change
since the Nashua discussion.)

> We need to decide on the iSCSI target's response when the iSCSI initiator
> attempts to break this rule.  The choices are:
> 1) REJECT the login with some error code (that the iSCSI initiator can
> understand or infer to mean "ISID in use") and leave the pre-existing
> session alone
> 2) CLOSE the pre-existing session (and abort all it's tasks) and then
> process the new login fresh.
>
> Personally, I have no strong feeling either way, but lean towards option
> (1).  It's simple, clean and doesn't involve any interruption.

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.

Regards,
Santosh