Request Sense Handling of Deferred Errors
roweber at IEEE.org
Tue Apr 12 15:31:38 PDT 2011
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
Yes, the text is very old. The purpose of this thread is to consider
whether it needs to be cleaned up (and incidentally to find someone
willing to write the cleanup proposal). The sentiment "...you have to
ignore..." suggests that you subscribe to the "needs cleanup" notion.
Surely, you would not advocate advice like this, sent to the reflector,
as a valid substitute for solid words in the working draft.
As to the "I see no indication here that REQUEST SENSE is prohibited
|from returning the appropriate sense data ..."
Since "here" only defines returning a CHECK CONDITION status, and
REQUEST SENSE explicitly prohibits that, you must be suggesting that
a suitable reading of SPC-4 r30 allows the behavior as part of returning
sense data as parameter data. As I recall this is precise the opposite
reading of SPC-4 as the reading which formed the basis for original
complaint. Surely, the goal of T10 is to avoid having two different
readings of the same text.
I can forgive anyone who tries to wiggle of the proposal-writing hook
with this fluff, but if we are to reach a condition where *everybody*
reads SPC-4 the same way, then a proposal looks like the only avenue
All the best,
On 4/12/2011 5:03 PM, Knight, Frederick wrote:
> Yes, that RECOVERED error case is interesting because it does NOT say
> */detected/* during the processing of the REQUEST SENSE command; it
> says if the recovered error _occurs during the processing_ of the
> REQUEST SENSE command.
> Im not quite sure how that happens?I think I understand what
> */detected/* during the processing of the R_S command is, but I dont
> know how a RECOVERED ERROR */occurs/* during the processing of the
> R_S command.
> But that is all very old text.For handling of deferred errors, you
> have ignored sub-clause 4.5.5 Deferred errors which describes how to
> return deferred errors as follows:
. The deferred error maybe indicated by returning CHECK CONDITION
> status to an application client accessed
> through a defined I_T nexus as described in this subclause. <note the
> may, not shall>
> If the command terminateswith CHECK CONDITION status <note the if,
> meaning terminating a command with CHECK CONDITION status is not
> required>and the sense data describes a deferred error, the terminated
> command shall not have been processed. After the device server detects
> a deferred error condition, it shall returna deferred error according
> to the following rules:
then a deferred error indication shall be returned for a
shall return a deferred error for one commandreceived
shall return the deferred error for one command
> REQUEST SENSE is a command.I see no indication here that REQUEST SENSE
> is prohibited from returning the appropriate sense data that occurred
> for the deferred error.There is no requirement that the deferred error
> sense data be returned either in the parameter data of a REQUEST SENSE
> command, or in the autosense data of a terminated command; therefore,
> either is allowed.
> *From:*Ralph Weber [mailto:roweber at IEEE.org]
> *Sent:* Tuesday, April 12, 2011 3:10 PM
> *To:* t10 at t10.org
> *Subject:* Re: Request Sense Handling of Deferred Errors
> Okay! We have clarified the situation regarding the original message,
> to whit the following statement is not strictly correct: "In the event
> that the device server detects a deferred error condition, and then
> subsequently receives a Request Sense command, should the deferred
> error cause a Check Condition status to be returned for the Request
> Sense command?" The presence of a deferred error is *_not_* sufficient to
> cause the REQUEST SENSE command to receive a CHECK CONDITION status.
> The new question (i.e., should the REQUEST SENSE command be affected
> by the presence of deferred error sense data?) is more challenging.
> If the answer is yes, then the ordered list at the top of page 373
> (see SPC-4 r30) needs to reflect this, probably via the addition of
> an new entry.
> Right or wrong, this is a normative change and cannot be made without
> a T10 vote.
> Those favoring the addition might take solace in the fact that the
> current 4) entry in the list specifically mentions a recovered error
> (detected _during_ the processing of the REQUEST SENSE command). I
> suspect that some experts would see this as a description of one
> particular instance of a deferred error, which necessarily leads
> to the question of why this specific case is special.
> Let's see how many SCSI gnomes this notion brings out of the
> electronic woodwork.
> All the best,
> On 4/12/2011 1:12 PM, Richard Deglin - SISA wrote:
> Nevertheless, the description of REQUEST SENSE does NOT include
> deferred errors in the list of returnable sense data. SPC4r30, page
> 373. This is a shall clause and I interpret it as meaning that
> REQUEST SENSE shall not return deferred error sense data because it is
> not explicitly listed. Of course, it is always possible that the
> different sections regarding sense data in SPC are in conflict or are
> ambiguous, and T10 perhaps needs to consider this and resolve the issues.
> Rich Deglin
> Senior Firmware Engineer, SAS SSD
> Samsung Information Systems America
> Office 408 544 5816
> Cell 408 410 6584
> *From:*owner-t10 at t10.org <mailto:owner-t10 at t10.org>
> [mailto:owner-t10 at t10.org] *On Behalf Of *Knight, Frederick
> *Sent:* Tuesday, April 12, 2011 6:10 AM
> *To:* Truong Nguyen - SISA; t10 at t10.org <mailto:t10 at t10.org>
> *Subject:* RE: Request Sense Handling of Deferred Errors
> NO. This can be confusing, as there are 2 places where sense data is
> returned. One, is the autosense data that is associated with a
> command. The second is the data buffer that is returned in response to
> the REQUEST SENSE command.
> From the definition:
> *3.1.158 sense data: *Data describing an error or exceptional
> condition that a device server delivers to an application
> clientin the same I_T_L_Q nexus transaction (see 3.1.67) as the
> statusor as parameter data in response to
> a REQUEST SENSE command (see 6.29). The format of sense data is
> defined in 4.5.
> The REDtext is the first (autosense), the GREENtext is the second
> (parameter data buffer) notice the OR between the two types of
> sense data.
> So, when there is a deferred error, and a REQUEST SENSE command is
> received, the parameter data bufferthat is returned will contain sense
> data that describes the deferred error. The autosense dataassociated
> with the REQUEST SENSE command will be associated with the GOOD status
> returned for the command itself.
> Basically, a successful REQUEST SENSE command returns GOOD status
> (with no autosense data); AND it returns a parameter data bufferthat
> happens to contain data that is in the format of sense data that
> describes the event (deferred error in your example).
> If the REQUEST SENSE command has a problem (an invalid field in the
> CDB for example), then the command will return an error status with
> autosense data that describes the problemwith the command (INVALID
> FIELD IN CDB). In this case, there is NO parameter data bufferto be
> returned, since the command failed. This is what 6.29 describes.
> Fred Knight
> *From:*Truong Nguyen - SISA [mailto:tru.nguyen at sisa.samsung.com]
> *Sent:* Monday, April 11, 2011 11:33 PM
> *To:* t10 at t10.org <mailto:t10 at t10.org>
> *Subject:* Request Sense Handling of Deferred Errors
> The Request Sense command definition in subclause 6.29 SPC4r30 states
> that the "device server shall return Check Condition status for a
> Request Sense command only to report exception conditions specific to
> the Request Sense command itself".
> Deferred errors may be indicated by returning Check Condition status
> as defined in subclause 4.5.5 in SPC4r30.
> In the event that the device server detects a deferred error
> condition, and then subsequently receives a Request Sense command,
> should the deferred error cause a Check Condition status to be
> returned for the Request Sense command? It would seem not, but some
> clarification would be appreciated.
> Truong Nguyen
> Samsung Information Systems America
* 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