Regarding UBI scalability

[Brijesh Singh]

On Tue, Feb 3, 2009 at 4:43 PM, Corentin Chary <corentin.chary at gmail.com> wrote:
> On Tue, Feb 3, 2009 at 11:46 AM, Artem Bityutskiy
> <dedekind at infradead.org> wrote:
>> On Tue, 2009-02-03 at 00:44 +0100, Corentin Chary wrote:
>>> 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.
>>
>> Journal + commit mechanisms should allow doing this.
>
> I'm asking some other questions, because in UFFS we are working on
> something like that, but not for UBI2. But if I can help for UBI2,
> I'll.
>
> A journal node, would probably take less than 16 B. With min_io_size
>>= 512 B (sometime 2KB), a journal for map/unmap operation will take
> some time before being written.
>
> I see two solutions, based on periodic journal write with padding to
> have min_io_size bytes to write:
> - based on time (every X ms)
> - based on changes (every X changes)
> - based on both
> But there is probably more clever solutions.
I will check this.As of now I don't find a way to skip writing journal
node.For consistency,
you have to.
>
> One other thing is the table will have to move on the flash for wear
> leveling, but for that we can use the "anchors" as defined in JFFS3
> pdf.
This will move on flash. In UBI,there is a small trick. Journal and
commit can be on internal volumes.
So it easily gets wear-leveled.

And the Super block will know where are they?Super block can be
logged. Fixed in 0-5 blocks.

Best Regards,
Brijesh