> [1 <text/plain; us-ascii (7bit)>] Run this on the client in a
> separate window:
> while usleep 100000; do ls notfound; done
> Go to the server and create the "notfound" file. The client
> script will never see this file due to caching. When the usleep
> is increased towards 1 second then the file will be found in
> most cases (but not all -- different issues).
> There are actually two aspects:
> - negative dentry caching
> - persistent negative dentry cache entries.
> The second one is clearly a bug, the first one may be wanted or
> unwanted behavior. The patch simply disables negative dentry
> caching to avoid both.
> Consider the source (fs/nfs/dir.c, around line 400): static
> inline int nfs_neg_need_reval(struct dentry *dentry) {
> unsigned long timeout = 30 * HZ; long diff = CURRENT_TIME -
> dentry->d_parent->d_inode->i_mtime;
> if (diff < 5*60)
> timeout = 1 * HZ;
> return time_after(jiffies, dentry->d_time + timeout);
> ^^^^^^^^^^^^^^
> }
> The observed behavior suggests that the dentry->d_time of a
> negative dentry is updated somwehere. Either that is a bug or
> using this time here (or not resetting it) is a bug. It is the
> cause I guess for the persistent negative dentry bug.
> -- Frank [2 nfs-negdentry.bugfix <text/plain; us-ascii (7bit)>]
> --- linux/fs/nfs/dir.c.orig Wed Aug 4 16:10:31 1999
> +++ linux/fs/nfs/dir.c Thu Aug 5 12:40:14 1999
> @@ -427,14 +427,11 @@
> struct nfs_fattr fattr;
> /*
> - * If we don't have an inode, let's look at the parent
> - * directory mtime to get a hint about how often we
> - * should validate things..
> + * If we don't have an inode then let the caller redo a
> lookup.
> + * Negative dentry caching is dangerous and should be optional
> anyway.
> */
> if (!inode) {
> - if (nfs_neg_need_reval(dentry))
> - goto out_bad;
> - goto out_valid;
> + goto out_bad;
> }
> if (is_bad_inode(inode)) {
This will in most cases put an unreasonable burden on the network with
huge numbers of NFS_LOOKUP requests. Linus rejected a similar patch
around the pre-patch-2.2.8 series for this very reason. The current
code was the best compromise that could be reached.
It will work quite reasonably for UNIX filesystems (except for entries
just below the mountpoint for which we currently have a small bug in
the updating of attributes), but may indeed be a problem for
VFAT-style filesystems that don't update directory mtimes.
Where are you BTW seeing persistent negative dentries? They should
never occur.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/