public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: "Bean Huo (beanhuo)" <beanhuo@micron.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	"Zoltan Szubbocsev \(zszubbocsev\)" <zszubbocsev@micron.com>,
	Steve deRosier <derosier@gmail.com>,
	Boris Brezillon <boris.brezillon@collabora.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: Wed, 6 May 2020 20:44:29 +0200 (CEST)	[thread overview]
Message-ID: <1414270659.192477.1588790669444.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <BN7PR08MB56843895500F4ADA88262C59DBA40@BN7PR08MB5684.namprd08.prod.outlook.com>

Bean, Boris,

----- Ursprüngliche Mail -----
>> > 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.

Uhh. Damaging just payload asks for trouble.

>> > 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.

Sadly it is not so easy.

IIRC the UBIFS log ring is such a corner case, it uses a fixed LEB range for
this purpose. Before writing to a new LEB it unmaps it. If the resulting erase operation
is interrupted before a new version of the same LEB is written reading from that
LEB would result in ECC errors.
 
> Would you please help us confirm this?  how does ubifs handle this situation?
> Also other FS? Eg, jffs2, yaffs

There are cases where (partially) erased LEBs are still referenced.
UBIFS assumes that a LEB it unmaps is after a power-cut either 0xFF or intact.
In relies in the fact that UBI will detect an interrupted erase operation and
re-erases the PEB.
Fastmap once violated this rule, it took years until the first user hit this.

So please make sure that the VID header will be destroyed.

JFFS2 needs also thoughts, let me check the source.

YAFFS is out tree and therefore out of mind.

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2020-05-06 18:44 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 [this message]
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=1414270659.192477.1588790669444.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=WojtaszczykP@cumminsallison.com \
    --cc=beanhuo@micron.com \
    --cc=boris.brezillon@collabora.com \
    --cc=derosier@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox