[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAyq3SZmuTPrEb4i7QR-4Gi6YWsLFGOGm9=a0UvLR5rMLiLxsA@mail.gmail.com>
Date: Fri, 12 Sep 2025 15:57:36 +0800
From: Cheng Ming Lin <linchengming884@...il.com>
To: Richard Weinberger <richard@....at>
Cc: chengzhihao1 <chengzhihao1@...wei.com>, Miquel Raynal <miquel.raynal@...tlin.com>,
Vignesh Raghavendra <vigneshr@...com>, linux-mtd <linux-mtd@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>, Alvin Zhou <alvinzhou@...c.com.tw>,
leoyu <leoyu@...c.com.tw>, Cheng Ming Lin <chengminglin@...c.com.tw>
Subject: Re: [RFC] mtd: ubi: skip programming unused bits in ubi headers
Hi Richard,
Richard Weinberger <richard@....at> 於 2025年9月12日 週五 下午3:57寫道:
>
> ----- Ursprüngliche Mail -----
> > Von: "Cheng Ming Lin" <linchengming884@...il.com>
> >> That's the crucial question. Is this true for all NAND chips?
> >> Do avoid larger writes of 0xFF patterns file systems such as UBIFS
> >> also use compression a lot.
> >> At least that's what I have been told when I asked 10+ years ago
> >> how UBI works.
> >
> > You are correct that there is an issue when blank data pages are repeatedly
> > erased. This can lead to cells entering a too deep VT state, which may
> > cause program failures in subsequent operations.
> >
> > To address this, newer NAND generations typically perform a pre-program
> > step before executing the actual erase. This keeps the VT distribution from
> > going too deep, thereby avoiding the blank-page degradation problem.
> > Such pre-PGM techniques have been widely adopted for roughly the past
> > 10–15 years.
> >
> > Additionally, JESD22-A117E (page 6, section 4.1.2.1) specifies examples of
> > acceptable data patterns, including solid-programmed, checkerboard/inverse-
> > checkerboard, and checkerboard-with-fill patterns. According to
> > qualification knowledge bases, using 0x00 can sometimes trigger special
> > failure modes, whereas writing 0xFF is more robust.
> >
> > Additionally, the Kioxia TC58NVG1S3HTA00 datasheet (page 63) also notes
> > that continuous program/erase cycling with a high percentage of ‘0'
> > bits in the data pattern can accelerate block endurance degradation.
> > This further supports avoiding large 0x00 patterns.
>
> Thanks for the detailed answer!
> So, yes let's apply this change.
Sorry, I need to adjust the code a bit, since I just noticed my
condition on vid_hdr shift was incorrect. I will send a v2 version.
>
> Thanks,
> //richard
Thanks,
Cheng Ming Lin
Powered by blists - more mailing lists