Late SPC-4 Letter Ballot comment request

Kevin D Butt kdbutt at us.ibm.com
Fri Dec 14 12:49:11 PST 2012


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

No, I have not prepared a proposal.  If there is opposition to the concept 
then I won't waste time preparing a proposal.  If the late letter ballot 
comment is accepted then I'll write a proposal for review.
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:	T10 Reflector <t10 at t10.org>, 
Date:	12/13/2012 08:21 AM
Subject:	Re: Late SPC-4 Letter Ballot comment request
Sent by:	owner-t10 at t10.org
It is unclear how your new requirements should be inserted into the quoted 
text. Have you prepared a proposal for this?
On Wed, Dec 12, 2012 at 5:48 PM, Kevin D Butt <kdbutt at us.ibm.com> wrote:
IBM would like to request a late letter ballot comment against SPC-4 to 
consider an additional way to indicate when an Error history snapshot is 
lost.  The following text highlights what is currently stated about error 
history snapshots, their persistent requirements, how to report a loss of 
a snapshot or error history I_T nexus, and that there may be vendor 
specific methods to retrieve error history. 
It is well known that Unit Attentions are often swallowed by application 
client stacks before the application has a chance to see them.	For this 
reason, having a Check Condition instead of a UA is preferable, at least 
in some environments.  Also, error history may be retrieved by vendor 
specific methods or other READ BUFFER command sequences.  The size of the 
error history buffers in some implementations could be such that these 
other methods would have to share these error history buffers.	Or other 
vendor specific requirements may force a release of the error history 
snapshot.  Currently, this would be a violation of the standard. 
We would like to allow vendor specific events in addition to the timer to 
cause a release of the snapshot.  We would also like to report this 
through a Check Condition, ILLEGAL REQUEST, ERROR HISTORY SNAPSHOT 
RELEASED on a subsequent READ BUFFER with mode 1Ch. 
<< 
5.5.2 Retrieving error history with the READ BUFFER command 
The device server shall not replace or release the error history snapshot 
while the error history I_T nexus is established. 
The device server shall implement a vendor specific timer for error 
history snapshot retrieval. If the vendor specific timer expires, then: 
  a) the device server shall: 
    A) clear the error history I_T nexus; and 
    B) establish a unit attention condition for the error history I_T 
nexus with the additional sense code set to ERROR HISTORY I_T NEXUS 
CLEARED; 
  or 
  b) the device server shall: 
    A) clear the error history I_T nexus; 
    B) release the error history snapshot; and 
    C) establish a unit attention condition for the error history I_T 
nexus with the additional sense code set to ERROR HISTORY SNAPSHOT 
RELEASED. 
Error history may also be retrieved by vendor specific methods or other 
READ BUFFER command sequences that are outside the scope of this standard. 
>> 
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