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

[Dan Mons]

On 15 May 2014 14:35, Ric Wheeler <rwheeler at redhat.com> wrote:
>
> it is up to those developers and users to test their preferred combination.
>

Not sure if this was quoting me or someone else.  BtrFS is in-tree for
most distros these days, and RHEL is putting it in as a "technology
preview" in 7, which likely means it'll be supported in a point
release down the road somewhere.  My question was merely if that's
going to be a bigger emphasis for Gluster.org folks to test into the
future, or if XFS is going to remain the default/recommended for a lot
longer yet.

If the answer is "it depends on our customers' needs", then put me
down as one who needs something better than XFS.  I'll happily put in
the hard yards to test BtrFS with GlusterFS, but at the same time I'm
keen to know if that's a wise use of my time or a complete waste of my
time if I'm deviating too far from what RedHat/Gluster.org is planning
on blessing in the future.

>
> The reason to look at either ZFS or btrfs is not really performance driven
> in most cases.
>

"Performance" means different things to different people.  For me,
part of XFS's production performance is how frequently I need to
xfs_repair my 40TB bricks.  BtrFS/ZFS drastically reduces this sort of
thing thanks to various checksumming properties not native to other
current filesystems.

When I average my MB/s over 6 months in a 24x7 business, a weekend
long outage required to run xfs_repair my entire cluster has as much
impact (potentially even more) as a file system with slower file IO
performance.

XFS is great when it works.  When it doesn't, there's tears and
tantrums.  Over the course of a production year, that all impacts
"performance" when the resolution of my Munin graphs are that low.

-Dan