SRP Response IU consideration

Edward A. Gardner eag at ophidian.com
Sun Mar 10 11:13:32 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Edward A. Gardner" <eag at ophidian.com>
*
>What I mean by "system cause the failure so that the
>  CMD or MGMT IU can not proceeding" is the system may temporarily out of
>recourses, such as memory. For this case, we don't want to disconnect the
>channel, because system can be recovery by himself later, we want to send

Problems with a temporary lack of resources have been around for a long
time, they are not SRP specific.  As Cris said, they are best dealt with at
a higher (SCSI) level, not specific to SRP.  SCSI (dating all the way back
to SCSI-1) provides a BUSY status code, currently defined as:

BUSY. This status indicates that the logical unit is busy. This status shall
be returned whenever a logical unit is unable to accept a command from an
otherwise acceptable initiator (i.e., no reservation conflicts). The
recommended initiator recovery action is to issue the command again at a
later time.

This sounds (to me) like exactly what you are looking for.  I believe it's
original intent was to report a temporary lack of resources.

With that said, do realize that having to recover from temporary or
transient problems is very difficult in a system context.  BUSY status may
report the problem, but there is no good way for the host OS / driver /
application to determine when it should retry the command.  The specific
method for reporting a temporary lack of resources doesn't matter, the
problem itself is the source of the difficulty.  Device vendors have learned
that they should ensure a temporary lack of resources never occurs, as that
leads to dissatisfied customers.

Edward A. Gardner               eag at ophidian.com
Ophidian Designs                719 593-8866 voice
1262 Hofstead Terrace           719 593-8989 fax
Colorado Springs, CO  80907     719 210-7200 cell
-----Original Message-----
From: Yaning Gao <YGao at jni.com>
To: 'Edward A. Gardner' <eag at ophidian.com>
Cc: 't10 at t10.org' <t10 at t10.org>
Date: Friday, March 08, 2002 3:25 PM
Subject: RE: SRP Response IU consideration


>* From the T10 Reflector (t10 at t10.org), posted by:
>* Yaning Gao <YGao at JNI.com>
>*
>Hello, Edward,
>What I mean by "system cause the failure so that the
>  CMD or MGMT IU can not proceeding" is the system may temporarily out of
>recourses, such as memory. For this case, we don't want to disconnect the
>channel, because system can be recovery by himself later, we want to send
>back a response with reason, like "SYSTEM FAILURE", or more general, like
>"COMMAND or TASK MANAGEMENT FUNCTION NOT COMPLETE", or "OTHER REASON CAUSED
>CMD or MGMT NOT COMPLETE" etc. Right now, there are only 4 RSP_CODE have
>been defined, when I implement SRP, I feel it is not sufficient.
>
>Thank you,
>
>Yaning Gao,
>JNI
> > -----Original Message-----
> > From: Edward A. Gardner [mailto:eag at ophidian.com]
> > Sent: Wednesday, March 06, 2002 7:48 PM
> > To: Yaning Gao
> > Subject: Re: SRP Response IU consideration
> >
> >
> > I don't understand the example you are giving.  Could you
> > give more details
> > as to what you mean by "system cause the failure so that the
> > CMD or MGMT IU
> > can not proceeding"?  Or otherwise explain how the new
> > rsp_code value would
> > be useful?
> >
> > In any case, please send this to the t10 reflector
> > (t10 at t10.org), not just
> > to me, as it is something that the entire SRP community
> > should consider.
> >
> > Edward A. Gardner               eag at ophidian.com
> > Ophidian Designs                719 593-8866 voice
> > 1262 Hofstead Terrace           719 593-8989 fax
> > Colorado Springs, CO  80907     719 210-7200 cell
> > -----Original Message-----
> > From: Yaning Gao <YGao at JNI.com>
> > To: 'eag at ophidian.com' <eag at ophidian.com>
> > Date: Wednesday, March 06, 2002 4:03 PM
> > Subject: SRP Response IU consideration
> >
> >
> > >Hello, Edward,
> > >
> > >The SRP Response IU will send back the RSP_Code in response
> > the SRP Cmd or
> > >SRP Mgmt IU. The RSP_CODE list of the CMD or MGMT IU excute
> > result. But
> > >there is other case to cause failure such as system cause
> > the failure so
> > >that the CMD or MGMT IU can not proceeding, how can I handle
> > this kind of
> > >case? Should I just discard the SRP CMD or MGMT IU? I don't
> > think this is
> > >the good way. Or could we consider to add some other value
> > in the RSP_CODE
> > >to indicate those kind of cases so that I can send back
> > response with those
> > >new value to tell other side the reason?
> > >
> > >Thank you,
> > >
> > >Yaning Gao
> > >JNI
> > >
> > >
> >
>
>*
>* 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