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: linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>
Subject: Re: [PATCH 00/32] Adaptive readahead V14
Date: Mon, 29 May 2006 11:01:53 +0800	[thread overview]
Message-ID: <348871711.21712@ustc.edu.cn> (raw)
Message-ID: <20060529030152.GA5994@mail.ustc.edu.cn> (raw)
In-Reply-To: <4479F8B5.90906@tls.msk.ru>

On Sun, May 28, 2006 at 11:23:33PM +0400, Michael Tokarev wrote:
> Wu Fengguang wrote:
> > 
> > It's not quite reasonable for readahead to worry about media errors.
> > If the media fails, fix it. Or it will hurt read sooner or later.
> 
> Well... In reality, it is just the opposite.
> 
> Suppose there's a CD-rom with a scratch/etc, one sector is unreadable.
> In order to "fix" it, one have to read it and write to another CD-rom,
> or something.. or just ignore the error (if it's just a skip in a video
> stream).  Let's assume the unreadable block is number U.
> 
> But current behavior is just insane.  An application requests block
> number N, which is before U. Kernel tries to read-ahead blocks N..U.
> Cdrom drive tries to read it, re-read it.. for some time.  Finally,
> when all the N..U-1 blocks are read, kernel returns block number N
> (as requested) to an application, successefully.
> 
> Now an app requests block number N+1, and kernel tries to read
> blocks N+1..U+1.  Retrying again as in previous step.
> 
> And so on, up to when an app requests block number U-1.  And when,
> finally, it requests block U, it receives read error.
> 
> So, kernel currentry tries to re-read the same failing block as
> many times as the current readahead value (256 (times?) by default).

Good insight... But I'm not sure about it.

Jens, will a bad sector cause the _whole_ request to fail?
Or only the page that contains the bad sector?

> This whole process already killed my cdrom drive (I posted about it
> to LKML several months ago) - literally, the drive has fried, and
> does not work anymore.  Ofcourse that problem was a bug in firmware
> (or whatever) of the drive *too*, but.. main problem with that is
> current readahead logic as described above.
> 
> With that logic, an app also becomes unkillable (at least for some
> time) -- ie, even when I knew something's wrong and the CDrom should
> not behave like it was, I wasn't able to stop it until I powered the
> machine off (just unplugged the power cable) - but.. too late.
> 
> Yes, bad media is just that - a bad thing.  But it's not a reason to
> force power unplug to stop the process, and not a reason to burn a
> drive (or anything else).  And this is where readahead comes into
> play - it IS read-ahead logic who's responsible for the situation.
> 
> And there's alot of scratched/whatever CD-Rom drives out there -
> unreadable CDrom (or a floppy which is already ancient, or some
> other media) - you can't just say to every user out there that
> linux isn't compatible with all people's stuff and those people
> should "fix" it before ever trying to insert it into their linux
> machine...
> 
> Thanks.
> 
> /mjt

  reply	other threads:[~2006-05-29  3:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-27 15:48 [PATCH 00/32] Adaptive readahead V14 Wu Fengguang
2006-05-27 15:48 ` Wu Fengguang
2006-05-27 17:29   ` Michael Tokarev
2006-05-28 12:08     ` Wu Fengguang
2006-05-28 12:08       ` Wu Fengguang
2006-05-28 19:23         ` Michael Tokarev
2006-05-29  3:01           ` Wu Fengguang [this message]
2006-05-29  3:01             ` Wu Fengguang
2006-05-30  9:23             ` Jens Axboe
2006-05-30 11:32               ` Wu Fengguang
2006-05-30 11:32                 ` Wu Fengguang
2006-05-30 12:29                 ` Jens Axboe
2006-05-30 14:34                   ` Wu Fengguang
2006-05-30 14:34                     ` Wu Fengguang
2006-05-27 15:48 ` [PATCH 01/32] readahead: kconfig options Wu Fengguang
2006-05-27 15:48   ` Wu Fengguang
2006-05-27 15:48 ` [PATCH 04/32] mm: introduce PG_readahead Wu Fengguang
2006-05-27 15:48   ` Wu Fengguang
2006-05-27 15:48 ` [PATCH 06/32] readahead: delay page release in do_generic_mapping_read() Wu Fengguang
2006-05-27 15:48   ` Wu Fengguang
2006-05-27 15:48 ` [PATCH 07/32] readahead: insert cond_resched() calls Wu Fengguang
2006-05-27 15:48   ` Wu Fengguang
2006-05-27 15:48 ` [PATCH 08/32] readahead: {MIN,MAX}_RA_PAGES Wu Fengguang
2006-05-27 15:48   ` Wu Fengguang
2006-05-27 15:48 ` [PATCH 09/32] readahead: events accounting Wu Fengguang
2006-05-27 15:48   ` Wu Fengguang
2006-05-27 15:48 ` [PATCH 10/32] readahead: rescue_pages() Wu Fengguang
2006-05-27 15:48   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 11/32] readahead: sysctl parameters Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 14/32] readahead: state based method - routines Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 15/32] readahead: state based method Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 18/32] readahead: initial method - thrashing guard size Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 20/32] readahead: initial method - user recommended size Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 22/32] readahead: backward prefetching method Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 24/32] readahead: thrashing recovery method Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 22:04     ` [PATCH 23/32] readahead: seeking reads method Ingo Oeser
2006-05-27 15:49 ` [PATCH 25/32] readahead: call scheme Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 26/32] readahead: laptop mode Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 27/32] readahead: loop case Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 30/32] readahead: debug radix tree new functions Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 31/32] readahead: debug traces showing accessed file names Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang
2006-05-27 15:49 ` [PATCH 32/32] readahead: debug traces showing read patterns Wu Fengguang
2006-05-27 15:49   ` Wu Fengguang

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=348871711.21712@ustc.edu.cn \
    --to=wfg@mail.ustc.edu.cn \
    --cc=axboe@suse.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.