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

From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>
Date: Mon, 28 May 2001 13:23:59 +0200

Hello,

Well the conflict of writing to same sector can still be avoided by
implementaion of some locks in the target but I wonder what will happen in
this case where 2 inititators are connected to a target.

Assume this sequence:
Initiator 1 issues a read command to check the existance of file location in
the iscsi target
	Assume the command goes with success
Initiator 2 issues a write command and changes the location of the file
	Assume this command also ends with success
Initiator 1 tries to read the file from the old location.
	In this case the command will end up with success but the data that
goes to the initiator 1 will be wrong.

Regards,
Sanjeev

-----Original Message-----
From: Lakshmi Ramasubramanian [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 9:28 AM
To: Santosh Rao
Cc: [email-masked]
Subject: RE: iSCSI: response to second login (with same ISID)

Even if the target is capable of supporting multiple initiators, won't
it cause problems
with devices such as disk - say, filesystem from the two initiators'
side attempt to write 
to the same sectors (even not intentionally) would cause data
corruption. Is iSCSI layer
suppose to guard against this type of device sharing? 

But, if the target serializes access to the device by reserve\release,
it would avoid
conflict. Is that how it's suppose to work? 

Thanks!
 -lakshmi

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]] 
Sent: Friday, May 25, 2001 6:09 PM
To: Lakshmi Ramasubramanian
Cc: [email-masked]
Subject: Re: iSCSI: response to second login (with same ISID)

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

Lakshmi Ramasubramanian wrote:
> 
> 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)?

---

From: Patrick Stirling <[email-masked]>
Date: Mon, 28 May 2001 15:45:13 -0700 (PDT)

> it cause problems  with devices such as disk - say, filesystem from the
> two initiators' side attempt to write 
> corruption. Is iSCSI layer suppose to guard against this type of
> device sharing? 

Umm, am I missing something here?

If 2 initiators want to access the same SCSI device, they must coordinate
to avoid clashing with each other. It's not the device's responsibility to
prevent this. This is one reason several companies have complicated
clustering software.

patrick
Patrick Stirling
VERITAS Software (vendor of complicated clustering software!)

---

From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <[email-masked]>
Date: Tue, 29 May 2001 02:57:39 +0200

Hello Patrick,

Since the initiators are two different entities working completely
independent of each other they cannot co-ordinate with each other. iSCSI
Target also sees these two different initiators in different sessions as
seperate entities. In the current implementation of iSCSI I guess it is not
possible for two different initiators to know about each other and so it is
difficult to resolve this conflicting situation.

The answer to this problem might be lying in SAM-2 specifications. May be I
am missing something there. Can somebody comment?

Sanjeev

---

From: Patrick Stirling <[email-masked]>
Date: Mon, 28 May 2001 19:28:27 -0700 (PDT)

> am missing something there. Can somebody comment?

As far as I'm aware, you have two options:

- the initiators co-operate to share the device
- the initiators make reservations to lock each other out (in which case
  one could assert that they have indirect knowledge of each other)

BTW this is a general SCSI issue, not confined to iSCSI. Note that you
must also be careful about target resets & other task management commands
here. Also note that when devices are shared it's usually done above the
initiator level, i.e. there's an application using the initiator to access
the device, and it's aware of other initiators. One might say "it's a
layering issue" - SCSI provides reservations to help share devices, but
it's up to higher layers to coordinate the sharing.

patrick