Subject: Re: COMPOUND and the nfs reply cache

From: Brent <[email-masked]>
Date: Sat, 02 Oct 1999 12:15:11 -0700

"Noveck, Dave" wrote:
> 
> Working on COMPOUND for the bake-off, I've run into some interesting issues
> that I wanted to bring to everybody's attention.  I'm not sure that they affect
> the spec too much if at all, but I wanted to warn anybody who is tempted to
> use COMPOUND too creatively.  The server, at least my server, might not
> be able to cope and return NFS4ERR_RESOURCE.

Right.  The client's willingness to generate arcane compound requests
must be checked by the client's responsibility to recover from
retransmissions or incompletely executed requests. Client beware.

> In the good old days, requests such as READ (and also READLINK and
> READDIR) did not cache their results to be returned in the case of
> retransmitted requests, although they might be dealt with in the reply
> cache to avoid executing a retransmitted request while the original is
> in the process of being retransmitted.  One doesn't need to cache the
> results because no fs state changes (everybody, by common consent,
> ignoring atime issues) so that if a retransmission gets different data
> from the orignal request, the new data is just as right as the original.
> Caching the result for these procs would be extremently onerous
> because a very large amount of data would have to be saved so
> people don't do it.

Right, caching of idempotent requests has no effect on correctness.

> Now, back to the future.  With COMPOUND, you can have a READ
> op, combined with ops that change fs state.  There are two cases
> to consider.  The state-modiying op may be either before or
> after the READ.  If it is before, you have a chance.  You can avoid
> saving the results.  You do have to save the results of the state-modifying
> op, and the current file handle for the READ.  This does add some
> complexity since you now have to deal with retransmission in
> which you partially replay and partially re-execute the request.  In the
> bake-off time frame, if you do a READ, READLINK or READDIR that
> follows a state-modifying op, I'm going to return NFS4ERR_RESOURCE.

That's a mistake.  Your server should not be making judgment on 
whether a request is sufficiently idempotent.  Your duplicate
request cache should be transparent to the client.  If you
get a request that's burdensome for your server to cache, then
don't cache it.  But don't return an error to the client for
what is otherwise a perfectly valid request.

> Maybe the spec should somehow stigmatize this particular use
> of compound as seriously anti-social behavior for which
> NFS4ERR_RESOURCE is an appropriate sanction.

Yes, the spec should certainly include some text that guides
implementors on the construction of compound requests, i.e.
do's and don'ts.  However, I'm very much against the server
returning errors for valid compound requests that it doesn't
like.  I still subscribe to the "smart client, dumb server"
model.

	Brent

---

From: "Dan Trufasiu" <[email-masked]>
Date: Mon, 4 Oct 1999 12:36:21 -0400

> like.  I still subscribe to the "smart client, dumb server"

I agree with Brent. I don't know any NFS V3 server that have a problem with
retransmission. The NFS Version 4 remove some burdensome from the server,
but this doesn't means that every time that the server have a problem we
have to let the client to deal with it.

Dan