[Gluster-users] gluster 3.2.0 - totally broken?

[Stephan von Krawczynski]

On Fri, 20 May 2011 08:35:35 -0400
Jeff Darcy <jdarcy at redhat.com> wrote:

> On 05/20/2011 05:15 AM, Stephan von Krawczynski wrote:
> > Sorry, this clearly shows the problem: understanding. It really does
> > not help you a lot to hire a big number of people, you do not fail in
> > terms of business relation. Your problem is the _code_. You need a 
> > filesystem expert. A _real_ one, not _some_ one. Like lets say
> > Daniel Phillips, Theodore "Ted" Ts'o or the like.
> 
> I know both Daniel and Ted professionally. As a member of the largest
> Linux filesystem group in the world, I am also privileged to work with
> many other world-class filesystem experts. I also know the Gluster folks
> quite well, and I can assure you that they have all the filesystem
> expertise they need. They also have a *second* kind of expertise -
> distributed systems - which is even more critical to this work and which
> the vast majority of filesystem developers lack.  What Gluster needs is
> not more filesystem experts but more *other kinds* of experts as well as
> non-experts and resources.  The actions AB has mentioned are IMO exactly
> those Gluster should be taking, and should be appreciated as such by any
> knowledgeable observer.
> 
> Your flames are not only counter-productive but factually incorrect as
> well. Please, if only for the sake of your own reputation, try to do
> better.

Forgive my ignorance Jeff, but it is obvious to anyone having used glusterfs
for months or years that the guys have a serious software design issue. If you
look at the "tuning" options configurable in glusterfs you should notice that
most of them are just an outcome of not being able to find a working i.e. best
solution for a problem. cache-timeout? thread-count? quick-read?
stat-prefetch? Gimme a break. Being a fs I'd even say all the cache-size paras
are bogus. When did you last tune the ext4 cache size or timeout? Don't come
up with ext4 being kernel vs. userspace fs. It was their decision to make it
userspace, so don't blame me. As a fs with networking it has to take the
comparison with nfs - as most interested users come from nfs. The first thing
they experience is that glusterfs is really slow compared to their old setups
with nfs. And the cause is _not_ replication per se. And as long as they
cannot cope with nfs performance my argument stands: they have a problem,be it
inferior per design or per coding.
As you see I am not talking at all about things that I count as basics in a
replication fs. I mean, really, I cannot express my feelings about the lack of
information for the admin around replication. Its pretty much like a wheel of
your car just fell off and you cannot find out which one. Would you trust that
car?
Let me clearly state this: the idea is quite brilliant, but the coding is at 
the stage of a design study and could have been far better if they only
concentrated on the basics. If you want to build a house you don't buy the tv
set at first...

-- 
Regards,
Stephan