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 <[email protected]> == 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 _______________________________________________ Celinux-dev mailing list [email protected] http://tree.celinuxforum.org/mailman/listinfo/celinux-dev
