From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: Konstantin Tokarev <annulen@yandex.ru>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Flashing UBIFS image to gluebi mtd
Date: Thu, 31 Oct 2013 15:40:46 -0300 [thread overview]
Message-ID: <20131031184045.GA2498@localhost> (raw)
In-Reply-To: <16161383242430@web27h.yandex.ru>
On Thu, Oct 31, 2013 at 10:00:30PM +0400, Konstantin Tokarev wrote:
>
>
> 31.10.2013, 19:08, "Ezequiel Garcia" <ezequiel.garcia@free-electrons.com>:
> > Hi Konstantin,
> >
> > On Thu, Oct 31, 2013 at 05:48:34PM +0400, Konstantin Tokarev wrote:
> >
> >> I'm migrating rootfs of device from SquashFS on top of gluebi to UBIFS.
> >
> > Sounds like you could use ubiblock for that setup, which is suitable
> > for squashfs, and completely independent of ubifs (thus less cpu and
> > memory hungry and easier to setup).
>
> Could you elaborate this a bit more? Do you mean that block device emultaion
> layer on top of UBI + FS on top of that can work faster than UBIFS on top of
> UBI?
>
Given you provided no details, I'm not sure why you're migrating from squashfs
(which is a read-only, block oriented fs) to ubifs (which supports r/w on MTD).
But anyway, let me do this homework for you :-)
So, you had squashfs on top of gluebi, right? I guess you had this:
mtd (plus your NAND driver) -> ubi -> gluebi/mtd -> mtdblock -> squashfs
On the other side, using ubiblock to emulate the block device you'd
end up with this:
mtd (plus your NAND driver) -> ubi -> ubiblock -> squashfs
Which is less memory (cpu?) hungry than the first alternative.
The latest git branch also contained a non-cached option which
has shown some good behavior, given squashfs does its own caching.
But of course, this is _NOT_ a replacement for UBIFS, and using ubiblock
for R/W is strictly discouraged.
And here's the (already ancient) discussion:
http://lists.infradead.org/pipermail/linux-mtd/2012-November/045011.html
And the v2:
http://lists.infradead.org/pipermail/linux-mtd/2012-December/045274.html
I'll post the latest work as soon as I find some time, but you're free
to pursue your own research.
Hope it helps and best of lucks!
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
next prev parent reply other threads:[~2013-10-31 18:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 13:48 Flashing UBIFS image to gluebi mtd Konstantin Tokarev
2013-10-31 15:08 ` Ezequiel Garcia
2013-10-31 18:00 ` Konstantin Tokarev
2013-10-31 18:40 ` Ezequiel Garcia [this message]
2013-11-01 7:48 ` Ricard Wanderlof
2013-11-01 9:12 ` Konstantin Tokarev
2013-11-01 9:43 ` Ricard Wanderlof
2013-11-01 11:10 ` Konstantin Tokarev
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=20131031184045.GA2498@localhost \
--to=ezequiel.garcia@free-electrons.com \
--cc=annulen@yandex.ru \
--cc=linux-mtd@lists.infradead.org \
/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