From: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
To: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Andreas Dilger <adilger@sun.com>, "Theodore Ts'o" <tytso@mit.edu>,
Jan Kara <jack@suse.cz>, Nick Piggin <npiggin@suse.de>,
dle-develop@lists.sourceforge.net,
Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>
Subject: Re: [PATCH] ext3: prevent reread after write IO error
Date: Thu, 14 Jan 2010 18:05:32 +0900 [thread overview]
Message-ID: <4B4EDE5C.8040600@hitachi.com> (raw)
In-Reply-To: <4B4EB5B9.4020809@hitachi.com>
Hi,
Hidehiro Kawai wrote:
> This patch fixes the similar bug fixed by commit 95450f5a.
>
> If a directory is modified, its data block is journaled as metadata
> and finally written back to the right place. Now, we assume a
> transient write erorr happens on that writeback. Uptodate flag of
> the buffer is cleared by write error, so next access on the buffer
> causes a reread from disk. This means it breaks the filesystems
> consistency.
After sending this patch, I noticed that I have to deal with
the bh_uptodate_or_lock() case as well. Actually, I confirmed
a data block sharing happens between two inodes. Allocate a new
block, then modified bitmap goes to the fs, but it fails due to
a transient IO error. Next access on the bitmap buffer cause a
reread from disk. As a result, the allocated block becomes
a FREE block! So this block can be shared by different two inodes.
I'll send the revised version later.
Thanks,
--
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center
next prev parent reply other threads:[~2010-01-14 9:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 6:12 [PATCH] ext3: prevent reread after write IO error Hidehiro Kawai
2010-01-14 9:05 ` Hidehiro Kawai [this message]
2010-01-14 10:14 ` [PATCH] ext3: prevent reread after write IO error v2 Hidehiro Kawai
2010-01-14 14:18 ` Jan Kara
2010-01-15 10:38 ` Hidehiro Kawai
2010-01-18 5:18 ` Nick Piggin
2010-01-18 6:05 ` IO error semantics Nick Piggin
2010-01-18 12:24 ` Dave Chinner
2010-01-18 14:00 ` Nick Piggin
2010-01-18 22:51 ` Dave Chinner
2010-01-18 23:33 ` Anton Altaparmakov
2010-01-18 23:33 ` Anton Altaparmakov
2010-01-25 15:23 ` Ric Wheeler
2010-01-25 15:23 ` Ric Wheeler
2010-01-25 16:15 ` Greg Freemyer
2010-01-25 16:15 ` Greg Freemyer
2010-01-25 17:47 ` tytso
2010-01-25 17:50 ` Ric Wheeler
2010-01-25 17:50 ` Ric Wheeler
2010-01-25 17:59 ` Nick Piggin
2010-01-25 17:50 ` Ric Wheeler
2010-01-25 17:55 ` Nick Piggin
2010-01-25 17:55 ` Nick Piggin
2010-01-26 6:19 ` Dave Chinner
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=4B4EDE5C.8040600@hitachi.com \
--to=hidehiro.kawai.ez@hitachi.com \
--cc=adilger@sun.com \
--cc=akpm@linux-foundation.org \
--cc=dle-develop@lists.sourceforge.net \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=satoshi.oshima.fk@hitachi.com \
--cc=tytso@mit.edu \
/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.