--- 1/draft-ietf-nfsv4-minorversion2-33.txt 2015-03-30 11:15:13.702879114 -0700 +++ 2/draft-ietf-nfsv4-minorversion2-34.txt 2015-03-30 11:15:13.882883476 -0700 @@ -1,18 +1,18 @@ NFSv4 T. Haynes Internet-Draft Primary Data -Intended status: Standards Track March 05, 2015 -Expires: September 6, 2015 +Intended status: Standards Track March 30, 2015 +Expires: October 1, 2015 NFS Version 4 Minor Version 2 - draft-ietf-nfsv4-minorversion2-33.txt + draft-ietf-nfsv4-minorversion2-34.txt Abstract This Internet-Draft describes NFS version 4 minor version two, describing the protocol extensions made from NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version two include: Server Side Copy, Application I/O Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. Requirements Language @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on September 6, 2015. + This Internet-Draft will expire on October 1, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -115,22 +115,22 @@ 9.3.2. Permission Checking . . . . . . . . . . . . . . . . . 38 9.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 38 9.3.4. Existing Objects . . . . . . . . . . . . . . . . . . 38 9.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 39 9.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 39 9.5. Discovery of Server Labeled NFS Support . . . . . . . . . 39 9.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 40 9.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 40 9.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . 41 9.7. Security Considerations for Labeled NFS . . . . . . . . . 42 - 10. Sharing change attribute implementation details with NFSv4 - clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 + 10. Sharing change attribute implementation characteristics with + NFSv4 clients . . . . . . . . . . . . . . . . . . . . . . . . 42 11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 43 11.1. Error Definitions . . . . . . . . . . . . . . . . . . . 43 11.1.1. General Errors . . . . . . . . . . . . . . . . . . . 43 11.1.2. Server to Server Copy Errors . . . . . . . . . . . . 43 11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . 44 11.2. New Operations and Their Valid Errors . . . . . . . . . 44 11.3. New Callback Operations and Their Valid Errors . . . . . 48 12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 49 12.1. New RECOMMENDED Attributes - List and Definition References . . . . . . . . . . . . . . . . . . . . . . . 49 @@ -144,23 +144,23 @@ 15.1. Operation 59: ALLOCATE - Reserve Space in A Region of a File . . . . . . . . . . . . . . . . . . . . . . . . . . 58 15.2. Operation 60: COPY - Initiate a server-side copy . . . . 59 15.3. Operation 61: COPY_NOTIFY - Notify a source server of a future copy . . . . . . . . . . . . . . . . . . . . . . 64 15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region of a File . . . . . . . . . . . . . . . . . . . . . . . 66 15.5. Operation 63: IO_ADVISE - Application I/O access pattern hints . . . . . . . . . . . . . . . . . . . . . . . . . 67 15.6. Operation 64: LAYOUTERROR - Provide Errors for the - Layout . . . . . . . . . . . . . . . . . . . . . . . . . 73 + Layout . . . . . . . . . . . . . . . . . . . . . . . . . 72 15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the - Layout . . . . . . . . . . . . . . . . . . . . . . . . . 76 + Layout . . . . . . . . . . . . . . . . . . . . . . . . . 75 15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded Operation . . . . . . . . . . . . . . . . . . . . . . . 77 15.9. Operation 67: OFFLOAD_STATUS - Poll for Status of Asynchronous Operation . . . . . . . . . . . . . . . . . 78 15.10. Operation 68: READ_PLUS - READ Data or Holes from a File 79 15.11. Operation 69: SEEK - Find the Next Data or Hole . . . . 84 15.12. Operation 70: WRITE_SAME - WRITE an ADB Multiple Times to a File . . . . . . . . . . . . . . . . . . . . . . . 85 16. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 89 16.1. Operation 15: CB_OFFLOAD - Report results of an @@ -1953,21 +1953,22 @@ protections. Alternate methods might be in use to handle the lack of MAC support and care should be taken to identify and mitigate threats from possible tampering outside of these methods. An example of this is that a server that modifies READDIR or LOOKUP results based on the client's subject label might want to always construct the same subject label for a client which does not present one. This will prevent a non-Labeled NFS client from mixing entries in the directory cache. -10. Sharing change attribute implementation details with NFSv4 clients +10. Sharing change attribute implementation characteristics with NFSv4 + clients Although both the NFSv4 [I-D.ietf-nfsv4-rfc3530bis] and NFSv4.1 protocol [RFC5661], define the change attribute as being mandatory to implement, there is little in the way of guidance as to its construction. The only mandated constraint is that the value must change whenever the file data or metadata change. While this allows for a wide range of implementations, it also leaves the client with no way to determine which is the most recent value for the change attribute in a case where several RPC calls have been @@ -2807,29 +2808,35 @@ void; }; 15.2.3. DESCRIPTION The COPY operation is used for both intra-server and inter-server copies. In both cases, the COPY is always sent from the client to the destination server of the file copy. The COPY operation requests - that a file be copied from the location specified by the SAVED_FH - value to the location specified by the CURRENT_FH. + that a range in the file specified by SAVED_FH is copied to a range + in the file specified by CURRENT_FH. - The SAVED_FH must be a regular file. If SAVED_FH is not a regular - file, the operation MUST fail and return NFS4ERR_WRONG_TYPE. + Both SAVED_FH and CURRENT_FH must be regular files. If either + SAVED_FH or CURRENT_FH are not regular files, the operation MUST fail + and return NFS4ERR_WRONG_TYPE. + + SAVED_FH and CURRENT_FH must be differet files. If SAVED_FH and + CURRENT_FH refer to the same file, the operation will fail with + NFS4ERR_INVAL. In order to set SAVED_FH to the source file handle, the compound procedure requesting the COPY will include a sub-sequence of operations such as + PUTFH source-fh SAVEFH If the request is for an inter-server-to-server copy, the source-fh is a filehandle from the source server and the compound procedure is being executed on the destination server. In this case, the source- fh is a foreign filehandle on the server receiving the COPY request. If either PUTFH or SAVEFH checked the validity of the filehandle, the operation would likely fail and return NFS4ERR_STALE. @@ -2829,62 +2836,53 @@ If the request is for an inter-server-to-server copy, the source-fh is a filehandle from the source server and the compound procedure is being executed on the destination server. In this case, the source- fh is a foreign filehandle on the server receiving the COPY request. If either PUTFH or SAVEFH checked the validity of the filehandle, the operation would likely fail and return NFS4ERR_STALE. If a server supports the inter-server-to-server COPY feature, a PUTFH followed by a SAVEFH MUST NOT return NFS4ERR_STALE for either operation. These restrictions do not pose substantial difficulties - for servers. The CURRENT_FH and SAVED_FH may be validated in the - context of the operation referencing them and an NFS4ERR_STALE error - returned for an invalid file handle at that point. - - For an inter-server copy, the ca_dst_stateid MUST refer to either - delegation, locking, or open states provided earlier by the server - (see Section 4.4.1). The order of selection is explained in - Section 8.2.5 of [RFC5661]. And the ca_src_stateid MUST be the - cnr_stateid returned from the earlier COPY_NOTIFY. If either stateid - is invalid, then the operation MUST fail. If the request is for an - intra-server copy, then the ca_src_stateid can be ignored. If - ca_dst_stateid is invalid, then the operation MUST fail. + for servers. CURRENT_FH and SAVED_FH may be validated in the context + of the operation referencing them and an NFS4ERR_STALE error returned + for an invalid file handle at that point. - The CURRENT_FH specifies the destination of the copy operation. The - CURRENT_FH MUST be a regular file and not a directory. Note, the - file MUST exist before the COPY operation begins. It is the - responsibility of the client to create the file if necessary, - regardless of the actual copy protocol used. If the file cannot be - created in the destination file system (due to file name - restrictions, such as case or length), the COPY operation MUST NOT be - called. + The ca_dst_stateid MUST refer to a stateid that is valid for a WRITE + operation and follows the rules for stateids in Sections 8.2.5 and + 18.32.3 of [RFC5661]. For an inter-server copy, the ca_src_stateid + MUST be the cnr_stateid returned from the earlier COPY_NOTIFY + operation, while for an intra-server copy ca_src_stateid MUST refer + to a stateid that is valid for a READ operations and follows the + rules for stateids in Sections 8.2.5 and 18.22.3 of [RFC5661]. If + either stateid is invalid, then the operation MUST fail. The ca_src_offset is the offset within the source file from which the data will be read, the ca_dst_offset is the offset within the destination file to which the data will be written, and the ca_count is the number of bytes that will be copied. An offset of 0 (zero) specifies the start of the file. A count of 0 (zero) requests that all bytes from ca_src_offset through EOF be copied to the destination. If concurrent modifications to the source file overlap with the source file region being copied, the data copied may include all, some, or none of the modifications. The client can use standard NFS operations (e.g., OPEN with OPEN4_SHARE_DENY_WRITE or mandatory byte range locks) to protect against concurrent modifications if the client is concerned about this. If the source file's end of file is being modified in parallel with a copy that specifies a count of 0 (zero) bytes, the amount of data copied is implementation dependent (clients may guard against this case by specifying a non-zero count value or preventing modification of the source file as mentioned above). If the source offset or the source offset plus count is greater than - or equal to the size of the source file, the operation will fail with + the size of the source file, the operation will fail with NFS4ERR_INVAL. The destination offset or destination offset plus count may be greater than the size of the destination file. This allows for the client to issue parallel copies to implement operations such as % cat file1 file2 file3 file4 > dest @@ -2923,43 +2921,22 @@ determine both requirements at the same time. Upon receiving the NFS4ERR_OFFLOAD_NO_REQS error, the client has to determine if it wants to either re-request the copy with a relaxed set of requirements or if it wants to revert to manually copying the data. If it decides to manually copy the data and this is a remote copy, then the client is responsible for informing the source that the earlier COPY_NOTIFY is no longer valid by sending it an OFFLOAD_CANCEL. - The copying of any and all attributes on the source file is the - responsibility of both the client and the copy protocol. Any - attribute which is both exposed via the NFS protocol on the source - file and set SHOULD be copied to the destination file. Any attribute - supported by the destination server that is not set on the source - file SHOULD be left unset. If the client cannot copy an attribute - from the source to destination, it MAY fail the copy transaction. - - Metadata attributes not exposed via the NFS protocol SHOULD be copied - to the destination file where appropriate via the copy protocol. - Note that if the copy protocol is NFSv4.x, then these attributes will - be lost. - - The destination file's named attributes are not duplicated from the - source file. After the copy process completes, the client MAY - attempt to duplicate named attributes using standard NFSv4 - operations. However, the destination file's named attribute - capabilities MAY be different from the source file's named attribute - capabilities. - If the operation does not result in an immediate failure, the server - will return NFS4_OK, and the CURRENT_FH will remain the destination's - filehandle. + will return NFS4_OK. If the wr_callback_id is returned, this indicates that the operation was initiated and a CB_OFFLOAD callback will deliver the final results of the operation. The wr_callback_id stateid is termed a copy stateid in this context. The server is given the option of returning the results in a callback because the data may require a relatively long period of time to copy. If no wr_callback_id is returned, the operation completed synchronously and no callback will be issued by the server. The @@ -3058,24 +3036,25 @@ the same copy notification request to the source server. The cnr_stateid is a copy stateid which uniquely describes the state needed on the source server to track the proposed copy. As defined in Section 8.2 of [RFC5661], a stateid is tied to the current filehandle and if the same stateid is presented by two different clients, it may refer to different state. As the source does not know which netloc4 network location the destinaton might use to establish the copy operation, it can use the cnr_stateid to identify that the destination is operating on behalf of the client. Thus the - source server MUST construct copy stateids such that they are unique - from all other stateids handed out to clients. These copy stateids - MUST equate to each of the earlier delegation, locking, and open - states for the client on the given file (see Section 4.4.1). + source server MUST construct copy stateids such that they are + distinct from all other stateids handed out to clients. These copy + stateids MUST denote the same set of locks as each of the earlier + delegation, locking, and open states for the client on the given file + (see Section 4.4.1). A successful response will also contain a list of netloc4 network location formats called cnr_source_server, on which the source is willing to accept connections from the destination. These might not be reachable from the client and might be located on networks to which the client has no connection. For a copy only involving one server (the source and destination are on the same server), this operation is unnecessary. @@ -4316,33 +4297,34 @@ Appendix A. Acknowledgments Tom Haynes would like to thank NetApp, Inc. for its funding of his time on this project. For the pNFS Access Permissions Check, the original draft was by Sorin Faibish, David Black, Mike Eisler, and Jason Glasgow. The work was influenced by discussions with Benny Halevy and Bruce Fields. A review was done by Tom Haynes. - For the Sharing change attribute implementation details with NFSv4 - clients, the original draft was by Trond Myklebust. + For the Sharing change attribute implementation characteristics with + NFSv4 clients, the original draft was by Trond Myklebust. For the NFS Server Side Copy, the original draft was by James Lentini, Mike Eisler, Deepak Kenchammana, Anshul Madan, and Rahul Iyer. Tom Talpey co-authored an unpublished version of that document. It was also was reviewed by a number of individuals: Pranoop Erasani, Tom Haynes, Arthur Lent, Trond Myklebust, Dave Noveck, Theresa Lingutla-Raj, Manjunath Shankararao, Satyam Vaghani, and Nico Williams. Anna Schumaker's early prototyping experience helped us avoid some traps. Also, both Olga Kornievskaia and Andy Adamson brought implementation experience to the use of copy stateids - in inter-server copy. + in inter-server copy. Jorge Mora was able to optimize the handling + of errors for the result of COPY. For the NFS space reservation operations, the original draft was by Mike Eisler, James Lentini, Manjunath Shankararao, and Rahul Iyer. For the sparse file support, the original draft was by Dean Hildebrand and Marc Eshel. Valuable input and advice was received from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and Richard Scheffenegger. For the Application IO Hints, the original draft was by Dean