A customer is facing a problem caused by a negative lookup in the same second the file is created on another machine. Since the mtime on the directory does not change, the negative lookup never expires. The customer tried using an upstream kernel with the lookupcache=pos option and confirmed that it works for them. This request is to backport the following GIT commits to enable finer grain control over the lookup cache. commit 4eec952e42314b53e48fef1f54dd89cbf9789734 Author: Trond Myklebust <Trond.Myklebust> Date: Tue Jul 15 17:58:13 2008 -0400 NFS: Add options for finer control of the lookup cache Add the flag NFS_MOUNT_LOOKUP_CACHE_NONEG to turn off the caching of negative dentries. In reality what we do is to force nfs_lookup_revalidate() to always discard negative dentries. Add the flag NFS_MOUNT_LOOKUP_CACHE_NONE for enforcing stricter revalidation of dentries. It forces the revalidate code to always do a lookup instead of just checking the cached mtime of the parent directory. Signed-off-by: Trond Myklebust <Trond.Myklebust> commit 7973c1f15a0687f47ed70e591e4642d6fc4334d0 Author: Trond Myklebust <Trond.Myklebust> Date: Tue Jul 15 17:58:14 2008 -0400 NFS: Add mount options for controlling the lookup cache Add the following NFS-specific mount options to the parser. -o lookupcache=all /* Default: cache positive & negative dentries */ -o lookupcache=pos[itive] /* Don't cache negative dentries */ -o lookupcache=none /* Strict revalidation of all dentries */ Signed-off-by: Trond Myklebust <Trond.Myklebust> The corresponding changes will also have to be made to the nfs-utils directory.
Created attachment 334489 [details] Reproducer for the negative lookup problem seen at customer Reproducer for negative lookup problem seen on customer systems. 2 machines mounting the nfs share on the same location are required. Change the remote_machine and set it to the hostname of the second client machine. ssh keys will have to be set to allow reproducing user to login into the second machine to execute commands. The reproducer aims to do a negative lookup within the same second the file is created on the second machine. Since the mtime on the directory is not modified, the negative lookup on the first machine never expires.
Created attachment 334538 [details] Add finer grained control over lookup cache. Proposed Patch 1 of 2. Backport of: commit 4eec952e42314b53e48fef1f54dd89cbf9789734 Author: Trond Myklebust <Trond.Myklebust> Date: Tue Jul 15 17:58:13 2008 -0400 NFS: Add options for finer control of the lookup cache Add the flag NFS_MOUNT_LOOKUP_CACHE_NONEG to turn off the caching of negative dentries. In reality what we do is to force nfs_lookup_revalidate() to always discard negative dentries. Add the flag NFS_MOUNT_LOOKUP_CACHE_NONE for enforcing stricter revalidation of dentries. It forces the revalidate code to always do a lookup instead of just checking the cached mtime of the parent directory. Signed-off-by: Trond Myklebust <Trond.Myklebust>
Created attachment 334540 [details] Add lookupcache mount option Patch 2 of 2 Backport of: commit 7973c1f15a0687f47ed70e591e4642d6fc4334d0 Author: Trond Myklebust <Trond.Myklebust> Date: Tue Jul 15 17:58:14 2008 -0400 NFS: Add mount options for controlling the lookup cache Add the following NFS-specific mount options to the parser. -o lookupcache=all /* Default: cache positive & negative dentries */ -o lookupcache=pos[itive] /* Don't cache negative dentries */ -o lookupcache=none /* Strict revalidation of all dentries */ Signed-off-by: Trond Myklebust <Trond.Myklebust>
BZ 489335: Add lookupcache option for the userland nfs-utils package.
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 release.
in kernel-2.6.18-136.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please do NOT transition this bugzilla state to VERIFIED until our QE team has sent specific instructions indicating when to do so. However feel free to provide a comment indicating that this fix has been verified.
*** Bug 500528 has been marked as a duplicate of this bug. ***
~~ Attention - RHEL 5.4 Beta Released! ~~ RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner! If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value. Questions can be posted to this bug or your customer or partner representative.
We appear to be missing the necessary code in RHEL5 for nfs4 mounts to recognise the lookupcache option. On nfs4 mounts I get # mount -t nfs4 -o lookupcache=all 192.168.122.11:/ /mnt unknown nfs mount parameter: lookupcache=0 Is there any intention to get this support added?
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The lookupcache nfs mount option is only available for NFS v3 in this release. Support for NFSv4 may be introduced in a future Red Hat Enterprise Linux 5 update. Please refer to Red Hat bugzilla 511312 for further information.
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 therefore 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. http://rhn.redhat.com/errata/RHSA-2009-1243.html