From: Eric Whitney <enwlinux@gmail.com>
To: Ye Bin <yebin@huaweicloud.com>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
jack@suse.cz, Ye Bin <yebin10@huawei.com>
Subject: Re: [PATCH v2 2/3] ext4: record error when detect abnormal 'i_reserved_data_blocks'
Date: Mon, 21 Nov 2022 22:34:59 -0500 [thread overview]
Message-ID: <Y3xDY4GVAF+eKAqY@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <20221121121434.1061725-3-yebin@huaweicloud.com>
* Ye Bin <yebin@huaweicloud.com>:
> From: Ye Bin <yebin10@huawei.com>
>
> If 'i_reserved_data_blocks' is not cleared which mean something wrong with
> code, free space accounting is likely wrong, according to Jan Kara's advice
> use ext4_error() to record this abnormal let fsck to repair and also we can
> capture this issue.
>
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
> fs/ext4/super.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 0690e2e0b74d..3d30007502a4 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1387,10 +1387,9 @@ static void ext4_destroy_inode(struct inode *inode)
> }
>
> if (EXT4_I(inode)->i_reserved_data_blocks)
> - ext4_msg(inode->i_sb, KERN_ERR,
Per the coding standard, IIRC, the string should not be split across lines
for "greppability", so it should remain as is. It's always good to run
checkpatch to catch stuff like this.
> - "Inode %lu (%p): i_reserved_data_blocks (%u) not cleared!",
> - inode->i_ino, EXT4_I(inode),
> - EXT4_I(inode)->i_reserved_data_blocks);
> + ext4_error(inode->i_sb, "Inode %lu (%p) i_reserved_data_blocks"
> + " (%u) not cleared!", inode->i_ino, EXT4_I(inode),
> + EXT4_I(inode)->i_reserved_data_blocks);
> }
>
> static void init_once(void *foo)
This is an improvement over the first version. If i_reserved_data_blocks is
non-zero, something is definitely broken, but it's perhaps less likely to
indicate file system damage than if it hits zero while there are still
outstanding delayed blocks (handled well elsewhere). So, it's not clear
we need to escalate handling this case but it doesn't hurt, either.
Eric
> --
> 2.31.1
>
next prev parent reply other threads:[~2022-11-22 3:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-21 12:14 [PATCH v2 0/3] Fix two issues about bigalloc feature Ye Bin
2022-11-21 12:14 ` [PATCH v2 1/3] ext4: fix incorrect calculate 'reserved' in '__es_remove_extent' when enable " Ye Bin
2022-12-01 22:21 ` Eric Whitney
2022-12-02 6:00 ` yebin (H)
2022-12-03 2:34 ` yebin (H)
2022-11-21 12:14 ` [PATCH v2 2/3] ext4: record error when detect abnormal 'i_reserved_data_blocks' Ye Bin
2022-11-22 3:34 ` Eric Whitney [this message]
2022-11-21 12:14 ` [PATCH v2 3/3] ext4: add check pending tree when evict inode Ye Bin
2022-11-24 2:08 ` Eric Whitney
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=Y3xDY4GVAF+eKAqY@debian-BULLSEYE-live-builder-AMD64 \
--to=enwlinux@gmail.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 \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox