All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Ezequiel Garcia <elezegarcia@gmail.com>,
	Ricard Wanderlof <ricard.wanderlof@axis.com>,
	Michael Opdenacker <michael.opdenacker@free-electrons.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Tim Bird <tim.bird@am.sony.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC/PATCH 0/1] ubi: Add ubiblock driver
Date: Fri, 30 Nov 2012 13:24:07 +0200	[thread overview]
Message-ID: <1354274647.30168.99.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <20121125093621.47f9cb25@pixies.home.jungo.com>

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

On Sun, 2012-11-25 at 09:36 +0200, Shmulik Ladkani wrote:
> Hi Ezequiel,
> 
> On Sat, 24 Nov 2012 18:02:59 -0300 Ezequiel Garcia <elezegarcia@gmail.com> wrote:
> > I've started working on a workload scenario to measure if ubiblock write
> > is useful or just plain nonsense.
> 
> Please note eraseblock wear is just one aspect of using a standard r/w
> filesystem over ubiblock.
> 
> There's another potential hazard of using r/w ubiblock, which is the
> lack of power-cut tolerance.
> Changing a file atomically in ubifs or jffs2 is tolerant to power
> cuts (see [1]).
> I'm not sure this is possible in ubiblock case, due to the 1-LEB
> writeback cache: if a file (in the mounted fs) is synced, are there any
> guarantees the 1-LEB cache is flushed synchronously?
> (you mentioned the actual write is only done when a request arrives to
> read or write to a different LEB or when the device is released).

Why would not it be? ubiblk is just like a hard drive or and SSD fro a
file-system. If it caches something, it is just like an internal disk
cache. The I/O barrier should flush it. And we have an atomic LEB change
operation, so when you want to change the LEB contents, you can do it in
power-cut-safe manner.

Do I miss something?

> 
> > Since read-only ubiblock is less controversial, I'll post a read-only
> > version of ubiblock (with an option to use a vmalloced
> > buffer to cache reads?).
> > We can add write support later, if it's not useless.
> > 
> > Any thoughts?
> 
> Well I was about to suggest that approach :)
> I would even split your patch further: the core stuff (with r/o
> support), and an additional patch with all the DEBUG stuff. This may
> ease reviewer's job.

I do not see why R/W ubiblock is controversial. You can use FAT on top
of this, which is a use-case many people wanted. Or even ext4.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-11-30 11:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-20 22:39 [RFC/PATCH 0/1] ubi: Add ubiblock driver Ezequiel Garcia
2012-11-21  5:28 ` Ricard Wanderlof
2012-11-21  9:56   ` Thomas Petazzoni
2012-11-21 10:00     ` Ricard Wanderlof
2012-11-21 10:05       ` Thomas Petazzoni
2012-11-24 21:02         ` Ezequiel Garcia
2012-11-25  7:36           ` Shmulik Ladkani
2012-11-30 11:24             ` Artem Bityutskiy [this message]
2012-12-02 17:39               ` Shmulik Ladkani
2012-12-03  0:58                 ` Ezequiel Garcia
2012-12-03 19:33                   ` Ezequiel Garcia
2012-12-03 21:03                     ` Shmulik Ladkani
2012-11-30 11:18         ` Artem Bityutskiy
2012-11-30 11:15   ` Artem Bityutskiy
2012-11-21 10:00 ` Thomas Petazzoni
2012-11-21 10:00   ` Thomas Petazzoni
2012-11-21 10:42   ` Ezequiel Garcia
2012-11-21 10:42     ` Ezequiel Garcia
2012-11-30 11:25   ` Artem Bityutskiy
2012-11-30 11:25     ` Artem Bityutskiy
2012-11-30 11:08 ` Artem Bityutskiy
2012-11-30 11:08   ` Artem Bityutskiy
2012-11-30 20:43   ` Ezequiel Garcia
2012-11-30 20:43     ` Ezequiel Garcia

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=1354274647.30168.99.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=elezegarcia@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael.opdenacker@free-electrons.com \
    --cc=ricard.wanderlof@axis.com \
    --cc=shmulik.ladkani@gmail.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tim.bird@am.sony.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.