Regarding UBI scalability

[Corentin Chary]

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.

Hi,
I was wondering how it is possible to get atomic operations using such tables ?
The first thing that come to my mind is TFAT (two tables, one for
operation in progress,
the other considered as always "valid"). But I'm not sure it' the good
way to do such a thing.



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