linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yuehai Xu <yuehaixu@gmail.com>
To: "Dipl.-Ing. Michael Niederle" <mniederle@gmx.at>
Cc: linux-btrfs@vger.kernel.org, yhxu@wayne.edu
Subject: Re: BTRFS && SSD
Date: Wed, 29 Sep 2010 14:38:56 -0400	[thread overview]
Message-ID: <AANLkTik61cvrvVedcYKtePx89aE1CoACS1NGNBsGXsK8@mail.gmail.com> (raw)
In-Reply-To: <20100929173757.7cf18c0d@simplux>

Hi,

On Wed, Sep 29, 2010 at 11:37 AM, Dipl.-Ing. Michael Niederle
<mniederle@gmx.at> wrote:
> Hi Yuehai!
>
> I tested nilfs2 and btrfs for the use with flash based pen drives.
>
> nilfs2 performed incredibly well as long as there were enough free blocks. But
> the garbage collector of nilfs used too much IO-bandwidth to be useable (with
> slow-write flash devices).

I also tested the performance of write for INTEL X25-V SSD by
postmark, the results are totally different from the results of INTEL
X25-M(http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf). In his
test, the performance of NILFS2 is the best over all, however, in my
test, ext3 is the best while NILFS2 is the worst, almost 10 times less
than ext3 for the throughput of write.

So, what's the role of file system to handle these tricky storage?
Different throughput might be gotten by different file system.

The question is why nilfs2 and btrfs perform so well compared with
ext3 without considering my results, here I just talk about SSD, since
the FTL internal should always do the same thing as the file system,
that redirects the write to a new place instead of writing to the
original place. The throughput for different file system should be
more or less the same.



>
> btrfs on the other side performed very well - a lot better than conventional
> file systems like ext2/3 or reiserfs. After switching the mount-options to
> "noatime" I was able to run a complete Linux system from a (quite slow) pen
> drive without (much) problems. Performance on a fast pen drive is great. I'm
> using btrfs as the root file system on a daily basis since last Christmas
> without running into any problems.
>

The performance of file system is determined by the internal structure
of SSD? or by the structure of file system? or by the coordination of
both file system and SSD?

Thanks very much for replying.

> Greetings, Michael
>

Thanks,
Yuehai

      parent reply	other threads:[~2010-09-29 18:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-29 15:30 BTRFS && SSD Yuehai Xu
2010-09-29 17:08 ` Sean Bartell
2010-09-29 18:45   ` Yuehai Xu
2010-09-29 19:59     ` Sean Bartell
2010-09-29 21:31       ` Yuehai Xu
2010-09-30  7:15         ` Sander
2010-09-30 12:06           ` Yuehai Xu
2010-09-30 13:45             ` Sander
2010-09-30  7:51         ` David Brown
2010-09-30 12:04           ` Yuehai Xu
2010-09-29 19:39   ` Aryeh Gregor
2010-09-29 20:08     ` Sean Bartell
     [not found] ` <20100929173757.7cf18c0d@simplux>
2010-09-29 18:38   ` Yuehai Xu [this message]

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=AANLkTik61cvrvVedcYKtePx89aE1CoACS1NGNBsGXsK8@mail.gmail.com \
    --to=yuehaixu@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mniederle@gmx.at \
    --cc=yhxu@wayne.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).