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
Created attachment 1341564 [details] lock-rename.c
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:2607