Date: Mon, 5 May 2003 23:13:51 +0000 (UTC)
From: wrstuden@wasabisystems.com
To: Eddy Quicksall <eddy_quicksall@ivivity.com>
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: clearing SCSI objects
In-Reply-To: <AEC4671C8179D61194DE0002B328BDD26A7D2D@ATLOPS>
Message-ID: <Pine.NEB.4.53.0305052307410.502@neverwinter.home-net.icnt.net>
References: <AEC4671C8179D61194DE0002B328BDD26A7D2D@ATLOPS>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

On Mon, 5 May 2003, Eddy Quicksall wrote:

> If you don't worry about it, you will either have to:
>
> 1) have lots of initiator structures available
> 2) not support multiple Initiator Ports
> 3) not be fully SCSI compliant
>
> The Microsoft Initiator will use a different ISID each time it logs on. It
> will log on with each boot and there is no guarantee that it will use the
> same ISID set with each boot. I think multiple applications will also be
> able to login at the same time ... each with a different ISID. If they login
> and logout with execution, you may run our of structures

?? Huh?

I was suggesting not worrying about keeping resources around to tell an
initiator it lost the I_T nexus when it already knows it lost the I_T
nexus. How will that mean I'll run out of resources?

Take care,

Bill

> -----Original Message-----
> From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]
> Sent: Monday, May 05, 2003 6:50 PM
> To: Eddy Quicksall
> Cc: David Black (Black_David@emc.com); ips@ece.cmu.edu
> Subject: RE: iSCSI: clearing SCSI objects
>
> On Sun, 4 May 2003, Eddy Quicksall wrote:
>
> > David,
> >
> > I'm wondering what other targets are doing about this. Was it thought
> about
> > during the design phase?
>
> Our (Wasabi's) target isn't going to do this, unless there is a strong
> indication that it's needed/required for certification. I see no real
> reason to do this as it's not conveying any value.
>
> > I'm thinking I will keep an LRU list and if I run out of structures to
> > handle SCSI Initiator Ports (and there are no persistent reserves
> > outstanding), I'll just discard the oldest structure. That will give a
> power
> > on reset UA if that InitiatorName+ISID is used again.
> >
> > Does that seem like a logical solution?
>
> I think it's far simpler to not worry about it, or be clearer about when
> we worry about it. SAM was written with parallel and FC SCSI in mind.
> While there are obvious references to iSCSI, we are only now gaining
> experience about what needs tweaking in light of iSCSI.
>
> I'd say start with asking why SAM says the target needs to set a UA, and
> see if that applies here. It's my understanding that parallel SCSI has no
> way for the target to asynchronously just tell the initiator something.
> Likewise, the initiator has no way to directly notice the loss of an I_T
> nexus.
>
> iSCSI, though, doesn't have those limitations. For instance, we can send
> Asynchronous messages with SCSI sense data. We also have one or more TCP
> connections, and rules for adding connections to a session. The up-shot is
> that the initiator will realize if it looses the I_T nexus due to
> transport issues. For instance, when it goes to add a connection to a
> session, it will be told that no such session exists (top of page 60 in
> draft 20) -> the session (I_T nexus) is dead. Alternately if the initiator
> chooses to do session reinstatement, it knows it is loosing the old I_T
> nexus (that's what it's telling the target to do, after all :-) .
>
> So I'd think that the best thing to do here is push back on SAM for iSCSI,
> and ignore the need to assert the UA for I_T nexus loss in the cases where
> the initiator will notice it itself.
>
> Note I'm hedging my words, since I think we still need a UA for nexus loss
> if it happens in a way the initiator won't notice.
>
> Thoughts?
>
> Take care,
>
> Bill
>