parity handling

Gerry Houlder Gerry_Houlder at
Mon Feb 5 09:05:03 PST 1996

* From the SCSI Reflector, posted by:
* Gerry Houlder  <Gerry_Houlder at>
Tony's original message, with my replies added:

>Here's the scenario: 
>1. A Write Extended of 100 blocks. 
>2. Parity error occurs within one of the blocks transferred.
>Are the following responses valid?
>1. Stop committing blocks to media at the block before the block with the 
>error. Set sense data to 0xB47. Return Check Condition.

This is valid. Most devices do this because it is simplest.

>2. Target transitions to Message In phase upon detection of the Parity Error 
>issues Restore Pointers Message. Target/Initiator reties Information Transfer 

This is valid.  Remember that a restore pointers message will cause the 
transfer to
restart from the last save pointers message or the last disconnect/ reconnect
sequence, which result in retransmitting many blocks that have already been
successfully received and may already be written to media.

>3. Commit all blocks to media. Set sense data to 0xB47. Return Check 
>Since all the data was committed, including the block with the parity error, 
>not sure if the sense data is a valid response because 0xB47 represents 
>Command - SCSI Parity Error. 

WRONG! Writing a known bad block to media goes against all the rules of data 
The target may accept data after the parity error and may write it to media as 
long as
there are no parity (or any other) errors but is not required to. Initiator 
recovery routines
are supposed to assume that the bad block and all blocks after the bad block 
have not
been written to media. In fact, it is safer to re-write the blocks before the 
error as well,
because the interface parity error could cause the target device to stop 
writing as soon
as the error was detected. This could be many blocks before the LBA with the 
error, especially if Write Caching (or buffering for tapes) is enabled.

More information about the T10 mailing list