All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
To: Jan Kara <jack@suse.cz>
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>,
	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 v2
Date: Fri, 15 Jan 2010 19:38:38 +0900	[thread overview]
Message-ID: <4B5045AE.9080604@hitachi.com> (raw)
In-Reply-To: <20100114141803.GB3146@quack.suse.cz>

Jan Kara wrote:

>>By the way, I think the right fix is to keep uptodate flag on write
>>error, but it gives a big impact.  We have to confirm whether
>>over 200 buffer_uptodate's are used for real uptodate check or write
>>error check.  For now, I adopt the quick-fix solution.
> 
>   Yes that needs to be solved. I also looked into it and it's too much work
> to do it in a one big sweep. But I think we could do the conversion
> filesystem by filesystem - see below.
>   Admittedly, I don't like your solution very much. It looks strange to
> check write_io_error when *reading* the buffer and I'm afraid we could
> introduce bugs e.g. by clearing write_io_error bit so that ext3_bread would
> then fail to detect the error condition or by some other code deciding to
> read the buffer from disk via other function than just ext3_bread. So I
> think it would be much better to set back uptodate flag shortly after the
> failed write or not clear it at all.
>   Now here's how I think we could achieve that without having to change all
> other filesystems: We could create a new superblock flag which would mean
> that "this filesystem handles write_io_error and doesn't want to clear
> uptodate flag". Filesystems with this capability would set this flag when
> calling get_sb_bdev. And if write IO fails we check this flag
> (via bh->b_bdev->bd_super->s_flags) and clear / not clear uptodate flag
> accordingly. What do you think?

Thanks for your comment!

Your suggestion is what I wanted to do ultimately, and it seems
to go well.  I'll send a rivised patch later.

Best regards,
-- 
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center


  reply	other threads:[~2010-01-15 10:38 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
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 [this message]
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=4B5045AE.9080604@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.