Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h0G6hKs09267
	for ips-outgoing; Thu, 16 Jan 2003 01:43:20 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0G6hHW09261
	for <ips@ece.cmu.edu>; Thu, 16 Jan 2003 01:43:17 -0500 (EST)
Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125])
	by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 5C72B3C85
	for <ips@ece.cmu.edu>; Thu, 16 Jan 2003 00:43:11 -0600 (CST)
Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 16 Jan 2003 00:43:10 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6344.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: UNH Plugfest 5
Date: Thu, 16 Jan 2003 00:43:10 -0600
Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C604204D39@cceexc17.americas.cpqcorp.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: UNH Plugfest 5
Thread-Index: AcK9AikIAsShJlw5Q6OKRqWKKI/8UgAJAu3A
From: "Elliott, Robert (Server Storage)" <Elliott@hp.com>
To: <ips@ece.cmu.edu>
X-OriginalArrivalTime: 16 Jan 2003 06:43:10.0794 (UTC) FILETIME=[8933BAA0:01C2BD2A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id h0G6hHW09263
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> -----Original Message-----
> From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] 
> Sent: Wednesday, January 15, 2003 3:28 PM
> To: Julian Satran; 
> Subject: Re: UNH Plugfest 5
> 
> Two more questions arose at the plugfest today, 15-Jan-2003.
> ...
> 2.  The question arose with regard to how an initiator maps a scsi
>     "bus reset" onto iscsi (this may be a legacy situation).  
>     Some vendor initiators are simply doing a session logout, but
>     other  vendors claim this is not sufficient, and that to 
>     correctly emulate a "bus reset"
>     the initiator needs to do a task management function TARGET WARM
>     RESET, or, since that is optional to implement, when it is not
>     implemented then the initiator needs to issue a task management
>     function LOGICAL UNIT RESET for all active LUNs in that session.
> 
>     Can/should there be a "note to implementors" on this in 
>     the standard, so that a consistent result will be obtained
>     in this situation?

All the SCSI transport protocols face this issue.

A parallel SCSI bus reset affects all the target ports on the shared
bus, and all the logical units on those ports.  This is fine if there
is one initiator.

In a multi-initiator fabric, however, an initiator shouldn't affect
target ports or logical units it is not using.  This messes up 
other initiators.  

iSCSI's TARGET COLD RESET doesn't honor SCSI access controls, so
isn't safe at all.  TARGET WARM RESET honors them, but doesn't mesh 
with other sharing schemes (e.g. HBA-based LUN masking).  Neither
of these is advisable outside of a lab.

The best approach is to send a LOGICAL UNIT RESET to each logical
unit the initiator is actually using.  This clears all the SCSI
level state but does not affect any iSCSI specific state.  If 
the "bus reset" is being used to clear reservations of a quorum
disk, this should suffice.

If the iSCSI specific state appears to have problems, then a 
connection or session logout should clear it.

> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774

---
Rob Elliott, HP Server Storage
elliott@hp.com 
