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

[Thilo Fromm]

Hello Ricard,

>> That's a bit much. What do I gain from a kernel in mtd/UBI instead of
>> putting it directly into a plain MTD?
>
> UBI performs bit scrubbing for you if you have a flash that requires it.
> Since the kernel is normally read by a bootloader however, you might have to
> do the occasional read on the kernel when the Linux system is up and running
> to trigger it. It still is much less work than "manually" scanning the mtd
> and rewritting blocks that seem to have bits flipping.

Agreed. I learned from this thread that scrubbing is almost a
necessity. I'm actually thinking about adding a very simple scrubbing
mechanism to blockrom. One could argue that another scrubbing
mechanism is redundant since UBI already does scrubbing. But then UBI
is r/w and there's a lot of things you don't have to care about if you
limit yourself to r/o access.

> By putting a bunch of UBI volumes in one UBI partition you also get the
> benifit of having UBI manage bad blocks for you, and you can have one large
> pool of bad blocks rather than an individual pool of bad blocks for each
> mtd, which in the end translates to better usage of the flash.
>
> These things may or may not be important to you, depending on how much flash
> you have and how reliable it is.

The most important point for me is whether you use your flash, or a
specific partition of your flash, in read-only or read-write mode.
When operating in r/o mode I don't quite see a point in most of the
more advanced stuff UBI does, e.g. wear leveling.

>>> Technically I suppose one could device a "jffs2a" to run directly on a
>>> UBI
>>> device, but it would be rather pointless; we have a "jffs3" which turned
>>> into ubifs in the end.
>>
>>
>> And I think you did some excellent work with the UBI/UBIFS stack. It's
>> the way to go when you need a flash-aware r/w fs. The drawback is that
>> handling and maintenance of UBI filesystems is still a bit "special"
>> (as in: things don't work like they do with other, more generic, file
>> systems). And one side effect of this "specialness" is that you're
>> currently seem to be limited to the MTD/UBI stack and can't use other
>> file systems on MTDs.
>
>
> The basic problem is that flash devices are not disks. "Normal" file systems
> are designed to work well with disk-based media. They are not intended to
> (and don't) work well with flash media. Flash Translation Layer solutions
> tend to be clumsy and/or unreliable, because you're basiclly trying to
> pretend a device of one type is really another type. So in the end, if you
> are using flash-based media you are going to need an fs which is designed
> for the job. I know that that might seem like the properties of the physical
> layer 'bleeding through' to the file system layer, but on the other hand, if
> you want to look at it that way, it's the same problem with ordinary file
> systems which assume that the underlying meda is a disk with a read/write
> sector size in the kilobyte range, and no penalties for extraneous writes.

Ah, okay, I see, and I do completely follow you with this when it's
about r/w file systems. Sometimes it is better to expose specifics of
a lower level if it is only badly abstracted, or, to put it in simpler
words, if you cannot gracefully degrade, then you should escalate.

I do miss a very simple r/o layer, though. I think there is a strong
use case for read-only file systems; especially in the embedded world.
And all things necessary - bad-block handling, scrubbing -
 can be abstracted well enough for a simple r/o block device at a very
low level.

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