Salyzyn, Mark wrote:
From: Douglas Gilbert [mailto:[EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
