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) | [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
