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

[Thilo Fromm]

Hello Gregory,

>> Since I really like the idea of a MTD block device that skips bad
>> blocks when reading I'm currently in the process of re-animating the
>> BBFREE patch <http://lists.infradead.org/pipermail/linux-mtd/2006-November/016835.html>:
>> it compiles for me, but still has some major issues. I'll keep this
>> list up to date on my progress.
>
> a few years ago I also tried to reanimated this patch, it was nearly
> adopted, but there were some argue about bit flipping during read or
> why create a new device driver: see
> http://lists.infradead.org/pipermail/linux-mtd/2007-November/019938.html
> and the dozen of email of this thread.

Ah, I see. Well, as I take it  MTD_BLOCK_RO_BBFREE takes care of
reading back what was actually written instead of "inserting" bad
blocks as the current driver does. Bit rot after many, many reads and
the corresponding flash scrubbing routines are a different kind of
problem. MTD_BLOCK_RO_BBFREE does not solve it, or pretend to solve
it.

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

> About "why create a new device driver" vitally Wool explained it was
> explicitly directed by David because he didn't want to add confusion.

Yepp, I get this, and I think it is a good idea. Still not sure
whether the extra device nodes are a good idea, though. Maybe
MTD_BLOCK_RO_BBFREE (and other flash translation layer code) could
work more like a serial line discipline, so kernel or user space can
attach and detach them to MTDs as required.

> But this patch were never merged in the end, maybe I should have to
> push more.
>
> Since this, at Free Electrons we worked on the same kind of feature
> but based on UBI: ubiblk, see http://lwn.net/Articles/452944/
>
> There were still some minor issue that prevents the patches to be
> included in mtd. I hope David will find time to solve them soon.

This doesn't really help us; we're stuck on kernel 2.6.37 and u-boot
2010-06, both heavily modified by patches from Texas Instruments. To
use the new UBI readonly block device we would need to integrate the
latest linux-mtd into both kernel and u-boot, something which I
consider way more complex (and risky) than trying to go with
MTD_BLOCK_RO_BBFREE for now.

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