[Gluster-devel] Regression tests: Should we test non-XFS too?

[James]

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 at 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 at gluster.org
> >> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
> >>
> >
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://supercolony.gluster.org/mailman/listinfo/gluster-devel
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140513/bc877127/attachment-0002.sig>