parity handling

Mark Heath Mark_Heath at notes.seagate.com
Tue Feb 6 04:47:02 PST 1996


* From the SCSI Reflector, posted by:
* Mark Heath <Mark_Heath at notes.seagate.com>
*
Pat LaVarre wrote:

>... but I thought that technically
>initiators were required to assume CORRUPT -
>possibly written, possibly not, possibly
>scrambled beyond ECC recovery - every LBA
>addressed by the transfer?
>
>For example, if the host sees a check
>condition on a write of x100 blocks to LBA
>x123, blocks x123 .. x222 may be corrupt?
>
>Exception:  If the info field of the sense
>data is flagged valid, the LBAs preceding
>the info LBA were written OK.

I agree with the first statement quoted above, but I disagree with the 
exception.  When the FSW (Mode Page 8, byte 12, bit 7) is zero, the target may 
write blocks to the media in any order it desires.  Thus, LBAs preceding the 
LBA reported in the sense data info field may not have been written to the 
media in the case of an error.  From SBC Rev. 1, section 7.1.3.1:

"The Force Sequential Write (FSW) bit when set to one, indicates that multiple 
block writes are to be transferred over the SCSI bus and written to the media 
in an ascending, sequential, logical block order.  When the FSW bit equals 
zero, the device server is allowed to reorder the sequence of writing addressed 
logical blocks in order to achieve a faster command completion."

Of course, for the specific case of a parity error, the target probably won't 
receive the data for LBAs beyond the one in which the parity error was 
detected, so the target won't be able to modify the media for subsequent LBAs.  
However, it seems like the simplest (and safest) form of error recovery for an 
initiator is to make absolutely no assumptions about which LBAs were or were 
not modified for a write command that terminated in error, regardless of the 
type of error.





More information about the T10 mailing list