[RFC] read-only filesystem support for NAND flash devices

Vitaly Wool
2006-05-10T09:52:13Z

Hi folks,

there had recently been some talks around $Subject... and I'm personally
interested in implementing that, both professionally and as an
open-source guy :)

The problem, as most of you know well, is that currently existing
compressed read-only filesystems don't support bad block handling. OTOH,
it's quite an attractive idea to use those for root filesystem of an
embedded device.
As a filesystem is read-only, wear-out can't occur during the normal
use, only on root filesystem upgrade. Therefore writing it using a tool
like nandwrite that bypasses bad blocks seems to be enough, and the only
thing needed is either an in-MTD layer that makes a partition look as if
there's no babd blocks, or similar means within a filesystem.

The only known implementation goes the former way (though I recall some
attempts for squashfs to implement the latter one). It's at
http://lists.infradead.org/pipermail/linux-mtd/2004-May/009695.html.
The main drawbacks I see in the implementation are:
- adds more functions/vars to struct mtd_info which is apparently a bad
idea (it's already overcomplicated)
- modifies a lot of generic files (i. e. CFI command set
implementations, etc.)
- possibly exposed to FTL/NFTL patents

What I'd like to suggest is to rework this patch to get rid of these
(and probably some more) drawbacks.
Ideas:
1. Implement it on top of NAND layer.
- use NAND bad block table, but make its construction lazy in order
to decrease boot time (might be a useful idea anyway)
- use tree-like structure to calculate the offset between the block
number supplied and the actual block to read (alternatively, just add
the how-many-to-add info to BBT entries)
2. Implement it on top of MTD layer.
- might be reasonable to use mtdblock_ro for that
- might be reasonable to make bad block table global for all MTD
devices, not for NAND only and, once again, add an option to construct
it lazily.

Comments, corrections and suggestions are welcome.

Thx,
Vitaly