Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS not idempotent (was re: mountd Performance under Stress)
Message-ID: <2474@auspex.auspex.com>
Date: 20 Sep 89 17:18:43 GMT
References: <14068@bloom-beacon.MIT.EDU> <1211@sequent.cs.qmc.ac.uk> <45595@bbn.COM> <45735@bbn.COM>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 21


 >I don't mean to drag Sun through the mud, just point out that most of
 >the world is using NFS v.2, and so here are these problems, some of
 >which could have been caught in the original design and testing
 >phases.
 >
 >Several things that NFS should (or could) do (NFS v.3 does at least
 >some of these):

I presume by "V.2" and "V.3" you're referring to versions of the
protocol, not the implementation; some of the items you list are
implementation issues, not protocol issues - e.g., the

 >The client should try to predict the servers mean delay time, a la
 >Jacobson and Karels TCP timeout predictor.  I believe NFS 3 does
 >something like this.

item is an implementation issue, and I think Sun's working on a client
implementation for protocol version 2 that does that.  You may be able
to make changes to the protocol that make it work better, but that
doesn't mean it's impossible in version 2.