From: Zhang Yi <yi.zhang@huawei.com>
To: Jan Kara <jack@suse.cz>, Ye Bin <yebin10@huawei.com>
Cc: <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
<linux-ext4@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<lczerner@redhat.com>
Subject: Re: [PATCH -next] ext4: Fix symlink file size not match to file content
Date: Mon, 21 Mar 2022 22:38:49 +0800 [thread overview]
Message-ID: <5b3e0bb7-370b-a950-1d2f-b0e31357cc01@huawei.com> (raw)
In-Reply-To: <20220321113703.cibgeac5ipslg3df@quack3.lan>
On 2022/3/21 19:37, Jan Kara wrote:
> On Mon 21-03-22 19:34:08, Ye Bin wrote:
>> We got issue as follows:
>> [home]# fsck.ext4 -fn ram0yb
>> e2fsck 1.45.6 (20-Mar-2020)
>> Pass 1: Checking inodes, blocks, and sizes
>> Pass 2: Checking directory structure
>> Symlink /p3/d14/d1a/l3d (inode #3494) is invalid.
>> Clear? no
>> Entry 'l3d' in /p3/d14/d1a (3383) has an incorrect filetype (was 7, should be 0).
>> Fix? no
>>
>> As symlink file size not match to file content. If symlink data block
>> writback failed, will call ext4_finish_bio to end io. In this path don't
>> mark buffer error. When umount do checkpoint can't detect buffer error,
>> then will cleanup jounral. Actually, correct data maybe in journal area.
>> To solve this issue, mark buffer error when detect bio error in
>> ext4_finish_bio.
>
> Thanks for the patch! Let me rephrase the text a bit:
>
> As the symlink file size does not match the file content. If the writeback
> of the symlink data block failed, ext4_finish_bio() handles the end of IO.
> However this function fails to mark the buffer with BH_write_io_error and
> so when unmount does journal checkpoint it cannot detect the writeback
> error and will cleanup the journal. Thus we've lost the correct data in the
> journal area. To solve this issue, mark the buffer as BH_write_io_error in
> ext4_finish_bio().
>
Hi, Jan.
Thinking about this issue in depth, the symlink data block is one kind of
metadata, but the page mapping of such block is belongs to the ext4 inode,
it's not coordinate to other metadata blocks, e.g. directory block and extents
block. This is why we have already fix the same issue of other metadata blocks
in commit fcf37549ae19e9 "jbd2: ensure abort the journal if detect IO error
when writing original buffer back" but missing the case of symlink data block.
So, after Ye Bin's fix, I think it's worth to unify the symlink data block
mapping to bdev, any suggestions?
Thanks,
Yi.
next prev parent reply other threads:[~2022-03-21 14:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-21 11:34 [PATCH -next] ext4: Fix symlink file size not match to file content Ye Bin
2022-03-21 11:37 ` Jan Kara
2022-03-21 13:35 ` yebin
2022-03-21 14:12 ` Jan Kara
2022-03-21 14:38 ` Zhang Yi [this message]
2022-03-21 15:11 ` Jan Kara
2022-04-06 8:31 ` Zhang Yi
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=5b3e0bb7-370b-a950-1d2f-b0e31357cc01@huawei.com \
--to=yi.zhang@huawei.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=lczerner@redhat.com \
--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