iSCSI Target Reset

Joseph C. Nemeth jnemeth at palg.com
Fri May 4 15:02:20 PDT 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* "Joseph C. Nemeth" <jnemeth at palg.com>
*
At 02:25 PM 5/4/01, you wrote:

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

Of course, our devices never hang, so this isn't an issue. (::laughing::)

Seriously, however, I've seen drivers that spit out a BUS RESET on a SCSI 
bus just because a command timed out, when an Abort would be the 
appropriate starting-point. This is, of course, devastating to some other 
tape drive on the bus that is working fine on some other backup for a 
different initiator. Parallel SCSI rarely shares a bus with multiple 
initiators, but fibre and iSCSI certainly do, and Resets of any sort in a 
multi-initiator environment are very unfriendly.

Target Reset makes a lot of sense on parallel SCSI controllers, since there 
are several target-based link-level parameters (like sync or wide) that can 
get out-of-sync with the initiator, preventing the initiator from talking 
to any LUN at that target address. On fibre and iSCSI, those kinds of 
link-level parameters are handled very differently, and if they get that 
badly out of whack, the Target Reset isn't going to get through anyway.

In our implementations of fibre and iSCSI, by the time we get a Target 
Reset, a LUN Reset, a Clear Task Set, an Abort Task Set, or an Abort, we've 
already demonstrated that the link level is fully functional, and that our 
controller is basically up and running. Clear Task Set, Abort Task Set, or 
Abort generally work just as well to "unwhack" the controller, since any 
one of these is enough to tell us that the initiator has lost patience, and 
we are free to start recovery actions. The distinctions, for us, among all 
these different task management functions are purely a matter of how much 
frosting we put on the cake.

In the massively shared environments of fibre and iSCSI, where there may be 
separate initiators talking to each LUN, the use of a Target Reset on a 
multi-LUN target controller is generally a disaster. LUN Reset isn't a 
problem, but isn't particularly any more useful than the Abort variants - 
EXCEPT for the fact that it is the only method of clearing a reservation.

This is what I mean by "nuisance."

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




More information about the T10 mailing list