linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: 李扬韬 <frank.li@vivo.com>
To: Chao Yu <yuchao0@huawei.com>
Cc: jaegeuk@kernel.org, chao@kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re:Re: [f2fs-dev] [PATCH] f2fs: set prefree as free segments after clear prefree segments
Date: Fri, 23 Apr 2021 10:40:57 +0800 (GMT+08:00)	[thread overview]
Message-ID: <AIMAXgAnDv8vtlWxuL6mq4q3.3.1619145657480.Hmail.frank.li@vivo.com> (raw)
In-Reply-To: <247c6055-c004-72a6-5093-3949c2ed8495@huawei.com>

HI Chao,
 
>> For now, when do_checkpoint fails, the prefree bitmap is not cleared,
>> but these segments are already in the free state. If these segments
>> are used, the segments in use will be reset to the free state when
>> f2fs_clear_prefree_segments is called next time.
>> 
>> So move set_prefree_as_free_segments after clear_prefree_segments.
>
>That's not correct.
>
>/*
>  * Should call f2fs_clear_prefree_segments after checkpoint is done.
>  */
>static void set_prefree_as_free_segments(struct f2fs_sb_info *sbi)
>
>Comments above set_prefree_as_free_segments() should have told you
>the rule, otherwise if checkpoint failed, valid data in last valid
>checkpoint could be corrupted after segment reuse.

For do_checkpoint sucess:

f2fs_write_checkpoint
->f2fs_flush_sit_entries
    ->set_prefree_as_free_segments
->do_checkpoint
->f2fs_clear_prefree_segments


Calling set_prefree_as_free_segments when do_checkpoint fails,
seems to be incorrect. I think clear free bitmap should be after
clear prefree bitmap.

For do_checkpoint fail:

f2fs_write_checkpoint
->f2fs_flush_sit_entries
    ->set_prefree_as_free_segments
->do_checkpoint
->f2fs_release_discard_addrs

The prefree bitmap is not cleared, but free bitmap is cleared,which means
we can use these segments that are marked as free. When the free segments
is used, the next f2fs_clear_prefree_segments will mark prefree as free again,
causing some problem.

With this patch, for do_checkpoint fail:

f2fs_write_checkpoint
->f2fs_flush_sit_entries
->do_checkpoint
->f2fs_release_discard_addrs

At this time, we did not mark prefree as free segments, so these segments will not be used.

Thx


  reply	other threads:[~2021-04-23  2:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22 12:59 [PATCH] f2fs: set prefree as free segments after clear prefree segments Yangtao Li
2021-04-23  1:30 ` [f2fs-dev] " Chao Yu
2021-04-23  2:40   ` 李扬韬 [this message]
2021-04-23  3:37     ` Chao Yu
2021-04-23  9:02       ` 李扬韬

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=AIMAXgAnDv8vtlWxuL6mq4q3.3.1619145657480.Hmail.frank.li@vivo.com \
    --to=frank.li@vivo.com \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --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).