From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Weinberger <richard@nod.at>
Cc: "Csókás Bence" <csokas.bence@prolan.hu>,
linux-mtd <linux-mtd@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Vignesh Raghavendra" <vigneshr@ti.com>
Subject: Re: [PATCH v3] mtd: Verify written data in paranoid mode
Date: Mon, 12 May 2025 17:33:28 +0200 [thread overview]
Message-ID: <87y0v1g7xz.fsf@bootlin.com> (raw)
In-Reply-To: <1689545397.30901605.1747063396608.JavaMail.zimbra@nod.at> (Richard Weinberger's message of "Mon, 12 May 2025 17:23:16 +0200 (CEST)")
On 12/05/2025 at 17:23:16 +02, Richard Weinberger <richard@nod.at> wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Miquel Raynal" <miquel.raynal@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 :-)
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Weinberger <richard@nod.at>
Cc: "Csókás Bence" <csokas.bence@prolan.hu>,
linux-mtd <linux-mtd@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Vignesh Raghavendra" <vigneshr@ti.com>
Subject: Re: [PATCH v3] mtd: Verify written data in paranoid mode
Date: Mon, 12 May 2025 17:33:28 +0200 [thread overview]
Message-ID: <87y0v1g7xz.fsf@bootlin.com> (raw)
In-Reply-To: <1689545397.30901605.1747063396608.JavaMail.zimbra@nod.at> (Richard Weinberger's message of "Mon, 12 May 2025 17:23:16 +0200 (CEST)")
On 12/05/2025 at 17:23:16 +02, Richard Weinberger <richard@nod.at> wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Miquel Raynal" <miquel.raynal@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 :-)
next prev parent reply other threads:[~2025-05-12 15:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-12 8:40 [PATCH v3] mtd: Verify written data in paranoid mode Bence Csókás
2025-05-12 8:40 ` Bence Csókás
2025-05-12 9:14 ` Miquel Raynal
2025-05-12 9:14 ` Miquel Raynal
2025-05-12 9:45 ` Richard Weinberger
2025-05-12 9:45 ` Richard Weinberger
2025-05-12 12:29 ` Csókás Bence
2025-05-12 12:29 ` Csókás Bence
2025-05-12 12:47 ` Richard Weinberger
2025-05-12 12:47 ` Richard Weinberger
2025-05-12 13:13 ` Csókás Bence
2025-05-12 13:13 ` Csókás Bence
2025-05-12 13:59 ` Miquel Raynal
2025-05-12 13:59 ` Miquel Raynal
2025-05-12 15:23 ` Richard Weinberger
2025-05-12 15:23 ` Richard Weinberger
2025-05-12 15:33 ` Miquel Raynal [this message]
2025-05-12 15:33 ` Miquel Raynal
2025-05-12 15:51 ` Csókás Bence
2025-05-12 15:51 ` Csókás Bence
2025-05-12 15:57 ` Richard Weinberger
2025-05-12 15:57 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y0v1g7xz.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=csokas.bence@prolan.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.