Messages in this thread | | | Subject | Re: NFS client performance 1.5 orders of magnitude too slow? | From | Trond Myklebust <> | Date | 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/
| |