From: Brent (brent@eng.sun.com)
Date: 10/02/99-02:15:11 PM Z
Message-ID: <37F659BF.D4FE173@eng.sun.com> Date: Sat, 02 Oct 1999 12:15:11 -0700 From: Brent <brent@eng.sun.com> Subject: Re: COMPOUND and the nfs reply cache "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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:40 AM Z CST