From: yebin <yebin10@huawei.com>
To: Jan Kara <jack@suse.cz>
Cc: <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
<linux-ext4@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] jbd2: detect old record when do journal scan
Date: Tue, 23 Aug 2022 17:17:59 +0800 [thread overview]
Message-ID: <63049B47.2000408@huawei.com> (raw)
In-Reply-To: <20220819095445.yq4d2qhrhb73p3zk@quack3>
On 2022/8/19 17:54, Jan Kara wrote:
> On Wed 10-08-22 09:34:42, Ye Bin wrote:
>> As https://github.com/tytso/e2fsprogs/issues/120 describe tune2fs do not update
>> j_tail_sequence when do journal recovery. This maybe recover old journal record,
>> then will lead to file system corruption.
>> To avoid file system corruption in this case, if detect current transaction's
>> commit time earlier than previous transaction's commit time when do journal
>> scan, just return error.
>>
>> Signed-off-by: Ye Bin <yebin10@huawei.com>
> Thanks for the patch! Let me see if I understand your concern right. You
> are concerned about the following scenario:
>
> 1) Kernel uses the filesystem, there's a crash.
> 2) E2fsprogs replays the journal but fails to update sb->s_sequence in the
> journal superblock.
> 3) Kernel mounts the fs again - however note that even if kernel skips
> recovery, it does scan the journal jbd2_journal_skip_recovery() and
> journal->j_transaction_sequence is set based on the last transaction found
> in the journal.
>
> So I don't think there is really possibility we will quickly reuse some
> transaction IDs and thus possibility of corruption on replay? Am I missing
> something?
>
> Honza
The file system corruption I encountered was indeed because e2fsprogs
did not update
journal - > J_ transaction_ Sequence leads to replay the old transaction.
So I wonder whether the kernel should detect this kind of exception, at
least when there
is a file system corruption, there are clues to trace.
>
>> ---
>> fs/jbd2/recovery.c | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/jbd2/recovery.c b/fs/jbd2/recovery.c
>> index f548479615c6..f3def21a96a5 100644
>> --- a/fs/jbd2/recovery.c
>> +++ b/fs/jbd2/recovery.c
>> @@ -812,8 +812,17 @@ static int do_one_pass(journal_t *journal,
>> break;
>> }
>> }
>> - if (pass == PASS_SCAN)
>> + if (pass == PASS_SCAN) {
>> + if (commit_time < last_trans_commit_time) {
>> + pr_err("JBD2: old journal record found "
>> + "in transaction %u\n",
>> + next_commit_ID);
>> + err = -EFSBADCRC;
>> + brelse(bh);
>> + goto failed;
>> + }
>> last_trans_commit_time = commit_time;
>> + }
>> brelse(bh);
>> next_commit_ID++;
>> continue;
>> --
>> 2.31.1
>>
next prev parent reply other threads:[~2022-08-23 11:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-10 1:34 [PATCH RFC] jbd2: detect old record when do journal scan Ye Bin
2022-08-19 8:00 ` yebin
2022-08-19 8:34 ` fengnan chang
2022-08-19 9:54 ` Jan Kara
2022-08-23 9:17 ` yebin [this message]
2022-08-23 13:07 ` Jan Kara
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=63049B47.2000408@huawei.com \
--to=yebin10@huawei.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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.