UBI File System

Introduction

UBIFS file-system stands for UBI File System. UBI stands for “UnsortedBlock Images”. UBIFS is a flash file system, which means it is designedto work with flash devices. It is important to understand, that UBIFSis completely different to any traditional file-system in Linux, likeExt2, XFS, JFS, etc. UBIFS represents a separate class of file-systemswhich work with MTD devices, not block devices. The other Linuxfile-system of this class is JFFS2.

To make it more clear, here is a small comparison of MTD devices andblock devices.

1 MTD devices represent flash devices and they consist of eraseblocks of

rather large size, typically about 128KiB. Block devices consist ofsmall blocks, typically 512 bytes.

2 MTD devices support 3 main operations - read from some offset within an

eraseblock, write to some offset within an eraseblock, and erase a wholeeraseblock. Block devices support 2 main operations - read a wholeblock and write a whole block.

3 The whole eraseblock has to be erased before it becomes possible to

re-write its contents. Blocks may be just re-written.

4 Eraseblocks become worn out after some number of erase cycles -

typically 100K-1G for SLC NAND and NOR flashes, and 1K-10K for MLCNAND flashes. Blocks do not have the wear-out property.

5 Eraseblocks may become bad (only on NAND flashes) and software should

deal with this. Blocks on hard drives typically do not become bad,because hardware has mechanisms to substitute bad blocks, at least inmodern LBA disks.

It should be quite obvious why UBIFS is very different to traditionalfile-systems.

UBIFS works on top of UBI. UBI is a separate software layer which may befound in drivers/mtd/ubi. UBI is basically a volume management andwear-leveling layer. It provides so called UBI volumes which is a higherlevel abstraction than a MTD device. The programming model of UBI devicesis very similar to MTD devices - they still consist of large eraseblocks,they have read/write/erase operations, but UBI devices are devoid oflimitations like wear and bad blocks (items 4 and 5 in the above list).

In a sense, UBIFS is a next generation of JFFS2 file-system, but it isvery different and incompatible to JFFS2. The following are the maindifferences.

  • JFFS2 works on top of MTD devices, UBIFS depends on UBI and works ontop of UBI volumes.

  • JFFS2 does not have on-media index and has to build it while mounting,which requires full media scan. UBIFS maintains the FS indexinginformation on the flash media and does not require full media scan,so it mounts many times faster than JFFS2.

  • JFFS2 is a write-through file-system, while UBIFS supports write-back,which makes UBIFS much faster on writes.

Similarly to JFFS2, UBIFS supports on-the-fly compression which makesit possible to fit quite a lot of data to the flash.

Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts.It does not need stuff like fsck.ext2. UBIFS automatically replays itsjournal and recovers from crashes, ensuring that the on-flash datastructures are consistent.

UBIFS scales logarithmically (most of the data structures it uses aretrees), so the mount time and memory consumption do not linearly dependon the flash size, like in case of JFFS2. This is because UBIFSmaintains the FS index on the flash media. However, UBIFS depends onUBI, which scales linearly. So overall UBI/UBIFS stack scales linearly.Nevertheless, UBI/UBIFS scales considerably better than JFFS2.

The authors of UBIFS believe, that it is possible to develop UBI2 whichwould scale logarithmically as well. UBI2 would support the same API as UBI,but it would be binary incompatible to UBI. So UBIFS would not need to bechanged to use UBI2

Mount options

(*) == default.

bulk_read

read more in one go to take advantage of flashmedia that read faster sequentially

no_bulk_read (*)

do not bulk-read

no_chk_data_crc (*)

skip checking of CRCs on data nodes in order toimprove read performance. Use this option onlyif the flash media is highly reliable. The effectof this option is that corruption of the contentsof a file can go unnoticed.

chk_data_crc

do not skip checking CRCs on data nodes

compr=none

override default compressor and set it to “none”

compr=lzo

override default compressor and set it to “lzo”

compr=zlib

override default compressor and set it to “zlib”

auth_key=

specify the key used for authenticating the filesystem.Passing this option makes authentication mandatory.The passed key must be present in the kernel keyringand must be of type ‘logon’

auth_hash_name=

The hash algorithm used for authentication. Used forboth hashing and for creating HMACs. Typical valuesinclude “sha256” or “sha512”

Quick usage instructions

The UBI volume to mount is specified using “ubiX_Y” or “ubiX:NAME” syntax,where “X” is UBI device number, “Y” is UBI volume number, and “NAME” isUBI volume name.

Mount volume 0 on UBI device 0 to /mnt/ubifs:

$ mount -t ubifs ubi0_0 /mnt/ubifs

Mount “rootfs” volume of UBI device 0 to /mnt/ubifs (“rootfs” is volumename):

$ mount -t ubifs ubi0:rootfs /mnt/ubifs

The following is an example of the kernel boot arguments to attach mtd0to UBI and mount volume “rootfs”:ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs

References

UBIFS documentation and FAQ/HOWTO at the MTD web site: