On Fri, 20 Aug 1999, Matthew Dillon wrote: > :> Just to be clear... I am wondering if mounting (on the NFS _server_) a > :> partition (that is exportable) as async will have any performance > :> benefits to the NFS clients? > : > :As a first guess, probably not unless you have a large number of active > :clients. Any modern hard disc will outperform ethernet/fast ethernet, > :especially for larger read/writes. For large numbers of smaller > :operations, or when there is a large number of simultaneous outstanding > :requests from clients, maybe. I'd say watch the disc itself (iostat is > :your friend), and if it's pegged (especially large numbers of tps) async > :might buy you some increase. > :-- > :Matthew Fuller (MF4839) | fulle...@over-yonder.net > > Not much if at all, whether you have a large number of clients or not, > at least if you are using NFSv3 mounts. > > The reason is due to the way NFSv3 issues writes. NFSv3 issues a > write but no longer assumes that the write has been synced to the > server's disk as of when the reply comes back. Instead it keeps the > buffer around and does a later commit rpc to do the sync, presumably > long after the server has already synced the data. > > So, effectively, all NFSv3 writes are async insofar as the client's > buffer cache is able to keep abrest of the write-rate. > > Hmm, interesting. I see another optimization I can do to fix the > buffer cache saturation case in CURRENT on the client. The COMMIT rpc's > aren't being issued async.
You need to track the return value of the commit so that you can detect server reboots and sync-write the data again. If you change to async, make sure that you still keep this part - its essential to the protocol. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
