This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 174010 - NFS client cache invalidate fails to occur when server's directory is updated.
NFS client cache invalidate fails to occur when server's directory is updated.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-23 11:49 EST by Stephen Tweedie
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-01 01:47:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Stephen Tweedie 2005-11-23 11:49:13 EST
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.)
Comment 1 Steve Dickson 2005-11-29 21:01:06 EST
Created attachment 121622 [details]
Here is the upstream patch is causing this regression...
Comment 3 Dave Jones 2005-11-30 00:23:17 EST
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 07:50:19 EST
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 01:21:19 EST
thanks. I switched the patch to this one in the 2.6.14-1.1734_FC5
 kernel.

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