Request Sense Handling of Deferred Errors

Knight, Frederick Frederick.Knight at netapp.com
Wed Apr 13 08:11:52 PDT 2011


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

We all agree on this.  We all agree that deferred error shall NOT cause
a CC on a REQUEST SENSE command.
The clarification I understood to be requested was in the ordered list
for what data is returned in the parameter data of the REQUEST SENSE
command.  There is no item for deferred error in that list.  The older
format (used in SPC-2) DOES include deferred errors in the text for the
REQUEST SENSE command, so it appears this was inadvertently dropped when
the text was moved from the REQUEST SENSE command description into the
model clause sections we have today.
Note the following sentence from SPC-2: "A subsequent REQUEST SENSE
command shall return the deferred error sense information."
Therefore, I support returning deferred error to being specifically
listed as an item returned in REQUEST SENSE parameter data.
As for old, the text I cited - "if the recovered error occurs during the
processing of the REQUEST SENSE command" occurs as far back as SPC-2
(I'd call that old).  A lot of the text has been reworked, but that
sentence is old.
		Fred
From: Penokie, George [mailto:George.Penokie at lsi.com] 
Sent: Tuesday, April 12, 2011 7:00 PM
To: Mark Evans; Knight, Frederick; Ralph Weber; t10 at t10.org
Subject: RE: Request Sense Handling of Deferred Errors
I do not agree, The wording in the REQUEST SENSE command is very clear
about what conditions cause it to CC and there is nothing about deferred
errors. And there is no way a deferred error  can be considered an
'exception condition specific to the REQUEST SENSE command itself'.
>From SPC:
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.
Examples of conditions that cause a
REQUEST SENSE command to return CHECK CONDITION status are:
a) an invalid field value is detected in the CDB;
b) the device server does not support the REQUEST SENSE command (see
4.3.1);
c) the initiator port that sent the REQUEST SENSE command is pending
enrollment for access controls (see
8.3.1.7) and no other sense data is available to return;
d) an unrecovered error is detected by a SCSI target port; or
e) a malfunction prevents return of the sense data.
There no clarification needed, If you want to add deferred errors as
something that can be returned in the REQUEST SENSE commands parameter
data then write a proposal and quit trying to read words that are not
there. 
Also, the REQUEST SENSE wording in not old. Most of thing we are talking
about where put into SPC-4 at revision 25.
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: Mark Evans [mailto:Mark.Evans at wdc.com] 
Sent: Tuesday, April 12, 2011 5:45 PM
To: Knight, Frederick; Ralph Weber; t10 at t10.org
Cc: Penokie, George
Subject: RE: Request Sense Handling of Deferred Errors
Hello all,
I agree with Fred.  I read all of the same material he cited but didn't
include any of it in my first response.  The way I read it, it is within
the definitions in the standard for a device server to return deferred
error sense data in the response data for a REQUEST SENSE command.
I am not opposed to a proposal to clarify that this is the case, but I
don't think it's necessary.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff. 
Regards, 
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight,
Frederick
Sent: Tuesday, April 12, 2011 3:03 PM
To: Ralph Weber; t10 at t10.org
Subject: RE: Request Sense Handling of Deferred Errors
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".
I'm not quite sure how that happens?  I think I understand what detected
during the processing of the R_S command is, but I don't 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 may be 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 terminates with 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 return a deferred error according to
the following rules:
b) ...then a deferred error indication shall be returned for a command
received...
c) ... shall return a deferred error for one command received...
d) ... 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.
		Fred
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,
.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] On Behalf Of Knight,
Frederick
Sent: Tuesday, April 12, 2011 6:10 AM
To: Truong Nguyen - SISA; 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
client in the same I_T_L_Q nexus transaction (see 3.1.67) as the status
or as parameter data in response to
a REQUEST SENSE command (see 6.29). The format of sense data is defined
in 4.5.
The RED text is the first (autosense), the GREEN text 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 buffer that is returned will contain sense
data that describes the deferred error.  The autosense data associated
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 buffer that 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 problem with the command (INVALID
FIELD IN CDB).	In this case, there is NO parameter data buffer to 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
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



More information about the T10 mailing list