Re: [PATCH 0/6] jffs2: extend write verification to all write paths

----- Ursprüngliche Mail -----
> Von: "zhouminqiang" <[email protected]>
> An: "David Woodhouse" <[email protected]>, "richard" <[email protected]>
> CC: "linux-mtd" <[email protected]>, "linux-kernel" <[email protected]>, "chengzhihao1"
> <[email protected]>, "yangerkun" <[email protected]>, "yi zhang" <[email protected]>
> 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