linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Yunlong Song <yunlong.song@huawei.com>
To: jaegeuk@kernel.org, cm224.lee@samsung.com, yuchao0@huawei.com,
	chao@kernel.org, sylinux@163.com, yunlong.song@huawei.com,
	miaoxie@huawei.com, zhouxiyu@huawei.com
Cc: bintian.wang@huawei.com, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] Reduce the overprovision size a lot in f2fs
Date: Fri, 17 Feb 2017 20:53:05 +0800	[thread overview]
Message-ID: <1487335987-32601-1-git-send-email-yunlong.song@huawei.com> (raw)

Rethink the meaning of reserved segments and overprovision segments in f2fs

The key issue is that flash FTL has already made overprovision itself, e.g. 7%,
according to the difference between gigabyte (GB) and gibibyte (GiB). And this
part can nenver be seen by the upper file system. The device capacity which it
tells the upper file system is the other part which does not include the
overprovision part, which means the whole device capacity that file system knows
can "all" be used for write safely. The overprovision flash FTL has already reserved
includes the needed capacity for garbage collection and other operations. So,
filesystem can just take it easy and do not need to set the reserved segments and
overprovision segments again in mkfs.f2fs.

I want to explain more in detail. First, let's forget the section alignment
issue in the following talk, since it is really not possible in real production
case. As a result, f2fs does not need to behave like flash (i.e., new write
must come after erase for a block page in flash).

Take a look at the current design of mkfs.f2fs:

	c.reserved_segments = (2 * (100 / c.overprovision + 1) + 6) * c.segs_per_sec;

The original motivation may be like this:

For example, if ovp is 20%, we select 5 victim segments to reclaim one free
segment in the worst case. During this migration, we need additional 4 free
segments to write valid blocks in the victim segments. Other remaining added
segments are just to keep as a buffer to prepare any abnormal situation.

But f2fs does not have to bahave like flash, so why do we need 4 more free segments
here? For current codes of f2fs gc, we only need 1 free segment:

Initial status: 1 free segment is needed

  segment 0     segment 1     segment 2     segment 3     segment 4     segment 5
|20% invalid| |20% invalid| |20% invalid| |20% invalid| |20% invalid|   | free |
|80%   valid| |80%   valid| |80%   valid| |80%   valid| |80%   valid|   | free |


step 1: segment 0 -> segment 5, free segment 0

  segment 0     segment 1     segment 2     segment 3     segment 4      segment 5
|    free   | |20% invalid| |20% invalid| |20% invalid| |20% invalid|   |20%  free|
|    free   | |80%   valid| |80%   valid| |80%   valid| |80%   valid|   |80% valid|


step 2: segment 1 -> segment 5 and segment 0, free segment 1

  segment 0     segment 1     segment 2     segment 3     segment 4      segment 5
|40%    free| |    free   | |20% invalid| |20% invalid| |20% invalid|   |20% valid|
|60%   valid| |    free   | |80%   valid| |80%   valid| |80%   valid|   |80% valid|


step 3: segment 2 -> segment 0 and segment 1, free segment 2

  segment 0     segment 1     segment 2     segment 3     segment 4      segment 5
|40%   valid| |60%    free| |    free   | |20% invalid| |20% invalid|   |20% valid|
|60%   valid| |40%   valid| |    free   | |80%   valid| |80%   valid|   |80% valid|


step 4: segment 3 -> segment 1 and segment 2, free segment 3

  segment 0     segment 1     segment 2     segment 3     segment 4      segment 5
|40%   valid| |60%   valid| |80%    free| |    free   | |20% invalid|   |20% valid|
|60%   valid| |40%   valid| |20%   valid| |    free   | |80%   valid|   |80% valid|


step 5: segment 4 -> segment 2, free segment 4

  segment 0     segment 1     segment 2     segment 3     segment 4      segment 5
|40%   valid| |60%   valid| |80%   valid| |    free   | |    free   |   |20% valid|
|60%   valid| |40%   valid| |20%   valid| |    free   | |    free   |   |80% valid|

done. Now there are 1 new free segment.

If we change the f2fs gc codes in future, we can even let the initial 1 free
segment go away, just copy valid data among the 5 segments themselves using SSR.

So the previous formula:

	c.reserved_segments = (2 * (100 / c.overprovision + 1) + 6) * c.segs_per_sec;

is not needed, we can set reserved_segments to any value if we want, no matter
what value c.overprovision is, just take it away from the formula.

And take take a look at the overprov_segment_count in current design of
mkfs.f2fs:

set_cp(overprov_segment_count, (get_sb(segment_count_main) - get_cp(rsvd_segment_count)) * c.overprovision / 100);

The original motivation may be like this:

For example, if ovp is 20%, the worst case is that each segment is 20% invalid,
then all the segments can not be selected as victim target for FTL GC, then
there is (segment_count_main - rsvd_segment_count) * 20%, which are all invalid
blocks and can not be used for write, thus we should regard this as
overprovision segments, which can never be used by user. However, as we
have explained above, all the device capacity which FTL tells f2fs can be used
for write, so it is not correct to use this formula. In fact, we do not need to set
the overprovision segments at all for this consideration.

Yunlong Song (2):
  mkfs.f2fs: add option to set the value of reserved segments
    and overprovision segments
  f2fs: fix the case when there is no free segment to allocate for
    CURSEG_WARM_NODE

 fs/f2fs/segment.c | 2 --
 1 file changed, 2 deletions(-)

-- 
1.8.5.2

             reply	other threads:[~2017-02-17 12:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17 12:53 Yunlong Song [this message]
2017-02-17 12:53 ` [PATCH 1/2] mkfs.f2fs: add option to set the value of reserved segments and overprovision segments Yunlong Song
2017-02-17 12:53 ` [PATCH 2/2] f2fs: fix the case when there is no free segment to allocate for CURSEG_WARM_NODE Yunlong Song
2017-02-17 18:39   ` Jaegeuk Kim
2017-02-23 12:06     ` Chao Yu
2017-02-23 19:27       ` Jaegeuk Kim
2017-02-17 19:33 ` [PATCH 0/2] Reduce the overprovision size a lot in f2fs Jaegeuk Kim

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=1487335987-32601-1-git-send-email-yunlong.song@huawei.com \
    --to=yunlong.song@huawei.com \
    --cc=bintian.wang@huawei.com \
    --cc=chao@kernel.org \
    --cc=cm224.lee@samsung.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=miaoxie@huawei.com \
    --cc=sylinux@163.com \
    --cc=yuchao0@huawei.com \
    --cc=zhouxiyu@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).