Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!jaytee!bodleian!geoff From: geoff@bodleian.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) Newsgroups: comp.protocols.nfs Subject: Re: NFS writes and fsync(). Message-ID: <3012@jaytee.East.Sun.COM> Date: 22 Oct 90 13:18:03 GMT References: <1990Oct9.152612@objy.objy.com> <1990Oct14.082712.10811@objy.com> <1990Oct19.222754.17622@dg-rtp.dg.com> Sender: news@East.Sun.COM Reply-To: geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top) Organization: Sun Microsystems PC-NFS Engineering Lines: 44 Quoth thurlow@convex.com (Robert Thurlow) (in ): #>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. # #Remember how hard a diskless node hits it's NFS-mounted swap device - #I've read numbers akin to five writes to every read from /export/swap. #If I'm the sort of user who doesn't run long-lived batch jobs from my #workstation, I might enjoy the performance edge I gain with async I/O #without minding the cost of rebooting most or all the time when my #boot server crashes. Simple-minded question: if you want to introduce this best-effort behaviour, why not do so on the client? I know it makes the imple- mentation simpler to shove the responsibility to the server, but it's really a client issue: only the client knows whether or not data is "precious" (to borrow an earlier attribute). It's pretty convoluted to force the server to create and export a filesystem with your whizzy "don't sync" attribute to solve this. The other reason not to fix this "problem" on the server is that it's so damned unilateral! Suppose some zealous system administrator decides to earn himself a bonus by "improving" the network performance by enabling your attribute on all file systems. Most users may say "sure, it's probably a good tradeoff, so go for it." The upshot is that it becomes impossible to reliably fsync a file, even when you want to! If you argue that this simply points up the need for a protocol revision, I won't disagree on the desirability of revising and fixing the protocol, but I would point out that this particular problem arises from solving the asynchrony issue on the server rather than the client, and is therefore pretty bogus... Bottom line: given the choice between changing the protocol and its well-known semantics or changing an implementation of that protocol, I'd rather change the implementation. The _right_ implementation, of course! -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- *** "Now is no time to speculate or hypothecate, but rather a time *** *** for action, or at least not a time to rule it out, though not *** *** necessarily a time to rule it in, either." - George Bush ***