Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!voder!pyramid!ctnews!unix386!markb
From: markb@unix386.Convergent.COM (Mark Beyer)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS not idempotent (was re: mountd Performance under Stress)
Summary: USENIX paper
Message-ID: <534@unix386.Convergent.COM>
Date: 14 Sep 89 23:06:30 GMT
References: <14068@bloom-beacon.MIT.EDU> <1211@sequent.cs.qmc.ac.uk> <45595@bbn.COM>
Organization: Unisys/Convergent
Lines: 33

I've just started reading this thread, so my apologies if this has
already been discussed:

In article <45595@bbn.COM>, news@bbn.COM (News system owner ID) writes:
> liam@cs.qmc.ac.uk (William Roberts) writes:
> < jtkohl@athena.mit.edu (John T Kohl) writes:
> < > liam@cs.qmc.ac.uk (William Roberts) writes:

[stuff about problems with NFS operations not being idempotent]

There's a paper in the 1989 Winter USENIX conference proceedings
by Chet Juszczak at DEC that describes a modification to the
NFS server that may be germane.

As I understand, the problem is that a sequence of non-idempotent
client requests like "create, write, create" may get jumbled at the
server because of server load and the stateless nature of the NFS
protocol.

This paper describes an extension of the server cache mechanism.
The cache is expanded to track all request types and the NFS layer
makes greater use of the cache as well.

Actually, the major reason for doing this was to improve
performance by sorting out duplicate requests, but it looks like
they thought it would solve these jumbled request problems.

Anyone from MIT or DEC care to comment on this ?  How well has it worked ?
Has anyone else implemented this idea in their NFS server ?

Many thanks,
Mark Beyer
{pyramid,pacbell,decwrl,sri-unix}!ctnews!markb