[RFC] mtd: ubi: skip programming unused bits in ubi headers

Cheng Ming Lin linchengming884 at gmail.com
Thu Aug 14 03:11:07 PDT 2025


Hi Richard,

Richard Weinberger <richard at nod.at> 於 2025年8月12日 週二 下午2:57寫道:
>
> ----- Ursprüngliche Mail -----
> > Von: "Cheng Ming Lin" <linchengming884 at gmail.com>
> > An: "richard" <richard at nod.at>, "chengzhihao1" <chengzhihao1 at huawei.com>, "Miquel Raynal" <miquel.raynal at bootlin.com>,
> > "Vignesh Raghavendra" <vigneshr at ti.com>, "linux-mtd" <linux-mtd at lists.infradead.org>, "linux-kernel"
> > <linux-kernel at vger.kernel.org>
> > CC: "Alvin Zhou" <alvinzhou at mxic.com.tw>, leoyu at mxic.com.tw, "Cheng Ming Lin" <chengminglin at mxic.com.tw>
> > Gesendet: Dienstag, 12. August 2025 07:19:49
> > Betreff: [RFC] mtd: ubi: skip programming unused bits in ubi headers
>
> > From: Cheng Ming Lin <chengminglin at mxic.com.tw>
> >
> > This patch prevents unnecessary programming of bits in ec_hdr and
> > vid_hdr that are not used or read during normal UBI operation. These
> > unused bits are typically already set to 1 in erased flash and do not
> > need to be explicitly programmed to 0 if they are not used.
> >
> > Programming such unused areas offers no functional benefit and may
> > result in unnecessary flash wear, reducing the overall lifetime of the
> > device. By skipping these writes, we preserve the flash state as much
> > as possible and minimize wear caused by redundant operations.
>
> We talk about programming a single (sub)page, right?

Since the UBI header is mainly written into a single page, the "unused
areas" here refer to the space within a single (sub)page that is outside
the header content.

>
> > This change ensures that only necessary fields are written when
> > preparing UBI headers, improving flash efficiency without affecting
> > functionality.
>
> I have been told that writing 0xFF bytes to NAND should be avoided.
> This is also why UBI initializes them to 0x00.

Normally, after a NAND flash block is erased, all bits are in the 0xFF
state. Programming 0xFF in this case will not actually change the NAND
cells, as the device can inhibit programming—either by raising the
bitline voltage or using a self-boosted program inhibit mechanism.
Therefore, programming 0xFF is a normal and harmless operation for NAND
flash.

>
> Do you have data which proves the opposite?

I am currently collecting relevant data, and will present it once it is
ready. Thank you.

>
> Thanks,
> //richard

Thanks,
Cheng Ming Lin



More information about the linux-mtd mailing list