From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 06/14/01-11:31:03 AM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335458@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: Server request processing: one pass or two Date: Thu, 14 Jun 2001 09:31:03 -0700 Given the division of a V4 request into multiple ops, an implementation has two choices: it can XDR the whole thing and then make a second pass to actually execute the ops or it can make a single pass xdr-ing each op as it is ready to execute. Normally, this implementation issue wouldn't affect the spec. However there are protocol consequences for the client that result from the server's choice. In particular, how does the server report an XDR error detected after it has executed one or more ops (which may have non-idempotently modified file system state)? Right now the spec seems to assume a two-pass model, but most existing servers (maybe all) actually use the one-pass approach. I propose the spec briefly discuss this issue and provide an error (e.g. NFS4ERR_BADXDR) to allow a server to indicate the occurrence of an XDR formatting error within a given op after executing, successfully, the previous ops. A server which used the two-pass model would be free to report XDR errors in the normal/standard/old-fashioned/ outmoded (choose your own loaded adjective) way, as long as it had not caused any state change before detecting the error. The one remaining issue concerns the handling of a bad or missing opcode. For this I propose we adopt Mike Eisler's suggestion (from a while back) that we reserve an otherwise invalid opcode (e.g. OP_WRITE+1) which would be used in the response together with NFS4ERR_BADXDR in the portion of the response corresponding to the invalid op.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:49 AM Z CST