From: Neil Brown <neilb@cse.unsw.edu.au>
Subject: Re: purpose of knfsd reply cache
Date: Sat, 6 Apr 2002 07:31:20 +1000 (EST)
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <15534.6056.626290.31180@notabene.cse.unsw.edu.au>
References: <200204051345.19407@tulip.eng.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: nfs@lists.sourceforge.net
To: jpmg@eng.cam.ac.uk
In-Reply-To: message from jpmg@eng.cam.ac.uk on Friday April 5
Errors-To: nfs-admin@lists.sourceforge.net

On Friday April 5, jpmg@eng.cam.ac.uk wrote:
> I'm trying to pin down a data corruption corruption bug in knfsd .  As
> a side effect, I've been looking at the reply cache, and getting puzzled.
> 
> Any answers to any of the following very much appreciated!

The purpose of the reply cache is for correctness, not performance.

If a client sends a MKDIR request where the presented name doesn't yet
exist, the server will create the directory and return "success".
If the reply gets lost, the client resends, and the server re-executes
the request, it will find that the directory already exists and so
will return "EEXIST".
So the client will see EEXIST where it should see "success".
The reply cache is for catching caches such as this.  The resend from
the client will cause a match in the reply cache, so the server
will not re-execute the MKDIR but will just send the original
"success" response.

So your assessment of what the reply cache does is exactly correct.
However you expectation of what it is for is wrong.


> 
> a) am I correct in thinking that the comment in both nfs3proc.c and
>    nfsproc.c 
>    * Only the results of non-idempotent operations are cached.
>    should actually read
>    * Only the results of idempotent operations are cached.
> 

No

>    [ ie, only operations that are idempotent (acts as if used only once
>    even if used many times) can safely be "faked" on subsequent calls
>    by using the cached reply data ]
> 
> b) given the set of operations for which reply caching is allowed, is
>    it not the case that the only likely cause of a reply cache hit is
>    when a client sends a request, the server handles the request, the
>    reply is lost, so the client repeats the request?

Yes.

> 
> c) on my server, "nfsstat -o rc" suggests that around 0.0005% of replies
>    that could have been cached were hits.  Is my server unusual?  Does
>    nfsstat correctly report this statistic?  If the answers to those
>    are "no" and "yes", then is the reply cache worth bothering with?  

No. Yes. Yes.
A low hit rate is good.  It means your network is not being
overloaded.

NeilBrown

> 
> -patrick.
> 
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs