[PATCH] kNFSd: Giant patch importing NFSv4 server functionality
Now that all the hooks are in place, this large patch imports all of the new code for the NFSv4 server. This patch makes almost no changes to the existing nfsd codebase (these have been taken care of by the preceding patches). One aspect of the NFSv4 code deserves comment. The most natural scheme for processing a COMPOUND request would seem to be: 1a. XDR decode phase, decode args of all operations 2a. processing phase, process all operations 3a. XDR encode phase, encode results of all operations However, we use a scheme which works as follows: 1b. XDR decode phase, decode args of all operations 2b. For each operation, process the operation encode the result To see what is wrong with the first scheme, consider a COMPOUND of the form READ REMOVE. Since the last bit of processing for the READ request occurs in XDR encode, we might discover in step 3a that the READ request should return an error. Therefore, the REMOVE request should not be processed at all. This is a fatal problem, since the REMOVE was already been done in step 2a! Another type of problem would occur in a COMPOUND of the form READ WRITE. Assume that both operations succeed. Under scheme (a), the WRITE is actually performed _before_ the READ (since the "real" READ is really done during XDR encode). This is certainly incorrect if the READ and WRITE ranges overlap. These examples might seem a little artificial, but nevertheless it does seem that in order to process a COMPOUND correctly in all cases, we need to use scheme (b) instead of scheme (a). (To construct less artificial examples, just substitute GETATTR for READ in the examples above. This works because the "real" GETATTR is done during XDR encode: one would really have to bend over backwards in order to arrange things otherwise.)
Showing
fs/nfsd/nfs4proc.c
0 → 100644
fs/nfsd/nfs4xdr.c
0 → 100644
Please register or sign in to comment