[PATCH 0/6] jffs2: extend write verification to all write paths
Richard Weinberger
richard at nod.at
Thu Aug 20 11:58:21 PDT 2026
----- Ursprüngliche Mail -----
> Von: "zhouminqiang" <zhouminqiang2 at huawei.com>
> An: "David Woodhouse" <dwmw2 at infradead.org>, "richard" <richard at nod.at>
> CC: "linux-mtd" <linux-mtd at lists.infradead.org>, "linux-kernel" <linux-kernel at vger.kernel.org>, "chengzhihao1"
> <chengzhihao1 at huawei.com>, "yangerkun" <yangerkun at huawei.com>, "yi zhang" <yi.zhang at 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
More information about the linux-mtd
mailing list