I am concerned about this patch: updated write-behind default values - http://patches.gluster.com/patch/3223/ > It changes the default value for performance/writebehind's flush-behind option from off to on. My understanding is that when flush-behind is off, all writes are done in the background but flush/close are blocking, which means they can return a valid error code. When flush-behind is on, the flush/close are also done in the background and so must always return success---which means an application has no way to know if the write really succeeded. There are certainly use cases where "fire and forget" is a valid write strategy. However, silently changing the DEFAULT behavior for something this critical to reliability does not seem like a good idea. Regarding Joshua's performance test results with untar'ing the linux kernel, I'm not at all surprised that he got such a huge speedup. However, the results are not really comparable, because one set was obtained with reliable writes, and the other was not. Barry
