[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