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

[Ric Wheeler]

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