Gerry_Houlder at notes.seagate.com
Mon Feb 5 09:05:03 PST 1996
* From the SCSI Reflector, posted by:
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
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
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
there are no parity (or any other) errors but is not required to. Initiator
are supposed to assume that the bad block and all blocks after the bad block
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