Re: [f2fs-dev] f2fs_symlink bug

[Chao Yu <yuchao0@huawei.com>]

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...

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