Bug 761848 (GLUSTER-116)

Summary:	Replicate: Need inode number from first subvolume on fresh lookup
Product:	[Community] GlusterFS	Reporter:	Shehjar Tikoo <shehjart>
Component:	replicate	Assignee:	Shehjar Tikoo <shehjart>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	mainline	CC:	gluster-bugs
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	RTP	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Shehjar Tikoo 2009-07-08 06:26:37 UTC

We know that replicate needs to do a lookup from multiple subvolumes on a fresh lookup request. It is possible that the inode number returned in this new lookup is different from the ino returned to the previous lookup for the same file.

This behaviour can break things for tools like unfs3 which depend on the same inode number, in order to map file handles to files.

Right now, libglusterfsclient works around this by avoiding the pruning of inodes. This has its limits since the memory consumption by the inode table will constantly increase.

This is not a bug but I think more of a feature required for a narrow bunch of tools. I am alright with having an option in replicate that forces it to return inode from one particular sub-volume when this option is set. In other cases, it does sound like a better idea to keep the current behaviour of round-robin'ing or load-balancing the fresh lookups among the various subvolumes.

Comment 1 Shehjar Tikoo 2009-07-10 05:03:41 UTC

Fix committed to release-2.0 branch.
http://git.savannah.gnu.org/cgit/gluster.git/commit/?h=release-2.0&id=b23c9fcc8a16b8c4a4b1814ff5035a18f03da0f4

Pending on mainline.


I'll defer changing the status till the time when I've done some tests with unfs3
and libglusterfsclient.

Comment 2 Anand Avati 2009-07-16 03:14:45 UTC

PATCH: http://patches.gluster.com/patch/722 in master (Return inode number always from the first up subvolume in AFR.)

Comment 3 Shehjar Tikoo 2009-07-19 06:02:34 UTC

Committed to master also:
http://git.savannah.gnu.org/cgit/gluster.git/commit/?id=161188e919968f1d782e857151f2f4dca1fdfc22

Comment 4 Shehjar Tikoo 2009-07-23 09:53:43 UTC

In recent tests using unfs3, booster and replicate and distribute, I do not see any failures due to stale file handles. This is with version 0.5 of unfs3booster and the patches that will be part of 2.0.5 release.