From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33996C433E0 for ; Fri, 5 Mar 2021 02:19:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E44E364FED for ; Fri, 5 Mar 2021 02:19:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229538AbhCECTf (ORCPT ); Thu, 4 Mar 2021 21:19:35 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:13059 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbhCECTe (ORCPT ); Thu, 4 Mar 2021 21:19:34 -0500 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4DsBFt356lzMjHn; Fri, 5 Mar 2021 10:17:22 +0800 (CST) Received: from [10.136.110.154] (10.136.110.154) by smtp.huawei.com (10.3.19.201) with Microsoft SMTP Server (TLS) id 14.3.498.0; Fri, 5 Mar 2021 10:19:31 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: expose # of overprivision segments To: Jaegeuk Kim CC: , , References: <20210302054233.3886681-1-jaegeuk@kernel.org> <920469a9-45d3-68e3-1f8d-a436bdd60cfe@huawei.com> <05b43d3e-d735-ae34-5a4f-3d81a4fc8a9b@huawei.com> From: Chao Yu Message-ID: Date: Fri, 5 Mar 2021 10:19:31 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.136.110.154] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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//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//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 "" 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//super_block /proc/fs/f2fs//checkpoint /proc/fs/f2fs//nat_table /proc/fs/f2fs//sit_table ... Thanks, > >> >> Thanks, >> >>> >>>> >>>>> >>>>>> >>>>>> Signed-off-by: Jaegeuk Kim >>>>>> --- >>>>>> 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 >>> . >>> > . >