Ubifs

Quick summary

Why UBIFS instead of JFFS2?

Because it's fast! Also, in theory, the UBI layer should be even smarter than JFFS2 about wear-levelling. But mainly because it's really fast. For reference:

# Mounting a JFFS2 rootfs from /dev/mtdblock2
root# mount -t jffs2 /dev/mtdblock2 /mnt/nand
    43.396s total

Compared to:

# Mounting an UBIFS rootfs from the same NAND partition
root# ubiattach /dev/ubi_ctrl -m 2 && mount -t ubifs ubi0:rootfs /mnt/nand
    1.488s total

Overview

from http://www.linux-mtd.infradead.org/doc/ubifs.html

UBIFS is a new flash file system developed by Nokia engineers with help of the University of Szeged. In a way, UBIFS may be considered as the next generation of the JFFS2 file-system.

JFFS2 file system works on top of MTD devices, but UBIFS works on top of UBI volumes and cannot operate on top of MTD devices. In other words, there are 3 subsystems involved:

• MTD subsystem, which provides uniform interface to access flash chips. MTD provides an notion of MTD devices (e.g., /dev/mtd0) which basically represents raw flash;

• UBI subsystem, which is a wear-leveling and volume management system for flash devices; UBI works on top of MTD devices and provides a notion of UBI volumes; UBI volumes are higher level entities than MTD devices and they are devoid of many unpleasant issues MTD devices have (e.g., wearing and bad blocks); see here for more information;

• UBIFS file system, which works on top of UBI volumes.

Here is a list of some of UBIFS features:

• scalability - UBIFS scales well with respect to flash size; namely, mount time, memory consumption and I/O speed does not depend on flash size (currently it is not 100% true for memory consumption, but the dependency is very weak, and this may be fixed); UBIFS (not UBI!) should work fine for hundreds of GiB flashes; however, UBIFS depends on UBI which has scalability limitations (see here); nonetheless, the UBI/UBIFS stack scales much better than JFFS2, and if UBI becomes a bottleneck, it is always possible to implement UBI2 without changing UBIFS;

• fast mount - unlike JFFS2, UBIFS does not have to scan whole media when mounting, it takes milliseconds for UBIFS to mount the media, and this does not depend on flash size; however, UBI initialization time depends on flash size and has to be taken into account (see here for more details);

• write-back support - this dramatically improves the throughput of the file system in many workloads, comparing to JFFS2, which is write-through; see here for more details;

• tolerance to unclean reboots - UBIFS is a journaling file system and it tolerates sudden crashes and unclean reboots; UBIFS just replays the journal and recovers from the unclean reboot; mount time is a little bit slower in this case, because of the need to replay the journal, but UBIFS does not need to scan whole media, so it anyway takes fractions of a second to mount UBIFS; note, authors payed special attention to this UBIFS aspect, see this

Making your UBIFS image

Make the ubifs filesystem from the rootfs

root# mkfs.ubifs -r /mnt/nfs/rootfs-debian -m 2048 -e 129024 -c 4096 -o ubifs.img -x zlib

The default compression option (if you don't specify -x (zlib|none)) is to compress with LZO - zlib tends to offer slightly better compression, and on the SheevaPlug CPU it appears to be faster. See performance benchmarks in the appendix for more details.

Make ubi image out of the ubifs

root# ubinize -o ubi.img -m 2048 -p 128KiB -s 512 ubi.cfg

contents of ubi.cfg:

[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=256MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize

Format the NAND with your new image

root# ubiformat /dev/mtd3 -s 512 -f ubi.img

Attach the image to the UBI subsystem

root# ubiattach /dev/ubi_ctrl -m 3

Mount the new device

root# mount -t ubifs ubi0:rootfs /mnt/ubi

Reboot into the new system with ubifs root

QI＃ setenv bootargs 'mem=32M console=ttyS0,57600n8 ubi.mtd=3 rootfstype=ubifs root=ubi0:rootfs rw rootwait' 
QI＃ boot