Support read-only block filesystems on MTD flash

From eLinux.org
Revision as of 01:06, 1 February 2011 by Wmat (Talk | contribs)

(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>

Contents

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
{"cc_re__cc_re__cc_by_sa_3_0": ["d=\"t-permalink\"><a href=\"/index.php?title=Support_read-only_block_filesystems_on_MTD_flash&amp;oldid=33409\" title=\"Permanent link to this revision of the page\">Permanent link</a></li>\n\t\t\t<li id=\"t-info\"><a href=\"/index.php?title=Support_read-only_block_filesystems_on_MTD_flash&amp;action=info\">Page information</a></li>\n\t\t</ul>\n\t</div>\n</div>\n\t\t\t</div>\n\t\t</div>\n\t\t<div id=\"footer\" role=\"contentinfo\">\n\t\t\t\t\t\t\t<ul id=\"footer-info\">\n\t\t\t\t\t\t\t\t\t\t\t<li id=\"footer-info-copyright\">Content is available under <a class=\"external\" rel=\"nofollow\" href=\"http://creativecommons.org/licenses/by-sa/3.0/\">a Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.</li>\n\t\t\t\t\t\t\t\t\t</ul>\n\t\t\t\t\t\t\t<ul id=\"footer-places\">\n\t\t\t\t\t\t\t\t\t\t\t<li id=\"footer-places-privacy\"><a href=\"/eLinux.org:Privacy_policy\" title=\"eLinux.org:Privacy policy\">Privacy policy</a></li>\n\t\t\t\t\t\t\t\t\t\t\t<li id=\"footer-places-about\"><a href=\"/eLinux.org:About\" title=\"eLinux.org:About\">About eLinux.org</a></li>\n\t\t\t\t\t\t\t\t\t\t\t<li id=\"footer-places-disclaimer\"><a href=\"/eLinux.org:General_disclaimer\" title=\"eLinux.org:General disclaimer\">D", "\t\t\t\t\t<li id=\"footer-places-privacy\"><a href=\"/eLinux.org:Privacy_policy\" title=\"eLinux.org:Privacy policy\">Privacy policy</a></li>\n\t\t\t\t\t\t\t\t\t\t\t<li id=\"footer-places-about\"><a href=\"/eLinux.org:About\" title=\"eLinux.org:About\">About eLinux.org</a></li>\n\t\t\t\t\t\t\t\t\t\t\t<li id=\"footer-places-disclaimer\"><a href=\"/eLinux.org:General_disclaimer\" title=\"eLinux.org:General disclaimer\">Disclaimers</a></li>\n\t\t\t\t\t\t\t\t\t</ul>\n\t\t\t\t\t\t\t\t\t\t<ul id=\"footer-icons\" class=\"noprint\">\n\t\t\t\t\t<li id=\"footer-copyrightico\">\n\t\t\t\t\t\t<a href=\"http://creativecommons.org/licenses/by-sa/3.0/\"><img src=\"http://i.creativecommons.org/l/by-sa/3.0/88x31.png\" alt=\"a Creative Commons Attribution-ShareAlike 3.0 Unported License\" width=\"88\" height=\"31\" /></a>\n\t\t\t\t\t</li>\n\t\t\t\t\t<li id=\"footer-poweredbyico\">\n\t\t\t\t\t\t<a href=\"//www.mediawiki.org/\"><img src=\"/skins/common/images/poweredby_mediawiki_88x31.png\" alt=\"Powered by MediaWiki\" width=\"88\" height=\"31\" /></a>\n\t\t\t\t\t</li>\n\t\t\t\t</ul>\n\t\t\t\t\t\t<div style=\"clear:both\"></div>\n\t\t</div>\n\t\t<script>/*<![CDATA[*/window.jQuery && jQuery.ready();/*]]>*/</script"], "copyright__copyright__copyright": ["", "o complex to be efficient.\n\nScope\n\nHere is the expected amount of work for the first two parts:\n\n  \u2022 bad-block aware MTD block device for read-only filesystems\n 4 weeks\n  \u2022 UBI block device:\n 4 weeks\n\nThese tasks would be implemented in close relationship with the MTD and UBI developer communities, to minimize mainstreaming costs.\n\nContractor Candidates\n\n  \u2022 Linux MTD developers\n  \u2022 Philip Lougher, SquashFS developer\n  \u2022 Development could be taken care of by my company (Free Electrons)\n\nComments", "o complex to be efficient.\n\nScope\n\nHere is the expected amount of work for the first two parts:\n\n  \u2022 bad-block aware MTD block device for read-only filesystems\n 4 weeks\n  \u2022 UBI block device:\n 4 weeks\n\nThese tasks would be implemented in close relationship with the MTD and UBI developer communities, to minimize mainstreaming costs.\n\nContractor Candidates\n\n  \u2022 Linux MTD developers\n  \u2022 Philip Lougher, SquashFS developer\n  \u2022 Development could be taken care of by my company (Free Electrons)\n\nComments"]}