Gluster users - Jun 2020 - State of Gluster project

On Thu, 18 Jun 2020 13:27:19 -0400
Alvin Starr <alvin at netvel.net> wrote:
> >  [me]
> This is an amazingly unreasonable comment.
> First off ALL distributed file systems are slower than non-distributed 
> file systems.
Obviously you fail to understand my point: the design of glusterfs implies
that it can be as fast as a non-distributed fs. If you have not understood
this by now you should stay another 10 years on this list.
As glusterfs should only read from a single node, and write concurrently to
all nodes it must only be slower than a non-distributed fs if your network is
not designed according to the needed paths. Glusterfs being
slow is not by design but by implementation.
> Second ALL network file systems are slower than local hardware.
Uh, really no comment.
 
> Kernel inclusion does not make for a radically faster implementation.
> I have worked with Kernel included NFS and user space NFS 
> implementations and the performance differences have not been all that 
> amazingly radical.
Probably you are not talking about linux based NFS experience. The last time
we used userspace nfs (very long ago) on linux it was slow _and_ amazingly
buggy. Many thanks to Neil that he made kernel nfs what it is today.
 
> If your so convinced that a kernel included file system is the answer 
> you are free to implement a solution.
Well, people were _paid_ for years now and came up with this mess. And you
want me to implement it for free in what time? If you give me the bucks that
were paid during the last decade you can be sure the solution is a lot
better, easier to configure, and thought-through.
> I am sure the project maintainers would love to have someone come along 
> and improve the code.
Yes, we perfectly agree on that.

-- 
Regards,
Stephan

My concern for Glusterd2 deprecation is, it tried to implement and fix
several things that we need in Gluster, and the promised features were not
considered in Gluster afterward "better logging, Journal Based
Replication".
We're running both Ceph and Gluster, while both solutions are great in
terms of features and performance, Gluster is a little bit behind in terms
of stability and monitoring, We have multiple production clusters running
Gluster and Red Hat Gluster, and both are somehow challenging
"stability wise" when trying to update or replace a node or brick,
administration operations are risky.
Troubleshooting tools is something also has not improved from the past
releases.
The strength of Gluster, in my opinion, is the simplicity of creating
distributed volumes that can be consumed by different clients, and this is
why we chose Gluster back in 2016 as our main VMs Storage backend for
VMWare and oVirt.
Red Hat contribution to the project is important of course and when we see
that major product like OCS is replacing Gluster with Ceph raises some
eyebrows.
The announcement of Kadalu a few months ago "or at least when we noticed
it" was uncomfortable, as part of the core team of Gluster is now focusing
on a new project, although it is depending on Gluster, Kadalu is focusing
on persistence storage for containers, while Gluster use cases are not
limited to containers.
We suffered "and still" from performance issues with Gluster on use
cases related to small files, but Gluster as a storage backend for Virtual
Machines is really performant.
Sadly I haven't contributed to the project, but I still want this project
to evolve more and be used widely as I still see it as a good Distributed
Storage option, with the hope of more focus on stability, tooling for
easier troubleshooting and practical monitoring.

-- 
Respectfully
Mahdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20200619/a01f080d/attachment.html>