Re: [PATCH 4/5] readahead: backoff on I/O error

Wu Fengguang
2006-06-12T01:12:51Z

Hi Ingo and Michael,

On Sat, Jun 10, 2006 at 11:48:45PM +0400, Michael Tokarev wrote:
> Ingo Oeser wrote:
> >> Backoff readahead size exponentially on I/O error.
> >
> >> With this patch, retries are expected to be reduced from, say, 256, to 5.
> >
> > 1. Would you mind to push this patch to -stable?
> >
> > Reason: If killing a drive was hit in the field, this should be critical
> > enough.
>

Andrew:
I was a bit afraid about that because I have no CDROM to try it out.
But since Michael has tested it OK, it should be OK for the stable kernel.

> > 2. Could you disable (at least optionally) read ahead complety
> > on the first IO error?
> >
> > Reason: In a data recovery situation (hitting EIO quite often,
> > but not really sequentially) readahead is counter productive.
> > E.g. trying to save an old CD with the cdparanoia software.

Should be ok. I have no experience on it. So Michael and users with
the taste have the last word :)

It might also be helpful to generate some uevent for it. User land
tools can then run blockdev --setra in a configurable way.

> I'm thinking about all this again.. well. Read-ahead is definitely
> very useful on a CD (I'm referring to all optical media here, be it
> DVD, or BlueRay, or whatever; floppies too, but there it's less useful
> due to speed of the whole thing) - I mean, say, DVDs are played more
> smoothly if readahead is enabled; a "live CD" distro will be more
> responsive if readahead is enabled, and so on - the effect of RA is
> trivially visible.
>
> But still, for a scratched CD, it might be a good idea to turn RA off
> while playing it, completely - by means of, eg, blockdev --setra 0,
> or something like that. Yes not many (end)users know this tool, yes
> it's privileged (oh well), but it helps.
>
> Why I recall --setra is: when kernel will start reducing RA by its
> own, next question will be "why my CD is too slow?" -- after playing
> a scratched CD, you insert another one, and RA is *still* zero...
>
> So I'm not really sure how simple the solution should be.

The patch operates on a per-fd basis. Thus the readahead size will not
be affected for other files and CDs. The readahead size also restores
on reopening the file :)

Thanks,
Wu