All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <wfg@mail.ustc.edu.cn>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Ingo Oeser <ioe-lkml@rameria.de>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>
Subject: Re: [PATCH 4/5] readahead: backoff on I/O error
Date: Mon, 12 Jun 2006 09:12:45 +0800	[thread overview]
Message-ID: <350074764.23563@ustc.edu.cn> (raw)
Message-ID: <20060612011245.GA5214@mail.ustc.edu.cn> (raw)
In-Reply-To: <448B221D.3080907@tls.msk.ru>

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

  reply	other threads:[~2006-06-12  1:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-09  8:08 [PATCH 0/5] Adaptive readahead updates 2 Wu Fengguang
2006-06-09  8:08 ` Wu Fengguang
2006-06-09  8:08 ` [PATCH 1/5] readahead: no RA_FLAG_EOF on single page file Wu Fengguang
2006-06-09  8:08   ` Wu Fengguang
2006-06-09  8:08 ` [PATCH 3/5] readahead: call scheme - no fastcall for readahead_cache_hit() Wu Fengguang
2006-06-09  8:08   ` Wu Fengguang
2006-06-09  8:08 ` [PATCH 4/5] readahead: backoff on I/O error Wu Fengguang
2006-06-09  8:08   ` Wu Fengguang
2006-06-10 18:33     ` Ingo Oeser
2006-06-10 19:48       ` Michael Tokarev
2006-06-12  1:12         ` Wu Fengguang [this message]
2006-06-12  1:12           ` Wu Fengguang
2006-06-12  3:43             ` Andrew Morton
2006-06-12 11:06             ` Michael Tokarev
2006-06-17  6:38               ` Michael Tokarev
2006-06-17  7:00                 ` Michael Tokarev
2006-06-09  8:08 ` [PATCH 5/5] readahead: remove size limit on read_ahead_kb Wu Fengguang
2006-06-09  8:08   ` Wu Fengguang
  -- strict thread matches above, loose matches on Subject: below --
2006-06-11  5:34 [PATCH 4/5] readahead: backoff on I/O error Just Marc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=350074764.23563@ustc.edu.cn \
    --to=wfg@mail.ustc.edu.cn \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=ioe-lkml@rameria.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.