[T10] rule of Recovered error

[Harlan Andrews]

* From the T10 Reflector (t10 at t10.org), posted by:
* Harlan Andrews <handrews at apple.com>
*
Pat,

I'm more concerned about diagnostics.  As far as I know, the host DOES 
retry the entire command.  However, it's useful in the diagnostics to 
know the address of a REAL recovered error rather than simply the first 
block of the transfer.

I'm not proposing that partial retries are a good idea.  I simply want 
more meaningful error LBAs.  Locating the "true" address of the bad spot 
should NOT involve "searching" for it.  The whole point of the recovered 
error is to point out where the trouble was detected.

It seems that "device folk" are always trying to obfuscate errors.  Some 
seem to think a timeout is better than a reported error.  I find it 
particularly irksum that a read can take 30 seconds or more without 
completing.  If there's a non-recoverable error, then please report it.  
A timeout is worse.  For a timeout, the host has to attempt to "clean up" 
and needs to be very careful not to mess up other transfers or other 
drives.  Eventually the "streaming" commands should help.  But right now 
they're not well supported on device or host side.

I suppose I should be grateful that a recovered error was returned in the 
first place ;-)

However, your description of "deferred errors" is "massively unreal".  
You may translate "deferred error" to be identical to "corrupted data".  
In many systems, there simply is no way to recover.  The devices had 
BETTER NOT ALLOW DEFERRED ERRORS.

...Harlan


On 5/12/03 12:13 PM, Pat LaVarre wrote:

>Lost me, help?
>
 
>
Host folk are again trying to recover in ways other than retrying the 
>whole command?
>
 
>
That didn't work too well, last time we tried it, did it?  Seems like I 
>remember drives that thought that failing any Lba of the command was as 
>good as failing all that followed, and that reporting the failure of any 
>one CDB was as good as failing all that followed.  Those drives were 
>encouraged to behave this way by massively distributed hosts that wrongly 
>associated each deferred error with the command that dequeued it, and 
>failed nastily if too many deferred errors arrived in a burst.  The errors 
>were deferred because write-behind was on by default, and write-behind was 
>on by default because of massively distributed hosts that choked off bytes 
>per CDB somewhere near zero, down below even 0.1 MiB/CDB.
>
 
>
Me, I thought, when a drive reports an error, the host that really wants 
>to know how much of the written data is readable should go read & compare 
>the data.
>
 
>
But maybe in MMC 4 we're trying to say something else now, except only 
>for when Enhanced Defect Reporting is current?
>
 
>
Pat LaVarre
>

>
	-----Original Message----- 
>
	From: Harlan Andrews [mailto:handrews at apple.com] 
>
	Sent: Mon 5/12/2003 11:16 AM 
>
	To: keiji_katata at post.pioneer.co.jp; mtfuji5 at avc-pioneer.com 
>
	Cc: T10 at t10.org 
>
	Subject: Re: rule of Recovered error
>
	
>
	
>

>
	* From the T10 Reflector (t10 at t10.org), posted by:
>
	* Harlan Andrews <handrews at apple.com>
>
	*
>
	The recovered error should prompt a request sense by the host.  That
>
	request sense should report the address of a bad block.  It should NOT
>
	simply report the first block of the packet containing the recovered
>
	error.  In the case of multiple recovered blocks in the same packet, I
>
	would prefer to see the address of the first recovered error.  However,
>
	seeing only the last error from the packet is FAR better than seeing the
>
	first block of the packet which contains the bad block (when that block
>
	did not actually cause the recovered error).
>
	
>
	...Harlan
>
	
>
	
>
	On 5/8/03 9:58 PM, keiji_katata at post.pioneer.co.jp wrote:
>
	
>
	>* From the T10 Reflector (t10 at t10.org), posted by:
>
	>* keiji_katata at post.pioneer.co.jp
>
	>*
>
	>
>
	>Hello all,
>
	>
>
	>I find inappropriate expression in logical unit associated software defect
>
	>management section about Recovered error reporting.
>
	>
>
	>SCSI Block Commands - 2 (SBC-2) revision 8 (sbc2r08.pdf) says in page 13
>
	>(pdf 33/157), section "4.2.1.13 Error reporting" as follows:
>
	>
>
	>"When a recovered read error is reported, the INFORMATION field of the
>
	>sense data shall contain the logical block address of the last recovered
>
	>error during the trasfer."
>
	>
>
	>Multimedia Commands-4 (MMC-4) Revision 2 (mmc4r02.pdf) says page 101 (pdf
>
	>139/587), section "4.8.3.3  Error reporting control" as follows:
>
	>
>
	>"A RECOVERED ERROR only reports the first LBA of one Packet in the REQUEST
>
	>SENSE data."
>
	>
>
	>Same thing is in "7.3.3 Error reporting control" of Fuji5 document.
>
	>
>
	>I think MMC and Fuji shall have following sentence.
>
	>
>
	>"A RECOVERED ERROR only reports the LBA of one Packet that causes the last
>
	>recovered error during the data transfer in the INFORMATION field of the
>
	>REQUEST SENSE data ."
>
	>
>
	>Oh, sbc2r08.pdf has "trasfer". It may be "transfer"?
>
	>
>
	>Best regards,
>
	>
>
	>Keiji Katata
>
	>PIONEER CORP.
>
	>
>
	>
>
	>
>
	>
>
	>
>
	>*
>
	>* For T10 Reflector information, send a message with
>
	>* 'info t10' (no quotes) in the message body to majordomo at t10.org
>
	
>
	*
>
	* For T10 Reflector information, send a message with
>
	* 'info t10' (no quotes) in the message body to majordomo at t10.org
>
	
>

>

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org