Bug 174010

Description of problem:

NFS client does not appear to reliably timeout its AC and reload from server if
the server's directory has changed.

Version-Release number of selected component (if applicable):

kernel-smp-2.6.14-1.1707_FC5.i686

Seen on current rawhide i686 client; also seen on older rawhide kernels for the
past 2 or 3 weeks.

How reproducible:

100%; trivially reproducible.

Steps to Reproduce:

1. On server:
$ mkdir ~/t
$ echo Hello > ~/t/tmp

2. On client, wait for a string to appear in this file:
$ until grep -q foo t/tmp ; do echo -n . ; sleep 1 ; done

3. On server, create a *new* file with the same name containing that string:
$ mv ~/t/tmp ~/t/tmp.old; echo foo > ~/t/tmp

Actual results:

Update file contents do not appear any time soon.  I've seen it appear after 4
minutes; I've seen it fail to appear even after 10 minutes, depending on the load.

Expected results:

I expect updated server files to be visible "soon" on the client.

Additional info:

*File* cache invalidation works.  If I do 
$ echo foo >> ~/t/tmp

on the server, adding the string to the *existing* file, the client sees it
promptly.  But renaming the existing inode and creating a new one is not seen. 
I've also seen negative dentries fail to invalidate in the same way: "ls -l
$file" on a non-existant file on the client, then create the file, then "ls -l"
several minutes later and still see ENOENT. 

Client NFS mount options are all defaults:

sct.boston.redhat.com:/home /home               nfs     defaults        0 0

in fstab.  Server is x86_64 RHEL-4WS with all updates, so is unlikely to be the
problem.  Exports options are rw,async,no_root_squash (it's not a root user
accessing the export, though, in this case, so root_squash options are not being
exercised.)