Support read-only block filesystems on MTD flash


 * Summary: support read-only block filesystems on MTD flash


 * Proposer: Michael Opdenacker 

Description
Our flash filesystem benchmarks have shown that SquashFS exhibits great mount time and good read speeds compared to the other flash filesystems (jffs2, yaffs2 and ubifs).

See http://free-electrons.com/pub/conferences/2008/elce/flash-filesystems.pdf

SquashFS is a block filesystem, but since it is read-only, it can be also used on a /dev/mtdblock device, because it will never attempt to write on any block. The same applies to other block filesystems, provided they are mounted in read-only mode.

The problem is that /dev/mtdblock, the block interface to MTD device , is not bad-block aware, and therefore can't be used reliably to mount read-only block filesystems. It will only work if you are lucky to have a board with no bad MTD blocks, as we were when we first benchmarked SquashFS on MTD.

The goals of this project are to make it possible to use read-only filesystems in a reliable way on top of MTD flash storage.

This could be achieved in multiple ways:


 * By implementing a bad-block aware block device of top of MTD, perhaps not a generic one, but limited to the needs of read-only filesystems.


 * By implementing a generic block device on top of UBI, for systems which use UBI to implement global wear leveling (without UBI, wear leveling can only be implemented locally, by each filesystem).


 * If SquashFS is identified as a priority, another idea would be to implement SquashFS back-ends for MTD and UBI. The solution wouldn't benefit other filesystems though.

The expected benefits are:


 * Ability to use Squashfs on MTD flash: tiny mount time, good compression, good read performance.


 * Ability to experiment with newer filesystems such as btrfs, in read-only mode, of course. btrfs shows great performance on flash based block storage (see http://elinux.org/images/d/d7/Elce2010-flash-filesystems.pdf).


 * A read-write block device on top of UBI would allow to implement hibernation to flash, in particular.

Related work

 * 'ubiblk' patches were developed in 2008, but never made it into mainline, and apparently haven't been heard of since then. We could revive this project.


 * "Nand Flash Translation Layer" (NTFL) already exists in the Linux kernel, to provide a block layer on NAND flash, but its usability is restricted by conflicts with software patents.

MTD -> UBI -> gluebi -> MTD -> mtdblock
 * It is already possible to use a reliable block device on UBI, but it is through MTD emulation. This is probably too complex to be efficient:

Scope
Here is the expected amount of work for the first two parts:


 * bad-block aware MTD block device for read-only filesystems: 4 weeks
 * UBI block device: 4 weeks

These tasks would be implemented in close relationship with the MTD and UBI developer communities, to minimize mainstreaming costs.

Contractor Candidates

 * Linux MTD developers


 * Phillip Lougher, SquashFS developer


 * Development could be taken care of by my company (Free Electrons)