public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: big flash disks?
Date: Mon, 2 Jun 2008 09:28:42 +0200	[thread overview]
Message-ID: <20080602072842.GB19219@logfs.org> (raw)
In-Reply-To: <20080601184239.GA11135@shareable.org>

On Sun, 1 June 2008 19:42:39 +0100, Jamie Lokier wrote:
> 
> Some people developing newer flash filesystems (UBIFS, Logfs,
> FAT-over-UBI :-) and interested in flash filesystem performance might
> be interested in this slashdot comment:
> 
>     http://slashdot.org/comments.pl?sid=569439&cid=23618215
> 
> They're implying that UBIFS and Logfs aren't suitable for high
> performance writes and/or large flash, and don't work well with up and
> coming flash disks either.
> 
> Also that patents may get in the way.

He has some good points, but also happens to argue in favor of his
company and against their competition.  To be served with a grain of
salt.

> I've never heard of MFT before.

Basically they create a log-structured block device.  For a while I've
been thinking of doing the same, essentially strip logfs down to a
single file, which gets a block device interface.  Removing all the
filesystem complexities (atomic create/unlink/rename, interactions with
vfs and mm, etc.) makes the project a _lot_ simpler.  I'm nor surprised
they have a usable product already.

I decided against it, because I don't believe it to be the best approach
long-term.  One of the disadvantages is that block devices have
relatively little knowledge about caching constraints.  A filesystem can
easily have gigabytes of dirty data around, where a block device is
expected to return success for every single write in a reasonable
timeframe, usually measures in milliseconds.

Jörn

-- 
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
-- M.A. Jackson

  parent reply	other threads:[~2008-06-02  7:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-01 18:42 big flash disks? Jamie Lokier
2008-06-01 20:41 ` Josh Boyer
2008-06-02  5:59 ` Artem Bityutskiy
2008-06-02  8:23   ` Jörn Engel
2008-06-02 10:43     ` Jamie Lokier
2008-06-02 11:55       ` Jörn Engel
2008-06-02 12:32         ` Jamie Lokier
2008-06-03 18:09           ` Jörn Engel
2008-06-03 18:44             ` Jamie Lokier
2008-06-04  6:25               ` Jörn Engel
2008-06-02  7:28 ` Jörn Engel [this message]
2008-06-02 10:41   ` Jamie Lokier
2008-06-02 11:43     ` Jörn Engel
2008-06-02 12:48       ` Jamie Lokier
2008-06-03 18:12         ` Jörn Engel
2008-06-03 18:56           ` Jamie Lokier
2008-06-04  6:18             ` 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=20080602072842.GB19219@logfs.org \
    --to=joern@logfs.org \
    --cc=jamie@shareable.org \
    --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