Regarding UBI scalability

[Brijesh Singh]

On Wed, Feb 4, 2009 at 3:17 PM, Adrian Hunter
<ext-adrian.hunter at nokia.com> wrote:
> 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?
Yes,this needs to be done.I agree with the approach, better to keep it for UBI3.