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 (Артём Битюцкий)
next prev 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.