From: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
Andrew Morton <akpm@linux-foundation.org>,
sct@redhat.com, adilger@sun.com, linux-kernel@vger.kernel.org,
linux-ext4@vger.kernel.org, jack@suse.cz,
sugita <yumiko.sugita.yf@hitachi.com>,
Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>
Subject: Re: [RFC][PATCH] ext3: don't read inode block if the buffer has a write error
Date: Tue, 24 Jun 2008 22:03:56 +0900 [thread overview]
Message-ID: <4860F0BC.1090404@hitachi.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0806232039300.2926@woody.linux-foundation.org>
Hi all,
Thank you for precious comments.
Linus Torvalds wrote:
>
> On Tue, 24 Jun 2008, Nick Piggin wrote:
>
>>What you want to do is not insane, but the way it is currently being
>>done is. As I said, just clearing the uptodate bit might blow up your
>>kernel pretty quickly from assertions in the vm. It should be going
>>through the whole truncate or invalidate page machinery in order to
>>do that.
>
> Fair enough.
>
> I would not mind, for example, leaving the uptodate bit, but removing it
> from the radix tree or something like that (ie turning it into an
> anonymous page for a page-cache page, just removing it from the
> hash-queues for a buffer_head).
If we move page caches with errors to another radix tree instead of
just removing, we may be able to do special handlings: rewrite once,
or check the page caches and get rid of them from user space, and so on.
> Of course, that could cause other problems (eg any VM assertions that
> shared mappings only contain non-anon pages).
As Jan and Nick stated, this seems to need a great effort, but I think
it is worthwhile to do.
Thanks,
--
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center
prev parent reply other threads:[~2008-06-24 13:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 11:25 [RFC][PATCH] ext3: don't read inode block if the buffer has a write error Hidehiro Kawai
2008-06-23 11:46 ` Nick Piggin
2008-06-23 12:31 ` Jan Kara
2008-06-23 12:36 ` Nick Piggin
2008-06-24 2:17 ` Andrew Morton
2008-06-24 3:01 ` Linus Torvalds
2008-06-24 3:17 ` Nick Piggin
2008-06-24 3:42 ` Linus Torvalds
2008-06-24 13:03 ` Hidehiro Kawai [this message]
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=4860F0BC.1090404@hitachi.com \
--to=hidehiro.kawai.ez@hitachi.com \
--cc=adilger@sun.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=satoshi.oshima.fk@hitachi.com \
--cc=sct@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=yumiko.sugita.yf@hitachi.com \
/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.