linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "zhangyi (F)" <yi.zhang@huawei.com>
To: <linux-ext4@vger.kernel.org>, <tytso@mit.edu>, <jack@suse.cz>
Cc: <adilger.kernel@dilger.ca>, <zhangxiaoxu5@huawei.com>,
	<yi.zhang@huawei.com>, <linux-fsdevel@vger.kernel.org>
Subject: [PATCH v2 0/5] ext4: fix inconsistency since reading old metadata from disk
Date: Wed, 17 Jun 2020 19:59:42 +0800	[thread overview]
Message-ID: <20200617115947.836221-1-yi.zhang@huawei.com> (raw)

Changes since v1:
 - Give up the solution of re-adding metadata buffer's uptodate flag.
 - Patch 1-2: Add a call back for end_buffer_async_write() and invoke
   ext4_error_err() to handle metadata buffer async write IO error
   immediately.
 - Patch 3: Add mapping->wb_err check and also invoke ext4_error_err()
   in ext4_journal_get_write_access() if wb_err is different from the
   original one saved at mount time. Add this patch because patch 2
   could not fix all cases.
 - Patch 4-5: Remove partial fix <7963e5ac90125> and <9c83a923c67d>.

The above 5 patches are based on linux-5.8-rc1 and have been tested by
xfstests, no new failures.

Thanks,
Yi.

-----------------------

Original background
===================

This patch set point to fix the inconsistency problem which has been
discussed and partial fixed in [1].

Now, the problem is on the unstable storage which has a flaky transport
(e.g. iSCSI transport may disconnect few seconds and reconnect due to
the bad network environment), if we failed to async write metadata in
background, the end write routine in block layer will clear the buffer's
uptodate flag, but the data in such buffer is actually uptodate. Finally
we may read "old && inconsistent" metadata from the disk when we get the
buffer later because not only the uptodate flag was cleared but also we
do not check the write io error flag, or even worse the buffer has been
freed due to memory presure.

Fortunately, if the jbd2 do checkpoint after async IO error happens,
the checkpoint routine will check the write_io_error flag and abort the
the journal if detect IO error. And in the journal recover case, the
recover code will invoke sync_blockdev() after recover complete, it will
also detect IO error and refuse to mount the filesystem.

Current ext4 have already deal with this problem in __ext4_get_inode_loc()
and commit 7963e5ac90125 ("ext4: treat buffers with write errors as
containing valid data"), but it's not enough.

[1] https://lore.kernel.org/linux-ext4/20190823030207.GC8130@mit.edu/

zhangyi (F) (5):
  fs: add bdev writepage hook to block device
  ext4: mark filesystem error if failed to async write metadata
  ext4: detect metadata async write error when getting journal's write
    access
  ext4: remove ext4_buffer_uptodate()
  ext4: remove write io error check before read inode block

 fs/block_dev.c      |  5 ++++
 fs/ext4/ext4.h      | 24 +++++++++----------
 fs/ext4/ext4_jbd2.c | 34 +++++++++++++++++++++++----
 fs/ext4/inode.c     | 13 ++---------
 fs/ext4/page-io.c   | 57 +++++++++++++++++++++++++++++++++++++++++++++
 fs/ext4/super.c     | 32 ++++++++++++++++++++++++-
 include/linux/fs.h  |  1 +
 7 files changed, 136 insertions(+), 30 deletions(-)

-- 
2.25.4


             reply	other threads:[~2020-06-17 11:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-17 11:59 zhangyi (F) [this message]
2020-06-17 11:59 ` [PATCH v2 1/5] fs: add bdev writepage hook to block device zhangyi (F)
2020-06-18  7:02   ` Christoph Hellwig
2020-06-17 11:59 ` [PATCH v2 2/5] ext4: mark filesystem error if failed to async write metadata zhangyi (F)
2020-06-17 12:48   ` Jan Kara
2020-06-17 11:59 ` [PATCH v2 3/5] ext4: detect metadata async write error when getting journal's write access zhangyi (F)
2020-06-17 12:41   ` Jan Kara
2020-06-17 13:44     ` zhangyi (F)
2020-06-18  3:53       ` zhangyi (F)
2020-06-17 11:59 ` [PATCH v2 4/5] ext4: remove ext4_buffer_uptodate() zhangyi (F)
2020-06-17 11:59 ` [PATCH v2 5/5] ext4: remove write io error check before read inode block zhangyi (F)

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=20200617115947.836221-1-yi.zhang@huawei.com \
    --to=yi.zhang@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=zhangxiaoxu5@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).