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

[Richard Weinberger <richard@xxxxxx>]

----- Ursprüngliche Mail -----
> Von: "Boris Brezillon" <boris.brezillon@xxxxxxxxxxxxx>
> An: "richard" <richard@xxxxxx>
> CC: "Bean Huo, beanhuo" <beanhuo@xxxxxxxxxx>, "Miquel Raynal" <miquel.raynal@xxxxxxxxxxx>, "Vignesh Raghavendra"
> <vigneshr@xxxxxx>, "Tudor Ambarus" <Tudor.Ambarus@xxxxxxxxxxxxx>, "linux-mtd" <linux-mtd@xxxxxxxxxxxxxxxxxxx>, "Steve
> deRosier" <derosier@xxxxxxxxx>, "Thomas Petazzoni" <thomas.petazzoni@xxxxxxxxxxx>, "tglx" <tglx@xxxxxxxxxxxxx>, "Zoltan
> Szubbocsev, zszubbocsev" <zszubbocsev@xxxxxxxxxx>, "Piotr Wojtaszczyk" <WojtaszczykP@xxxxxxxxxxxxxxxxxx>
> Gesendet: Mittwoch, 6. Mai 2020 21:01:58
> Betreff: Re: [EXT] [PATCH v2 3/3] mtd: rawnand: micron: Address the shallow erase issue

> On Wed, 6 May 2020 20:44:29 +0200 (CEST)
> Richard Weinberger <richard@xxxxxx> 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).

UBI scans only headers during attach. If you don't touch these, no way.

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

UBIFS stops if there are *unexpected* ECC errors.
The last node in the last node group of the last log LEB is allowed to have ECC errors.

I get where you trying to head to. Let me give this a deep thought and re-read
the fixes for fastmap I did a few years ago.

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

And I hate the idea of changing UBIFS semantics. ;-)

I think you read equally much NAND datasheets as I did, so you know how often
they guarantee something. ;-)
UBIFS (actually UBI) assumes that interrupted erase will cause ECC errors across
the whole PEB.

Thanks,
//richard

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