[PATCH v3] mtd: Verify written data in paranoid mode
Csókás Bence
csokas.bence at prolan.hu
Mon May 12 08:51:10 PDT 2025
Hi,
On 2025. 05. 12. 17:33, Miquel Raynal wrote:
> On 12/05/2025 at 17:23:16 +02, Richard Weinberger <richard at nod.at> wrote:
>
>> ----- Ursprüngliche Mail -----
>>> Von: "Miquel Raynal" <miquel.raynal at bootlin.com>
>>>> The problem we _have_ though happens to be a bit different: here we are
>>>> blursed with a system that corrupts data at a noticeable
>>>> probability. But the model is the same: a stochastic process introducing
>>>> bit errors on write. But I sincerely hope no one else has this problem,
>>>> and this is *not* the primary aim of this patch; it just happens to
>>>> solve our issue as well. But I intend it to be useful for the larger
>>>> Linux community, thus the primary goal is to solve the first issue.
>>>
>>> I don't have a strong opinion there but I don't dislike this idea
>>> because it might also help troubleshooting errors sometimes. It is very
>>> hard to understand issues which happen to be discovered way after they
>>> have been generated (typically during a read, way later than a "faulty"
>>> write). Having this paranoid option would give a more synchronous
>>> approach which is easier to work with sometimes.
>>
>> UBI offers this already, there is a write self-check as part of the io
>> checks that can be enabled
>> via debugfs per UBI device.
>> So for troubleshooting this should be good enough.
>> There is room for improvement, though. Currently it uses vmalloc().
>
> UBI is full of uncovered resources :-)
For sure. Plus, even though we use UBI + UBIFS, that may not necessarily
be the case for others. Maybe someone uses mtdblock + some
"conventional" FS (ext*, f2fs etc.). Or maybe they use JFFS. Or maybe no
FS at all. We should still allow userspace or higher FS layers to be
notified of the problem.
Bence
More information about the linux-mtd
mailing list