Re: Disk Errors

[Douglas Gilbert <dougg@torque.net>]

Salyzyn, Mark wrote:
> From: Douglas Gilbert [mailto:dougg@torque.net] writes:
> 
>>All may not be lost. If a medium error occurs and the ASC and
>>ASCQ imply the sector could be read but
>>failed ECC then the READ LONG SCSI command should fetch the
>>block (plus ECC and other data). For example a Fujitsu MAM3184
>>returns 576 bytes. It is probably too much to expect that all
>>the damage will be in the last 64 bytes.
> 
> 
> However, the drive has taken whatever action it could to reconstruct the
> data, the failure to report the block for a standard read means that the
> data is in fact `lost'. The data+ECC combination must be in a state
> where there are more bits of damage than the error correction can deal
> with; 64 bytes of ECC deals with single bit errors thus we know that we
> have more than 1 bit of damage to the disk. We could have 4096 bits of
> damage in the worst case :-) and never know that fact.
> 
> If I wanted in desperation to recover whatever data I could, this would
> be grand, but as it stands, from the Linux File System Driver
> perspective, it would be dangerous to accept this block as anything more
> than it is.
> 
> If the data is of the form to permit some loss, for example video, audio
> content or an error correcting stream of data, someone can make a case
> where READ_LONG is an appropriate action to take to help fill in missing
> content. 
> 
> A fun thought ...

Mark,
I will try extending sg_dd in sg3_utils to do this
when its "continue on error" flag is set. It could
return additional counts of dubious blocks as well as
completely lost ones.

If that is useful then perhaps sd could be extended.

Doug Gilbert