Add checkpointing or logging to UBIFS


 * Summary: Add checkpointing or logging to UBIFS


 * Proposer: Tim Bird

Description
Currently, the UBI file system takes a long time to be ready for use, due to a badblock scan that takes place during initialization of UBI (the UBI attach operation). The scan takes a time that is linearly proportional to the size of flash. As flash sizes grow, the delay caused by this scan becomes a problem.

It would be beneficial to eliminate the scan, or make it more scalable, using some kind of checkpointing or logging.

Related work

 * UBIFS
 * http://en.wikipedia.org/wiki/UBIFS
 * http://lwn.net/Articles/276025/
 * UBI2
 * see portions of http://www.mjmwired.net/kernel/Documentation/filesystems/ubifs.txt
 * Mount times
 * http://osl.sed.hu/wiki/ubifs/index.php/Mount_results
 * http://elinux.org/images/f/f8/CELFJamboree30-UBIFS_update.pdf


 * This proposal was suggested last year, but the project was not done
 * See http://elinux.org/CELF_Project_Proposal/UBIFS_mount_time_speedups

UBI logging feature submitted by Samsung
A developer with Samsung (in India) proposed UBIL - UBI logging - to solve this problem, in April 2010.
 * Initial announcement: http://lists.infradead.org/pipermail/linux-mtd/2010-February/029256.html
 * performance improvement: http://git.infradead.org/users/brijesh/ubil_results/blob/da4f975b5a2fc5cb2f9398bcb6b4329ba7e8c770:/nand_mount_time.pdf
 * patches in April, 2010: http://lists.infradead.org/pipermail/linux-mtd/2010-April/029573.html

I seem to recall someone at the kernel summit (maybe Thomas) telling me that these patches improved the speed, but still had scalability proportional to the flash size.

Scope
A rough estimate would be 3 months of development and test work, followed by some work to mainline the changes upstream.

Contractor Candidates

 * Thomas Gleixner
 * Artem Bityutskiy
 * Free Electrons