0. UBI / UBIFS

1. 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.

2. 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.

3. 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.

4. 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.

5. 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

6. 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)

7. 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

8. 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.

9. UBI/UBIFS stack

10. 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

11. 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.

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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.

21. 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.

22. References
UBI - Unsorted Block Images,
UBI presentation,
UBIFS - UBI File-System,
UBIFS white pager,
UBIFS presentation,