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