[Gluster-users] Small File and "ls" performance ..

[Anand Avati]

Barry,
  Some clarifications below -

On Fri, Jun 4, 2010 at 9:17 PM, Barry Jaspan <barry.jaspan at acquia.com> wrote:
> 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.

When flush-behind is on, the flush/close is indeed done in the
background, but only after the last write has returned. Applications
will _not_ miss the error of previous writes in close(). The
operations performed in flush() itself are just maintenance tasks
(like clearing pending locks, freeing data structures etc) and it does
not make sense for the application to wait for the round trip of the
message which performs these non critical operations on the server
side. That is what flush-behind does.


> 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.

The default behavior change was not very critical (as explained
above), so there wasn't a need for a bigger announcement.

> 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.

Reliability of writes in both the cases are exactly the same.

Thanks,
Avati