From: "yebin (H)" <yebin10@huawei.com>
To: Jan Kara <jack@suse.cz>, Ye Bin <yebin@huaweicloud.com>
Cc: <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
<linux-ext4@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] ext4: commit super block if fs record error when journal record without error
Date: Fri, 17 Feb 2023 09:44:57 +0800 [thread overview]
Message-ID: <63EEDC19.6010204@huawei.com> (raw)
In-Reply-To: <20230216173159.zkj4qd2nmj2yjpkr@quack3>
On 2023/2/17 1:31, Jan Kara wrote:
> On Tue 14-02-23 10:29:04, Ye Bin wrote:
>> From: Ye Bin <yebin10@huawei.com>
>>
>> Now, 'es->s_state' maybe covered by recover journal. And journal errno
>> maybe not recorded in journal sb as IO error. ext4_update_super() only
>> update error information when 'sbi->s_add_error_count' large than zero.
>> Then 'EXT4_ERROR_FS' flag maybe lost.
>> To solve above issue commit error information after recover journal.
>>
>> Signed-off-by: Ye Bin <yebin10@huawei.com>
>> ---
>> fs/ext4/super.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index dc3907dff13a..b94754ba8556 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -5932,6 +5932,18 @@ static int ext4_load_journal(struct super_block *sb,
>> goto err_out;
>> }
>>
>> + if (unlikely(es->s_error_count && !jbd2_journal_errno(journal) &&
>> + !(le16_to_cpu(es->s_state) & EXT4_ERROR_FS))) {
>> + EXT4_SB(sb)->s_mount_state |= EXT4_ERROR_FS;
>> + es->s_state |= cpu_to_le16(EXT4_ERROR_FS);
>> + err = ext4_commit_super(sb);
>> + if (err) {
>> + ext4_msg(sb, KERN_ERR,
>> + "Failed to commit error information, please repair fs force!");
>> + goto err_out;
>> + }
>> + }
>> +
> Hum, I'm not sure I follow here. If journal replay has overwritten the
> superblock (and thus the stored error info), then I'd expect
> es->s_error_count got overwritten (possibly to 0) as well. And this is
> actually relatively realistic scenario with errors=remount-ro behavior when
> the first fs error happens.
>
> What I intended in my original suggestion was to save es->s_error_count,
> es->s_state & EXT4_ERROR_FS, es->s_first_error_*, es->s_last_error_* before
> doing journal replay in ext4_load_journal() and then after journal replay
> merge this info back to the superblock
Actually,commit 1c13d5c08728 ("ext4: Save error information to the
superblock for analysis")
already merged error info back to the superblock after journal replay
except 'es->s_state'.
The problem I have now is that the error flag in the journal superblock
was not recorded,
but the error message was recorded in the superblock. So it leads to
ext4_clear_journal_err()
does not detect errors and marks the file system as an error. Because
ext4_update_super() is
only set error flag when 'sbi->s_add_error_count > 0'. Although
'sbi->s_mount_state' is
written to the super block when umount, but it is also conditional.
So I handle the scenario "es->s_error_count &&
!jbd2_journal_errno(journal) &&
!(le16_to_cpu(es->s_state) & EXT4_ERROR_FS)". Maybe we can just store
'EXT4_SB(sb)->s_mount_state & EXT4_ERROR_FS' back to the superblock. But i
prefer to mark fs as error if it contain detail error info without
EXT4_ERROR_FS.
> - if EXT4_ERROR_FS was set, set it
> now as well, take max of old and new s_error_count, set s_first_error_* if
> it is now unset, set s_last_error_* if stored timestamp is newer than
> current timestamp.
>
> Or am I overengineering it now? :)
>
> Honza
next prev parent reply other threads:[~2023-02-17 1:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-14 2:29 [PATCH v3 0/2] fix error flag covered by journal recovery Ye Bin
2023-02-14 2:29 ` [PATCH v3 1/2] ext4: commit super block if fs record error when journal record without error Ye Bin
2023-02-16 7:17 ` Baokun Li
2023-02-16 7:44 ` yebin (H)
2023-02-16 9:17 ` Baokun Li
2023-02-16 9:29 ` yebin (H)
2023-02-16 17:31 ` Jan Kara
2023-02-17 1:43 ` Baokun Li
2023-02-17 1:44 ` yebin (H) [this message]
2023-02-17 10:56 ` Jan Kara
2023-02-18 2:18 ` yebin (H)
2023-02-27 11:20 ` Jan Kara
2023-02-28 2:24 ` yebin (H)
2023-03-01 9:07 ` Jan Kara
2023-02-14 2:29 ` [PATCH v3 2/2] ext4: make sure fs error flag setted before clear journal error Ye Bin
2023-02-16 7:17 ` Baokun Li
2023-02-16 17:20 ` Jan Kara
2023-02-16 7:18 ` [PATCH v3 0/2] fix error flag covered by journal recovery Baokun Li
2023-02-16 8:12 ` yebin (H)
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=63EEDC19.6010204@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 \
--cc=yebin@huaweicloud.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 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.