Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!swrinde!ucsd!ames!ncar!mephisto!mcnc!rti!dg-rtp!egghead!stukenborg From: stukenborg@egghead.rtp.dg.com (Stephen Stukenborg) Newsgroups: comp.protocols.nfs Subject: Re: NeFS Keywords: NeFS, NFS, caching, coherence Message-ID: <1990Jul4.174509.10106@dg-rtp.dg.com> Date: 4 Jul 90 17:45:09 GMT References: <1075@cluster.cs.su.oz> <138222@sun.Eng.Sun.COM> <1990Jul3.172516.16691@Neon.Stanford.EDU> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: stukenborg@egghead.dg.com () Organization: Data General Corporation, Research Triangle Park, NC Lines: 61 In article <1990Jul3.172516.16691@Neon.Stanford.EDU> gray@Neon.Stanford.EDU (Cary G. Gray) writes: >Brent Callaghan's latest message points out clearly what I judge >to be a serious flaw in the NeFS spec: the absence of support for >coherent (aka consistent) caching. He gives two examples for which >caching on clients is an excellent fit--and for which, therefore, NFS >and NeFS are poorly suited. >... >Caching is not a panacea, but neither is coherent caching impossible--or >even impractical. Interested folks should look at two papers in the >proceedings of last December's SOSP (published as Operating Systems >Review 23(5)). First, Srinivasan and Mogul ("Spritely NFS") add support >for coherence of file contents to NFS, reaping a significant improvement >in performance. I don't know if I would call the performance improvement "significant". Yes, the Andrew benchmarks ran 15-20% faster using Spritely NFS (SNFS) vs. vanilla NFS. But they call out in the paper that they used 4K block sizes rather than 8K blocks, which was to SNFS's advantage (NFS was forced to do more write calls). More importently, they also noted that their NFS implementation had a bug where the client data cache is invalidated when a file is closed, preventing the client from using its cached copy (NFS is forced to do more read calls). Also, SNFS uses a delayed-write policy (they sync their buffers after aging them 30 seconds), where NFS syncs a file's buffers on close. This is to SNFS's advantage, in that SNFS is not "paying" for the writes as part of the benchmark timing, where NFS has to pay. The tradeoff is robustness. The SNFS policy may be great for temporary file generation (which the Andrew benchmarks do a lot of), but it is certainly less robust than the NFS policy. Would users be satisified with this tradeoff? Probably. (They already accept it in the local file system case.) SNFS also is likely to lose some performance when (and if) they implement crash recovery. I'm not saying that cache consistancy is bad, just that you have to take the SNFS numbers with a grain of salt. I believe that it's a win to show that you can have cache consistancy and still have performance comparible to NFS. I also believe that the "next" NFS has to have cache consistancy. People aren't going to put up with this "stateless" junk forever. >Their approach does require additional server state; for >a way to make that state "soft"--i.e., to allow recovery when it is lost-- >see the paper by Gray and Cheriton on "Leases". The ideal would combine >the two ideas and add coherent caching of naming and attribute information. >It's not trivial to do so, but it is largely straightforward. It's an interesting paper. I guess the only drawback is that they haven't applied it to a "real" system to verify their analysis. The real drawback to Sprite and Spritely NFS is that crash recovery is not (currently) implemented. The Sprite paper even says that clients who are using files from a crashed server have to be killed. Somehow I think that customers would be more than a little miffed over that sort of "crash recovery" scheme. The "leases" paper looks like a good compromise between statelessness and cache consistancy. Steve Stukenborg Data General Corporation 62 Alexander Drive stukenborg@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!stukenborg