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

[Richard Weinberger <richard@xxxxxx>]

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/