draft-ietf-nfsv4-minorversion2-28.txt   draft-ietf-nfsv4-minorversion2-29.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Primary Data Internet-Draft Primary Data
Intended status: Standards Track November 24, 2014 Intended status: Standards Track December 08, 2014
Expires: May 28, 2015 Expires: June 11, 2015
NFS Version 4 Minor Version 2 NFS Version 4 Minor Version 2
draft-ietf-nfsv4-minorversion2-28.txt draft-ietf-nfsv4-minorversion2-29.txt
Abstract Abstract
This Internet-Draft describes NFS version 4 minor version two, This Internet-Draft describes NFS version 4 minor version two,
describing the protocol extensions made from NFS version 4 minor describing the protocol extensions made from NFS version 4 minor
version 1. Major extensions introduced in 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 version two include: Server Side Copy, Application I/O Advise, Space
Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.
Requirements Language Requirements Language
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 May 28, 2015. This Internet-Draft will expire on June 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
4.6. Inter-Server Copy . . . . . . . . . . . . . . . . . . . . 13 4.6. Inter-Server Copy . . . . . . . . . . . . . . . . . . . . 13
4.7. Server-to-Server Copy Protocol . . . . . . . . . . . . . 17 4.7. Server-to-Server Copy Protocol . . . . . . . . . . . . . 17
4.7.1. Considerations on Selecting a Copy Protocol . . . . . 17 4.7.1. Considerations on Selecting a Copy Protocol . . . . . 17
4.7.2. Using NFSv4.x as the Copy Protocol . . . . . . . . . 17 4.7.2. Using NFSv4.x as the Copy Protocol . . . . . . . . . 17
4.7.3. Using an Alternative Copy Protocol . . . . . . . . . 17 4.7.3. Using an Alternative Copy Protocol . . . . . . . . . 17
4.8. netloc4 - Network Locations . . . . . . . . . . . . . . . 18 4.8. netloc4 - Network Locations . . . . . . . . . . . . . . . 18
4.9. Copy Offload Stateids . . . . . . . . . . . . . . . . . . 19 4.9. Copy Offload Stateids . . . . . . . . . . . . . . . . . . 19
4.10. Security Considerations . . . . . . . . . . . . . . . . . 19 4.10. Security Considerations . . . . . . . . . . . . . . . . . 19
4.10.1. Inter-Server Copy Security . . . . . . . . . . . . . 19 4.10.1. Inter-Server Copy Security . . . . . . . . . . . . . 19
5. Support for Application IO Hints . . . . . . . . . . . . . . 27 5. Support for Application IO Hints . . . . . . . . . . . . . . 27
6. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. New Operations . . . . . . . . . . . . . . . . . . . . . 29 6.3. New Operations . . . . . . . . . . . . . . . . . . . . . 29
6.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 29 6.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 29
6.3.2. DEALLOCATE . . . . . . . . . . . . . . . . . . . . . 29 6.3.2. DEALLOCATE . . . . . . . . . . . . . . . . . . . . . 30
7. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 29 7. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 30
8. Application Data Block Support . . . . . . . . . . . . . . . 31 8. Application Data Block Support . . . . . . . . . . . . . . . 32
8.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 32 8.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 33
8.1.1. Data Block Representation . . . . . . . . . . . . . . 33 8.1.1. Data Block Representation . . . . . . . . . . . . . . 33
8.2. An Example of Detecting Corruption . . . . . . . . . . . 33 8.2. An Example of Detecting Corruption . . . . . . . . . . . 34
8.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 35 8.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 35
8.4. An Example of Zeroing Space . . . . . . . . . . . . . . . 35 8.4. An Example of Zeroing Space . . . . . . . . . . . . . . . 36
9. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36 9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36
9.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 9.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37
9.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 37 9.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 38
9.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 38 9.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 38
9.3.2. Permission Checking . . . . . . . . . . . . . . . . . 38 9.3.2. Permission Checking . . . . . . . . . . . . . . . . . 39
9.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 38 9.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 39
9.3.4. Existing Objects . . . . . . . . . . . . . . . . . . 39 9.3.4. Existing Objects . . . . . . . . . . . . . . . . . . 39
9.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 39 9.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 39
9.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 39 9.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 40
9.5. Discovery of Server Labeled NFS Support . . . . . . . . . 39 9.5. Discovery of Server Labeled NFS Support . . . . . . . . . 40
9.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 40 9.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 40
9.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 40 9.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 41
9.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . 42 9.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . 42
9.7. Security Considerations for Labeled NFS . . . . . . . . . 42 9.7. Security Considerations for Labeled NFS . . . . . . . . . 42
10. Sharing change attribute implementation details with NFSv4 10. Sharing change attribute implementation details with NFSv4
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 43 11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Error Definitions . . . . . . . . . . . . . . . . . . . 43 11.1. Error Definitions . . . . . . . . . . . . . . . . . . . 44
11.1.1. General Errors . . . . . . . . . . . . . . . . . . . 43 11.1.1. General Errors . . . . . . . . . . . . . . . . . . . 44
11.1.2. Server to Server Copy Errors . . . . . . . . . . . . 44 11.1.2. Server to Server Copy Errors . . . . . . . . . . . . 44
11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . 44 11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . 45
11.2. New Operations and Their Valid Errors . . . . . . . . . 45 11.2. New Operations and Their Valid Errors . . . . . . . . . 45
11.3. New Callback Operations and Their Valid Errors . . . . . 48 11.3. New Callback Operations and Their Valid Errors . . . . . 49
12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 49 12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 49
12.1. New RECOMMENDED Attributes - List and Definition 12.1. New RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 49 References . . . . . . . . . . . . . . . . . . . . . . . 49
12.2. Attribute Definitions . . . . . . . . . . . . . . . . . 50 12.2. Attribute Definitions . . . . . . . . . . . . . . . . . 50
13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 52 13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 53
14. Modifications to NFSv4.1 Operations . . . . . . . . . . . . . 56 14. Modifications to NFSv4.1 Operations . . . . . . . . . . . . . 56
14.1. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 56 14.1. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 56
14.2. Operation 48: GETDEVICELIST - Get All Device Mappings 14.2. Operation 48: GETDEVICELIST - Get All Device Mappings
for a File System . . . . . . . . . . . . . . . . . . . 57 for a File System . . . . . . . . . . . . . . . . . . . 57
15. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . 58 15. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . 59
15.1. Operation 59: ALLOCATE - Reserve Space in A Region of a 15.1. Operation 59: ALLOCATE - Reserve Space in A Region of a
File . . . . . . . . . . . . . . . . . . . . . . . . . . 58 File . . . . . . . . . . . . . . . . . . . . . . . . . . 59
15.2. Operation 60: COPY - Initiate a server-side copy . . . . 59 15.2. Operation 60: COPY - Initiate a server-side copy . . . . 60
15.3. Operation 61: COPY_NOTIFY - Notify a source server of a 15.3. Operation 61: COPY_NOTIFY - Notify a source server of a
future copy . . . . . . . . . . . . . . . . . . . . . . 63 future copy . . . . . . . . . . . . . . . . . . . . . . 65
15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region 15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region
of a File . . . . . . . . . . . . . . . . . . . . . . . 65 of a File . . . . . . . . . . . . . . . . . . . . . . . 66
15.5. Operation 63: IO_ADVISE - Application I/O access pattern 15.5. Operation 63: IO_ADVISE - Application I/O access pattern
hints . . . . . . . . . . . . . . . . . . . . . . . . . 66 hints . . . . . . . . . . . . . . . . . . . . . . . . . 67
15.6. Operation 64: LAYOUTERROR - Provide Errors for the 15.6. Operation 64: LAYOUTERROR - Provide Errors for the
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 71 Layout . . . . . . . . . . . . . . . . . . . . . . . . . 73
15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the 15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 74 Layout . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded 15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded
Operation . . . . . . . . . . . . . . . . . . . . . . . 75 Operation . . . . . . . . . . . . . . . . . . . . . . . 78
15.9. Operation 67: OFFLOAD_STATUS - Poll for Status of 15.9. Operation 67: OFFLOAD_STATUS - Poll for Status of
Asynchronous Operation . . . . . . . . . . . . . . . . . 76 Asynchronous Operation . . . . . . . . . . . . . . . . . 79
15.10. Operation 68: READ_PLUS - READ Data or Holes from a File 77 15.10. Operation 68: READ_PLUS - READ Data or Holes from a File 80
15.11. Operation 69: SEEK - Find the Next Data or Hole . . . . 82 15.11. Operation 69: SEEK - Find the Next Data or Hole . . . . 85
15.12. Operation 70: WRITE_SAME - WRITE an ADB Multiple Times 15.12. Operation 70: WRITE_SAME - WRITE an ADB Multiple Times
to a File . . . . . . . . . . . . . . . . . . . . . . . 83 to a File . . . . . . . . . . . . . . . . . . . . . . . 86
16. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 86 16. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 90
16.1. Operation 15: CB_OFFLOAD - Report results of an 16.1. Operation 15: CB_OFFLOAD - Report results of an
asynchronous operation . . . . . . . . . . . . . . . . . 86 asynchronous operation . . . . . . . . . . . . . . . . . 90
17. Security Considerations . . . . . . . . . . . . . . . . . . . 87 17. Security Considerations . . . . . . . . . . . . . . . . . . . 91
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
19.1. Normative References . . . . . . . . . . . . . . . . . . 88 19.1. Normative References . . . . . . . . . . . . . . . . . . 91
19.2. Informative References . . . . . . . . . . . . . . . . . 88 19.2. Informative References . . . . . . . . . . . . . . . . . 92
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 90 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 94
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 91 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 95
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 95
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]. second minor version, NFSv4.1, is described in [RFC5661].
skipping to change at page 5, line 19 skipping to change at page 5, line 19
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 [NFSv42xdr]. The full External Data Representation (XDR) [RFC4506] for NFSv4.2 is
presented in [NFSv42xdr].
1.3. NFSv4.2 Goals 1.3. NFSv4.2 Goals
A major goal of the design of NFSv4.2 is to take common local file A major goal of the design of NFSv4.2 is to take common local file
system features and offer them remotely. These features might system 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 pulls in both o be under development as a new standard, e.g., SEEK pulls in both
SEEK_HOLE and SEEK_DATA SEEK_HOLE and SEEK_DATA
skipping to change at page 18, line 31 skipping to change at page 18, line 31
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 4.10.1.3. this are given in Section 4.10.1.3.
4.8. netloc4 - Network Locations 4.8. netloc4 - Network Locations
The server-side copy operations specify network locations using the The server-side copy operations specify network locations using the
netloc4 data type shown below: netloc4 data type shown below:
<CODE BEGINS>
enum netloc_type4 { enum netloc_type4 {
NL4_NAME = 0, NL4_NAME = 0,
NL4_URL = 1, NL4_URL = 1,
NL4_NETADDR = 2 NL4_NETADDR = 2
}; };
union netloc4 switch (netloc_type4 nl_type) { union netloc4 switch (netloc_type4 nl_type) {
case NL4_NAME: utf8str_cis nl_name; case NL4_NAME: utf8str_cis nl_name;
case NL4_URL: utf8str_cis nl_url; case NL4_URL: utf8str_cis nl_url;
case NL4_NETADDR: netaddr4 nl_addr; case NL4_NETADDR: netaddr4 nl_addr;
}; };
<CODE ENDS>
If the netloc4 is of type NL4_NAME, the nl_name field MUST be If the netloc4 is of type NL4_NAME, the nl_name field MUST be
specified as a UTF-8 string. The nl_name is expected to be resolved specified as a UTF-8 string. The nl_name is expected to be resolved
to a network address via DNS, LDAP, NIS, /etc/hosts, or some other to a network address via DNS, LDAP, NIS, /etc/hosts, or some other
means. If the netloc4 is of type NL4_URL, a server URL [RFC3986] means. If the netloc4 is of type NL4_URL, a server URL [RFC3986]
appropriate for the server-to-server copy operation is specified as a appropriate for the server-to-server copy operation is specified as a
UTF-8 string. If the netloc4 is of type NL4_NETADDR, the nl_addr UTF-8 string. If the netloc4 is of type NL4_NETADDR, the nl_addr
field MUST contain a valid netaddr4 as defined in Section 3.3.9 of field MUST contain a valid netaddr4 as defined in Section 3.3.9 of
[RFC5661]. [RFC5661].
When netloc4 values are used for an inter-server copy as shown in When netloc4 values are used for an inter-server copy as shown in
skipping to change at page 20, line 42 skipping to change at page 20, line 50
copy_from_auth: A user principal is authorizing a source principal copy_from_auth: A user principal is authorizing a source principal
("nfs@<source>") to allow a destination principal ("nfs@<source>") to allow a destination principal
("nfs@<destination>") to setup the copy_confirm_auth privilege ("nfs@<destination>") to setup the copy_confirm_auth privilege
required to copy a file from the source to the destination on required to copy a file from the source to the destination on
behalf of the user principal. This privilege is established on behalf of the user principal. This privilege is established on
the source server before the user principal sends a COPY_NOTIFY the source server before the user principal sends a COPY_NOTIFY
operation to the source server, and the resultant RPCSEC_GSSv3 operation to the source server, and the resultant RPCSEC_GSSv3
context is used to secure the COPY_NOTIFY operation. context is used to secure the COPY_NOTIFY operation.
<CODE BEGINS>
struct copy_from_auth_priv { struct copy_from_auth_priv {
secret4 cfap_shared_secret; secret4 cfap_shared_secret;
netloc4 cfap_destination; netloc4 cfap_destination;
/* the NFSv4 user name that the user principal maps to */ /* the NFSv4 user name that the user principal maps to */
utf8str_mixed cfap_username; utf8str_mixed cfap_username;
}; };
<CODE ENDS>
cfp_shared_secret is an automatically generated random number cfp_shared_secret is an automatically generated random number
secret value. secret value.
copy_to_auth: A user principal is authorizing a destination copy_to_auth: A user principal is authorizing a destination
principal ("nfs@<destination>") to setup a copy_confirm_auth principal ("nfs@<destination>") to setup a copy_confirm_auth
privilege with a source principal ("nfs@<source>") to allow it to privilege with a source principal ("nfs@<source>") to allow it to
copy a file from the source to the destination on behalf of the copy a file from the source to the destination on behalf of the
user principal. This privilege is established on the destination user principal. This privilege is established on the destination
server before the user principal sends a COPY operation to the server before the user principal sends a COPY operation to the
destination server, and the resultant RPCSEC_GSSv3 context is used destination server, and the resultant RPCSEC_GSSv3 context is used
to secure the COPY operation. to secure the COPY operation.
<CODE BEGINS>
struct copy_to_auth_priv { struct copy_to_auth_priv {
/* equal to cfap_shared_secret */ /* equal to cfap_shared_secret */
secret4 ctap_shared_secret; secret4 ctap_shared_secret;
netloc4 ctap_source<>; netloc4 ctap_source<>;
/* the NFSv4 user name that the user principal maps to */ /* the NFSv4 user name that the user principal maps to */
utf8str_mixed ctap_username; utf8str_mixed ctap_username;
}; };
<CODE ENDS>
ctap_shared_secret is the automatically generated secret value ctap_shared_secret is the automatically generated secret value
used to establish the copy_from_auth privilege with the source used to establish the copy_from_auth privilege with the source
principal. See Section 4.10.1.1.1. principal. See Section 4.10.1.1.1.
copy_confirm_auth: A destination principal ("nfs@<destination>") is copy_confirm_auth: A destination principal ("nfs@<destination>") is
confirming with the source principal ("nfs@<source>") that it is confirming with the source principal ("nfs@<source>") that it is
authorized to copy data from the source. This privilege is authorized to copy data from the source. This privilege is
established on the destination server before the file is copied established on the destination server before the file is copied
from the source to the destination. The resultant RPCSEC_GSSv3 from the source to the destination. The resultant RPCSEC_GSSv3
context is used to secure the READ operations from the source to context is used to secure the READ operations from the source to
the destination server. the destination server.
<CODE BEGINS>
struct copy_confirm_auth_priv { struct copy_confirm_auth_priv {
/* equal to GSS_GetMIC() of cfap_shared_secret */ /* equal to GSS_GetMIC() of cfap_shared_secret */
opaque ccap_shared_secret_mic<>; opaque ccap_shared_secret_mic<>;
/* the NFSv4 user name that the user principal maps to */ /* the NFSv4 user name that the user principal maps to */
utf8str_mixed ccap_username; utf8str_mixed ccap_username;
}; };
<CODE ENDS>
4.10.1.1.1. Establishing a Security Context 4.10.1.1.1. Establishing a Security Context
When the user principal wants to COPY a file between two servers, if 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 it has not established copy_from_auth and copy_to_auth privileges on
the servers, it establishes them: the servers, it establishes them:
o As noted in [rpcsec_gssv3] the client uses an existing o As noted in [rpcsec_gssv3] the client uses an existing
RPCSEC_GSSv3 context termed the "parent" handle to establish and RPCSEC_GSSv3 context termed the "parent" handle to establish and
protect RPCSEC_GSSv3 structured privilege assertion exchanges. protect RPCSEC_GSSv3 structured privilege assertion exchanges.
The copy_from_auth privilege will use the context established The copy_from_auth privilege will use the context established
skipping to change at page 22, line 19 skipping to change at page 22, line 41
between the two servers. This shared secret will be placed in the between the two servers. This shared secret will be placed in the
cfap_shared_secret and ctap_shared_secret fields of the cfap_shared_secret and ctap_shared_secret fields of the
appropriate privilege data types, copy_from_auth_priv and appropriate privilege data types, copy_from_auth_priv and
copy_to_auth_priv. Because of this shared_secret the copy_to_auth_priv. Because of this shared_secret the
RPCSEC_GSS3_CREATE control messages for copy_from_auth and RPCSEC_GSS3_CREATE control messages for copy_from_auth and
copy_to_auth MUST use a QOP of rpc_gss_svc_privacy. 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 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 secret, the destination server, and the NFSv4 user id of the user
principal and is placed in rpc_gss3_create_args principal and is placed in rpc_gss3_create_args
assertions[0].assertion.privs.privilege. The string assertions[0].privs.privilege. The string "copy_from_auth" is
"copy_from_auth" is placed in assertions[0].assertion.privs.name. placed in assertions[0].privs.name. The source server unwraps the
The source server unwraps the rpc_gss_svc_privacy rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload and verifies that
RPCSEC_GSS3_CREATE payload and verifies that the NFSv4 user id the NFSv4 user id being asserted matches the source server's
being asserted matches the source server's mapping of the user mapping of the user principal. If it does, the privilege is
principal. If it does, the privilege is established on the source established on the source server as: <"copy_from_auth", user id,
server as: <"copy_from_auth", user id, destination>. The field destination>. The field "handle" in a successful reply is the
"handle" in a successful reply is the RPCSEC_GSSv3 copy_from_auth RPCSEC_GSSv3 copy_from_auth "child" handle that the client will
"child" handle that the client will use on COPY_NOTIFY requests to use on COPY_NOTIFY requests to the source server.
the source server.
o An instance of copy_to_auth_priv is filled in with the shared 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 secret, the cnr_source_server list returned by COPY_NOTIFY, and
the NFSv4 user id of the user principal. The copy_to_auth_priv the NFSv4 user id of the user principal. The copy_to_auth_priv
instance is placed in rpc_gss3_create_args instance is placed in rpc_gss3_create_args
assertions[0].assertion.privs.privilege. The string assertions[0].privs.privilege. The string "copy_to_auth" is
"copy_to_auth" is placed in assertions[0].assertion.privs.name. placed in assertions[0].privs.name. The destination server
The destination server unwraps the rpc_gss_svc_privacy unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload and
RPCSEC_GSS3_CREATE payload and verifies that the NFSv4 user id verifies that the NFSv4 user id being asserted matches the
being asserted matches the destination server's mapping of the destination server's mapping of the user principal. If it does,
user principal. If it does, the privilege is established on the the privilege is established on the destination server as:
destination server as: <"copy_to_auth", user id, source list>. <"copy_to_auth", user id, source list>. The field "handle" in a
The field "handle" in a successful reply is the RPCSEC_GSSv3 successful reply is the RPCSEC_GSSv3 copy_to_auth "child" handle
copy_to_auth "child" handle that the client will use on COPY that the client will use on COPY requests to the destination
requests to the destination server involving the source server. server involving the source server.
As noted in [rpcsec_gssv3] Section 2.3.1 "Create Request", both the As noted in [rpcsec_gssv3] Section 2.3.1 "Create Request", both the
client and the source server should associate the RPCSEC_GSSv3 client and the source server should associate the RPCSEC_GSSv3
"child" handle with the parent RPCSEC_GSSv3 handle used to create the "child" handle with the parent RPCSEC_GSSv3 handle used to create the
RPCSEC_GSSv3 child handle. RPCSEC_GSSv3 child handle.
4.10.1.1.2. Starting a Secure Inter-Server Copy 4.10.1.1.2. Starting a Secure Inter-Server Copy
When the client sends a COPY_NOTIFY request to the source server, it When the client sends a COPY_NOTIFY request to the source server, it
uses the privileged "copy_from_auth" RPCSEC_GSSv3 handle. uses the privileged "copy_from_auth" RPCSEC_GSSv3 handle.
skipping to change at page 24, line 8 skipping to change at page 24, line 27
server must mount the source server using RPCSEC_GSSv3. server must mount the source server using RPCSEC_GSSv3.
o An instance of copy_confirm_auth_priv is filled in with o An instance of copy_confirm_auth_priv is filled in with
information from the established "copy_to_auth" privilege. The information from the established "copy_to_auth" privilege. The
value of the field ccap_shared_secret_mic is a GSS_GetMIC() of 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 ctap_shared_secret in the copy_to_auth privilege using the parent
handle context. The field ccap_username is the mapping of the handle context. The field ccap_username is the mapping of the
user principal to an NFSv4 user name ("user"@"domain" form), and user principal to an NFSv4 user name ("user"@"domain" form), and
MUST be the same as the ctap_username in the copy_to_auth MUST be the same as the ctap_username in the copy_to_auth
privilege. The copy_confirm_auth_priv instance is placed in privilege. The copy_confirm_auth_priv instance is placed in
rpc_gss3_create_args assertions[0].assertion.privs.privilege. The rpc_gss3_create_args assertions[0].privs.privilege. The string
string "copy_confirm_auth" is placed in "copy_confirm_auth" is placed in assertions[0].privs.name.
assertions[0].assertion.privs.name.
o The RPCSEC_GSS3_CREATE copy_from_auth message is sent to the 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 source server with a QOP of rpc_gss_svc_privacy. The source
server unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload server unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload
and verifies the cap_shared_secret_mic by calling GSS_VerifyMIC() and verifies the cap_shared_secret_mic by calling GSS_VerifyMIC()
using the parent context on the cfap_shared_secret from the using the parent context on the cfap_shared_secret from the
established "copy_from_auth" privilege, and verifies the that the established "copy_from_auth" privilege, and verifies the that the
ccap_username equals the cfap_username. ccap_username equals the cfap_username.
o If all verification succeeds, the "copy_confirm_auth" privilege is o If all verification succeeds, the "copy_confirm_auth" privilege is
skipping to change at page 33, line 11 skipping to change at page 33, line 29
The guard pattern can be used to represent the state of the block, to The guard pattern can be used to represent the state of the block, to
protect against corruption, or both. Again, it needs to be able to protect against corruption, or both. Again, it needs to be able to
be placed anywhere within the ADB. be placed anywhere within the ADB.
We need to be able to represent the starting offset of the block and We need to be able to represent the starting offset of the block and
the size of the block. Note that nothing prevents the application the size of the block. Note that nothing prevents the application
from defining different sized blocks in a file. from defining different sized blocks in a file.
8.1.1. Data Block Representation 8.1.1. Data Block Representation
<CODE BEGINS>
struct app_data_block4 { struct app_data_block4 {
offset4 adb_offset; offset4 adb_offset;
length4 adb_block_size; length4 adb_block_size;
length4 adb_block_count; length4 adb_block_count;
length4 adb_reloff_blocknum; length4 adb_reloff_blocknum;
count4 adb_block_num; count4 adb_block_num;
length4 adb_reloff_pattern; length4 adb_reloff_pattern;
opaque adb_pattern<>; opaque adb_pattern<>;
}; };
<CODE ENDS>
The app_data_block4 structure captures the abstraction presented for The app_data_block4 structure captures the abstraction presented for
the ADB. The additional fields present are to allow the transmission the ADB. The additional fields present are to allow the transmission
of adb_block_count ADBs at one time. We also use adb_block_num to of adb_block_count ADBs at one time. We also use adb_block_num to
convey the ADBN of the first block in the sequence. Each ADB will convey the ADBN of the first block in the sequence. Each ADB will
contain the same adb_pattern string. contain the same adb_pattern string.
As both adb_block_num and adb_pattern are optional, if either As both adb_block_num and adb_pattern are optional, if either
adb_reloff_pattern or adb_reloff_blocknum is set to NFS4_UINT64_MAX, adb_reloff_pattern or adb_reloff_blocknum is set to NFS4_UINT64_MAX,
then the corresponding field is not set in any of the ADB. then the corresponding field is not set in any of the ADB.
skipping to change at page 40, line 37 skipping to change at page 41, line 15
9.6.1. Full Mode 9.6.1. Full Mode
Full mode environments consist of MAC-Functional NFSv4 servers and Full mode environments consist of MAC-Functional NFSv4 servers and
clients and may be composed of mixed MAC models and policies. The clients and may be composed of mixed MAC models and policies. The
system requires that both the client and server have an opportunity system requires that both the client and server have an opportunity
to perform an access control check based on all relevant information to perform an access control check based on all relevant information
within the network. The file object security attribute is provided within the network. The file object security attribute is provided
using the mechanism described in Section 9.3. using the mechanism described in Section 9.3.
Fully MAC-Functional NFSv4 servers are not possible in the absence of Fully MAC-Functional NFSv4 servers are not possible in the absence of
RPC layer modifications to support subject label transport. However, RPCSEC_GSSv3 [rpcsec_gssv3] support for subject label transport.
servers may make decisions based on the RPC credential information However, servers may make decisions based on the RPC credential
available and future specifications may provide subject label information available.
transport.
9.6.1.1. Initial Labeling and Translation 9.6.1.1. Initial Labeling and Translation
The ability to create a file is an action that a MAC model may wish The ability to create a file is an action that a MAC model may wish
to mediate. The client is given the responsibility to determine the to mediate. The client is given the responsibility to determine the
initial security attribute to be placed on a file. This allows the initial security attribute to be placed on a file. This allows the
client to make a decision as to the acceptable security attributes to client to make a decision as to the acceptable security attributes to
create a file with before sending the request to the server. Once create a file with before sending the request to the server. Once
the server receives the creation request from the client it may the server receives the creation request from the client it may
choose to evaluate if the security attribute is acceptable. choose to evaluate if the security attribute is acceptable.
skipping to change at page 50, line 19 skipping to change at page 50, line 30
| change_attr_type | 78 | change_attr_type4 | R | Section 12.2.1 | | change_attr_type | 78 | change_attr_type4 | R | Section 12.2.1 |
| sec_label | 79 | sec_label4 | R W | Section 12.2.2 | | sec_label | 79 | sec_label4 | R W | Section 12.2.2 |
+------------------+----+-------------------+-----+----------------+ +------------------+----+-------------------+-----+----------------+
Table 4 Table 4
12.2. Attribute Definitions 12.2. Attribute Definitions
12.2.1. Attribute 78: change_attr_type 12.2.1. Attribute 78: change_attr_type
<CODE BEGINS>
enum change_attr_type4 { enum change_attr_type4 {
NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR = 0, NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR = 0,
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER = 1, NFS4_CHANGE_TYPE_IS_VERSION_COUNTER = 1,
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS = 2, NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS = 2,
NFS4_CHANGE_TYPE_IS_TIME_METADATA = 3, NFS4_CHANGE_TYPE_IS_TIME_METADATA = 3,
NFS4_CHANGE_TYPE_IS_UNDEFINED = 4 NFS4_CHANGE_TYPE_IS_UNDEFINED = 4
}; };
<CODE ENDS>
change_attr_type is a per file system attribute which enables the change_attr_type is a per file system attribute which enables the
NFSv4.2 server to provide additional information about how it expects NFSv4.2 server to provide additional information about how it expects
the change attribute value to evolve after the file data, or metadata the change attribute value to evolve after the file data, or metadata
has changed. While Section 5.4 of [RFC5661] discusses per file has changed. While Section 5.4 of [RFC5661] discusses per file
system attributes, it is expected that the value of change_attr_type system attributes, it is expected that the value of change_attr_type
not depend on the value of "homogeneous" and only changes in the not depend on the value of "homogeneous" and only changes in the
event of a migration. event of a migration.
NFS4_CHANGE_TYPE_IS_UNDEFINED: The change attribute does not take NFS4_CHANGE_TYPE_IS_UNDEFINED: The change attribute does not take
values that fit into any of these categories. values that fit into any of these categories.
skipping to change at page 51, line 35 skipping to change at page 52, line 7
The value NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS permits the The value NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS permits the
same, but only if the client is not doing pNFS WRITEs. same, but only if the client is not doing pNFS WRITEs.
Finally, if the server does not support change_attr_type or if Finally, if the server does not support change_attr_type or if
NFS4_CHANGE_TYPE_IS_UNDEFINED is set, then the server SHOULD make an NFS4_CHANGE_TYPE_IS_UNDEFINED is set, then the server SHOULD make an
effort to implement the change attribute in terms of the effort to implement the change attribute in terms of the
time_metadata attribute. time_metadata attribute.
12.2.2. Attribute 79: sec_label 12.2.2. Attribute 79: sec_label
<CODE BEGINS>
typedef uint32_t policy4; typedef uint32_t policy4;
struct labelformat_spec4 { struct labelformat_spec4 {
policy4 lfs_lfs; policy4 lfs_lfs;
policy4 lfs_pi; policy4 lfs_pi;
}; };
struct sec_label4 { struct sec_label4 {
labelformat_spec4 slai_lfs; labelformat_spec4 slai_lfs;
opaque slai_data<>; opaque slai_data<>;
}; };
<CODE ENDS>
The FATTR4_SEC_LABEL contains an array of two components with the The FATTR4_SEC_LABEL contains an array of two components with the
first component being an LFS. It serves to provide the receiving end first component being an LFS. It serves to provide the receiving end
with the information necessary to translate the security attribute with the information necessary to translate the security attribute
into a form that is usable by the endpoint. Label Formats assigned into a form that is usable by the endpoint. Label Formats assigned
an LFS may optionally choose to include a Policy Identifier field to an LFS may optionally choose to include a Policy Identifier field to
allow for complex policy deployments. The LFS and Label Format allow for complex policy deployments. The LFS and Label Format
Registry are described in detail in [Quigley14]. The translation Registry are described in detail in [Quigley14]. The translation
used to interpret the security attribute is not specified as part of used to interpret the security attribute is not specified as part of
the protocol as it may depend on various factors. The second the protocol as it may depend on various factors. The second
component is an opaque section which contains the data of the component is an opaque section which contains the data of the
skipping to change at page 56, line 11 skipping to change at page 56, line 36
| CB_WANTS_CANCELLED | OPT | FDELG, DDELG, pNFS | | CB_WANTS_CANCELLED | OPT | FDELG, DDELG, pNFS |
| | | (REQ) | | | | (REQ) |
+-------------------------+------------------+----------------------+ +-------------------------+------------------+----------------------+
14. Modifications to NFSv4.1 Operations 14. Modifications to NFSv4.1 Operations
14.1. Operation 42: EXCHANGE_ID - Instantiate Client ID 14.1. Operation 42: EXCHANGE_ID - Instantiate Client ID
14.1.1. ARGUMENT 14.1.1. ARGUMENT
<CODE BEGINS>
/* new */ /* new */
const EXCHGID4_FLAG_SUPP_FENCE_OPS = 0x00000004; const EXCHGID4_FLAG_SUPP_FENCE_OPS = 0x00000004;
<CODE ENDS>
14.1.2. RESULT 14.1.2. RESULT
Unchanged Unchanged
14.1.3. MOTIVATION 14.1.3. MOTIVATION
Enterprise applications require guarantees that an operation has Enterprise applications require guarantees that an operation has
either aborted or completed. NFSv4.1 provides this guarantee as long either aborted or completed. NFSv4.1 provides this guarantee as long
as the session is alive: simply send a SEQUENCE operation on the same as the session is alive: simply send a SEQUENCE operation on the same
slot with a new sequence number, and the successful return of slot with a new sequence number, and the successful return of
skipping to change at page 57, line 12 skipping to change at page 57, line 41
ID created on one node of the storage cluster MUST be destroyable ID created on one node of the storage cluster MUST be destroyable
via DESTROY_SESSION. In addition, DESTROY_CLIENTID and an via DESTROY_SESSION. In addition, DESTROY_CLIENTID and an
EXCHANGE_ID with a new verifier affects all sessions regardless EXCHANGE_ID with a new verifier affects all sessions regardless
what node the sessions were created on. what node the sessions were created on.
14.2. Operation 48: GETDEVICELIST - Get All Device Mappings for a File 14.2. Operation 48: GETDEVICELIST - Get All Device Mappings for a File
System System
14.2.1. ARGUMENT 14.2.1. ARGUMENT
<CODE BEGINS>
struct GETDEVICELIST4args { struct GETDEVICELIST4args {
/* CURRENT_FH: object belonging to the file system */ /* CURRENT_FH: object belonging to the file system */
layouttype4 gdla_layout_type; layouttype4 gdla_layout_type;
/* number of deviceIDs to return */ /* number of deviceIDs to return */
count4 gdla_maxdevices; count4 gdla_maxdevices;
nfs_cookie4 gdla_cookie; nfs_cookie4 gdla_cookie;
verifier4 gdla_cookieverf; verifier4 gdla_cookieverf;
}; };
<CODE ENDS>
14.2.2. RESULT 14.2.2. RESULT
<CODE BEGINS>
struct GETDEVICELIST4resok { struct GETDEVICELIST4resok {
nfs_cookie4 gdlr_cookie; nfs_cookie4 gdlr_cookie;
verifier4 gdlr_cookieverf; verifier4 gdlr_cookieverf;
deviceid4 gdlr_deviceid_list<>; deviceid4 gdlr_deviceid_list<>;
bool gdlr_eof; bool gdlr_eof;
}; };
union GETDEVICELIST4res switch (nfsstat4 gdlr_status) { union GETDEVICELIST4res switch (nfsstat4 gdlr_status) {
case NFS4_OK: case NFS4_OK:
GETDEVICELIST4resok gdlr_resok4; GETDEVICELIST4resok gdlr_resok4;
default: default:
void; void;
}; };
<CODE ENDS>
14.2.3. MOTIVATION 14.2.3. MOTIVATION
The GETDEVICELIST operation was introduced in [RFC5661] specifically The GETDEVICELIST operation was introduced in [RFC5661] specifically
to request a list of devices at filesystem mount time from block to request a list of devices at filesystem mount time from block
layout type servers. However use of the GETDEVICELIST operation layout type servers. However use of the GETDEVICELIST operation
introduces a race condition versus notification about changes to pNFS introduces a race condition versus notification about changes to pNFS
device IDs as provided by CB_NOTIFY_DEVICEID. Implementation device IDs as provided by CB_NOTIFY_DEVICEID. Implementation
experience with block layout servers has shown there is no need for experience with block layout servers has shown there is no need for
GETDEVICELIST. Clients have to be able to request new devices using GETDEVICELIST. Clients have to be able to request new devices using
GETDEVICEINFO at any time in response either to a new deviceid in GETDEVICEINFO at any time in response either to a new deviceid in
skipping to change at page 58, line 15 skipping to change at page 59, line 15
14.2.4. DESCRIPTION 14.2.4. DESCRIPTION
Clients and servers MUST NOT implement the GETDEVICELIST operation. Clients and servers MUST NOT implement the GETDEVICELIST operation.
15. NFSv4.2 Operations 15. NFSv4.2 Operations
15.1. Operation 59: ALLOCATE - Reserve Space in A Region of a File 15.1. Operation 59: ALLOCATE - Reserve Space in A Region of a File
15.1.1. ARGUMENT 15.1.1. ARGUMENT
<CODE BEGINS>
struct ALLOCATE4args { struct ALLOCATE4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
stateid4 aa_stateid; stateid4 aa_stateid;
offset4 aa_offset; offset4 aa_offset;
length4 aa_length; length4 aa_length;
}; };
<CODE ENDS>
15.1.2. RESULT 15.1.2. RESULT
<CODE BEGINS>
struct ALLOCATE4res { struct ALLOCATE4res {
nfsstat4 ar_status; nfsstat4 ar_status;
}; };
<CODE ENDS>
15.1.3. DESCRIPTION 15.1.3. DESCRIPTION
Whenever a client wishes to reserve space for a region in a file it Whenever a client wishes to reserve space for a region in a file it
calls the ALLOCATE operation with the current filehandle set to the calls the ALLOCATE operation with the current filehandle set to the
filehandle of the file in question, and the start offset and length filehandle of the file in question, and the start offset and length
in bytes of the region set in aa_offset and aa_length respectively. in bytes of the region set in aa_offset and aa_length respectively.
The server will ensure that backing blocks are reserved to the region The server will ensure that backing blocks are reserved to the region
specified by aa_offset and aa_length, and that no future writes into specified by aa_offset and aa_length, and that no future writes into
this region will return NFS4ERR_NOSPC. If the region lies partially this region will return NFS4ERR_NOSPC. If the region lies partially
skipping to change at page 59, line 14 skipping to change at page 60, line 21
The ALLOCATE operation will result in the space_used attribute and The ALLOCATE operation will result in the space_used attribute and
space_freed attributes being increased by the number of bytes space_freed attributes being increased by the number of bytes
reserved unless they were previously reserved or written and not reserved unless they were previously reserved or written and not
shared. shared.
15.2. Operation 60: COPY - Initiate a server-side copy 15.2. Operation 60: COPY - Initiate a server-side copy
15.2.1. ARGUMENT 15.2.1. ARGUMENT
<CODE BEGINS>
struct COPY4args { struct COPY4args {
/* SAVED_FH: source file */ /* SAVED_FH: source file */
/* CURRENT_FH: destination file */ /* CURRENT_FH: destination file */
stateid4 ca_src_stateid; stateid4 ca_src_stateid;
stateid4 ca_dst_stateid; stateid4 ca_dst_stateid;
offset4 ca_src_offset; offset4 ca_src_offset;
offset4 ca_dst_offset; offset4 ca_dst_offset;
length4 ca_count; length4 ca_count;
bool ca_consecutive; bool ca_consecutive;
bool ca_synchronous; bool ca_synchronous;
netloc4 ca_source_server<>; netloc4 ca_source_server<>;
}; };
<CODE ENDS>
15.2.2. RESULT 15.2.2. RESULT
<CODE BEGINS>
struct write_response4 { struct write_response4 {
stateid4 wr_callback_id<1>; stateid4 wr_callback_id<1>;
length4 wr_count; length4 wr_count;
stable_how4 wr_committed; stable_how4 wr_committed;
verifier4 wr_writeverf; verifier4 wr_writeverf;
}; };
struct COPY4res { struct COPY4res {
nfsstat4 cr_status; nfsstat4 cr_status;
write_response4 cr_response; write_response4 cr_response;
bool cr_consecutive; bool cr_consecutive;
bool cr_synchronous; bool cr_synchronous;
}; };
<CODE ENDS>
15.2.3. DESCRIPTION 15.2.3. DESCRIPTION
The COPY operation is used for both intra-server and inter-server 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 copies. In both cases, the COPY is always sent from the client to
the destination server of the file copy. The COPY operation requests the destination server of the file copy. The COPY operation requests
that a file be copied from the location specified by the SAVED_FH that a file be copied from the location specified by the SAVED_FH
value to the location specified by the CURRENT_FH. value to the location specified by the CURRENT_FH.
The SAVED_FH must be a regular file. If SAVED_FH is not a regular 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. file, the operation MUST fail and return NFS4ERR_WRONG_TYPE.
skipping to change at page 61, line 24 skipping to change at page 62, line 39
value or preventing modification of the source file as mentioned value or preventing modification of the source file as mentioned
above). above).
If the source offset or the source offset plus count is greater than 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 or equal to the size of the source file, the operation will fail with
NFS4ERR_INVAL. The destination offset or destination offset plus NFS4ERR_INVAL. The destination offset or destination offset plus
count may be greater than the size of the destination file. This count may be greater than the size of the destination file. This
allows for the client to issue parallel copies to implement allows for the client to issue parallel copies to implement
operations such as operations such as
<CODE BEGINS>
% cat file1 file2 file3 file4 > dest % cat file1 file2 file3 file4 > dest
<CODE ENDS>
If the ca_source_server list is specified, then this is an inter- If the ca_source_server list is specified, then this is an inter-
server copy operation and the source file is on a remote server. The server copy operation and the source file is on a remote server. The
client is expected to have previously issued a successful COPY_NOTIFY client is expected to have previously issued a successful COPY_NOTIFY
request to the remote source server. The ca_source_server list MUST request to the remote source server. The ca_source_server list MUST
be the same as the COPY_NOTIFY response's cnr_source_server list. If be the same as the COPY_NOTIFY response's cnr_source_server list. If
the client includes the entries from the COPY_NOTIFY response's the client includes the entries from the COPY_NOTIFY response's
cnr_source_server list in the ca_source_server list, the source cnr_source_server list in the ca_source_server list, the source
server can indicate a specific copy protocol for the destination server can indicate a specific copy protocol for the destination
server to use by returning a URL, which specifies both a protocol server to use by returning a URL, which specifies both a protocol
service and server name. Server-to-server copy protocol service and server name. Server-to-server copy protocol
skipping to change at page 63, line 40 skipping to change at page 65, line 10
on the destination, then the last byte written to will determine the on the destination, then the last byte written to will determine the
new file size. The contents of any block not written to and past the new file size. The contents of any block not written to and past the
original size of the file will be as if a normal WRITE extended the original size of the file will be as if a normal WRITE extended the
file. file.
15.3. Operation 61: COPY_NOTIFY - Notify a source server of a future 15.3. Operation 61: COPY_NOTIFY - Notify a source server of a future
copy copy
15.3.1. ARGUMENT 15.3.1. ARGUMENT
<CODE BEGINS>
struct COPY_NOTIFY4args { struct COPY_NOTIFY4args {
/* CURRENT_FH: source file */ /* CURRENT_FH: source file */
stateid4 cna_src_stateid; stateid4 cna_src_stateid;
netloc4 cna_destination_server; netloc4 cna_destination_server;
}; };
<CODE ENDS>
15.3.2. RESULT 15.3.2. RESULT
<CODE BEGINS>
struct COPY_NOTIFY4resok { struct COPY_NOTIFY4resok {
nfstime4 cnr_lease_time; nfstime4 cnr_lease_time;
netloc4 cnr_source_server<>; netloc4 cnr_source_server<>;
}; };
union COPY_NOTIFY4res switch (nfsstat4 cnr_status) { union COPY_NOTIFY4res switch (nfsstat4 cnr_status) {
case NFS4_OK: case NFS4_OK:
COPY_NOTIFY4resok resok4; COPY_NOTIFY4resok resok4;
default: default:
void; void;
}; };
<CODE ENDS>
15.3.3. DESCRIPTION 15.3.3. DESCRIPTION
This operation is used for an inter-server copy. A client sends this This operation is used for an inter-server copy. A client sends this
operation in a COMPOUND request to the source server to authorize a operation in a COMPOUND request to the source server to authorize a
destination server identified by cna_destination_server to read the destination server identified by cna_destination_server to read the
file specified by CURRENT_FH on behalf of the given user. file specified by CURRENT_FH on behalf of the given user.
The cna_src_stateid MUST refer to either open or locking states The cna_src_stateid MUST refer to either open or locking states
provided earlier by the server. If it is invalid, then the operation provided earlier by the server. If it is invalid, then the operation
MUST fail. MUST fail.
skipping to change at page 65, line 15 skipping to change at page 66, line 40
be reachable from the client and might be located on networks to be reachable from the client and might be located on networks to
which the client has no connection. which the client has no connection.
For a copy only involving one server (the source and destination are For a copy only involving one server (the source and destination are
on the same server), this operation is unnecessary. on the same server), this operation is unnecessary.
15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region of a File 15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region of a File
15.4.1. ARGUMENT 15.4.1. ARGUMENT
<CODE BEGINS>
struct DEALLOCATE4args { struct DEALLOCATE4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
stateid4 da_stateid; stateid4 da_stateid;
offset4 da_offset; offset4 da_offset;
length4 da_length; length4 da_length;
}; };
<CODE ENDS>
15.4.2. RESULT 15.4.2. RESULT
<CODE BEGINS>
struct DEALLOCATE4res { struct DEALLOCATE4res {
nfsstat4 dr_status; nfsstat4 dr_status;
}; };
<CODE ENDS>
15.4.3. DESCRIPTION 15.4.3. DESCRIPTION
Whenever a client wishes to unreserve space for a region in a file it Whenever a client wishes to unreserve space for a region in a file it
calls the DEALLOCATE operation with the current filehandle set to the calls the DEALLOCATE operation with the current filehandle set to the
filehandle of the file in question, and the start offset and length filehandle of the file in question, and the start offset and length
in bytes of the region set in da_offset and da_length respectively. in bytes of the region set in da_offset and da_length respectively.
If no space was allocated or reserved for all or parts of the region, If no space was allocated or reserved for all or parts of the region,
the DEALLOCATE operation will have no effect for the region that the DEALLOCATE operation will have no effect for the region that
already is in unreserved state. All further reads from the region already is in unreserved state. All further reads from the region
passed to DEALLOCATE MUST return zeros until overwritten. The passed to DEALLOCATE MUST return zeros until overwritten. The
skipping to change at page 66, line 12 skipping to change at page 67, line 44
DEALLOCATE will result in the space_used attribute being decreased by DEALLOCATE will result in the space_used attribute being decreased by
the number of bytes that were deallocated. The space_freed attribute the number of bytes that were deallocated. The space_freed attribute
may or may not decrease, depending on the support and whether the may or may not decrease, depending on the support and whether the
blocks backing the specified range were shared or not. The size blocks backing the specified range were shared or not. The size
attribute will remain unchanged. attribute will remain unchanged.
15.5. Operation 63: IO_ADVISE - Application I/O access pattern hints 15.5. Operation 63: IO_ADVISE - Application I/O access pattern hints
15.5.1. ARGUMENT 15.5.1. ARGUMENT
<CODE BEGINS>
enum IO_ADVISE_type4 { enum IO_ADVISE_type4 {
IO_ADVISE4_NORMAL = 0, IO_ADVISE4_NORMAL = 0,
IO_ADVISE4_SEQUENTIAL = 1, IO_ADVISE4_SEQUENTIAL = 1,
IO_ADVISE4_SEQUENTIAL_BACKWARDS = 2, IO_ADVISE4_SEQUENTIAL_BACKWARDS = 2,
IO_ADVISE4_RANDOM = 3, IO_ADVISE4_RANDOM = 3,
IO_ADVISE4_WILLNEED = 4, IO_ADVISE4_WILLNEED = 4,
IO_ADVISE4_WILLNEED_OPPORTUNISTIC = 5, IO_ADVISE4_WILLNEED_OPPORTUNISTIC = 5,
IO_ADVISE4_DONTNEED = 6, IO_ADVISE4_DONTNEED = 6,
IO_ADVISE4_NOREUSE = 7, IO_ADVISE4_NOREUSE = 7,
IO_ADVISE4_READ = 8, IO_ADVISE4_READ = 8,
skipping to change at page 66, line 34 skipping to change at page 68, line 26
}; };
struct IO_ADVISE4args { struct IO_ADVISE4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
stateid4 iaa_stateid; stateid4 iaa_stateid;
offset4 iaa_offset; offset4 iaa_offset;
length4 iaa_count; length4 iaa_count;
bitmap4 iaa_hints; bitmap4 iaa_hints;
}; };
<CODE ENDS>
15.5.2. RESULT 15.5.2. RESULT
<CODE BEGINS>
struct IO_ADVISE4resok { struct IO_ADVISE4resok {
bitmap4 ior_hints; bitmap4 ior_hints;
}; };
union IO_ADVISE4res switch (nfsstat4 ior_status) { union IO_ADVISE4res switch (nfsstat4 ior_status) {
case NFS4_OK: case NFS4_OK:
IO_ADVISE4resok resok4; IO_ADVISE4resok resok4;
default: default:
void; void;
}; };
<CODE ENDS>
15.5.3. DESCRIPTION 15.5.3. DESCRIPTION
The IO_ADVISE operation sends an I/O access pattern hint to the The IO_ADVISE operation sends an I/O access pattern hint to the
server for the owner of the stateid for a given byte range specified server for the owner of the stateid for a given byte range specified
by iar_offset and iar_count. The byte range specified by iaa_offset by iar_offset and iar_count. The byte range specified by iaa_offset
and iaa_count need not currently exist in the file, but the iaa_hints and iaa_count need not currently exist in the file, but the iaa_hints
will apply to the byte range when it does exist. If iaa_count is 0, will apply to the byte range when it does exist. If iaa_count is 0,
all data following iaa_offset is specified. The server MAY ignore all data following iaa_offset is specified. The server MAY ignore
the advice. the advice.
skipping to change at page 71, line 35 skipping to change at page 73, line 35
that the data server does not serve MUST NOT result in the status that the data server does not serve MUST NOT result in the status
NFS4ERR_PNFS_IO_HOLE. Instead, the response SHOULD be successful and NFS4ERR_PNFS_IO_HOLE. Instead, the response SHOULD be successful and
if the server applies IO_ADVISE hints on any stripe units that if the server applies IO_ADVISE hints on any stripe units that
overlap with the specified range, those hints SHOULD be indicated in overlap with the specified range, those hints SHOULD be indicated in
the response. the response.
15.6. Operation 64: LAYOUTERROR - Provide Errors for the Layout 15.6. Operation 64: LAYOUTERROR - Provide Errors for the Layout
15.6.1. ARGUMENT 15.6.1. ARGUMENT
<CODE BEGINS>
struct device_error4 { struct device_error4 {
deviceid4 de_deviceid; deviceid4 de_deviceid;
nfsstat4 de_status; nfsstat4 de_status;
nfs_opnum4 de_opnum; nfs_opnum4 de_opnum;
}; };
struct LAYOUTERROR4args { struct LAYOUTERROR4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
offset4 lea_offset; offset4 lea_offset;
length4 lea_length; length4 lea_length;
stateid4 lea_stateid; stateid4 lea_stateid;
device_error4 lea_errors; device_error4 lea_errors;
}; };
<CODE ENDS>
15.6.2. RESULT 15.6.2. RESULT
<CODE BEGINS>
struct LAYOUTERROR4res { struct LAYOUTERROR4res {
nfsstat4 ler_status; nfsstat4 ler_status;
}; };
<CODE ENDS>
15.6.3. DESCRIPTION 15.6.3. DESCRIPTION
The client can use LAYOUTERROR to inform the metadata server about The client can use LAYOUTERROR to inform the metadata server about
errors in its interaction with the layout represented by the current errors in its interaction with the layout represented by the current
filehandle, client ID (derived from the session ID in the preceding filehandle, client ID (derived from the session ID in the preceding
SEQUENCE operation), byte-range (lea_offset + lea_length), and SEQUENCE operation), byte-range (lea_offset + lea_length), and
lea_stateid. lea_stateid.
Each individual device_error4 describes a single error associated Each individual device_error4 describes a single error associated
with a storage device, which is identified via de_deviceid. If the with a storage device, which is identified via de_deviceid. If the
skipping to change at page 74, line 27 skipping to change at page 76, line 39
The metadata server is not required to indefinitely retain per-client The metadata server is not required to indefinitely retain per-client
storage device error information. An metadata server is also not storage device error information. An metadata server is also not
required to automatically reinstate use of a previously problematic required to automatically reinstate use of a previously problematic
storage device; administrative intervention may be required instead. storage device; administrative intervention may be required instead.
15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the Layout 15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the Layout
15.7.1. ARGUMENT 15.7.1. ARGUMENT
<CODE BEGINS>
struct layoutupdate4 { struct layoutupdate4 {
layouttype4 lou_type; layouttype4 lou_type;
opaque lou_body<>; opaque lou_body<>;
}; };
struct io_info4 { struct io_info4 {
uint32_t ii_count; uint32_t ii_count;
uint64_t ii_bytes; uint64_t ii_bytes;
}; };
struct LAYOUTSTATS4args { struct LAYOUTSTATS4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
offset4 lsa_offset; offset4 lsa_offset;
length4 lsa_length; length4 lsa_length;
stateid4 lsa_stateid; stateid4 lsa_stateid;
io_info4 lsa_read; io_info4 lsa_read;
io_info4 lsa_write; io_info4 lsa_write;
deviceid4 lsa_deviceid;
layoutupdate4 lsa_layoutupdate; layoutupdate4 lsa_layoutupdate;
}; };
<CODE ENDS>
15.7.2. RESULT 15.7.2. RESULT
<CODE BEGINS>
struct LAYOUTSTATS4res { struct LAYOUTSTATS4res {
nfsstat4 lsr_status; nfsstat4 lsr_status;
}; };
<CODE ENDS>
15.7.3. DESCRIPTION 15.7.3. DESCRIPTION
The client can use LAYOUTSTATS to inform the metadata server about The client can use LAYOUTSTATS to inform the metadata server about
its interaction with the layout represented by the current its interaction with the layout represented by the current
filehandle, client ID (derived from the session ID in the preceding filehandle, client ID (derived from the session ID in the preceding
SEQUENCE operation), byte-range (lea_offset + lea_length), and SEQUENCE operation), byte-range (lsa_offset and lsa_length), and
lea_stateid. lsa_read and lsa_write allow for non-Layout Type lsa_stateid. lsa_read and lsa_write allow for non-Layout Type
specific statistics to be reported. The remaining information the specific statistics to be reported. lsa_deviceid allows the client
client is presenting is specific to the Layout Type and presented in to specify to which storage device the statistics apply. The
the lea_layoutupdate field. Each Layout Type MUST define the remaining information the client is presenting is specific to the
contents of lea_layoutupdate in their respective specifications. Layout Type and presented in the lsa_layoutupdate field. Each Layout
Type MUST define the contents of lsa_layoutupdate in their respective
specifications.
LAYOUTSTATS can be combined with IO_ADVISE (see Section 15.5) to LAYOUTSTATS can be combined with IO_ADVISE (see Section 15.5) to
augment the decision making process of how the metadata server augment the decision making process of how the metadata server
handles a file. I.e., IO_ADVISE lets the server know that a byte handles a file. I.e., IO_ADVISE lets the server know that a byte
range has a certain characteristic, but not necessarily the intensity range has a certain characteristic, but not necessarily the intensity
of that characteristic. of that characteristic.
The client MUST reset the statistics after getting a successfully The client MUST reset the statistics after getting a successfully
reply from the metadata server. The first LAYOUTSTATS sent by the reply from the metadata server. The first LAYOUTSTATS sent by the
client SHOULD be from the opening of the file. The choice of how client SHOULD be from the opening of the file. The choice of how
often to update the metadata server is made by the client. often to update the metadata server is made by the client.
Note that while the metadata server may return an error associated Note that while the metadata server may return an error associated
with the layout stateid or the open file, it MUST NOT return an error with the layout stateid or the open file, it MUST NOT return an error
in the processing of the statistics. in the processing of the statistics.
15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded Operation 15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded Operation
15.8.1. ARGUMENT 15.8.1. ARGUMENT
<CODE BEGINS>
struct OFFLOAD_CANCEL4args { struct OFFLOAD_CANCEL4args {
/* CURRENT_FH: file to cancel */ /* CURRENT_FH: file to cancel */
stateid4 oca_stateid; stateid4 oca_stateid;
}; };
<CODE ENDS>
15.8.2. RESULT 15.8.2. RESULT
<CODE BEGINS>
struct OFFLOAD_CANCEL4res { struct OFFLOAD_CANCEL4res {
nfsstat4 ocr_status; nfsstat4 ocr_status;
}; };
<CODE ENDS>
15.8.3. DESCRIPTION 15.8.3. DESCRIPTION
OFFLOAD_CANCEL is used by the client to terminate an asynchronous OFFLOAD_CANCEL is used by the client to terminate an asynchronous
operation, which is identified both by CURRENT_FH and the operation, which is identified both by CURRENT_FH and the
oca_stateid. I.e., there can be multiple offloaded operations acting oca_stateid. I.e., there can be multiple offloaded operations acting
on the file, the stateid will identify to the server exactly which on the file, the stateid will identify to the server exactly which
one is to be stopped. Currently there are only two operations which one is to be stopped. Currently there are only two operations which
can decide to be asynchronous: COPY and WRITE_SAME. can decide to be asynchronous: COPY and WRITE_SAME.
In the context of server-to-server copy, the client can send In the context of server-to-server copy, the client can send
skipping to change at page 76, line 32 skipping to change at page 79, line 15
OFFLOAD_CANCEL is also useful in situations in which the source OFFLOAD_CANCEL is also useful in situations in which the source
server granted a very long or infinite lease on the destination server granted a very long or infinite lease on the destination
server's ability to read the source file and all copy operations on server's ability to read the source file and all copy operations on
the source file have been completed. the source file have been completed.
15.9. Operation 67: OFFLOAD_STATUS - Poll for Status of Asynchronous 15.9. Operation 67: OFFLOAD_STATUS - Poll for Status of Asynchronous
Operation Operation
15.9.1. ARGUMENT 15.9.1. ARGUMENT
<CODE BEGINS>
struct OFFLOAD_STATUS4args { struct OFFLOAD_STATUS4args {
/* CURRENT_FH: destination file */ /* CURRENT_FH: destination file */
stateid4 osa_stateid; stateid4 osa_stateid;
}; };
<CODE ENDS>
15.9.2. RESULT 15.9.2. RESULT
<CODE BEGINS>
struct OFFLOAD_STATUS4resok { struct OFFLOAD_STATUS4resok {
length4 osr_count; length4 osr_count;
nfsstat4 osr_complete<1>; nfsstat4 osr_complete<1>;
}; };
union OFFLOAD_STATUS4res switch (nfsstat4 osr_status) { union OFFLOAD_STATUS4res switch (nfsstat4 osr_status) {
case NFS4_OK: case NFS4_OK:
OFFLOAD_STATUS4resok osr_resok4; OFFLOAD_STATUS4resok osr_resok4;
default: default:
void; void;
}; };
<CODE ENDS>
15.9.3. DESCRIPTION 15.9.3. DESCRIPTION
OFFLOAD_STATUS can be used by the client to query the progress of an OFFLOAD_STATUS can be used by the client to query the progress of an
asynchronous operation, which is identified both by CURRENT_FH and asynchronous operation, which is identified both by CURRENT_FH and
the osa_stateid. If this operation is successful, the number of the osa_stateid. If this operation is successful, the number of
bytes processed are returned to the client in the osr_count field. bytes processed are returned to the client in the osr_count field.
If the optional osr_complete field is present, the asynchronous If the optional osr_complete field is present, the asynchronous
operation has completed. In this case the status value indicates the operation has completed. In this case the status value indicates the
result of the asynchronous operation. In all cases, the server will result of the asynchronous operation. In all cases, the server will
also deliver the final results of the asynchronous operation in a also deliver the final results of the asynchronous operation in a
CB_OFFLOAD operation. CB_OFFLOAD operation.
The failure of this operation does not indicate the result of the The failure of this operation does not indicate the result of the
asynchronous operation in any way. asynchronous operation in any way.
15.10. Operation 68: READ_PLUS - READ Data or Holes from a File 15.10. Operation 68: READ_PLUS - READ Data or Holes from a File
15.10.1. ARGUMENT 15.10.1. ARGUMENT
<CODE BEGINS>
struct READ_PLUS4args { struct READ_PLUS4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
stateid4 rpa_stateid; stateid4 rpa_stateid;
offset4 rpa_offset; offset4 rpa_offset;
count4 rpa_count; count4 rpa_count;
}; };
<CODE ENDS>
15.10.2. RESULT 15.10.2. RESULT
<CODE BEGINS>
enum data_content4 { enum data_content4 {
NFS4_CONTENT_DATA = 0, NFS4_CONTENT_DATA = 0,
NFS4_CONTENT_HOLE = 1 NFS4_CONTENT_HOLE = 1
}; };
struct data_info4 { struct data_info4 {
offset4 di_offset; offset4 di_offset;
length4 di_length; length4 di_length;
}; };
skipping to change at page 78, line 28 skipping to change at page 81, line 28
read_plus_content rpr_contents<>; read_plus_content rpr_contents<>;
}; };
union READ_PLUS4res switch (nfsstat4 rp_status) { union READ_PLUS4res switch (nfsstat4 rp_status) {
case NFS4_OK: case NFS4_OK:
read_plus_res4 rp_resok4; read_plus_res4 rp_resok4;
default: default:
void; void;
}; };
<CODE ENDS>
15.10.3. DESCRIPTION 15.10.3. DESCRIPTION
The READ_PLUS operation is based upon the NFSv4.1 READ operation (see The READ_PLUS operation is based upon the NFSv4.1 READ operation (see
Section 18.22 of [RFC5661]) and similarly reads data from the regular Section 18.22 of [RFC5661]) and similarly reads data from the regular
file identified by the current filehandle. file identified by the current filehandle.
The client provides a rpa_offset of where the READ_PLUS is to start The client provides a rpa_offset of where the READ_PLUS is to start
and a rpa_count of how many bytes are to be read. A rpa_offset of and a rpa_count of how many bytes are to be read. A rpa_offset of
zero means to read data starting at the beginning of the file. If zero means to read data starting at the beginning of the file. If
rpa_offset is greater than or equal to the size of the file, the rpa_offset is greater than or equal to the size of the file, the
skipping to change at page 82, line 9 skipping to change at page 85, line 9
the hole which extends to 354K. the hole which extends to 354K.
4. READ_PLUS(s, 354K, 64K) --> NFS_OK, eof = true, <data[354K, 4. READ_PLUS(s, 354K, 64K) --> NFS_OK, eof = true, <data[354K,
418K]>. Returns the final 64K of data and informs the client 418K]>. Returns the final 64K of data and informs the client
there is no more data in the file. there is no more data in the file.
15.11. Operation 69: SEEK - Find the Next Data or Hole 15.11. Operation 69: SEEK - Find the Next Data or Hole
15.11.1. ARGUMENT 15.11.1. ARGUMENT
<CODE BEGINS>
enum data_content4 { enum data_content4 {
NFS4_CONTENT_DATA = 0, NFS4_CONTENT_DATA = 0,
NFS4_CONTENT_HOLE = 1 NFS4_CONTENT_HOLE = 1
}; };
struct SEEK4args { struct SEEK4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
stateid4 sa_stateid; stateid4 sa_stateid;
offset4 sa_offset; offset4 sa_offset;
data_content4 sa_what; data_content4 sa_what;
}; };
<CODE ENDS>
15.11.2. RESULT 15.11.2. RESULT
<CODE BEGINS>
struct seek_res4 { struct seek_res4 {
bool sr_eof; bool sr_eof;
offset4 sr_offset; offset4 sr_offset;
}; };
union SEEK4res switch (nfsstat4 sa_status) { union SEEK4res switch (nfsstat4 sa_status) {
case NFS4_OK: case NFS4_OK:
seek_res4 resok4; seek_res4 resok4;
default: default:
void; void;
}; };
<CODE ENDS>
15.11.3. DESCRIPTION 15.11.3. DESCRIPTION
SEEK is an operation that allows a client to determine the location SEEK is an operation that allows a client to determine the location
of the next data_content4 in a file. It allows an implementation of of the next data_content4 in a file. It allows an implementation of
the emerging extension to lseek(2) to allow clients to determine the the emerging extension to lseek(2) to allow clients to determine the
next hole whilst in data or the next data whilst in a hole. next hole whilst in data or the next data whilst in a hole.
From the given sa_offset, find the next data_content4 of type sa_what From the given sa_offset, find the next data_content4 of type sa_what
in the file. If the server can not find a corresponding sa_what, in the file. If the server can not find a corresponding sa_what,
then the status will still be NFS4_OK, but sr_eof would be TRUE. If then the status will still be NFS4_OK, but sr_eof would be TRUE. If
skipping to change at page 83, line 12 skipping to change at page 86, line 20
{SEEK 0 NFS4_CONTENT_HOLE;} would return a result of {SEEK 1 X;} {SEEK 0 NFS4_CONTENT_HOLE;} would return a result of {SEEK 1 X;}
where 'X' was the size of the file. where 'X' was the size of the file.
SEEK must follow the same rules for stateids as READ_PLUS SEEK must follow the same rules for stateids as READ_PLUS
(Section 15.10.3). (Section 15.10.3).
15.12. Operation 70: WRITE_SAME - WRITE an ADB Multiple Times to a File 15.12. Operation 70: WRITE_SAME - WRITE an ADB Multiple Times to a File
15.12.1. ARGUMENT 15.12.1. ARGUMENT
<CODE BEGINS>
enum stable_how4 { enum stable_how4 {
UNSTABLE4 = 0, UNSTABLE4 = 0,
DATA_SYNC4 = 1, DATA_SYNC4 = 1,
FILE_SYNC4 = 2 FILE_SYNC4 = 2
}; };
struct app_data_block4 { struct app_data_block4 {
offset4 adb_offset; offset4 adb_offset;
length4 adb_block_size; length4 adb_block_size;
length4 adb_block_count; length4 adb_block_count;
skipping to change at page 83, line 35 skipping to change at page 86, line 45
opaque adb_pattern<>; opaque adb_pattern<>;
}; };
struct WRITE_SAME4args { struct WRITE_SAME4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
stateid4 wsa_stateid; stateid4 wsa_stateid;
stable_how4 wsa_stable; stable_how4 wsa_stable;
app_data_block4 wsa_adb; app_data_block4 wsa_adb;
}; };
<CODE ENDS>
15.12.2. RESULT 15.12.2. RESULT
<CODE BEGINS>
struct write_response4 { struct write_response4 {
stateid4 wr_callback_id<1>; stateid4 wr_callback_id<1>;
length4 wr_count; length4 wr_count;
stable_how4 wr_committed; stable_how4 wr_committed;
verifier4 wr_writeverf; verifier4 wr_writeverf;
}; };
union WRITE_SAME4res switch (nfsstat4 wsr_status) { union WRITE_SAME4res switch (nfsstat4 wsr_status) {
case NFS4_OK: case NFS4_OK:
write_response4 resok4; write_response4 resok4;
default: default:
void; void;
}; };
<CODE ENDS>
15.12.3. DESCRIPTION 15.12.3. DESCRIPTION
The WRITE_SAME operation writes an application data block to the The WRITE_SAME operation writes an application data block to the
regular file identified by the current filehandle (see WRITE SAME regular file identified by the current filehandle (see WRITE SAME
(10) in [T10-SBC2]). The target file is specified by the current (10) in [T10-SBC2]). The target file is specified by the current
filehandle. The data to be written is specified by an filehandle. The data to be written is specified by an
app_data_block4 structure (Section 8.1.1). The client specifies with app_data_block4 structure (Section 8.1.1). The client specifies with
the wsa_stable parameter the method of how the data is to be the wsa_stable parameter the method of how the data is to be
processed by the server. It is treated like the stable parameter in processed by the server. It is treated like the stable parameter in
the NFSv4.1 WRITE operation (see Section 18.2 of [RFC5661]). the NFSv4.1 WRITE operation (see Section 18.2 of [RFC5661]).
skipping to change at page 86, line 34 skipping to change at page 90, line 12
be easy for the client to determine in case of a partially complete be easy for the client to determine in case of a partially complete
WRITE_SAME. WRITE_SAME.
16. NFSv4.2 Callback Operations 16. NFSv4.2 Callback Operations
16.1. Operation 15: CB_OFFLOAD - Report results of an asynchronous 16.1. Operation 15: CB_OFFLOAD - Report results of an asynchronous
operation operation
16.1.1. ARGUMENT 16.1.1. ARGUMENT
<CODE BEGINS>
struct write_response4 { struct write_response4 {
stateid4 wr_callback_id<1>; stateid4 wr_callback_id<1>;
length4 wr_count; length4 wr_count;
stable_how4 wr_committed; stable_how4 wr_committed;
verifier4 wr_writeverf; verifier4 wr_writeverf;
}; };
union offload_info4 switch (nfsstat4 coa_status) { union offload_info4 switch (nfsstat4 coa_status) {
case NFS4_OK: case NFS4_OK:
write_response4 coa_resok4; write_response4 coa_resok4;
skipping to change at page 87, line 4 skipping to change at page 90, line 27
stable_how4 wr_committed; stable_how4 wr_committed;
verifier4 wr_writeverf; verifier4 wr_writeverf;
}; };
union offload_info4 switch (nfsstat4 coa_status) { union offload_info4 switch (nfsstat4 coa_status) {
case NFS4_OK: case NFS4_OK:
write_response4 coa_resok4; write_response4 coa_resok4;
default: default:
length4 coa_bytes_copied; length4 coa_bytes_copied;
}; };
struct CB_OFFLOAD4args { struct CB_OFFLOAD4args {
nfs_fh4 coa_fh; nfs_fh4 coa_fh;
stateid4 coa_stateid; stateid4 coa_stateid;
offload_info4 coa_offload_info; offload_info4 coa_offload_info;
}; };
<CODE ENDS>
16.1.2. RESULT 16.1.2. RESULT
<CODE BEGINS>
struct CB_OFFLOAD4res { struct CB_OFFLOAD4res {
nfsstat4 cor_status; nfsstat4 cor_status;
}; };
<CODE ENDS>
16.1.3. DESCRIPTION 16.1.3. DESCRIPTION
CB_OFFLOAD is used to report to the client the results of an CB_OFFLOAD is used to report to the client the results of an
asynchronous operation, e.g., Server Side Copy or WRITE_SAME. The asynchronous operation, e.g., Server Side Copy or WRITE_SAME. The
coa_fh and coa_stateid identify the transaction and the coa_status coa_fh and coa_stateid identify the transaction and the coa_status
indicates success or failure. The coa_resok4.wr_callback_id MUST NOT indicates success or failure. The coa_resok4.wr_callback_id MUST NOT
be set. If the transaction failed, then the coa_bytes_copied be set. If the transaction failed, then the coa_bytes_copied
contains the number of bytes copied before the failure occurred. The contains the number of bytes copied before the failure occurred. The
coa_bytes_copied value indicates the number of bytes copied but not coa_bytes_copied value indicates the number of bytes copied but not
which specific bytes have been copied. which specific bytes have been copied.
skipping to change at page 88, line 16 skipping to change at page 91, line 46
The IANA Considerations for Labeled NFS are addressed in [Quigley14]. The IANA Considerations for Labeled NFS are addressed in [Quigley14].
19. References 19. References
19.1. Normative References 19.1. Normative References
[NFSv42xdr] [NFSv42xdr]
Haynes, T., "Network File System (NFS) Version 4 Minor Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 External Data Representation Standard (XDR) Version 2 External Data Representation Standard (XDR)
Description", November 2014. Description", December 2014.
[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, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 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", RFC System (NFS) Version 4 Minor Version 1 Protocol", RFC
5661, January 2010. 5661, January 2010.
[RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5662] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 External Data System (NFS) Version 4 Minor Version 1 External Data
Representation Standard (XDR) Description", RFC 5662, Representation Standard (XDR) Description", RFC 5662,
January 2010. January 2010.
[RFC5664] Halevy, B., Welch, B., and J. Zelenka, "Object-Based
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.
[posix_fallocate] [posix_fallocate]
The Open Group, "Section 'posix_fallocate()' of System The Open Group, "Section 'posix_fallocate()' 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] [rpcsec_gssv3]
Adamson, W. and N. Williams, "Remote Procedure Call (RPC) Adamson, W. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", November 2014. Security Version 3", December 2014.
19.2. Informative References 19.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.
[BL73] Bell, D. and L. LaPadula, "Secure Computer Systems: [BL73] Bell, D. and L. LaPadula, "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report Mathematical Foundations and Model", Technical Report
M74-244, The MITRE Corporation, Bedford, MA, May 1973. M74-244, The MITRE Corporation, Bedford, MA, May 1973.
[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
USENIX Symposium on File and Storage Technologies (FAST USENIX Symposium on File and Storage Technologies (FAST
'08) , 2008. '08) , 2008.
[I-D.ietf-nfsv4-rfc3530bis] [I-D.ietf-nfsv4-rfc3530bis]
Haynes, T. and D. Noveck, "Network File System (NFS) Haynes, T. and D. Noveck, "Network File System (NFS)
version 4 Protocol", draft-ietf-nfsv4-rfc3530bis-33 (Work version 4 Protocol", draft-ietf-nfsv4-rfc3530bis-35 (Work
In Progress), April 2014. In Progress), November 2014.
[IESG08] ISEG, "IESG Processing of RFC Errata for the IETF Stream", [IESG08] ISEG, "IESG Processing of RFC Errata for the IETF Stream",
2008. 2008.
[McDougall07] [McDougall07]
McDougall, R. and J. Mauro, "Section 11.4.3, Detecting McDougall, R. and J. Mauro, "Section 11.4.3, Detecting
Memory Corruption of Solaris Internals", 2007. Memory Corruption of Solaris Internals", 2007.
[NFSv4-Versioning] [NFSv4-Versioning]
Haynes, T. and D. Noveck, "NFSv4 Version Management", Haynes, T. and D. Noveck, "NFSv4 Version Management",
 End of changes. 117 change blocks. 
92 lines changed or deleted 237 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/