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@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
Piotr Wojtaszczyk <WojtaszczykP@cumminsallison.com>
Subject: Re: [EXT] [PATCH v2 3/3] mtd: rawnand: micron: Address the shallow erase issue
Date: Wed, 6 May 2020 18:29:10 +0200 [thread overview]
Message-ID: <20200506182910.6a9863bd@collabora.com> (raw)
In-Reply-To: <BN7PR08MB56843895500F4ADA88262C59DBA40@BN7PR08MB5684.namprd08.prod.outlook.com>
On Wed, 6 May 2020 16:09:19 +0000
"Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
> Hi, Richard
>
> > > > > > + }
> > > > >
> > > > >
> > > > > Here, if the power loss happens before erasing this block, for the
> > > > > next time boot up, What will happen from FS layer in case FS
> > > > > detect this filled
> > > > data?
> > > >
> > > > Most likely ECC errors will be returned, but that doesn't matter
> > > > since this block was about to be erased. You have pretty much the
> > > > same problem for partially erase blocks already, and that should be
> > > > handled by the wear-leveling/FS, if not, that would be bug (note
> > > > that it's properly handled by UBI, which just considers the block as invalid and
> > schedules an erase).
> > > >
> > >
> > > Concerning this, I still have question, for the UBIFS, If I am
> > > correct, there are EC and VID header both being damaged, then UBIFS
> > > will re-erase it. I don't know if UBIFS can handle there is dirty/filling data in the
> > some pages and EC/VID valid.
> > > Maybe Richard has fixed it.
> >
> > If the block is being erased that means there's another one mapped to the same
> > LEB, or the block is simply not needed anymore. In both cases, this old block
> > shouldn't be referenced. Again, if that happens, it's a bug.
>
> Would you please help us confirm this? how does ubifs handle this situation? Also other FS? Eg, jffs2, yaffs
>
And if you're really worried about that, forcibly writing all pages
starting from 0 should do the trick. But I don't think that's needed.
As I said, when you trigger an erase, you're not guaranteed the erase
will complete before a potential power-cut, meaning that part of your
data might still be valid, while others could be corrupted.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-05-06 16:29 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 [this message]
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
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=20200506182910.6a9863bd@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.