> 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.
If you are looking for more optimizations, you can delay NFS write
operations for some interval X, on all write buffers, entirely.
Sun does this (it is technically called "write gathering" in the
literature).
The upshot of introducing this latency between request and action
is that multiple writes to adjacent regions on non-buffer boundaries
are "batched up" for processing by the NFS server.
The net result is that you can do more writes, while generating
less wire traffic.
Be forewarned, however, that you must include synchronization
primitives at the appropriate places. Among these are:
1) When a write lock is acquired, a write is issued in a
region spanned by the lock, and the lock released, the
lock release must also be delayed.
The reason for this is that the lock is being used to
ensure distributed cache coherency (actually, in effect,
a lease-stall for other clients wanting to do writes).
2) When a conflicting lock is requested, you need to initate
a synchronization point.
This is because even though they are proxied from the
same system ID, the NFS locks are on different process
ID's, and some NFS servers will enforce based on this,
even though the locks are, putatively, advisory, not
mandatory.
3) On file deletions.
Generally, this just boils down to not being able to
delete an NFS file in actuality, unless you are the
last closer on the file. Implementation-wise, it means
that a delete operation is a request-to-sync operation.
4) Etc..
While these aren't technically necessary right now (in FreeBSD,
since FreeBSD fails to implement NFS locking), omitting them now
will make it nearly impossible to repair later, should NFS locking
support arise from my (or someone else's) kernel patches being applied,
and someone hacking up the lock and stat daemons to make the proper
system calls.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
