+++ This bug was initially created as a clone of Bug #1502455 +++

Description of problem:
The current behavior of the option disperse.eager-lock is not optimal:

disperse.eager-lock on: good performance on large-file read/write, but actually degrades performance for many file create workloads. The degradation for file create workloads seems to be due to lock contention on directories.

disperse.eager-lock off: loses the performance advantages of eager-locking for large-file access, but better performance on file create workloads than with disperse.eager-lock on.

We should fix eager locking so that it can be kept on without incurring a performance penalty on file create workloads.

Version-Release number of selected component (if applicable):
glusterfs*-3.12.1-2.el7.x86_64

How reproducible:
Consistently

--- Additional comment from Manoj Pillai on 2017-10-16 07:32:52 CEST ---


IMO, a solution that adds a separate option to control eager locking in the case of directories would be acceptable, and probably simple. 

So the default could be:
disperse.dir-eager-lock off: applies to directories
disperse.eager-lock on: applies to regular files

Would that work?

--- Additional comment from Xavier Hernandez on 2017-10-16 10:12:26 CEST ---

I guess this problem happens when multiple clients are creating files on the same directory, right ? otherwise, eager-locking shouldn't interfere with file creation (in fact it should be faster).

In cases where multiple clients access the same directory, then yes, we could keep a separate configuration for this purpose. However, is it really necessary to have it disabled by default ? I think that an scenario where multiple clients are writing to the same directory is less probable than one where all writes to a single directory come from the same client.