Re: Performance problems with NFS under 2.4.20

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Mon Jan 13 2003 - 10:57:28 EST


>>>>> " " == 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:45 EST