From: Ye Bin <yebin@huaweicloud.com>
To: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, jack@suse.cz, Ye Bin <yebin10@huawei.com>
Subject: [PATCH v5 0/2] fix error flag covered by journal recovery
Date: Tue, 7 Mar 2023 14:17:01 +0800 [thread overview]
Message-ID: <20230307061703.245965-1-yebin@huaweicloud.com> (raw)
From: Ye Bin <yebin10@huawei.com>
Diff v5 Vs v4:
Only commit error info to disk when bdev is not readonly.
Diff v4 Vs v3:
After journal replay recover 'es->s_state' error flag like recover error
info.
Diff v3 Vs v2:
Only fix fs error flag lost when previous journal errno is not record
in disk. As this may lead to drop orphan list, however fs not record
error flag, then fsck will not repair deeply.
Diff v2 vs v1:
Move call 'j_replay_prepare_callback' and 'j_replay_end_callback' from
ext4_load_journal() to jbd2_journal_recover().
When do fault injection test, got issue as follows:
EXT4-fs (dm-5): warning: mounting fs with errors, running e2fsck is recommended
EXT4-fs (dm-5): Errors on filesystem, clearing orphan list.
EXT4-fs (dm-5): recovery complete
EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro
EXT4-fs (dm-5): recovery complete
EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: data_err=abort,errors=remount-ro
Without do file system check, file system is clean when do second mount.
Theoretically, the kernel will not clear fs error flag. In errors=remount-ro
mode the last super block is commit directly. So super block in journal is
not uptodate. When do jounral recovery, the uptodate super block will be
covered by jounral data. If super block submit all failed after recover
journal, then file system error flag is lost. When do "fsck -a" couldn't
repair file system deeply.
To solve above issue we need to do extra handle when do super block journal
recovery.
Ye Bin (2):
ext4: commit super block if fs record error when journal record
without error
ext4: make sure fs error flag setted before clear journal error
fs/ext4/super.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
--
2.31.1
next reply other threads:[~2023-03-07 5:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-07 6:17 Ye Bin [this message]
2023-03-07 6:17 ` [PATCH v5 1/2] ext4: commit super block if fs record error when journal record without error Ye Bin
2023-03-07 9:02 ` Jan Kara
2023-03-08 1:04 ` Baokun Li
2023-03-07 6:17 ` [PATCH v5 2/2] ext4: make sure fs error flag setted before clear journal error Ye Bin
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=20230307061703.245965-1-yebin@huaweicloud.com \
--to=yebin@huaweicloud.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 \
--cc=yebin10@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).