Re: Performance problems with NFS under 2.4.20

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

     > Upgrading from 2.2.20, I'm seeing vastly increased network
     > traffic, and after poking around a bit, I find that all calls
     > to open() on files on NFS-mounted partitions generates one UDP
     > packet.  Switching on NFS debugging, and then saying

     > $ cat file $ cat file

     > shows me this:

     > Jan 13 16:27:23 litos kernel: NFS: refresh_inode(b/876609548
     > ct=1 info=0x2) Jan 13 16:27:23 litos kernel: nfs: read(//file,
     > 4096@0) Jan 13 16:27:23 litos kernel: nfs: read(//file,
     > 4096@17) Jan 13 16:27:23 litos kernel: nfs: flush(b/876609548)
     > Jan 13 16:27:23 litos kernel: NFS: dentry_delete(//file, 0) Jan
     > 13 16:27:24 litos kernel: NFS: refresh_inode(b/876609548 ct=1
     > info=0x2) Jan 13 16:27:24 litos kernel: nfs: read(//file,
     > 4096@0) Jan 13 16:27:24 litos kernel: nfs: read(//file,
     > 4096@17) Jan 13 16:27:24 litos kernel: nfs: flush(b/876609548)
     > Jan 13 16:27:24 litos kernel: NFS: dentry_delete(//file, 0)

     > The partition is mounted with just

     > $ mount server:/db /db

     > Adding a "-o actimeo=100" makes no difference.

     > Is this supposed 1) to be this way, or 2) a bug, or 3) a
     > misconfiguration on my part?

That is quite deliberate.

open() is supposed to generate an RPC call in order to ensure that
cached attributes (and hence cached data) are still valid (this is
part of what is known as NFS 'close-to-open' cache consistency).

If you are certain that you will never access the same file/directory
from 2 different machines, you can try to mount with the 'nocto' mount
option.

Cheers,
  Trond