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.
Best Answer
rootfsmounted on/is an in-memory filesystem which typically only contains the tools needed to mount the “real” root filesystem and is emptied after this is done. The initial content of the rootfs are loaded from an initramfs image stored inside or next to the kernel binary and loaded by the bootloader.The root filesystem on flash is
ubi0:root. This is a three-layer system:(Take the rest of this answer with caution, I've never actually worked with UBI.)
The
ubi0:rootvolume is created by arguments to theubimodule or theubiattachutility. This is not a block device, because the interface between the UBI level and the filesystem on top of it is more complex than “write this byte at this location”. You can create a read-only block device on top of UBI with theubiblockcommand, then back that up — something like