State of the UBI fastmap feature

State of the UBI fastmap feature

[Alexander Dahl]

Hello everyone,

after using UBI for almost 15 years now without fastmap, I'm currently
experimenting with that feature.  The help text in Kconfig menu
(drivers/mtd/ubi/Kconfig) still says "Experimental feature" and
further down:

> Important: this feature is experimental so far and the on-flash
> format for fastmap may change in the next kernel versions

Is this still the current state?  I can not remember seing any patches
touching fastmap in the last time.  Are there plans to stabilize this?
Will there be changes in the on-flash format?  Do folks even use this
feature?  In production?

Happy to get some opinions here.

Greets
Alex

Re: State of the UBI fastmap feature

[Richard Weinberger]

On Tue, Sep 2, 2025 at 8:00 AM Alexander Dahl <ada@thorsis.com> wrote:
> Hello everyone,
>
> after using UBI for almost 15 years now without fastmap, I'm currently
> experimenting with that feature.  The help text in Kconfig menu
> (drivers/mtd/ubi/Kconfig) still says "Experimental feature" and
> further down:
>
> > Important: this feature is experimental so far and the on-flash
> > format for fastmap may change in the next kernel versions
>
> Is this still the current state?  I can not remember seing any patches
> touching fastmap in the last time.  Are there plans to stabilize this?
> Will there be changes in the on-flash format?  Do folks even use this
> feature?  In production?

I don’t expect changes to the on-disk format, but the number of new raw NAND
devices being introduced is now close to zero. As a result, the user
base is very small,
and subtle bugs are likely to remain undiscovered.

Fastmap does have users, including in production,
but I don’t have concrete numbers. And I don't know their workload.
That said, Fastmap should work but I still anticipate performance and
runtime issues.

I guess your motivation is reducing the attach time?

-- 
Thanks,
//richard

Re: State of the UBI fastmap feature

[Alexander Dahl]

Hello Richard,

Am Tue, Sep 02, 2025 at 09:23:04AM +0200 schrieb Richard Weinberger:
> On Tue, Sep 2, 2025 at 8:00 AM Alexander Dahl <ada@thorsis.com> wrote:
> > Hello everyone,
> >
> > after using UBI for almost 15 years now without fastmap, I'm currently
> > experimenting with that feature.  The help text in Kconfig menu
> > (drivers/mtd/ubi/Kconfig) still says "Experimental feature" and
> > further down:
> >
> > > Important: this feature is experimental so far and the on-flash
> > > format for fastmap may change in the next kernel versions
> >
> > Is this still the current state?  I can not remember seing any patches
> > touching fastmap in the last time.  Are there plans to stabilize this?
> > Will there be changes in the on-flash format?  Do folks even use this
> > feature?  In production?
> 
> I don’t expect changes to the on-disk format, but the number of new raw NAND
> devices being introduced is now close to zero. As a result, the user
> base is very small,
> and subtle bugs are likely to remain undiscovered.

We are still using it in cost-sensitive products.  Those raw NAND
flash chips are a lot cheaper than eMMC or even NOR flashs of the same
size.

> Fastmap does have users, including in production,
> but I don’t have concrete numbers. And I don't know their workload.
> That said, Fastmap should work but I still anticipate performance and
> runtime issues.
> 
> I guess your motivation is reducing the attach time?

Indeed.  Need to reduce boot time here, and UBI is attached twice.
Once in U-Boot to read the kernel image and then again in Linux.

Greets
Alex

Re: State of the UBI fastmap feature

[Richard Weinberger]

On Tue, Sep 2, 2025 at 9:37 AM Alexander Dahl <ada@thorsis.com> wrote:
> > I guess your motivation is reducing the attach time?
>
> Indeed.  Need to reduce boot time here, and UBI is attached twice.
> Once in U-Boot to read the kernel image and then again in Linux.

Some ideas that could significantly improve attach time while being
less invasive than Fastmap:
1. Pass the LEB-PEB mapping from U-Boot to Linux so that scanning
occurs only in U-Boot.
2. Optimize EC/VID header reads:
2.1. If supported by the device, transfer only the actual header size
instead of the entire (sub)page.
2.2. Read headers without ECC (if ECC overhead is measurable). If the
header CRC fails, re-read with ECC.

-- 
Thanks,
//richard