[Gluster-users] glusterfs performance issues

[Stephan von Krawczynski]

On Mon, 07 Jan 2013 20:21:25 -0800
Joe Julian <joe at julianfamily.org> wrote:

> >> I don't know the answer. I know that they want this problem to be
> >> solved, but right now the best solution is hardware. The lower the
> >> latency, the less of a problem you'll have.
> > The only solution is correct programming, no matter what the below hardware
> > looks like. The only outcome of good or bad hardware is how _fast_ the
> > _correct_ answer reaches the fs client.
> Yes, if you can control the programming of your application, that would 
> be a better solution. Unfortunately most of us use pre-packaged software 
> like apache, php, etc. Since most of us don't have the chance to use the 
> "correct programming" solution, then you're going to need to decrease 
> latency if your going to open thousands of fd's for every operation and 
> are unsatisfied with the results.

I am _not_ talking about the application software. I am talking about the fact
that everybody using glusterfs has seen glusterfs choosing the _wrong_ (i.e.
old) version of a file from a brick just coming back from downstate to the
replicated unit.
In fact I already saw just about every possibility you can think of when
accessing files, be it a simple "ls" or writing or reading a file.
I verified files being absent if opened although shown in "ls". I saw outdated
file content, although timestamp in "ls" being up to date. I saw file content
being new although "ls" shows outdated file date _and_ length.
Please don't tell me the fs has no immanent confusion about the various stats
of different bricks.
I don't state this happens with every file, I'm just saying it does happen.
Am I the only one with these kind of experiences?

-- 
Regards,
Stephan