Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
On 15 May 2014 14:35, Ric Wheeler rwhee...@redhat.com wrote: it is up to those developers and users to test their preferred combination. Not sure if this was quoting me or someone else. BtrFS is in-tree for most distros these days, and RHEL is putting it in as a technology preview in 7, which likely means it'll be supported in a point release down the road somewhere. My question was merely if that's going to be a bigger emphasis for Gluster.org folks to test into the future, or if XFS is going to remain the default/recommended for a lot longer yet. If the answer is it depends on our customers' needs, then put me down as one who needs something better than XFS. I'll happily put in the hard yards to test BtrFS with GlusterFS, but at the same time I'm keen to know if that's a wise use of my time or a complete waste of my time if I'm deviating too far from what RedHat/Gluster.org is planning on blessing in the future. The reason to look at either ZFS or btrfs is not really performance driven in most cases. Performance means different things to different people. For me, part of XFS's production performance is how frequently I need to xfs_repair my 40TB bricks. BtrFS/ZFS drastically reduces this sort of thing thanks to various checksumming properties not native to other current filesystems. When I average my MB/s over 6 months in a 24x7 business, a weekend long outage required to run xfs_repair my entire cluster has as much impact (potentially even more) as a file system with slower file IO performance. XFS is great when it works. When it doesn't, there's tears and tantrums. Over the course of a production year, that all impacts performance when the resolution of my Munin graphs are that low. -Dan ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
On 05/14/2014 04:20 AM, Joe Julian wrote: On 5/13/2014 2:55 PM, Dan Mons wrote: Not trying to start a flame war (don't you love posts that start like this). And also, this might be slightly off-topic in this thread... I don't take it as such. ZFS is clearly painful to use in large Linux environments due to licensing, and thus a lack of simple packaging. We avoid ZFS for this reason, and the fact that due to this reason nobody else is really using it in anger on Linux (or if they are, they're not reporting publicly, so the lack of community documentation pushes us away from it). Likewise we'll never get support from anyone for ZFS on Linux, so if it blows up in our face, we're stuck. Never the less, there are users in the community using ZFSoL. Like any community supported open-source software, if you're not using a supported platform you're pretty much on your own. I don't think that precludes us from trying to avoid breaking something that's already working for some people. To paraphrase Linus, if it breaks [storage] it's a [GlusterFS] bug. It would be nice to be proactive on this, imho. My personal preference is to work on mainstream, in tree file systems and to work to improve those. Just to be clear, how you (and your lawyers if you have them!) interpret the license things are up to you. More than happy to have other people test it out, but we have no plans for Red Hat employed people to do that. Same story for other out of tree file systems (some open source, some closed source) - it is up to those developers and users to test their preferred combination. And to poke back at both btrfs and zfs, I do strongly suspect that XFS (and ext4) will both out perform them for some time to come, especially on complicated storage with the largest loads. The reason to look at either ZFS or btrfs is not really performance driven in most cases. Regards, Ric BtrFS is destined to be the next big thing for Linux file systems, and roughly feature-equivalent with ZFS for the important stuff (checksumming is the big one for most of us, with the volume of data we hold, and the pain we've all faced with XFS on large volumes). Best of all it's GPL and in the kernel, and nobody has to deal with the pain of the intentionally-incompatible CDDL codebase of ZFS. What's the goal for both RHEL and GlusterFS as far as BtrFS goes? RHEL7 seems to be going the conservative path with BtrFS still being marked beta/testing. Is there a roadmap to move it on past this? Likewise the GlusterFS official docs still state XFS is the primary candidate. Is there a plan to push BtrFS more heavily for future releases? Will there be an eventual goal for both projects to make BtrFS the default target? There are use cases for each. BtrFS is slow for heavy random write workloads making it inappropriate for those if performance matters. I have no problem with ZFS - it's a great file system. The licensing sucks, however, and doesn't look like it will ever change given who the current custodians are. As long as that's the case, I'd really like to see more effort from everyone (not just GlusterFS and RHEL) pushing BtrFS as the long term goal for large Linux file systems. -Dan Dan Mons Unbreaker of broken things Cutting Edge http://cuttingedge.com.au On 14 May 2014 05:18, Joe Julian j...@julianfamily.org wrote: On Tue, May 13, 2014 6:33 am, Ric Wheeler wrote: On 05/07/2014 05:17 PM, Kaleb S. KEITHLEY wrote: On 05/06/2014 10:44 PM, B.K.Raghuram wrote: For those of us who are toying with the idea of using ZFS as the underlying filesystem but are hesitating only because it is not widely tested, a regression test on ZFS would be very welcome. If there are some issues running it at redhat for license reasons, Yes, there are issues with running it at Red Hat for exactly those reasons. License issues and in general we don't test on out of upstream tree (and I know the open zfs team itself are not the reason that it is out of tree :)) ric I thought we were upstream. Are these tests run on Red Hat equipment or at Rackspace? If we're testing things upstream from Red Hat on hosts for which Red Hat has no legal obligation, can we not test on differently licensed subsystems? Frankly, since there's no inclusion of code, headers, libraries, etc. in GlusterFS, there's no mixing of licenses. Just to have a test that shows that something still works doesn't affect copyright, in my non-legally trained opinion. would it help if someone outside ran the tests and reported the results periodically? Yes, if someone were to do that I'm sure it would be appreciated. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
On 05/14/2014 04:20 AM, Joe Julian wrote: On 5/13/2014 2:55 PM, Dan Mons wrote: Not trying to start a flame war (don't you love posts that start like this). And also, this might be slightly off-topic in this thread... I don't take it as such. ZFS is clearly painful to use in large Linux environments due to licensing, and thus a lack of simple packaging. We avoid ZFS for this reason, and the fact that due to this reason nobody else is really using it in anger on Linux (or if they are, they're not reporting publicly, so the lack of community documentation pushes us away from it). Likewise we'll never get support from anyone for ZFS on Linux, so if it blows up in our face, we're stuck. Never the less, there are users in the community using ZFSoL. Like any community supported open-source software, if you're not using a supported platform you're pretty much on your own. I don't think that precludes us from trying to avoid breaking something that's already working for some people. To paraphrase Linus, if it breaks [storage] it's a [GlusterFS] bug. It would be nice to be proactive on this, imho. My personal preference is to work on mainstream, in tree file systems and to work to improve those. Just to be clear, how you (and your lawyers if you have them!) interpret the license things are up to you. More than happy to have other people test it out, but we have no plans for Red Hat employed people to do that. Same story for other out of tree file systems (some open source, some closed source) - it is up to those developers and users to test their preferred combination. And to poke back at both btrfs and zfs, I do strongly suspect that XFS (and ext4) will both out perform them for some time to come, especially on complicated storage with the largest loads. The reason to look at either ZFS or btrfs is not really performance driven in most cases. Regards, Ric BtrFS is destined to be the next big thing for Linux file systems, and roughly feature-equivalent with ZFS for the important stuff (checksumming is the big one for most of us, with the volume of data we hold, and the pain we've all faced with XFS on large volumes). Best of all it's GPL and in the kernel, and nobody has to deal with the pain of the intentionally-incompatible CDDL codebase of ZFS. What's the goal for both RHEL and GlusterFS as far as BtrFS goes? RHEL7 seems to be going the conservative path with BtrFS still being marked beta/testing. Is there a roadmap to move it on past this? Likewise the GlusterFS official docs still state XFS is the primary candidate. Is there a plan to push BtrFS more heavily for future releases? Will there be an eventual goal for both projects to make BtrFS the default target? There are use cases for each. BtrFS is slow for heavy random write workloads making it inappropriate for those if performance matters. I have no problem with ZFS - it's a great file system. The licensing sucks, however, and doesn't look like it will ever change given who the current custodians are. As long as that's the case, I'd really like to see more effort from everyone (not just GlusterFS and RHEL) pushing BtrFS as the long term goal for large Linux file systems. -Dan Dan Mons Unbreaker of broken things Cutting Edge http://cuttingedge.com.au On 14 May 2014 05:18, Joe Julian j...@julianfamily.org wrote: On Tue, May 13, 2014 6:33 am, Ric Wheeler wrote: On 05/07/2014 05:17 PM, Kaleb S. KEITHLEY wrote: On 05/06/2014 10:44 PM, B.K.Raghuram wrote: For those of us who are toying with the idea of using ZFS as the underlying filesystem but are hesitating only because it is not widely tested, a regression test on ZFS would be very welcome. If there are some issues running it at redhat for license reasons, Yes, there are issues with running it at Red Hat for exactly those reasons. License issues and in general we don't test on out of upstream tree (and I know the open zfs team itself are not the reason that it is out of tree :)) ric I thought we were upstream. Are these tests run on Red Hat equipment or at Rackspace? If we're testing things upstream from Red Hat on hosts for which Red Hat has no legal obligation, can we not test on differently licensed subsystems? Frankly, since there's no inclusion of code, headers, libraries, etc. in GlusterFS, there's no mixing of licenses. Just to have a test that shows that something still works doesn't affect copyright, in my non-legally trained opinion. would it help if someone outside ran the tests and reported the results periodically? Yes, if someone were to do that I'm sure it would be appreciated. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
On Tue, May 13, 2014 6:33 am, Ric Wheeler wrote: On 05/07/2014 05:17 PM, Kaleb S. KEITHLEY wrote: On 05/06/2014 10:44 PM, B.K.Raghuram wrote: For those of us who are toying with the idea of using ZFS as the underlying filesystem but are hesitating only because it is not widely tested, a regression test on ZFS would be very welcome. If there are some issues running it at redhat for license reasons, Yes, there are issues with running it at Red Hat for exactly those reasons. License issues and in general we don't test on out of upstream tree (and I know the open zfs team itself are not the reason that it is out of tree :)) ric I thought we were upstream. Are these tests run on Red Hat equipment or at Rackspace? If we're testing things upstream from Red Hat on hosts for which Red Hat has no legal obligation, can we not test on differently licensed subsystems? Frankly, since there's no inclusion of code, headers, libraries, etc. in GlusterFS, there's no mixing of licenses. Just to have a test that shows that something still works doesn't affect copyright, in my non-legally trained opinion. would it help if someone outside ran the tests and reported the results periodically? Yes, if someone were to do that I'm sure it would be appreciated. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
On 14 May 2014 07:55, Dan Mons dm...@cuttingedge.com.au wrote: What's the goal for both RHEL and GlusterFS as far as BtrFS goes? RHEL7 seems to be going the conservative path with BtrFS still being marked beta/testing. Is there a roadmap to move it on past this? This showed up in some Googling: http://rhsummit.files.wordpress.com/2014/04/rwheeler_thursday_0945_rhel7_beta_file_systems.pdf -Dan ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
