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

[Santosh Rao <santoshr@cup.hp.com>]

Nick,

I agree with you that there is a case for both usage models and a bit in
the Login PDU that allows for both behaviours would address both sets of
issues.

I'm in support of adding a bit ("login unconditionally") to the Login
PDU that allows the initiator to specify whether any previous session
for that ISID, if it exists, is to be logged out and a new session login
established.

Thanks,
Santosh


"Martin, Nick" wrote:
> 
> [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
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard