Re: [EXT] [PATCH v2 3/3] mtd: rawnand: micron: Address the shallow erase issue

From: Boris Brezillon <boris.brezillon@collabora.com>
To: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	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>,
	"Bean Huo \(beanhuo\)" <beanhuo@micron.com>
Subject: Re: [EXT] [PATCH v2 3/3] mtd: rawnand: micron: Address the shallow erase issue
Date: Wed, 6 May 2020 21:01:58 +0200	[thread overview]
Message-ID: <20200506210158.7fe33cec@collabora.com> (raw)
In-Reply-To: <1414270659.192477.1588790669444.JavaMail.zimbra@nod.at>

On Wed, 6 May 2020 20:44:29 +0200 (CEST)
Richard Weinberger <richard@nod.at> wrote:

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

I'd expect UBI to just mark the LEB as bad and schedule it for erasure
(again, pretty similar to an interrupted erase).

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

Duh. What happens when you have ECC errors? Does that stop the mount?
Shouldn't we make that part more robust?

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

I really hate the idea of having FS-specific logic in the Micron
quirk. Isn't there a way we can fix that in UBIFS? Plus, do we have any
guarantee that the EC/VID headers will be corrupted along with UBIFS
data when an erase is interrupted?

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