From: Chris Mason <chris.mason@oracle.com>
To: Stephan von Krawczynski <skraw@ithnet.com>
Cc: Mike Ramsey <MikeJRamsey@comcast.net>, linux-btrfs@vger.kernel.org
Subject: Re: Phoronix article slaming BTRFS
Date: Tue, 23 Jun 2009 12:30:10 -0400 [thread overview]
Message-ID: <20090623163010.GC4379@think> (raw)
In-Reply-To: <20090623181935.2b01c17d.skraw@ithnet.com>
On Tue, Jun 23, 2009 at 06:19:35PM +0200, Stephan von Krawczynski wrote:
> On Tue, 23 Jun 2009 10:41:23 -0400
> Chris Mason <chris.mason@oracle.com> wrote:
>
> > On Tue, Jun 23, 2009 at 02:51:41AM +0000, Mike Ramsey wrote:
> > > I ran across this article "Testing Out The SSD Mode In Btrfs".
> > > http://www.phoronix.com/scan.php?page=article&item=btrfs_ssd_mode&num=1
> > >
> > > At first I was disappointed. It gave a very disappointing set of benchmarks.
> > > However, a close reading revealed this:
> > >
> > > "With the OCZ Vertex SATA 2.0 SSD, which we used for this testing today, had its
> > > write caching always enabled. When attempting to disable the write cache through
> > > hdparm it would remain enabled regardless and when using sdparm it would report
> > > change_mode_page: failed setting page: Caching (SBC)."
> > >
> > > This invalidates the benchmark! Disabling the write cache would yield a 2X
> > > improvement.
> >
> > Hmmm, I'm not sure I follow. I'm guessing the write cache is critical
> > on the vertex drives because they are using it to queue up writes into
> > large enough units to fill an entire erasure block at once. If they
> > took the time to put 64MB of the stuff in there, it probably does
> > something good ;)
> >
> > Jens Axboe tried to reproduce the phoronix results on his ocz drive, and
> > generally found that each run was slower than the last regardless of
> > which mount options were used. This isn't entirely surprising, but it
> > did make it very difficult to nail down good or bad performance.
> >
> > -chris
>
> Can someone explain to a quite naive person like me why one should be
> interested in SSDs that perform worse than Intel? Why shouldn't I just buy the
> best-performing product? This is a moving market, and it is obvious that the
> bad performers will be left behind...
Fast, reliable, cheap, pick any two? If the filesystem has enough
smarts to write more efficiently to the SSD, you may even get to pick
all three (depending on how fast you really need).
But, it is clear the vertex firmware is still being shaken out. Take a
look at Jens Axboe's blog for some fun details.
http://axboe.livejournal.com/
-chris
next prev parent reply other threads:[~2009-06-23 16:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-23 2:51 Phoronix article slaming BTRFS Mike Ramsey
2009-06-23 10:13 ` Miguel F Mascarenhas Sousa Filipe
[not found] ` <2d23818a0906231026g6e4567fdv8eda3d6c4828ef4d@mail.gmail.com>
2009-06-23 17:28 ` Jaime sanchez
2009-06-24 1:27 ` Mike Ramsey
2009-06-24 2:20 ` Wil Reichert
2009-06-24 2:47 ` Mike Ramsey
2009-06-24 9:31 ` Bron Gondwana
2009-06-24 12:57 ` Mike Ramsey
2009-06-25 1:32 ` Bron Gondwana
2009-06-23 14:41 ` Chris Mason
2009-06-23 14:53 ` Sander
2009-06-23 15:17 ` Chris Mason
2009-06-23 16:19 ` Stephan von Krawczynski
2009-06-23 16:30 ` Chris Mason [this message]
2009-06-24 2:20 ` Mike Ramsey
2009-06-24 8:20 ` Sander
2009-06-24 8:31 ` Jens Axboe
2009-06-24 13:11 ` Mike Ramsey
2009-06-24 17:38 ` Jens Axboe
2009-06-25 8:43 ` Stephan von Krawczynski
2009-06-23 17:30 ` Jaime sanchez
2009-06-23 17:44 ` nightrow
2009-06-23 18:27 ` Jaime sanchez
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=20090623163010.GC4379@think \
--to=chris.mason@oracle.com \
--cc=MikeJRamsey@comcast.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=skraw@ithnet.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox