Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h4217jS26722
	for <ipsml@ece.cmu.edu>; Thu, 1 May 2003 21:07:46 -0400 (EDT)
Received: by osgood.ece.cmu.edu (Postfix, from userid 953)
	id 2F44FA5; Thu,  1 May 2003 21:07:45 -0400 (EDT)
Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27])
	by osgood.ece.cmu.edu (Postfix) with ESMTP
	id AA820A3; Thu,  1 May 2003 21:07:42 -0400 (EDT)
Received: by sos.ece.cmu.edu (Postfix)
	id 21E948993; Thu,  1 May 2003 21:07:27 -0400 (EDT)
Received: from sos.ece.cmu.edu (localhost [127.0.0.1])
	by sos.ece.cmu.edu (Postfix) with ESMTP id E2A0F8992
	for <ips-outgoing@sos.ece.cmu.edu>; Thu,  1 May 2003 21:07:26 -0400 (EDT)
Received: (from majordom@localhost)
	by sos.ece.cmu.edu (8.12.9+Sun/8.12.2/Submit) id h4217Q3b001144
	for ips-outgoing; Thu, 1 May 2003 21:07:26 -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 osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25])
	by sos.ece.cmu.edu (Postfix) with ESMTP id 31DCA8991
	for <ips@sos.ece.cmu.edu>; Thu,  1 May 2003 21:07:25 -0400 (EDT)
Received: by osgood.ece.cmu.edu (Postfix)
	id E7FCAA3; Thu,  1 May 2003 21:07:24 -0400 (EDT)
Delivered-To: ips@ece.cmu.edu
Received: by osgood.ece.cmu.edu (Postfix, from userid 953)
	id B0CBBA4; Thu,  1 May 2003 21:07:24 -0400 (EDT)
Received: from mail.ivivity.com (unknown [64.238.111.99])
	by osgood.ece.cmu.edu (Postfix) with ESMTP id CB013A3
	for <ips@ece.cmu.edu>; Thu,  1 May 2003 21:07:21 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2653.19)
	id <2CY0STHA>; Thu, 1 May 2003 21:07:21 -0400
Message-ID: <AEC4671C8179D61194DE0002B328BDD26A7BB5@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: Thu, 1 May 2003 21:07:16 -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.5 required=5.0
	tests=BAYES_01,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, 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
>  
> 
