Re: NFS client performance 1.5 orders of magnitude too slow?

Trond Myklebust (trond.myklebust@fys.uio.no)
09 Mar 1999 15:34:18 +0100


Godmar Back <gback@cs.utah.edu> writes:

> So, I guess I have two questions:
>
> + Why does Linux do the getattr following the write?

It shouldn't unless you have turned off attribute caching. If this is
not the case, please try 'echo 9 >/proc/sys/sunrpc/nfs_debug' and send
me the syslogged output.

> + Assuming the write takes so long (almost 5 ms) because the server does
> synchronous writes to disk, then the issue is that Linux doesn't aggregate
> write requests?
>
> I assume this is what the README file for nfsserver2.2beta40
> means when it says:
>
> * NFS operation between two Linux boxes can be quite
> slow. There are a number of reasons for this, only one
> of which is that unfsd runs in user space. Another
> (and much worse) problem is that the Linux NFS client
> code currently does no proper caching, read-ahead and
> write-behind of NFS data. This problem can be helped
> by increasing the RPC transfer size on the client by
> adding the `rsize=8192,wsize=8192' mount options. This
> will at least improve throughput when reading or
> writing large files. You are still in a lose-lose
> situation when applications write data line by line or
> with no output buffering at all.

Looks like nobody has updated that for a while. Linux-2.2.x has both
read and write caching. The wsize is limited in stock linux-2.2.x to
the page size (4k on ix86 machines), but there are currently
experimental patches for exceeding this value.

Cheers,
Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/