public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: yangerkun <yangerkun@huawei.com>
Cc: Jan Kara <jack@suse.cz>, "Theodore Y . Ts'o" <tytso@mit.edu>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [QUESTION] question for commit 2d01ddc86606 ("ext4: save error info to sb through journal if available")
Date: Wed, 25 Aug 2021 12:25:18 +0200	[thread overview]
Message-ID: <20210825102518.GA14620@quack2.suse.cz> (raw)
In-Reply-To: <05ff3a17-6559-9317-a382-f0a02fa59926@huawei.com>


Hello Kun!

On Wed 25-08-21 10:13:03, yangerkun wrote:
> There is a question about 2d01ddc86606 ("ext4: save error info to sb through
> journal if available"). This commit describe that we can have checksum
> failure with follow case:
> 
> 1. ext4_handle_error will call ext4_commit_super which write directly to the
> superblock
> 2. At the same time, jounalled update of the superblock is ongoing
> 
> However, after commit 05c2c00f3769 ("ext4: protect superblock modifications
> with a buffer lock"), all the update for superblock and the csum will be
> protected with buffer lock. It seems we won't get a csum error after that
> commit and the journal logic in flush_stashed_error_work seems useless.
> 
> Maybe there is something missing... Can you help to explain more for that...

You are correct that after commit 05c2c00f3769 the checksum will be
correct. However there are also other problems that 2d01ddc86606 addresses
and that are mentioned in the commit description like "writing inconsistent
information". The fundamental problem is that you cannot mix journalled and
non-journalled updates to any block. Because e.g. the unjournalled update
could store to disk information that was changed only as part of the
currently running transaction and if the machine crashes before the
transaction commits, we have too new information in the block and thus
inconsistent filesystem. Or in the other direction, journal replay can
overwrite unjournalled modifications to the superblock if we crash at the
right moment.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2021-08-25 10:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25  2:13 [QUESTION] question for commit 2d01ddc86606 ("ext4: save error info to sb through journal if available") yangerkun
2021-08-25 10:25 ` Jan Kara [this message]
2021-08-26  1:06   ` yangerkun

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=20210825102518.GA14620@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=yangerkun@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