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

[julian_satran@il.ibm.com]

An amazingly long thread.

The basic assumptions of the thread have been that:

a - a resource (device) is allocated by reserve/release
b -  reservations are associated with a INAME+ISID as the "reserver name"
and therefore those have to be unique in a initiator target pair.

Assuming that everything else is running fine (initiators are able to
login), IMHO this looks entirely as a matter of recovery.  If a target
senses an attempt to create a new session with the same INAME+ISID as an
existing session it should:

    1-Determine if the old session is active (currently transmitting and
receiving or send a polling NOP-In and wait for
         an answer)
      If it is then it has to reject the new session
    2-If it does not it has to clean the old session and establish a new
session.

I also assume that well designed targets will determine that a session is
dead well before a new login forces them
to do so.

The larger question (that Marjorie alluded to)  is whether SCSI is designed
to allow user level access and employ only reservations for coordination
and if it is not conceivable that several sessions can own a reservation
(as several threads in process can get the same lock).  And if reservation
uniqueness within a given initiator should not be maintained by some SCSI
mechanism (a key that is already in SCSI) as in some networks I might have
now a thing running over FCP and after a while a session running on a
backup dialup iSCSI link.

Julo






"Martin, Nick" <Nick.Martin@compaq.com> on 24-05-2001 09:38:17

Please respond to "Martin, Nick" <Nick.Martin@compaq.com>

To:   "'Santosh Rao'" <santoshr@cup.hp.com>, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: response to second login (with same ISID)




[The message I am replying to is below this one.  A similar one was posted
while I was composing this reply.]

Santosh,

If the iSCSI HBA is exposing SCSI targets to the OS, then the OS's SCSI
target driver (or class driver if I have my Microsoft terminology correct)
can support "exclusive access" semantics which can protect the current user
of a tape device from other users on the same system attempting to use the
same device through the same driver, or can allow a disk device (and the
session for it) to be shared by multiple users when that is appropriate.
If
the target device supports some form of SCSI reserve/release, then this
would protect the device from access via a second session from anywhere.
In
the target, iSCSI could also refuse a second concurrent session login to
the
same tape target protecting initiators which do not reserve/release.  (The
trick is: does the target think this is a new session using the same ISID
(reject), or an attempt to clean-up and re-establish an existing session
(reset, accept).)

Think about an iSCSI enabled version of tar or cpio (simple applications
used for tape backups).  These could run from user space over a TCP
connection on a standard NIC using an OS that has no awareness of iSCSI.
If
a second copy of the program is started, how is it to know that something
is
already using the same tape device?  How is it to know the ISID used for
that other copy?  How is it to know whether ANY particular ISID is really
currently in use, or what it is being used for?  How can we prevent the
second copy from unknowingly stealing the device from the first by simply
using the same ISID?  The second user thinks everything is fine until the
first user restarts his command that just failed.  In this model there is
no
HBA driver or target driver.  There is nothing that knows about both
sessions being attempted except the target.

You may think this is a bit far fetched, but I almost have such a program.
I expect other folks will be clever enough to think of other ways to use
this "user mode access" capability of TCP/IP to use remote iSCSI devices
without kernel co-operation.  Can we enable them to peacefully co-exist
with
each other?  Can they peacefully co-exist with kernel mode drivers?

There may be other scenarios such as administrators dynamically adding and
removing iSCSI devices to an OS while a system is running rather than at
boot time (think 24x7 operations, what choice to they have?).  If the
ISID's
are going to have to be manually configured, then there is a high
likelihood
of human error causing disruptions.  If we can enable non-disruptive
automatic ISID probing to find an available ISID during device
configuration
or initialization, this seems safer.  Once we pick an ISID, we should still
remember it across re-boot, to avoid repeated probing, and to assist manual
clean-up after ungraceful shutdown.  We also need the "logout this old
session" capability both for recovery after an initiator crash or error
which failed to logout, and for when the initiator realizes it has no
remaining working TCP connections to an existing session and wants to be
sure to free target resources and start fresh.

So, I think there are valid arguments for both behaviors 1 and 2, and we
need to enable the initiator to select the behavior appropriate for each
application.

Stated another way, we need to allow for the case when the initiator is
sure
that this ISID is unique and it takes full responsibility for all
consequences, and for the case where the initiator can not be sure this
ISID
is unique and wants there to be no side effects for others if it turns out
not to be unique.

Thanks,
Nick
-----Original Message-----
From: Santosh Rao [mailto:santoshr@cup.hp.com]
Sent: Wednesday, May 23, 2001 8:36 PM
To: Martin, Nick
Cc: santoshr@cup.hp.com
Subject: Re: iSCSI: response to second login (with same ISID)


"Martin, Nick" wrote:

>
> I know from personal experience how easy it is for an authorized user to
> unintentionally start a second copy of a backup program, while the tape
> drive is still in use.  This should be a harmless mistake.  What kind of
> traffic cop would prevent this request from making it to the iSCSI target
> and terminating the session already in progress?  (Rhetorical question,
> please do not describe for me such a mechanism ;)

Nick,

I know you don't want an answer to your rhetorical question ;-}, but, I
could'nt resist one quick query here.

In the scenario you describe, is it not the case that HBA drivers would
only send out a Login on the first open of that target, and on
subsequent opens would only bump an open_count or a ref_count of some
kind rather than send a login on the wire on every open ?

If that is correct, then, the scenario you describe would still cause
disruption even with the modified semantics, only, when the WRITE is
issued by the 2nd execution of the backup application (?).

Regards,
Santosh