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

[Ricard Wanderlof]

On Wed, 2 May 2012, Thilo Fromm wrote:

>> One way is to use a file system intended for flashes, but mount it
>> read-only. I.e. use a jffs2 filesystem, mounted readonly.
>
> Yupp, or I coud hack up SquashFS to be bad blocks aware. However, it
> feels kind of wrong to me to leave bad block handling to the file
> system layer. Because I would have to provide bad block awareness to
> every read-only FS I am planning to use. Over and over again.

I principally agree, however, jffs2 is doing just that, managing bad 
blocks. Whether that is a good idea or not is debatable of course. 
Technically it mixes up file system and device properties. Also, you might 
not plan to change read-only FS's very often so the effort might be quite 
minimal in practice.

>> Or, let UBI handle the flash, and use ubifs in a static volume, which means
>> it will be non-writable. Last time I checked it wasn't possible to use file
>> systems such as cramfs on UBI, because UBI did not supply a block device
>> which is required by cramfs. I seem to remember some patch to add block
>> devices to UBI, not sure what the state of that is.
>
> I think a simpler option would be to have your (read-only squash-)root
> FS image in a static UBI volume and mount it via loop-back. This is
> currently our fallback option. Still this feels like way too much
> overhead for what we're looking for.

Interting, it never occurred to me that that was possible. I always think 
of loopback mounts for mounting things like files as cdrom drives. How do 
you specify a loopback mount for the rootfs on the kernel command line?

> It's rather easy for both boot loader and Linux to write to a raw
> flash device, skipping bad blocks along the way. It's also easy for
> the boot loader to read back what was written, also skipping bad
> blocks. Finally, using an user space tool like "nanddump", I can read
> back what *really* has been written without a problem.
>
> Unfortunately it seems to be impossible to provide this read behavior
> via an MTD API to other parts of the linux kernel. All the workarounds
> seem such a waste, and this bad block-free read-only API seems such a
> good idea for a lot of things I'm really curious why the work on
> something as cool as MTD_BLOCK_RO_BBFREE  ceased in 2006.

I don't know for sure, but I think the majority of flash subsystem effort 
has been centered around UBI and ubifs; for instance, there is very little 
(if any) development on jffs2 nowadays, with all the effort going into 
ubifs (and yaffs, different mailing list). One of the main points of UBI 
is to handle bad blocks, consequently with UBI in the mainstream kernel 
for a while now, most other efforts have a limited appeal.

Linutronix have made a small UBI library for reading static UBI volumes 
which is suitable for boot loaders, so that one can have the kernel 
residing in a UBI volume and get all the benefits of bad block management 
etc even at that level.

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

All pathes would be welcome; I'm sure there are others who would find such 
an approach beneficial, even if I think UBI is probably the way to go 
these days.

/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