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!
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.
[ 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?
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?
-patrick.
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Friday April 5, [email protected] 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 - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Well, the "correctness" is subject to whether a
previous reply was actually found in the cache or not.
That will not only depend on the quality of the
network, but also on the number of entries in the
cache. The comment in the begining of the file
nfscache.c ("Size of reply cache ...") itself seems to
convey that guesswork was at it's best.
--- Neil Brown <[email protected]> wrote:
> On Friday April 5, [email protected] 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 - [email protected]
> > https://lists.sourceforge.net/lists/listinfo/nfs
>
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs