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 <joe@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx > >> http://supercolony.gluster.org/mailman/listinfo/gluster-devel > >> > > > > _______________________________________________ > > Gluster-devel mailing list > > Gluster-devel@xxxxxxxxxxx > > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
