Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h42DjHS07432
	for <ipsml@ece.cmu.edu>; Fri, 2 May 2003 09:45:17 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix, from userid 953)
	id 18F279B; Fri,  2 May 2003 09:45:16 -0400 (EDT)
Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27])
	by hazard.ece.cmu.edu (Postfix) with ESMTP
	id 3665BA6; Fri,  2 May 2003 09:44:50 -0400 (EDT)
Received: by sos.ece.cmu.edu (Postfix)
	id 6B0918995; Fri,  2 May 2003 09:44:33 -0400 (EDT)
Received: from sos.ece.cmu.edu (localhost [127.0.0.1])
	by sos.ece.cmu.edu (Postfix) with ESMTP id C538D8997
	for <ips-outgoing@sos.ece.cmu.edu>; Fri,  2 May 2003 09:44:32 -0400 (EDT)
Received: (from majordom@localhost)
	by sos.ece.cmu.edu (8.12.9+Sun/8.12.2/Submit) id h42DiW0g006768
	for ips-outgoing; Fri, 2 May 2003 09:44:32 -0400 (EDT)
X-Authentication-Warning: sos.ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
X-Original-To: ips@sos.ece.cmu.edu
Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24])
	by sos.ece.cmu.edu (Postfix) with ESMTP id 3F89C8995
	for <ips@sos.ece.cmu.edu>; Fri,  2 May 2003 09:44:31 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix)
	id BD23F9B; Fri,  2 May 2003 09:44:30 -0400 (EDT)
Delivered-To: ips@ece.cmu.edu
Received: by hazard.ece.cmu.edu (Postfix, from userid 953)
	id A0169A1; Fri,  2 May 2003 09:44:30 -0400 (EDT)
Received: from mail.ivivity.com (unknown [64.238.111.99])
	by hazard.ece.cmu.edu (Postfix) with ESMTP id E1FC39B
	for <ips@ece.cmu.edu>; Fri,  2 May 2003 09:44:26 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2653.19)
	id <2CY0STPH>; Fri, 2 May 2003 09:44:26 -0400
Message-ID: <AEC4671C8179D61194DE0002B328BDD26A7BCC@ATLOPS>
From: Eddy Quicksall <eddy_quicksall@ivivity.com>
To: "Mallikarjun C." <cbm@rose.hp.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: clearing SCSI objects
Date: Fri, 2 May 2003 09:44:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
X-Spam-Status: No, hits=-17.3 required=5.0
	tests=BAYES_00,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,X_AUTH_WARNING
	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)

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
> >  
> > 
> 
