Re: Phoronix article slaming BTRFS
On Wed, 24 Jun 2009 19:38:37 +0200 Jens Axboe jens.ax...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
On Tue, 23 Jun 2009 22:47 +, Mike Ramsey mikejram...@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 br...@fastmail.fm -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
Bron Gondwana brong at fastmail.fm writes: On Tue, 23 Jun 2009 22:47 +, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
On Tue, Jun 23, 2009 at 3:51 AM, Mike Ramseymikejram...@comcast.net wrote: I ran across this article Testing Out The SSD Mode In Btrfs. http://www.phoronix.com/scan.php?page=articleitem=btrfs_ssd_modenum=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-s...@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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
On Tue, Jun 23, 2009 at 02:51:41AM +, Mike Ramsey wrote: I ran across this article Testing Out The SSD Mode In Btrfs. http://www.phoronix.com/scan.php?page=articleitem=btrfs_ssd_modenum=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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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.ma...@oracle.com wrote: On Tue, Jun 23, 2009 at 02:51:41AM +, Mike Ramsey wrote: I ran across this article Testing Out The SSD Mode In Btrfs. http://www.phoronix.com/scan.php?page=articleitem=btrfs_ssd_modenum=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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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, nightrownight...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Phoronix article slaming BTRFS
On Tue, Jun 23, 2009 at 6:27 PM, Mike Ramseymikejram...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Phoronix article slaming BTRFS
I ran across this article Testing Out The SSD Mode In Btrfs. http://www.phoronix.com/scan.php?page=articleitem=btrfs_ssd_modenum=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-s...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
