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

From: "Lakshmi Ramasubramanian" <[email-masked]>
Date: Fri, 25 May 2001 13:48:37 -0700

How is a target driver suppose to respond to a login from an initiator,
when
another initiator already has a session going on with the given target?
Is the target 
suppose to reject the second login (say, with an error "device busy" or
something simialar)? 

Thanks!
 -lakshmi 

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]] 
Sent: Monday, May 21, 2001 5:39 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: [email-masked]
Subject: Re: iSCSI: response to second login (with same ISID)

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

>  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.

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

---

From: Santosh Rao <[email-masked]>
Date: Fri, 25 May 2001 18:08:31 -0700

Why would the target want to reject the login, unless it is not capable
of [or does not wish to] speak to multiple initiators ?

In the case of most targets, they should be capable of handling multiple
initiators and therefore, should accept the login.

If the target is incapable of supporting multiple initiators or does not
wish to allow multiple initiators (ex : iSCSI tape drive preventing
concurrent access), then, it can reject the login with a status
class/response of 0x0205. (Target Conflict).

- Santosh