Logical unit groups and optional target reset

Elliott, Robert Robert.Elliott at COMPAQ.com
Tue Jan 2 16:18:27 PST 2001

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert" <Robert.Elliott at compaq.com>
I'll simplify the quotes since we're getting too deeply nested.

Charles Monia:
>>>>> The other issue is whether mechanisms, such as target reset, 
>>>>> are appropriate for a given transport.  In my view, the only 
>>>>> immutable requirement is to preserve the 
>>>>> transport-independent 
>>>>> part of the semantics.  The definition of transport-specific
>>>>> side effects is best handled in the appropriate transport
>>>>> specification.

>>>> The transport-independent parts are a major part of the 
>>>> problem.  Tasks are aborted, mode pages are reset, etc. 
>>>> unexpectedly.  Based on the rule from 99-245r9, devices 
>>>> offering Access Controls can be set up to behave better.

>>> For a shared device, doesn't an LU reset have similar 
>>> adverse side effects
>>> on other initiators?  This still leaves me wondering 
>>> whether or not it would
>>> be better to restrict the operation altogether.

Rob (responding to Charles):
I expect initiators sharing a logical unit to understand each other.  For
example, they'll be members of a cluster running the same clustering
algorithm.  If they want to use LOGICAL UNIT RESET, that's fine.  Some
clustering algorithms routinely use resets on purpose - they don't just use
it to try to revive a hung device.

Initiators using different logical units that happen to be on the same
target, on the other hand, don't know about each other.  They don't need to
know, except for one case: TARGET RESET.  Targets implementing Access
Controls will keep TARGET RESET from affecting logical units to which the
initiator does not have access rights, which will help (provided access
rights are very strictly granted).

Andrew Hisgen (responding to Charles):
>> We need it to have those side-effects, when the device is wedged.
>> Yes, target reset is a powerful hammer, but we need it to unwedge
>> the device.  The fact that multiple initiators are affected is
>> kind of beside the point when the device is wedged anyway.

Rob (responding to Andrew):
When does your initiator code issue these TARGET RESETs?  As part of normal
operation, or only when a user is performing maintenance and thinks
something is broken?  Does it try LOGICAL UNIT RESET first, or does it just
use TARGET RESET?  I'm not too worried about it being used by
diagnostic-type software, just normal operation.  

Charles (responding to Andrew):
> No argument on that score.
> To me, restricting the operation means providing hooks so that only a
> trusted class of initiators can perform the function.  It's a bit like
> controlling access to a file so that lots of users can read 
> it but only a
> trusted few can perform a write or delete operation.

PC: Robert.Elliott at compaq.com
UNIX: relliott at unixmail.compaq.com

* 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