:> 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
These are buffer-cache entities we are talking about here, so they won't
go away until NFS tells the system they can go away. In that respect
async I/O is no different then sync I/O. async I/O is simply run
synchronously from an nfsiod context.
-Matt
Matthew Dillon
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
