linux-kernel - Re: [PATCH 2/2] f2fs: add sysfs support for controlling the gc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 May 2013 13:45:55 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	jaegeuk.kim@...sung.com
Cc:	linux-f2fs-devel@...ts.sourceforge.net,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Namjae Jeon <namjae.jeon@...sung.com>,
	Pankaj Kumar <pankaj.km@...sung.com>
Subject: Re: [PATCH 2/2] f2fs: add sysfs support for controlling the gc_thread

2013/5/27, Jaegeuk Kim <jaegeuk.kim@...sung.com>:
> Hi Namjae,
Hi Jaegeuk.

First, Thanks for your interest.
>
> This is an interesting functionality.
> Could you describe why and when we need to do this?
> What are pros and cons?
> How can we use this?
As the default size of the F2FS parameter can vary as per the storage
size, so we can figure out the default values for Garbage collection
on each device.
It will be good if we can provide an interface which helps in tunning
these timing parameters to optimize the behavior of GC thread.

As you know, we can see performance dropping suddenly by GC thread. GC
thread is working more roughly for big size disk. And on other hand,
it is more work hard for very small partition.

And If App didn't access f2fs partition for a while. We can use this
time to make possible valid blocks using foregound gc thread working.
So we should need gc thread fg start and stop functionality.
We will describe how to use it and more detail in patch changelog(v2).

>
> IMO, when users try to control IO latencies, it seems that they can
> trigger such the explicit GCs, but in order to do that, they also need
> to know the status of current f2fs in more precisely. Does the debugfs
> show it enoughly?
First important thing before running the GC thread forecefully from
the user level ‘sysfs’ is to have diagnostic values of the FLASH
partition. So, we are trying to figure out how we can check the stats
regarding running the GC thread.

I have thought more after getting your reply.
f2fs_cleaner(a tentative name) is that provide the following several
options to control gc thread.
1. start forground gc thread to clean all invalid blocks.
2. stop number 1(fg) working.
3. set new tunning parameter (min/max/no_gc).
4. get status of current f2fs.

We will provide user level util in f2fs tools and sysfs at the same time.
It is useful if the console level user/App user can change them easily.

>
> Afterwards, it is worth to add some information to
> Document/filesystems/f2fs.txt.
Yes, It will be included in next series patches.
How do you think ? If you agree my suggestion, I will start to work
the above jobs.

Let me know your opinion.

Thanks.
>
> Thanks,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/