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

From eLinux.org
Jump to: navigation, search
(added body to page: support read-only block filesystems on MTD flash)
 
m (Contractor Candidates)
 
(3 intermediate revisions by one other user not shown)
Line 28: Line 28:
 
This could be achieved in multiple ways:
 
This could be achieved in multiple ways:
  
* By implementing a bad-block aware block device of top of MTD,
+
* 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.
  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
+
* 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).
  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
+
* 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.
  to implement SquashFS back-ends for MTD and UBI. The solution
+
  wouldn't benefit other filesystems though.
+
  
 
The expected benefits are:
 
The expected benefits are:
  
* Ability to use Squashfs on MTD flash: tiny mount time,
+
* Ability to use Squashfs on MTD flash: tiny mount time, good compression, good read performance.
  good compression, good read performance.
+
  
* Ability to experiment with newer filesystems such as btrfs,
+
* 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).
  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
+
* A read-write block device on top of UBI would allow to implement hibernation to flash, in particular.
  hibernation to flash, in particular.
+
  
 
== 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 72: 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 84: 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