Re: Regarding UBI scalability

Artem Bityutskiy
2009-02-03T10:48:59Z

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@gmail.com> wrote:
> > On Mon, Feb 2, 2009 at 12:18 PM, Adrian Hunter
> > <ext-adrian.hunter@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 (Битюцкий Артём)