Re: Release plan
Hi there, On Mon, Jun 22, 2009 at 4:53 PM, Mike Ramsey michael.j.ram...@lmco.com wrote: I was looking at file systems for Linux, Ubuntu in particular. I really like Sun's ZPF. ZPF's copy-on-write transaction model strikes me as the correct way to go. But ZPF lacks a GNU General Public License which blocks ZPF's adoption by the Linux kernel. This led me to btrfs. You mean ZFS, but I think everybody who read this self-corrected your typo. I understand that the B-TRee File System is a copy-on-write file system for Linux announced by Oracle in 2007 and published under the GNU General Public License (GPL). For planning purposes, what timeframe do you see for releasing a stable version of btrfs? I am not a paying customer nor am I an annoying manager. I am just curious as to when I should plan to start paying closer attention. 4Q 2009? 2Q 2010? Filesystems take a long time to mature, btrfs is stable enough for daily use, has long has you don't use it for sensitive/critical data. There are still some problems, the most anoying being the premature out of space/disc full errors. I would say that in time for Fedora 12, you will probably have a btrfs more usable for the common user, but still not advised for the faint of heart. Consider the time that ext4 took to mature and for people to trust it. Ext4 is stable for quite some months, but even now, the majority of recent distro builds choose ext3 has the default filesystem. Again.. filesystems take quite a bit of time to mature... disclaimer: I'm not a btrfs developer, just a entusiast that follows the developement. Kind regards, -- 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 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: Release plan
Miguel F Mascarenhas Sousa Filipe miguel.filipe at gmail.com writes: [snip] You mean ZFS, but I think everybody who read this self-corrected your typo. Yes, I mean ZFS. ZFS used to be known as the Zettapoint File System. I guess my subconsciousness couldn't let go of the point. [snip] File systems take a long time to mature, btrfs is stable enough for daily use, has long has you don't use it for sensitive/critical data. There are still some problems, the most annoying being the premature out of space/disc full errors. I would say that in time for Fedora 12, you will probably have a btrfs more usable for the common user, but still not advised for the faint of heart. Consider the time that ext4 took to mature and for people to trust it. Ext4 is stable for quite some months, but even now, the majority of recent distro builds choose ext3 has the default file system. Again.. file systems take quite a bit of time to mature... [snip] I know. A schedule has an amazing way of focusing people on what is important. There may be ten things that should be done but not all ten things need to be done. :-) --Best regards, --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
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
