Regarding UBI scalability

[Adrian Hunter]

ext BRIJESH SINGH wrote:
> Hi,
> 
> Artem Bityutskiy wrote:
>> On Mon, 2009-02-02 at 13:07 +0200, Adrian Hunter wrote:
>>> I would suggest an intermediate step.  Create UBI2 which is
>>> similar to UBI but stores eraseblock information in one place,
>>> instead of at the beginning of each eraseblock.  Such an approach
>>> might be OK up to as much as 64GiB, and would probably perform
>>> better than a fully scalable version.
>>>
>>> Then look at creating UBI3, which is fully scalable.
>> Yes, I assume UBI2 should store mapping/erasure information in separate
>> tables, not in each eraseblock. So we should get rid of eraseblock
>> headers.
> 
> Yes that is what I meant.  You could probably make do with as little as
> 12 bytes per eraseblock so a 64GiB flash with 512KiB eraseblock size
> would need 1536KiB table, which could be read in a second or two, so
> mount time is OK.
> 
> I have an idea for how to update the table relatively efficiently if you
> are interested.
> 
> I am definitely interested. But apart from on flash headers, I am also interested in memory consumption scaling.
> UBIFS solved this problem quite interestingly. Can something similar be borrowed for UBI?
> 
> Thanks and Regards,
> Brijesh

I would leave the memory consumption issue for UBI3.

Do you have a target memory consumption in mind?