Regarding UBI scalability

Hi,

Quoted 11 lines · Artem Bityutskiy

Quoted 7 lines · Adrian Hunter

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

Quoted 26 lines · ext BRIJESH SINGH

Hi,

Quoted 11 lines · Artem Bityutskiy

Quoted 7 lines · Adrian Hunter

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?

Quoted 2 lines

Thanks and Regards,
Brijesh

I would leave the memory consumption issue for UBI3.

Do you have a target memory consumption in mind?

Quoted 24 lines · Adrian Hunter

Quoted 23 lines · ext BRIJESH SINGH

Hi,

Quoted 11 lines · Artem Bityutskiy

Quoted 7 lines · Adrian Hunter

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.

Quoted 7 lines

Quoted 5 lines

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.

Quoted 29 lines · Brijesh Singh

Quoted 27 lines · Adrian Hunter

Quoted 26 lines · ext BRIJESH SINGH

Hi,

Quoted 11 lines · Artem Bityutskiy

Quoted 7 lines · Adrian Hunter

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?

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

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?