On 15 May 2014 14:35, Ric Wheeler <rwheeler@xxxxxxxxxx> 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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
