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
