13

Here's my set up: One NFS Server machine (v4), several NFS client machines.

When a client machine write files to the NFS mount, the other clients see the new content instantly : no problem.

But, when the server machine modify the content of the file, this new content is not shown on the client until I do a ls of the directory from the client.

I'm absolutely stumped on this inconsistency...any help would be greatly appreciated!

Infos :

  • nfs 1.2.3-r1 on both client and server
  • acregmin, acregmax, acdirmin, acdirmax, lookupcache : default values
2
  • 1
    Can you do a little experiment for more info?: Do an ls -i on the client before editing the file on the server, then again after. See if the numbers change. If they do its because the server is replacing the file and the client doesnt notice this until it rescans the directory. If so try setting the mount option lookupcache=none and see if the behavior changes.
    – phemmer
    Apr 19, 2012 at 1:39
  • 2
    sorry for the delay. The inode effectively changes. I've added the lookupcache option, it seems to work. I will check again tomorrow.
    – numberxiii
    Apr 24, 2012 at 16:39

3 Answers 3

13

Adding as an answer based on your comment.
The solution is to add lookupcache=none to your nfs mount options.

What happens is that the first time your client reads the file it does a NFS lookup to get the NFS fileid. It then caches the NFS fileid, and when you go back to open the file, it uses the cache. Normally this isnt a problem as when the file is updated its fileid stays the same. But for some reason the old file is being removed, and a new one is created (or renamed, or something to where its not the same file).
Now normally this isnt a problem either as when your client tries to open a fileid which isnt there, it will get an error from the server and do another lookup to get the new fileid. But for some reason the NFS server is letting the client open that old fileid. Perhaps another client has the file open and so its not being deleted yet, I dont know.

In any case the way to solve it is to tell the client to always do an nfslookup before opening a file by using the nfs mount option lookupcache=none. The downside to this is that it can be expensive if you are frequently opening files since it adds more traffic to the NFS server.

1
  • Thanks for your explication. On the NFS server, the stack of the exported directory is DRBD/LVM/ext4. May be it's causing the "bug". I have the problem on several client, but not on some others... I will redo all my tests and tell you if all is going well with this option.
    – numberxiii
    Apr 24, 2012 at 21:37
1

You can also manually refresh the NFS cache with

sudo mount /nfs-mount -o remount

...in case you do not want to add any mount options degrading performance.

0

Change the mount option to hard,intr. i think the default may be soft in your system. this will help.

4
  • unfortunately, adding these mount options didn't change anything :(
    – numberxiii
    Apr 18, 2012 at 8:17
  • For my first test, I do a remount. Then I've done a test from another client, with a clean mount. The problem seems to be corrected : we wait 30s to see the new content
    – numberxiii
    Apr 18, 2012 at 9:12
  • I've build a new client (vm) to check : no problem with the content !
    – numberxiii
    Apr 18, 2012 at 15:44
  • 2
    @johnshen64 why do you think hard would solve the issue? Hard/soft only matter when it comes to connection interruption, has nothing to do with caching.
    – phemmer
    Apr 19, 2012 at 12:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.