Linux-f2fs-devel Archive on lore.kernel.org
 help / color / Atom feed
* [f2fs-dev] f2fs_symlink bug
@ 2019-08-12 12:01 Chao Yu
  2019-08-21  8:36 ` Chao Yu
  0 siblings, 1 reply; 6+ messages in thread
From: Chao Yu @ 2019-08-12 12:01 UTC (permalink / raw)
  To: Jaegeuk Kim; +Cc: linux-f2fs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] f2fs_symlink bug
  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
  0 siblings, 1 reply; 6+ messages in thread
From: Chao Yu @ 2019-08-21  8:36 UTC (permalink / raw)
  To: Jaegeuk Kim; +Cc: linux-f2fs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] f2fs_symlink bug
  2019-08-21  8:36 ` Chao Yu
@ 2019-08-22 19:49   ` Jaegeuk Kim
  2019-08-23  1:39     ` Chao Yu
  0 siblings, 1 reply; 6+ messages in thread
From: Jaegeuk Kim @ 2019-08-22 19:49 UTC (permalink / raw)
  To: Chao Yu; +Cc: linux-f2fs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] f2fs_symlink bug
  2019-08-22 19:49   ` Jaegeuk Kim
@ 2019-08-23  1:39     ` Chao Yu
  2019-08-23 15:04       ` Jaegeuk Kim
  0 siblings, 1 reply; 6+ messages in thread
From: Chao Yu @ 2019-08-23  1:39 UTC (permalink / raw)
  To: Jaegeuk Kim; +Cc: linux-f2fs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] f2fs_symlink bug
  2019-08-23  1:39     ` Chao Yu
@ 2019-08-23 15:04       ` Jaegeuk Kim
  2019-08-23 15:48         ` Chao Yu
  0 siblings, 1 reply; 6+ messages in thread
From: Jaegeuk Kim @ 2019-08-23 15:04 UTC (permalink / raw)
  To: Chao Yu; +Cc: linux-f2fs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [f2fs-dev] f2fs_symlink bug
  2019-08-23 15:04       ` Jaegeuk Kim
@ 2019-08-23 15:48         ` Chao Yu
  0 siblings, 0 replies; 6+ messages in thread
From: Chao Yu @ 2019-08-23 15:48 UTC (permalink / raw)
  To: Jaegeuk Kim, Chao Yu; +Cc: linux-f2fs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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

Linux-f2fs-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-f2fs-devel/0 linux-f2fs-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-f2fs-devel linux-f2fs-devel/ https://lore.kernel.org/linux-f2fs-devel \
		linux-f2fs-devel@lists.sourceforge.net linux-f2fs-devel@archiver.kernel.org
	public-inbox-index linux-f2fs-devel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/net.sourceforge.lists.linux-f2fs-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox