[f2fs-dev] f2fs_symlink bug

[f2fs-dev] f2fs_symlink bug

[Chao Yu]

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?


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] f2fs_symlink bug

[Chao Yu]

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?
> 
> 
> _______________________________________________
> 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

Re: [f2fs-dev] f2fs_symlink bug

[Jaegeuk Kim]

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?
If it's fitted in inline_data, it's more easy to guarantee that, right?

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

Re: [f2fs-dev] f2fs_symlink bug

[Chao Yu]

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

Re: [f2fs-dev] f2fs_symlink bug

[Jaegeuk Kim]

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.

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

Re: [f2fs-dev] f2fs_symlink bug

[Chao Yu]

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