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

[Rickard X Andersson]

On 11/16/24 03:55, Zhihao Cheng wrote:
> 在 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.

Thanks for feedback.

> 
> 1. We need to know the overall flash wear, including:
>    1) Is the flash over/approaching lifetime? - the 'max_ec' could tell us

On many devices max_ec is practically unusable. The reason for this 
being previous bugs in UBI causing single fastmap blocks to be written 
many many times. For example a situation where single fastmap block is 
written e.g. 60000 times and the rest of the fastmap blocks being 
written around 2000 times.

>    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).
> 

@Richard Weinberger, do you also prefer an IOCTL solution? Should I 
resend my patch series using IOCTL.

Thanks,
Rickard A.