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

[Ricard Wanderlof]

On Mon, 7 May 2012, Thilo Fromm wrote:

>>> But unfortunately I can use these features with nothing else than UBIFS?
>>
>> Well, you can use it for large binary objects, such as the Linux kernel, if
>> you want. There are currently no other filesystems other than ubifs which
>> run directly on top of UBI, but if you enable the gluebi layer, you get mtd
>> devices on top of each ubi volume so you can use jffs2 if you want.
>
> 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.

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.

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

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30