Deferred error in REQUEST SENSE parameter data - order causes a problem

Gerry Houlder gerry.houlder at seagate.com
Fri Aug 26 12:00:47 PDT 2011


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1108261_f.htm">HTML-formatted message</a>

There are a bunch of pollable sense data possibilities that take along time
before they will clear. The OPERATION IN PROGRESS case is one, the device
being is a low power condition is another. A deferred error can only be from
something that already posted GOOD status for a command before the current
"operation in progress". The longer this deferred notification gets delayed,
the more likely that this error will cause a new error -- maybe even an
error affecting the operation in progress.
A host that is looking for an operation in progress to be completed had
better be looking specifically for GOOD status -- anything else is going to
force the host into some kind of error recovery scenario anyway.
On Fri, Aug 26, 2011 at 12:52 PM, Kevin D Butt <kdbutt at us.ibm.com> wrote:
> CAP recently made a change to the ordered list of allowable sense data to
> be returned in REQUEST SENSE parameter data by adding in deferred error
> sense data.  This is in the ordered list shown below as 1-5.
>
> One of my engineers pointed out a problem with having this order (i.e., 5
> before 6) and as such we believe the order needs to be reversed to be
> pollable sense prior to deferred error sense.
>
> The reason is that an initiator that is polling for status on an immediate
> command is looking for one of the additional sense codes that indicate
> processing is in progress (e.g., OPERATION IN PROGRESS).  When it sees
sense
> data that is some other additional sense code - as will happen with a
> deferred error, the initiator believes the operation is complete.  In fact,
> if recovered errors are allowed and a device implements reporting temporary
> errors, these might happen on immediate commands (e.g., format, verify,
etc)
> and they might happen many times.  These all would get in the way of
polling
> for process completion.
>
> *6.29 REQUEST SENSE command*
> ....
> Except as described elsewhere in this subclause, the device server shall
> process a REQUEST SENSE command as follows:
> 1) return applicable sense data in the parameter data as follows:
> 1) if the logical unit that reports a peripheral qualifier of 011b or 001b
> in its standard INQUIRY data (see 6.4.2), then return parameter data
> containing sense data with the sense key set to ILLEGAL REQUEST and the
> additional sense code shall be set to LOGICAL UNIT NOT SUPPORTED;
> 2) if the logical unit that reports a peripheral qualifier of 000b in its
> standard INQUIRY data because it has a peripheral device connected but is
> not ready for access, then return parameter data containing sense data
> appropriate to the condition that is making the logical unit not
> operational;
> 3) if the REQUEST SENSE command was received on an I_T nexus with a pending
> unit attention condition, then return parameter data containing sense data
> for the unit attention and clear the unit attention condition as described
> in SAM-4;
> 4) if a recovered error occurs during the processing of the REQUEST SENSE
> command, then return parameter data containing sense data with the sense
key
> set to RECOVERED ERROR;
> 5) if deferred error sense data (see 4.5.5) is available, then return
> parameter data containing sense data for the deferred error;
> 6) return pollable sense data (see 5.6.2), if any; or
> 7) return parameter data containing sense data with the sense key set to NO
> SENSE and the additional sense code set to NO ADDITIONAL SENSE INFORMATION;
> and
> 2) complete the REQUEST SENSE command with GOOD status.
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> Data Protection & Retention
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/



More information about the T10 mailing list