Description of problem:

Through Multiple client file update, few times results in  'No such file or directory' and whole completion time is much more than a single client update


Version-Release number of selected component (if applicable):

glusterfs-server-3.8.4-44.el7rhgs.x86_64

How reproducible:

Customer Environment

Steps to Reproduce:

- We have a file name 'property' which is being accessed by multiple clients.
- Client 1 takes a lock on file 'property'
- Create a tmp file something like 'property.tmp' 
- Update the tmp file
- Rename the tmp file to 'property' again and replaced the older 'property' file
- Other client repeat the process


Additional info:

Initial thought was issue can be a cache coherency issue. Imagine the following hypothetical scenario:
A file f1 is looked up by client2 and the inode number for f1 - say inode1 - is cached by VFS of client2.  A rename (f2, f1) is done by client1, which changes the inode number of f1 to inode2 (as inode2 was the inode number of f2 before rename). client2 tries to access f1. However VFS passes inode1 to glusterfs as the cache is not updated with new inode2 for f1. Since inode1 doesn't exist, the access fails with ENOENT.

As per this hypothesis,test has been done by setting entry-timeout and attribute-timeout values as 0 while mounting client1 and client2.
# mount -t glusterfs <volfile-server>:/<volfile-name> -o entry-timeout=0,attribute-timeout=0 <mount-path>

Even with this, same issue is happening