State of read-only filesystems in NAND / MTD bad blocks handling when reading

[Thilo Fromm]

Hello Ricard,

(sorry for calling you "Richard" in the previous mails :-/ )

>>> Finally Ricard Wanderlof share his experience about bit flipping
>>> during reading and concluded that "At least for this chip [ST 256
>>> Mbit flash], it seemed that if a block has only been written a few
>>> times, then there seems to be virtually no limit to how many times it
>>> can be read without bit flips occurring ".
>>
>>
>> So the bit-rot-after-many-reads-issue is maybe a non-issue?
>
> It wasn't much of an issue when I ran tests on 256 Mbit flashes, but they
> are quite old by know, and starting to be EOL'd by manufacturers. Modern
> flashes have smaller on-chip geometries with physically smaller bit cells,
> and the chances of bits flipping is much greater, if nothing indicated by
> increased requirements in ECC strength. Sometimes the requirement changes
> have been subtle. For instance, for 256 Mbit flashes, most manufacturers
> specified the first block to be always good. For 1 Gbit flashes, this was
> changed to be a 'valid block up to 1k program/erase cycles with 1bit/512
> byte ECC', although the general ECC requirement was the same. Larger flashes
> have 4 bit ECC requirements instead of the old 1 bit ECC, and as chip
> foundries migrate to small geometries older chips get reworked to suit
> modern manufacturing methods, and as a result they also get higher bitflip
> probabilities and consequently severer ECC requirements.
>
> So, I would consider 'read disturb' as the phenomen is normally described to
> be an issue which must be dealt with these days.

Oh, okay, thanks for the info, so we need to take care about bit rot,
too. I don't think this is too big a challenge.

Hey guys, I think I've got a bold idea. Could I re-use parts of UBI's
EB handling code in my readonly FTL? It depends on whether the erase
block scrubbing routines within UBIFS are generic enough to be used by
other components. Or whether the linux-mtd project is interested in
having these routines re-usable at some point in the future when they
are not re-usable right now.

Comments, suggestions?

Regards,
Thilo

-- 
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515 932 228   mailto:fromm at dresearch-fe.de
Fax: +49 (30) 515 932 77    http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB 130120 B
Ust.-IDNr. DE273952058
Geschäftsführer: Dr. M. Weber, W. Mögle