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

[Joe Julian]

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 <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