public inbox for linux-kernel@vger.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
     [not found] <20060609080801.741901069@localhost.localdomain>
2006-06-09  8:08 ` [PATCH 0/5] Adaptive readahead updates 2 Wu Fengguang
     [not found] ` <20060609081119.231751179@localhost.localdomain>
2006-06-09  8:08   ` [PATCH 1/5] readahead: no RA_FLAG_EOF on single page file Wu Fengguang
     [not found] ` <20060609081120.054527393@localhost.localdomain>
2006-06-09  8:08   ` [PATCH 3/5] readahead: call scheme - no fastcall for readahead_cache_hit() Wu Fengguang
     [not found] ` <20060609081120.531013274@localhost.localdomain>
2006-06-09  8:08   ` [PATCH 4/5] readahead: backoff on I/O error Wu Fengguang
2006-06-10 18:33     ` Ingo Oeser
2006-06-10 19:48       ` Michael Tokarev
     [not found]         ` <20060612011245.GA5214@mail.ustc.edu.cn>
2006-06-12  1:12           ` Wu Fengguang [this message]
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
     [not found] ` <20060609081121.002572642@localhost.localdomain>
2006-06-09  8:08   ` [PATCH 5/5] readahead: remove size limit on read_ahead_kb Wu Fengguang
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox