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

[Ricard Wanderlof]

On Mon, 7 May 2012, Thilo Fromm wrote:

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

One could argue though that once you start using UBI for bit scrubbing, 
then wear levelling becomes an issue even on a r/o file system.

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

I'm not too sure. There is a r/o mode in UBI, so-called static volumes, 
which have a fixed size after creation or writing data to them, and have 
built-in checksums for validation. They are primarily intended for blobs 
such as a kernel, but can also be used for read/write file systems.

My biggest gripe about adding another "simple" r/o layer is this: Since 
UBI is stable and maintained, it seems a bit pointless to dilute future 
development and maintenence efforts by introducing another layer which 
basically is a subset of UBI. For instance, future changes to the 
mtd API that affect the layers above will have to be maintained not just 
for UBI but for other mtd users as well. Sure, a parallel layer may be 
simpler, but with UBI already in place and working well, I'm not convinced 
it actually makes a practical difference in the end.

Especially if you are using UBI in your system anyway, but not necessarily 
for you root file system, adding another parallel layer seems rather 
pointless. You've got UBI in your system anyway, why add something else 
that does the same thing just because UBI seems overly convoluted for 
readonly file systems. It does the job and does it well and doesn't cost 
anything since it's there anyway.

If you are really pressed for space in the kernel (in terms of required 
space on the flash or the amount of RAM it consumes run time) I could 
understand that replacing the Big and Grand UBI with something smaller 
might have some value.

/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