UBI starts metadata in a block header for each eraseblock. At attach time, it has to scan all eraseblocks to find the mapping of LEBs to PEBs. This increases attach time linearly with flash size. This was already realized when UBI was designed, but not considered a priority.
The first idea was to store metadata in a special volume, but then you still don’t know where that is going to be.
Second idea: split in two volumes: actual data volume, and reference volume. The reference volume is only updated when you write new metadata (i.e. on block erase). It contains pointers to where the metadata is. Reference volume is still found by scanning, but a limited number of blocks. Data volume contains information about all physical eraseblocks. It can be more space-efficient than the volume headers. If reference volume isn’t found, can still find data volume by scanning everything (headers are still there).
Avoid overwriting the metadata block every time by specifying a pool of eraseblocks in there, which is still scanned at attach time.
Pool list is only changed when wear levelling is done, or more blocks are required.
With this speedup, the attach time is not growing as dramatically anymore with flash size. And even for small flash it helps.
Another interesting speedup would be if the bootloader could hand the scan table to the kernel. Or even better, a (fast) NVRAM which contains the map.
Merged in 3.7
Don’t rely on Hamming for modern flash (even SLC); use BCH.