Re: Investigation Request - Strange PEB Reservation Behavior in UBI

From: Zhihao Cheng
Date: Wed Jul 31 2024 - 22:22:09 EST


在 2024/7/31 17:53, Nikhil Kashyap H R 写道:
Dear Team,
I am writing to request an investigation into a strange issue we have observed regarding PEB reservation for bad block management in UBI. For context, our system uses MT29FxxG NAND flash chips with a minimum of 4016 valid blocks (NVB) per LUN out of a total of 4096 blocks.
We have noticed that when using the CONFIG_MTD_UBI_BEB_LIMIT parameter, which is typically calculated as 1024 * (1 - MinNVB / TotalNVB) = 20 PEBs, UBI is reserving significantly more PEBs than expected. Instead of the expected 20 PEBs, UBI is reserving around 160 PEBs per LUN, which is approximately 8 times more than it should be.
To work around this issue, we have set the CONFIG_MTD_UBI_BEB_LIMIT parameter to 3, which corresponds to ~91 reserved PEBs per LUN. However, this strange 8x multiplier effect is concerning and requires further investigation. Additionally, we have observed crashes in our system and suspect that the over-reservation of PEBs for bad block handling may be related to these issues.
We would like to understand the root cause of the crashes and how the excessive PEB reservation might be contributing to the problem. We have some similar questions related to the PEB's usage in UBI operations:
Why is UBI reserving significantly more PEBs for bad block handling than expected when using the CONFIG_MTD_UBI_BEB_LIMIT parameter?

Just like the description in drivers/mtd/ubi/Kconfig, CONFIG_MTD_UBI_BEB_LIMIT specifies the maximum bad physical eraseblocks UBI expects on the MTD device (per 1024 eraseblocks). For example, if we attach an UBI device to a mtd partition(from a nandchip with 8192 PEBs), UBI will keep 8192/1024 * CONFIG_MTD_UBI_BEB_LIMIT[default val is 20] = 160 PEBs for bad block reservation.

config MTD_UBI_BEB_LIMIT
int "Maximum expected bad eraseblock count per 1024 eraseblocks"
default 20
range 0 768
help
This option specifies the maximum bad physical eraseblocks UBI
expects on the MTD device (per 1024 eraseblocks). If the underlying
flash does not admit of bad eraseblocks (e.g. NOR flash), this value
is ignored.


NAND datasheets often specify the minimum and maximum NVM (Number of
Valid Blocks) for the flashes' endurance lifetime. The maximum
expected bad eraseblocks per 1024 eraseblocks then can be calculated
as "1024 * (1 - MinNVB / MaxNVB)", which gives 20 for most NANDs
(MaxNVB is basically the total count of eraseblocks on the chip).


To put it differently, if this value is 20, UBI will try to reserve
about 1.9% of physical eraseblocks for bad blocks handling. And that
will be 1.9% of eraseblocks on the entire NAND chip, not just the MTD
partition UBI attaches. This means that if you have, say, a NAND
flash chip admits maximum 40 bad eraseblocks, and it is split on two
MTD partitions of the same size, UBI will reserve 40 eraseblocks when
attaching a partition.

1A) The typical calculation suggests reserving 20 PEBs, but UBI is reserving 8 times more, around 160 PEBs per LUN. What is causing this 8x multiplier effect?
Does the issue of over-reserving PEBs only occur when multiple NAND partitions are grouped under the same parent MTD device, as is the case with the custom driver? Or can it also happen with a single NAND partition per MTD device?
Is the over-reservation of PEBs for bad block handling related to the crashes observed in the system? If so, what is the root cause of the crashes and how does the excessive PEB reservation contribute to the issue?
What is the expected behavior of UBI when reserving PEBs for bad block management based on the CONFIG_MTD_UBI_BEB_LIMIT parameter? Why is UBI not following the typical calculation in this case?
Are there any known bugs, issues or unexpected behaviors in the UBI subsystem or NAND flash drivers that could explain the observed PEB reservation problem? If so, are there any workarounds or fixes available?
We would greatly appreciate if you could investigate this issue and provide us with your findings and recommendations.
Thank you for your assistance.
Best regards,
Nikhil Kashyap H R


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