Re: [PATCHSET #upstream] libata: improve FLUSH error handling

[Mark Lord <liml@rtr.ca>]

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.

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.

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).

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).

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