Re: Lots of fastmap writes

From: Zhihao Cheng <chengzhihao1@huawei.com>
To: Rickard x Andersson <rickaran@axis.com>, <richard@nod.at>,
	<linux-mtd@lists.infradead.org>
Cc: <rickard314.andersson@gmail.com>
Subject: Re: Lots of fastmap writes
Date: Mon, 17 Jun 2024 21:55:38 +0800	[thread overview]
Message-ID: <9cf2cb43-e5e1-0ed9-f795-ffd9f58bae6d@huawei.com> (raw)
In-Reply-To: <60ebb822-3161-f9b1-59df-fcc9b5e0e24e@axis.com>

在 2024/6/17 21:48, Rickard x Andersson 写道:
> On 6/17/24 15:21, Zhihao Cheng wrote:
>> 在 2024/6/17 19:20, Rickard x Andersson 写道:
>>> On 6/14/24 14:28, Zhihao Cheng wrote:
>>>> 在 2024/6/14 19:42, Rickard X Andersson 写道:
>>>>> On 6/4/24 03:52, Zhihao Cheng wrote:
>>>>
>>>> [...]
>>>>>>
>>>>>> BTW, after applying the patches, the kernel should run on a new 
>>>>>> flash, the improved wear-leveling algorithm cannot rescue the worn 
>>>>>> out image.
>>>>>>
>>>>>
>>>>> Thanks for the patches!
>>>>>
>>>>> I have backported the patches to Linux kernel 6.1. Do you think the 
>>>>> patches are safe to apply to Linux kernel 6.1?
>>>>
>>>> Yes, it's okay. I have backported the patches to our product(kernel 
>>>> v5.10) and it works fine.
>>>
>>> Thanks! I backported the patches to Linux 6.1 and did run my own 
>>> stress test for a few days. (On another device with fresh flash 
>>> memory.) It seems like the wear of the fastmap physical blocks (0-63) 
>>> is a lot less now with the patches applied, which is good.
>>>
>>> However I got this problem after almost 3 days of stress testing 
>>> (file system is set to read only mode):
>>>
>>>
>>> [ 7885.036577][  T182] ubi2: scrubbed PEB 2904 (LEB 0:229), data 
>>> moved to PEB 627
>>> [83721.724621][  T182] ubi2: scrubbed PEB 983 (LEB 0:3240), data 
>>> moved to PEB 7
>>> [83721.832521][  T182] ubi2: scrubbed PEB 997 (LEB 0:2819), data 
>>> moved to PEB 5
>>> [83784.750714][  T182] ubi2: scrubbed PEB 1927 (LEB 0:10), data moved 
>>> to PEB 2
>>> [165812.657934][  T182] ubi2: scrubbed PEB 3691 (LEB 0:11), data 
>>> moved to PEB 18
>>> [166748.055242][  T182] ubi2: scrubbed PEB 3045 (LEB 0:2), data moved 
>>> to PEB 837
>>> [166834.742451][  T182] ubi2: scrubbed PEB 918 (LEB 0:2), data moved 
>>> to PEB 43
>>
>> Looks like that some of PEBs have met the bitflip errors.
> 
> One thing that struck me. When looking at the scrubbing being done 
> above, is it not strange that data is moved from physical PEBs outside 
> fastmap area into the fastmap area? For example from PEB 997 to PEB 5?

Yes, it is expected. The first 64 PEBs usally have bigger erase counter, 
so UBI moves cold data into bigger ec PEB, it is the part of 
wear-leveling algorithm.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/