All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Artem Bityutskiy <dedekind@yandex.ru>
Cc: Tomasz Chmielewski <mangoo@wpkg.org>,
	LKML <linux-kernel@vger.kernel.org>,
	penberg@cs.helsinki.fi, ext-adrian.hunter@nokia.com,
	jwboyer@gmail.com
Subject: Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)
Date: Tue, 1 Apr 2008 11:03:09 +0200	[thread overview]
Message-ID: <20080401090309.GA7465@logfs.org> (raw)
In-Reply-To: <47F1F644.4060000@yandex.ru>

On Tue, 1 April 2008 11:45:56 +0300, Artem Bityutskiy wrote:
> Tomasz Chmielewski wrote:
> >For me, the motivators to wait for LogFS are mainly the facts that it
> >can work on traditional block devices, and not only on pure flash:
> 
> Sorry Thomasz, for me this makes zero sense. There are _much_ better file
> systems for block devices. UBIFS may work on top of a block device as
> well (just needs few hacks to make it possible) - it is not a problem
> at all, it is just _senseless_.
> 
> JFFS2/UBIFS/LogFS is a separate _class_ of file-systems. The are designed
> for _flash_, which has completely different work model then block device.
> They are _native_ flash file systems.
> Here are more details: 
> http://www.linux-mtd.infradead.org/faq/general.html#L_mtd_vs_hdd
> 
> The traditional FSes _cannot_ work on top of flash. The solution for this
> is using FTL, which emulates a block device on top of flash. It _hides_ the
> real device, and fakes a block device for you. And you can use traditional
> FSes on top of that fake block device.
> 
> The whole _point_ of this separate class of FSes is because we believe
> we may do much _better_ job if we use flash _natively_, instead of using
> FTL. FTL is the place where you loose performance, reliability, and so on.
> 
> And you are saying about using a native flash FS on top of a block device
> like an SD card. This is just not sane: SD card first emulates a block 
> device
> for you, looses performance at this point, then you again emulate a flash
> on top of this, and suffer from this again.

About a year ago I would have used roughly the same argument.  But in
the meanwhile I have accepted the fact that any piece of flash I'll use
in a notebook in the next five years will likely use SATA or USB as a
transport medium.

Jörn

-- 
...one more straw can't possibly matter...
-- Kirby Bakken

  reply	other threads:[~2008-04-01  9:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01  8:02 UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system) Tomasz Chmielewski
2008-04-01  8:45 ` Artem Bityutskiy
2008-04-01  9:03   ` Jörn Engel [this message]
2008-04-01  9:09     ` Artem Bityutskiy
2008-04-01  9:31       ` Jörn Engel
2008-04-01  9:39   ` Tomasz Chmielewski
2008-04-01  9:57     ` Artem Bityutskiy
2008-04-02 14:17       ` Tomasz Chmielewski
2008-04-02 14:22         ` Jörn Engel
2008-04-01 11:06   ` Andi Kleen
2008-04-01 11:23     ` Artem Bityutskiy
2008-04-01 16:27       ` H. Peter Anvin
2008-04-01 21:26         ` Willy Tarreau
2008-04-02  4:47           ` Artem Bityutskiy
2008-04-02  6:25             ` Willy Tarreau
2008-04-02  7:17               ` Artem Bityutskiy
2008-04-09 21:09 ` Pavel Machek
2008-04-09 21:32   ` Jörn Engel
  -- strict thread matches above, loose matches on Subject: below --
2008-03-27 14:55 [RFC PATCH] UBIFS - new flash file system Artem Bityutskiy
2008-03-31 12:29 ` Jan Engelhardt
2008-03-31 12:47   ` Adrian Hunter
2008-03-31 13:20     ` Jörn Engel
2008-04-01  5:26       ` UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system) Artem Bityutskiy
2008-04-01  5:28         ` Artem Bityutskiy
2008-04-01  5:56         ` Artem Bityutskiy
2008-04-01  9:25           ` Jörn Engel
2008-04-01  9:39             ` Artem Bityutskiy
2008-04-01 10:51               ` Jörn Engel
2008-04-01 11:17                 ` Artem Bityutskiy
2008-04-01  9:19         ` Jörn Engel
2008-04-01  9:46           ` Artem Bityutskiy
2008-04-01 11:16             ` Jörn Engel

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=20080401090309.GA7465@logfs.org \
    --to=joern@logfs.org \
    --cc=dedekind@yandex.ru \
    --cc=ext-adrian.hunter@nokia.com \
    --cc=jwboyer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mangoo@wpkg.org \
    --cc=penberg@cs.helsinki.fi \
    /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.