Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 25 Aug 2021 12:25:18 +0200
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")
Message-ID: <20210825102518.GA14620@quack2.suse.cz>
References: <05ff3a17-6559-9317-a382-f0a02fa59926@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <05ff3a17-6559-9317-a382-f0a02fa59926@huawei.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


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