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--u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nfs-negdentry.bugfix"
--- 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)) {
--u3/rZRmxL6MmkK24--
- 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/