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
