Re: LU access through an iSCSI session

["Matt Wakeley" <matt_wakeley@agilent.com>]

Jim Hafner/Almaden/IBM wrote:

> Pierre,
>
> The answer to your questions (in my mind) are:
>
> > 1) Do commands directed to a particular LU through a session are
> > able to use any of the TCP connections within the  session?
>
> I think this should be "Yes" and is a very desirable design point (but I
> don't know if that's what we're going to get).

As I said in a previous reply, the *only* answer is "Yes", which leads to...

>
>
> > 2) Do commands directed to a particular LU through a session
> > need to be associated to different LUNs depending on the TCP
> > connection used or is it always the same LUN for all
> > the connections?
>
> This has a more complicated answer, namely: *it depends*.

Again, the *only* answer is "Yes".  The multiple TCP connections make up a
*single* session.  The session just happens to have lots of "TCP connections"
to make it look like it has a "big pipe" (for example, 4 1Gbit connections can
be used to emulate a 4Gbit link).

If you want different "LU views" per TCP connection, then each TCP connection
would be a separate, independent iscsi session.

-Matt

>

>  Vendors can
> implement what they like, so in some of today's FC devices, the answer is
> that you might get different LUNs on different ports.  Though, in that
> case, it's not clear if different ports are conceptually connected in
> anything that resembles an initiator/target session.  The "same LUN for all
> connections" was a hoped-for side effect of the SCSI access controls model,
> since in that model, LUN Maps are defined per initiator, regardless of port
> connection.  If the initiator in an I_T nexus is coalesced across multiple
> connections, then you should see this.  On the other hand, the model
> doesn't preclude more complex implementations and other behaviour.  Such
> implementations would not necessarily be contrary to the SCSI standards
> (they are silent on this point) but would definitely be extra-standard.
>
> I agree with you that this behaviour is undesirable for many reasons, but
> there's nothing to inhibit it except market forces (I think).  I don't
> think IETF through iSCSI can mandate this behavior particularly since T10
> through SAM/SPC doesn't.
>
> Also, I agree with your assessment of the situation.
>
> Jim Hafner