Regarding UBI scalability

Kyungmin Park kmpark at infradead.org
Sun Feb 8 05:31:49 EST 2009


Hi,

On Sun, Feb 8, 2009 at 6:48 PM, Corentin Chary <corentin.chary at gmail.com> wrote:
> On Thu, Feb 5, 2009 at 10:40 AM, Brijesh Singh <brij.singh at samsung.com> wrote:
>> On Wed, Feb 4, 2009 at 3:17 PM, Adrian Hunter
>> <ext-adrian.hunter at nokia.com> wrote:
>>> ext BRIJESH SINGH wrote:
>>>> Hi,
>>>>
>>>> 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.
>>>>
>>>> I have an idea for how to update the table relatively efficiently if you
>>>> are interested.
>>>>
>>>> I am definitely interested. But apart from on flash headers, I am also interested in memory consumption scaling.
>>>> UBIFS solved this problem quite interestingly. Can something similar be borrowed for UBI?
>>>>
>>>> Thanks and Regards,
>>>> Brijesh
>>>
>>> I would leave the memory consumption issue for UBI3.
>
> As you are working on UBI2, have you a git tree or something ? I may
> have some time to help :)
> Thanks
>

One more requested feature.
How about to scan ubi image and bad block table at simultaneously?
Now there's two full device scan, bbt and ubi at booting time.
As internal LEA mapping layout, how about to add bbt layout?

It's also helpful to MLC since MLC doesn't have read oob so it calls
page read command to build bbt.
As you know it takes long time.

I'm not sure if internal LEA maping is supported, it's meaningful work or not.

How do you think?

Thank you,
Kyungmin Park



More information about the linux-mtd mailing list