Regarding UBI scalability

[Artem Bityutskiy]

On Tue, 2009-02-03 at 16:05 +0530, Brijesh Singh wrote:
> 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?

For UBI2 I would just forget about static volumes support. They are not
so necessary, and a rare user needs them. This would simplify things.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)