Path: utzoo!attcan!uunet!crdgw1!uakari.primate.wisc.edu!uflorida!gatech!mcnc!rti!dg-rtp!mavplus9!stukenborg From: stukenborg@mavplus9.rtp.dg.com (Stephen Stukenborg) Newsgroups: comp.protocols.nfs Subject: Re: NFS writes and fsync(). Message-ID: <1990Oct19.222754.17622@dg-rtp.dg.com> Date: 19 Oct 90 22:27:54 GMT References: <1990Oct9.152612@objy.objy.com> <1990Oct14.082712.10811@objy.com> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Organization: Data General Corporation, RTP, NC. Lines: 47 (Sorry this is slightly dated, but our news feed has been wacked out all week.) After reading the postings back and forth on the issue, I still haven't seen anyone really hit the nail on the head on why nfs write operations are synchronous. The primary reason is to make the client tolerant of server crashes. If I'm an NFS client, I don't want the fact that the server has crashed to impact my "view" of the world. My system is still up and running. Why should I lose any data? As has already been described by Rob Thurlow, if I mark my client buffer cache block as "clean" when the server acks my write, then I'm counting on that data being on stable storage. If the server is merely going to ack the receipt of my write request, then I have to hold on to that buffer until close (or the janitor daemon) verifies that everything is on the server's disk. As Jeff Mogul pointed out, the primary difference between traditional unix file system behavior and NFS is that the NFS close operation writes all of a files dirty buffers to disk. It is this "sync-on-close" behavior that really dictates the synchronous write policy. (Any also provides a wimpy consistancy-control policy.) The performance win is if the writes (before the close) are asynchronous; then the disk arm on the server is not "forced" to seek all over the place. This is essentially the Rev. 3 protocol spec WRITECACHE call that Guy Harris talked about. It would probably be worth the added complexity to the client side code for the improved server performance. Another thought. I'm having trouble with the several people who have mentioned that NFS data integrity is not a big factor to some users. Do users really want a MIPS-like export option that says "don't do sync writes"? (Note that these async writes are different that those mentioned above. Now I'm talking about the possibility that data will be lost on a server crash.) The only reason I can think of having this feature is for truly wondrous benchmark results that you can wave in a customer's face. If I've just edited my code module or circuit layout, then I want to be sure that a server crash is not going to lose any of my thoughts. (Maybe the users who want this feature are the same ones that use "soft" mounts on filesystems mounted r/w.) Steve Stukenborg DG/UX Kernel Development Data General Corporation 62 Alexander Drive stukenborg@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!stukenborg Steve Stukenborg Data General Corporation 62 Alexander Drive stukenborg@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!stukenborg