Date: Fri, 20 Aug 1999 22:52:31 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: fullermd@futuresouth.com, steve@cioe.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Async NFS exports? Message-ID: <199908202252.PAA17363@usr09.primenet.com> In-Reply-To: <199908202032.NAA64957@apollo.backplane.com> from "Matthew Dillon" at Aug 20, 99 01:32:17 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908202252.PAA17363>