Re: [f2fs-dev] [PATCH] f2fs: expose # of overprivision segments

From: Chao Yu
Date: Mon Mar 08 2021 - 21:51:52 EST


On 2021/3/9 8:07, Jaegeuk Kim wrote:
On 03/05, Chao Yu wrote:
On 2021/3/5 1:50, Jaegeuk Kim wrote:
On 03/04, Chao Yu wrote:
On 2021/3/3 2:44, Jaegeuk Kim wrote:
On 03/02, Jaegeuk Kim wrote:
On 03/02, Chao Yu wrote:
On 2021/3/2 13:42, Jaegeuk Kim wrote:
This is useful when checking conditions during checkpoint=disable in Android.

This sysfs entry is readonly, how about putting this at
/sys/fs/f2fs/<disk>/stat/?

Urg.. "stat" is a bit confused. I'll take a look a better ones.

Oh, I mean put it into "stat" directory, not "stat" entry, something like this:

/sys/fs/f2fs/<disk>/stat/ovp_segments

I meant that too. Why is it like stat, since it's a geomerty?

Hmm.. I feel a little bit weired to treat ovp_segments as 'stat' class, one reason
is ovp_segments is readonly and is matching the readonly attribute of a stat.

It seems I don't fully understand what you suggest here. I don't want to add the
# of ovp_segments in <disk>/stat, since it is not part of status, but put it in
<disk>/ to sync with other # of free/dirty segments. If you can't read out easily,
I suggest to create symlinks to organize all the current mess.

Alright.






Taking a look at other entries using in Android, I feel that this one can't be
in stat or whatever other location, since I worry about the consistency with
similar dirty/free segments. It seems it's not easy to clean up the existing
ones anymore.

Well, actually, the entry number are still increasing continuously, the result is
that it becomes more and more slower and harder for me to find target entry name
from that directory.

IMO, once new readonly entry was added to "<disk>" directory, there is no chance
to reloacate it due to interface compatibility. So I think this is the only
chance to put it to the appropriate place at this time.

I know, but this will diverge those info into different places. I don't have
big concern when finding a specific entry with this tho, how about making
symlinks to create a dir structure for your easy access? Or, using a script
would be alternative way.

Yes, there should be some alternative ways to help to access f2fs sysfs
interface, but from a point view of user, I'm not sure he can figure out those
ways.

For those fs meta stat, why not adding a single entry to include all info you
need rather than adding them one by one? e.g.

You can add that in /proc as well, which requires to parse back when retrieving
specific values.

Copied.

Thanks,



/proc/fs/f2fs/<disk>/super_block
/proc/fs/f2fs/<disk>/checkpoint
/proc/fs/f2fs/<disk>/nat_table
/proc/fs/f2fs/<disk>/sit_table
...

Thanks,



Thanks,





Signed-off-by: Jaegeuk Kim <jaegeuk@xxxxxxxxxx>
---
fs/f2fs/sysfs.c | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index e38a7f6921dd..254b6fa17406 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -91,6 +91,13 @@ static ssize_t free_segments_show(struct f2fs_attr *a,
(unsigned long long)(free_segments(sbi)));
}
+static ssize_t ovp_segments_show(struct f2fs_attr *a,
+ struct f2fs_sb_info *sbi, char *buf)
+{
+ return sprintf(buf, "%llu\n",
+ (unsigned long long)(overprovision_segments(sbi)));
+}
+
static ssize_t lifetime_write_kbytes_show(struct f2fs_attr *a,
struct f2fs_sb_info *sbi, char *buf)
{
@@ -629,6 +636,7 @@ F2FS_RW_ATTR(F2FS_SBI, f2fs_sb_info, node_io_flag, node_io_flag);
F2FS_RW_ATTR(CPRC_INFO, ckpt_req_control, ckpt_thread_ioprio, ckpt_thread_ioprio);
F2FS_GENERAL_RO_ATTR(dirty_segments);
F2FS_GENERAL_RO_ATTR(free_segments);
+F2FS_GENERAL_RO_ATTR(ovp_segments);

Missed to add document entry in Documentation/ABI/testing/sysfs-fs-f2fs?

Yeah, thanks.


Thanks,

F2FS_GENERAL_RO_ATTR(lifetime_write_kbytes);
F2FS_GENERAL_RO_ATTR(features);
F2FS_GENERAL_RO_ATTR(current_reserved_blocks);



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
.

.

.