Difference between revisions of "Support read-only block filesystems on MTD flash"

From eLinux.org
Jump to: navigation, search
(Description: Fixed paragraphs)
m (Contractor Candidates)
 
(2 intermediate revisions by one other user not shown)
Line 44: Line 44:
 
== Related work ==
 
== Related work ==
  
* 'ubiblk' patches were developed in 2008, but never made it into
+
* '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.
  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
+
* "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.
  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,
+
* 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:  
  but it is through MTD emulation:
+
 
   MTD -> UBI -> gluebi -> MTD -> mtdblock
 
   MTD -> UBI -> gluebi -> MTD -> mtdblock
  This is probably too complex to be efficient.
 
  
 
== Scope ==
 
== Scope ==
Line 61: Line 55:
 
Here is the expected amount of work for the first two parts:
 
Here is the expected amount of work for the first two parts:
  
* bad-block aware MTD block device for read-only filesystems
+
* bad-block aware MTD block device for read-only filesystems: 4 weeks
  4 weeks
+
* UBI block device: 4 weeks
* UBI block device:
+
  4 weeks
+
  
 
These tasks would be implemented in close relationship with the MTD and UBI
 
These tasks would be implemented in close relationship with the MTD and UBI
Line 73: Line 65:
 
* Linux MTD developers
 
* Linux MTD developers
  
* Philip Lougher, SquashFS developer
+
* Phillip Lougher, SquashFS developer
  
 
* Development could be taken care of by my company (Free Electrons)
 
* Development could be taken care of by my company (Free Electrons)

Latest revision as of 00:28, 8 February 2011

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.
  • 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.
  • 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:
 MTD -> UBI -> gluebi -> MTD -> mtdblock

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)

Comments