linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
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

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