iSCSI Target Reset

Fri May 4 13:25:27 PDT 2001

* From the T10 Reflector (t10 at t10.org), posted by:
* Andrew Hisgen <Andrew.Hisgen at eng.sun.com>
*

> X-Authentication-Warning: t10.t10.org: lohmeyer set sender to 
owner-t10 at t10.org using -f
> X-Sender: jnemeth%palg.com at pop3.palg.com
> Date: Fri, 04 May 2001 13:17:27 -0600
> To: t10 at t10.org
> From: "Joseph C. Nemeth" <jnemeth at palg.com> (by way of "Joseph C. Nemeth" 
<jnemeth at palg.com>)
> Subject: RE: iSCSI Target Reset 
> Mime-Version: 1.0
> X-Message-Number: 1696
> 
> I have cross-posted the following from the iSCSI reflector site, since the 
> suggestion in the final paragraph is relevant to T10.
> 
> >From: "Elliott, Robert" <Robert.Elliott at COMPAQ.com>
> >To: "'Joseph C. Nemeth'" <jnemeth at palg.com>
> >Subject: RE: iSCSI Target Reset
> >Date: Fri, 4 May 2001 14:02:58 -0500
> >X-Mailer: Internet Mail Service (5.5.2652.78)
> >
> >You should post the reservation feature proposal mentioned below to the 
> >T10 list (see <http://www.t10.org>www.t10.org).
> >
> >---
> >PC: Robert.Elliott at compaq.com
> >UNIX: relliott at unixmail.compaq.com
> >-----Original Message-----
> >From: Joseph C. Nemeth [mailto:jnemeth at palg.com]
> >Sent: Wednesday, May 02, 2001 7:25 PM
> >To: iSCSI Reflector
> >Subject: Re: iSCSI Target Reset
> >
> >On the Spectra Logic tape drives and libraries, we can and do implement 
> >both Target Reset and LUN Reset on interfaces that support these task 
> >management functions (e.g. Fibre Channel), and when we receive either, we 
> >generally do what each of these is supposed to do, making allowances for 
> >real environments. However, Target Reset is useless to us - and its use is 
> >dangerous in a shared environment, because it really should affect 
> >multiple LUNs on the controller. Application vendors have told us that on 
> >some host systems, access to Target Reset or LUN Reset is hidden by the 
> >drivers, so they often can't use it even when they need to, making both 
> >Reset functions mostly a nuisance. 

I think there may be some confusion here of who the expected client
of this Reset functionality.  The fact that it is not exposed to
end applications does NOT imply that drivers do not need it.  
Device drivers often use the Reset functionality to clear hung
devices.  It disturbs me to hear you say that BOTH forms
of Reset are a nuisance, and that "LUN Reset is probably still
useful".  Huh?  Once you have gotten rid of Target Reset, LUN
Reset becomes a *requirement*.  "Probably useful" is probably
an understatement.

> >So Target Reset could be deprecated in 
> >iSCSI and there would be no tears here. LUN Reset is probably still useful.
> >
> >Reset seems to be a problem because it is a BIG hammer used to solve a lot 
> >of different problems, often with undesirable side effects. Here are the 
> >main things Reset is used for:
> >    * Clear a hung parallel SCSI bus (only applies to parallel SCSI)
> >    * Reset parallel SCSI target data transfer parameters (e.g. sync and 
> > wide, only applies to parallel SCSI)
> >    * Reset a hung SCSI state machine (doesn't happen much, any more, with 
> > intelligent chipsets)
> >    * Clear the command queues for one or more LUNs
> >    * Clear LUN reservations made by a defunct host
> >    * Reset all Mode Pages to default/last saved values (rarely useful, 
> > once you can communicate with the device)
> >    * Rewind/reload tapes in tape drives (usually an undesirable side-effect)
> >    * Re-inventory autochangers and return robotics to a "known state" 
> > (usually an undesirable side-effect)
> >    * Set Unit Attention conditions (often silently swallowed by drivers)
> >In particular, trying to gracefully recover control of a device that has 
> >been reserved by a host that has gone down seems to be what's really 
> >driving this recent round of discussions about Reset. Reservation 
> >preemption is a needed function that simply isn't in SCSI, other than 
> >using Reset -  or making the shift to Persistent Reserve In/Out, which 
> >(frankly) has too many bells and whistles and breaks existing code, since 
> >you can't mix Persistent Reserve with Reserve.

The non-mixing is deliberate.  Persistent Reserve makes sense -- it makes
the Reservation immune to resets, which is what we need.  The
Persistent Reservations also provide for Preemption, which is
also needed.

> >
> >I would like to see a simple extension of Reserve and Release to allow 
> >existing reservations to be preempted. The preempted initiator should get 
> >a UNIT ATN condition to let it know that it got bumped (and there is 
> >already a standard UNIT ATN error defined), but other than that, the LUN 
> >state should be left strictly alone. If this feature were added, I think 
> >it would take a lot of pressure off the Reset issue. This could be easily 
> >prototyped by using the VU bits (6 or 7) of the CDB Control Byte in the 
> >Reserve or Release command, and later standardized by moving the bit to 
> >one of the reserved bits in byte 1 of the CDB.

thanks,
--Andy Hisgen
Solaris Clusters, 
Solaris Products Group
Sun Microsystems Inc.

> >
> >Joseph C. Nemeth          Precision Algorithms          (970) 226-5427
> >contact:                         Spectra Logic                    (303) 
> >449-6400
> Joseph C. Nemeth          Precision Algorithms          (970) 226-5427
> contact:                         Spectra Logic                    (303) 
> 449-6400x1102

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org