Gluster users - Jun 2020 - State of Gluster project

On 6/18/20 12:41 PM, Stephan von Krawczynski wrote
> Top Poster ;-)
>
> And in fact, it's not true. The clear message to me once was: we are
not able
> to make a kernel version.
> Which I understood as: we have not the knowledge to do that.
> Since that was quite some time before Red Hat stepped in there was still
hope
> that some day someone capable may come ...
> Since 2009 when I entered the list there was not a single month where there
> were no complaints about gluster being slow. I wonder if you could accept
> after 11 years and the projects near death now that I was right from the
very
> first day.
>
>
This is an amazingly unreasonable comment.
First off ALL distributed file systems are slower than non-distributed 
file systems.
Second ALL network file systems are slower than local hardware.

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.

If your so convinced that a kernel included file system is the answer 
you are free to implement a solution.
I am sure the project maintainers would love to have someone come along 
and improve the code.

-- 
Alvin Starr                   ||   land:  (647)478-6285
Netvel Inc.                   ||   Cell:  (416)806-0133
alvin at netvel.net              ||

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