Regarding UBI scalability

[Brijesh Singh]

On Tue, Feb 3, 2009 at 5:14 AM, Corentin Chary <corentin.chary at gmail.com> wrote:
> On Mon, Feb 2, 2009 at 12:18 PM, Adrian Hunter
> <ext-adrian.hunter at nokia.com> wrote:
>> 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.

Adrian,to my understanding, this is minimum info needed per physical
erase block...

Erase count                   -8 bytes
Lnum                             -4 bytes
Volume ID                      -4 byte(Can make it 1 byte for now as
vol limit=128)
Header CRC                   -4 bytes(Only for static volumes.)
i.e. Minimum 20 bytes.  Is there any other way to make it 12?
And how to update the table relatively efficiently?

> Hi,
> I was wondering how it is possible to get atomic operations using such tables ?
May be keeping a commit block and journal will help.(*Like UBIFS design)

Thanks,
Brijesh