[PATCH v3 01/10] ubi: Expose mean erase counter in sysfs

Zhihao Cheng chengzhihao1 at huawei.com
Fri Nov 15 18:55:33 PST 2024


在 2024/11/15 17:00, Rickard x Andersson 写道:
> On 11/14/24 19:50, Richard Weinberger wrote:
>> ----- Ursprüngliche Mail -----
>>> Von: "chengzhihao1" <chengzhihao1 at huawei.com>
>>> An: "richard" <richard at nod.at>, "Rickard X Andersson" 
>>> <rickard.andersson at axis.com>
>>> CC: "linux-mtd" <linux-mtd at lists.infradead.org>, "rickard314 
>>> andersson" <rickard314.andersson at gmail.com>, "kernel"
>>> <kernel at axis.com>
>>> Gesendet: Donnerstag, 7. November 2024 02:39:45
>>> Betreff: Re: [PATCH v3 01/10] ubi: Expose mean erase counter in sysfs
>>
>>> 在 2024/11/7 4:34, Richard Weinberger 写道:
>>>> ----- Ursprüngliche Mail -----
>>>>> Von: "Rickard X Andersson" <rickard.andersson at axis.com>
>>>>> There exists more detailed info in debugfs, but this information is
>>>>> only available for debug builds.
>>>>
>>>> If the detailed info is useful for regular userspace we can also think
>>>> of adding a non-debugfs interface for it.
>>>> E.g. an ioctl() that returns this data in binary form.
>>>
>>> This method sounds better.
>>
>> Rickard, what do you think about this option?
>>
>> Thanks,
>> //richard
> 
> Hi,
> 
> I would prefer to keep it in sysfs. We already have the following in 
> sysfs (/sys/class/ubi/ubiX) that is related to flash wear:
> 
> -r--r--r--    1 root root      4096 Oct 24 08:54 avail_eraseblocks
> -r--r--r--    1 root root      4096 Nov 15 08:26 bad_peb_count
> -r--r--r--    1 root root      4096 Nov 15 08:26 max_ec
> -r--r--r--    1 root root      4096 Oct 24 08:54 reserved_for_bad
> 
> With my patch series the following will be added for normal builds:
> 
> -r--r--r--    1 root root      4096 Nov 15 08:26 mean_ec
> 
> If fastmap is enabled (CONFIG_MTD_UBI_FASTMAP=y) also the following is 
> added:
> 
> -r--r--r--    1 root root      4096 Nov 15 08:26 max_ec_data
> -r--r--r--    1 root root      4096 Nov 15 08:26 max_ec_fastmap
> -r--r--r--    1 root root      4096 Nov 15 08:26 mean_ec_data
> -r--r--r--    1 root root      4096 Nov 15 08:26 mean_ec_fastmap
> 
> If you think the above is too "bloated" in the fastmap case 
> (CONFIG_MTD_UBI_FASTMAP=y) we could reduce the additional files in the 
> fastmap case to the following (More similar to my V1 version of the 
> patch series):
> 
> -r--r--r--    1 root root      4096 Nov 15 08:26 mean_ec_fastmap
> 
> Thanks,
> Rickard A.
> 
> .

Hi Rickard. Let's reorganize our thoughts.

1. We need to know the overall flash wear, including:
   1) Is the flash over/approaching lifetime? - the 'max_ec' could tell us
   2) How worn down the flash is in different areas? the 'mean_ec' could 
tell us the overall situation, the 'mean_ec_data' and 'mean_ec_fastmap' 
could tell us more details in different areas.
   3) Does the wear-leveling algorithm work correctly? the 
'max_ec_data', 'min_ec_data' could be used to judge whether PEBs usage 
in data area is balanced,the 'max_ec_fastmap', 'min_ec_fastmap' could be 
used to judge whether PEBs usage in fastmap area is balanced.
2. Kernel only provides mechanisms, user program implements logic to 
satisfy what user wants.
3. I think points 1-1)~3) belongs to user requirements, they can be 
implemented according to the raw ec statistics(debugfs interface, or 
according to Richard's suggestion providing a new ioctl).
Why do I think points 1-1)~3) belong to user logic? They are customized 
and can only be used in specific scenarios, not like 'max_ec', 
'bad_peb_count' and 'leb_size' which are general features of UBI and be 
widely used. For example, if someday one user wants to known the mediam 
ec count in data and fastmap areas, two interfaces will be added in 
sysfs, which looks bloated(There are too many bespoke interfaces under 
sysfs).




More information about the linux-mtd mailing list