reading blocks prior to a medium error

Penokie, George George.Penokie at lsi.com
Mon Dec 27 06:25:13 PST 2010


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

This whole issue is about UNRECOVERED read errors not RECOVERED read errors.
All the read data is valid when there is a RECOVERED read error.
The wording in SAM that states " While some valid data may be present for
other values of status, the application client should rely on additional
information from the logical unit (e.g., sense data) to determine the state
of the buffer contents." allows this.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
-----Original Message-----
From: Douglas Gilbert [mailto:dgilbert at interlog.com]
Sent: Wednesday, December 22, 2010 9:52 PM
To: Penokie, George
Cc: T10 Reflector (t10 at t10.org)
Subject: Re: reading blocks prior to a medium error
Good to read that the SAM-5 document addresses this issue.
Pity that it makes such an equivocal statement.
Linux is probably not the only OS that will accept the data-in
buffer from a READ when the status is CHECK CONDITION and
the sense key is RECOVERED ERROR. After all that sense key
is defined (in SPC-4) as indicating "that the command has
completely successfully". That also seems to be in keeping
with the SAM-5 section quoted below: "While some valid data
may be present for other values of status, the application
client should rely on additional information from the logical
unit (e.g., sense data) to determine the state of the buffer
contents."
Perhaps some words in SBC-3, even weasel words, might be
appropriate in the unrecovered error case.
In Linux we intend to address the issue of blocks prior
to a medium error by examining the number of bytes read
into the data-in buffer by the DMA unit in the initiator.
The Execute Command procedure call in SAM-5 section 5.1
(rev 5) seems to be incomplete in this regard. The Data-in
buffer and the Sense data are structurally similar. IMO
both should have a "maximum number of bytes" input argument
and an "actual number of bytes received" output argument.
If the transport does not report the number of bytes
actually received, then something else in the initiator
should work that out.
Douglas Gilbert
On 10-12-15 03:28 PM, Penokie, George wrote:
> This very topic was talked about in the last SCSI standards meeting in
November. The minutes from that discussion state:
>
> 5.2.7 SBC-3: Read data transferred on unrecovered error (yes-no-maybe?)
[Penokie]
>
> George Penokie asked the group to consider whether the contents of the
Data-in Buffer are valid when an unrecovered error is reported. The group
suggested that George read the definition of the Data-in Buffer in subclause
5.1
> of SAM-5.
>
> George asked that this topic be removed from future agendas.
>
>
> The wording being referenced in the minutes is:
>
> Data-In Buffer: A buffer (see 5.4.3) to contain command specific
information returned by the logical unit by the time of command completion.
The Execute Command procedure call shall not return a GOOD status or
CONDITION MET status unless the buffer contents are valid. The application
client shall treat the buffer contents as invalid unless Execute Command
procedure call returns a GOOD status or CONDITION MET status. While some
valid data may be present for other values of status, the application client
should rely on additional information from the logical unit (e.g., sense
data) to determine the state of the buffer contents. If the command
terminates with a service response of SERVICE DELIVERY OR TARGET FAILURE, the
application client shall consider the buffer to be undefined
>
> The net of all that is that no data from a read command should be
considered valid unless the command is successful.
>
> Bye for now,
> George Penokie
>
> LSI Corporation
> 3033 41st St. NW
> Suite 100
> Rochester, MN 55901
>
> 507-328-9017
> george.penokie at lsi.com
>
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Douglas
Gilbert
> Sent: Wednesday, December 15, 2010 11:29 AM
> Subject: sbc: reading blocks prior to a medium error
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Douglas Gilbert<dgilbert at interlog.com>
> *
> When the TB bit is set in the Read-Write Error
> Recovery mode page section 6.4.7 of sbc3r25.pdf
> seems to imply that the good logical blocks
> read prior to the unrecovered error will be
> placed in the data-in buffer.
>
> The TB bit only applies to the lowest numbered
> LBA with an unrecovered error that is being read.
> It seems counter intuitive to place that logical
> block in the data-in buffer and not the good blocks
> that precede it.
>
> But I can't see the words that imply that the good
> logical blocks prior to the unrecovered error will
> be placed in the data-in buffer when the TB bit is
> clear. Is this guaranteed?
>
> Douglas Gilbert
>
> *
> * 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