Messages in this thread | | | Subject | Re: [f2fs-dev] [PATCH] f2fs: expose # of overprivision segments | From | Chao Yu <> | Date | Fri, 5 Mar 2021 10:19:31 +0800 |
| |
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.
> >> >>> >>> 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.
/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@kernel.org> >>>>>> --- >>>>>> 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@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >>> . >>> > . >
| |