From: Michael Tokarev <mjt@tls.msk.ru>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Wu Fengguang <wfg@mail.ustc.edu.cn>,
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: Sat, 17 Jun 2006 11:00:50 +0400 [thread overview]
Message-ID: <4493A8A2.9040505@tls.msk.ru> (raw)
In-Reply-To: <4493A354.4020602@tls.msk.ru>
Michael Tokarev wrote:
> Michael Tokarev wrote:
[]
> .....alot of similar errors skipped, with consequtive block numbers.
> At this point (10:18), I hit Ctrl+C on the xterm where dd was running...
[]
> And finally here we go: the new logic triggered. And the dd command
> unfroze as well (reacted to the interrupt).
[]
> So finally.. it looks like the whole thing is somewhere else still.
> The last batch of messages shows exactly the previous behaviour
> (numerous attempts to read quite alot of failing sectors, which
> takes quite some time too - depending on the CD-ROM drive alot),
> BEFORE the new RA-reducing logic gets triggered.
I forgot to add: when turning RA off for the device before reading
the disk, read errors are propagated to the application quickly,
without those long delays and attempts to read all the bad blocks.
Ofcourse (with conv=noerror), dd will request next blocks anyway,
but it stays responsive still, and reports each error quickly.
The patch helps still: after first batch of attempts to read,
RA gets reduced, when follows next (much smaller) batch, and
finally RA is set to 0, and the above 'quick route' (as if
RA was turned off initially) takes effect.
/mjt
next prev parent reply other threads:[~2006-06-17 7:00 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
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 [this message]
[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=4493A8A2.9040505@tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=ioe-lkml@rameria.de \
--cc=linux-kernel@vger.kernel.org \
--cc=wfg@mail.ustc.edu.cn \
/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