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 reportchange_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/[email protected]/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
On Tue, Jun 23, 2009 at 3:51 AM, Mike Ramsey<[email protected]> w= rote:
Quoted 2 lines
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
Quoted 2 lines
At first I was disappointed. =C2=A0It gave a very disappointing set o=
f benchmarks.
Quoted 3 lines
However, a close reading revealed this:
"With the OCZ Vertex SATA 2.0 SSD, which we used for this testing tod=
ay, had its
Quoted 1 line
write caching always enabled. When attempting to disable the write ca=
che through
Quoted 1 line
hdparm it would remain enabled regardless and when using sdparm it wo=
uld report
Quoted 3 lines
change_mode_page: failed setting page: Caching (SBC)."This invalidates the benchmark! Disabling the write cache would yield=
a 2X
Quoted 16 lines
improvement.
Digging deeper, I found this:
http://www.mail-archive.com/[email protected]/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.
Quoted 8 lines
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...
Quoted 6 lines
--Mike Ramsey
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
Quoted 2 lines
the body of a message to [email protected]
More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht=
ml
Quoted 1 line
--=20
Miguel Sousa Filipe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · 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
Quoted 1 line
benchmarking an experimental file system benchmark it with the lates=
t
Quoted 1 line
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 23, 2009 at 6:27 PM, Mike Ramsey<[email protected]> w= rote:
Quoted 6 lines
Quoted 4 lines · 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
Quoted 1 line
Quoted 1 line
=C2=A0is a very bad work and benchmarks results from phoronix part. =
If u are
Quoted 1 line
Quoted 1 line
=C2=A0benchmarking an experimental file system benchmark it with the=
latest
Quoted 4 lines
Quoted 1 line
=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
Quoted 1 line
that a lot of people are going to read it and lose interest in btrfs.=
=C2=A0I was
Quoted 1 line
disheartened but then the analyst in me said, "Wait, this just can't =
be right.
Quoted 5 lines
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
Quoted 1 line
explicitly reference and refute the phoronix article. =C2=A0Tom's Har=
dware
Quoted 2 lines
http://www.tomshardware.com/
is a reputable place. =C2=A0They would run a fair benchmark and their=
work would
Quoted 3 lines
carry weight.
BTW, the Sun side of Oracle isn't likely to release ZFS to the Linux =
world
Quoted 3 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Wil Reichert <wil.reichert <at> gmail.com> writes:
Quoted 3 lines · On Tue, Jun 23, 2009 at 6:27 PM, Mike Ramsey<MikeJRamsey <at> comcast.net>…
Quoted 1 line · Jaime sanchez <jskartman <at> gmail.com> writes:
[snip]
Quoted 3 lines
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.
Quoted 2 lines
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
Quoted 2 lines
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. :-)
Quoted 2 lines
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]
Quoted 8 lines · Mike Ramsey
Quoted 2 lines · 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.
Signature · 2 lines
Bron Gondwana [email protected]
Quoted 3 lines · Bron Gondwana <brong <at> fastmail.fm> writes:
On Tue, 23 Jun 2009 22:47 +0000, "Mike Ramsey" <MikeJRamsey <at> comcast.net>
Quoted 10 lines · wrote:
Quoted 8 lines
Quoted 2 lines · 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 libataMeaning 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."
Quoted 2 lines
Sounds to me like they are benchmarking the real world rather than trying to
favour btrfs by making changes
Quoted 1 line
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.
Quoted 2 lines
Sure there are ways that btrfs performance could be improved, but they're not
realistically available to
Quoted 1 line
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
Quoted 2 lines
Bron.
Quoted 6 lines · Mike Ramsey
Quoted 2 lines · 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.
Quoted 7 lines
Quoted 1 line
Sounds to me like they are benchmarking the real world rather than trying to
favour btrfs by making changes
Quoted 1 line
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.
Quoted 8 lines
Quoted 1 line
Sure there are ways that btrfs performance could be improved, but they're not
realistically available to
Quoted 1 line
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 )
Quoted 6 lines · 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=1At first I was disappointed. It gave a very disappointing set of benchmarks. However, a close reading revealed this:
Quoted 7 lines
"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
Chris Mason wrote (ao):
Quoted 4 lines
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.
Signature · 2 lines
Humilis IT Services and Solutions http://www.humilis.net
Quoted 10 lines · Sander
Chris Mason wrote (ao):
Quoted 4 lines
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
Quoted 21 lines · On Tue, 23 Jun 2009 10:41:23 -0400 Chris Mason <[email protected]> wrote:
Quoted 6 lines · 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=1At first I was disappointed. It gave a very disappointing set of benchmarks. However, a close reading revealed this:
Quoted 7 lines
"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 ;)
Quoted 6 lines
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?
Signature · 2 lines
Regards, Stephan
Quoted 29 lines · Stephan von Krawczynski
Quoted 26 lines · On Tue, 23 Jun 2009 10:41:23 -0400 Chris Mason <[email protected]> wrote:
Quoted 6 lines · 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=1At first I was disappointed. It gave a very disappointing set of benchmarks. However, a close reading revealed this:
Quoted 7 lines
"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.
Quoted 6 lines
Quoted 1 line
-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.
-chris
Stephan von Krawczynski <skraw <at> ithnet.com> writes:
[snip]
Quoted 11 lines
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
Mike Ramsey wrote (ao):
Quoted 7 lines
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
Signature · 2 lines
Humilis IT Services and Solutions http://www.humilis.net
Quoted 15 lines · Mike Ramsey
Stephan von Krawczynski <skraw <at> ithnet.com> writes:
[snip]
Quoted 11 lines
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?
Quoted 5 lines
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.
Signature · 1 line
Jens Axboe
Quoted 3 lines · Jens Axboe <jens.axboe <at> oracle.com> writes:
Quoted 1 line · Mike Ramsey
Stephan von Krawczynski <skraw <at> ithnet.com> writes:
[snip]
Quoted 12 lines
Quoted 5 lines
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.
Quoted 6 lines
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
Quoted 30 lines · Mike Ramsey
Quoted 3 lines · Jens Axboe <jens.axboe <at> oracle.com> writes:
Quoted 1 line · Mike Ramsey
Stephan von Krawczynski <skraw <at> ithnet.com> writes:
[snip]
Quoted 12 lines
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Signature · 1 line
Jens Axboe
Quoted 4 lines · On Wed, 24 Jun 2009 19:38:37 +0200 Jens Axboe <[email protected]> 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.
Signature · 2 lines
Regards, Stephan
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 [email protected]
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=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.
Quoted 4 lines · 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 ar=
e
Quoted 4 lines
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 [email protected]
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.
Quoted 1 line · nightrow
If you look here : http://btrfs.wiki.kernel.org/index.php/Main_Page i=
n the
Quoted 1 line
benchmarking section, you will notice that the test was made more tha=
n one
Quoted 5 lines
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.
Quoted 2 lines
I made the link to the phoronix test. They may not be the best, but t=
his is
Quoted 13 lines
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.
Quoted 5 lines · 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 a=
re
Quoted 1 line
Quoted 1 line
benchmarking an experimental filesystem benchmark it with the lastes=
t
Quoted 7 lines
Quoted 3 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html