public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: Mike Ramsey <MikeJRamsey@comcast.net>, linux-btrfs@vger.kernel.org
Subject: Re: Phoronix article slaming BTRFS
Date: Tue, 23 Jun 2009 18:19:35 +0200	[thread overview]
Message-ID: <20090623181935.2b01c17d.skraw@ithnet.com> (raw)
In-Reply-To: <20090623144123.GB19276@think>

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...
If you really care to fiddle with ssd options then use a real bad hw for
testing the performance - take an ide interface and connect a CF card.
This is a common setup for embedded usage and frequently used. Everything in
between CF and Intel will just be dead before your fs options will become
really stable. So why loose time with it?

-- 
Regards,
Stephan


  parent reply	other threads:[~2009-06-23 16:19 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 [this message]
2009-06-23 16:30     ` Chris Mason
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=20090623181935.2b01c17d.skraw@ithnet.com \
    --to=skraw@ithnet.com \
    --cc=MikeJRamsey@comcast.net \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.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