Nfs – How to improve NFS performance on a gigabit LAN

Maybe it's not slower transfer speed, but increased write latency. Try mounting the NFS share async instead of sync and see if that closes the speed gap. When you rsync over ssh, the remote rsync process writes asynchronously (quickly). But when writing to the synchronously mounted nfs share, the writes aren't confirmed immediately: the NFS server waits until they've hit disk (or more likely the controller cache) before sending confirmation to the NFS client that the write was successful.

If 'async' fixes your problem, be aware that if something happens to the NFS server mid-write you very well might end up with inconsistent data on disk. As long as this NFS mount isn't the primary storage for this (or any other) data, you'll probably be fine. Of course you'd be in the same boat if you pulled the plug on the nfs server during/after rsync-over-ssh ran (e.g. rsync returns having 'finished', nfs server crashes, uncommitted data in the write cache is now lost leaving inconsistent data on disk).

Although not an issue with your test (rsyncing new data), do be aware that rsync over ssh can make significant CPU and IO demands on remote server before a single byte is transfered while it calculating checksums and generating the list of files that need to be updated.

Adam, in my opinion you ARE in the right ballpark.

Blocksize is hugely important as the sourceforge article implies.

It's unlikely that you can hit your network wire speed 110-120MB/s (1 Gb, that's bits not bytes).

For the audience, here's the article which is great: http://nfs.sourceforge.net/nfs-howto/ar01s05.html

There is of course some overhead of transferring the block, getting the response. We tested on 10 Gb Ethernet, it wasn't faster. But in theory we could run more NFS in parallel with that fatter pipe.