usefullness of a read-only block UBI interface ?

[Ivan Djelic]

On Tue, May 24, 2011 at 03:53:03PM +0100, David Wagner wrote:
> 	Hello linux-mtd, -embedded and -fsdevel,
> 
> There are a lot of actively developed block filesystems out there, more
> than flash filesystems. Read-only block FS can run with great perfs on
> flash supports with the mtdblock interface (eg. SquashFS) but since it
> doesn't handle bad blocks, read will fail when you hit one.
> 
> That's why we are considering the pros and cons of having a block
> interface on top of UBI: UBI takes care of bad blocks and filesystems
> above it don't have to worry about them.
> 
> An option could be to implement bad block handling in mtdblock but
> then, there wouldn't be any wear-leveling.

Hello David,

Handling bad blocks is one thing, but it would not be enough. I assume you want
to use a nand device (bad blocks ?). Reading nand pages over and over will
result in bitflips (so-called "read disturbs"). Those bitflips are corrected by
ecc in mtd, but they must also be taken care of at a higher level, by
(atomically) moving faulty data to another block and erasing the original
block (which is enough to clear read disturbs). UBI does that in its block
scrubbing operation.

> In case of read-only filesystems, wear-leveling is not so important but
> when read-only and read-write filesystems coexist, static wear-leveling
> is important. And I understand that UBI implements static
> wear-leveling. So it would make sense to have a block read-only
> filesystem on top of UBI along with a ubifs read-write filesystem.

Yes, especially if your read-only filesystem is very large; you need to spread
wear-levelling across the entire device in order to maximize its lifetime.

Regards,

Ivan