From: Richard Weinberger <richard@nod.at>
To: zhouminqiang <zhouminqiang2@huawei.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-mtd <linux-mtd@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
chengzhihao1 <chengzhihao1@huawei.com>,
yangerkun <yangerkun@huawei.com>, yi zhang <yi.zhang@huawei.com>
Subject: Re: [PATCH 0/6] jffs2: extend write verification to all write paths
Date: Fri, 21 Aug 2026 08:31:30 +0200 (CEST) [thread overview]
Message-ID: <1421509427.8290.1787293890858.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <2ca192b7-f903-41ba-8ffe-e8bfe9f79125@huawei.com>
----- Ursprüngliche Mail -----
> Von: "zhouminqiang" <zhouminqiang2@huawei.com>
> Thank you for your review and feedback.
>
> Sorry for the confusion caused by my cover letter. We are not using
> JFFS2 on NAND flash devices. Our primary goal is to extend write
> verification to the NOR flash path because we have encountered data
> corruption incidents in production environment and currently lack a
> quick diagnostic tool to isolate the cause. While reviewing the
> code flow, we noticed that the NAND buffered write path also lacked
> verification, so we took the opportunity to extend it as well.
>
> Although JFFS2 is in "Odd fixes" maintenance mode, there are still
> a significant number of devices in production that rely on JFFS2,
Okay, this makes more sense.
> and we are encountering data corruption issues on live nodes.
> Extending write verification to the NOR flash path would provide a
> diagnostic tool for fault isolation. We notice that WBUF_VERIFY has
> existed since 2007 (a6bc432e296d), so we want to extend the same
> diagnostic facility to cover the write paths it missed, so that it
> can serve ongoing product issue diagnosis. IMHO, this is a
> debugging/maintenance feature, not introducing new functionality.
>
> We respect your judgment and will leave the final decision to you.
These days many patches are created by an LLM where people change software
for the sake of changing.
But if it solves a real problem you're facing in production things are different,
of course.
Please have a look at Sashiko review, maybe it's useful (maybe not...)
and resend with an updated cover letter.
Thanks,
//richard
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: zhouminqiang <zhouminqiang2@huawei.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-mtd <linux-mtd@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
chengzhihao1 <chengzhihao1@huawei.com>,
yangerkun <yangerkun@huawei.com>, yi zhang <yi.zhang@huawei.com>
Subject: Re: [PATCH 0/6] jffs2: extend write verification to all write paths
Date: Fri, 21 Aug 2026 08:31:30 +0200 (CEST) [thread overview]
Message-ID: <1421509427.8290.1787293890858.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <2ca192b7-f903-41ba-8ffe-e8bfe9f79125@huawei.com>
----- Ursprüngliche Mail -----
> Von: "zhouminqiang" <zhouminqiang2@huawei.com>
> Thank you for your review and feedback.
>
> Sorry for the confusion caused by my cover letter. We are not using
> JFFS2 on NAND flash devices. Our primary goal is to extend write
> verification to the NOR flash path because we have encountered data
> corruption incidents in production environment and currently lack a
> quick diagnostic tool to isolate the cause. While reviewing the
> code flow, we noticed that the NAND buffered write path also lacked
> verification, so we took the opportunity to extend it as well.
>
> Although JFFS2 is in "Odd fixes" maintenance mode, there are still
> a significant number of devices in production that rely on JFFS2,
Okay, this makes more sense.
> and we are encountering data corruption issues on live nodes.
> Extending write verification to the NOR flash path would provide a
> diagnostic tool for fault isolation. We notice that WBUF_VERIFY has
> existed since 2007 (a6bc432e296d), so we want to extend the same
> diagnostic facility to cover the write paths it missed, so that it
> can serve ongoing product issue diagnosis. IMHO, this is a
> debugging/maintenance feature, not introducing new functionality.
>
> We respect your judgment and will leave the final decision to you.
These days many patches are created by an LLM where people change software
for the sake of changing.
But if it solves a real problem you're facing in production things are different,
of course.
Please have a look at Sashiko review, maybe it's useful (maybe not...)
and resend with an updated cover letter.
Thanks,
//richard
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-08-21 6:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 10:49 [PATCH 0/6] jffs2: extend write verification to all write paths zhouminqiang
2026-08-20 10:49 ` zhouminqiang
2026-08-20 10:49 ` [PATCH 1/6] jffs2: replace per-superblock verify buffer with per-write buffer zhouminqiang
2026-08-20 10:49 ` zhouminqiang
2026-08-20 10:49 ` [PATCH 2/6] jffs2: write verify: replace memcmp with byte-by-byte comparison zhouminqiang
2026-08-20 10:49 ` zhouminqiang
2026-08-20 10:49 ` [PATCH 3/6] jffs2: add write verification to direct page writes in flash_writev zhouminqiang
2026-08-20 10:49 ` zhouminqiang
2026-08-20 10:50 ` [PATCH 4/6] jffs2: add write verification to NOR direct write paths zhouminqiang
2026-08-20 10:50 ` zhouminqiang
2026-08-20 10:50 ` [PATCH 5/6] jffs2: rename CONFIG_JFFS2_FS_WBUF_VERIFY to CONFIG_JFFS2_FS_WRITE_VERIFY zhouminqiang
2026-08-20 10:50 ` zhouminqiang
2026-08-20 10:50 ` [PATCH 6/6] jffs2: add runtime toggle for write verification zhouminqiang
2026-08-20 10:50 ` zhouminqiang
2026-08-20 18:58 ` [PATCH 0/6] jffs2: extend write verification to all write paths Richard Weinberger
2026-08-20 18:58 ` Richard Weinberger
2026-08-20 20:46 ` David Woodhouse
2026-08-20 20:46 ` David Woodhouse
2026-08-21 3:37 ` zhouminqiang
2026-08-21 3:37 ` zhouminqiang
2026-08-21 6:31 ` Richard Weinberger [this message]
2026-08-21 6:31 ` 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=1421509427.8290.1787293890858.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=chengzhihao1@huawei.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=zhouminqiang2@huawei.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.