Path: utzoo!attcan!uunet!decwrl!shelby!neon!gray
From: gray@Neon.Stanford.EDU (Cary G. Gray)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS
Keywords: NeFS, NFS, caching, coherence
Message-ID: <1990Jul3.172516.16691@Neon.Stanford.EDU>
Date: 3 Jul 90 17:25:16 GMT
References: <1075@cluster.cs.su.oz> <138222@sun.Eng.Sun.COM>
Organization: Computer Science Department, Stanford University
Lines: 29

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.

First, in deprecating multiple-component name lookup, he notes that
the client "directory name lookup cache" is most Unix implementations
eliminates most over-the-wire name lookups.  Fine.  But it isn't
coherent, so it's going to surprise me someday when I try to use two
hosts.

The second example is the 'ls -F'.  Here the attributes need to be
cached as well.  The same applies to the example of needing attributes
to support an interface with icons.

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.  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.

	Cary Gray
	gray@cs.stanford.edu