12-402 feedback

[Kevin D Butt]

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

Gerry,
While there may be a new code, this proposal requires existing software to 
be modified.  That is not something that IBM wants to sign up for.
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/ 
From:	Gerry Houlder <gerry.houlder at seagate.com>
To:	Kevin D Butt/Tucson/IBM at IBMUS, 
Cc:	T10 Reflector <t10 at t10.org>
Date:	11/01/2012 11:32 AM
Subject:	Re: 12-402 feedback
I agree with the need for that distinction. That is why there is a new 
REASSIGN STATUS code value to distinguish foreground unrecovered errors 
|from background unrecovered errors. I did not bother to add other code 
values to distinguish foreground recovered errors because once they are 
recovered there is no further action required of a host and the issue 
becomes moot.
Also keep in mind that all foreground recovered errors are supposed to be 
reported to the host as either a current error (the CHECK CONDITION status 
is returned on the command with the unrecovered error) or a deferred 
error. Adding foreground unrecovered errors to this list provides a 
convenience to the host in that there is only on place that has to be 
examined to find all of the unrecovered error sites that the device server 
knows about, regardless of how the errors were detected.
I do concede that there might be different categories of foreground 
unrecovered errors that could be accounted for. This would suggest the 
possible need for two or more REASSIGN STATUS codes to distinguish 
different foreground error sources. I am open to suggestions for such 
additional categories but don't see any useful distinctions at the moment.
On Thu, Nov 1, 2012 at 12:48 PM, Kevin D Butt <kdbutt at us.ibm.com> wrote:
Gerry, 
IBM has reviewed proposal 12-402r0.  While the goal of being able to 
report other errors seems good, we believe that it would better be 
accomplished by using a different page for non-background errors (e.g., 
SCSI Foreground Media Errors log page) and leave the existing background 
error page alone.  We believe it is important to be able to distinguish an 
error between background and foreground operations. 
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/