Bug 763857 - (GLUSTER-2125) Zero-ed out GFID causes hash collision during nfs fh resolution
Zero-ed out GFID causes hash collision during nfs fh resolution
Status: CLOSED DUPLICATE of bug 763781
Product: GlusterFS
Classification: Community
Component: nfs (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Shehjar Tikoo
Depends On:
  Show dependency treegraph
Reported: 2010-11-17 05:48 EST by Shehjar Tikoo
Modified: 2015-12-01 11:45 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: RTP
Mount Type: nfs
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Shehjar Tikoo 2010-11-17 05:48:13 EST
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-21 22:26:49 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.