Re: nfs_inode_cache not getting pruned

[Tigran Aivazian]

On Wed, 7 Jul 2004, Andrew Morton wrote:
> Sorry, I still cannot reproduce it.  I suspect it's specific to the access
> patterns in some way.

A simple access pattern that drives mad any filesystem over NFS is:

# symlink & readlink & unlink &

symlink.c is while (1) symlink("a", "/test/b");
readlink.c is while(1) readlink("/test/b", buf, 900);
unlink.c is while(1) unlink("/test/b");

On the server nothing interesting happens (except expected messages about
"//b" being already there and d_count being too high):

nfs_safe_remove: //b busy, d_count=2
nfs_proc_symlink: //b already exists??
nfs_proc_symlink: //b already exists??
nfs_proc_symlink: //b already exists??
nfs_proc_symlink: //b already exists??
nfs_proc_symlink: //b already exists??
nfs_proc_symlink: //b already exists??
nfs_proc_symlink: //b already exists??
nfs_safe_remove: //b busy, d_count=2
nfs_proc_symlink: //b already exists??
nfs_proc_symlink: //b already exists??

But on the client the inode_cache and dentry_cache grow indefinitely. The
kernel (both client and server) is 2.4.21-15.ELsmp (haven't tried on 2.6
yet). The fs on the server was ext3 made with default options and mounted 
with defaults and exported with:

/mnt *(rw,no_root_squash,insecure,no_subtree_check,sync)

Btw, this access pattern was suggested by running racer. If you run the
whole racer over NFS you may hit other interesting problems after a
while.

Kind regards
Tigran

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/