From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Csókás Bence" <csokas.bence@prolan.hu>
Cc: Richard Weinberger <richard@nod.at>,
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 15:59:22 +0200 [thread overview]
Message-ID: <87r00ugcat.fsf@bootlin.com> (raw)
In-Reply-To: <4ebe2146-ee1c-4325-8259-be3803475f1f@prolan.hu> ("Csókás Bence"'s message of "Mon, 12 May 2025 15:13:20 +0200")
Hello,
On 12/05/2025 at 15:13:20 +02, Csókás Bence <csokas.bence@prolan.hu> wrote:
> Hi,
>
> On 2025. 05. 12. 14:47, Richard Weinberger wrote:
>> ----- Ursprüngliche Mail -----
>>> Von: "Csókás Bence" <csokas.bence@prolan.hu>
>>> Well, yes, in our case. But the point is, we have a strict requirement
>>> for data integrity, which is not unique to us I believe. I would think
>>> there are other industrial control applications like ours, which dictate
>>> a high data integrity.
>> In your last patch set you said your hardware has an issue that every
>> now and that data is not properly written.
>> Now you talk about data integrity requirements. I'm confused.
>
> The two problems are not too dissimilar: in one case you have a random,
> and _very_ low chance of data corruption, e.g. because of noise, aging
> hardware, power supply ripple etc. But you still need to make sure that
> the written data is absolutely correct; or if it is not, the system will
> immediately enter some fail-safe mode. This is the problem we want to
> solve, for everybody using Linux in high reliability environments.
>
> 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.
Cheers,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2025-05-12 14:24 UTC|newest]
Thread overview: 11+ 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 9:14 ` Miquel Raynal
2025-05-12 9:45 ` Richard Weinberger
2025-05-12 12:29 ` Csókás Bence
2025-05-12 12:47 ` Richard Weinberger
2025-05-12 13:13 ` Csókás Bence
2025-05-12 13:59 ` Miquel Raynal [this message]
2025-05-12 15:23 ` Richard Weinberger
2025-05-12 15:33 ` Miquel Raynal
2025-05-12 15:51 ` Csókás Bence
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=87r00ugcat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox