Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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