ubifs- 六大区域 （superblock area, master area, log area, lpt area, orphan area, main area ）

There are in fact six areas in UBIFS whose position is fixed at the time the file system is created.

The first two areas have already been described. The superblock area is LEB zero. The superblock node is always at offset zero, and the superblock LEB is written using UBI's atomic LEB change

facility which guarantees that the LEB is updated successfully or not at all.

The next area is the master node area. It occupies LEB one and LEB two. In general, those two LEBs contain identical data. The master node is written to successive positions in each LEB until there is no more space,

at which point the LEBs are unmapped and the master node written at offset zero (which automatically causes UBI to map an erased LEB). Note that the master node LEBs are not both unmapped at the

same time because that would leave the file system temporarily with no valid master node.The other UBIFS areas are: the log area (or simply the log), the LEB properties tree (LPT) area, the orphan area and the main area.

The log is a part of UBIFS's journal. The purpose of the UBIFS journal is to reduce the frequencyof updates to the on-flash index.

Recall, that the index consists of the top part of the wandering treethat is made up of only index nodes, and that to update the file system a leaf node must be added or replaced in the wandering tree and all the ancestral index nodes updated accordingly.

It would be very inefficient if the on-flash index were updated every time a leaf node was written, because many of the same index nodes would be written repeatedly, particularly towards the top of the tree.

Instead, UBIFS defines a journal where leaf nodes are written but not immediately added to the on-flash index. Note that the index in memory (see TNC) is updated.

Periodically, when the journal isconsidered reasonably full, it is committed. The commit process consists of writing the newversion of the index and the corresponding master node.

The next complication is that the replay must bring the LEB properties tree (LPT) area up-to-date.LEB properties are three values that need to be known for all LEBs in the main area.

Those values are: free space, dirty space and whether the eraseblock is an index eraseblock or not. Note that  index nodes and non-index nodes are never mixed within the same eraseblock, hence an index
eraseblock is an eraseblock that contains (only) index nodes, and a non-index eraseblock is an eraseblock that contains (only) non-index nodes. Free space is the number of bytes at the end of an

eraseblock that have not been written to yet, and so can be filled with more nodes. Dirty space is the number of bytes taken up by obsolete nodes and padding, that can potentially be reclaimed by  garbage collection.

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. Every time a node is written, the free space must be reduced for that eraseblock.

Every time a node is obsoleted or a padding node is written, or a truncation or deletion node is written, dirty space must be increased for that eraseblock.
When an eraseblock is allocated to the index, it must be recorded so that, for example, an index eraseblock with free space is not allocated to the journal - which would cause index and non-index nodes to be mixed.

Note, the reason that index and non-index nodes may not be mixed has to do with budgeting which is described further on.

After the log area, comes the LPT area. The size of the log area is defined when the file system is created and consequently so is the start of the LPT area.

At present, the size of the LPT area is automatically calculated based on the LEB size and maximum LEB count specified when the file  system is created.

Like the log area, the LPT area must never run out of space. Unlike the log area, updates to the LPT area are not sequential in nature - they are random. In addition, the amount of LEB properties data is potentially quite large and access to it must be scalable.

The solution is to store LEB properties in a wandering tree. In fact the LPT area is much like a miniature file system in its own right. It has its own LEB properties - that is, the LEB properties of the LEB properties area (called ltab).

It has its own form of garbage collection. It has its own node structure that packs the nodes as tightly as possible into bit-fields. However, like the index, the LPT area is updated only during commit.

Thus the on-flash index and the on-flash LPT represent what the file system looked like as at the last commit. The difference between that and the actual state of the file system, is represented by the nodes in the journal.

One of the main tasks of UBIFS is to access the index which is a wandering tree.To make that  efficient, index nodes are cached in memory in a structure called the tree node cache (TNC).

The TNC is B+tree that is node-for-node the same as the on-flash index, with the addition of all changes made since the last commit. The nodes of the TNC are called znodes.Another way to look at that,
is that a znode when it is on-flash is called an index node, and an index node when it is in memory is called a znode. Initially there are no znodes. When a lookup is done on the index, just the index  nodes that are needed are read and added to the TNC as znodes.

When a znode needs to be changed, it is marked as dirty which pins it in memory until the next commit at which time it  becomes clean again. At any time UBIFS memory shrinker may decide to free clean znodes in the
TNC, so that the amount of memory needed is proportional to the size of the parts of the index that  are in use, not the total size of the index. In addition, hanging off the bottom of the TNC is a leaf- node cache (LNC) which is used only for directory entries (and extended attribute entries).

The LNC is needed to cache nodes read as a result of collision resolution or readdir operations. Because the LNC is attached to the TNC it effectively gets shrunk when the TNC does.

There are three important differences between UBIFS and JFFS2. The first has already been mentioned: UBIFS has an on-flash index, JFFS2 does not - thus UBIFS is potentially scalable.

Thesecond difference is implied: UBIFS runs on top of the UBI layer which runs on top of the MTD subsystem, whereas JFFS2 runs directly over MTD. UBIFS benefits from the wear-leveling and
error handling of UBI at the cost of the flash space, memory and other resources taken by UBI. Thethird important difference is that UBIFS allows writeback.
Writeback is a VFS facility that allows written data to be cached and not written immediately to the media. That makes the system more responsive and potentially more efficient because updates to the same file can be grouped together.

The difficulty with supporting writeback is that it requiresthat the file system know how much free space is available so that the cache is never bigger than the space on the media.

That is very difficult for UBIFS to determine, so an entire subsystem calledbudgeting is dedicated to it. The difficulties are for several reasons.

The final UBIFS area is the main area. The main area contains the nodes that make up the file system data and the index. A main area LEB may be an index eraseblock or a non-index eraseblock.
A non-index eraseblock may be a bud (part of the journal) or have been committed. A bud may be currently one of the journal heads. A LEB that contains committed nodes can still become a bud ifit has free space.

Thus a bud LEB has an offset from which journal nodes begin, although that offset is usually zero.

关于 journal 和 TNC 相关的PPT 介绍很不错：