Regarding UBI scalability

[Adrian Hunter]

Amit Kumar Sharma wrote:
> Hi
> ----- Original Message -----
> From: "Artem Bityutskiy" <dedekind at infradead.org>
> To: <brij.singh at samsung.com>
> Cc: <linux-mtd at lists.infradead.org>
> Sent: Monday, February 02, 2009 3:01 PM
> Subject: Re: Regarding UBI scalability
> 
> 
>> On Fri, 2009-01-30 at 12:45 +0000, BRIJESH SINGH wrote:
>>> Hi,
>>>     I have gone through UBI documentation which clearly
>>> mentions that
>>> UBI doesn't scale very well.(Boot time and Memory
>>> consumption
>>> increases with size of device.)This is very similar to
>>> JFFS2
>>> scalability issues. Log, journal(like UBIFS LPT)
>>> combination might
>>> surely help on this issue.
>> Right
>>
>>>   I would like to work on this enhancement with the
>>> community. Before
>>> that I just wanted to check if any one is already working
>>> on it.
>> No, I do not think so.
>>
>>>   As this a well known issue, I am sure somebody will
>>> have some design
>>> suggestions. Any design suggestions will be appreciated.
>> You could look at the old JFFS3 design document:
>>
>> http://www.linux-mtd.infradead.org/doc/JFFS3design.pdf
>>
>> at the "The superblock" section, which describes the idea
>> of how to have
>> a data structure which refers everything else in the
>> media: journal,
>> root nodes of the trees, etc.
>>
>> An then you should think about how to store the EBA table
>> on flash. And
>> how to store the erase counters on the flash. Many ideas
>> may be borrowed
>> from UBIFS in this area.
>>
>> I may help you in terms of design suggestions / review,
>> and some code
>> review. But I do not really have time to seriously work on
>> this.
>>
>> --
>> Best regards,
>> Artem Bityutskiy (???????? ?????)
> 
> Thanks for your comments Brijesh will check all your
> suggestion and we will discuss final design with you for
> your comments.
> 
> Thanks
> Amit

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.