Proposal: support read-only block filesystems on MTD flash


Michael Opdenacker
 

Hi,

I'm glad that Phillip has just submitted a similar proposal, making
SquashFS available on MTD flash storage....

Cheers,

Michael.

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

; Proposer: Michael Opdenacker <michael@...>

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

[[Category:Project proposals 2011]]

--
Michael Opdenacker, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+ 33 621 604 642


Bill Traynor <wmat@...>
 

Hi,

I'm glad that Phillip has just submitted a similar proposal, making
SquashFS available on MTD flash storage....

Cheers,

Michael.

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

; Proposer: Michael Opdenacker <michael@...>
<snip>

Thanks Michael, I've added your proposal to the elinux.org wiki here:

http://elinux.org/Support_read-only_block_filesystems_on_MTD_flash



--
Michael Opdenacker, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+ 33 621 604 642

_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
http://tree.celinuxforum.org/mailman/listinfo/celinux-dev