From: Arnd Bergmann <arnd@arndb.de>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Thomas <alexander.thomas@esaturnus.com>,
Carlos Alberto Lopez Perez <clopez@igalia.com>,
Dan Luedtke <mail@danrl.de>,
Jochen Striepe <jochen@tolot.escape.de>,
Marco Stornelli <marco.stornelli@gmail.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
lanyfs@librelist.com
Subject: Re: [PATCH] fs: Introducing Lanyard Filesystem
Date: Wed, 22 Aug 2012 08:38:25 +0000 [thread overview]
Message-ID: <201208220838.25876.arnd@arndb.de> (raw)
In-Reply-To: <20120820132141.GC5197@thunk.org>
On Monday 20 August 2012, Theodore Ts'o wrote:
> On Mon, Aug 20, 2012 at 11:12:07AM +0200, Alexander Thomas wrote:
> >
> > Flash drives are getting faster as well. Copying an 8GB file to/from a
> > USB drive is not excruciatingly slow and may be quicker and more
> > certain than figuring out how to get a working network connection in
> > some random place, if possible at all. If it is some lousy WiFi with
> > the base station at a distance, a flash drive will be faster. And
> > sometimes people just want to be sure that their data will be at a
> > certain place at a certain time without having to rely on a network
> > that may go down due to external reasons.
Actually, flash drives are not really getting faster as much as you
think, at least not any more. The main source for performance improvements
over the last few years was from increasing the flash page and block
sizes. Writing single bits may get slightly faster over time, but
we are writing more of them at the same time now, which leads to
significant problems:
* The page size is now effectively 16kb on most flash drives, and
writing in 4kb alignments as practically all our file systems do
(including the lanyfs proposal) means we're actually slower now
than we would be with smaller pages, unless you get into the
special case of writing large chunks of data.
* The erase block size is increasing insanely. We're seeing 12MB
and 16MB block size devices now, and our simulations have shown that
our file systems that are not aware of this block size are hitting
a wall at around 4MB.
> I used to think that we would need an IP unencumbered file system,
> given issues around TomTom and Microsoft, but these days, given how
> quickly Linux has taken over the embedded and mobile landscape[2] for
> all but the most tiniest of devices, I don't think that's as important
> of an issue, since we can just simply use a native linux file system.
> In the time that it would take to get some other new file system
> adopted across the industry, it's likely Linux will have enough market
> share to perhaps compel the other OS vendors to provide
> interoperability solutions. (Just as the BSD folks have implemented
> ext2 support; Linux hasn't bothered to implement FFS2 support....)
There will be patches very soon for a new file system from a major
flash vendor that I'm cooperating with. I haven't seen the patches
myself yet, but the design is similar to a prototype that was done
as a thesis I supervised [1]. I hope that the new implementation is
similarly simple to this design, and also able to provide optimum
performance on most flash media.
Arnd
[1] https://wiki.linaro.org/WorkingGroups/Kernel/Specs/flash-file-system-prototype
next prev parent reply other threads:[~2012-08-22 8:38 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-18 23:38 [PATCH] fs: Introducing Lanyard Filesystem Dan Luedtke
2012-08-18 22:06 ` Alan Cox
2012-08-18 22:16 ` richard -rw- weinberger
[not found] ` <c925f795-28d8-4e6d-8131-9a14d6e83659@email.android.com>
2012-08-18 22:27 ` richard -rw- weinberger
2012-08-19 10:12 ` Dan Luedtke
2012-08-19 10:14 ` Marco Stornelli
2012-08-19 13:34 ` Dan Luedtke
2012-08-19 12:02 ` Jochen Striepe
2012-08-19 15:33 ` Dan Luedtke
2012-08-19 14:07 ` Jochen Striepe
2012-08-19 14:27 ` Al Viro
2012-08-19 16:53 ` Dan Luedtke
2012-08-19 15:12 ` Al Viro
2012-08-19 15:24 ` Marco Stornelli
2012-08-20 17:36 ` Dan Luedtke
2012-08-19 21:04 ` Theodore Ts'o
2012-08-19 21:20 ` Andi Kleen
2012-08-19 23:06 ` Carlos Alberto Lopez Perez
2012-08-20 0:47 ` Theodore Ts'o
2012-08-20 6:07 ` Raymond Jennings
2012-08-20 6:49 ` Oliver Neukum
2012-08-20 9:12 ` Alexander Thomas
2012-08-20 13:21 ` Theodore Ts'o
2012-08-22 8:38 ` Arnd Bergmann [this message]
2012-08-20 11:36 ` Pavel Machek
2012-08-20 12:49 ` Ronnie Collinson
2012-08-20 17:48 ` Dan Luedtke
2012-08-19 13:25 ` Marco Stornelli
2012-08-19 15:45 ` Dan Luedtke
2012-08-22 9:53 ` Jan Engelhardt
2012-08-21 6:09 ` Vyacheslav Dubeyko
2012-08-23 17:29 ` Eric W. Biederman
2012-08-24 11:50 ` Prashant Shah
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=201208220838.25876.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=alexander.thomas@esaturnus.com \
--cc=clopez@igalia.com \
--cc=jochen@tolot.escape.de \
--cc=lanyfs@librelist.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@danrl.de \
--cc=marco.stornelli@gmail.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).