Btrfs devel - Jun 2009 - Phoronix article slaming BTRFS

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.  

Digging deeper, I found this:
http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg07949.html

" Michael,
 My information may be out of date, but last time I
 looked libata didn''t support MODE SELECT which is
 the SCSI command to change mode page settings.
 [I have sent patches several times to add support
 for this in libata but ...]

Ahhha!!!

That looks exactly the case.

I tested the two drives (AS and NS ones) on different
machines, and currently, NS (where things doesn''t work)
is connected to AHCI controller, while the AS one is
behind mptsas.  So it just looks like mptsas is doing
the right thing in the first place, while ahci (or
libata, whatever) is failing."

So the article managed to unjustly smear both OCZ Vertex and BTRFS in one shot. 

--Mike Ramsey


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Jun 23, 2009 at 3:51 AM, Mike Ramsey<MikeJRamsey@comcast.net>
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.
>
> Digging deeper, I found this:
> http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg07949.html
>
> " Michael,
>  My information may be out of date, but last time I
>  looked libata didn''t support MODE SELECT which is
>  the SCSI command to change mode page settings.
>  [I have sent patches several times to add support
>  for this in libata but ...]
>
> Ahhha!!!
>
> That looks exactly the case.
>
> I tested the two drives (AS and NS ones) on different
> machines, and currently, NS (where things doesn''t work)
> is connected to AHCI controller, while the AS one is
> behind mptsas.  So it just looks like mptsas is doing
> the right thing in the first place, while ahci (or
> libata, whatever) is failing."
>
> So the article managed to unjustly smear both OCZ Vertex and BTRFS in one
shot.
allways take phoronix tests with a very big grain of salt. :-p

usually they are made/prepared "with their eyes closed".. completely
in the dark and they don''t diagnose or try to understand the results.
nevertheless, they do test stuff out...

>
> --Mike Ramsey
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Miguel Sousa Filipe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Chris Mason wrote (ao):
> 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.
The performance should stabilize within a handful max fills I believe?

There should be a moment where things don''t get more complicated for
the
controller I thought.

-- 
Humilis IT Services and Solutions
http://www.humilis.net
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Jun 23, 2009 at 04:53:59PM +0200, Sander wrote:
> Chris Mason wrote (ao):
> > 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.
> 
> The performance should stabilize within a handful max fills I believe?
> 
> There should be a moment where things don''t get more complicated
for the
> controller I thought.
That''s the idea, but every device is different, and they are very
complex.  Especially for write performance, tuning is a long and complex
process...a simple benchmark run where you do three tries and average
them isn''t going to give you a great picture of drive performance.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

They are using 2.6.29.4 kernel, it isn''t a bit old??

 I think that kernel doesn''t have the last btrfs updates, and that it
 is a very bad work and benchmarks results from phoronix part. If u are
 benchmarking an experimental filesystem benchmark it with the lastest
 updaets ¿? it doesn''t have sense.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

They are using 2.6.29.4 kernel, it isn''t a bit old??

I think that kernel doesn''t have the last btrfs updates, and that it
is a very bad work and benchmarks results from phoronix part. If u are
benchmarking an experimental filesystem benchmark it with the lastest
updaets ¿? it doesn''t have sense.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

If you look here : http://btrfs.wiki.kernel.org/index.php/Main_Page in 
the benchmarking section, you will notice that the test was made more 
than one month ago.
I also mentionned, as said by chris on phoronix phorums, that kernel 
starting from 2.6.30 should be faster.

I think we should expect them to run it periodicaly against newer version.

I made the link to the phoronix test. They may not be the best, but this 
is all I found. If you find any better test, don''t hesitate to add
them.

disclaimer: I''m not a btrfs developer, just a entusiast that follows
the developement.

Jb benoit.

Jaime sanchez wrote :
> They are using 2.6.29.4 kernel, it isn''t a bit old??
>
> I think that kernel doesn''t have the last btrfs updates, and that
it
> is a very bad work and benchmarks results from phoronix part. If u are
> benchmarking an experimental filesystem benchmark it with the lastest
> updaets ¿? it doesn''t have sense.
>
>   


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

My fault then, i thought it was a recent article (the discussion
appeared recently on the list) , i read it all except the date. I
didn''t see it was from 29 may. I apologize.

On Tue, Jun 23, 2009 at 7:44 PM, nightrow<nightrow@gmail.com>
wrote:
> If you look here : http://btrfs.wiki.kernel.org/index.php/Main_Page in the
> benchmarking section, you will notice that the test was made more than one
> month ago.
> I also mentionned, as said by chris on phoronix phorums, that kernel
> starting from 2.6.30 should be faster.
>
> I think we should expect them to run it periodicaly against newer version.
>
> I made the link to the phoronix test. They may not be the best, but this is
> all I found. If you find any better test, don''t hesitate to add
them.
>
> disclaimer: I''m not a btrfs developer, just a entusiast that
follows
> the developement.
>
> Jb benoit.
>
> Jaime sanchez wrote :
>>
>> They are using 2.6.29.4 kernel, it isn''t a bit old??
>>
>> I think that kernel doesn''t have the last btrfs updates, and
that it
>> is a very bad work and benchmarks results from phoronix part. If u are
>> benchmarking an experimental filesystem benchmark it with the lastest
>> updaets ¿? it doesn''t have sense.
>>
>>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jaime sanchez <jskartman <at> gmail.com> writes:
> 
> They are using 2.6.29.4 kernel, it isn''t a bit old??
> 
>  I think that kernel doesn''t have the last btrfs updates, and that
it
>  is a very bad work and benchmarks results from phoronix part. If u are
>  benchmarking an experimental file system benchmark it with the latest
>  updates ¿? it doesn''t have sense.
[snip] 

I agree.  It was either a hatchet job or just a poor effort.  The problem is
that a lot of people are going to read it and lose interest in btrfs.  I was
disheartened but then the analyst in me said, "Wait, this just
can''t be right.
A copy-on-write file system has got be screaming!"  

So I decided to dig deeper.  

It might not be a bad idea to get some counter information out there.  It should
explicitly reference and refute the phoronix article.  Tom''s Hardware
http://www.tomshardware.com/
is a reputable place.  They would run a fair benchmark and their work would
carry weight.

BTW, the Sun side of Oracle isn''t likely to release ZFS to the Linux
world
because they need to preserve a competitive edge for Solaris.  

Butters has a future.  Believe it.

--Mike Ramsey






--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Stephan von Krawczynski <skraw <at> ithnet.com> writes:

[snip]
> 
> 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?
> 
Depends on who you talk to.

http://www.tomshardware.com/news/ocz-ssd-vertex-intel-solid-state,7127.html

"OCZ Says Its New Vertex SSD Beats Intel''s X25-E"

I am not taking sides.  I am just saying that the SSD market is fluid.

--Mike Ramsey



--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Jun 23, 2009 at 6:27 PM, Mike Ramsey<MikeJRamsey@comcast.net>
wrote:
> Jaime sanchez <jskartman <at> gmail.com> writes:
>
>>
>> They are using 2.6.29.4 kernel, it isn''t a bit old??
>>
>>  I think that kernel doesn''t have the last btrfs updates, and
that it
>>  is a very bad work and benchmarks results from phoronix part. If u are
>>  benchmarking an experimental file system benchmark it with the latest
>>  updates ¿? it doesn''t have sense.
> [snip]
>
> I agree.  It was either a hatchet job or just a poor effort.  The problem
is
> that a lot of people are going to read it and lose interest in btrfs.  I
was
> disheartened but then the analyst in me said, "Wait, this just
can''t be right.
> A copy-on-write file system has got be screaming!"
>
> So I decided to dig deeper.
>
> It might not be a bad idea to get some counter information out there.  It
should
> explicitly reference and refute the phoronix article.  Tom''s
Hardware
> http://www.tomshardware.com/
> is a reputable place.  They would run a fair benchmark and their work would
> carry weight.
>
> BTW, the Sun side of Oracle isn''t likely to release ZFS to the
Linux world
> because they need to preserve a competitive edge for Solaris.
>
> Butters has a future.  Believe it.
I seriously doubt Phoronix has anything against btrfs, most likely
quite the opposite.  My suggestion is either to show where their
benchmarks are in err, or come up with better benchmarks that
demonstrate btrfs in a more positive light.  Its quite possible
Phoronix would post updated benchmarks regarding the topic.

Wil
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Wil Reichert <wil.reichert <at> gmail.com> writes:
> 
> On Tue, Jun 23, 2009 at 6:27 PM, Mike Ramsey<MikeJRamsey <at> 
> comcast.net> wrote:
> > Jaime sanchez <jskartman <at> gmail.com> writes:
> >
> >>
[snip]
> 
> I seriously doubt Phoronix has anything against btrfs, most likely
> quite the opposite.  
I gave two possibilities, 

1. Hatchet job i.e. malice with forethought
2. Just a poor effort

I am not necessary favoring option 1.  Regarding option 2, to err 
is human.

Just admit it, correct it, and then don''t repeat it.
> My suggestion is either to show where their
> benchmarks are in err, 
I did this, didn''t I?
 1. Vertex with write cache enabled; disabled would have seen a 
    2X improvement.
 2. Error in libata
> or come up with better benchmarks that
> demonstrate btrfs in a more positive light.  
That is the ticket.  I suggest that someone contact Tom''s Hardware
http://www.tomshardware.com/

And arrange to work with them to perform an honest benchmark.  
Head to head with Ext4 would work for me.  :-)
> Its quite possible
> Phoronix would post updated benchmarks regarding the topic.
They should either repeat the benchmark and do it right, or print a r
etraction.

BTW, thank you for your reply.  I hope that none of the above sounded 
too harsh. The article was IMO damaging and needs to be countered.

--Mike Ramsey
 
[snip]




--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mike Ramsey wrote (ao):
> Depends on who you talk to.
> 
> http://www.tomshardware.com/news/ocz-ssd-vertex-intel-solid-state,7127.html
> 
> "OCZ Says Its New Vertex SSD Beats Intel''s X25-E"
> 
> I am not taking sides.  I am just saying that the SSD market is fluid.
Read and write speeds specs mean (almost) nothing when it comes to SSD.

The true performance is shown in heavy long-running benchmarks. OCZ has
a long history of very bad performing SSD products.

The Intel SSD did set the standard since it came on the market (hence
the reason OCZ mentions the X25-E).

Btw, not only benchmarks show paper specs mean (almost) nothing: check
the OCZ forums and google on real life usage performance problems
(stutters mostly) under normal to low load.

Especially small writes kill OCZ SSD performance, although their
products have improved with the last releases.

	With kind regards, Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Jun 24 2009, Mike Ramsey wrote:
> Stephan von Krawczynski <skraw <at> ithnet.com> writes:
> 
> [snip]
> > 
> > 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?
> > 
> 
> Depends on who you talk to.
> 
> http://www.tomshardware.com/news/ocz-ssd-vertex-intel-solid-state,7127.html
> 
> "OCZ Says Its New Vertex SSD Beats Intel''s X25-E"
Heh, the Vertex beating the X25-E? I think such a statement could only
come from OCZ. No amount of magic will suddenly make MLC beat SLC, let
alone a well tuned firmware like the X25-E''s. I''m sure they
concocted
some synthetic benchmark where the Vertex has some slight edge. In the
real world, the X25-E wipes the floor with the Vertex.

The Vertex is indeed a good performer, in its price range it''s
currently
the one to beat. I have doubts about the maturity of the product though,
looks mostly like a live beta being tested in the field. So I''d just be
careful with what kind of use they are put to. But just running tests on
the drive does show that it performs well for most things.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 23 Jun 2009 22:47 +0000, "Mike Ramsey"
<MikeJRamsey@comcast.net> wrote:
> Wil Reichert <wil.reichert <at> gmail.com> writes:
> > My suggestion is either to show where their
> > benchmarks are in err, 
> 
> I did this, didn''t I?
>  1. Vertex with write cache enabled; disabled would have seen a 
>     2X improvement.
>  2. Error in libata
Meaning that nobody can turn off the write cache in linux without deep kernel
hackery.

Sounds to me like they are benchmarking the real world rather than trying to
favour btrfs by making changes that are unlikely to be viable for anyone trying
to run it in production.  I.e. they''re benchmarking reality.

Sure there are ways that btrfs performance could be improved, but
they''re not realistically available to mortals selecting "use
btrfs for /home" in their Ubuntu "Bleeding-Edge Badger" release.

Bron.
-- 
  Bron Gondwana
  brong@fastmail.fm

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bron Gondwana <brong <at> fastmail.fm> writes:
> 
> 
> On Tue, 23 Jun 2009 22:47 +0000, "Mike Ramsey" <MikeJRamsey
<at> comcast.net>
wrote:
> > Wil Reichert <wil.reichert <at> gmail.com> writes:
> > > My suggestion is either to show where their
> > > benchmarks are in err, 
> > 
> > I did this, didn''t I?
> >  1. Vertex with write cache enabled; disabled would have seen a 
> >     2X improvement.
> >  2. Error in libata
> 
> Meaning that nobody can turn off the write cache in linux without deep
kernel
hackery.

I would say this differently.  "Meaning that nobody can turn off the write
cache
in linux without applying the known fixes to libata."
> 
> Sounds to me like they are benchmarking the real world rather than trying
to
favour btrfs by making changes
> that are unlikely to be viable for anyone trying to run it in production. 
I.e. they''re benchmarking reality.

Real world is running kernel software that is compatible with the unit under
test.  Benchmarking Butters with a broken kernel is not real world;
it''s unfair.
> 
> Sure there are ways that btrfs performance could be improved, but
they''re not
realistically available to
> mortals selecting "use btrfs for /home" in their Ubuntu
"Bleeding-Edge Badger"
release.

Butters is experimental. Currently, it should only be used under adult
supervision.  I am looking forward to the day that Butters can be used by
novices when they click http://www.ubuntu.com/products/GetUbuntu/download
> 
> Bron.



--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jens Axboe <jens.axboe <at> oracle.com> writes:
> 
> On Wed, Jun 24 2009, Mike Ramsey wrote:
> > Stephan von Krawczynski <skraw <at> ithnet.com> writes:
[snip]
> > Depends on who you talk to.
> > 
> >
http://www.tomshardware.com/news/ocz-ssd-vertex-intel-solid-state,7127.html
> > 
> > "OCZ Says Its New Vertex SSD Beats Intel''s X25-E"
> 
> Heh, the Vertex beating the X25-E? I think such a statement could only
> come from OCZ. No amount of magic will suddenly make MLC beat SLC, let
> alone a well tuned firmware like the X25-E''s. I''m sure
they concocted
> some synthetic benchmark where the Vertex has some slight edge. In the
> real world, the X25-E wipes the floor with the Vertex.
> 
> The Vertex is indeed a good performer, in its price range it''s
currently
> the one to beat. I have doubts about the maturity of the product though,
> looks mostly like a live beta being tested in the field. So I''d
just be
> careful with what kind of use they are put to. But just running tests on
> the drive does show that it performs well for most things.
> 
If I was buying for business than the Intel drives would be my choice.  
They are clearly the quality leader.  For instance, Intel has tweaked 
their firmware to optimize for small IOs.  The X25-E and X25-M are class.
We agree here I think.

For home use where it is *my* money I am willing to have a little faith 
in order to save a couple hundred dollars.  I realize that OCZ and its
controller supplier will be shipping firmware updates.  But don''t kid 
yourself, so is Intel.

BTW, what OCZ did to increase speed was to increase the cache size in 
their large capacity high end Vertex models.  This wouldn''t help my 
30 GB model.

Mike Ramsey


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Jun 24 2009, Mike Ramsey wrote:
> Jens Axboe <jens.axboe <at> oracle.com> writes:
> 
> > 
> > On Wed, Jun 24 2009, Mike Ramsey wrote:
> > > Stephan von Krawczynski <skraw <at> ithnet.com>
writes:
> [snip]
> > > Depends on who you talk to.
> > > 
> > >
http://www.tomshardware.com/news/ocz-ssd-vertex-intel-solid-state,7127.html
> > > 
> > > "OCZ Says Its New Vertex SSD Beats Intel''s
X25-E"
> > 
> > Heh, the Vertex beating the X25-E? I think such a statement could only
> > come from OCZ. No amount of magic will suddenly make MLC beat SLC, let
> > alone a well tuned firmware like the X25-E''s. I''m
sure they concocted
> > some synthetic benchmark where the Vertex has some slight edge. In the
> > real world, the X25-E wipes the floor with the Vertex.
> > 
> > The Vertex is indeed a good performer, in its price range
it''s currently
> > the one to beat. I have doubts about the maturity of the product
though,
> > looks mostly like a live beta being tested in the field. So
I''d just be
> > careful with what kind of use they are put to. But just running tests
on
> > the drive does show that it performs well for most things.
> > 
> 
> If I was buying for business than the Intel drives would be my choice.  
> They are clearly the quality leader.  For instance, Intel has tweaked 
> their firmware to optimize for small IOs.  The X25-E and X25-M are class.
> We agree here I think.
> 
> For home use where it is *my* money I am willing to have a little faith 
> in order to save a couple hundred dollars.  I realize that OCZ and its
> controller supplier will be shipping firmware updates.  But don''t
kid
> yourself, so is Intel.
Of course they do, everything has bugs. What I''m worried about is the
severity of those bugs, and the amount and quality of testing that has
gone into these products.
> BTW, what OCZ did to increase speed was to increase the cache size in 
> their large capacity high end Vertex models.  This wouldn''t help
my
> 30 GB model.
It''s easy to throw cache at the problem and make it faster.
That''s like
shaving weight off a car. Might make it go faster, definitely wont make
it safer.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Jun 24, 2009 at 12:57:40PM +0000, Mike Ramsey
wrote:
> Bron Gondwana <brong <at> fastmail.fm> writes:
> > Meaning that nobody can turn off the write cache in linux without deep
kernel
> > hackery.
> 
> I would say this differently.  "Meaning that nobody can turn off the
write cache
> in linux without applying the known fixes to libata."
Depending on the environment you''re in, building a non-default kernel
can be tricky.
> > Sounds to me like they are benchmarking the real world rather than
trying to
> favour btrfs by making changes
> > that are unlikely to be viable for anyone trying to run it in
production.
> I.e. they''re benchmarking reality.
> 
> Real world is running kernel software that is compatible with the unit
under
> test.  Benchmarking Butters with a broken kernel is not real world;
it''s unfair.
Well, yeah.  The world''s full of unfair stuff.  I would find this
valuable
information to have if I had a kernel of that vintage.
 
> > Sure there are ways that btrfs performance could be improved, but
they''re not
> realistically available to
> > mortals selecting "use btrfs for /home" in their Ubuntu
"Bleeding-Edge Badger"
> release.
> 
> Butters is experimental. Currently, it should only be used under adult
> supervision.  I am looking forward to the day that Butters can be used by
> novices when they click http://www.ubuntu.com/products/GetUbuntu/download
Yeah, that would be nice.  I still use reiser3 in locations where I need a
good all-round filesystem.

Bron ( who probably should get a current kernel again - but the .30rcs were
       causing fun and games with my soundcard and I didn''t have time
to go
       debuggerising them )
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, 24 Jun 2009 19:38:37 +0200
Jens Axboe <jens.axboe@oracle.com> wrote:
> [...]
> It''s easy to throw cache at the problem and make it faster.
That''s like
> shaving weight off a car. Might make it go faster, definitely wont make
> it safer.
Interestingly nobody talks about "the other end" of the ssd market.
Ok, a cf
card isn''t really a ssd, but it is basically the same technology
without very
intelligent controllers in front. So if you really want to see improvements
from ssd options this might be the most visible platform for playing. And
again, this is indeed a mainstream market, lots of routers and other embedded
gadgets use this - currently mostly implementing ram disks for performance
reasons.

-- 
Regards,
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html