Description of problem: Setup : 4 Nodes gluster cluster with samba ctdb setup. Same volume is mounted over two different windows client. (Client1-Volume1 & Client2-Volume1) create a file or a directory over one of the windows client volume share, rename that file. Now over the other windows client try to rename the same. It throws error stating file path not available. Version-Release number of selected component (if applicable): samba-4.6.2-0.el7rhgs.x86_64 glusterfs-3.8.4-23.el7rhgs.x86_64 Windwos10 How reproducible: 8/10 Steps to Reproduce: 1.Create file A.txt in windows client1 2.Rename file A.txt to B.txt in windows client1 3.Rename file B.txt back to A.txt in windows client2 Actual results: Does not allow to rename, throws error Expected results: Should not have any issue with above steps Additional info:
This bug has the same RCA as https://bugzilla.redhat.com/show_bug.cgi?id=1416450. The scenario for this to happen is: client 1: touch File1 client 2: lookup File1 client 1: rename FILE1 to FILE2 client 2: lookup File2 client 1: rename FILE2 to FILE1 client 2: lookup File1 client 2: rename FILE1 to FILE2 => fails with FILE2 already exists. This is because on a rename, the md-cache invalidates the inodes stat, but the dentry from the inode table is not removed(as its global and in in libglusterfs). And md-cache serves lookup based on inode not names, as it stores cache in inode_ctx. If the gfapi/fuse resolve code resolves a name to an inode, and if md-cache has latest data for that inode, it serves the lookup irrespective of the dentry it belongs to.
Since this is a rare scenario, i think it can be deferred from 3.3
Fixing this bug requires invalidation of inode dentry in libglustrefs on receiving upcall(resulted from other client doing rename/unlink).
Not worked on the bug for 2.5 years - closing.