Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!mogul
From: mogul@wrl.dec.com (Jeffrey Mogul)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS
Keywords: NeFS, NFS, caching, coherence
Message-ID: <1990Jul6.211654.11617@wrl.dec.com>
Date: 6 Jul 90 21:16:54 GMT
References: <138222@sun.Eng.Sun.COM> <1990Jul3.172516.16691@Neon.Stanford.EDU> <1990Jul4.174509.10106@dg-rtp.dg.com>
Sender: news@wrl.dec.com (News)
Organization: DEC Western Research
Lines: 50

In article <1990Jul4.174509.10106@dg-rtp.dg.com> stukenborg@egghead.dg.com () writes:
>I don't know if I would call the performance improvement "significant".

In spite of the various qualifications pointed out in your message,
I still think the results are "significant" in the sense that
as hardware speeds scale differentially (disk seek times not improving
as fast as anything else, and network latencies somewhat constrained
by the speed of light) the places where an NFS-like protocol wastes
time are going to end up as serious bottlenecks.  But you're right
that people replacing NFS with SNFS today aren't going to end up
getting their daily work done by noon as a result.

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

More precisely, Sprite (or SNFS) allows an application to decide if it
wants NFS-like "robustness" (i.e., data forced to disk on close) or
UFS-like performance (with 30 seconds of vulnerability).  NFS doesn't
give you the choice.

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

In Sprite, crash recovery is most certainly implemented.  It was
already done at the time the SNFS paper was written; see the reference
to Brent Welch's thesis (which might have been published by now).
I've even seen the source code.

I've had several "discussions" with John Ousterhout over the relative
virtues of lease-based recovery for Sprite-like systems.  I think
we decided that Sprite-recovery was better for Sprite (because it
had some additional useful features) but that a lease-based system
would be much easier to retrofit into an NFS-based system such as
SNFS.  I've been trying to convince someone to reimplement SNFS using
a more modern NFS port, and to add lease-based recovery, but so
far nobody has had the ambition.

-Jeff