draft-ietf-nfsv4-minorversion2-20.txt   draft-ietf-nfsv4-minorversion2-21.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track August 13, 2013 Intended status: Standards Track February 03, 2014
Expires: February 14, 2014 Expires: August 7, 2014
NFS Version 4 Minor Version 2 NFS Version 4 Minor Version 2
draft-ietf-nfsv4-minorversion2-20.txt draft-ietf-nfsv4-minorversion2-21.txt
Abstract Abstract
This Internet-Draft describes NFS version 4 minor version two, This Internet-Draft describes NFS version 4 minor version two,
focusing mainly on the protocol extensions made from NFS version 4 focusing mainly on the protocol extensions made from NFS version 4
minor version 0 and NFS version 4 minor version 1. Major extensions minor version 0 and NFS version 4 minor version 1. Major extensions
introduced in NFS version 4 minor version two include: Server-side introduced in NFS version 4 minor version two include: Server-side
Copy, Application I/O Advise, Space Reservations, Sparse Files, Copy, Application I/O Advise, Space Reservations, Sparse Files,
Application Data Blocks, and Labeled NFS. Application Data Blocks, and Labeled NFS.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 14, 2014. This Internet-Draft will expire on August 7, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3.2.1. Overview of Copy Operations . . . . . . . . . . . . . 11 3.2.1. Overview of Copy Operations . . . . . . . . . . . . . 11
3.2.2. Locking the Files . . . . . . . . . . . . . . . . . . 12 3.2.2. Locking the Files . . . . . . . . . . . . . . . . . . 12
3.2.3. Intra-Server Copy . . . . . . . . . . . . . . . . . . 12 3.2.3. Intra-Server Copy . . . . . . . . . . . . . . . . . . 12
3.2.4. Inter-Server Copy . . . . . . . . . . . . . . . . . . 14 3.2.4. Inter-Server Copy . . . . . . . . . . . . . . . . . . 14
3.2.5. Server-to-Server Copy Protocol . . . . . . . . . . . . 18 3.2.5. Server-to-Server Copy Protocol . . . . . . . . . . . . 18
3.3. Requirements for Operations . . . . . . . . . . . . . . . 19 3.3. Requirements for Operations . . . . . . . . . . . . . . . 19
3.3.1. netloc4 - Network Locations . . . . . . . . . . . . . 20 3.3.1. netloc4 - Network Locations . . . . . . . . . . . . . 20
3.3.2. Copy Offload Stateids . . . . . . . . . . . . . . . . 20 3.3.2. Copy Offload Stateids . . . . . . . . . . . . . . . . 20
3.4. Security Considerations . . . . . . . . . . . . . . . . . 21 3.4. Security Considerations . . . . . . . . . . . . . . . . . 21
3.4.1. Inter-Server Copy Security . . . . . . . . . . . . . . 21 3.4.1. Inter-Server Copy Security . . . . . . . . . . . . . . 21
4. Support for Application IO Hints . . . . . . . . . . . . . . . 23 4. Support for Application IO Hints . . . . . . . . . . . . . . . 31
5. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 31
5.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 32
5.3. New Operations . . . . . . . . . . . . . . . . . . . . . 25 5.3. New Operations . . . . . . . . . . . . . . . . . . . . . 33
5.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 25 5.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 33
5.3.2. WRITE_PLUS . . . . . . . . . . . . . . . . . . . . . . 25 5.3.2. WRITE_PLUS . . . . . . . . . . . . . . . . . . . . . . 33
6. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 26 6. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 34
7. Application Data Hole Support . . . . . . . . . . . . . . . . 28 7. Application Data Hole Support . . . . . . . . . . . . . . . . 36
7.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 29 7.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 36
7.1.1. Data Hole Representation . . . . . . . . . . . . . . . 29 7.1.1. Data Hole Representation . . . . . . . . . . . . . . . 37
7.1.2. Data Content . . . . . . . . . . . . . . . . . . . . . 30 7.1.2. Data Content . . . . . . . . . . . . . . . . . . . . . 38
7.2. An Example of Detecting Corruption . . . . . . . . . . . 30 7.2. An Example of Detecting Corruption . . . . . . . . . . . 38
7.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 31 7.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 39
8. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 33 8.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 34 8.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 41
8.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 34 8.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 42
8.3.2. Permission Checking . . . . . . . . . . . . . . . . . 35 8.3.2. Permission Checking . . . . . . . . . . . . . . . . . 42
8.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 35 8.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 43
8.3.4. Existing Objects . . . . . . . . . . . . . . . . . . . 35 8.3.4. Existing Objects . . . . . . . . . . . . . . . . . . . 43
8.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 35 8.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 43
8.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 36 8.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 44
8.5. Discovery of Server Labeled NFS Support . . . . . . . . . 36 8.5. Discovery of Server Labeled NFS Support . . . . . . . . . 44
8.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 36 8.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 44
8.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 36 8.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 44
8.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 38 8.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 46
8.7. Security Considerations . . . . . . . . . . . . . . . . . 38 8.7. Security Considerations . . . . . . . . . . . . . . . . . 46
9. Sharing change attribute implementation details with NFSv4 9. Sharing change attribute implementation details with NFSv4
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 39 9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 10. Security Considerations . . . . . . . . . . . . . . . . . . . 47
11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. Error Definitions . . . . . . . . . . . . . . . . . . . . 40 11.1. Error Definitions . . . . . . . . . . . . . . . . . . . . 48
11.1.1. General Errors . . . . . . . . . . . . . . . . . . . . 40 11.1.1. General Errors . . . . . . . . . . . . . . . . . . . . 48
11.1.2. Server to Server Copy Errors . . . . . . . . . . . . . 40 11.1.2. Server to Server Copy Errors . . . . . . . . . . . . . 48
11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . . 41 11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . . 49
11.2. New Operations and Their Valid Errors . . . . . . . . . . 41 11.2. New Operations and Their Valid Errors . . . . . . . . . . 49
11.3. New Callback Operations and Their Valid Errors . . . . . 44 11.3. New Callback Operations and Their Valid Errors . . . . . 52
12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 45 12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 53
12.1. New RECOMMENDED Attributes - List and Definition 12.1. New RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 45 References . . . . . . . . . . . . . . . . . . . . . . . 53
12.2. Attribute Definitions . . . . . . . . . . . . . . . . . . 46 12.2. Attribute Definitions . . . . . . . . . . . . . . . . . . 53
13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . . 49 13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . . 57
14. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . . 53 14. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . . 60
14.1. Operation 59: COPY - Initiate a server-side copy . . . . 53 14.1. Operation 59: COPY - Initiate a server-side copy . . . . 60
14.2. Operation 60: OFFLOAD_ABORT - Cancel a server-side 14.2. Operation 60: OFFLOAD_ABORT - Cancel a server-side
copy . . . . . . . . . . . . . . . . . . . . . . . . . . 56 copy . . . . . . . . . . . . . . . . . . . . . . . . . . 64
14.3. Operation 61: COPY_NOTIFY - Notify a source server of 14.3. Operation 61: COPY_NOTIFY - Notify a source server of
a future copy . . . . . . . . . . . . . . . . . . . . . . 57 a future copy . . . . . . . . . . . . . . . . . . . . . . 65
14.4. Operation 62: OFFLOAD_REVOKE - Revoke a destination 14.4. Operation 62: OFFLOAD_REVOKE - Revoke a destination
server's copy privileges . . . . . . . . . . . . . . . . 58 server's copy privileges . . . . . . . . . . . . . . . . 66
14.5. Operation 63: OFFLOAD_STATUS - Poll for status of a 14.5. Operation 63: OFFLOAD_STATUS - Poll for status of a
server-side copy . . . . . . . . . . . . . . . . . . . . 59 server-side copy . . . . . . . . . . . . . . . . . . . . 67
14.6. Modification to Operation 42: EXCHANGE_ID - 14.6. Modification to Operation 42: EXCHANGE_ID -
Instantiate Client ID . . . . . . . . . . . . . . . . . . 60 Instantiate Client ID . . . . . . . . . . . . . . . . . . 68
14.7. Operation 64: WRITE_PLUS . . . . . . . . . . . . . . . . 61 14.7. Operation 64: WRITE_PLUS . . . . . . . . . . . . . . . . 69
14.8. Operation 67: IO_ADVISE - Application I/O access 14.8. Operation 67: IO_ADVISE - Application I/O access
pattern hints . . . . . . . . . . . . . . . . . . . . . . 67 pattern hints . . . . . . . . . . . . . . . . . . . . . . 75
14.9. Changes to Operation 51: LAYOUTRETURN . . . . . . . . . . 72 14.9. Changes to Operation 51: LAYOUTRETURN . . . . . . . . . . 80
14.10. Operation 65: READ_PLUS . . . . . . . . . . . . . . . . . 75 14.10. Operation 65: READ_PLUS . . . . . . . . . . . . . . . . . 83
14.11. Operation 66: SEEK . . . . . . . . . . . . . . . . . . . 80 14.11. Operation 66: SEEK . . . . . . . . . . . . . . . . . . . 88
15. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 81 15. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 89
15.1. Operation 15: CB_OFFLOAD - Report results of an 15.1. Operation 15: CB_OFFLOAD - Report results of an
asynchronous operation . . . . . . . . . . . . . . . . . 81 asynchronous operation . . . . . . . . . . . . . . . . . 89
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 90
17.1. Normative References . . . . . . . . . . . . . . . . . . 83 17.1. Normative References . . . . . . . . . . . . . . . . . . 90
17.2. Informative References . . . . . . . . . . . . . . . . . 83 17.2. Informative References . . . . . . . . . . . . . . . . . 91
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 85 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 92
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 85 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 93
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction 1. Introduction
1.1. The NFS Version 4 Minor Version 2 Protocol 1.1. The NFS Version 4 Minor Version 2 Protocol
The NFS version 4 minor version 2 (NFSv4.2) protocol is the third The NFS version 4 minor version 2 (NFSv4.2) protocol is the third
minor version of the NFS version 4 (NFSv4) protocol. The first minor minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0, is described in [I-D.ietf-nfsv4-rfc3530bis] and the version, NFSv4.0, is described in [I-D.ietf-nfsv4-rfc3530bis] and the
second minor version, NFSv4.1, is described in [RFC5661]. It follows second minor version, NFSv4.1, is described in [RFC5661]. It follows
the guidelines for minor versioning that are listed in Section 11 of the guidelines for minor versioning that are listed in Section 11 of
skipping to change at page 5, line 36 skipping to change at page 5, line 36
o describe the NFSv4.0 or NFSv4.1 protocols, except where needed to o describe the NFSv4.0 or NFSv4.1 protocols, except where needed to
contrast with NFSv4.2 contrast with NFSv4.2
o modify the specification of the NFSv4.0 or NFSv4.1 protocols o modify the specification of the NFSv4.0 or NFSv4.1 protocols
o clarify the NFSv4.0 or NFSv4.1 protocols. I.e., any o clarify the NFSv4.0 or NFSv4.1 protocols. I.e., any
clarifications made here apply to NFSv4.2 and neither of the prior clarifications made here apply to NFSv4.2 and neither of the prior
protocols protocols
The full XDR for NFSv4.2 is presented in [4.2xdr]. The full XDR for NFSv4.2 is presented in [NFSv42xdr].
1.3. NFSv4.2 Goals 1.3. NFSv4.2 Goals
The goal of the design of NFSv4.2 is to take common local file system The goal of the design of NFSv4.2 is to take common local file system
features and offer them remotely. These features might features and offer them remotely. These features might
o already be available on the servers, e.g., sparse files o already be available on the servers, e.g., sparse files
o be under development as a new standard, e.g., SEEK_HOLE and o be under development as a new standard, e.g., SEEK_HOLE and
SEEK_DATA SEEK_DATA
skipping to change at page 10, line 43 skipping to change at page 10, line 43
16. A client MUST NOT attempt to use a stateid, filehandle, or 16. A client MUST NOT attempt to use a stateid, filehandle, or
similar returned object from the COMPOUND procedure with minor similar returned object from the COMPOUND procedure with minor
version X for another COMPOUND procedure with minor version Y, version X for another COMPOUND procedure with minor version Y,
where X != Y. where X != Y.
3. Server-side Copy 3. Server-side Copy
3.1. Introduction 3.1. Introduction
The server-side copy feature provides a mechanism for the NFS client The server-side copy feature provides a mechanism for the NFS client
to perform a file copy on the server without the data being to perform a file copy on a server or between two servers without the
transmitted back and forth over the network. Without this feature, data being transmitted back and forth over the network through the
an NFS client copies data from one location to another by reading the NFS client. Without this feature, an NFS client copies data from one
data from the server over the network, and then writing the data back location to another by reading the data from the source server over
over the network to the server. Using this server-side copy the network, and then writing the data back over the network to the
operation, the client is able to instruct the server to copy the data destiniation server.
locally without the data being sent back and forth over the network
unnecessarily.
If the source object and destination object are on different file If the source object and destination object are on different file
servers, the file servers will communicate with one another to servers, the file servers will communicate with one another to
perform the copy operation. The server-to-server protocol by which perform the copy operation. The server-to-server protocol by which
this is accomplished is not defined in this document. this is accomplished is not defined in this document.
3.2. Protocol Overview 3.2. Protocol Overview
The server-side copy offload operations support both intra-server and The server-side copy offload operations support both intra-server and
inter-server file copies. An intra-server copy is a copy in which inter-server file copies. An intra-server copy is a copy in which
skipping to change at page 18, line 16 skipping to change at page 18, line 16
The source server and destination server are not required to use a The source server and destination server are not required to use a
specific protocol to transfer the file data. The choice of what specific protocol to transfer the file data. The choice of what
protocol to use is ultimately the destination server's decision. protocol to use is ultimately the destination server's decision.
3.2.5.1. Using NFSv4.x as a Server-to-Server Copy Protocol 3.2.5.1. Using NFSv4.x as a Server-to-Server Copy Protocol
The destination server MAY use standard NFSv4.x (where x >= 1) The destination server MAY use standard NFSv4.x (where x >= 1)
operations to read the data from the source server. If NFSv4.x is operations to read the data from the source server. If NFSv4.x is
used for the server-to-server copy protocol, the destination server used for the server-to-server copy protocol, the destination server
can use the source filehandle provided in the COPY request with can use the source filehandle and ca_src_stateid provided in the COPY
standard NFSv4.x operations to read data from the source server. request with standard NFSv4.x operations to read data from the source
Specifically, the destination server may use the NFSv4.x OPEN server.
operation's CLAIM_FH facility to open the file being copied and
obtain an open stateid. Using the stateid, the destination server
may then use NFSv4.x READ operations to read the file.
3.2.5.2. Using an alternative Server-to-Server Copy Protocol 3.2.5.2. Using an alternative Server-to-Server Copy Protocol
In a homogeneous environment, the source and destination servers In a homogeneous environment, the source and destination servers
might be able to perform the file copy extremely efficiently using might be able to perform the file copy extremely efficiently using
specialized protocols. For example the source and destination specialized protocols. For example the source and destination
servers might be two nodes sharing a common file system format for servers might be two nodes sharing a common file system format for
the source and destination file systems. Thus the source and the source and destination file systems. Thus the source and
destination are in an ideal position to efficiently render the image destination are in an ideal position to efficiently render the image
of the source file to the destination file by replicating the file of the source file to the destination file by replicating the file
skipping to change at page 19, line 15 skipping to change at page 19, line 12
destination server receives the source server's URL, it would use destination server receives the source server's URL, it would use
"_FH/0x12345" as the file name to pass to the FTP server listening on "_FH/0x12345" as the file name to pass to the FTP server listening on
port 9999 of s1.example.com. On port 9999 there would be a special port 9999 of s1.example.com. On port 9999 there would be a special
instance of the FTP service that understands how to convert NFS instance of the FTP service that understands how to convert NFS
filehandles to an open file descriptor (in many operating systems, filehandles to an open file descriptor (in many operating systems,
this would require a new system call, one which is the inverse of the this would require a new system call, one which is the inverse of the
makefh() function that the pre-NFSv4 MOUNT service needs). makefh() function that the pre-NFSv4 MOUNT service needs).
Authenticating and identifying the destination server to the source Authenticating and identifying the destination server to the source
server is also a challenge. Recommendations for how to accomplish server is also a challenge. Recommendations for how to accomplish
this are given in Section 3.4.1.3. this are given in Section 3.4.1.4.
3.3. Requirements for Operations 3.3. Requirements for Operations
The implementation of server-side copy is OPTIONAL by the client and The implementation of server-side copy is OPTIONAL by the client and
the server. However, in order to successfully copy a file, some the server. However, in order to successfully copy a file, some
operations MUST be supported by the client and/or server. operations MUST be supported by the client and/or server.
If a client desires an intra-server file copy, then it MUST support If a client desires an intra-server file copy, then it MUST support
the COPY and CB_OFFLOAD operations. If COPY returns a stateid, then the COPY and CB_OFFLOAD operations. If COPY returns a stateid, then
the client MAY use the OFFLOAD_ABORT and OFFLOAD_STATUS operations. the client MAY use the OFFLOAD_ABORT and OFFLOAD_STATUS operations.
skipping to change at page 21, line 23 skipping to change at page 21, line 20
The security considerations pertaining to NFSv4 The security considerations pertaining to NFSv4
[I-D.ietf-nfsv4-rfc3530bis] apply to this chapter. [I-D.ietf-nfsv4-rfc3530bis] apply to this chapter.
The standard security mechanisms provide by NFSv4 The standard security mechanisms provide by NFSv4
[I-D.ietf-nfsv4-rfc3530bis] may be used to secure the protocol [I-D.ietf-nfsv4-rfc3530bis] may be used to secure the protocol
described in this chapter. described in this chapter.
NFSv4 clients and servers supporting the inter-server copy operations NFSv4 clients and servers supporting the inter-server copy operations
described in this chapter are REQUIRED to implement the mechanism described in this chapter are REQUIRED to implement the mechanism
described in Section 3.4.1.2, and to support rejecting COPY_NOTIFY described in Section 3.4.1.2, and to support rejecting COPY_NOTIFY
requests that do not use RPCSEC_GSS with privacy. This requirement requests that do not use RPCSEC_GSS with privacy. If the server-to-
to implement is not a requirement to use; for example, a server may server copy protocol is ONC RPC based, the servers are also REQUIRED
depending on configuration also allow COPY_NOTIFY requests that use to implement [rpcsec_gssv3] including the RPCSEC_GSSv3 copy_to_auth,
only AUTH_SYS. copy_from_auth, and copy_confirm_auth structured privileges. This
requirement to implement is not a requirement to use; for example, a
server may depending on configuration also allow COPY_NOTIFY requests
that use only AUTH_SYS.
3.4.1. Inter-Server Copy Security 3.4.1. Inter-Server Copy Security
3.4.1.1. Requirements for Secure Inter-Server Copy 3.4.1.1. Requirements for Secure Inter-Server Copy
Inter-server copy is driven by several requirements: Inter-server copy is driven by several requirements:
o The specification must not mandate an inter-server copy protocol. o The specification must not mandate an inter-server copy protocol.
There are many ways to copy data. Some will be more optimal than There are many ways to copy data. Some will be more optimal than
others depending on the identities of the source server and others depending on the identities of the source server and
skipping to change at page 22, line 17 skipping to change at page 22, line 17
destination first have a "copying relationship" increases the destination first have a "copying relationship" increases the
administrative burden. However the specification MUST NOT administrative burden. However the specification MUST NOT
preclude implementations that require pre-configuration. preclude implementations that require pre-configuration.
o The specification must not mandate a trust relationship between o The specification must not mandate a trust relationship between
the source and destination server. The NFSv4 security model the source and destination server. The NFSv4 security model
requires mutual authentication between a principal on an NFS requires mutual authentication between a principal on an NFS
client and a principal on an NFS server. This model MUST continue client and a principal on an NFS server. This model MUST continue
with the introduction of COPY. with the introduction of COPY.
3.4.1.2. Inter-Server Copy via ONC RPC 3.4.1.2. Inter-Server Copy via ONC RPC with RPCSEC_GSSv3
When the client sends a COPY_NOTIFY to the source server to expect
the destination to attempt to copy data from the source server, it is
expected that this copy is being done on behalf of the principal
(called the "user principal") that sent the RPC request that encloses
the COMPOUND procedure that contains the COPY_NOTIFY operation. The
user principal is identified by the RPC credentials. A mechanism
that allows the user principal to authorize the destination server to
perform the copy, that lets the source server properly authenticate
the destination's copy, and does not allow the destination server to
exceed this authorization, is necessary.
An approach that sends delegated credentials of the client's user
principal to the destination server is not used for the following
reason. If the client's user delegated its credentials, the
destination would authenticate as the user principal. If the
destination were using the NFSv4 protocol to perform the copy, then
the source server would authenticate the destination server as the
user principal, and the file copy would securely proceed. However,
this approach would allow the destination server to copy other files.
The user principal would have to trust the destination server to not
do so. This is counter to the requirements, and therefore is not
considered.
Instead, we employ a combination of two features of the RPCSEC_GSSv3
[rpcsec_gssv3] protocol: compound authentication and RPC application
defined structured privilege assertions. The combination of these
features allows the destination server to authenticate to the source
server as acting on behalf of the user prinicpal, and to authorize
the destination server to perform READs of the file to be copied from
the source on behalf of the user principal. Once the copy is
complete, the client can destroy the RPCSEC_GSSv3 handles to end the
source and destination servers authorization to copy.
RPCSEC_GSSv3 introduces the notion of RPC application defined
structured privileges. We define three structured privileges that
work in tandum to authorize the copy:
copy_from_auth: A user principal is authorizing a source principal
("nfs@<source>") to allow a destination principal ("nfs@
<destination>") to setup the copy_confirm_auth privilege required
to copy a file from the source to the destination on behalf of the
user principal. This privilege is established on the source
server before the user principal sends a COPY_NOTIFY operation to
the source server, and the resultant RPCSEC_GSSv3 context is used
to secure the COPY_NOTIFY operation.
struct copy_from_auth_priv {
secret4 cfap_shared_secret;
netloc4 cfap_destination;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed cfap_username;
};
cfp_shared_secret is an automatically generated random number
secret value.
copy_to_auth: A user principal is authorizing a destination
principal ("nfs@<destination>") to setup a copy_confirm_auth
privilege with a source principal ("nfs@<source>") to allow it to
copy a file from the source to the destination on behalf of the
user principal. This privilege is established on the destination
server before the user principal sends a COPY operation to the
destination server, and the resultant RPCSEC_GSSv3 context is used
to secure the COPY operation.
struct copy_to_auth_priv {
/* equal to cfap_shared_secret */
secret4 ctap_shared_secret;
netloc4 ctap_source;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ctap_username;
/*
* user principal RPCSEC_GSSv1 (or v2) handle shared
* with the source server
*/
opaque ctap_handle;
int ctap_handle_vers;
/* A nounce and a mic of the nounce using ctap_handle */
opaque ctap_nounce;
opaque ctap_nounce_mic;
};
ctap_shared_secret is the automatically generated secret value
used to establish the copy_from_auth privilege with the source
principal. ctap_handle, ctap_handle_vers, ctap_nounce and
ctap_nounce_mic are used to construct the compound authentication
portion of the copy_confirm_auth RPCGSS_GSSv3 context between the
destination server and the source server. See Section 3.4.1.2.1
copy_confirm_auth: A destination principal ("nfs@<destination>") is
confirming with the source principal ("nfs@<source>") that it is
authorized to copy data from the source. Note that besides the
rpc_gss3_privs payload (struct copy_confirm_auth_priv), the
copy_confirm_auth RPCSEC_GSS3_CREATE message also contains an
rpc_gss3_gss_binding payload so that the copy is done on behalf of
the user principal. This privilege is established on the
destination server before the file is copied from the source to
the destination. The resultant RPCSEC_GSSv3 context is used to
secure the READ operations from the source to the destination
server.
struct copy_confirm_auth_priv {
/* equal to GSS_GetMIC() of cfap_shared_secret */
opaque ccap_shared_secret_mic<>;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ccap_username;
};
3.4.1.2.1. Establishing a Security Context
The RPCSEC_GSSv3 compound authentication feature allows a server to
act on behalf of a user if the server identifies the user and trusts
the client. In the inter-server server side copy case, the server is
the source server, and the client is the destination server acting as
a client when performing the copy.
The user principal is not required (nor expected) to have an
RPCSEC_GSS secured connection and context between the destination
server (acting as a client) and the source server. The user
principal does have an RPCSEC_GSS secured connection and context
between the client and the source server established for the OPEN of
the file to be copied.
We use the RPCSEC_GSS context established between the user principal
and the source server to OPEN the file to be copied to provide the
the necessary user principal identification to the source server from
the destination server (acting as a client). This is accomplished by
sending the user principal indentification information: e.g the
rpc_gss3_gss_binding fields, in the copy_to_auth privilege
established between the client and the destination server. This same
information is then placed in the rpc_gss3_gss_binding fields of the
copy_confirm_auth RPCSEC_GSS3_CREATE message sent from the
destination server (acting as a client) to the source server.
When the user principal wants to COPY a file between two servers, if
it has not established copy_from_auth and copy_to_auth privileges on
the servers, it establishes them:
o As noted in [rpcsec_gssv3] the client uses an existing
RPCSEC_GSSv1 (or v2) context termed the "parent" handle to
establish and protect RPCSEC_GSSv3 exchanges. The copy_from_auth
privilege will use the context established between the user
principal and the source server used to OPEN the source file as
the RPCSEC_GSSv3 parent handle. The copy_to_auth privilege will
use the context established between the user principal and the
destination server used to OPEN the destination file as the
RPCSEC_GSSv3 parent handle.
o A random number is generated to use as a secret to be shared
between the two servers. This shared secret will be placed in the
cfap_shared_secret and ctap_shared_secret fields of the
appropriate privilege data types, copy_from_auth_priv and
copy_to_auth_priv. Because of this shared_secret the
RPCSEC_GSS3_CREATE control messages for copy_from_auth and
copy_to_auth MUST use a QOP of rpc_gss_svc_privacy.
o An instance of copy_from_auth_priv is filled in with the shared
secret, the destination server, and the NFSv4 user id of the user
principal and is placed in rpc_gss3_create_args
assertions[0].assertion.privs.privilege. The string
"copy_from_auth" is placed in assertions[0].assertion.privs.name.
The field assertions[0].critical is set to TRUE. The source
server unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload
and verifies that the NFSv4 user id being asserted matches the
source server's mapping of the user principal. If it does, the
privilege is established on the source server as:
<"copy_from_auth", user id, destination>. The field "handle" in a
successful reply is the RPCSEC_GSSv3 "child" handle that the
client will use on COPY_NOTIFY requests to the source server
involving the destination server.
granted_assertions[0].assertion.privs.name will be equal to
"copy_from_auth".
o An instance of copy_to_auth_priv is filled in with the shared
secret, the cnr_source_server list returned by COPY_NOTIFY, and
the NFSv4 user id of the user principal. The next four fields are
passed in the copy_to_auth privilege to be used by the
copy_confirm_auth rpc_gss3_gss_binding fields as explained above.
A nounce is created, and GSS_MIC() is invoked on the nounce using
the RPCSEC_GSSv1 (or v2) context shared between user prinicpal and
the source server. The nounce, nounce MIC, context handle used to
create the nounce MIC, and the context handle version are added to
the copy_to_auth_priv instance which is placed in
rpc_gss3_create_args assertions[0].assertion.privs.privilege. The
string "copy_to_auth" is placed in
assertions[0].assertion.privs.name. The field
assertions[0].critical is set to TRUE. The destination server
unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload and
verifies that the NFSv4 user id being asserted matches the
destination server's mapping of the user principal. If it does,
the privilege is established on the destination server as:
<"copy_to_auth", user id, source list, nounce, nounce MIC, context
handle, handle version>. The field "handle" in a successful reply
is the RPCSEC_GSSv3 "child" handle that the client will use on
COPY requests to the destination server involving the source
server. granted_assertions[0].assertion.privs.name will be equal
to "copy_to_auth".
As noted in [rpcsec_gssv3] section 2.3.1 "Create Request", both the
client and the source server should associate the RPCSEC_GSSv3
"child" handle with the parent RPCSEC_GSSv1 (or v2) handle used to
create the RPCSEC_GSSv3 child handle.
3.4.1.2.2. Starting a Secure Inter-Server Copy
When the client sends a COPY_NOTIFY request to the source server, it
uses the privileged "copy_from_auth" RPCSEC_GSSv3 handle.
cna_destination_server in COPY_NOTIFY MUST be the same as
cfap_destination specified in copy_from_auth_priv. Otherwise,
COPY_NOTIFY will fail with NFS4ERR_ACCESS. The source server
verifies that the privilege <"copy_from_auth", user id, destination>
exists, and annotates it with the source filehandle, if the user
principal has read access to the source file, and if administrative
policies give the user principal and the NFS client read access to
the source file (i.e., if the ACCESS operation would grant read
access). Otherwise, COPY_NOTIFY will fail with NFS4ERR_ACCESS.
When the client sends a COPY request to the destination server, it
uses the privileged "copy_to_auth" RPCSEC_GSSv3 handle.
ca_source_server list in COPY MUST be the same as ctap_source list
specified in copy_to_auth_priv. Otherwise, COPY will fail with
NFS4ERR_ACCESS. The destination server verifies that the privilege
<"copy_to_auth", user id, source list, nounce, nounce MIC, context
handle, handle version> exists, and annotates it with the source and
destination filehandles. If the COPY returns a wr_callback_id, then
this is an asynchronous copy and the wr_callback_id must also must be
annotated to the copy_to_auth privilege. If the client has failed to
establish the "copy_to_auth" privilege it will reject the request
with NFS4ERR_PARTNER_NO_AUTH.
If either the COPY_NOTIFY, or the COPY operations fail, the
associated "copy_from_auth" and "copy_to_auth" RPCSEC_GSSv3 handles
MUST be destroyed.
3.4.1.2.3. Securing ONC RPC Server-to-Server Copy Protocols
After a destination server has a "copy_to_auth" privilege established
on it, and it receives a COPY request, if it knows it will use an ONC
RPC protocol to copy data, it will establish a "copy_confirm_auth"
privilege on the source server prior to responding to the COPY
operation as follows:
o Before establishing an RPCSEC_GSSv3 context, a parent context
needs to exist between nfs@<destination> as the initiator
principal, and nfs@<source> as the target principal. If NFS is to
be used as the copy protocol, this means that the destiniation
server must mount the source server using RPCSEC_GSS.
o An instance of copy_confirm_auth_priv is filled in with
information from the established "copy_to_auth" privilege. The
value of the field ccap_shared_secret_mic is a GSS_GetMIC() of the
ctap_shared_secret in the copy_to_auth privilege using the parent
handle context. The field ccap_username is the mapping of the
user principal to an NFSv4 user name ("user"@"domain" form), and
MUST be the same as the ctap_username in the copy_to_auth
privilege. The copy_confirm_auth_priv instance is placed in
rpc_gss3_create_args assertions[0].assertion.privs.privilege. The
string "copy_confirm_auth" is placed in
assertions[0].assertion.privs.name. The field
assertions[0].critical is set to TRUE.
o The copy_confirm_auth RPCSEC_GSS3_CREATE call also includes a
compound authentication component. The rpc_gss3_gss_binding
fields are filled in with information from the estalished
"copy_to_auth" privilege (see Section 3.4.1.2.1). The
ctap_handle_vers, ctap_handle, ctap_nounce, and ctap_nounce_mic
are assigned to the vers, handle, nounce, and mic fields of an
rpc_gss3_gss_binding instance respectively.
o The RPCSEC_GSS3_CREATE copy_from_auth message is sent to the
source server with a QOP of rpc_gss_svc_privacy. The source
server unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload
and verifies the cap_shared_secret_mic by calling GSS_VerifyMIC()
using the parent context on the cfap_shared_secret from the
established "copy_from_auth" privilege, and verifies the that the
ccap_username equals the cfap_username. The source server then
locates the ctap_handle in it's GSS context cache and verifies
that the handle belongs to the user principal that maps to the
ccap_username and that the cached handle version equals
ctap_handle_vers. The ctap_nounce_mic is verified by calling
GSS_VerifyMIC() on the ctap_nounce using the cached handle
context. If all verification succeeds, the "copy_confirm_auth"
privilege is established on the source server as <
"copy_confirm_auth", shared_secret_mic, user id, nounce, nounce
MIC, context handle, context handle version>, and the resultant
child handle is noted to be acting on behalf of the user
principal. If the source server fails to verify either the
privilege or the compound_binding, the COPY operation will be
rejected with NFS4ERR_PARTNER_NO_AUTH.
o All subsequent ONC RPC requests sent from the destination to copy
data from the source to the destination will use the RPCSEC_GSSv3
handle returned by the source's RPCSEC_GSS3_CREATE response. Note
that as per the Compound Authenticaion section of [rpcsec_gssv3]
the resultant RPCSEC_GSSv3 context handle is bound to the user
principal RPCSEC_GSS context and so it MUST be treated by servers
as authenticating the user principal.
Note that the use of the "copy_confirm_auth" privilege accomplishes
the following:
o If a protocol like NFS is being used, with export policies, export
policies can be overridden in case the destination server as-an-
NFS-client is not authorized
o Manual configuration to allow a copy relationship between the
source and destination is not needed.
3.4.1.2.4. Finishing or Stoping a Secure Inter-Server Copy
Under normal operation, the client MUST destroy the copy_from_auth
and the copy_to_auth RPCSEC_GSSv3 handle once the COPY operation
returns for a synchronous inter-server copy or a CB_OFFLOAD reports
the result of an asynchronous copy.
The copy_confirm_auth privilege and compound authentication
RPCSEC_GSSv3 handle is constructed from information held by the
copy_to_auth privilege, and MUST be destroyed by the destination
server (via an RPCSEC_GSS3_DESTROY call) when the copy_to_auth
RPCSEC_GSSv3 handle is destroyed.
If the client sends a OFFLOAD_REVOKE to the source server to rescind
the destination server's synchronous copy privilege, it uses the
privileged "copy_from_auth" RPCSEC_GSSv3 handle and the
cra_destination_server in OFFLOAD_REVOKE MUST be the same as the name
of the destination server specified in copy_from_auth_priv. The
source server will then delete the <"copy_from_auth", user id,
destination> privilege and fail any subsequent copy requests sent
under the auspices of this privilege from the destination server.
The client MUST destroy both the "copy_from_auth" and the
"copy_to_auth" RPCSEC_GSSv3 handles.
If the client sends a OFFLOAD_STATUS to the destination server to
check on the status of an asynchronous copy, it uses the privileged
"copy_to_auth" RPCSEC_GSSv3 handle and the osa_stateid in
OFFLOAD_STATUS MUST be the same as the wr_callback_id specified in
the "copy_to_auth" privilege stored on the destiniation server.
If the client sends a OFFLOAD_ABORT to the destination server to
cancel an asynchronous copy, it uses the privileged "copy_to_auth"
RPCSEC_GSSv3 handle and the oaa_stateid in OFFLOAD_ABORT MUST be the
same as the wr_callback_id specified in the "copy_to_auth" privilege
stored on the destiniation server. The destiniation server will then
delete the <"copy_to_auth", user id, source list, nounce, nounce MIC,
context handle, handle version> privilege and the associated
"copy_confirm_auth" RPCSEC_GSSv3 handle. The client MUST destroy
both the copy_to_auth and copy_from_auth RPCSEC_GSSv3 handles.
3.4.1.3. Inter-Server Copy via ONC RPC without RPCSEC_GSS
ONC RPC security flavors other than RPCSEC_GSS MAY be used with the
server-side copy offload operations described in this chapter. In
particular, host-based ONC RPC security flavors such as AUTH_NONE and
AUTH_SYS MAY be used. If a host-based security flavor is used, a
minimal level of protection for the server-to-server copy protocol is
possible.
In the absence of a strong security mechanism designed for the In the absence of a strong security mechanism designed for the
purpose, the challenge is how the source server and destination purpose, the challenge is how the source server and destination
server identify themselves to each other, especially in the presence server identify themselves to each other, especially in the presence
of multi-homed source and destination servers. In a multi-homed of multi-homed source and destination servers. In a multi-homed
environment, the destination server might not contact the source environment, the destination server might not contact the source
server from the same network address specified by the client in the server from the same network address specified by the client in the
COPY_NOTIFY. This can be overcome using the procedure described COPY_NOTIFY. This can be overcome using the procedure described
below. below.
skipping to change at page 23, line 29 skipping to change at page 31, line 24
cannot defend against man-in-the-middle attacks after authentication cannot defend against man-in-the-middle attacks after authentication
or an eavesdropper that observes the random number on the wire. or an eavesdropper that observes the random number on the wire.
Other secure communication techniques (e.g., IPsec) are necessary to Other secure communication techniques (e.g., IPsec) are necessary to
block these attacks. block these attacks.
Servers SHOULD reject COPY_NOTIFY requests that do not use RPCSEC_GSS Servers SHOULD reject COPY_NOTIFY requests that do not use RPCSEC_GSS
with privacy, thus ensuring the URL in the COPY_NOTIFY reply is with privacy, thus ensuring the URL in the COPY_NOTIFY reply is
encrypted. For the same reason, clients SHOULD send COPY requests to encrypted. For the same reason, clients SHOULD send COPY requests to
the destination using RPCSEC_GSS with privacy. the destination using RPCSEC_GSS with privacy.
3.4.1.3. Inter-Server Copy without ONC RPC 3.4.1.4. Inter-Server Copy without ONC RPC
The same techniques as Section 3.4.1.2, using unique URLs for each The same techniques as Section 3.4.1.3, using unique URLs for each
destination server, can be used for other protocols (e.g., HTTP destination server, can be used for other protocols (e.g., HTTP
[RFC2616] and FTP [RFC0959]) as well. [RFC2616] and FTP [RFC0959]) as well.
4. Support for Application IO Hints 4. Support for Application IO Hints
Applications can issue client I/O hints via posix_fadvise() Applications can issue client I/O hints via posix_fadvise()
[posix_fadvise] to the NFS client. While this can help the NFS [posix_fadvise] to the NFS client. While this can help the NFS
client optimize I/O and caching for a file, it does not allow the NFS client optimize I/O and caching for a file, it does not allow the NFS
server and its exported file system to do likewise. We add an server and its exported file system to do likewise. We add an
IO_ADVISE procedure (Section 14.8) to communicate the client file IO_ADVISE procedure (Section 14.8) to communicate the client file
skipping to change at page 26, line 4 skipping to change at page 33, line 44
server can only send back bytes starting from that offset. In server can only send back bytes starting from that offset. In
contrast, if a READ_PLUS occurs in the middle of a hole or ADH, the contrast, if a READ_PLUS occurs in the middle of a hole or ADH, the
server can send back a range which starts before the offset and server can send back a range which starts before the offset and
extends past the range. extends past the range.
5.3.2. WRITE_PLUS 5.3.2. WRITE_PLUS
WRITE_PLUS can be used to either hole punch or initialize ADHs. For WRITE_PLUS can be used to either hole punch or initialize ADHs. For
either purpose, the client can avoid the transfer of a repetitive either purpose, the client can avoid the transfer of a repetitive
pattern across the network. If the filesystem on the server does not pattern across the network. If the filesystem on the server does not
supports sparse files, the WRITE_PLUS operation may return the result support sparse files, the WRITE_PLUS operation may return the result
asynchronously via the CB_OFFLOAD operation. As a hole punch may asynchronously via the CB_OFFLOAD operation. As a hole punch may
entail deallocating data blocks, even if the filesystem supports entail deallocating data blocks, even if the filesystem supports
sparse files, it may still have to return the result via CB_OFFLOAD. sparse files, it may still have to return the result via CB_OFFLOAD.
6. Space Reservation 6. Space Reservation
6.1. Introduction 6.1. Introduction
Applications such as hypervisors want to be able to reserve space for Applications such as hypervisors want to be able to reserve space for
a file, report the amount of actual disk space a file occupies, and a file, report the amount of actual disk space a file occupies, and
free-up the backing space of a file when it is not required. In free-up the backing space of a file when it is not required. In
virtualized environments, virtual disk files are often stored on NFS virtualized environments, virtual disk files are often stored on NFS
mounted volumes. Since virtual disk files represent the hard disks mounted volumes. Since virtual disk files represent the hard disks
of virtual machines, hypervisors often have to guarantee certain of virtual machines, hypervisors often have to guarantee certain
properties for the file. properties for the file.
skipping to change at page 40, line 15 skipping to change at page 48, line 9
number of NFS operations that have their results encoded in sequence number of NFS operations that have their results encoded in sequence
in a Compound reply. The results of successful operations will in a Compound reply. The results of successful operations will
consist of an NFS4_OK status followed by the encoded results of the consist of an NFS4_OK status followed by the encoded results of the
operation. If an NFS operation fails, an error status will be operation. If an NFS operation fails, an error status will be
entered in the reply and the Compound request will be terminated. entered in the reply and the Compound request will be terminated.
11.1. Error Definitions 11.1. Error Definitions
Protocol Error Definitions Protocol Error Definitions
+--------------------------+--------+------------------+ +-------------------------+--------+------------------+
| Error | Number | Description | | Error | Number | Description |
+--------------------------+--------+------------------+ +-------------------------+--------+------------------+
| NFS4ERR_BADLABEL | 10093 | Section 11.1.3.1 | | NFS4ERR_BADLABEL | 10093 | Section 11.1.3.1 |
| NFS4ERR_METADATA_NOTSUPP | 10090 | Section 11.1.2.1 | | NFS4ERR_OFFLOAD_DENIED | 10091 | Section 11.1.2.1 |
| NFS4ERR_OFFLOAD_DENIED | 10091 | Section 11.1.2.2 | | NFS4ERR_PARTNER_NO_AUTH | 10089 | Section 11.1.2.2 |
| NFS4ERR_PARTNER_NO_AUTH | 10089 | Section 11.1.2.3 | | NFS4ERR_PARTNER_NOTSUPP | 10088 | Section 11.1.2.3 |
| NFS4ERR_PARTNER_NOTSUPP | 10088 | Section 11.1.2.4 | | NFS4ERR_UNION_NOTSUPP | 10090 | Section 11.1.1.1 |
| NFS4ERR_UNION_NOTSUPP | 10094 | Section 11.1.1.1 | | NFS4ERR_WRONG_LFS | 10092 | Section 11.1.3.2 |
| NFS4ERR_WRONG_LFS | 10092 | Section 11.1.3.2 | +-------------------------+--------+------------------+
+--------------------------+--------+------------------+
Table 1 Table 1
11.1.1. General Errors 11.1.1. General Errors
This section deals with errors that are applicable to a broad set of This section deals with errors that are applicable to a broad set of
different purposes. different purposes.
11.1.1.1. NFS4ERR_UNION_NOTSUPP (Error Code 10094) 11.1.1.1. NFS4ERR_UNION_NOTSUPP (Error Code 10090)
One of the arguments to the operation is a discriminated union and One of the arguments to the operation is a discriminated union and
while the server supports the given operation, it does not support while the server supports the given operation, it does not support
the selected arm of the discriminated union. For an example, see the selected arm of the discriminated union. For an example, see
READ_PLUS (Section 14.10). WRITE_PLUS (Section 14.7).
11.1.2. Server to Server Copy Errors 11.1.2. Server to Server Copy Errors
These errors deal with the interaction between server to server These errors deal with the interaction between server to server
copies. copies.
11.1.2.1. NFS4ERR_METADATA_NOTSUPP (Error Code 10090) 11.1.2.1. NFS4ERR_OFFLOAD_DENIED (Error Code 10091)
The destination file cannot support the same metadata as the source
file.
11.1.2.2. NFS4ERR_OFFLOAD_DENIED (Error Code 10091)
The copy offload operation is supported by both the source and the The copy offload operation is supported by both the source and the
destination, but the destination is not allowing it for this file. destination, but the destination is not allowing it for this file.
If the client sees this error, it should fall back to the normal copy If the client sees this error, it should fall back to the normal copy
semantics. semantics.
11.1.2.3. NFS4ERR_PARTNER_NO_AUTH (Error Code 10089) 11.1.2.2. NFS4ERR_PARTNER_NO_AUTH (Error Code 10089)
The source server does not authorize a server-to-server copy offload The source server does not authorize a server-to-server copy offload
operation. This may be due to the client's failure to send the operation. This may be due to the client's failure to send the
COPY_NOTIFY operation to the source server, the source server COPY_NOTIFY operation to the source server, the source server
receiving a server-to-server copy offload request after the copy receiving a server-to-server copy offload request after the copy
lease time expired, or for some other permission problem. lease time expired, or for some other permission problem.
11.1.2.4. NFS4ERR_PARTNER_NOTSUPP (Error Code 10088) 11.1.2.3. NFS4ERR_PARTNER_NOTSUPP (Error Code 10088)
The remote server does not support the server-to-server copy offload The remote server does not support the server-to-server copy offload
protocol. protocol.
11.1.3. Labeled NFS Errors 11.1.3. Labeled NFS Errors
These errors are used in Labeled NFS. These errors are used in Labeled NFS.
11.1.3.1. NFS4ERR_BADLABEL (Error Code 10093) 11.1.3.1. NFS4ERR_BADLABEL (Error Code 10093)
skipping to change at page 43, line 29 skipping to change at page 51, line 24
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_IO, NFS4ERR_LOCKED, | | | NFS4ERR_ISDIR, NFS4ERR_IO, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, | | | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_UNION_NOTSUPP, NFS4ERR_WRONG_TYPE | | | NFS4ERR_WRONG_TYPE |
| SEEK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | SEEK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_IO, NFS4ERR_LOCKED, | | | NFS4ERR_ISDIR, NFS4ERR_IO, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, | | | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, |
skipping to change at page 45, line 29 skipping to change at page 53, line 15
12. New File Attributes 12. New File Attributes
12.1. New RECOMMENDED Attributes - List and Definition References 12.1. New RECOMMENDED Attributes - List and Definition References
The list of new RECOMMENDED attributes appears in Table 4. The The list of new RECOMMENDED attributes appears in Table 4. The
meaning of the columns of the table are: meaning of the columns of the table are:
Name: The name of the attribute. Name: The name of the attribute.
Id: The number assigned to the attribute. In the event of conflicts Id: The number assigned to the attribute. In the event of conflicts
between the assigned number and [4.2xdr], the latter is likely between the assigned number and [NFSv42xdr], the latter is likely
authoritative, but should be resolved with Errata to this document authoritative, but should be resolved with Errata to this document
and/or [4.2xdr]. See [IESG08] for the Errata process. and/or [NFSv42xdr]. See [IESG08] for the Errata process.
Data Type: The XDR data type of the attribute. Data Type: The XDR data type of the attribute.
Acc: Access allowed to the attribute. Acc: Access allowed to the attribute.
R means read-only (GETATTR may retrieve, SETATTR may not set). R means read-only (GETATTR may retrieve, SETATTR may not set).
W means write-only (SETATTR may set, GETATTR may not retrieve). W means write-only (SETATTR may set, GETATTR may not retrieve).
R W means read/write (GETATTR may retrieve, SETATTR may set). R W means read/write (GETATTR may retrieve, SETATTR may set).
skipping to change at page 56, line 6 skipping to change at page 63, line 50
If an immediate failure does occur, cr_bytes_copied will be set to If an immediate failure does occur, cr_bytes_copied will be set to
the number of bytes copied to the destination file before the error the number of bytes copied to the destination file before the error
occurred. The cr_bytes_copied value indicates the number of bytes occurred. The cr_bytes_copied value indicates the number of bytes
copied but not which specific bytes have been copied. copied but not which specific bytes have been copied.
A return of NFS4_OK indicates that either the operation is complete A return of NFS4_OK indicates that either the operation is complete
or the operation was initiated and a callback will be used to deliver or the operation was initiated and a callback will be used to deliver
the final status of the operation. the final status of the operation.
If the cr_callback_id is returned, this indicates that the operation If the wr_callback_id is returned, this indicates that the operation
was initiated and a CB_OFFLOAD callback will deliver the final was initiated and a CB_OFFLOAD callback will deliver the final
results of the operation. The cr_callback_id stateid is termed a results of the operation. The wr_callback_id stateid is termed a
copy stateid in this context. The server is given the option of copy stateid in this context. The server is given the option of
returning the results in a callback because the data may require a returning the results in a callback because the data may require a
relatively long period of time to copy. relatively long period of time to copy.
If no cr_callback_id is returned, the operation completed If no wr_callback_id is returned, the operation completed
synchronously and no callback will be issued by the server. The synchronously and no callback will be issued by the server. The
completion status of the operation is indicated by cr_status. completion status of the operation is indicated by cr_status.
If the copy completes successfully, either synchronously or If the copy completes successfully, either synchronously or
asynchronously, the data copied from the source file to the asynchronously, the data copied from the source file to the
destination file MUST appear identical to the NFS client. However, destination file MUST appear identical to the NFS client. However,
the NFS server's on disk representation of the data in the source the NFS server's on disk representation of the data in the source
file and destination file MAY differ. For example, the NFS server file and destination file MAY differ. For example, the NFS server
might encrypt, compress, deduplicate, or otherwise represent the on might encrypt, compress, deduplicate, or otherwise represent the on
disk data in the source and destination file differently. disk data in the source and destination file differently.
skipping to change at page 62, line 33 skipping to change at page 70, line 33
case NFS4_CONTENT_HOLE: case NFS4_CONTENT_HOLE:
data_info4 wpa_hole; data_info4 wpa_hole;
default: default:
void; void;
}; };
struct WRITE_PLUS4args { struct WRITE_PLUS4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
stateid4 wp_stateid; stateid4 wp_stateid;
stable_how4 wp_stable; stable_how4 wp_stable;
write_plus_arg4 wp_data<>; write_plus_arg4 wp_data;
}; };
14.7.2. RESULT 14.7.2. RESULT
struct write_response4 { struct write_response4 {
stateid4 wr_callback_id<1>; stateid4 wr_callback_id<1>;
count4 wr_count; count4 wr_count;
stable_how4 wr_committed; stable_how4 wr_committed;
verifier4 wr_writeverf; verifier4 wr_writeverf;
}; };
union WRITE_PLUS4res switch (nfsstat4 wp_status) { union WRITE_PLUS4res switch (nfsstat4 wp_status) {
case NFS4_OK: case NFS4_OK:
write_response4 wp_resok4; write_response4 wp_resok4;
default: default:
void; void;
}; };
14.7.3. DESCRIPTION 14.7.3. DESCRIPTION
The WRITE_PLUS operation is an extension of the NFSv4.1 WRITE The WRITE_PLUS operation is an extension of the NFSv4.1 WRITE
operation (see Section 18.2 of [RFC5661] and writes data to the operation (see Section 18.2 of [RFC5661]) and writes data to the
regular file identified by the current filehandle. The server MAY regular file identified by the current filehandle. The server MAY
write fewer bytes than requested by the client. write fewer bytes than requested by the client.
The WRITE_PLUS argument is comprised of an array of rpr_contents, The WRITE_PLUS argument is comprised of an array of rpr_contents,
each of which describe a data_content4 type of data (Section 7.1.2). each of which describe a data_content4 type of data (Section 7.1.2).
For NFSv4.2, the allowed values are data, ADH, and hole. The array For NFSv4.2, the allowed values are data, ADH, and hole. The array
contents MUST be contiguous in the file. A successful WRITE_PLUS contents MUST be contiguous in the file. A successful WRITE_PLUS
will construct a reply for wr_count, wr_committed, and wr_writeverf will construct a reply for wr_count, wr_committed, and wr_writeverf
as per the NFSv4.1 WRITE operation results. If wr_callback_id is as per the NFSv4.1 WRITE operation results. If wr_callback_id is
set, it indicates an asynchronous reply (see Section 14.7.3.4). set, it indicates an asynchronous reply (see Section 14.7.3.4).
skipping to change at page 77, line 5 skipping to change at page 85, line 5
The READ_PLUS result is comprised of an array of rpr_contents, each The READ_PLUS result is comprised of an array of rpr_contents, each
of which describe a data_content4 type of data (Section 7.1.2). For of which describe a data_content4 type of data (Section 7.1.2). For
NFSv4.2, the allowed values are data, ADH, and hole. A server is NFSv4.2, the allowed values are data, ADH, and hole. A server is
required to support the data type, but neither ADH nor hole. Both an required to support the data type, but neither ADH nor hole. Both an
ADH and a hole must be returned in its entirety - clients must be ADH and a hole must be returned in its entirety - clients must be
prepared to get more information than they requested. Both the start prepared to get more information than they requested. Both the start
and the end of the hole may exceed what was requested. The array and the end of the hole may exceed what was requested. The array
contents MUST be contiguous in the file. contents MUST be contiguous in the file.
READ_PLUS has to support all of the errors which are returned by READ
plus NFS4ERR_UNION_NOTSUPP. If the client asks for a hole and the
server does not support that arm of the discriminated union, but does
support one or more additional arms, it can signal to the client that
it supports the operation, but not the arm with
NFS4ERR_UNION_NOTSUPP.
If the data to be returned is comprised entirely of zeros, then the If the data to be returned is comprised entirely of zeros, then the
server may elect to return that data as a hole. The server server may elect to return that data as a hole. The server
differentiates this to the client by setting di_allocated to TRUE in differentiates this to the client by setting di_allocated to TRUE in
this case. Note that in such a scenario, the server is not required this case. Note that in such a scenario, the server is not required
to determine the full extent of the "hole" - it does not need to to determine the full extent of the "hole" - it does not need to
determine where the zeros start and end. If the server elects to determine where the zeros start and end. If the server elects to
return the hole as data, then it can set the d_allocted to FALSE in return the hole as data, then it can set the d_allocted to FALSE in
the rpc_data to indicate it is a hole. the rpc_data to indicate it is a hole.
The server may elect to return adjacent elements of the same type. The server may elect to return adjacent elements of the same type.
skipping to change at page 83, line 9 skipping to change at page 90, line 45
same information that a synchronous WRITE_PLUS would have returned. same information that a synchronous WRITE_PLUS would have returned.
16. IANA Considerations 16. IANA Considerations
This section uses terms that are defined in [RFC5226]. This section uses terms that are defined in [RFC5226].
17. References 17. References
17.1. Normative References 17.1. Normative References
[4.2xdr] Haynes, T., "Network File System (NFS) Version 4 Minor [NFSv42xdr]
Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 External Data Representation Standard (XDR) Version 2 External Data Representation Standard (XDR)
Description", March 2013. Description", March 2013.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010. RFC 5661, January 2010.
[RFC5664] Halevy, B., Welch, B., and J. Zelenka, "Object-Based [RFC5664] Halevy, B., Welch, B., and J. Zelenka, "Object-Based
Parallel NFS (pNFS) Operations", RFC 5664, January 2010. Parallel NFS (pNFS) Operations", RFC 5664, January 2010.
[posix_fadvise] [posix_fadvise]
The Open Group, "Section 'posix_fadvise()' of System The Open Group, "Section 'posix_fadvise()' of System
Interfaces of The Open Group Base Specifications Issue 6, Interfaces of The Open Group Base Specifications Issue 6,
IEEE Std 1003.1, 2004 Edition", 2004. IEEE Std 1003.1, 2004 Edition", 2004.
[rpcsec_gssv3]
Adamson, W. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", October 2013.
17.2. Informative References 17.2. Informative References
[Ashdown08] [Ashdown08]
Ashdown, L., "Chapter 15, Validating Database Files and Ashdown, L., "Chapter 15, Validating Database Files and
Backups, of Oracle Database Backup and Recovery User's Backups, of Oracle Database Backup and Recovery User's
Guide 11g Release 1 (11.1)", August 2008. Guide 11g Release 1 (11.1)", August 2008.
[Baira08] Bairavasundaram, L., Goodson, G., Schroeder, B., Arpaci- [Baira08] Bairavasundaram, L., Goodson, G., Schroeder, B., Arpaci-
Dusseau, A., and R. Arpaci-Dusseau, "An Analysis of Data Dusseau, A., and R. Arpaci-Dusseau, "An Analysis of Data
Corruption in the Storage Stack", Proceedings of the 6th Corruption in the Storage Stack", Proceedings of the 6th
skipping to change at page 85, line 21 skipping to change at page 93, line 17
For the Sharing change attribute implementation details with NFSv4 For the Sharing change attribute implementation details with NFSv4
clients, the original draft was by Trond Myklebust. clients, the original draft was by Trond Myklebust.
For the NFS Server-side Copy, the original draft was by James For the NFS Server-side Copy, the original draft was by James
Lentini, Mike Eisler, Deepak Kenchammana, Anshul Madan, and Rahul Lentini, Mike Eisler, Deepak Kenchammana, Anshul Madan, and Rahul
Iyer. Tom Talpey co-authored an unpublished version of that Iyer. Tom Talpey co-authored an unpublished version of that
document. It was also was reviewed by a number of individuals: document. It was also was reviewed by a number of individuals:
Pranoop Erasani, Tom Haynes, Arthur Lent, Trond Myklebust, Dave Pranoop Erasani, Tom Haynes, Arthur Lent, Trond Myklebust, Dave
Noveck, Theresa Lingutla-Raj, Manjunath Shankararao, Satyam Vaghani, Noveck, Theresa Lingutla-Raj, Manjunath Shankararao, Satyam Vaghani,
and Nico Williams. and Nico Williams. Anna Schumaker's early prototyping experience
helped us avoid some traps.
For the NFS space reservation operations, the original draft was by For the NFS space reservation operations, the original draft was by
Mike Eisler, James Lentini, Manjunath Shankararao, and Rahul Iyer. Mike Eisler, James Lentini, Manjunath Shankararao, and Rahul Iyer.
For the sparse file support, the original draft was by Dean For the sparse file support, the original draft was by Dean
Hildebrand and Marc Eshel. Valuable input and advice was received Hildebrand and Marc Eshel. Valuable input and advice was received
from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and
Richard Scheffenegger. Richard Scheffenegger.
For the Application IO Hints, the original draft was by Dean For the Application IO Hints, the original draft was by Dean
 End of changes. 42 change blocks. 
133 lines changed or deleted 480 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/