Network Working Group Brian J. Wickman Internet Draft Document: draft-wickman-nfsv4-directory-delegations-00.txt February 2005 NFSv4.1: Directory Delegations Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be dis- closed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 mate- rial 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. "Copyright (C) The Internet Society (2005). All Rights Reserved." Abstract NFS version 4 (NFSv4) introduces the use of file delegations to improve the ability of clients to cache file data and to provide locks in certain sharing environments without performing a round-trip communication to the server. Directory caching in NFSv4, however, is similar to previous versions and generates unnecessary revalidation Expires: August 2005 [Page 1] Directory Delegations February 2005 traffic to maintain consistency weaker than delegations can provide. This document addresses the issues involved in providing a directory delegation mechanism and specifies a new operation, REQUEST_DELEGA- TION, to enable directory delegations. Expires: August 2005 [Page 2] Directory Delegations February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Proposed Protocol Extensions . . . . . . . . . . . . . . . . 5 4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Differences from draft-ietf-nfsv4-directory-delegation-00.txt . . . . . . . 5 4.2. New Model Proposed . . . . . . . . . . . . . . . . . . . . 6 5. New Operation: REQUEST_DELEGATION - Indicate desire for delegation . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Server Issues . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Delegation Recall . . . . . . . . . . . . . . . . . . . 11 6.2. Delegation Recovery . . . . . . . . . . . . . . . . . . 11 7. Client Issues and Best Practices . . . . . . . . . . . . . 11 7.1. Asynchronous directory metadata updating . . . . . . . . 12 7.2. Whole-tree directory write delegation . . . . . . . . . 13 8. RPC Definition File Changes . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19 10. Normative References . . . . . . . . . . . . . . . . . . 19 11. Informative References . . . . . . . . . . . . . . . . . 19 12. Author's Address . . . . . . . . . . . . . . . . . . . . 20 13. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . 20 14. Copyright Notice . . . . . . . . . . . . . . . . . . . . 20 Expires: August 2005 [Page 3] Directory Delegations February 2005 1. Introduction This document assumes understanding of the NFSv4.0 specification, specifically those sections pertaining to file read and write delega- tions [RFC3530]. A major addition to NFS version 4 is the ability of the server to delegate certain caching responsibilities to the client. When a client issues an OPEN on a filehandle, the server may grant a read or write delegation to the client for that file. This action bestows upon the client certain semantic guarantees with respect to the shar- ing of that file with other clients. When granted a read delegation, the client is assured that no other clients have the ability to write to the file for the duration of the delegation. If the client is granted a write delegation, the client is assured that no other clients have read or write access to the file for the duration of the delegation. Upon receiving an operation that conflicts with the del- egation, the server synchronously recalls the delegation. Any addi- tional data that is required to synchronize the server with the dele- gated client is sent to the server. As such, delegations reduce net- work traffic for certain sharing patterns allowing many operations to be performed locally on cached file data. Directory caching for the NFS version 4 protocol is similar to previ- ous versions. Clients typically cache the results of LOOKUP and READDIR for a predetermined period of time. At the end of this period, the client queries the server to see if the attributes of the directory have been changed. The client uses the response to deter- mine whether or not the cached directory entries corresponding to this directory have been modified. Caching the data in this manner allows clients to reduce the number of synchronous LOOKUP calls made to the server. No mechanism in NFS version 4 provides delegations on directory meta- data. All data associated with directory caches requires either a periodic (asynchronous) attribute refresh or some a synchronous round-trip communication with the server coincident with a user request. This directory delegation draft proposal provides a mecha- nism to eliminate these unnecessary RPCs and to eliminate the possi- bility that cached entries are stale. Furthermore, this draft addresses issues and the specification of directory write delega- tions. Directory write delegations are intended to increase the ability of clients to issue directory operations asynchronously as well as decrease the amount of file delegation state that the server needs to hold. Expires: August 2005 [Page 4] Directory Delegations February 2005 2. Motivation Directory delegation is a proposed extension for NFSv4. Such an extension can dramatically reduce synchronous round-trip RPCs to NFS servers as described by [Wickman]. By allowing clients to cache directory contents while being synchronously notified in the event of a cache invalidation, the client can avoid making frequent requests to interrogate the contents of slowly-changing directories, reducing network traffic, client latency and improving overall client perfor- mance. Furthermore, in the presence of directory write delegations, communication to the server for several common cases can be rendered asynchronous or eliminated entirely. 3. Proposed Protocol Extensions This document includes the definition of protocol extensions to implement both read and write directory delegations. It is believed that these extensions fit within the minor-versioning framework presented in [RFC3530]. The mechanisms explained within this document are designed supposing that session extensions [Talpey] or other means of verifying callback path integrity will be present in the same minor version. In the absence of a verified callback path to a client, delegations should not be granted to the client. 4. Design 4.1. Differences from draft-ietf-nfsv4-directory-delegation-00.txt The approach taken in this draft to enable directory delegations is different than the approach proposed by Khan in [Khan]. Khan's approach involves integrating read-only directory delegations and notifications. Notifications allow a client to persistently cache both directory contents as well as file attributes associated with the directory because the server notifies clients when either file- name bindings or filehandle attributes are changed. This fine-granu- larity insures that no mass invalidation need take place. Single directory entries may be modified and the integrity of the entire cache is maintained, at the cost of a notification. The amount of traffic generated by notifications on file attribute changes has been shown to far outweigh actual requests for informa- tion about the attributes based upon studies of actual workloads Expires: August 2005 [Page 5] Directory Delegations February 2005 [Wickman]. Notifications have two major drawbacks; 1) In the scenario that notifications are allowed to be synchronous, there is the potential for a dramatic increase latency of opera- tions involving delegated directory data as well as an increase in the total amount of traffic generated by the server. 2) In the scenario that notifications are delivered asynchronously, the potential of serving stale data from local cache still exists. The model of directory delegations proposed herein is intended to be simpler to implement, provide better consistency semantics and do so with as little overhead as possible. It is hoped that the implemen- tation of directory delegations proposed within this document resem- bles that of file delegations to the extent that extensive code reuse can take place. Servers with existing delegation support should be able to deploy directory delegations more rapidly. The caveat is that the full range of benefits provided by directory delegations relies upon more sophisticated client behavior. As the exemplar, file delegations are a server optimization intended to improve a client's ability to cache. These delegations are invis- ible to the user or application to the extent that it is unknown to either whether or not a delegation is held on a given file. Notifi- cations have an important use-case in GUI file system browsers. In both scenarios, the ability to register notifications on directories is mandated by the application and not the client. Therefore, it is seen to be more useful to decouple notifications from delegations and explore drafting notifications as a separate user-visible extension. As such, this document has removed the treatment of notifications and suggests their exploration as a separate draft. 4.2. New Model Proposed The directory delegation semantics proposed herein are intended to be symmetric to file delegation semantics in order to make integration of directory delegations as straightforward as possible. File dele- gation infrastructure may be reused to implement this style of direc- tory delegations. The decision to grant a directory delegation is determined directly by server policy and the client can never assume that it will acquire a delegation under any circumstances. Instead of indicating desire to acquire a delegation implicitly via Expires: August 2005 [Page 6] Directory Delegations February 2005 OPEN, the client explicitly indicates desire for a directory delega- tion via a new operation REQUEST_DELEGATION. REQUEST_DELEGATION specifies the mode of access (read or write) and an optional claim of previous delegation state for delegation recovery. REQUEST_DELEGA- TION returns a delegation stateid and various information regarding the client's responsibilities if the delegation is granted. Directory delegation stateids should be issued from the same pool as file dele- gation stateids. This allows CB_RECALL to be agnostic to a particu- lar type of delegation, avoiding the necessity of introducing a new callback for directory delegations. A directory read delegation prevents the change of a given direc- tory's data by other clients without first synchronously revoking any delegations on that directory. Creation and deletion of directory entries are grounds necessitating revocation. This directly corre- sponds to a delegation on the change attribute of a directory. Therefore, the server may implement this feature in the same manner it would implement a file read delegation. Note that files within a read delegated directory may be read, written, and their attributes changed in any manner without disrupting the directory's change attribute. Similarly, a directory write delegation prevents read and write access to directory data by other clients. The server can effectively translate directory delegations to file delegations by treating operations that access directory contents as a synonymous sequence of operations on a file. For example, a LOOKUP operation on a directory is effectively OPEN; READ; CLOSE; and a RENAME operation is effectively OPEN; WRITE; CLOSE; where OPEN is specified for read and write respectively. When another client issues a directory read operation that mandates a revocation, the server delivers a CB_RECALL to the delegated client, which should immediately return NFS4_OK. Any changes to the direc- tory should be flushed to the server and followed by DELEGRETURN. The implementation of directory delegations on the server should be minimal if an existing file delegation implementation exists. There is considerable room for the client to exhibit advanced behavior with regard to directory write delegations in the area of delegation recall and potential support for write delegation on entire directory subtrees. These points are described in the following sections. 5. New Operation: REQUEST_DELEGATION - Indicate desire for delegation on a directory. SYNOPSIS Expires: August 2005 [Page 7] Directory Delegations February 2005 (cfh), delegation_type, claim -> (cfh), delegation_stateid, delegation_type, recall, permis- sions, delegation ARGUMENT struct REQUEST_DELEGATION4args { dir_delegation_type4 delegation_type; dir_delegation_claim4 claim; }; RESULT enum dir_delegation_type4 { DIR_DELEGATE_READ, DIR_DELEGATE_WRITE }; enum dir_delegation_claim4 { DIR_DELEGATE_CLAIM_NULL, DIR_DELEGATE_CLAIM_CUR, DIR_DELEGATE_CLAIM_PREV }; union directory_delegation4 switch (dir_delegation_type4 delegation_type) { case DIR_DELEGATE_READ: void; case DIR_DELEGATE_WRITE: dir_write_delegation4 write; }; struct dir_write_delegation4 { /* amount of space allowed for all files created */ nfs_space_limit4 space_limit; /* number of directory entries allowed to be created for this directory before committing OPENs to server */ uint32_t dirent_limit; }; struct REQUEST_DELEGATION4resok { /* delegation stateid */ stateid4 delegation_stateid; dir_delegation_type4 delegation_type; bool recall; Expires: August 2005 [Page 8] Directory Delegations February 2005 nfsace4 permissions; directory_delegation4 delegation; }; union REQUEST_DELEGATION4res switch (nfsstat4 status) { case NFS4_OK: /* CURRENT_FH: delegated dir fh */ REQUEST_DELEGATION4resok resok4; default: void; }; DESCRIPTION REQUEST_DELEGATION indicates a client's desire to hold a directory delegation on a given directory as specified by the current file- handle. When the server receives REQUEST_DELEGATION, it should determine whether or not granting the delegation is possible or if it is prudent. It could do this by a simple history-based heuris- tic. However, no specific policy is mandated. The server must not grant a read or write delegation on a direc- tory if any files within the directory are write delegated to other clients. The server must not grant a write delegation on a directory if any files within the directory are read or write del- egated to other clients. In order to service operations asynchronously on a delegated directory, the client should adhere to the returned access control rights so that it can determine whether or not certain directory operations are acceptable. Otherwise, it must issue all directory operations synchronously. This mirrors the behavior of file dele- gations and should be treated the same. A suitable client practice would be to issue a REQUEST_DELEGATION for read delegation along with READDIR operations. A client should preferably make a best effort attempt at acquiring a dele- gation whenever it has a large number of fresh directory entries associated with a particular directory filehandle. Furthermore, it is best practice to request a directory write del- egation each time a new directory is created. Under normal cir- cumstances, it is expected that the lifetime of a new directory is quite short, and the combination of directory and file delegations can defer most directory operations from the server entirely if files are ultimately overwritten or deleted. Because a client may service OPEN and CREATE operations Expires: August 2005 [Page 9] Directory Delegations February 2005 asynchronously on a write delegated directory, the server needs to regulate the maximum resources a client may allocate on behalf of the server in the same way it does with file write delegations. However, we must extend the resource limitations beyond allocable bytes or blocks for files by limiting the quantity of directory entries allowed to be created. As such, the field dirent_limit is returned on a successful REQUEST_DELEGATION for write, and speci- fies the number of new files or directories that may be created while the delegation is held. If a file is created within a directory while the directory is delegated, then the contents of the new file are write delegated to the client until the directory delegation is revoked. This optimization is allowed because the same protections and guaran- tees of a file write delegation exist for newly created objects. Directory delegation revocation occurs in precisely the same man- ner as file delegations, based upon attribute changes. The server initiates the sequence by issuing a CB_RECALL. The client returns NFS4_OK immediately and follows by doing all the necessary opera- tions to synchronize the local and remote directory metadata and file contents. Last, the client issues a DELEGRETURN. Because directory delegations and file delegations share the same type of stateids, CB_RECALL and DELEGRETURN are left unmodified. IMPLEMENTATION As abovementioned, the implementation of granting policy is intended to be symmetric with file delegations and should be treated in a similar manner. If the server opts not to support directory delegations, then it should issue an NFS4ERR_DIRDE- LEG_UNAVAIL error. ERRORS NFS4ERR_ACCESS NFS4ERR_BADHANDLE NFS4ERR_BADXDR NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_MOVED NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_DIRDELEG_UNAVAIL Expires: August 2005 [Page 10] Directory Delegations February 2005 NFS4ERR_DIRDELEG_DENIED 6. Server Issues 6.1. Delegation Recall The server will recall the directory delegation by sending a callback to the client. It will use the same callback procedure as used for recalling file delegations. The server will recall the delegation when a conflicting operation is issued by another client. 6.2. Delegation Recovery The recovery parameters of OPEN delegations are encapsulated within the parameters in the explicit REQUEST_DELEGATION call. The behavior of delegation recovery is intended to be explicitly symmetric with that of OPEN delegations for files. 7. Client Issues and Best Practices There are several optimizations the client may be able to perform using directory delegations. However, if directory write delegations are supported by the server, the client must address possible compli- cations that may arise. Specifically, it would be desirable for a client to defer as many directory operations as possible, either servicing them completely locally or allowing them to be delivered asynchronously to the server. All read operations on the directory may be serviced from cached data acquired by the client since the delegation has been granted because the directory is left unchanged for the duration of the delegation. In the case of write directory delegations, write operations on the directory have the potential to be problematic for the following rea- sons. 1) When the user wishes to create a file or directory, it must be allocated a fileid by the server. This must be a unique and per- manent identifier. The client has no way of providing this fileid without actually creating a placeholder object on the server. Expires: August 2005 [Page 11] Directory Delegations February 2005 2) chown and chgrp operations cannot be resolved by the client because the client can never be aware of the underlying security mechanisms put in place by the server. 3) Similar to file write delegations, which need to know a bound on the free space available on the server, directory write delega- tions must place a bound on free space as well as the allowable number of directory entries allocable by the client. Some of these issues are addressed in the following sections. 7.1. Asynchronous directory metadata updating When a client holds a directory write delegation, many directory operations on cached entries may be deferred until the delegation is recalled so long as the maximum allowed number of new directory entries has not been exceeded. This parameter, dirent_limit, is specified when a directory delegation is granted. There are two complications. 1) If a CREATE or OPEN for create is serviced by the client, then it must leave the fileid as unresolved until the user requests a GETATTR or any other operation that returns fileid as a parameter. Once such an operation has been issued by the user, the client must create an entry for this file on the server and get a proper fileid. This gives the client a window of time between the ini- tial file creation and the first time the fileid is queried that the OPEN or CREATE operation can be deferred. This allows the client to render the file creation asynchronous within this win- dow, potentially improving perceived filesystem latency to the user. 2) It is up to the client to implement a log of changes to the direc- tory for operations that are normally serviced asynchronously. For example, if a file is created and deleted before its fileid is queried, these self-cancelling operations need never be delivered to the server. The client may opt against sophistication and sim- ply issue some or all directory modifications synchronously to the server. Expires: August 2005 [Page 12] Directory Delegations February 2005 7.2. Whole-tree directory write delegation If the client can insure that a single level of a directory is uncached and undelegated by other clients, then it may do full direc- tory sub-tree write delegation, e.g.: MKDIR/GETFH or LOOKUP REQUEST_DELEGATION (mode = write) READDIR If MKDIR/LOOKUP and REQUEST_DELEGATION succeed and READDIR returns an empty directory, the client may assume that it is delegated the directory and all sub-directories until the server recalls the dele- gation, at which time the client must dump the cached sub-directories to the server. However, the same consideration of acquiring correct fileids applies and must not be overlooked. 8. RPC Definition File Changes /* * Copyright (C) The Internet Society (2005) * All Rights Reserved. */ /* * nfs41_prot.x */ enum dir_delegation_type4 { DIR_DELEGATE_READ, DIR_DELEGATE_WRITE }; enum dir_delegation_claim4 { DIR_DELEGATE_CLAIM_NULL, DIR_DELEGATE_CLAIM_CUR, DIR_DELEGATE_CLAIM_PREV }; /* * Input arguments passed to the GET_DIR_DELEGATION operation. */ struct REQUEST_DELEGATION4args { /* CURRENT_FH: directory */ Expires: August 2005 [Page 13] Directory Delegations February 2005 dir_delegation_type4 delegation_type; dir_delegation_claim4 claim; }; union directory_delegation4 switch (dir_delegation_type4 delegation_type) { case DIR_DELEGATE_READ: void; case DIR_DELEGATE_WRITE: dir_write_delegation4 write; }; struct dir_write_delegation4 { /* amount of space allowed for all files created */ nfs_space_limit4 space_limit; /* number of directory entries allowed to be created for this directory */ uint32_t dirent_limit; }; /* * Result flags */ struct REQUEST_DELEGATION4resok { /* delegation stateid */ stateid4 delegation_stateid; dir_delegation_type4 delegation_type; bool recall; nfsace4 permissions; directory_delegation4 delegation; }; union REQUEST_DELEGATION4res switch (nfsstat4 status) { case NFS4_OK: /* CURRENT_FH: delegated dir fh */ REQUEST_DELEGATION4resok resok4; default: void; }; /* * Operation arrays */ enum nfs_opnum4 { OP_ACCESS = 3, Expires: August 2005 [Page 14] Directory Delegations February 2005 OP_CLOSE = 4, OP_COMMIT = 5, OP_CREATE = 6, OP_DELEGPURGE = 7, OP_DELEGRETURN = 8, OP_GETATTR = 9, OP_GETFH = 10, OP_LINK = 11, OP_LOCK = 12, OP_LOCKT = 13, OP_LOCKU = 14, OP_LOOKUP = 15, OP_LOOKUPP = 16, OP_NVERIFY = 17, OP_OPEN = 18, OP_OPENATTR = 19, OP_OPEN_CONFIRM = 20, OP_OPEN_DOWNGRADE = 21, OP_PUTFH = 22, OP_PUTPUBFH = 23, OP_PUTROOTFH = 24, OP_READ = 25, OP_READDIR = 26, OP_READLINK = 27, OP_REMOVE = 28, OP_RENAME = 29, OP_RENEW = 30, OP_RESTOREFH = 31, OP_SAVEFH = 32, OP_SECINFO = 33, OP_SETATTR = 34, OP_SETCLIENTID = 35, OP_SETCLIENTID_CONFIRM = 36, OP_VERIFY = 37, OP_WRITE = 38, OP_RELEASE_LOCKOWNER = 39, OP_REQUEST_DELEGATION = 40, OP_ILLEGAL = 10044 }; union nfs_argop4 switch (nfs_opnum4 argop) { case OP_ACCESS: ACCESS4args opaccess; case OP_CLOSE: CLOSE4args opclose; case OP_COMMIT: COMMIT4args opcommit; case OP_CREATE: CREATE4args opcreate; case OP_DELEGPURGE: DELEGPURGE4args opdelegpurge; case OP_DELEGRETURN: DELEGRETURN4args opdelegreturn; case OP_GETATTR: GETATTR4args opgetattr; Expires: August 2005 [Page 15] Directory Delegations February 2005 case OP_GETFH: void; case OP_LINK: LINK4args oplink; case OP_LOCK: LOCK4args oplock; case OP_LOCKT: LOCKT4args oplockt; case OP_LOCKU: LOCKU4args oplocku; case OP_LOOKUP: LOOKUP4args oplookup; case OP_LOOKUPP: void; case OP_NVERIFY: NVERIFY4args opnverify; case OP_OPEN: OPEN4args opopen; case OP_OPENATTR: OPENATTR4args opopenattr; case OP_OPEN_CONFIRM: OPEN_CONFIRM4args opopen_confirm; case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4args opopen_downgrade; case OP_PUTFH: PUTFH4args opputfh; case OP_PUTPUBFH: void; case OP_PUTROOTFH: void; case OP_READ: READ4args opread; case OP_READDIR: READDIR4args opreaddir; case OP_READLINK: void; case OP_REMOVE: REMOVE4args opremove; case OP_RENAME: RENAME4args oprename; case OP_RENEW: RENEW4args oprenew; case OP_RESTOREFH: void; case OP_SAVEFH: void; case OP_SECINFO: SECINFO4args opsecinfo; case OP_SETATTR: SETATTR4args opsetattr; case OP_SETCLIENTID: SETCLIENTID4args opsetclientid; case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4args opsetclientid_confirm; case OP_VERIFY: VERIFY4args opverify; case OP_WRITE: WRITE4args opwrite; case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4args oprelease_lockowner; case OP_REQUEST_DELEGATION: REQUEST_DELEGATION4args oprequest_delegation; case OP_ILLEGAL: void; }; union nfs_resop4 switch (nfs_opnum4 resop){ case OP_ACCESS: ACCESS4res opaccess; case OP_CLOSE: CLOSE4res opclose; case OP_COMMIT: COMMIT4res opcommit; case OP_CREATE: CREATE4res opcreate; case OP_DELEGPURGE: DELEGPURGE4res opdelegpurge; case OP_DELEGRETURN: DELEGRETURN4res opdelegreturn; case OP_GETATTR: GETATTR4res opgetattr; case OP_GETFH: GETFH4res opgetfh; case OP_LINK: LINK4res oplink; Expires: August 2005 [Page 16] Directory Delegations February 2005 case OP_LOCK: LOCK4res oplock; case OP_LOCKT: LOCKT4res oplockt; case OP_LOCKU: LOCKU4res oplocku; case OP_LOOKUP: LOOKUP4res oplookup; case OP_LOOKUPP: LOOKUPP4res oplookupp; case OP_NVERIFY: NVERIFY4res opnverify; case OP_OPEN: OPEN4res opopen; case OP_OPENATTR: OPENATTR4res opopenattr; case OP_OPEN_CONFIRM: OPEN_CONFIRM4res opopen_confirm; case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4res opopen_downgrade; case OP_PUTFH: PUTFH4res opputfh; case OP_PUTPUBFH: PUTPUBFH4res opputpubfh; case OP_PUTROOTFH: PUTROOTFH4res opputrootfh; case OP_READ: READ4res opread; case OP_READDIR: READDIR4res opreaddir; case OP_READLINK: READLINK4res opreadlink; case OP_REMOVE: REMOVE4res opremove; case OP_RENAME: RENAME4res oprename; case OP_RENEW: RENEW4res oprenew; case OP_RESTOREFH: RESTOREFH4res oprestorefh; case OP_SAVEFH: SAVEFH4res opsavefh; case OP_SECINFO: SECINFO4res opsecinfo; case OP_SETATTR: SETATTR4res opsetattr; case OP_SETCLIENTID: SETCLIENTID4res opsetclientid; case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4res opsetclientid_confirm; case OP_VERIFY: VERIFY4res opverify; case OP_WRITE: WRITE4res opwrite; case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4res oprelease_lockowner; case OP_REQUEST_DELEGATION: REQUEST_DELEGATION4res oprequest_delegation; case OP_ILLEGAL: ILLEGAL4res opillegal; }; /* * New error codes */ enum nfsstat4 { NFS4_OK = 0, /* everything is okay */ NFS4ERR_PERM = 1, /* caller not privileged */ NFS4ERR_NOENT = 2, /* no such file/directory */ NFS4ERR_IO = 5, /* hard I/O error */ NFS4ERR_NXIO = 6, /* no such device */ NFS4ERR_ACCESS = 13, /* access denied */ NFS4ERR_EXIST = 17, /* file already exists */ Expires: August 2005 [Page 17] Directory Delegations February 2005 NFS4ERR_XDEV = 18, /* different filesystems */ /* Unused/reserved 19 */ NFS4ERR_NOTDIR = 20, /* should be a directory */ NFS4ERR_ISDIR = 21, /* should not be directory */ NFS4ERR_INVAL = 22, /* invalid argument */ NFS4ERR_FBIG = 27, /* file exceeds server max */ NFS4ERR_NOSPC = 28, /* no space on filesystem */ NFS4ERR_ROFS = 30, /* read-only filesystem */ NFS4ERR_MLINK = 31, /* too many hard links */ NFS4ERR_NAMETOOLONG = 63, /* name exceeds server max */ NFS4ERR_NOTEMPTY = 66, /* directory not empty */ NFS4ERR_DQUOT = 69, /* hard quota limit reached*/ NFS4ERR_STALE = 70, /* file no longer exists */ NFS4ERR_BADHANDLE = 10001,/* Illegal filehandle */ NFS4ERR_BAD_COOKIE = 10003,/* READDIR cookie is stale */ NFS4ERR_NOTSUPP = 10004,/* operation not supported */ NFS4ERR_TOOSMALL = 10005,/* response limit exceeded */ NFS4ERR_SERVERFAULT = 10006,/* undefined server error */ NFS4ERR_BADTYPE = 10007,/* type invalid for CREATE */ NFS4ERR_DELAY = 10008,/* file "busy" - retry */ NFS4ERR_SAME = 10009,/* nverify says attrs same */ NFS4ERR_DENIED = 10010,/* lock unavailable */ NFS4ERR_EXPIRED = 10011,/* lock lease expired */ NFS4ERR_LOCKED = 10012,/* I/O failed due to lock */ NFS4ERR_GRACE = 10013,/* in grace period */ NFS4ERR_FHEXPIRED = 10014,/* filehandle expired */ NFS4ERR_SHARE_DENIED = 10015,/* share reserve denied */ NFS4ERR_WRONGSEC = 10016,/* wrong security flavor */ NFS4ERR_CLID_INUSE = 10017,/* clientid in use */ NFS4ERR_RESOURCE = 10018,/* resource exhaustion */ NFS4ERR_MOVED = 10019,/* filesystem relocated */ NFS4ERR_NOFILEHANDLE = 10020,/* current FH is not set */ NFS4ERR_MINOR_VERS_MISMATCH = 10021,/* minor vers not supp */ NFS4ERR_STALE_CLIENTID = 10022,/* server has rebooted */ NFS4ERR_STALE_STATEID = 10023,/* server has rebooted */ NFS4ERR_OLD_STATEID = 10024,/* state is out of sync */ NFS4ERR_BAD_STATEID = 10025,/* incorrect stateid */ NFS4ERR_BAD_SEQID = 10026,/* request is out of seq. */ NFS4ERR_NOT_SAME = 10027,/* verify - attrs not same */ NFS4ERR_LOCK_RANGE = 10028,/* lock range not supported*/ NFS4ERR_SYMLINK = 10029,/* should be file/directory*/ NFS4ERR_RESTOREFH = 10030,/* no saved filehandle */ NFS4ERR_LEASE_MOVED = 10031,/* some filesystem moved */ NFS4ERR_ATTRNOTSUPP = 10032,/* recommended attr not sup*/ NFS4ERR_NO_GRACE = 10033,/* reclaim outside of grace*/ NFS4ERR_RECLAIM_BAD = 10034,/* reclaim error at server */ NFS4ERR_RECLAIM_CONFLICT = 10035,/* conflict on reclaim */ NFS4ERR_BADXDR = 10036,/* XDR decode failed */ Expires: August 2005 [Page 18] Directory Delegations February 2005 NFS4ERR_LOCKS_HELD = 10037,/* file locks held at CLOSE*/ NFS4ERR_OPENMODE = 10038,/* conflict in OPEN and I/O*/ NFS4ERR_BADOWNER = 10039,/* owner translation bad */ NFS4ERR_BADCHAR = 10040,/* utf-8 char not supported*/ NFS4ERR_BADNAME = 10041,/* name not supported */ NFS4ERR_BAD_RANGE = 10042,/* lock range not supported*/ NFS4ERR_LOCK_NOTSUPP = 10043,/* no atomic up/downgrade */ NFS4ERR_OP_ILLEGAL = 10044,/* undefined operation */ NFS4ERR_DEADLOCK = 10045,/* file locking deadlock */ NFS4ERR_FILE_OPEN = 10046,/* open file blocks op. */ NFS4ERR_ADMIN_REVOKED = 10047,/* lockowner state revoked */ NFS4ERR_CB_PATH_DOWN = 10048,/* callback path down */ NFS4ERR_DIRDELEG_UNAVAIL= 10049,/* dir dlg. not returned */ NFS4ERR_DIRDELEG_DENIED = 10050 /* dir delegation denied */ }; 9. Acknowledgements Trond Myklebust, Spencer Shepler, Saadia Khan, Carl Burnett, and Peter Honeyman for their comments and constructive criticism. 10. Normative References [Khan] S. Khan, "NFSv4.1: Directory Delegations and Notifications", Internet Draft, July, 2004, draft-ietf-nfsv4-directory- delegation-00.txt [RFC3530] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck, "NFS version 4 Protocol", RFC 3530, April, 2003. [Talpey] T. Talpey, S. Shepler, "NFSv4 Session Extensions", Internet Draft, July, 2004, draft-ietf-nfsv4-sess-00.txt 11. Informative References [Wickman] B. Wickman, "NFSv4: Directory Delegations", http://www.citi.umich.edu/u/bwickman/dirdel/whitepaper.html Expires: August 2005 [Page 19] Directory Delegations February 2005 12. Author's Address Brian Wickman CITI 535 W. William, Ste. 3100 Ann Arbor, MI 48103-4943 USA Phone: (734) 763-2929 E-mail: bwickman@citi.umich.edu 13. IPR Notices 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 assur- ances 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. 14. Copyright Notice Copyright (C) The Internet Society (2004). 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. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Expires: August 2005 [Page 20] Directory Delegations February 2005 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires: August 2005 [Page 21]