Regarding UBI scalability

[Corentin Chary]

On Thu, Feb 5, 2009 at 10:40 AM, Brijesh Singh <brij.singh at samsung.com> wrote:
> 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.

As you are working on UBI2, have you a git tree or something ? I may
have some time to help :)
Thanks

-- 
Corentin Chary
http://xf.iksaif.net