Re: Heads Up: default NFS server changing to the new one

Chris Forgeron wrote:
[stuff snipped]
> 
> I hope to do a speed test comparison between new and old NFS servers
> this weekend - At this stage, my feeling is that the new NFS server is
> at least as fast. I suspect tests will show it to be faster (at least
> the code looks faster. :-) ).
> 
Well, I doubt you'll find much difference performance wise. An NFS
server can be looked as a protocol translator, converting the NFS RPCs
into VFS/VOP calls. Performance is largely defined by how well the network
stack and/or file system perform.

When you set up a server, there are a few things that may help:
- If you are using FFS, create the file systems with the largest block
  size allowed.
- If you are using ZFS, I know diddly about it, but others have suggested
  moving the ZIL log to a dedicated device which can do fast writes, such
  as an SSD optimized for fast write performance (not all SSDs do fast writing,
  although I think choosing the size of it significantly larger that the
  size of the log, so it has a lot of free blocks may help?).
- Use lottsa nfsd threads (the default of 4 is for very minimal nfs serving
  only).

Others may have additional suggestions?

As for things the nfsd server code can do, I plan on looking at a couple
of things, but I don't think those will be in 9.0:
- Making MAXBSIZE larger. Even if it is larger than the largest block
  size supported for the underlying fs, this may help, because it can
  reduce the # of I/O RPCs.
- A small patch (I'll probably make it available to anyone who wants to
  test it once I've done so) that will allow some NFS RPCs to use shared
  vnode locks. This should allow for more parallelism of read operations
  on a file, such as read-aheads done by a client. (I recently added a
  lock flags argument to VFS_FHTOVP() for 9.0, to facilitate this.)
  --> This one might improve the VFS/VOP call side.

Thanks for letting me know how it's going, rick