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 h421LSS27582
	for <ipsml@ece.cmu.edu>; Thu, 1 May 2003 21:21:28 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix, from userid 953)
	id F245B99; Thu,  1 May 2003 21:21:27 -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 992598D; Thu,  1 May 2003 21:21:21 -0400 (EDT)
Received: by sos.ece.cmu.edu (Postfix)
	id 2B1208996; Thu,  1 May 2003 21:21:07 -0400 (EDT)
Received: from sos.ece.cmu.edu (localhost [127.0.0.1])
	by sos.ece.cmu.edu (Postfix) with ESMTP id 057978995
	for <ips-outgoing@sos.ece.cmu.edu>; Thu,  1 May 2003 21:21:07 -0400 (EDT)
Received: (from majordom@localhost)
	by sos.ece.cmu.edu (8.12.9+Sun/8.12.2/Submit) id h421L6N2001310
	for ips-outgoing; Thu, 1 May 2003 21:21:06 -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 bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23])
	by sos.ece.cmu.edu (Postfix) with ESMTP id 0D54E8992
	for <ips@sos.ece.cmu.edu>; Thu,  1 May 2003 21:21:04 -0400 (EDT)
Received: by bache.ece.cmu.edu (Postfix)
	id 8D44D76; Thu,  1 May 2003 21:21:04 -0400 (EDT)
Delivered-To: ips@ece.cmu.edu
Received: by bache.ece.cmu.edu (Postfix, from userid 953)
	id 6DE11B9; Thu,  1 May 2003 21:21:04 -0400 (EDT)
Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245])
	by bache.ece.cmu.edu (Postfix) with ESMTP id 01FAA76
	for <ips@ece.cmu.edu>; Thu,  1 May 2003 21:21:00 -0400 (EDT)
Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26])
	by palrel10.hp.com (Postfix) with ESMTP id 5874F1C01B9D
	for <ips@ece.cmu.edu>; Thu,  1 May 2003 18:21:00 -0700 (PDT)
Received: from swathi (dhcp-rosefl-bbb118.rose.hp.com [15.3.111.118]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id SAA23737 for <ips@ece.cmu.edu>; Thu, 1 May 2003 18:20:59 -0700 (PDT)
Message-ID: <008901c31049$16460350$766f030f@rose.hp.com>
From: "Mallikarjun C." <cbm@rose.hp.com>
To: <ips@ece.cmu.edu>
References: <AEC4671C8179D61194DE0002B328BDD26A7BB5@ATLOPS>
Subject: Re: iSCSI: clearing SCSI objects
Date: Thu, 1 May 2003 18:20:58 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
X-Spam-Status: No, hits=-11.3 required=5.0
	tests=QUOTED_EMAIL_TEXT,REFERENCES,X_AUTH_WARNING
	autolearn=ham	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)

>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
> >  
> > 
> 

