linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Gao Xiang <hsiangkao@aol.com>, Chao Yu <yuchao0@huawei.com>,
	jaegeuk@kernel.org, Yunlei He <heyunlei@huawei.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs: fix to handle looped node chain during recovery
Date: Sun, 4 Feb 2018 23:14:21 +0800	[thread overview]
Message-ID: <250b6aaa-84ab-13b6-0da0-f47ba9b65b35@kernel.org> (raw)
In-Reply-To: <34884138-31e6-566d-5be3-d62f61a3416e@aol.com>

Well, that's classic algorithm for checking loop in a list, as well as
other one we know, in order to decrease time complexity of these algorithms,
their implementations are a little more complex.

But IMO, the issue we are trying to fix is really a corner case, and the
performance in that path is not such critical, so I just intend to fix it
with fewest codes.

On 2018/2/3 19:36, Gao Xiang via Linux-f2fs-devel wrote:
> 
> Sorry, I saw the related code entirely, please ignore these replies.
> 
> 
> On 2018/2/3 18:45, Gao Xiang wrote:
>>
>>
>> On 2018/2/3 18:35, Gao Xiang wrote:
>>> Hi Chao and YunLei,
>>>
>>>
>>> On 2018/2/3 17:44, Chao Yu wrote:
>>>> There is no checksum in node block now, so bit-transition from hardware
>>>> can make node_footer.next_blkaddr being corrupted w/o any detection,
>>>> result in node chain becoming looped one.
>>>>
>>>> For this condition, during recovery, in order to avoid running into dead
>>>> loop, let's detect it and just skip out.
>>>>
>>>> Signed-off-by: Yunlei He <heyunlei@huawei.com>
>>>> Signed-off-by: Chao Yu <yuchao0@huawei.com>
>>>> ---
>>>>   fs/f2fs/recovery.c | 14 ++++++++++++++
>>>>   1 file changed, 14 insertions(+)
>>>>
>>>> diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
>>>> index b6d1ec620a8c..60dd0cee4820 100644
>>>> --- a/fs/f2fs/recovery.c
>>>> +++ b/fs/f2fs/recovery.c
>>>> @@ -243,6 +243,9 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, struct list_head *head,
>>>>       struct curseg_info *curseg;
>>>>       struct page *page = NULL;
>>>>       block_t blkaddr;
>>>> +    unsigned int loop_cnt = 0;
>>>> +    unsigned int free_blocks = sbi->user_block_count -
>>>> +                    valid_user_blocks(sbi);
>>> There exists another way to detect loop more faster but only using two variables.
>>> The algorithm is described as simply "B goes forward a steps only A goes forwards 2 steps".
>> "B goes forward a step only when A goes forward 2(or constant x, more than 1) steps".
>>
>>> For example:
>>> 1)
>>>    1   2  3  4   5   6     7
>>>    |             \             /
>>>    |                \------/
>>>   A, B
>>> 2)
>>>    1  2  3  4   5   6     7
>>>     |   |        \             /
>>>    B   A        \------/
>>>  3)
>>>    1  2  3  4   5   6     7
>>>        |    |     \             /
>>>       B   A      \------/
>>>   4)
>>>    1  2  3  4   5   6     7
>>>        |       |\             /
>>>       B      A \------/
>>> 5)....
>>>
>>
>>
>> Sorry, it seems the encoded diagram is in a mess, I try again.
>> 1)
>>    1 -> 2 -> 3 -> 4 -> 5 ->  6 -> 7
>>    |               \             /
>>    |                \-----<-----/
>>   A, B
>> 2)
>>    1 -> 2 -> 3 -> 4 -> 5 ->  6 -> 7
>>    |    |          \             /
>>    |    |           \-----<-----/
>>    B    A
>> 3)
>>    1 -> 2 -> 3 -> 4 -> 5 ->  6 -> 7
>>         |    |     \             /
>>         |    |      \-----<-----/
>>         B    A
>> 4)
>>    1 -> 2 -> 3 -> 4 -> 5 ->  6 -> 7
>>         |         |\             /
>>         |         | \-----<-----/
>>         B         A
>> 5)....
>> if B catchs up A, there exists a cycle.
>>
>>
>> Thanks,
>>> B will equal A or beyoud A if and only if there has a cycle.
>>> It's a more faster algorithm. :D
>>>
>>> Thanks,
>>>
>>>>       int err = 0;
>>>>         /* get node pages in the current segment */
>>>> @@ -295,6 +298,17 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, struct list_head *head,
>>>>           if (IS_INODE(page) && is_dent_dnode(page))
>>>>               entry->last_dentry = blkaddr;
>>>>   next:
>>>> +        /* sanity check in order to detect looped node chain */
>>>> +        if (++loop_cnt >= free_blocks ||
>>>> +            blkaddr == next_blkaddr_of_node(page)) {
>>>> +            f2fs_msg(sbi->sb, KERN_NOTICE,
>>>> +                "%s: detect looped node chain, "
>>>> +                "blkaddr:%u, next:%u",
>>>> +                __func__, blkaddr, next_blkaddr_of_node(page));
>>>> +            err = -EINVAL;
>>>> +            break;
>>>> +        }
>>>> +
>>>>           /* check next segment */
>>>>           blkaddr = next_blkaddr_of_node(page);
>>>>           f2fs_put_page(page, 1);
>>>
>>
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

      reply	other threads:[~2018-02-04 15:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-03  9:44 [PATCH] f2fs: fix to handle looped node chain during recovery Chao Yu
2018-02-03 10:35 ` [f2fs-dev] " Gao Xiang
2018-02-03 10:45   ` Gao Xiang
2018-02-03 11:36     ` Gao Xiang
2018-02-04 15:14       ` 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=250b6aaa-84ab-13b6-0da0-f47ba9b65b35@kernel.org \
    --to=chao@kernel.org \
    --cc=heyunlei@huawei.com \
    --cc=hsiangkao@aol.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).