[PATCH 1/2] ubi: wl: Put source PEB into correct list if trying locking LEB failed

[Zhihao Cheng]

在 2024/8/27 14:25, Ryder Wang 写道:
>> Now, e1 is the source PEB with smaller erase counter, it will be picked
>> as source PEB again in next WL if it not becomes free yet.
>>
>> We don't put it into scrub tree, because the scrub type PEB means that
>> biflips ever happen during reading, the data is not stable anymore in
>> that PEB, so UBI moves data from scrub type PEB just take the
>> opportunity of WL process.
>>
>> IOW, in this case, the WL won't lost keeping ec balanced whether we keep
>> e1 in used tree or move it into scrub tree. It's the same thing as the
>> MOVE_TARGET_WR_ERR/MOVE_TARGET_RD_ERR case.
> 
> Then what's the positive return and necessity of this patch? It looks there is few difference before and after applying the patch.
> .
> 

The most necessity is that make the message 'ubi0: scrubbed PEB 66 (LEB 
0:10), data moved to PEB 165' not be false positive, user could be 
confused when he get the kernel message while running tests on a 
nandsim(a nand simulator based on memory, which won't generate bitflips).
As for the testing results(a small decrement of ec counter) based on the 
patches, there is a small difference:

Before patches:
step 1. In first wl, e1 is put into scrub tree, e2 is put into free tree.
step 2. The second wl must be scheduled according to the implementation 
of ensure_wear_leveling(), because scrub tree is not empty.
step 3. In second wl, e1 is still e1 in step 1, e2 is picked from 
ubi->fm_wl_pool, which is not the same e2 in step 2, which means that 
the e2->ec could be smaller than e1->ec + UBI_WL_THRESHOLD, there is no 
need to do the second wl actually.

After patches:
step 1. In first wl, e1 is put into used tree, e2 is put into free tree.
step 2. The second wl may not be scheduled according to the 
implementation of ensure_wear_leveling(), because scrub tree is empty 
and the ec counter of first entry in ubi->fm_wl_pool is not greater than 
e1->ec + UBI_WL_THRESHOLD.