NFSv4 D. Robinson Internet-Draft Sun Expires: January 14, 2006 July 13, 2005 NFSv4 ELSE operation draft-robinson-else-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract A new NFSv4 operation ELSE is proposed for a minor version to allow the VERIFY/NVERIFY operations to perform some operations after they have failed their comparisons. Robinson Expires January 14, 2006 [Page 1] Internet-Draft NFSv4 ELSE operation July 2005 1. Introduction The NFSv4 protocol introduces the powerful construct of allowing multiple operations to be compounded into a single RPC request reducing the average latency of many operations. A pair of new operations called VERIFY and NVERIFY were also introduced to allow the client to conditionally execute operations by comparing a supplied attribute to that of a file's current attribute. These operations have proven to be very useful for performing client cache management. The functionality of the verify operations is substantially the same as the common programming construct 'if-then'. The missing functionality that is proposed is to add an 'else' clause. Robinson Expires January 14, 2006 [Page 2] Internet-Draft NFSv4 ELSE operation July 2005 2. Motivation The existing VERIFY/NVERIFY have proven to be very useful in managing caches by eliminating RPC requests that only contain GETATTR operations. A specific example is a client managing a cache of file and directory names that were returned as the result of either a LOOKUP or READDIR operation. The name cache can be safely used as long as the directory containing that name has not been changed since the name was cached. In previous versions of NFS, to guarantee correctness, it was necessary to issue a GETATTR operation on the directory to retrieve its change time before using the cache. If the directory had changed, the cache was purged and a separate LOOKUP request was sent. With NFSv4, the NVERIFY operation can be used to check the directory change attribute and perform the LOOKUP. PUTFH (directory filehandle) NVERIFY (change != previous change) GETATTR (change) LOOKUP (file name) GETFH The server will first check if the change attribute is different, if true, then it will retrieve the new change attribute and LOOKUP the file name. This enables the client to not only validate its name cache but to also update its entry in a single RPC request While this is a significant optimization in the case where the directory has changed and thus invalidating the cache, it provides no gains in the case where the directory has not changed. Often the client will immediately use the result of cached lookup to issue another request negating some of the value of the cache itself. This proposal suggests adding a new ELSE operation to allow the client to issue a single RPC request that enables useful work to be perform regardless of the result of VERIFY/NVERIFY. PUTFH (directory filehandle) NVERIFY (change != previous change) GETATTR (change) LOOKUP "foobar" GETFH READ 0 32767 ELSE PUTFH ("foobar" filehandle) READ 0 32767 Robinson Expires January 14, 2006 [Page 3] Internet-Draft NFSv4 ELSE operation July 2005 In this simple example, the client is able to optimally perform a READ operation in a single RPC request while avoiding a LOOKUP by using its name cache if still valid. If the directory has changed, the client is able to not only invalidate its cache, it can re- populate it with the LOOKUP and perform the READ in a single request. Robinson Expires January 14, 2006 [Page 4] Internet-Draft NFSv4 ELSE operation July 2005 3. The ELSE Operation The ELSE operation allows a COMPOUND that would previously be terminated due to a VERIFY returning NFS4ERR_NOT_SAME, or NVERIFY returning NFS4ERR_SAME, to continue at a subsequent paired ELSE operation. All operations between the failing VERIFY and the paired ELSE are not evaluated. Conversely, if the VERIFY/NVERIFY succeeds evaluation continues and if the paired ELSE is encountered it will return the NFS4ERR_NOT_SAME/NFS4ERR_SAME ending evaluation. As part of this proposal the wording in section 13.2 of RFC 3530 [1] is changed to be more lenient in handing "non error" conditions. If an operation results in a non-zero status code, the status will be encoded and evaluation of the compound sequence will halt and the reply will be returned, except in the cases of the VERIFY and NVERIFY operations returning the "non error" conditions NFS4ERR_NOT_SAME and NFS4ERR_SAME respectively. If either of these operations is paired with an ELSE operation, evaluation will continue at the paired ELSE. 3.1 Pairing ELSE Operations Every ELSE operation MUST be "paired" with a VERIFY or NVERIFY operation, but not every VERIFY or NVERIFY may necessarily be paired with an ELSE. The pairing of ELSE operations is performed by processing a COMPOUND in order, when an ELSE operation is encountered it is paired with the nearest preceding VERIFY or NVERIFY operation that is not already paired. Pairing is is based on the syntactic order of the operations and is performed independent of if the operations will be evaluated or not. Robinson Expires January 14, 2006 [Page 5] Internet-Draft NFSv4 ELSE operation July 2005 Some examples of ELSE pairing. V V V V | | | | E V V V | | | | E V V | | | E E | | E E | | E V | | E | A B C D Figure 1 In Figure 1, examples A and C show by indentation the simple pairing of an equal number of ELSE operations with their previous VERIFY operation. Examples B and D show the pairing of unequal numbers of ELSE operations, most notable in D is how an additional VERIFY after an ELSE will cause the next ELSE to pair to the nearest VERIFY when there is more than one unpaired VERIFY. 3.2 Status Codes When a VERIFY operation results in a status code of NFS4ERR_NOT_SAME, or NFS4ERR_SAME for NVERIFY, the paired ELSE operation MUST return NFS4_OK. All operations between the pairs MUST NOT be evaluated and MUST return the status NFS4ERR_ANNULLED. If the VERIFY or NVERIFY operation results in a status code of NFS4_OK, the paired ELSE operation if evaluated MUST return NFS4ERR_NOT_SAME or NFS4ERR_SAME and evaluation MUST terminate. Robinson Expires January 14, 2006 [Page 6] Internet-Draft NFSv4 ELSE operation July 2005 4. Operation N: ELSE SYNOPSIS - -> - ARGUMENT void; RESULT struct ELSE4resok { nfsstat4 status; }; DESCRIPTION The ELSE operation is paired with the nearest preceding VERIFY or NVERIFY operation in the COMPOUND that is not already paired. If there is no unpaired VERIFY or NVERIFY the status code of NFS4ERR_INVAL is returned. The ELSE operation is dependent on the status code of the paired VERIFY (or NVERIFY) operation. If the paired operation has a status code of NFS4_OK the ELSE MUST return NFS4ERR_NOT_SAME (or NFS4ERR_SAME) and terminate evaluation of the COMPOUND. Conversely, if the VERIFY (or NVERIFY) operation has a status code of NFS4ERR_NOT_SAME (or NFS4ERR_SAME) the ELSE MUST return NFS4_OK and evaluate the next operation. ERRORS NFS4ERR_INVAL NFS4ERR_SERVERFAULT NFS4ERR_BADXDR NFS4ERR_RESOURCE NFS4ERR_SAME NFS4ERR_NOT_SAME Robinson Expires January 14, 2006 [Page 7] Internet-Draft NFSv4 ELSE operation July 2005 5. Security Considerations The ELSE operation works within the existing security framework of RFC 3530 [1] and introduces no new security issues. Robinson Expires January 14, 2006 [Page 8] Internet-Draft NFSv4 ELSE operation July 2005 6. IANA Considerations This document has no actions for IANA. 7. Normative References [1] Shepler, et al., S., "NFS Version 4 Protocol", RFC 3530, April 2003. Author's Address David Robinson Sun Microsystems, Inc. 5300 Riata Park Court UAUS08-102 Austin, TX 78727 US Phone: +1 512 401 1757 Email: David.Robinson@sun.com Robinson Expires January 14, 2006 [Page 9] Internet-Draft NFSv4 ELSE operation July 2005 Appendix A. Alternatives to NFS4ERR_ANULLED An alternative to having the unevaluated operations between the VERIFY and ELSE return NFS4ERR_ANNULLED was considered. The syntax of the COMPOUND dictates the pairing of ELSE operations so the client will know which ELSE statement was evaluated next and all of the intervening annulled operations are redundant. However, removing the annulled operations from the response will save only a few words of network bandwidth and will allow both the client and other diagnostic tools to better determine what was actually evaluated in case of a server incorrectly performing the pairing. Robinson Expires January 14, 2006 [Page 10] Internet-Draft NFSv4 ELSE operation July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Robinson Expires January 14, 2006 [Page 11]