Message-ID: <AEC4671C8179D61194DE0002B328BDD26A7C68@ATLOPS>
From: Eddy Quicksall <eddy_quicksall@ivivity.com>
To: "David Black (Black_David@emc.com)" <Black_David@emc.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: clearing SCSI objects
Date: Sun, 4 May 2003 09:34:53 -0400 
MIME-Version: 1.0
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

I'm wondering what other targets are doing about this. Was it thought about
during the design phase?

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?

Eddy

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] 
Sent: Friday, May 02, 2003 9:44 AM
To: Mallikarjun C.; ips@ece.cmu.edu
Subject: RE: iSCSI: clearing SCSI objects

Thanks for making me more aware.

Actually what I'm looking for is a sure fire way I can release resources for
a SCSI Initiator Port (InitiatorName+ISID) after session closure (assuming
there are no outstanding persistent reservations).

Understanding "I_T Nexus Loss" better brings up another point regarding
this:

Section 6.3.4 of SAM-3R6 says that the target shall establish a unit
attention for the SCSI initiator port. But the SCSI initiator port is
identified via the ISID. That means after a session closure (in my case via
a session logout), the target needs to still keep state information for each
ISID that was ever used.

That can be a burden on the target's resources. Especially if the initiator
device uses a different ISID for each login.

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com] 
Sent: Thursday, May 01, 2003 9:21 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: clearing SCSI objects

>But if the
> default versions apply to ErrorLevel 0, that is exactly what I want.

Careful here, the default versions apply to any level when there's
no explicit Logout dialogue (refer 6.4.1).

> Also, paragraph 12.16 does not talk about exceeding DefaultTime2Retain
> causing an I_T Nexus Loss notification 

Because exceeding (DefaultTime2Wait+DefaultTime2Retain) does not
necessarily always cause an I_T Nexus Loss, refer 5.3.5.1 for what does.

> Can you confirm that the following would be correct?

Correct if that's a single-connection session.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Eddy Quicksall" <eddy_quicksall@ivivity.com>
To: "Mallikarjun C." <cbm@rose.hp.com>; <ips@ece.cmu.edu>
Sent: Thursday, May 01, 2003 6:07 PM
Subject: RE: iSCSI: clearing SCSI objects


> Thanks, that was the missing link I think ... I thought since
> DefaultTime2Wait & DefaultTime2Retain were only for ErrorLevel 2 because
> that is said in the logout regarding Time2Wait and Time2Retain. But if the
> default versions apply to ErrorLevel 0, that is exactly what I want.
> 
> Also, paragraph 12.16 does not talk about exceeding DefaultTime2Retain
> causing an I_T Nexus Loss notification (which is the only iSCSI thing that
> can clear a SCSI object).
> 
> Can you confirm that the following would be correct?
> 
> - I negotiate for ErrorLevel 0
> - I negotiate for DefaultTime2Wait and DefaultTime2Retain = 0
> - I get a logout
> - I clear all SCSI objects other than the ones you mention below.
> 
> Eddy
> 
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com] 
> Sent: Thursday, May 01, 2003 8:34 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: clearing SCSI objects
> 
> > First, am I correct in the above?
> 
> Not completely.  If there are no active FFP connections
> in the iSCSI session, the session will eventually come to 
> an end ([Default]Time2Wait/Return).  That is when the
> associated I_T Nexus Loss notification is generated, and 
> with it, all the SCSI objects that are considered attributes of 
> that instance of I_T Nexus are cleared.
> 
> Note however that there may be SCSI objects that are
> not linked to the life of an instance of I_T Nexus - this is
> a SCSI issue (and F.2 does refer to it).
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668 
> Roseville CA 95747
> cbm@rose.hp.com
> 
> ----- Original Message ----- 
> From: "Eddy Quicksall" <eddy_quicksall@ivivity.com>
> To: <ips@ece.cmu.edu>
> Sent: Thursday, May 01, 2003 11:58 AM
> Subject: clearing SCSI objects
> 
> 
> > I have a concern regarding a logout followed by login's with a different
> > ISID from the same initiator device.
> >  
> > Here is my concern:
> >  
> > -          the target must keep state information for the initiator port
> > after a logout (such as a reservation - but not limited to that). This
is
> > because section F.2 says only an I_T Nexus Loss can effect clearing
> actions
> > on SCSI objects.
> > -          If a target receives a logout, then another login from
another
> > initiator (or even another login from the same initiator device but a
> > different ISID) then it must have resources available because it can't
> clear
> > the SCSI objects from the logged out session.
> > -          The resources can become stale and the target could run out
of
> > resources.
> >  
> > First, am I correct in the above? If not please explain.
> >  
> > If this is correct, I have not found anything in the spec that says how
> long
> > the SCSI objects must be kept around. 
> >  
> > Eddy
> >  
> > 
>