Re: [PATCH 0/2] Reduce the overprovision size a lot in f2fs

From: Jaegeuk Kim
Date: Fri Feb 17 2017 - 14:33:51 EST


Hi Yunlong,

On 02/17, Yunlong Song wrote:
> 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).

Simply say no, F2FS has nothing to do with FTL, and LFS acts like 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

Should be step 1: segment 0 -> segment 5, prefree segment 0
Anyway,

> 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

Here, we cannot use segment 0 to fill 60% to handle power-cut. If power-cut
happens after this, we will lose prevous data in segment 0. That's why we're
using prefree segments.

Thanks,

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