Phoronix article slaming BTRFS

Phoronix article slaming BTRFS

[Mike Ramsey]

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

Re: Phoronix article slaming BTRFS

[Miguel F Mascarenhas Sousa Filipe]

On Tue, Jun 23, 2009 at 3:51 AM, Mike Ramsey<MikeJRamsey@comcast.net> w=
rote:
> I ran across this article "Testing Out The SSD Mode In Btrfs".
> http://www.phoronix.com/scan.php?page=3Darticle&item=3Dbtrfs_ssd_mode=
&num=3D1
>
> At first I was disappointed. =C2=A0It gave a very disappointing set o=
f benchmarks.
> However, a close reading revealed this:
>
> "With the OCZ Vertex SATA 2.0 SSD, which we used for this testing tod=
ay, had its
> write caching always enabled. When attempting to disable the write ca=
che through
> hdparm it would remain enabled regardless and when using sdparm it wo=
uld 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,
> =C2=A0My information may be out of date, but last time I
> =C2=A0looked libata didn't support MODE SELECT which is
> =C2=A0the SCSI command to change mode page settings.
> =C2=A0[I have sent patches several times to add support
> =C2=A0for 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. =C2=A0So 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 =C2=A0http://vger.kernel.org/majordomo-info.ht=
ml
>



--=20
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

Re: Phoronix article slaming BTRFS

[Jaime sanchez]

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 =BF? 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

Re: Phoronix article slaming BTRFS

[Mike Ramsey]

Jaime sanchez <jskartman <at> gmail.com> writes:

>=20
> They are using 2.6.29.4 kernel, it isn't a bit old??
>=20
>  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 a=
re
>  benchmarking an experimental file system benchmark it with the lates=
t
>  updates =C2=BF? it doesn't have sense.
[snip]=20

I agree.  It was either a hatchet job or just a poor effort.  The probl=
em 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.=20
A copy-on-write file system has got be screaming!" =20

So I decided to dig deeper. =20

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 w=
ould
carry weight.

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

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

Re: Phoronix article slaming BTRFS

[Wil Reichert]

On Tue, Jun 23, 2009 at 6:27 PM, Mike Ramsey<MikeJRamsey@comcast.net> w=
rote:
> Jaime sanchez <jskartman <at> gmail.com> writes:
>
>>
>> They are using 2.6.29.4 kernel, it isn't a bit old??
>>
>> =C2=A0I think that kernel doesn't have the last btrfs updates, and t=
hat it
>> =C2=A0is a very bad work and benchmarks results from phoronix part. =
If u are
>> =C2=A0benchmarking an experimental file system benchmark it with the=
 latest
>> =C2=A0updates =C2=BF? it doesn't have sense.
> [snip]
>
> I agree. =C2=A0It was either a hatchet job or just a poor effort. =C2=
=A0The problem is
> that a lot of people are going to read it and lose interest in btrfs.=
 =C2=A0I 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.=
 =C2=A0It should
> explicitly reference and refute the phoronix article. =C2=A0Tom's Har=
dware
> http://www.tomshardware.com/
> is a reputable place. =C2=A0They 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. =C2=A0Believe 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

Re: Phoronix article slaming BTRFS

[Mike Ramsey]

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]

Re: Phoronix article slaming BTRFS

[Bron Gondwana]

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

Re: Phoronix article slaming BTRFS

[Mike Ramsey]

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.

Re: Phoronix article slaming BTRFS

[Bron Gondwana]

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 )

Re: Phoronix article slaming BTRFS

[Chris Mason]

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

Re: Phoronix article slaming BTRFS

[Sander]

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

Re: Phoronix article slaming BTRFS

[Chris Mason]

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

Re: Phoronix article slaming BTRFS

[Stephan von Krawczynski]

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

Re: Phoronix article slaming BTRFS

[Chris Mason]

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

Re: Phoronix article slaming BTRFS

[Mike Ramsey]

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

Re: Phoronix article slaming BTRFS

[Sander]

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

Re: Phoronix article slaming BTRFS

[Jens Axboe]

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

Re: Phoronix article slaming BTRFS

[Mike Ramsey]

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

Re: Phoronix article slaming BTRFS

[Jens Axboe]

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

Re: Phoronix article slaming BTRFS

[Stephan von Krawczynski]

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

Re: Phoronix article slaming BTRFS

[Jaime sanchez]

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 =BF? 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

Re: Phoronix article slaming BTRFS

[nightrow]

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

I think we should expect them to run it periodicaly against newer versi=
on.

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

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 ar=
e
> benchmarking an experimental filesystem benchmark it with the lastest
> updaets =BF? it doesn't have sense.
>
>  =20



--
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

Re: Phoronix article slaming BTRFS

[Jaime sanchez]

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 i=
n the
> benchmarking section, you will notice that the test was made more tha=
n 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 ver=
sion.
>
> I made the link to the phoronix test. They may not be the best, but t=
his 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 a=
re
>> benchmarking an experimental filesystem benchmark it with the lastes=
t
>> updaets =BF? 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