Re: UBI - EBA table (Erase block association table) - wear leveling

[Artem Bityutskiy <dedekind1@gmail.com>]

Hello,

On Fri, 2011-03-18 at 19:49 +0530, Navaneethan P wrote:
>  Hi Linux-Mtd users,
> 
> We are using UBI over NAND Flash. I have the following dubts.
> 
> 1) UBI stores the volume id table & EBA table in some PEB of the NAND Flash.

No, only the volume table is stored on-flash. The EBA table is built
when the flash is scanned.

> My assumption is that volume id table will always be stored in LEB
> 'X'. and UBI will go & read the information during initialization.
> Is my undersatnding correct?

Not sure, probably. On initialization UBI scans whole flash and finds
the volume table
> 
> 2) One of the assumption is that EBA table is always stored in an PEB.
> Is my assumption correct?

No, EBA table is built while scanning in RAM. This is why UBI is not
very scalable. UBI2 would need to solve it, but no one developed UBI2
yet.

> 3) I read from the wear leveling subsystem (wl.c), the maximum
> difference between the erase counters of erase blocks will be
> CONFIG_MTD_UBI_WL_THRESHOLD (defined as 4096).

OK.

> If the difference exceeds then it will move the data from high EC
> block to low EC block.

Yes.

> Let me take the case of PEB 'A' stores the EBA table.

There is no such PEB.

>  Because of the
> writting to the flash, EC of PEB 'A' reaches to 4096. As per the
> documentation, it has to be wear leveled to lower EC block. Let me
> assume that this PEB is 'B'. My doubt is "In the next initialization,
> how does the UBI understands that EBA is stored in PEB 'B' instead of
> PEB 'A'?"

UBI always scans. That is design decision. It has advantages
(robustness, simplicity) and drawbacks (linear scalability).

Here you can find various docs, BTW:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubidoc

HTH.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)