Bug 174010 - NFS client cache invalidate fails to occur when server's directory is updated.
Summary: NFS client cache invalidate fails to occur when server's directory is updated.
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-23 16:49 UTC by Stephen Tweedie
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2005-12-01 06:47:35 UTC

Attachments (Terms of Use)
Here is the upstream patch is causing this regression... (2.76 KB, patch)
2005-11-30 02:01 UTC, Steve Dickson
no flags Details | Diff
Proposed Upstream patch (646 bytes, patch)
2005-12-01 12:50 UTC, Steve Dickson
no flags Details | Diff

Description Stephen Tweedie 2005-11-23 16:49:13 UTC
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):


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

Comment 1 Steve Dickson 2005-11-30 02:01:06 UTC
Created attachment 121622 [details]
Here is the upstream patch is causing this regression...

Comment 3 Dave Jones 2005-11-30 05:23:17 UTC
will be fixed in the 1722 kernel, by backing out that patch.
Steve, can you let the NFS people upstream know about this ?

Comment 4 Steve Dickson 2005-12-01 12:50:19 UTC
Created attachment 121680 [details]
Proposed Upstream patch

I have and they were not in favor of reverting the patch, so I came up
with this proposed patch that seem to be acceptable (although I have
not seen it go in on any of the commit lists).

Comment 5 Dave Jones 2005-12-02 06:21:19 UTC
thanks. I switched the patch to this one in the 2.6.14-1.1734_FC5

Note You need to log in before you can comment on or make changes to this bug.