iSCSI Target Reset

Joseph C. Nemeth jnemeth at palg.com
Fri May 4 12:17:27 PDT 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* "Joseph C. Nemeth" <jnemeth at palg.com> (by way of "Joseph C. Nemeth" <jnemeth at palg.com>)
*
--=====================_672204028==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

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 www.t10.org <http://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. 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.



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.



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



--=====================_672204028==_.ALT
Content-Type: text/html; charset="us-ascii"


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 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. 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.
 
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.
 
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
 

--=====================_672204028==_.ALT--




More information about the T10 mailing list