Request Sense Handling of Deferred Errors

Ralph Weber roweber at IEEE.org
Tue Apr 12 15:39:55 PDT 2011


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
FWIW here is my reason for agreeing with George.
My problem is an ordered list that does not include a "do any vendor
specific thing the device server wants to do" entry. When such a list
is preceded by a 'shall' (as is true in this case), exactly where in
any of our standards do we document the implicit location of the
"vendor specific behavior" entry in our lists? (Please defer searching
until after reading the remainder of this message. There is no known
exit from an infinite loop.)
We picked an ordered list in this case because we wanted certainty
about what is done in what order. If vendor specific behaviors are
*assumed* to be allowed, why bother with the ordered list specificity?
Whine all you want. If your product returns deferred errors in the
REQUEST SENSE parameter data, you should be supporting a change in
this list. (I might even go so far as to claim that everyone who
defends the proposition that REQUEST SENSE command returning deferred
errors is codified between the lines in SPC-4 r30 is already in this
camp.)
My inclination would be to add a new entry between 4 and 5. If there
is enough passionate support for not returning deferred errors in
REQUEST SENSE parameter data, we might be able to weasel-word it
with a well-placed 'may'.
All the best,
.Ralph
On 4/12/2011 3:26 PM, Penokie, George wrote:
>
> Ralph is correct. The list does not include deferred errors, 
> therefore, if these was a deferred error then the parameter data would 
> containing sense data with the sense key set to NO SENSE and the 
> additional sense code set to NO ADDITIONAL SENSE INFORMATION as 
> defined in step 6. No amount of weasel wording is going to get around 
> that.
>
> It’s also clear that under no case will a deferred error cause a CC on 
> a REQUEST SENSE command.
>
> If you don’t like it the way it is then bring in a proposal to add 
> deferred errors into the list on page 373 and to add it that deferred 
> errors will now be cleared without reporting a CC.
>
> Bye for now,
> George Penokie
>
> LSI Corporation
> 3033 41st St. NW
> Suite 100
> Rochester, MN 55901
>
> 507-328-9017
> george.penokie at lsi.com
>
> *From:*owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of 
> *Ralph Weber
> *Sent:* Tuesday, April 12, 2011 2: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,
>
> .Ralph
>
> 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.
>
> Thanks,
>
> 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 mailing list