Support read-only block filesystems on MTD flash

From eLinux.org
Revision as of 18:06, 31 January 2011 by Wmat (talk | contribs) (added body to page: support read-only block filesystems on MTD flash)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Summary
support read-only block filesystems on MTD flash
Proposer
Michael Opdenacker <michael@free-electrons.com>

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<x> 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<x>, the block interface to MTD device <x>, 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 software patents.
  • It is already possible to use a reliable block device on UBI,
 but it is through MTD emulation:
 MTD -> UBI -> gluebi -> MTD -> mtdblock
 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
  • Philip Lougher, SquashFS developer
  • Development could be taken care of by my company (Free Electrons)

Comments