ubifs – Linux Alternatives to UBIFS on MLC NAND

Why the numbers don't match up

The "at least 17 erase blocks" warning counts blocks needed by the UBIFS filesystem itself. Of those 17 erase blocks, 14 are UBIFS overhead and 3 are usable filesystem space. The underlying UBI layer underneath also uses 5 erase blocks of overhead.

Getting More Space

There's no way to make a single UBI partition with a single UBIFS filesystem use less overhead.

However, if you have more than one UBI partition on the same MTD device, I recommend merging them. Not only will it free up 5 erase blocks, but it will also get you improved wear leveling and bad block handling, because UBI will have more options for mapping physical erase blocks to logical erase blocks as needed.

(Ignoring overhead, imagine two partitions of two blocks each, one of which is bad. Now one partition only has one block left, and it's impossible to do wear leveling. But if you merge the two, then you have three good blocks left to share between the two filesystems as needed.)

To merge two adjacent UBI partitions:

• Update your MTD partition table, replacing the two partitions with one larger one.
• Run ubiformat on that one large partition.
• Run ubimkvol twice, providing appropriate partition names and and specifying the sizes manually with -s or -S.

An accounting of UBI+UBIFS overhead

First, the UBI layer takes 5 erase blocks of overhead:

• 2 for the volume table
• 1 reserved for the wear leveling algorithm
• 1 reserved for the "atomic LEB change" feature, which allows for reliable in-place updates of a logical erase block
• 1 (ideally more, as you mentioned) reserved for handling bad physical erase blocks.

Next, the UBIFS layer has a minimum number of erase blocks for the filesystem metadata:

• 1 for the filesystem superblock, which identifies the volume as a valid UBIFS and stores the filesystem parameters
• 2 for the master node area (redundant copies), which are the roots of the tree used for filesystem lookups
• 2 or more for the log area (which counts towards usable space)
• 2 for the LEB properties tree, which tracks how each logical erase block is used
• 1 or more for the orphan area (for tracking deleted files, so they are cleaned up correctly after an unclean unmount)
• 8 reserved for filesystem metadata (garbage collection, deletions, buds, index)
• 1 or more for committed data not in the log (usable space).

References

For the UBI overhead, the linux-mtd site has a straightforward description.

For the UBIFS overhead, I had to do a little more digging. The source code of mtd-utils counts up the absolute minimum number of erase blocks and mentions what each block is for. To make sense of it, the UBIFS whitepaper is useful.