When JFFS2 writes data to flash, it first calculates a node CRC, and
the NAND controller calculates ECC as the data is programmed. If
corruption occurs between these two points, the possible causes are
RAM failures or bus transfer errors before the data reaches the flash,
or bit flips on the flash medium itself. To distinguish whether the
corruption happened during the write transfer or after commit to the
medium, commit a6bc432e296d ("[JFFS2] Add support for write-buffer
verification") introduced CONFIG_JFFS2_FS_WBUF_VERIFY: reading the
data back immediately after a successful write and comparing it with
the in-memory source buffer provides the missing observation point
for that diagnosis.

However, the current implementation only performs read-back verification
on write-buffer flush paths. Two scenarios remain uncovered:

  1. When the write data length exceeds wbuf_pagesize, the excess data
  bypasses the write buffer and is written directly to flash via
  mtd_write() in jffs2_flash_writev(), with no verification.
  2. NOR Flash and other non-writebuffered devices write directly through
  jffs2_flash_direct_write() and jffs2_flash_direct_writev(), with no
  equivalent check.

In both cases, if MTD reports a successful write but the readable medium
differs from JFFS2's source buffer, a later node CRC failure cannot
distinguish transport/program-time corruption from post-commit media
damage, defeating the original diagnostic intent.

This series covers both scenarios with the following changes.

Replace the pre-allocated per-superblock wbuf_verify buffer with
on-demand allocation inside jffs2_verify_write(). This allows
concurrent verification calls to proceed independently without
contending for a shared buffer. Additionally, memcmp() is replaced
with a byte-by-byte comparison that pinpoints the exact mismatch
offset, rather than merely reporting equal or not-equal.

Add verification calls in jffs2_flash_writev() for direct page
writes, and in jffs2_flash_direct_write() and
jffs2_flash_direct_writev() for NOR and other non-writebuffered
devices.

Since verification now covers all write paths rather than only the
write-buffer path, rename CONFIG_JFFS2_FS_WBUF_VERIFY to
CONFIG_JFFS2_FS_WRITE_VERIFY and remove the Kconfig dependency on
CONFIG_JFFS2_FS_WRITEBUFFER.

Add a module parameter write_verify (default off, 0644) to allow
dynamic enable/disable of write verification at runtime, so kernels
can carry the diagnostic facility without read-back overhead until
fault isolation is required. The parameter can be accessed through:

    /sys/module/jffs2/parameters/write_verify

This remains an optional diagnostic aid; node CRCs continue to provide
JFFS2's normal on-media integrity check.

zhouminqiang (6):
  jffs2: replace per-superblock verify buffer with per-write buffer
  jffs2: write verify: replace memcmp with byte-by-byte comparison
  jffs2: add write verification to direct page writes in flash_writev
  jffs2: add write verification to NOR direct write paths
  jffs2: rename CONFIG_JFFS2_FS_WBUF_VERIFY to
    CONFIG_JFFS2_FS_WRITE_VERIFY
  jffs2: add runtime toggle for write verification

 fs/jffs2/Kconfig       |  31 +++++++--
 fs/jffs2/jffs2_fs_sb.h |   3 -
 fs/jffs2/os-linux.h    |  11 ++++
 fs/jffs2/wbuf.c        |  86 +++---------------------
 fs/jffs2/writev.c      | 145 ++++++++++++++++++++++++++++++++++++++++-
 5 files changed, 188 insertions(+), 88 deletions(-)

-- 
2.52.0

----- Ursprüngliche Mail -----
> Von: "zhouminqiang" <zhouminqiang2@huawei.com>
> An: "David Woodhouse" <dwmw2@infradead.org>, "richard" <richard@nod.at>
> CC: "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>
> Gesendet: Donnerstag, 20. August 2026 12:49:56
> Betreff: [PATCH 0/6] jffs2: extend write verification to all write paths

> When JFFS2 writes data to flash, it first calculates a node CRC, and
> the NAND controller calculates ECC as the data is programmed. If

Why would one use JFFS2 in 2026 on NAND flash?

> corruption occurs between these two points, the possible causes are
> RAM failures or bus transfer errors before the data reaches the flash,
> or bit flips on the flash medium itself. To distinguish whether the
> corruption happened during the write transfer or after commit to the
> medium, commit a6bc432e296d ("[JFFS2] Add support for write-buffer
> verification") introduced CONFIG_JFFS2_FS_WBUF_VERIFY: reading the
> data back immediately after a successful write and comparing it with
> the in-memory source buffer provides the missing observation point
> for that diagnosis.
> 
> However, the current implementation only performs read-back verification
> on write-buffer flush paths. Two scenarios remain uncovered:
> 
>  1. When the write data length exceeds wbuf_pagesize, the excess data
>  bypasses the write buffer and is written directly to flash via
>  mtd_write() in jffs2_flash_writev(), with no verification.
>  2. NOR Flash and other non-writebuffered devices write directly through
>  jffs2_flash_direct_write() and jffs2_flash_direct_writev(), with no
>  equivalent check.
> 
> In both cases, if MTD reports a successful write but the readable medium
> differs from JFFS2's source buffer, a later node CRC failure cannot
> distinguish transport/program-time corruption from post-commit media
> damage, defeating the original diagnostic intent.
> 
> This series covers both scenarios with the following changes.
> 
> Replace the pre-allocated per-superblock wbuf_verify buffer with
> on-demand allocation inside jffs2_verify_write(). This allows
> concurrent verification calls to proceed independently without
> contending for a shared buffer. Additionally, memcmp() is replaced
> with a byte-by-byte comparison that pinpoints the exact mismatch
> offset, rather than merely reporting equal or not-equal.
> 
> Add verification calls in jffs2_flash_writev() for direct page
> writes, and in jffs2_flash_direct_write() and
> jffs2_flash_direct_writev() for NOR and other non-writebuffered
> devices.
> 
> Since verification now covers all write paths rather than only the
> write-buffer path, rename CONFIG_JFFS2_FS_WBUF_VERIFY to
> CONFIG_JFFS2_FS_WRITE_VERIFY and remove the Kconfig dependency on
> CONFIG_JFFS2_FS_WRITEBUFFER.
> 
> Add a module parameter write_verify (default off, 0644) to allow
> dynamic enable/disable of write verification at runtime, so kernels
> can carry the diagnostic facility without read-back overhead until
> fault isolation is required. The parameter can be accessed through:
> 
>    /sys/module/jffs2/parameters/write_verify
> 
> This remains an optional diagnostic aid; node CRCs continue to provide
> JFFS2's normal on-media integrity check.

Please explain why this is needed.
JFFS2 is in "Odd fixes" maintenance mode.
It never worked well for NAND flash, that's why UBIFS (JFFS3) was born.

Thanks,
//richard

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,
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.

在 2026/8/21 2:58, Richard Weinberger 写道:
> ----- Ursprüngliche Mail -----
>> Von: "zhouminqiang" <zhouminqiang2@huawei.com>
>> An: "David Woodhouse" <dwmw2@infradead.org>, "richard" <richard@nod.at>
>> CC: "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>
>> Gesendet: Donnerstag, 20. August 2026 12:49:56
>> Betreff: [PATCH 0/6] jffs2: extend write verification to all write paths
> 
>> When JFFS2 writes data to flash, it first calculates a node CRC, and
>> the NAND controller calculates ECC as the data is programmed. If
> 
> Why would one use JFFS2 in 2026 on NAND flash?
> 
>> corruption occurs between these two points, the possible causes are
>> RAM failures or bus transfer errors before the data reaches the flash,
>> or bit flips on the flash medium itself. To distinguish whether the
>> corruption happened during the write transfer or after commit to the
>> medium, commit a6bc432e296d ("[JFFS2] Add support for write-buffer
>> verification") introduced CONFIG_JFFS2_FS_WBUF_VERIFY: reading the
>> data back immediately after a successful write and comparing it with
>> the in-memory source buffer provides the missing observation point
>> for that diagnosis.
>>
>> However, the current implementation only performs read-back verification
>> on write-buffer flush paths. Two scenarios remain uncovered:
>>
>>   1. When the write data length exceeds wbuf_pagesize, the excess data
>>   bypasses the write buffer and is written directly to flash via
>>   mtd_write() in jffs2_flash_writev(), with no verification.
>>   2. NOR Flash and other non-writebuffered devices write directly through
>>   jffs2_flash_direct_write() and jffs2_flash_direct_writev(), with no
>>   equivalent check.
>>
>> In both cases, if MTD reports a successful write but the readable medium
>> differs from JFFS2's source buffer, a later node CRC failure cannot
>> distinguish transport/program-time corruption from post-commit media
>> damage, defeating the original diagnostic intent.
>>
>> This series covers both scenarios with the following changes.
>>
>> Replace the pre-allocated per-superblock wbuf_verify buffer with
>> on-demand allocation inside jffs2_verify_write(). This allows
>> concurrent verification calls to proceed independently without
>> contending for a shared buffer. Additionally, memcmp() is replaced
>> with a byte-by-byte comparison that pinpoints the exact mismatch
>> offset, rather than merely reporting equal or not-equal.
>>
>> Add verification calls in jffs2_flash_writev() for direct page
>> writes, and in jffs2_flash_direct_write() and
>> jffs2_flash_direct_writev() for NOR and other non-writebuffered
>> devices.
>>
>> Since verification now covers all write paths rather than only the
>> write-buffer path, rename CONFIG_JFFS2_FS_WBUF_VERIFY to
>> CONFIG_JFFS2_FS_WRITE_VERIFY and remove the Kconfig dependency on
>> CONFIG_JFFS2_FS_WRITEBUFFER.
>>
>> Add a module parameter write_verify (default off, 0644) to allow
>> dynamic enable/disable of write verification at runtime, so kernels
>> can carry the diagnostic facility without read-back overhead until
>> fault isolation is required. The parameter can be accessed through:
>>
>>     /sys/module/jffs2/parameters/write_verify
>>
>> This remains an optional diagnostic aid; node CRCs continue to provide
>> JFFS2's normal on-media integrity check.
> 
> Please explain why this is needed.
> JFFS2 is in "Odd fixes" maintenance mode.
> It never worked well for NAND flash, that's why UBIFS (JFFS3) was born.
> 
> Thanks,
> //richard

----- 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

On Thu, 2026-08-20 at 20:58 +0200, Richard Weinberger wrote:
> 
> Please explain why this is needed.
> JFFS2 is in "Odd fixes" maintenance mode.
> It never worked well for NAND flash, that's why UBIFS (JFFS3) was
> born.

JFFS2 works OK for NAND flash. We got it running with up to 1GiB of
NAND for OLPC.

It doesn't scale well past that, with both memory usage and mount time,
but it's still in active use on NAND in a bunch of embedded platforms
(including OpenWRT routers).