From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Bean Huo (beanhuo)" <beanhuo@micron.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Richard Weinberger <richard@nod.at>,
Steve deRosier <derosier@gmail.com>,
"Zoltan Szubbocsev \(zszubbocsev\)" <zszubbocsev@micron.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
tglx <tglx@linutronix.de>,
Piotr Wojtaszczyk <WojtaszczykP@cumminsallison.com>
Subject: Re: [EXT] [PATCH v2 3/3] mtd: rawnand: micron: Address the shallow erase issue
Date: Thu, 7 May 2020 11:40:44 +0200 [thread overview]
Message-ID: <20200507114044.1f0b51af@collabora.com> (raw)
In-Reply-To: <BN7PR08MB568434AC9C9168C016CC1592DBA50@BN7PR08MB5684.namprd08.prod.outlook.com>
On Thu, 7 May 2020 09:28:29 +0000
"Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
> Hi, Boris, Richard
>
> > >
> > > A missing VID header plus good payload will cause UBI to stop
> > > attaching since it violates the IO model.
> >
> > Sure, and that's not what we want to do anyway. We basically have 2 choices
> > here:
> >
> > 1/ overwrite all pages starting from page 0 and ending at page 15. This will lead
> > to ECC errors on already written pages, and 0-filled pages for others (unless we
> > go for a raw write, in which case it might actually lead to ECC errors depending
> > on the engine).
>
> No need for overwriting all pages. I overwrite EC and VID page just for prevent of
> Erase power loss issue. But you hate this since FS-specific approach.
> According to Richard's emails, we don't need to overwrite page0, overwrite page1
> Is enough.
It's still UBI specific, so that's still a no-go for me.
>
> > 2/ track already written pages (by reading them first), and only writes those that
> > have not been written yet. That means no ECC error in that case, and no
> > corrupted EC/VID header as well.
>
> This is similar with my patch approach, but corrupted EC and VID headers.
>
> I have two proposals:
> 1. rebase my patch, and copy one idea from Miquel's patch which records the programmed pages.
> But page 1 should be overwrote considering the UBIFS re-erase mechanism.
See above, and remember we do all that because Micron broke one of the
base assumptions we have about NANDs => erase should reset all bits to
1 or return an error if that fails.
>
> 2. add a new padding structure in the MTD, which is used to filling empty page in the MTD.
> And once FS layer detects this padding data, just ignore or trigger re-erase this block.
Not sure what you mean by padding structure, but yes, filling empty
pages with 0s and expecting the FS/wear-leveling layers to be happy
with that would be ideal. But, as for the "erase only 2-page because
this is where UBI puts its VID header" thing, that's a NACK on my side
if you want to introduce a new pattern that's only understood by
UBI/UBIFS.
I really wish FS/wear-leveling layers were immune to corrupted/invalid
LEBs they should no longer reference, but according to Richard, that's
not that simple.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-05-07 9:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-03 11:40 [PATCH v2 0/3] Fix proposal for the Micron shallow erase issue Miquel Raynal
2020-05-03 11:40 ` [PATCH v2 1/3] mtd: rawnand: Add the nand_chip->erase hook Miquel Raynal
2020-05-03 15:01 ` Boris Brezillon
2020-05-03 11:40 ` [PATCH v2 2/3] mtd: rawnand: Add the nand_chip->write_oob hook Miquel Raynal
2020-05-03 15:09 ` Boris Brezillon
2020-05-03 17:02 ` Miquel Raynal
2020-05-03 11:40 ` [PATCH v2 3/3] mtd: rawnand: micron: Address the shallow erase issue Miquel Raynal
2020-05-03 16:10 ` Steve deRosier
2020-05-03 16:34 ` Boris Brezillon
2020-05-03 16:36 ` Miquel Raynal
2020-05-03 19:57 ` Steve deRosier
2020-05-06 8:37 ` [EXT] " Bean Huo (beanhuo)
2020-05-06 8:28 ` [EXT] " Bean Huo (beanhuo)
2020-05-06 8:45 ` Boris Brezillon
2020-05-06 15:50 ` Bean Huo (beanhuo)
2020-05-06 16:04 ` Boris Brezillon
2020-05-06 16:09 ` Bean Huo (beanhuo)
2020-05-06 16:29 ` Boris Brezillon
2020-05-06 16:50 ` Bean Huo (beanhuo)
2020-05-06 18:44 ` Richard Weinberger
2020-05-06 19:01 ` Boris Brezillon
2020-05-06 19:23 ` Richard Weinberger
2020-05-06 20:40 ` Boris Brezillon
2020-05-06 20:59 ` Richard Weinberger
2020-05-06 21:11 ` Boris Brezillon
2020-05-07 9:28 ` Bean Huo (beanhuo)
2020-05-07 9:40 ` Boris Brezillon [this message]
2020-05-07 9:28 ` Bean Huo (beanhuo)
2020-05-07 9:30 ` Boris Brezillon
2020-05-07 10:02 ` Richard Weinberger
2020-05-07 12:20 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200507114044.1f0b51af@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=WojtaszczykP@cumminsallison.com \
--cc=beanhuo@micron.com \
--cc=derosier@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=tglx@linutronix.de \
--cc=thomas.petazzoni@bootlin.com \
--cc=vigneshr@ti.com \
--cc=zszubbocsev@micron.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.