Release of UBIL: ubi with log

Release of UBIL: ubi with log

[Brijesh Singh]

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.

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

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.

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

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.


Thanks and Regards,
Brijesh

Re: Release of UBIL: ubi with log

[Artem Bityutskiy]

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.
> 
> The source code of UBIL can be found in the following git tree:
> http://git.infradead.org/users/brijesh/ubi-2.6.git
> 

Sounds interesting! However, I'm out of office till end of March, and
won't be able to look closely at this. But hopefully others will try it.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: Release of UBIL: ubi with log

[Corentin Chary]

On Tue, Mar 2, 2010 at 8:45 PM, Artem Bityutskiy <dedekind1@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.
>>
>> The source code of UBIL can be found in the following git tree:
>> http://git.infradead.org/users/brijesh/ubi-2.6.git
>>
>
> Sounds interesting! However, I'm out of office till end of March, and
> won't be able to look closely at this. But hopefully others will try it.
>

Hi,
Didn't took the time  to read the code, I'll try to do so soon.
Could you tell us more about what you did and how it works ?
Is it similar to yaffs checkpoints ? When are the log written ?
What will happen if you try to mount something that used UBIL with a
kernel without UBIL support ?
Thanks,

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

Re: Release of UBIL: ubi with log

[Artem Bityutskiy]

On Wed, 2010-03-31 at 14:57 +0200, ext Corentin Chary wrote:
> On Tue, Mar 2, 2010 at 8:45 PM, Artem Bityutskiy <dedekind1@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.
> >>
> >> The source code of UBIL can be found in the following git tree:
> >> http://git.infradead.org/users/brijesh/ubi-2.6.git
> >>
> >
> > Sounds interesting! However, I'm out of office till end of March, and
> > won't be able to look closely at this. But hopefully others will try it.
> >
> 
> Hi,
> Didn't took the time  to read the code, I'll try to do so soon.
> Could you tell us more about what you did and how it works ?
> Is it similar to yaffs checkpoints ? When are the log written ?
> What will happen if you try to mount something that used UBIL with a
> kernel without UBIL support ?
> Thanks,

Right. 

And Brijesh, just go ahead, split your stuff on patches, and submit them
to the MTD ML. Send your docs/URL to docs there as well.

Please, do not wait, just go ahead and start pushing it out.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: Release of UBIL: ubi with log

[Brijesh Singh]

Hi,

On Wed, Mar 31, 2010 at 6:29 PM, Artem Bityutskiy
<Artem.Bityutskiy@nokia.com> wrote:
> On Wed, 2010-03-31 at 14:57 +0200, ext Corentin Chary wrote:
>> On Tue, Mar 2, 2010 at 8:45 PM, Artem Bityutskiy <dedekind1@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.
>> >>
>> >> The source code of UBIL can be found in the following git tree:
>> >> http://git.infradead.org/users/brijesh/ubi-2.6.git
>> >>
>> >
>> > Sounds interesting! However, I'm out of office till end of March, and
>> > won't be able to look closely at this. But hopefully others will try it.
>> >
>>
>> Hi,
>> Didn't took the time  to read the code, I'll try to do so soon.
>> Could you tell us more about what you did and how it works ?
>> Is it similar to yaffs checkpoints ? When are the log written ?
>> What will happen if you try to mount something that used UBIL with a
>> kernel without UBIL support ?
>> Thanks,
>
> Right.
>
> And Brijesh, just go ahead, split your stuff on patches, and submit them
> to the MTD ML. Send your docs/URL to docs there as well.
>
> Please, do not wait, just go ahead and start pushing it out.
Thank you. We will rebase the git and start posting right away.

Re: Release of UBIL: ubi with log

[Brijesh Singh]

Hi,

On Wed, Mar 31, 2010 at 6:27 PM, Corentin Chary
<corentin.chary@gmail.com> wrote:
> On Tue, Mar 2, 2010 at 8:45 PM, Artem Bityutskiy <dedekind1@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.
>>>
>>> The source code of UBIL can be found in the following git tree:
>>> http://git.infradead.org/users/brijesh/ubi-2.6.git
>>>
>>
>> Sounds interesting! However, I'm out of office till end of March, and
>> won't be able to look closely at this. But hopefully others will try it.
>>
>
> Hi,
> Didn't took the time  to read the code, I'll try to do so soon.
> Could you tell us more about what you did and how it works ?
> Is it similar to yaffs checkpoints ? When are the log written ?
Not sure with yaffs checkpoints. But commit writes only valid log entries.
Log is written when an eba mapping is changed or when ec of peb is changed.

> What will happen if you try to mount something that used UBIL with a
> kernel without UBIL support ?
It won't work.


Thanks
Brijesh

Re: Release of UBIL: ubi with log

[Corentin Chary]

On Thu, Apr 1, 2010 at 1:14 PM, Brijesh Singh <brijesh.s.singh@gmail.com> wrote:
> Hi,
>
> On Wed, Mar 31, 2010 at 6:27 PM, Corentin Chary
> <corentin.chary@gmail.com> wrote:
>> On Tue, Mar 2, 2010 at 8:45 PM, Artem Bityutskiy <dedekind1@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.
>>>>
>>>> The source code of UBIL can be found in the following git tree:
>>>> http://git.infradead.org/users/brijesh/ubi-2.6.git
>>>>
>>>
>>> Sounds interesting! However, I'm out of office till end of March, and
>>> won't be able to look closely at this. But hopefully others will try it.
>>>
>>
>> Hi,
>> Didn't took the time  to read the code, I'll try to do so soon.
>> Could you tell us more about what you did and how it works ?
>> Is it similar to yaffs checkpoints ? When are the log written ?
> Not sure with yaffs checkpoints.

Yaffs works by writting it's internal memory representation on the
nand while unmounting, so it seems to be different.

> But commit writes only valid log entries.
> Log is written when an eba mapping is changed or when ec of peb is changed.

How this affect write performances ?

>> What will happen if you try to mount something that used UBIL with a
>> kernel without UBIL support ?
> It won't work.

Could it work by using a separate UBI volume with the right flag ? Are
the log per-volume ?

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

Re: Release of UBIL: ubi with log

[Brijesh Singh]

On Thu, Apr 1, 2010 at 5:29 PM, Corentin Chary <corentin.chary@gmail.com> wrote:
> On Thu, Apr 1, 2010 at 1:14 PM, Brijesh Singh <brijesh.s.singh@gmail.com> wrote:
>> Hi,
>>
>> On Wed, Mar 31, 2010 at 6:27 PM, Corentin Chary
>> <corentin.chary@gmail.com> wrote:
>>> On Tue, Mar 2, 2010 at 8:45 PM, Artem Bityutskiy <dedekind1@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.
>>>>>
>>>>> The source code of UBIL can be found in the following git tree:
>>>>> http://git.infradead.org/users/brijesh/ubi-2.6.git
>>>>>
>>>>
>>>> Sounds interesting! However, I'm out of office till end of March, and
>>>> won't be able to look closely at this. But hopefully others will try it.
>>>>
>>>
>>> Hi,
>>> Didn't took the time  to read the code, I'll try to do so soon.
>>> Could you tell us more about what you did and how it works ?
>>> Is it similar to yaffs checkpoints ? When are the log written ?
>> Not sure with yaffs checkpoints.
>
> Yaffs works by writting it's internal memory representation on the
> nand while unmounting, so it seems to be different.

Right now, all the valid log is kept in buffer. This is written at
umount/ when log is full.
However, I have got some code that dumps ram data structure(eba table
and wl trees). Right now it works only when
meta data is less than single block. This is certainly best approach,
and is much faster.

>> But commit writes only valid log entries.
>> Log is written when an eba mapping is changed or when ec of peb is changed.
>
> How this affect write performances ?
RIght now, as long as there is space in log, read/write performance is
the same.
The results we got, are almost same as old UBI. I will update the
results on monday,

>>> What will happen if you try to mount something that used UBIL with a
>>> kernel without UBIL support ?
>> It won't work.
>
> Could it work by using a separate UBI volume with the right flag ? Are
> the log per-volume ?
No. Log is per UBI instance. It is not per volume. I am not sure why
would this be necessary.
Any suggestion?

Re: Release of UBIL: ubi with log

[Artem Bityutskiy]

On Fri, 2010-04-02 at 00:36 +0530, Brijesh Singh wrote:
> On Thu, Apr 1, 2010 at 5:29 PM, Corentin Chary <corentin.chary@gmail.com> wrote:
> > On Thu, Apr 1, 2010 at 1:14 PM, Brijesh Singh <brijesh.s.singh@gmail.com> wrote:
> >> Hi,
> >>
> >> On Wed, Mar 31, 2010 at 6:27 PM, Corentin Chary
> >> <corentin.chary@gmail.com> wrote:
> >>> On Tue, Mar 2, 2010 at 8:45 PM, Artem Bityutskiy <dedekind1@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.
> >>>>>
> >>>>> The source code of UBIL can be found in the following git tree:
> >>>>> http://git.infradead.org/users/brijesh/ubi-2.6.git
> >>>>>
> >>>>
> >>>> Sounds interesting! However, I'm out of office till end of March, and
> >>>> won't be able to look closely at this. But hopefully others will try it.
> >>>>
> >>>
> >>> Hi,
> >>> Didn't took the time  to read the code, I'll try to do so soon.
> >>> Could you tell us more about what you did and how it works ?
> >>> Is it similar to yaffs checkpoints ? When are the log written ?
> >> Not sure with yaffs checkpoints.
> >
> > Yaffs works by writting it's internal memory representation on the
> > nand while unmounting, so it seems to be different.
> 
> Right now, all the valid log is kept in buffer. This is written at
> umount/ when log is full.

So do you mean that in case of a power-cut, the log is lost and UBI will
have to do scanning?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: Release of UBIL: ubi with log

[Artem Bityutskiy]

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.
> 
> 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
> 
> We are working on utilities and design document of UBIL. I will share
> those as soon as possible.

Is there any doc available?

I've briefly looked at the source code, and found out that:

1. It looks like code from UBIFS, but tweaked and transformed, is this
right?
2. Various small coding style things which do not correspond to UBI
coding style. I usually want contributors to use the same style to keep
the UBI code uniform and consistent.
3. A design document would be cool.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: Release of UBIL: ubi with log

[Brijesh Singh]

Hi,
On Tue, Apr 6, 2010 at 2:01 PM, Artem Bityutskiy <dedekind1@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.
>>
>> 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
>>
>> We are working on utilities and design document of UBIL. I will share
>> those as soon as possible.
>
> Is there any doc available?
Working on it.
> I've briefly looked at the source code, and found out that:
>
> 1. It looks like code from UBIFS, but tweaked and transformed, is this
> right?
Yes,some parts like compression.
> 2. Various small coding style things which do not correspond to UBI
> coding style. I usually want contributors to use the same style to keep
> the UBI code uniform and consistent.
We have tried to do this as much as possible. If there is anything
missing, I will fix it.
> 3. A design document would be cool.
Working on it. I will send the patches earliest possible.

Thanks and Regards,
Brijesh

Re: Release of UBIL: ubi with log

[Artem Bityutskiy]

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?

> 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?

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.

> 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?

> 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.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: Release of UBIL: ubi with log

[Brijesh Singh]

Hi,

On Mon, May 10, 2010 at 12:19 PM, Artem Bityutskiy <dedekind1@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

Re: Release of UBIL: ubi with log

[Artem Bityutskiy]

On Mon, 2010-05-10 at 14:33 +0530, Brijesh Singh wrote:
> >> 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.

File system just never formats the media, so of course they never
corrupt anything. Utilities mkfs.ext3 and the like do this instead. 

In fact, you can thing of UBI the same way - it does not format, there
is ubiformat tool for that. Then, there is one single exception - empty
flash. It is just very handy to be able to attach it without ubiformat.
You can consider this as an additional usefuls feature.

And UBI does manage somehow to not corrupt anything. So the question was
- why UBIL cannot?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: Release of UBIL: ubi with log

[Brijesh Singh]

On Mon, May 10, 2010 at 2:37 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Mon, 2010-05-10 at 14:33 +0530, Brijesh Singh wrote:
>> >> 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.
>
> File system just never formats the media, so of course they never
> corrupt anything. Utilities mkfs.ext3 and the like do this instead.
>
> In fact, you can thing of UBI the same way - it does not format, there
> is ubiformat tool for that. Then, there is one single exception - empty
> flash. It is just very handy to be able to attach it without ubiformat.
> You can consider this as an additional usefuls feature.
>
> And UBI does manage somehow to not corrupt anything. So the question was
> - why UBIL cannot?

Personally, I wasn't sure if it is nice idea to find empty flash and
then format it on it's own.

UBIL certainly can do this. I will add this, if you find it useful.

Re: Release of UBIL: ubi with log

[Artem Bityutskiy]

On Mon, 2010-05-10 at 15:51 +0530, Brijesh Singh wrote:
> On Mon, May 10, 2010 at 2:37 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > On Mon, 2010-05-10 at 14:33 +0530, Brijesh Singh wrote:
> >> >> 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.
> >
> > File system just never formats the media, so of course they never
> > corrupt anything. Utilities mkfs.ext3 and the like do this instead.
> >
> > In fact, you can thing of UBI the same way - it does not format, there
> > is ubiformat tool for that. Then, there is one single exception - empty
> > flash. It is just very handy to be able to attach it without ubiformat.
> > You can consider this as an additional usefuls feature.
> >
> > And UBI does manage somehow to not corrupt anything. So the question was
> > - why UBIL cannot?
> 
> Personally, I wasn't sure if it is nice idea to find empty flash and
> then format it on it's own.
> 
> UBIL certainly can do this. I will add this, if you find it useful.

Well, many people found it very useful. I found it very useful for
development as well. And since it already exists and is used, it is nice
to make UBIL consistent with it.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: Release of UBIL: ubi with log

[Artem Bityutskiy]

On Mon, 2010-05-10 at 14:33 +0530, Brijesh Singh wrote:
> Hi,
> 
> On Mon, May 10, 2010 at 12:19 PM, Artem Bityutskiy <dedekind1@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

Please, run also the integck test which you can find in the mtd-utils,
it is a very good test, and I think it is better than fsstress even.

If integck will work, this will mean UBIL is quite stable. Then let's
make sure it does not regress when we introduce changes.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)