After upgrading to FC18 I started seeing a persistent problem where clients don't see a file change on the NFS server. Both the server and clients are high performance systems - Sueprmicro dual CPU servers with 64GB of memory. Server has the following in the /etc/exports: /a/eng *(rw,sync) Clients mount with the following options (I tried many other options too): hard,intr,noac,noatime,lookupcache=none Here is a small test that I use: $ cat check.c #include <stdio.h> #ifdef XXX int x = 1; #else int x = 0; #endif int main () { #ifdef XXX x++; #endif printf ("%d\n", x); } And shell script to reproduce the problem: ======================== $ cat run_check.sh #!/bin/bash cc=`pwd` gcc -o check check.c ssh thor1 "cd ${cc}; ./check" rm check gcc -DXXX -o check check.c ssh thor1 "cd ${cc}; ./check" rm check gcc -o check check.c ssh thor1 "cd ${cc}; ./check" rm check ======================== The above shell scripts creates the same program name (but size of the file changes) and executes it on the client machine (thor1). Expected result from the run is: 0 2 0 When I start from the beginning I get: 0 2 2 and the next run would give me: 2 2 2 I was able to make this test work in two ways: (1) Add "ls >/dev/null" before executing the program. (2) Mount the client with "nfsvers=3" I tried to enable NFS debugging but that created to much of the data. Any idea? Is it possible that there is some interaction with file system cache and NFS on the server side?
If you "echo 0 >/proc/sys/fs/leases-enable" on the server, before starting the nfs server, does that help?
I verified that this change works for my system. I verified that leases-enable is set to 1, set it to 0, and restarted nfs-server. The clients have the following options - hard,intr,noac,noatime,sync,lookupcache=none (even though none of the clients are writing anything to the disk). After reading this article https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/5.6_Technical_Notes/Known_Issues-kernel.html (specially the sentence "restore correctness at the expense of some performance") I wonder why was performance chosen as a default, instead of correctness. Before the update to FC18 our server was FC15.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is now fixed upstream in 3.13--I'm not sure when that change will make it in to Fedora.