Messages in this thread | | | From | Bill Davidsen <> | Subject | Re: Driver retries disk errors. | Date | Wed, 01 Sep 2004 11:18:30 -0400 |
| |
Alan Cox wrote: > On Maw, 2004-08-31 at 18:00, Erik Mouw wrote: > >>>For non hard disk cases many devices do want and need retry. >> >>And many others do not. CompactFlash readers are usually implemented as >>a USB storage device, which on its turn is implemented as a SCSI >>"disk". So far I haven't seen a CompactFlash which could be "fixed" by >>retries. > > > It does no harm trying. It does real harm not being conservative and > losing peoples data. You recover people's data after its lost, the > IDE layer's job is to make sure it doesn't get lost in the first place. > > >>(1) Imagine an application doing a linear read on a file with an 8 >>block read ahead and the last block being bad. The kernel will try to >>read that bad block 16 times, but because the IDE driver also has 8 >>retries, the kernel will try to read that bad block *64* times. It >>usually takes an IDE drive about 2 seconds to figure out a block is >>bad, so the application gets stuck for 2 minutes in that single bad >>block. > > > Right now I know of no way to tell which is readahead for a failed > command or of telling the block layer to forget them. Fix this at the > block layer and IDE can abort the readahead sequence happily enough > because IDE is too dumb to have issued further commands to the drive at > this point.
If would probably be good to retry "read what you were asked, nothing more" on error, to avoid passing back errors caused by readahead. I suspect this would avoid some issues reading data off CD as well, where one software can read clean and another ends with a short image and error.
-- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |