Red Hat Bugzilla – Bug 227373
link() on nfsv4 sometimes fails to update i_nlink count
Last modified: 2007-11-16 20:14:55 EST
This was noticed at connectathon running cthon04 basic test7 against a Solaris
10 NFS server. This is the rename and link test. Sometimes, after creating a
hardlink, a follow-on stat call would still show that i_nlink hadn't been
The issue seems to be that we're not properly doing a postop attribute update
after the LINK call.
Created attachment 147380 [details]
patch 1 -- add restorefh xdr calls
Preliminary patch to add the xdr functions for RESTOREFH.
Created attachment 147381 [details]
patch 2 -- optimize nfs4 link calls and add postop attributes
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Oct 27 22:12:42 2005 -0400
NFSv4: Add post-op attributes to nfs4_proc_link()
Optimise attribute revalidation when hardlinking. Add post-op attributes
for the directory and the original inode.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Reproducer here is pretty much identical to the one in 227249:
On an nfs4 mount:
$ mkdir d1 d2
$ touch d1/foo; stat d1/foo; ln d1/foo d2/bar; stat d1/foo
The second stat should show 2 hardlinks, but it usually shows only 1. With a
combination of the two patches in this BZ, the problem goes away.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
This request was evaluated by Red Hat Kernel Team for inclusion in a Red
Hat Enterprise Linux maintenance release, and has moved to bugzilla
*** Bug 237894 has been marked as a duplicate of this bug. ***
It's not clear to me that this is a regression, though maybe we opened a race
window with a different patch and that makes this occur more often, or we
eliminated a GETATTR somewhere.
It looks like Steve D. made mention of seeing this issue as well, and said that
the patchset for bz155929 seemed to fix it for him. This does not seem to be the
case since we still see the problem even with his patches.
I think this patch is the surest way to fix this since it ensures that the attrs
are updated after the link.
committed in stream U6 build 55.6. A test kernel with this patch is available
added to RHEL4.6 release notes under "Kernel-Related Updates":
fixed an nfsv4 link bug that prevented i_nlink counts from updating properly
please advise if any revisions are necessary. thanks!
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.