Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h420YXS25101
	for <ipsml@ece.cmu.edu>; Thu, 1 May 2003 20:34:33 -0400 (EDT)
Received: by bache.ece.cmu.edu (Postfix, from userid 953)
	id E00DAB9; Thu,  1 May 2003 20:34:32 -0400 (EDT)
Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27])
	by bache.ece.cmu.edu (Postfix) with ESMTP
	id 36251B7; Thu,  1 May 2003 20:34:29 -0400 (EDT)
Received: by sos.ece.cmu.edu (Postfix)
	id 47118898F; Thu,  1 May 2003 20:34:13 -0400 (EDT)
Received: from sos.ece.cmu.edu (localhost [127.0.0.1])
	by sos.ece.cmu.edu (Postfix) with ESMTP id C7C78898E
	for <ips-outgoing@sos.ece.cmu.edu>; Thu,  1 May 2003 20:34:12 -0400 (EDT)
Received: (from majordom@localhost)
	by sos.ece.cmu.edu (8.12.9+Sun/8.12.2/Submit) id h420YCfL000793
	for ips-outgoing; Thu, 1 May 2003 20:34:12 -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 CE378898C
	for <ips@sos.ece.cmu.edu>; Thu,  1 May 2003 20:34:10 -0400 (EDT)
Received: by bache.ece.cmu.edu (Postfix)
	id 56FEBA3; Thu,  1 May 2003 20:34:10 -0400 (EDT)
Delivered-To: ips@ece.cmu.edu
Received: by bache.ece.cmu.edu (Postfix, from userid 953)
	id 363A8B9; Thu,  1 May 2003 20:34:10 -0400 (EDT)
Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213])
	by bache.ece.cmu.edu (Postfix) with ESMTP id CD1F1A3
	for <ips@ece.cmu.edu>; Thu,  1 May 2003 20:34:07 -0400 (EDT)
Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26])
	by atlrel7.hp.com (Postfix) with ESMTP id E35A41C013B7
	for <ips@ece.cmu.edu>; Thu,  1 May 2003 20:34:06 -0400 (EDT)
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 RAA20403 for <ips@ece.cmu.edu>; Thu, 1 May 2003 17:34:05 -0700 (PDT)
Message-ID: <006f01c31042$88d6f2a0$766f030f@rose.hp.com>
From: "Mallikarjun C." <cbm@rose.hp.com>
To: <ips@ece.cmu.edu>
References: <AEC4671C8179D61194DE0002B328BDD26A7B66@ATLOPS>
Subject: Re: iSCSI: clearing SCSI objects
Date: Thu, 1 May 2003 17:33:57 -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=-17.7 required=5.0
	tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES,X_AUTH_WARNING
	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)

> 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
>  
> 

