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
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>> .
>>>
> .
>
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
