public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Brijesh Singh <brij.singh@samsung.com>
Cc: brijesh.s.singh@gmail.com, rohitvdongre@gmail.com,
	David Woodhouse <dwmw2@infradead.org>,
	linux-mtd@lists.infradead.org,
	Adrian Hunter <adrian.hunter@nokia.com>
Subject: Re: Release of UBIL: ubi with log
Date: Mon, 10 May 2010 09:49:35 +0300	[thread overview]
Message-ID: <1273474175.2209.61.camel@localhost> (raw)
In-Reply-To: <6b5362aa1002260458j571852cbl2f2d86130828333a@mail.gmail.com>

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 (Артём Битюцкий)

  parent reply	other threads:[~2010-05-10  6:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-26 12:58 Release of UBIL: ubi with log Brijesh Singh
2010-03-02 19:45 ` Artem Bityutskiy
2010-03-31 12:57   ` Corentin Chary
2010-03-31 12:59     ` Artem Bityutskiy
2010-04-01 18:54       ` Brijesh Singh
2010-04-01 11:14     ` Brijesh Singh
2010-04-01 11:59       ` Corentin Chary
2010-04-01 19:06         ` Brijesh Singh
2010-04-23 12:11           ` Artem Bityutskiy
2010-04-06  8:31 ` Artem Bityutskiy
2010-04-07  8:51   ` Brijesh Singh
2010-05-10  6:49 ` Artem Bityutskiy [this message]
2010-05-10  9:03   ` Brijesh Singh
2010-05-10  9:07     ` Artem Bityutskiy
2010-05-10 10:21       ` Brijesh Singh
2010-05-10 11:09         ` Artem Bityutskiy
2010-05-10 11:02     ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1273474175.2209.61.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=adrian.hunter@nokia.com \
    --cc=brij.singh@samsung.com \
    --cc=brijesh.s.singh@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rohitvdongre@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox