Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
On 05/20/2014 04:01 AM, Vijay Bellur wrote: On 05/19/2014 06:56 AM, Dan Mons wrote: On 15 May 2014 14:35, Ric Wheeler 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. From a gluster.org perspective, btrfs is certainly very interesting. Integrating with btrfs and exposing its capabilities like bitrot, snapshots etc. through glusterfs is on the cards. There have been few reports of using glusterfs over btrfs in the community. I would definitely be interested in hearing more feedback and addressing issues in this combination by collaborating with the btrfs community. Regards, Vijay I agree that btrfs is an interesting technology and it would be great to have people work on it to make it more stable and see what it can do for us in gluster. That said, I think that XFS will continue to be the most stable and high performance file system for the next few years and has become increasingly common across many distros and in places like openstack :) Always interesting to hear what you find worrying about XFS or why it does not meet your needs. ric ___ 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/19/2014 06:56 AM, Dan Mons wrote: On 15 May 2014 14:35, Ric Wheeler 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. From a gluster.org perspective, btrfs is certainly very interesting. Integrating with btrfs and exposing its capabilities like bitrot, snapshots etc. through glusterfs is on the cards. There have been few reports of using glusterfs over btrfs in the community. I would definitely be interested in hearing more feedback and addressing issues in this combination by collaborating with the btrfs community. Regards, Vijay ___ 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 15 May 2014 14:35, Ric Wheeler 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 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 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 Wed, 2014-05-14 at 07:55 +1000, 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... > > 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 +1 > , 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. > > 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? I'd like to start fooling around with it myself. One partial blocker for me is: https://bugzilla.redhat.com/show_bug.cgi?id=1094857 I think that if I make it easy to try out with Puppet-Gluster, then more people might be interested. This situation is more positive, because Vagrant on Fedora got easier: https://ttboj.wordpress.com/2014/05/13/vagrant-on-fedora-with-libvirt-reprise/ and vagrant-libvirt now supports adding extra disks, so I can simulate a real gluster deployment with xfs bricks. https://github.com/purpleidea/puppet-gluster/commit/a80a7a64835d450c168c4cede18ed156095a4fd7 > > 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? > > 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 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 > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel signature.asc Description: This is a digitally signed message part ___ 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 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. 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 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 ___ 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 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
Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
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... 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. 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? 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 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 ___ 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 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 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
Re: [Gluster-devel] Regression tests: Should we test non-XFS too?
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. 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. -- Kaleb ___ 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?
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, would it help if someone outside ran the tests and reported the results periodically? On Wed, May 7, 2014 at 12:04 AM, James wrote: > On Mon, 2014-04-14 at 15:50 -0400, Ric Wheeler wrote: > > On 04/07/2014 08:55 AM, Kaleb S. KEITHLEY wrote: > > > On 04/05/2014 01:23 PM, Vijay Bellur wrote: > > >> On 04/05/2014 10:27 PM, Justin Clift wrote: > > >>> On 05/04/2014, at 5:17 PM, James wrote: > > On Sat, Apr 5, 2014 at 11:37 AM, Justin Clift > > wrote: > > > So, are people interested in us running the tests on other > > > brick filesystem types, such as ext4? (or whatever else) > > > > Yes, absolutely, but I think it's btrfs that will matter, not ext4. > > >>> > > >>> > > >>> Cool. Running the tests on CentOS 6.5 VM's at the moment, so will > need > > >>> to investigate btrfs for that. :) > > >> > > >> We need to increase the number of variables for our regression runs. > > >> Hence running on both ext4 and btrfs would be nice to have. > > > > > > Seconded. I almost hesitate to say it, but we should probably test on > zfs too. > > > > The ZFS kernel modules cannot be legally shipped with either RHEL or > CentOS - > > end users (according to some lawyers) can download and run it themselves. > > > > Testing ZFS it iffy for those of us at Red Hat at least :) > > > > > > > >> > > >>> > > >>> If btrfs on CentOS 6.5 isn't a go-er (no idea), we'll need to get the > > >>> tests running cleanly on something where it is. Maybe Fedora 20? > > >>> (again, no idea, would have to check) :) > > >> > > >> btrfs on Fedora 20 is probably a better bet than CentOS 6.5. > > >> > > > > > > btrfs is in the kernel. There's a > > > > /lib/modules/2.6.32-431.11.2.el6.centos.plus.x86_64/kernel/fs/btrfs/btrfs.ko > > > on my CentOS 6.5 box. You can get btrfs-progs from epel. > > > > > > A cursory look at the diff between the RHEL6.5 .../fs/btrfs source and > the > > > Fedora .../fs/btrfs source doesn't look too different; if we're > worried about > > > the relative stability of btrfs. It's my understanding that it was > only the > > > lack of an fsck utility that was hindering its adoption in RHEL. > > > > > > I'd say we ought to test on both RHEL/CentOS and Fedora. With our > limited > > > resources we just need to prioritize accordingly. > > > > > > And if there's some concern about the diff between btrfs-progs-0.20.0 > in > > > RHEL/CentOS versus btrfs-progs-3.12-1 in Fedora, I suspect we can build > > > btrfs-progs-3.12-1 for RHEL and CentOS. > > > > > > > I would use a recent Fedora or (eventually) RHEL7 versions of the kernel > to test > > btrfs. The btrfs code in Fedora (and RHEL7) tracks upstream well, > RHEL6/CentOS6 > > is pretty old and rife with bugs (data loss/performance/you name it). > > > > Btrfs is tech preview in RHEL6.x so you should not need to get anything > from > > EPEL - the utilities should be there. > > So your message motivated me to start working on a patch for btrfs in > Puppet-Gluster. I think this is an easy way to get btrfs+gluster in the > hands of users, testers, developers. I made a feature bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1094860 > > with WIP patch: > https://github.com/purpleidea/puppet-gluster/tree/feat/btrfs > > Turns out choosing UUID's is missing in btrfs: > https://bugzilla.redhat.com/show_bug.cgi?id=1094857 > > which blocks this for now. Would love to know if you know the correct > person to address this missing feature. > > Note hacking on this is now quite easy with vagrant-libvirt thanks to: > > https://github.com/purpleidea/vagrant-libvirt/commit/be2042537e4f8f3e59a7880bf3e09358252be252 > > https://github.com/purpleidea/vagrant-libvirt/commit/72fbedaaca00302b433a2cbb25983b036f9a9619 > > HTH, > James > > > > > Testing ext4 on RHEL6.x/CentOS should be fine though, > > > > Ric > > > > > > > > > > ___ > > Gluster-devel mailing list > > gluster-de...@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/gluster-devel > > > ___ > 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 Mon, 2014-04-14 at 15:50 -0400, Ric Wheeler wrote: > On 04/07/2014 08:55 AM, Kaleb S. KEITHLEY wrote: > > On 04/05/2014 01:23 PM, Vijay Bellur wrote: > >> On 04/05/2014 10:27 PM, Justin Clift wrote: > >>> On 05/04/2014, at 5:17 PM, James wrote: > On Sat, Apr 5, 2014 at 11:37 AM, Justin Clift > wrote: > > So, are people interested in us running the tests on other > > brick filesystem types, such as ext4? (or whatever else) > > Yes, absolutely, but I think it's btrfs that will matter, not ext4. > >>> > >>> > >>> Cool. Running the tests on CentOS 6.5 VM's at the moment, so will need > >>> to investigate btrfs for that. :) > >> > >> We need to increase the number of variables for our regression runs. > >> Hence running on both ext4 and btrfs would be nice to have. > > > > Seconded. I almost hesitate to say it, but we should probably test on zfs > > too. > > The ZFS kernel modules cannot be legally shipped with either RHEL or CentOS - > end users (according to some lawyers) can download and run it themselves. > > Testing ZFS it iffy for those of us at Red Hat at least :) > > > > >> > >>> > >>> If btrfs on CentOS 6.5 isn't a go-er (no idea), we'll need to get the > >>> tests running cleanly on something where it is. Maybe Fedora 20? > >>> (again, no idea, would have to check) :) > >> > >> btrfs on Fedora 20 is probably a better bet than CentOS 6.5. > >> > > > > btrfs is in the kernel. There's a > > /lib/modules/2.6.32-431.11.2.el6.centos.plus.x86_64/kernel/fs/btrfs/btrfs.ko > > > > on my CentOS 6.5 box. You can get btrfs-progs from epel. > > > > A cursory look at the diff between the RHEL6.5 .../fs/btrfs source and the > > Fedora .../fs/btrfs source doesn't look too different; if we're worried > > about > > the relative stability of btrfs. It's my understanding that it was only the > > lack of an fsck utility that was hindering its adoption in RHEL. > > > > I'd say we ought to test on both RHEL/CentOS and Fedora. With our limited > > resources we just need to prioritize accordingly. > > > > And if there's some concern about the diff between btrfs-progs-0.20.0 in > > RHEL/CentOS versus btrfs-progs-3.12-1 in Fedora, I suspect we can build > > btrfs-progs-3.12-1 for RHEL and CentOS. > > > > I would use a recent Fedora or (eventually) RHEL7 versions of the kernel to > test > btrfs. The btrfs code in Fedora (and RHEL7) tracks upstream well, > RHEL6/CentOS6 > is pretty old and rife with bugs (data loss/performance/you name it). > > Btrfs is tech preview in RHEL6.x so you should not need to get anything from > EPEL - the utilities should be there. So your message motivated me to start working on a patch for btrfs in Puppet-Gluster. I think this is an easy way to get btrfs+gluster in the hands of users, testers, developers. I made a feature bug: https://bugzilla.redhat.com/show_bug.cgi?id=1094860 with WIP patch: https://github.com/purpleidea/puppet-gluster/tree/feat/btrfs Turns out choosing UUID's is missing in btrfs: https://bugzilla.redhat.com/show_bug.cgi?id=1094857 which blocks this for now. Would love to know if you know the correct person to address this missing feature. Note hacking on this is now quite easy with vagrant-libvirt thanks to: https://github.com/purpleidea/vagrant-libvirt/commit/be2042537e4f8f3e59a7880bf3e09358252be252 https://github.com/purpleidea/vagrant-libvirt/commit/72fbedaaca00302b433a2cbb25983b036f9a9619 HTH, James > > Testing ext4 on RHEL6.x/CentOS should be fine though, > > Ric > > > > > ___ > Gluster-devel mailing list > gluster-de...@nongnu.org > https://lists.nongnu.org/mailman/listinfo/gluster-devel signature.asc Description: This is a digitally signed message part ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
