Path: utzoo!attcan!uunet!wuarchive!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent
From: brent@terra.Eng.Sun.COM (Brent Callaghan)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS
Keywords: NeFS, NFS, caching, coherence
Message-ID: <138331@sun.Eng.Sun.COM>
Date: 3 Jul 90 21:58:48 GMT
References: <1075@cluster.cs.su.oz> <138222@sun.Eng.Sun.COM> <1990Jul3.172516.16691@Neon.Stanford.EDU>
Sender: news@sun.Eng.Sun.COM
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.

It's true, the current spec makes no mention of explicit support for
client cache consistency.  This is just a first draft of the protocol
spec - a request for comments.  There's definitely room for a client
cache consistency model in NeFS - perhaps more than one.  It's just
not clear at this stage what's appropriate.  A cache consistency 
model that assumes a stateful server is OK provided the state is
easy to recover and doesn't become a burden as the number of clients
scales.

> 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 original discussion was over a DFS protocol that allowed "batching"
of filesystem requests.  My contention was that MCL is OK but don't
expect to see a noticeable improvement in performance if you are
using a DNLC.  The lack of complete cache consistency of a DNLC over
an NFS filesystem is not something I take issue with.

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

Again, you missed the point of the discussion: no matter what kind
of caching you employ, the first time you "ls -F" in a filesystem
you'll have to wait while the underlying DFS handles all the
separate over-the-wire attribute requests. Caching isn't going
to make your folder full of icons open any faster.

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

Spritely NFS *does* require additional server state - for each active
file is has to keep a record of which clients have it open and what
they're doing with it.

I agree that coherent caching is not only desirable but that it can
also significantly improve performance.  If it means sacrificing
server statelessness then so be it - just make sure that the state
is scalable and easy to recover.

--

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 uucp: sun!bcallaghan
			 phone: (415) 336 1051