public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
To: Daniel Ehrenberg <dehrenberg@google.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Using UBIFS as an FTL
Date: Mon, 28 Jul 2014 19:54:09 +0300	[thread overview]
Message-ID: <1406566449.23376.61.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <CAAK6Zt03J=0=tv5rPvZH0pTZWM8ha5eu0gqFbZ6P_FgSrgwW-A@mail.gmail.com>

On Fri, 2014-07-25 at 11:21 -0700, Daniel Ehrenberg wrote:
> Hi Artem, others,
> 
> For my project, I'm looking into using ext4 on top of NAND flash, in
> order to use some fancy ext4 features. For this, I need an FTL in the
> middle. I'm wondering which would be good to use. Options that I've
> looked at are:
> - ubiblock--the read-modify-write sounds unacceptable to me, even if
> wear leveling and atomicity are handled.

This may not give you the optimal performance.

> - Some coworkers have suggested a new effort to build a new block
> device, but that that's a huge project and takes a long time to get
> right.

Yes.

> - loopback-mounting a file on ubifs--From skimming the code, it looks
> to me like ubifs uses some nice datastructures to handle writes within
> a file without doing read-modify-writes all the time as ubiblock
> forces. ubifs authors/maintainers, do you see any downside to using
> ubifs this way?

I never tried loopback over UBIFS. Should work in theory.
Synchronization (as in 'fsync()') is something which comes to mind.

What I mean is that when ext4 handles an fsync(), or a commit, it
eventually needs to make sure the data goes to the underlying media. It
sends REQ_FLUSH bios, and it seems that the loopback driver will map
that to UBIFS's 'vfs_fsync()'. That should be fine, but may be too
coarse? You could just write the right pages instead, to gain better
performance?

Then ext4 commit has various ordering requirements, and I do not know
how this works with loopback.

This all matters if you need to have some kind of power-cut tolerance.

Thanks!

-- 
Best Regards,
Artem Bityutskiy

  parent reply	other threads:[~2014-07-28 16:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25 18:21 Using UBIFS as an FTL Daniel Ehrenberg
2014-07-25 23:41 ` hujianyang
2014-07-27  7:20   ` Richard Weinberger
2014-07-28  2:49     ` hujianyang
2014-07-28  3:06     ` Ezequiel Garcia
2014-07-28  6:56       ` Richard Weinberger
2014-07-28 16:54 ` Artem Bityutskiy [this message]
2014-07-28 17:47   ` Daniel Ehrenberg
2014-07-29  7:16     ` Artem Bityutskiy
2014-07-29 16:45       ` Daniel Ehrenberg

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=1406566449.23376.61.camel@sauron.fi.intel.com \
    --to=artem.bityutskiy@linux.intel.com \
    --cc=dehrenberg@google.com \
    --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