Release of UBIL: ubi with log

Brijesh Singh brijesh.s.singh at gmail.com
Mon May 10 05:03:17 EDT 2010


Hi,

On Mon, May 10, 2010 at 12:19 PM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> On Fri, 2010-02-26 at 18:28 +0530, Brijesh Singh wrote:
>> Hi,
>>  It gives me great pleasure in sharing UBIL: ubi with log.  We have
>> added logging functionality to ubi for reducing mount time.
>> UBIL uses the "same source base of UBI". The logging functionality can
>> be added or removed at compile time using "make menuconfig option".
>>
>> We have seen mount time reduction of 50% in 1GB NAND. We are expecting
>> even better results for larger flash memories.
>
> Was that SLC or MLC NAND?

It was SLC NAND.

>> The source code of UBIL can be found in the following git tree:
>> http://git.infradead.org/users/brijesh/ubi-2.6.git
>>
>> We have tested ubil for samsung nand and onenand. The test results can
>> be found in the following git tree:
>> http://git.infradead.org/users/brijesh/ubil_results
>
> Did you run any stress tests for UBIL? Which?

We ran
1) fsstress on UBIFS without power failure
2) fsstress on UBIFS with power failure

> I think it is very important to stress test it and make sure is stable.
> After that, we can start doing changes required for upstreaming it. I
> propose the following roadmap:
>
> The main idea is to make UBIL as stable as possible first. Then, make
> sure whatever change we introduce - it stays stable. IOW, run tests
> after each change and make sure nothing breaks. With this test-driven
> scheme we can add all the needed improvements and keep it working.
>
>> We are working on utilities and design document of UBIL. I will share
>> those as soon as possible.
>>
>> If someone wants to try, please follow the instructions:
>> make menuconfig
>>          select ubi as module
>>          select ubil feature.
>> compile ubi module.
>
> I think UBIL should not be compiled separately. UBI should automatically
> detect the format type.
Possible.
>> 1) First mount of ubil is little different than ubi.
>>
>> insmod ubi mtd=1,ubinize.
>>  (Second parameter "ubinize" is introduced to avoid accidental loss of data.)
>> insmod ubifs
>> mount ubifs
>
> Why this ubinize parameter exists? Why you cannot detect empty media
> just like UBI?

The idea was not to accidentally ubinize mtd partition.
For example: the file system generally don't format empty partition on
it's own. It is forced.

>> 2)For next mounts:
>> insmod ubi mtd=1
>> insmod ubifs
>> mount ubifs
>>
>> Though UBIL is functionally complete,there is a lot of scope for
>> optimizations. All the help is very much appreciated.
>
> The main requirement for upstreaming is to make sure the on-flash format
> is stable. Once you are in upstream - you cannot change your on-flash
> data structures anymore. Any change will become huge PITA.
>
> Thus, it is very important to think carefully about on-flash format, and
> possibly invent mechanisms for future extensions.
I agree.

Thanks and Regards,
Brijesh



More information about the linux-mtd mailing list