UBI / UBIFS

MTD overview MTD subsystem (stands for Memory Technology Devices) Provide an abstraction layer for raw flash devices. Provide uniform access to various flash devices. Provide a generic API for that. Interfaces MTD character devices The sysfs interface The /proc/mtd proc file system file MTD partition Flash chip may be split on several MTD partitions. MTD partitions are static – a set of consecutive eraseblocks. Do not provide wear-leveling for the whole Nand flash chip.

UBI overview UBI (stands for Unsorted Block Images) A volume management system for raw flash devices Manage multiple logical volumes Spread the I/O load across whole flash chip Vs. the Logical Volume Manager (LVM). LVM maps logical sectors to physical sectors, UBI maps logical eraseblocks to physical eraseblocks. UBI implements global wear-leveling and transparent I/O errors handling. An UBI volume is a set of consecutive logical eraseblocks (LEBs). UBI is aware of bad eraseblocks and frees the upper layers from any bad block handling.

UBI overview 2 types of UBI volumes UBI handles flash bit-flips Static volume Read-only & their contents are protected by CRC-32. Dynamic volume Read-write & ensuring data integrity. UBI handles flash bit-flips Scrubbing, by moving data from physical eraseblocks which have bit-flips to other physical eraseblocks. Scrubbing is done transparently in background and is hidden from upper layers.

UBI features UBI provides volumes which may be dynamically created, removed, or re-sized; UBI implements wear-leveling across whole flash device UBI transparently handles bad physical eraseblocks; UBI minimizes chances to loose data by means of scrubbing.

UBI Volume UBI provides logical volumes instead of MTD partitions UBI volume a set of consecutive logical eraseblocks (LEBs) Each LEB is mapped to any PEB Dynamically created, deleted and re-sized. Volume A (static) Volume B (dynamic) LEB 0 LEB 1 LEB 2 LEB 3 LEB 0 LEB 1 LEB 2 UBI layer PEB 0 PEB 1 PEB 2 PEB 3 PEB 4 PEB 5 PEB 6 PEB 7 PEB 8 PEB 9

Wear-leveling UBI does wear-leveling across whole MTD device Wear-leveling is done by UBI, not by the UBI user JFFS2 Boot volume Kernel volume Root filesystem volume UBI layer MTD device (Nand flash chip)

Bad eraseblock handling 1% of PEBs are reserved for bad eraseblock handling If a PEB becomes bad, corresponding LEB is remapped to a good PEB I/O errors are handled transparently. 1. Write data & failed 3. Retry write data x LEB Volume A UBI layer 4. Remap LEB to new PEB PEB 2. Recover the data to a good PEB 5. Mark this PEB bad

UBIFS Overview UBIFS is a new flash file system Developed by Nokia engineers with help of the University of Szeged. 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. MTD subsystem Provide uniform interface to access flash chips. Provide an notion of MTD devices (e.g., /dev/mtd0) UBI subsystem a wear-leveling and volume management system for flash devices; Work on top of MTD devices Provide a notion of UBI volumes UBIFS file system Work on top of UBI volumes.

UBI/UBIFS stack

UBIFS features Scalability Fast mount Write-back support Tolerance to unclean reboots Fast I/O On-the-flight compression Recoverability Integrity Garbage collection UBIFS features Scalability UBIFS scales well with respect to flash size; mount time, memory consumption and I/O speed does not depend on flash size. Fast mount UBIFS do not scan whole media before mounting. However, UBI initialization time depends on flash size. Write-back support Improve the throughput of the file system (Jffs2, write-through) User can configure it while mounting the file system Can use –o sync, but file system performance may drop Tolerance to unclean reboots UBIFS does not need to scan whole media so it takes fractions of a second to mount UBIFS Fast I/O UBIFS maintain indexing data structures on flash, But, UBIFS is still fast because of the way UBIFS commits the journal On-the-flight compression The data stored in compressed form on the flash media. Allow to switch the compresstion on/off on per-inode basis Recoverability UBIFS may be fully recovered if the indexing information gets corrupted. Integrity UBIFS checksums everything it writes to the flash media to guarantee data integrity. Can disable CRC checking for data to improve file system read speed and lessen CPU usage Garbage collection

Out-of-place updates (1/2) Flash memory must be erased before it can be written. Requires garbage collection Garbage collection suggests the benefits of node-structure. Node (data & metadata) UBIFS stores the index on the flash whereas JFFS2 stores the index only in main memory. Unfortunately, storing the index on flash is very complex because the index itself must be updated out-of-place.

Out-of-place updates (2/2) UBIFS Wandering tree (B+ tree) A top part (Metadata) consisting of index nodes that create the structure of the tree A bottom part (Data) consisting of leaf nodes that hold the actual file data ............................................................................. Leaf level contains FS data Index

UBIFS index UBIFS index is stored and maintained on flash Full flash media scanning is not needed Only the journal is scanned in case of power cut Journal is small, has fixed and configurable size Thus, UBIFS mounts fast ............................................................ UBIFS Journal

Wandering trees How to find the root of the tree? A A A B B B C C C D 1. Write data node “D” 2. Old “D” becomes obsolete 3. Write indexing node “C” 4. Old “C” becomes obsolete 5. Write indexing node “B” 6. Old “B” becomes obsolete B B B 7. Write indexing node “A” 6. Old “A” becomes obsolete C C C D D D Explain wandering tree mechanisms. At the end ask logical question – how to find the root of the tree on mount? How to find the root of the tree? UBIFS D A A B B A D D C C C B

Master node Keep two copies for the purpose of recovery. Two situations that can cause a corrupt or missing master node A loss of power at the same instant that the master node is being written the previous version of the master node can be used Degradation or corruption of the flash media itself. cannot be determined reliably what is a valid master node version be needed to analyze all the nodes on the media and attempt to fix or recreate corrupt or missing nodes Having two copies of the master node makes it possible to determine which situation has arisen, and respond accordingly

Master node Stored at the master area (LEBs 1 and 2) Points to the root index node 2 copies of master node exist for recoverability Master area may be quickly found on mount Valid master node is found by scanning master area 1. Suppose “R” is changed 6. LEBs 1 and 2 become full R .................................................................. 2. Then “M” is updated 7. LEB 1 is erased 3. Old “M” becomes obsolete 8. “M” is written 4. The same is done to the 2nd copy 9. The same for the 2nd copy 5. and so on ... UBIFS LEB 0 M M M M M M M M M M M M R R R R R R Master area (LEBs 1 and 2) Root index node

Superblock node Stored at the first node (LEB 0) Contain the static information The flash geometry eraseblock size, number of eraseblocks etc… Configuration information Index tree fanout, default compression type(zlib or lzo) etc… Superblock is read on mount LEB 0 LEB 1 LEB 2 LEB n UBIFS Superblock Master area

UBIFS partition layout Six areas in UBIFS SB, MST Super Block (SB) : static information Master Node (MST) : dynamic information LOG A part of UBIFS journal that the buds are. LPT (LEB properties tree) A wandering tree used to store LEB properties. ORPHAN Store the orphan inodes, which should be deleted at next reboot. MAIN the nodes that make up the file system data and the index. SB MST LOG LPT ORPHAN MAIN

LOG, UBIFS’s Journal The purpose of the UBIFS journal Journal To reduce the frequency of updates to the on-flash index Journal All FS changes go to the journal Indexing information is changed in RAM (TNC), but not on the flash Journal greatly increases FS write performance When mounting, journal is scanned and replayed Journal size is configurable and is stored in superblock TNC (Tree Node Cache) Caches indexing nodes A B+tree in RAM. Speeds up indexing tree lookup

LPT, LEB Properties Tree A wandering tree used to store LEB properties. LEB properties tree values Free space Dirty space Whether Eraseblock is an index eraseblock or not. Index eraseblock contain only index nodes. The LEB properties are essential to find space to add to the journal, or the index, and to find the dirtiest eraseblocks to garbage collect.

Garbage collection Garbage Collector(GC) is responsible to turn dirty space to free space One empty LEB is always reserved for GC GC procedure Pick a victim LEB which has some dirty space. Moves valid nodes from the victim LEB to the LEB reserved for GC. If the victim LEB is erasable, erase the victim LEB. pick new victim LEB, and moves the data to the reserved LEB When the reserved LEB is full, pick another empty LEB, and continues moving nodes from the victim LEB to the new reserved LEB The process continues until a full empty LEB is produced.

References UBI - Unsorted Block Images, http://www.linux-mtd.infradead.org/doc/ubi.html UBI presentation, http://www.linux-mtd.infradead.org/doc/ubi.ppt UBIFS - UBI File-System, http://www.linux-mtd.infradead.org/doc/ubifs.html UBIFS white pager, http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf UBIFS presentation, http://www.linux-mtd.infradead.org/doc/ubifs.odp