Bug 1444509

Summary:	[SAMBA]Rename of files & directories fails when multiple windows clients are involved
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Vivek Das <vdas>
Component:	md-cache	Assignee:	Michael Adam <madam>
Status:	CLOSED DEFERRED	QA Contact:	Vivek Das <vdas>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rhgs-3.3	CC:	amukherj, rhs-bugs, rhs-smb, storage-qa-internal
Target Milestone:	---	Keywords:	EasyFix, ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-12-12 22:08:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1416450
Bug Blocks:

Description Vivek Das 2017-04-21 13:23:03 UTC

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:

Comment 3 Poornima G 2017-05-12 12:58:34 UTC

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.

Comment 4 Poornima G 2017-05-12 12:59:17 UTC

Since this is a rare scenario, i think it can be deferred from 3.3

Comment 8 Poornima G 2018-11-19 06:56:00 UTC

Fixing this bug requires invalidation of inode dentry in libglustrefs on receiving upcall(resulted from other client doing rename/unlink).

Comment 10 Yaniv Kaul 2019-12-12 22:08:06 UTC

Not worked on the bug for 2.5 years - closing.