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