Bug 763857 (GLUSTER-2125)

Summary: Zero-ed out GFID causes hash collision during nfs fh resolution
Product: [Community] GlusterFS Reporter: Shehjar Tikoo <shehjart>
Component: nfsAssignee: Shehjar Tikoo <shehjart>
Status: CLOSED DUPLICATE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: mainlineCC: 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: nfs
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Shehjar Tikoo 2010-11-17 10:48:13 UTC 
In cases where some dirs are created directly on the backend,  either by users or by the disk FS like the lost+found dir, these new dirs do not contain the GFID attr. NFS gets a zero-ed out iatt->ia_gfid in such case. Because the hash for this gfid will be 0, it ends up matching a directory whose hash may be zero.

ANother situation is when the 0 hash is compared to a hash value beyond the hash idx in the FH resulting in a successful hash match. Eventually, it causes an ESTALE because we ended up taking the wrong dir path.

Simple solution is to use a salt value when computing the hash.
Comment 1 Shehjar Tikoo 2011-02-22 03:26:49 UTC 
Been looking into this bug and I think we should leave this out of 3.1.3.

The addition of a salt value will change the encoding scheme of the FH. If a user upgrades from 3.1.2 to 3.1.3, the nfs clients will start receiving ESTALE because the nfs server will not recognize the old file handles.

In effect, this bug is similar to bug 763781.

*** This bug has been marked as a duplicate of bug 2049 ***