Mark Lord wrote:
Mark Lord wrote:
..
Absolute theoretical worst case for a drive with a buffer 4X the largest
current size: 328 seconds. Not taking into account having bad-sector
retries for each of those I/O blocks, but *nobody* is going to wait
that long anyway. They'll have long since pulled the power cord or
reached for the BIG RED BUTTON.
..
Speaking of which.. these are all WRITEs.
In 18 years of IDE/ATA development,
I have *never* seen a hard disk drive report a WRITE error.
I have seen them in the wild.
Which makes sense, if you think about it -- it's rewriting the sector
with new ECC info, so it *should* succeed. The only case where it won't,
is if the sector has been marked as "bad" internally, and the drive is
too dumb to try anyways after it runs out of remap space.
In which case we've already lost data, and taking more than a hundred
and twenty seconds isn't going to make a serious difference.
You can definitely start failing writes once your remapped sector table is
exhausted, but to your point, that drive is usually in bad shape at this point
in time.
That makes it more important to fail quickly so that we don't hang waiting for
something that is most likely to be on its last legs...
Mmm.. anyone got a spare modern-ish drive to risk destroying?
Say, one of the few still-functioning DeathStars, or an buggy-NCQ Maxtor ?
If so, it might be fun to try and produce a no-more-remaps scenario on it.
One could use "hdparm --make-bad-sector" to corrupt a few hundred/thousand
sectors in a row (sequentially numbered).
I don't think that this will do it. What happens with our sector corruption, I
believe, is that we corrupt the data integrity bits around the sector. Once we
write, that original sector is repaired since the drive overwrites the junk bits
we gave it. The remapped sector count should not be growing (but it is worth
checking to verify my theory ;-)).
You have my blessing to be mean to a drive that you got from me if that helps ;-)
Then loop and attempt to read from them individually with "hdparm
--read-sector"
(should fail on all, but it might force the drive to remap them).
Again, I don't think that reads will ever force a remap.
Then finally try and write back to them with "hdparm --write-sector",
and see if a WRITE ERROR is ever reported. Maybe time the individual
WRITEs
to see if any of them take more than a few milliseconds.
Perhaps try this whole thing with/without the write cache enabled.
Mmm...
Cheers
ric
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
