UBI Fastmap (Thomas Gleixner)

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.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s