Bug 765563 (GLUSTER-3831)

Summary:	ENOENT when Node replaced by another machine
Product:	[Community] GlusterFS	Reporter:	Anush Shetty <anush>
Component:	protocol	Assignee:	Amar Tumballi <amarts>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.2.4	CC:	gluster-bugs, vraman
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.4.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	854633 (view as bug list)		Environment:
Last Closed:	2013-07-24 17:14:08 UTC	Type:	---
Regression:	RTP	Mount Type:	fuse
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	854633

Description Anush Shetty 2011-11-28 12:22:06 UTC

From gluster-devel mailing list

After machine2 replaced the node, machine1 gets the new inode number using READDIR, but the inode number returned by LOOKUP is the one for the deleted node. The only way to work it around is to unmount and remount the filesystem.

machine1# cd /gfs/stale && ls -l
total 4
drwxr-xr-x  2 root  wheel  2048 Nov 27 06:47 a

machine2# cd /gfs/stale && cp -r a b && rm -Rf a && mv b a

machine1# ls -l 
ls: a: No such file or directory
machine1# cd a
machine1# ls
ls: .: No such file or directory
machine1# cd /gfs/stale 
machine1# ls -l
ls: a: No such file or directory

Comment 1 Amar Tumballi 2011-12-01 07:38:40 UTC

Is this tried to reproduce? I see that fuse-bridge already has a mechanism to re-validate the inodes.

Please try to reproduce on master branch, and confirm the behavior.

Comment 2 Amar Tumballi 2012-12-24 09:25:17 UTC

not seen in master branch now (after an year of bug report), please test with 3.4.0qa series and see if it happens again.