From: Chao Yu <chao@kernel.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <yuchao0@huawei.com>
Cc: "linux-f2fs-devel@lists.sourceforge.net"
<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] f2fs_symlink bug
Date: Fri, 23 Aug 2019 23:48:58 +0800 [thread overview]
Message-ID: <9d7b76fc-c116-d7e8-1988-41b4978eaa76@kernel.org> (raw)
In-Reply-To: <20190823150437.GB35310@jaegeuk-macbookpro.roam.corp.google.com>
On 2019-8-23 23:04, Jaegeuk Kim wrote:
> On 08/23, Chao Yu wrote:
>> On 2019/8/23 3:49, Jaegeuk Kim wrote:
>>> On 08/21, Chao Yu wrote:
>>>> Ping,
>>>>
>>>> On 2019/8/12 20:01, Chao Yu wrote:
>>>>> Hi Jaegeuk,
>>>>>
>>>>> In por_fsstress testcase, fsck reports below inconsistent status, I found one
>>>>> path can cause this case.
>>>>>
>>>>> [FIX] (fsck_chk_inode_blk:1002) --> Symlink: recover 0x1425 with i_size=4096
>>>>> [ASSERT] (fsck_chk_inode_blk:1030) --> ino: 0x1425 chksum:0x6983d47, but
>>>>> calculated one is: 0xdb284b35
>>>>> [FIX] (fsck_chk_inode_blk:1036) --> ino: 0x1425 recover, i_inode_checksum=
>>>>> 0x6983d47 -> 0xdb284b35
>>>>>
>>>>> - f2fs_symlink
>>>>> - page_symlink failed -> f2fs_write_failed() will truncate size to zero
>>>>> - f2fs_unlink failed -> symlink inode w/o data will remain in fs
>>>>>
>>>>> Not sure, but one choice of fix is to treat symlink as fs meta like we did for
>>>>> directory, so that checkpoint can take care of all data/node of symlink, any
>>>>> thoughts?
>>>
>>> Hmm, how's the possible to get very long path name requiring another data block?
>>
>> It can with below script, which is actually existed case in fsstress.
>>
>> #!/bin/bash
>>
>> for (( i = 0; i < 4095; i++ )); do
>> if [ $((i % 255)) -eq 0 ]
>> then
>> filename=$filename"/"
>> else
>> filename=$filename"0"
>> fi
>> done
>>
>> ln -s $filename /f2fs_mount_point/symlink
>>
>>> If it's fitted in inline_data, it's more easy to guarantee that, right?
>>
>> If the length of symlink is 4095, not sure inline space is enough even we can
>> compress symlink...
>
> I meant real usecases larger than 3.5KB. There's no posix rule to guarantee
> this. IOWs, it's known behavior across filesystems.
Correct, it looks not a big deal that whether we truncate i_size of symlink to
zero or not? how about avoiding such assert in fsck?
Thanks,
>
>>
>> Thanks,
>>
>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-f2fs-devel mailing list
>>>>> Linux-f2fs-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>>>> .
>>>>>
>>> .
>>>
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
prev parent reply other threads:[~2019-08-23 15:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-12 12:01 [f2fs-dev] f2fs_symlink bug Chao Yu
2019-08-21 8:36 ` Chao Yu
2019-08-22 19:49 ` Jaegeuk Kim
2019-08-23 1:39 ` Chao Yu
2019-08-23 15:04 ` Jaegeuk Kim
2019-08-23 15:48 ` Chao Yu [this message]
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=9d7b76fc-c116-d7e8-1988-41b4978eaa76@kernel.org \
--to=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=yuchao0@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).