[T10] rule of Recovered error

[Pat LaVarre]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
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