On December 9, 2015 at 10:31:03 AM, Raghavendra Gowdappa (rgowdapp@xxxxxxxxxx) wrote: > forking off since it muddles the original conversation. I've some questions: > > 1. Why do multiple writes need to be compounded together? > 2. If the reason is aggregation, cant we tune write-behind to do the same? I think compounding (as we’ve been discussing it) is only necessary when there’s a dependency between operations. For example, if the first creates a value (e.g. file descriptor) used by the second, or if the second should not proceed unless the first (e.g. a lock) succeeded. If multiple operations are completely independent of one another, as is the case for writes without fsync, then I think we should rely on write-behind or something similar instead. Compounding is likely to be the wrong solution here for two reasons: * Correctness: if the writes are independent, there’s no reason why failure of the first should cause the second not to be issued (as would be the case with compounding). * Performance: compounding would keep the writes separate, whereas write-behind can reduce overhead even more by coalescing them into a single request. There is, however, one case where compounding would be the right answer: when there really is a dependency between the writes. There’s no way to specify this through the POSIX/VFS interface (more’s the pity), but it’s easy to imagine GFAPI or internal use cases where a second write should not overtake or continue without the first - e.g. a key/value store that writes new data followed by an index update pointing to that data. The strictly-sequential behavior of a compound operation might be just the right match for such cases. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
