Hello,
On Sun, Oct 04, 2015 at 11:54:30AM +0200, Marc Lehmann wrote:
> Hi!
>
> In this mail I describe what I would expect of f2fs in general, and the gc
> in particular. I already know my expectations or assumptions are partially
> incorrect, and will note so when I know of it. The idea of this mail is
> both to correct me in my understanding (if you would be so nice :), and
> also explain my expectations and motivation in more detail.
>
> General f2fs behaviour:
>
> Expectation: f2fs logs need not be consecutive, so it can GC sections
> relatively independently and, with suitable configuration, it
> will always free whole sections (e.g. 128MB at -s64) and reuse
> them for writing. This would mitigate the SMR problemxs, because,
> assuming continous writing to the fs, it would write whole sections
> consecutively, which would span multiple zones.
>
> Reality: quite obviously f2fs reuses space in roughly 2MB chunks, most
> likely on a segment basis.
When there are not enough empty sections, f2fs starts to reuse the obsolete
segments, which is called as SSR. The victims are selected on a segment basis,
but we can expect the next victim would be inside the same section, since
searching is done in an increasing order.
>
> (background) GC:
>
> Expectation/Blind Guessing: While there is nothing to GC, the GC will sleep
> for gc_no_gc_sleep_time intervals (it may be woken up for other reasons).
>
> When there is something to GC, then the GC will check if the filesystem
> is idle (by unknown means, e.g. by checking if there was activity within
> a certain time, or whether there is activity at the moment it checks).
>
> If the fs is idle, it would GC one section (or something similar), then
> sleep for gc_min_sleep_time.
>
> If the fs is busy, it would GC one section (or something similar), then
> sleep for gc_max_sleep_time.
>
> Ignoring slight variations, the expected behaviour would be for the GC
> to GC a bit every gc_min_sleep_time+time_it_takes_for_IO when idle, or
> longer when the fs is busy.
>
> As a result, ideal settings would be 0 for gc_min_sleep_time
> and something high (potentially very high, such as an hour) for
> gc_max_sleep_time.
>
> Reality: If I understood you correctly, the GC will just queue writes
> whether there are already outstanding writes or not, it has no notion
> of when one GC iteration is finished, so gc_min_sleep_time has to be
> long enough for the writes to finish. Since this is impossible (the
> time is obviously not fixed and gc_min_sleep_time is a constant), there
> is no way to run GC with maximum speed during fs idle times (unless one
> writes a separate program to force GC when idle time is detected by
> some means).
>
> Also, quite obviously, even when the fs is completely idle, the GC will
> typically sleep for gc_max_sleep_time, so it seems "idle fs" is not the
> concept that influences the time between gc activity.
Urg, indeed, I missed one condition for this behavior.
In f2fs_gc, originally I added a condition not to conduct GC too aggressively,
which is, in fs/f2fs/gc.c,
if (has_enough_invalid_blocks())
decrease_sleep_time()
else
increase_sleep_time()
By default, only if the partition is filled with data over 40% and free
segments are remained less than 40% of data amount that user can do sequential
wrties, f2fs decreases the waiting time.
1. For your intention, accordingly, it needs to decrease the gc_max_sleep_time
dramatically.
2. In order to disable ipu, setting 0 is enough, IMO.
echo 0 > ipu_policy
3. I added a patch to issue checkpoint with the following configurable interval:
echo 30 > sync_interval # checkpoint at every 30secs as a best effort
4. I submitted a couple of patches to do GC synchronously in background, could
you try out "background_gc=sync" in your mount options?
5. Another patch also introduces for users to monitor GC behaviors by:
echo 1 > /sys/fs/f2fs/dev/events/f2fs/f2fs_background_gc/enable
echo 1 > /sys/fs/f2fs/dev/events/f2fs/f2fs_get_victim/enable
Thank,
>
> --
> The choice of a Deliantra, the free code+content MORPG
> -----==- _GNU_ http://www.deliantra.net
> ----==-- _ generation
> ---==---(_)__ __ ____ __ Marc Lehmann
> --==---/ / _ \/ // /\ \/ / schm...@schmorp.de
> -=====/_/_//_/\_,_/ /_/\_\
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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
