Logical unit groups and optional target reset

Charles Monia cmonia at NishanSystems.com
Fri Dec 22 14:00:33 PST 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* Charles Monia <cmonia at NishanSystems.com>
*
Hi:

I believe simply categorizing such functionality as mandatory or optional
begs the question.

The main issue is how to limit access to mechanisms that are deemed to be
dangerous in certain environments. In my opinion, in an open environment,
use of such "dangerous" mechanisms is best governed by the access control
policy.

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

Charles

> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber at CompuServe.COM]
> Sent: Thursday, December 21, 2000 5:06 PM
> To: 't10 at t10.org'
> Cc: Elliott, Robert
> Subject: Re: Logical unit groups and optional target reset
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <ralphoweber at compuserve.com>
> *
> Rob,
> 
> } We could change SAM-2 to let command sets dictate, so
> } new command sets like SBC-2 and SSC-2 could mark it as
> } optional.  However, command set standards don't normally
> } deal with task management features.
> 
> The mail announcing this proposal suggested that changing
> SAM-2 would allow protocol standards to decide whether
> TARGET RESET is mandatory, and I had no problems with that.
> I assume(d) that SPI, FCP, and other predominately storage
> protocols would continue to require TARGET RESET support,
> whereas iSCSI and such like would make it optional or even
> prohibit it.
> 
> This is appropriate because protocols such as iSCSI may have
> a great deal more than storage transactions riding on an
> interconnect and a TARGET RESET could be a very bad thing
> in some such environments.
> 
> However, I have serious problems with making the TARGET
> RESET decision in the command set standards.  It is the
> nature of the transport protocol that reflects on the
> presence of non-storage traffic on the interconnect and
> thus the appropriateness of TARGET RESET.
> 
> As noted above, I would oppose making TARGET RESET mandatory
> in any strictly or predominately storage protocol because it
> is a tool that most current storage protocol drivers use to
> some level of beneficial effect.  But, where storage is not
> the predominate  traffic on the protocol bus, TARGET RESET
> may simply be too big a hammer, at least as we understand
> the concept today.
> 
> I think the proposal that SBC-2 or any other command set
> standard should discuss the implementation of TARGET RESET
> (or any other task management function for that matter)
> is wrong.  To do so almost certainly would result in
> misdirected requirements for or against the presence of
> TARGET RESET.  It's a protocol not a command set issue.
> 
> Thanks.
> 
> Ralph...
> 
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
*
* 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