< draft-ietf-nfsv4-minorversion1-28.txt   draft-ietf-nfsv4-minorversion1-29.txt >
NFSv4 S. Shepler NFSv4 S. Shepler
Internet-Draft M. Eisler Internet-Draft M. Eisler
Intended status: Standards Track D. Noveck Intended status: Standards Track D. Noveck
Expires: June 7, 2009 Editors Expires: June 18, 2009 Editors
December 04, 2008 December 15, 2008
NFS Version 4 Minor Version 1 NFS Version 4 Minor Version 1
draft-ietf-nfsv4-minorversion1-28.txt draft-ietf-nfsv4-minorversion1-29.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 7, 2009. This Internet-Draft will expire on June 18, 2009.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document describes NFS version 4 minor version one, including This document describes NFS version 4 minor version one, including
features retained from the base protocol (NFS version 4 minor version features retained from the base protocol (NFS version 4 minor version
zero which is specified in RFC3530) and protocol extensions made zero which is specified in RFC3530) and protocol extensions made
subsequently. Major extensions introduced in NFS version 4 minor subsequently. Major extensions introduced in NFS version 4 minor
version one include: Sessions, Directory Delegations, and parallel version one include: Sessions, Directory Delegations, and parallel
NFS (pNFS). NFS version 4 minor version one has no dependencies on NFS (pNFS). NFS version 4 minor version one has no dependencies on
NFS version 4 minor version zero, and is considered a separate NFS version 4 minor version zero, and is considered a separate
skipping to change at page 2, line 14 skipping to change at page 3, line 7
on the same network, between the same client and server. on the same network, between the same client and server.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1. The NFS Version 4 Minor Version 1 Protocol . . . . . . . 11 1.1. The NFS Version 4 Minor Version 1 Protocol . . . . . . . 12
1.2. Scope of this Document . . . . . . . . . . . . . . . . . 11 1.2. Scope of this Document . . . . . . . . . . . . . . . . . 12
1.3. NFSv4 Goals . . . . . . . . . . . . . . . . . . . . . . 11 1.3. NFSv4 Goals . . . . . . . . . . . . . . . . . . . . . . 12
1.4. NFSv4.1 Goals . . . . . . . . . . . . . . . . . . . . . 12 1.4. NFSv4.1 Goals . . . . . . . . . . . . . . . . . . . . . 13
1.5. General Definitions . . . . . . . . . . . . . . . . . . 12 1.5. General Definitions . . . . . . . . . . . . . . . . . . 13
1.6. Overview of NFSv4.1 Features . . . . . . . . . . . . . . 15 1.6. Overview of NFSv4.1 Features . . . . . . . . . . . . . . 16
1.6.1. RPC and Security . . . . . . . . . . . . . . . . . . 15 1.6.1. RPC and Security . . . . . . . . . . . . . . . . . . 16
1.6.2. Protocol Structure . . . . . . . . . . . . . . . . . 16 1.6.2. Protocol Structure . . . . . . . . . . . . . . . . . 17
1.6.3. File System Model . . . . . . . . . . . . . . . . . 16 1.6.3. File System Model . . . . . . . . . . . . . . . . . 17
1.6.4. Locking Facilities . . . . . . . . . . . . . . . . . 18 1.6.4. Locking Facilities . . . . . . . . . . . . . . . . . 19
1.7. Differences from NFSv4.0 . . . . . . . . . . . . . . . . 19 1.7. Differences from NFSv4.0 . . . . . . . . . . . . . . . . 20
2. Core Infrastructure . . . . . . . . . . . . . . . . . . . . . 20 2. Core Infrastructure . . . . . . . . . . . . . . . . . . . . . 21
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 21
2.2. RPC and XDR . . . . . . . . . . . . . . . . . . . . . . 20 2.2. RPC and XDR . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1. RPC-based Security . . . . . . . . . . . . . . . . . 20 2.2.1. RPC-based Security . . . . . . . . . . . . . . . . . 21
2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 23 2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 24
2.4. Client Identifiers and Client Owners . . . . . . . . . . 24 2.4. Client Identifiers and Client Owners . . . . . . . . . . 25
2.4.1. Upgrade from NFSv4.0 to NFSv4.1 . . . . . . . . . . 28 2.4.1. Upgrade from NFSv4.0 to NFSv4.1 . . . . . . . . . . 29
2.4.2. Server Release of Client ID . . . . . . . . . . . . 28 2.4.2. Server Release of Client ID . . . . . . . . . . . . 29
2.4.3. Resolving Client Owner Conflicts . . . . . . . . . . 29 2.4.3. Resolving Client Owner Conflicts . . . . . . . . . . 30
2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . 30 2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . 31
2.6. Security Service Negotiation . . . . . . . . . . . . . . 30 2.6. Security Service Negotiation . . . . . . . . . . . . . . 31
2.6.1. NFSv4.1 Security Tuples . . . . . . . . . . . . . . 31 2.6.1. NFSv4.1 Security Tuples . . . . . . . . . . . . . . 32
2.6.2. SECINFO and SECINFO_NO_NAME . . . . . . . . . . . . 31 2.6.2. SECINFO and SECINFO_NO_NAME . . . . . . . . . . . . 32
2.6.3. Security Error . . . . . . . . . . . . . . . . . . . 31 2.6.3. Security Error . . . . . . . . . . . . . . . . . . . 32
2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 36 2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 37
2.8. Non-RPC-based Security Services . . . . . . . . . . . . 38 2.8. Non-RPC-based Security Services . . . . . . . . . . . . 39
2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 38 2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 39
2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 38 2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 39
2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 39 2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 40
2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 39 2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 40
2.9.1. REQUIRED and RECOMMENDED Properties of Transports . 39 2.9.1. REQUIRED and RECOMMENDED Properties of Transports . 40
2.9.2. Client and Server Transport Behavior . . . . . . . . 40 2.9.2. Client and Server Transport Behavior . . . . . . . . 41
2.9.3. Ports . . . . . . . . . . . . . . . . . . . . . . . 41 2.9.3. Ports . . . . . . . . . . . . . . . . . . . . . . . 42
2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . 41 2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . 42
2.10.1. Motivation and Overview . . . . . . . . . . . . . . 41 2.10.1. Motivation and Overview . . . . . . . . . . . . . . 42
2.10.2. NFSv4 Integration . . . . . . . . . . . . . . . . . 43 2.10.2. NFSv4 Integration . . . . . . . . . . . . . . . . . 44
2.10.3. Channels . . . . . . . . . . . . . . . . . . . . . . 44 2.10.3. Channels . . . . . . . . . . . . . . . . . . . . . . 45
2.10.4. Server Scope . . . . . . . . . . . . . . . . . . . . 45 2.10.4. Server Scope . . . . . . . . . . . . . . . . . . . . 46
2.10.5. Trunking . . . . . . . . . . . . . . . . . . . . . . 48 2.10.5. Trunking . . . . . . . . . . . . . . . . . . . . . . 49
2.10.6. Exactly Once Semantics . . . . . . . . . . . . . . . 51 2.10.6. Exactly Once Semantics . . . . . . . . . . . . . . . 52
2.10.7. RDMA Considerations . . . . . . . . . . . . . . . . 64 2.10.7. RDMA Considerations . . . . . . . . . . . . . . . . 65
2.10.8. Sessions Security . . . . . . . . . . . . . . . . . 67 2.10.8. Sessions Security . . . . . . . . . . . . . . . . . 68
2.10.9. The Secret State Verifier (SSV) GSS Mechanism . . . 72 2.10.9. The Secret State Verifier (SSV) GSS Mechanism . . . 73
2.10.10. Session Mechanics - Steady State . . . . . . . . . . 76 2.10.10. Session Mechanics - Steady State . . . . . . . . . . 77
2.10.11. Session Inactivity Timer . . . . . . . . . . . . . . 78 2.10.11. Session Inactivity Timer . . . . . . . . . . . . . . 79
2.10.12. Session Mechanics - Recovery . . . . . . . . . . . . 78 2.10.12. Session Mechanics - Recovery . . . . . . . . . . . . 80
2.10.13. Parallel NFS and Sessions . . . . . . . . . . . . . 83 2.10.13. Parallel NFS and Sessions . . . . . . . . . . . . . 84
3. Protocol Constants and Data Types . . . . . . . . . . . . . . 84 3. Protocol Constants and Data Types . . . . . . . . . . . . . . 85
3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . 84 3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . 85
3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 85 3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 86
3.3. Structured Data Types . . . . . . . . . . . . . . . . . 86 3.3. Structured Data Types . . . . . . . . . . . . . . . . . 87
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 95 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 95 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 96
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 95 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 96
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 96 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 97
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 96 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 97
4.2.1. General Properties of a Filehandle . . . . . . . . . 97 4.2.1. General Properties of a Filehandle . . . . . . . . . 98
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 97 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 98
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 98 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 99
4.3. One Method of Constructing a Volatile Filehandle . . . . 99 4.3. One Method of Constructing a Volatile Filehandle . . . . 100
4.4. Client Recovery from Filehandle Expiration . . . . . . . 99 4.4. Client Recovery from Filehandle Expiration . . . . . . . 100
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 100 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 101
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 102 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 103
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 102 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 103
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 102 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 103
5.4. Classification of Attributes . . . . . . . . . . . . . . 104 5.4. Classification of Attributes . . . . . . . . . . . . . . 105
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 105 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 106
5.6. REQUIRED Attributes - List and Definition References . . 105 5.6. REQUIRED Attributes - List and Definition References . . 106
5.7. RECOMMENDED Attributes - List and Definition 5.7. RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 106 References . . . . . . . . . . . . . . . . . . . . . . . 107
5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 108 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 109
5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 108 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 109
5.8.2. Definitions of Uncategorized RECOMMENDED 5.8.2. Definitions of Uncategorized RECOMMENDED
Attributes . . . . . . . . . . . . . . . . . . . . . 110 Attributes . . . . . . . . . . . . . . . . . . . . . 111
5.9. Interpreting owner and owner_group . . . . . . . . . . . 116 5.9. Interpreting owner and owner_group . . . . . . . . . . . 117
5.10. Character Case Attributes . . . . . . . . . . . . . . . 118 5.10. Character Case Attributes . . . . . . . . . . . . . . . 119
5.11. Directory Notification Attributes . . . . . . . . . . . 119 5.11. Directory Notification Attributes . . . . . . . . . . . 120
5.12. pNFS Attribute Definitions . . . . . . . . . . . . . . . 119 5.12. pNFS Attribute Definitions . . . . . . . . . . . . . . . 120
5.13. Retention Attributes . . . . . . . . . . . . . . . . . . 121 5.13. Retention Attributes . . . . . . . . . . . . . . . . . . 122
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 124 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 125
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 125 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 126
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 125 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 126
6.2.2. Attribute 58: dacl . . . . . . . . . . . . . . . . . 140 6.2.2. Attribute 58: dacl . . . . . . . . . . . . . . . . . 141
6.2.3. Attribute 59: sacl . . . . . . . . . . . . . . . . . 140 6.2.3. Attribute 59: sacl . . . . . . . . . . . . . . . . . 141
6.2.4. Attribute 33: mode . . . . . . . . . . . . . . . . . 140 6.2.4. Attribute 33: mode . . . . . . . . . . . . . . . . . 141
6.2.5. Attribute 74: mode_set_masked . . . . . . . . . . . 141 6.2.5. Attribute 74: mode_set_masked . . . . . . . . . . . 142
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 142 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 143
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 142 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 143
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 143 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 144
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 144 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 145
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 144 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 145
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 146 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 147
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 146 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 147
7. Single-server Namespace . . . . . . . . . . . . . . . . . . . 150 7. Single-server Namespace . . . . . . . . . . . . . . . . . . . 151
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 151 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 152
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 151 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 152
7.3. Server Pseudo File System . . . . . . . . . . . . . . . 151 7.3. Server Pseudo File System . . . . . . . . . . . . . . . 152
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 152 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 153
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 152 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 153
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 153 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 154
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 153 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 154
7.8. Security Policy and Namespace Presentation . . . . . . . 153 7.8. Security Policy and Namespace Presentation . . . . . . . 154
8. State Management . . . . . . . . . . . . . . . . . . . . . . 154 8. State Management . . . . . . . . . . . . . . . . . . . . . . 155
8.1. Client and Session ID . . . . . . . . . . . . . . . . . 155 8.1. Client and Session ID . . . . . . . . . . . . . . . . . 156
8.2. Stateid Definition . . . . . . . . . . . . . . . . . . . 156 8.2. Stateid Definition . . . . . . . . . . . . . . . . . . . 157
8.2.1. Stateid Types . . . . . . . . . . . . . . . . . . . 156 8.2.1. Stateid Types . . . . . . . . . . . . . . . . . . . 157
8.2.2. Stateid Structure . . . . . . . . . . . . . . . . . 157 8.2.2. Stateid Structure . . . . . . . . . . . . . . . . . 158
8.2.3. Special Stateids . . . . . . . . . . . . . . . . . . 159 8.2.3. Special Stateids . . . . . . . . . . . . . . . . . . 160
8.2.4. Stateid Lifetime and Validation . . . . . . . . . . 160 8.2.4. Stateid Lifetime and Validation . . . . . . . . . . 161
8.2.5. Stateid Use for I/O Operations . . . . . . . . . . . 163 8.2.5. Stateid Use for I/O Operations . . . . . . . . . . . 164
8.2.6. Stateid Use for SETATTR Operations . . . . . . . . . 164 8.2.6. Stateid Use for SETATTR Operations . . . . . . . . . 165
8.3. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 164 8.3. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 165
8.4. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 167 8.4. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 168
8.4.1. Client Failure and Recovery . . . . . . . . . . . . 167 8.4.1. Client Failure and Recovery . . . . . . . . . . . . 168
8.4.2. Server Failure and Recovery . . . . . . . . . . . . 168 8.4.2. Server Failure and Recovery . . . . . . . . . . . . 169
8.4.3. Network Partitions and Recovery . . . . . . . . . . 173 8.4.3. Network Partitions and Recovery . . . . . . . . . . 174
8.5. Server Revocation of Locks . . . . . . . . . . . . . . . 178 8.5. Server Revocation of Locks . . . . . . . . . . . . . . . 179
8.6. Short and Long Leases . . . . . . . . . . . . . . . . . 179 8.6. Short and Long Leases . . . . . . . . . . . . . . . . . 180
8.7. Clocks, Propagation Delay, and Calculating Lease 8.7. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 179 Expiration . . . . . . . . . . . . . . . . . . . . . . . 180
8.8. Obsolete Locking Infrastructure From NFSv4.0 . . . . . . 180 8.8. Obsolete Locking Infrastructure From NFSv4.0 . . . . . . 181
9. File Locking and Share Reservations . . . . . . . . . . . . . 181 9. File Locking and Share Reservations . . . . . . . . . . . . . 182
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 181 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 182
9.1.1. State-owner Definition . . . . . . . . . . . . . . . 181 9.1.1. State-owner Definition . . . . . . . . . . . . . . . 182
9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 181 9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 182
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 184 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 185
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 185 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 186
9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 185 9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 186
9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 186 9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 187
9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 186 9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 187
9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 187 9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 188
9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 188 9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 189
9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 189 9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 190
9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 190 9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 191
9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 190 9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 191
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 191 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 192
10.1. Performance Challenges for Client-Side Caching . . . . . 191 10.1. Performance Challenges for Client-Side Caching . . . . . 192
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 192 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 193
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 194 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 195
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 197
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 197 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 198
10.3.2. Data Caching and File Locking . . . . . . . . . . . 198 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 198
10.3.3. Data Caching and Mandatory File Locking . . . . . . 200 10.3.2. Data Caching and File Locking . . . . . . . . . . . 199
10.3.4. Data Caching and File Identity . . . . . . . . . . . 200 10.3.3. Data Caching and Mandatory File Locking . . . . . . 201
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 201 10.3.4. Data Caching and File Identity . . . . . . . . . . . 201
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 204 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 202
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 205 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 205
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 205 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 206
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 208 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 206
10.4.5. Clients that Fail to Honor Delegation Recalls . . . 210 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 209
10.4.6. Delegation Revocation . . . . . . . . . . . . . . . 211 10.4.5. Clients that Fail to Honor Delegation Recalls . . . 211
10.4.7. Delegations via WANT_DELEGATION . . . . . . . . . . 211 10.4.6. Delegation Revocation . . . . . . . . . . . . . . . 212
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 212 10.4.7. Delegations via WANT_DELEGATION . . . . . . . . . . 212
10.5.1. Revocation Recovery for Write Open Delegation . . . 213 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 213
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 213 10.5.1. Revocation Recovery for Write Open Delegation . . . 214
10.7. Data and Metadata Caching and Memory Mapped Files . . . 215 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 214
10.7. Data and Metadata Caching and Memory Mapped Files . . . 216
10.8. Name and Directory Caching without Directory 10.8. Name and Directory Caching without Directory
Delegations . . . . . . . . . . . . . . . . . . . . . . 218 Delegations . . . . . . . . . . . . . . . . . . . . . . 219
10.8.1. Name Caching . . . . . . . . . . . . . . . . . . . . 218 10.8.1. Name Caching . . . . . . . . . . . . . . . . . . . . 219
10.8.2. Directory Caching . . . . . . . . . . . . . . . . . 219 10.8.2. Directory Caching . . . . . . . . . . . . . . . . . 220
10.9. Directory Delegations . . . . . . . . . . . . . . . . . 220 10.9. Directory Delegations . . . . . . . . . . . . . . . . . 221
10.9.1. Introduction to Directory Delegations . . . . . . . 220 10.9.1. Introduction to Directory Delegations . . . . . . . 221
10.9.2. Directory Delegation Design . . . . . . . . . . . . 221 10.9.2. Directory Delegation Design . . . . . . . . . . . . 222
10.9.3. Attributes in Support of Directory Notifications . . 222 10.9.3. Attributes in Support of Directory Notifications . . 223
10.9.4. Directory Delegation Recall . . . . . . . . . . . . 222 10.9.4. Directory Delegation Recall . . . . . . . . . . . . 223
10.9.5. Directory Delegation Recovery . . . . . . . . . . . 223 10.9.5. Directory Delegation Recovery . . . . . . . . . . . 224
11. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 223 11. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 224
11.1. Location Attributes . . . . . . . . . . . . . . . . . . 224 11.1. Location Attributes . . . . . . . . . . . . . . . . . . 225
11.2. File System Presence or Absence . . . . . . . . . . . . 224 11.2. File System Presence or Absence . . . . . . . . . . . . 225
11.3. Getting Attributes for an Absent File System . . . . . . 225 11.3. Getting Attributes for an Absent File System . . . . . . 226
11.3.1. GETATTR Within an Absent File System . . . . . . . . 226 11.3.1. GETATTR Within an Absent File System . . . . . . . . 227
11.3.2. READDIR and Absent File Systems . . . . . . . . . . 227 11.3.2. READDIR and Absent File Systems . . . . . . . . . . 228
11.4. Uses of Location Information . . . . . . . . . . . . . . 227 11.4. Uses of Location Information . . . . . . . . . . . . . . 228
11.4.1. File System Replication . . . . . . . . . . . . . . 228 11.4.1. File System Replication . . . . . . . . . . . . . . 229
11.4.2. File System Migration . . . . . . . . . . . . . . . 229 11.4.2. File System Migration . . . . . . . . . . . . . . . 230
11.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 230 11.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 231
11.5. Location Entries and Server Identity . . . . . . . . . . 232 11.5. Location Entries and Server Identity . . . . . . . . . . 233
11.6. Additional Client-side Considerations . . . . . . . . . 232 11.6. Additional Client-side Considerations . . . . . . . . . 233
11.7. Effecting File System Transitions . . . . . . . . . . . 233 11.7. Effecting File System Transitions . . . . . . . . . . . 234
11.7.1. File System Transitions and Simultaneous Access . . 234 11.7.1. File System Transitions and Simultaneous Access . . 235
11.7.2. Simultaneous Use and Transparent Transitions . . . . 235 11.7.2. Simultaneous Use and Transparent Transitions . . . . 236
11.7.3. Filehandles and File System Transitions . . . . . . 238 11.7.3. Filehandles and File System Transitions . . . . . . 239
11.7.4. Fileids and File System Transitions . . . . . . . . 238 11.7.4. Fileids and File System Transitions . . . . . . . . 239
11.7.5. Fsids and File System Transitions . . . . . . . . . 239 11.7.5. Fsids and File System Transitions . . . . . . . . . 240
11.7.6. The Change Attribute and File System Transitions . . 240 11.7.6. The Change Attribute and File System Transitions . . 241
11.7.7. Lock State and File System Transitions . . . . . . . 240 11.7.7. Lock State and File System Transitions . . . . . . . 241
11.7.8. Write Verifiers and File System Transitions . . . . 245 11.7.8. Write Verifiers and File System Transitions . . . . 246
11.7.9. Readdir Cookies and Verifiers and File System 11.7.9. Readdir Cookies and Verifiers and File System
Transitions . . . . . . . . . . . . . . . . . . . . 245 Transitions . . . . . . . . . . . . . . . . . . . . 246
11.7.10. File System Data and File System Transitions . . . . 245 11.7.10. File System Data and File System Transitions . . . . 246
11.8. Effecting File System Referrals . . . . . . . . . . . . 247 11.8. Effecting File System Referrals . . . . . . . . . . . . 248
11.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 247 11.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 248
11.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 251 11.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 252
11.9. The Attribute fs_locations . . . . . . . . . . . . . . . 253 11.9. The Attribute fs_locations . . . . . . . . . . . . . . . 254
11.10. The Attribute fs_locations_info . . . . . . . . . . . . 256 11.10. The Attribute fs_locations_info . . . . . . . . . . . . 257
11.10.1. The fs_locations_server4 Structure . . . . . . . . . 260 11.10.1. The fs_locations_server4 Structure . . . . . . . . . 261
11.10.2. The fs_locations_info4 Structure . . . . . . . . . . 265 11.10.2. The fs_locations_info4 Structure . . . . . . . . . . 266
11.10.3. The fs_locations_item4 Structure . . . . . . . . . . 266 11.10.3. The fs_locations_item4 Structure . . . . . . . . . . 267
11.11. The Attribute fs_status . . . . . . . . . . . . . . . . 268 11.11. The Attribute fs_status . . . . . . . . . . . . . . . . 269
12. Parallel NFS (pNFS) . . . . . . . . . . . . . . . . . . . . . 272 12. Parallel NFS (pNFS) . . . . . . . . . . . . . . . . . . . . . 273
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 272 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 273
12.2. pNFS Definitions . . . . . . . . . . . . . . . . . . . . 273 12.2. pNFS Definitions . . . . . . . . . . . . . . . . . . . . 274
12.2.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 274 12.2.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 275
12.2.2. Metadata Server . . . . . . . . . . . . . . . . . . 274 12.2.2. Metadata Server . . . . . . . . . . . . . . . . . . 275
12.2.3. pNFS Client . . . . . . . . . . . . . . . . . . . . 274 12.2.3. pNFS Client . . . . . . . . . . . . . . . . . . . . 275
12.2.4. Storage Device . . . . . . . . . . . . . . . . . . . 274 12.2.4. Storage Device . . . . . . . . . . . . . . . . . . . 275
12.2.5. Storage Protocol . . . . . . . . . . . . . . . . . . 275 12.2.5. Storage Protocol . . . . . . . . . . . . . . . . . . 276
12.2.6. Control Protocol . . . . . . . . . . . . . . . . . . 275 12.2.6. Control Protocol . . . . . . . . . . . . . . . . . . 276
12.2.7. Layout Types . . . . . . . . . . . . . . . . . . . . 276 12.2.7. Layout Types . . . . . . . . . . . . . . . . . . . . 277
12.2.8. Layout . . . . . . . . . . . . . . . . . . . . . . . 276 12.2.8. Layout . . . . . . . . . . . . . . . . . . . . . . . 277
12.2.9. Layout Iomode . . . . . . . . . . . . . . . . . . . 277 12.2.9. Layout Iomode . . . . . . . . . . . . . . . . . . . 278
12.2.10. Device IDs . . . . . . . . . . . . . . . . . . . . . 277 12.2.10. Device IDs . . . . . . . . . . . . . . . . . . . . . 278
12.3. pNFS Operations . . . . . . . . . . . . . . . . . . . . 279 12.3. pNFS Operations . . . . . . . . . . . . . . . . . . . . 280
12.4. pNFS Attributes . . . . . . . . . . . . . . . . . . . . 280 12.4. pNFS Attributes . . . . . . . . . . . . . . . . . . . . 281
12.5. Layout Semantics . . . . . . . . . . . . . . . . . . . . 280 12.5. Layout Semantics . . . . . . . . . . . . . . . . . . . . 281
12.5.1. Guarantees Provided by Layouts . . . . . . . . . . . 280 12.5.1. Guarantees Provided by Layouts . . . . . . . . . . . 281
12.5.2. Getting a Layout . . . . . . . . . . . . . . . . . . 281 12.5.2. Getting a Layout . . . . . . . . . . . . . . . . . . 282
12.5.3. Layout Stateid . . . . . . . . . . . . . . . . . . . 282 12.5.3. Layout Stateid . . . . . . . . . . . . . . . . . . . 283
12.5.4. Committing a Layout . . . . . . . . . . . . . . . . 283 12.5.4. Committing a Layout . . . . . . . . . . . . . . . . 284
12.5.5. Recalling a Layout . . . . . . . . . . . . . . . . . 286 12.5.5. Recalling a Layout . . . . . . . . . . . . . . . . . 287
12.5.6. Revoking Layouts . . . . . . . . . . . . . . . . . . 294 12.5.6. Revoking Layouts . . . . . . . . . . . . . . . . . . 295
12.5.7. Metadata Server Write Propagation . . . . . . . . . 295 12.5.7. Metadata Server Write Propagation . . . . . . . . . 296
12.6. pNFS Mechanics . . . . . . . . . . . . . . . . . . . . . 295 12.6. pNFS Mechanics . . . . . . . . . . . . . . . . . . . . . 296
12.7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 296 12.7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 297
12.7.1. Recovery from Client Restart . . . . . . . . . . . . 297 12.7.1. Recovery from Client Restart . . . . . . . . . . . . 298
12.7.2. Dealing with Lease Expiration on the Client . . . . 297 12.7.2. Dealing with Lease Expiration on the Client . . . . 298
12.7.3. Dealing with Loss of Layout State on the Metadata 12.7.3. Dealing with Loss of Layout State on the Metadata
Server . . . . . . . . . . . . . . . . . . . . . . . 298 Server . . . . . . . . . . . . . . . . . . . . . . . 299
12.7.4. Recovery from Metadata Server Restart . . . . . . . 299 12.7.4. Recovery from Metadata Server Restart . . . . . . . 300
12.7.5. Operations During Metadata Server Grace Period . . . 301 12.7.5. Operations During Metadata Server Grace Period . . . 302
12.7.6. Storage Device Recovery . . . . . . . . . . . . . . 301 12.7.6. Storage Device Recovery . . . . . . . . . . . . . . 302
12.8. Metadata and Storage Device Roles . . . . . . . . . . . 301 12.8. Metadata and Storage Device Roles . . . . . . . . . . . 302
12.9. Security Considerations for pNFS . . . . . . . . . . . . 302 12.9. Security Considerations for pNFS . . . . . . . . . . . . 303
13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type . 303 13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type . 304
13.1. Client ID and Session Considerations . . . . . . . . . . 303 13.1. Client ID and Session Considerations . . . . . . . . . . 304
13.1.1. Sessions Considerations for Data Servers . . . . . . 306 13.1.1. Sessions Considerations for Data Servers . . . . . . 307
13.2. File Layout Definitions . . . . . . . . . . . . . . . . 306 13.2. File Layout Definitions . . . . . . . . . . . . . . . . 307
13.3. File Layout Data Types . . . . . . . . . . . . . . . . . 307 13.3. File Layout Data Types . . . . . . . . . . . . . . . . . 308
13.4. Interpreting the File Layout . . . . . . . . . . . . . . 311 13.4. Interpreting the File Layout . . . . . . . . . . . . . . 312
13.4.1. Determining the Stripe Unit Number . . . . . . . . . 311 13.4.1. Determining the Stripe Unit Number . . . . . . . . . 312
13.4.2. Interpreting the File Layout Using Sparse Packing . 311 13.4.2. Interpreting the File Layout Using Sparse Packing . 312
13.4.3. Interpreting the File Layout Using Dense Packing . . 314 13.4.3. Interpreting the File Layout Using Dense Packing . . 315
13.4.4. Sparse and Dense Stripe Unit Packing . . . . . . . . 316 13.4.4. Sparse and Dense Stripe Unit Packing . . . . . . . . 317
13.5. Data Server Multipathing . . . . . . . . . . . . . . . . 318 13.5. Data Server Multipathing . . . . . . . . . . . . . . . . 319
13.6. Operations Sent to NFSv4.1 Data Servers . . . . . . . . 319 13.6. Operations Sent to NFSv4.1 Data Servers . . . . . . . . 320
13.7. COMMIT Through Metadata Server . . . . . . . . . . . . . 321 13.7. COMMIT Through Metadata Server . . . . . . . . . . . . . 322
13.8. The Layout Iomode . . . . . . . . . . . . . . . . . . . 323 13.8. The Layout Iomode . . . . . . . . . . . . . . . . . . . 324
13.9. Metadata and Data Server State Coordination . . . . . . 323 13.9. Metadata and Data Server State Coordination . . . . . . 324
13.9.1. Global Stateid Requirements . . . . . . . . . . . . 323 13.9.1. Global Stateid Requirements . . . . . . . . . . . . 324
13.9.2. Data Server State Propagation . . . . . . . . . . . 324 13.9.2. Data Server State Propagation . . . . . . . . . . . 325
13.10. Data Server Component File Size . . . . . . . . . . . . 326 13.10. Data Server Component File Size . . . . . . . . . . . . 327
13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 327 13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 328
13.12. Security Considerations for the File Layout Type . . . . 327 13.12. Security Considerations for the File Layout Type . . . . 328
14. Internationalization . . . . . . . . . . . . . . . . . . . . 328 14. Internationalization . . . . . . . . . . . . . . . . . . . . 329
14.1. Stringprep profile for the utf8str_cs type . . . . . . . 329 14.1. Stringprep profile for the utf8str_cs type . . . . . . . 330
14.2. Stringprep profile for the utf8str_cis type . . . . . . 331 14.2. Stringprep profile for the utf8str_cis type . . . . . . 332
14.3. Stringprep profile for the utf8str_mixed type . . . . . 332 14.3. Stringprep profile for the utf8str_mixed type . . . . . 333
14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 333 14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 334
14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 334 14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 335
15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 334 15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 335
15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 335 15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 336
15.1.1. General Errors . . . . . . . . . . . . . . . . . . . 337 15.1.1. General Errors . . . . . . . . . . . . . . . . . . . 338
15.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 339 15.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 340
15.1.3. Compound Structure Errors . . . . . . . . . . . . . 340 15.1.3. Compound Structure Errors . . . . . . . . . . . . . 341
15.1.4. File System Errors . . . . . . . . . . . . . . . . . 342 15.1.4. File System Errors . . . . . . . . . . . . . . . . . 343
15.1.5. State Management Errors . . . . . . . . . . . . . . 344 15.1.5. State Management Errors . . . . . . . . . . . . . . 345
15.1.6. Security Errors . . . . . . . . . . . . . . . . . . 344 15.1.6. Security Errors . . . . . . . . . . . . . . . . . . 345
15.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 345 15.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 346
15.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 346 15.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 347
15.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 347 15.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 348
15.1.10. pNFS Errors . . . . . . . . . . . . . . . . . . . . 348 15.1.10. pNFS Errors . . . . . . . . . . . . . . . . . . . . 349
15.1.11. Session Use Errors . . . . . . . . . . . . . . . . . 349 15.1.11. Session Use Errors . . . . . . . . . . . . . . . . . 350
15.1.12. Session Management Errors . . . . . . . . . . . . . 350 15.1.12. Session Management Errors . . . . . . . . . . . . . 351
15.1.13. Client Management Errors . . . . . . . . . . . . . . 351 15.1.13. Client Management Errors . . . . . . . . . . . . . . 352
15.1.14. Delegation Errors . . . . . . . . . . . . . . . . . 352 15.1.14. Delegation Errors . . . . . . . . . . . . . . . . . 353
15.1.15. Attribute Handling Errors . . . . . . . . . . . . . 352 15.1.15. Attribute Handling Errors . . . . . . . . . . . . . 353
15.1.16. Obsoleted Errors . . . . . . . . . . . . . . . . . . 353 15.1.16. Obsoleted Errors . . . . . . . . . . . . . . . . . . 354
15.2. Operations and their valid errors . . . . . . . . . . . 354 15.2. Operations and their valid errors . . . . . . . . . . . 355
15.3. Callback operations and their valid errors . . . . . . . 370 15.3. Callback operations and their valid errors . . . . . . . 371
15.4. Errors and the operations that use them . . . . . . . . 372 15.4. Errors and the operations that use them . . . . . . . . 373
16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 387 16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 388
16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 387 16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 388
16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 388 16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 389
17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 399
18. NFSv4.1 Operations . . . . . . . . . . . . . . . . . . . . . 402 17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 400
18.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 402 18. NFSv4.1 Operations . . . . . . . . . . . . . . . . . . . . . 403
18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 408 18.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 403
18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 409 18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 409
18.4. Operation 6: CREATE - Create a Non-Regular File Object . 412 18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 410
18.4. Operation 6: CREATE - Create a Non-Regular File Object . 413
18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting 18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 415 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 416
18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 416 18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 417
18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 416 18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 417
18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 418 18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 419
18.9. Operation 11: LINK - Create Link to a File . . . . . . . 419 18.9. Operation 11: LINK - Create Link to a File . . . . . . . 420
18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 422 18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 423
18.11. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 426 18.11. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 427
18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 427 18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 428
18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 429 18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 430
18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 430 18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 431
18.15. Operation 17: NVERIFY - Verify Difference in 18.15. Operation 17: NVERIFY - Verify Difference in
Attributes . . . . . . . . . . . . . . . . . . . . . . . 432 Attributes . . . . . . . . . . . . . . . . . . . . . . . 433
18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 433 18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 434
18.17. Operation 19: OPENATTR - Open Named Attribute 18.17. Operation 19: OPENATTR - Open Named Attribute
Directory . . . . . . . . . . . . . . . . . . . . . . . 452 Directory . . . . . . . . . . . . . . . . . . . . . . . 453
18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 453 18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 454
18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 455 18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 456
18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 455 18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 456
18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 457 18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 458
18.22. Operation 25: READ - Read from File . . . . . . . . . . 458 18.22. Operation 25: READ - Read from File . . . . . . . . . . 459
18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 460 18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 461
18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 464 18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 465
18.25. Operation 28: REMOVE - Remove File System Object . . . . 465 18.25. Operation 28: REMOVE - Remove File System Object . . . . 466
18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 467 18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 468
18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 471 18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 472
18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 472 18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 473
18.29. Operation 33: SECINFO - Obtain Available Security . . . 473 18.29. Operation 33: SECINFO - Obtain Available Security . . . 474
18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 477 18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 478
18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 480 18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 481
18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 481 18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 482
18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control . . 485 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control . . 486
18.34. Operation 41: BIND_CONN_TO_SESSION - Associate 18.34. Operation 41: BIND_CONN_TO_SESSION - Associate
Connection with Session . . . . . . . . . . . . . . . . 487 Connection with Session . . . . . . . . . . . . . . . . 488
18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 490 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 491
18.36. Operation 43: CREATE_SESSION - Create New Session and 18.36. Operation 43: CREATE_SESSION - Create New Session and
Confirm Client ID . . . . . . . . . . . . . . . . . . . 507 Confirm Client ID . . . . . . . . . . . . . . . . . . . 509
18.37. Operation 44: DESTROY_SESSION - Destroy a Session . . . 517 18.37. Operation 44: DESTROY_SESSION - Destroy a Session . . . 519
18.38. Operation 45: FREE_STATEID - Free Stateid with No 18.38. Operation 45: FREE_STATEID - Free Stateid with No
Locks . . . . . . . . . . . . . . . . . . . . . . . . . 518 Locks . . . . . . . . . . . . . . . . . . . . . . . . . 520
18.39. Operation 46: GET_DIR_DELEGATION - Get a directory 18.39. Operation 46: GET_DIR_DELEGATION - Get a directory
delegation . . . . . . . . . . . . . . . . . . . . . . . 519 delegation . . . . . . . . . . . . . . . . . . . . . . . 521
18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 523
18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 525
18.41. Operation 48: GETDEVICELIST - Get All Device Mappings 18.41. Operation 48: GETDEVICELIST - Get All Device Mappings
for a File System . . . . . . . . . . . . . . . . . . . 525 for a File System . . . . . . . . . . . . . . . . . . . 527
18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made Using 18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made Using
a Layout . . . . . . . . . . . . . . . . . . . . . . . . 527 a Layout . . . . . . . . . . . . . . . . . . . . . . . . 529
18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 530 18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 532
18.44. Operation 51: LAYOUTRETURN - Release Layout 18.44. Operation 51: LAYOUTRETURN - Release Layout
Information . . . . . . . . . . . . . . . . . . . . . . 540 Information . . . . . . . . . . . . . . . . . . . . . . 542
18.45. Operation 52: SECINFO_NO_NAME - Get Security on 18.45. Operation 52: SECINFO_NO_NAME - Get Security on
Unnamed Object . . . . . . . . . . . . . . . . . . . . . 544 Unnamed Object . . . . . . . . . . . . . . . . . . . . . 546
18.46. Operation 53: SEQUENCE - Supply Per-Procedure 18.46. Operation 53: SEQUENCE - Supply Per-Procedure
Sequencing and Control . . . . . . . . . . . . . . . . . 545 Sequencing and Control . . . . . . . . . . . . . . . . . 547
18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 551 18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 553
18.48. Operation 55: TEST_STATEID - Test Stateids for 18.48. Operation 55: TEST_STATEID - Test Stateids for
Validity . . . . . . . . . . . . . . . . . . . . . . . . 553 Validity . . . . . . . . . . . . . . . . . . . . . . . . 555
18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 555 18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 557
18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID . . 559 18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID . . 561
18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims 18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims
Finished . . . . . . . . . . . . . . . . . . . . . . . . 559 Finished . . . . . . . . . . . . . . . . . . . . . . . . 561
18.52. Operation 10044: ILLEGAL - Illegal operation . . . . . . 562 18.52. Operation 10044: ILLEGAL - Illegal operation . . . . . . 564
19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 562 19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 564
19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 563 19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 565
19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 563 19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 565
20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 567 20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 569
20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 567 20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 569
20.2. Operation 4: CB_RECALL - Recall a Delegation . . . . . . 568 20.2. Operation 4: CB_RECALL - Recall a Delegation . . . . . . 570
20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from 20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from
Client . . . . . . . . . . . . . . . . . . . . . . . . . 569 Client . . . . . . . . . . . . . . . . . . . . . . . . . 571
20.4. Operation 6: CB_NOTIFY - Notify Client of Directory 20.4. Operation 6: CB_NOTIFY - Notify Client of Directory
Changes . . . . . . . . . . . . . . . . . . . . . . . . 573 Changes . . . . . . . . . . . . . . . . . . . . . . . . 575
20.5. Operation 7: CB_PUSH_DELEG - Offer Previously 20.5. Operation 7: CB_PUSH_DELEG - Offer Previously
Requested Delegation to Client . . . . . . . . . . . . . 577 Requested Delegation to Client . . . . . . . . . . . . . 579
20.6. Operation 8: CB_RECALL_ANY - Keep Any N Recallable 20.6. Operation 8: CB_RECALL_ANY - Keep Any N Recallable
Objects . . . . . . . . . . . . . . . . . . . . . . . . 578 Objects . . . . . . . . . . . . . . . . . . . . . . . . 580
20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal 20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal
Resources for Recallable Objects . . . . . . . . . . . . 581 Resources for Recallable Objects . . . . . . . . . . . . 583
20.8. Operation 10: CB_RECALL_SLOT - Change Flow Control 20.8. Operation 10: CB_RECALL_SLOT - Change Flow Control
Limits . . . . . . . . . . . . . . . . . . . . . . . . . 582 Limits . . . . . . . . . . . . . . . . . . . . . . . . . 584
20.9. Operation 11: CB_SEQUENCE - Supply Backchannel 20.9. Operation 11: CB_SEQUENCE - Supply Backchannel
Sequencing and Control . . . . . . . . . . . . . . . . . 583 Sequencing and Control . . . . . . . . . . . . . . . . . 585
20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending 20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending
Delegation Wants . . . . . . . . . . . . . . . . . . . . 585 Delegation Wants . . . . . . . . . . . . . . . . . . . . 587
20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of 20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of
Possible Lock Availability . . . . . . . . . . . . . . . 586 Possible Lock Availability . . . . . . . . . . . . . . . 588
20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify Client of 20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify Client of
Device ID Changes . . . . . . . . . . . . . . . . . . . 588 Device ID Changes . . . . . . . . . . . . . . . . . . . 590
20.13. Operation 10044: CB_ILLEGAL - Illegal Callback 20.13. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . . . 590 Operation . . . . . . . . . . . . . . . . . . . . . . . 592
21. Security Considerations . . . . . . . . . . . . . . . . . . . 590
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 592 21. Security Considerations . . . . . . . . . . . . . . . . . . . 592
22.1. Named Attribute Definitions . . . . . . . . . . . . . . 592 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 594
22.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 593 22.1. Named Attribute Definitions . . . . . . . . . . . . . . 594
22.1.2. Updating Registrations . . . . . . . . . . . . . . . 593 22.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 595
22.2. Device ID Notifications . . . . . . . . . . . . . . . . 593 22.1.2. Updating Registrations . . . . . . . . . . . . . . . 595
22.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 594 22.2. Device ID Notifications . . . . . . . . . . . . . . . . 595
22.2.2. Updating Registrations . . . . . . . . . . . . . . . 594 22.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 596
22.3. Object Recall Types . . . . . . . . . . . . . . . . . . 594 22.2.2. Updating Registrations . . . . . . . . . . . . . . . 596
22.3.1. Initial Registry . . . . . . . . . . . . . . . . . . 596 22.3. Object Recall Types . . . . . . . . . . . . . . . . . . 596
22.3.2. Updating Registrations . . . . . . . . . . . . . . . 596 22.3.1. Initial Registry . . . . . . . . . . . . . . . . . . 598
22.4. Layout Types . . . . . . . . . . . . . . . . . . . . . . 596 22.3.2. Updating Registrations . . . . . . . . . . . . . . . 598
22.4.1. Initial Registry . . . . . . . . . . . . . . . . . . 597 22.4. Layout Types . . . . . . . . . . . . . . . . . . . . . . 598
22.4.2. Updating Registrations . . . . . . . . . . . . . . . 597 22.4.1. Initial Registry . . . . . . . . . . . . . . . . . . 599
22.4.3. Guidelines for Writing Layout Type Specifications . 597 22.4.2. Updating Registrations . . . . . . . . . . . . . . . 599
22.5. Path Variable Definitions . . . . . . . . . . . . . . . 599 22.4.3. Guidelines for Writing Layout Type Specifications . 599
22.5.1. Path Variables Registry . . . . . . . . . . . . . . 599 22.5. Path Variable Definitions . . . . . . . . . . . . . . . 601
22.5.2. Values for the ${ietf.org:CPU_ARCH} Variable . . . . 601 22.5.1. Path Variables Registry . . . . . . . . . . . . . . 601
22.5.3. Values for the ${ietf.org:OS_TYPE} Variable . . . . 601 22.5.2. Values for the ${ietf.org:CPU_ARCH} Variable . . . . 603
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 602 22.5.3. Values for the ${ietf.org:OS_TYPE} Variable . . . . 603
23.1. Normative References . . . . . . . . . . . . . . . . . . 602 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 604
23.2. Informative References . . . . . . . . . . . . . . . . . 605 23.1. Normative References . . . . . . . . . . . . . . . . . . 604
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 606 23.2. Informative References . . . . . . . . . . . . . . . . . 607
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 609 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 608
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 609 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 611
Intellectual Property and Copyright Statements . . . . . . . . . 611 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 611
1. Introduction 1. Introduction
1.1. The NFS Version 4 Minor Version 1 Protocol 1.1. The NFS Version 4 Minor Version 1 Protocol
The NFS version 4 minor version 1 (NFSv4.1) protocol is the second The NFS version 4 minor version 1 (NFSv4.1) protocol is the second
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 [29]. It generally follows the version, NFSv4.0 is described in [29]. It generally follows the
guidelines for minor versioning model listed in Section 10 of RFC guidelines for minor versioning model listed in Section 10 of RFC
3530. However, it diverges from guidelines 11 ("a client and server 3530. However, it diverges from guidelines 11 ("a client and server
skipping to change at page 24, line 36 skipping to change at page 25, line 36
Except for a small number of operations needed for session creation, Except for a small number of operations needed for session creation,
server requests and callback requests are performed within the server requests and callback requests are performed within the
context of a session. Sessions provide a client context for every context of a session. Sessions provide a client context for every
request and support robust reply protection for non-idempotent request and support robust reply protection for non-idempotent
requests. requests.
2.4. Client Identifiers and Client Owners 2.4. Client Identifiers and Client Owners
For each operation that obtains or depends on locking state, the For each operation that obtains or depends on locking state, the
specific client must be identifiable by the server. specific client needs to be identifiable by the server.
Each distinct client instance is represented by a client ID. A Each distinct client instance is represented by a client ID. A
client ID is a 64-bit identifier representing a specific client at a client ID is a 64-bit identifier representing a specific client at a
given time. The client ID is changed whenever the client re- given time. The client ID is changed whenever the client re-
initializes, and may change when the server re-initializes. Client initializes, and may change when the server re-initializes. Client
IDs are used to support lock identification and crash recovery. IDs are used to support lock identification and crash recovery.
During steady state operation, the client ID associated with each During steady state operation, the client ID associated with each
operation is derived from the session (see Section 2.10) on which the operation is derived from the session (see Section 2.10) on which the
operation is sent. A session is associated with a client ID when the operation is sent. A session is associated with a client ID when the
skipping to change at page 27, line 22 skipping to change at page 28, line 22
client ID previously assigned by the server. This applies across client ID previously assigned by the server. This applies across
server restarts. server restarts.
In the event of a server restart, a client may find out that its In the event of a server restart, a client may find out that its
current client ID is no longer valid when it receives an current client ID is no longer valid when it receives an
NFS4ERR_STALE_CLIENTID error. The precise circumstances depend on NFS4ERR_STALE_CLIENTID error. The precise circumstances depend on
the characteristics of the sessions involved, specifically whether the characteristics of the sessions involved, specifically whether
the session is persistent (see Section 2.10.6.5), but in each case the session is persistent (see Section 2.10.6.5), but in each case
the client will receive this error when it attempts to establish a the client will receive this error when it attempts to establish a
new session with the existing client ID and receives the error new session with the existing client ID and receives the error
NFS4ERR_STALE_CLIENTID, indicating that a new client ID must be NFS4ERR_STALE_CLIENTID, indicating that a new client ID needs to be
obtained via EXCHANGE_ID and the new session established with that obtained via EXCHANGE_ID and the new session established with that
client ID. client ID.
When a session is not persistent, the client will find out that it When a session is not persistent, the client will find out that it
needs to create a new session as a result of getting an needs to create a new session as a result of getting an
NFS4ERR_BADSESSION, since the session in question was lost as part of NFS4ERR_BADSESSION, since the session in question was lost as part of
a server restart. When the existing client ID is presented to a a server restart. When the existing client ID is presented to a
server as part of creating a session and that client ID is not server as part of creating a session and that client ID is not
recognized, as would happen after a server restart, the server will recognized, as would happen after a server restart, the server will
reject the request with the error NFS4ERR_STALE_CLIENTID. reject the request with the error NFS4ERR_STALE_CLIENTID.
In the case of the session being persistent, the client will re- In the case of the session being persistent, the client will re-
establish communication using the existing session after the restart. establish communication using the existing session after the restart.
This session will be associated with the existing client ID but may This session will be associated with the existing client ID but may
only be used to retransmit operations that the client previously only be used to retransmit operations that the client previously
transmitted and did not see replies to. Replies to operations that transmitted and did not see replies to. Replies to operations that
the server previously performed will come from the reply cache, the server previously performed will come from the reply cache,
otherwise NFS4ERR_DEADSESSION will be returned. Hence, such a otherwise NFS4ERR_DEADSESSION will be returned. Hence, such a
session is referred to as "dead". In this situation, in order to session is referred to as "dead". In this situation, in order to
perform new operations, the client must establish a new session. If perform new operations, the client needs to establish a new session.
an attempt is made to establish this new session with the existing If an attempt is made to establish this new session with the existing
client ID, the server will reject the request with client ID, the server will reject the request with
NFS4ERR_STALE_CLIENTID. NFS4ERR_STALE_CLIENTID.
When NFS4ERR_STALE_CLIENTID is received in either of these When NFS4ERR_STALE_CLIENTID is received in either of these
situations, the client must obtain a new client ID by use of the situations, the client needs to obtain a new client ID by use of the
EXCHANGE_ID operation, then use that client ID as the basis of a new EXCHANGE_ID operation, then use that client ID as the basis of a new
session, and then proceed to any other necessary recovery for the session, and then proceed to any other necessary recovery for the
server restart case (See Section 8.4.2). server restart case (See Section 8.4.2).
See the descriptions of EXCHANGE_ID (Section 18.35) and See the descriptions of EXCHANGE_ID (Section 18.35) and
CREATE_SESSION (Section 18.36) for a complete specification of these CREATE_SESSION (Section 18.36) for a complete specification of these
operations. operations.
2.4.1. Upgrade from NFSv4.0 to NFSv4.1 2.4.1. Upgrade from NFSv4.0 to NFSv4.1
skipping to change at page 28, line 40 skipping to change at page 29, line 40
NFSv4.1 introduces a new operation called DESTROY_CLIENTID NFSv4.1 introduces a new operation called DESTROY_CLIENTID
(Section 18.50) which the client SHOULD use to destroy a client ID it (Section 18.50) which the client SHOULD use to destroy a client ID it
no longer needs. This permits graceful, bilateral release of a no longer needs. This permits graceful, bilateral release of a
client ID. The operation cannot be used if there are sessions client ID. The operation cannot be used if there are sessions
associated with the client ID, or state with an unexpired lease. associated with the client ID, or state with an unexpired lease.
If the server determines that the client holds no associated state If the server determines that the client holds no associated state
for its client ID (including sessions, opens, locks, delegations, for its client ID (including sessions, opens, locks, delegations,
layouts, and wants), the server may choose to unilaterally release layouts, and wants), the server may choose to unilaterally release
the client ID in order to conserve resources. If the client contacts the client ID in order to conserve resources. If the client contacts
the server after this release, the server must ensure the client the server after this release, the server MUST ensure the client
receives the appropriate error so that it will use the EXCHANGE_ID/ receives the appropriate error so that it will use the EXCHANGE_ID/
CREATE_SESSION sequence to establish a new client ID. The server CREATE_SESSION sequence to establish a new client ID. The server
ought to be very hesitant to release a client ID since the resulting ought to be very hesitant to release a client ID since the resulting
work on the client to recover from such an event will be the same work on the client to recover from such an event will be the same
burden as if the server had failed and restarted. Typically a server burden as if the server had failed and restarted. Typically a server
would not release a client ID unless there had been no activity from would not release a client ID unless there had been no activity from
that client for many minutes. As long as there are sessions, opens, that client for many minutes. As long as there are sessions, opens,
locks, delegations, layouts, or wants, the server MUST NOT release locks, delegations, layouts, or wants, the server MUST NOT release
the client ID. See Section 2.10.12.1.4 for discussion on releasing the client ID. See Section 2.10.12.1.4 for discussion on releasing
inactive sessions. inactive sessions.
skipping to change at page 29, line 24 skipping to change at page 30, line 24
unexpired lease, the server is allowed to dispose of the state of the unexpired lease, the server is allowed to dispose of the state of the
previous incarnation of the client owner if one of the following are previous incarnation of the client owner if one of the following are
true: true:
o The principal that created the client ID for the client owner is o The principal that created the client ID for the client owner is
the same as the principal that is issuing the EXCHANGE_ID. Note the same as the principal that is issuing the EXCHANGE_ID. Note
that if the client ID was created with SP4_MACH_CRED state that if the client ID was created with SP4_MACH_CRED state
protection (Section 18.35), the principal MUST be based on protection (Section 18.35), the principal MUST be based on
RPCSEC_GSS authentication, the RPCSEC_GSS service used MUST be RPCSEC_GSS authentication, the RPCSEC_GSS service used MUST be
integrity or privacy, and the same GSS mechanism and principal integrity or privacy, and the same GSS mechanism and principal
must be used as that used when the client ID was created. MUST be used as that used when the client ID was created.
o The client ID was established with SP4_SSV protection o The client ID was established with SP4_SSV protection
(Section 18.35, Section 2.10.8.3) and the client sends the (Section 18.35, Section 2.10.8.3) and the client sends the
EXCHANGE_ID with the security flavor set to RPCSEC_GSS using the EXCHANGE_ID with the security flavor set to RPCSEC_GSS using the
GSS SSV mechanism (Section 2.10.9). GSS SSV mechanism (Section 2.10.9).
o The client ID was established with SP4_SSV protection, and under o The client ID was established with SP4_SSV protection, and under
the conditions described herein, the EXCHANGE_ID was sent with the conditions described herein, the EXCHANGE_ID was sent with
SP4_MACH_CRED state protection. Because the SSV might not persist SP4_MACH_CRED state protection. Because the SSV might not persist
across client and server restart, and because the first time a across client and server restart, and because the first time a
skipping to change at page 30, line 47 skipping to change at page 31, line 47
With the NFSv4.1 server potentially offering multiple security With the NFSv4.1 server potentially offering multiple security
mechanisms, the client needs a method to determine or negotiate which mechanisms, the client needs a method to determine or negotiate which
mechanism is to be used for its communication with the server. The mechanism is to be used for its communication with the server. The
NFS server may have multiple points within its file system namespace NFS server may have multiple points within its file system namespace
that are available for use by NFS clients. These points can be that are available for use by NFS clients. These points can be
considered security policy boundaries, and in some NFS considered security policy boundaries, and in some NFS
implementations are tied to NFS export points. In turn the NFS implementations are tied to NFS export points. In turn the NFS
server may be configured such that each of these security policy server may be configured such that each of these security policy
boundaries may have different or multiple security mechanisms in use. boundaries may have different or multiple security mechanisms in use.
The security negotiation between client and server must be done with The security negotiation between client and server SHOULD be done
a secure channel to eliminate the possibility of a third party with a secure channel to eliminate the possibility of a third party
intercepting the negotiation sequence and forcing the client and intercepting the negotiation sequence and forcing the client and
server to choose a lower level of security than required or desired. server to choose a lower level of security than required or desired.
See Section 21 for further discussion. See Section 21 for further discussion.
2.6.1. NFSv4.1 Security Tuples 2.6.1. NFSv4.1 Security Tuples
An NFS server can assign one or more "security tuples" to each An NFS server can assign one or more "security tuples" to each
security policy boundary in its namespace. Each security tuple security policy boundary in its namespace. Each security tuple
consists of a security flavor (see Section 2.2.1.1), and if the consists of a security flavor (see Section 2.2.1.1), and if the
skipping to change at page 31, line 37 skipping to change at page 32, line 37
connection used for the SECINFO or SECINFO_NO_NAME operation (e.g. connection used for the SECINFO or SECINFO_NO_NAME operation (e.g.
read-only vs. read-write) access, security tuples that allow greater read-only vs. read-write) access, security tuples that allow greater
access should be presented first. Where the general level of access access should be presented first. Where the general level of access
is the same and different security flavors limit the range of is the same and different security flavors limit the range of
principals whose privileges are recognized (e.g. allowing or principals whose privileges are recognized (e.g. allowing or
disallowing root access), flavors supporting the greatest range of disallowing root access), flavors supporting the greatest range of
principals should be listed first. principals should be listed first.
2.6.3. Security Error 2.6.3. Security Error
Based on the assumption that each NFSv4.1 client and server must Based on the assumption that each NFSv4.1 client and server MUST
support a minimum set of security (i.e., Kerberos V5 under support a minimum set of security (i.e., Kerberos V5 under
RPCSEC_GSS), the NFS client will initiate file access to the server RPCSEC_GSS), the NFS client will initiate file access to the server
with one of the minimal security tuples. During communication with with one of the minimal security tuples. During communication with
the server, the client may receive an NFS error of NFS4ERR_WRONGSEC. the server, the client may receive an NFS error of NFS4ERR_WRONGSEC.
This error allows the server to notify the client that the security This error allows the server to notify the client that the security
tuple currently being used contravenes the server's security policy. tuple currently being used contravenes the server's security policy.
The client is then responsible for determining (see Section 2.6.3.1) The client is then responsible for determining (see Section 2.6.3.1)
what security tuples are available at the server and choosing one what security tuples are available at the server and choosing one
which is appropriate for the client. which is appropriate for the client.
skipping to change at page 34, line 39 skipping to change at page 35, line 39
2.6.3.1.1.6. Put Filehandle Operation + Nothing 2.6.3.1.1.6. Put Filehandle Operation + Nothing
The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC. The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC.
2.6.3.1.1.7. Put Filehandle Operation + Anything Else 2.6.3.1.1.7. Put Filehandle Operation + Anything Else
"Anything Else" includes OPEN by filehandle. "Anything Else" includes OPEN by filehandle.
The security policy enforcement applies to the filehandle specified The security policy enforcement applies to the filehandle specified
in the put filehandle operation. Therefore the put filehandle in the put filehandle operation. Therefore the put filehandle
operation must return NFS4ERR_WRONGSEC when there is a security tuple operation MUST return NFS4ERR_WRONGSEC when there is a security tuple
mismatch. This avoids the complexity adding NFS4ERR_WRONGSEC as an mismatch. This avoids the complexity adding NFS4ERR_WRONGSEC as an
allowable error to every other operation. allowable error to every other operation.
A COMPOUND containing the series put filehandle operation + A COMPOUND containing the series put filehandle operation +
SECINFO_NO_NAME (style SECINFO_STYLE4_CURRENT_FH) is an efficient way SECINFO_NO_NAME (style SECINFO_STYLE4_CURRENT_FH) is an efficient way
for the client to recover from NFS4ERR_WRONGSEC. for the client to recover from NFS4ERR_WRONGSEC.
The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to any operation The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to any operation
other than a put filehandle operation, LOOKUP, LOOKUPP, and OPEN (by other than a put filehandle operation, LOOKUP, LOOKUPP, and OPEN (by
component name). component name).
skipping to change at page 54, line 30 skipping to change at page 55, line 30
Section 2.10.6.2 for direction on how the replier deals with Section 2.10.6.2 for direction on how the replier deals with
retries of requests that are still in progress. retries of requests that are still in progress.
o A misordered retry, in which the sequence ID is less than o A misordered retry, in which the sequence ID is less than
(accounting for sequence wraparound) that previously seen in the (accounting for sequence wraparound) that previously seen in the
slot. The replier MUST return NFS4ERR_SEQ_MISORDERED (as the slot. The replier MUST return NFS4ERR_SEQ_MISORDERED (as the
result from SEQUENCE or CB_SEQUENCE). result from SEQUENCE or CB_SEQUENCE).
o A misordered new request, in which the sequence ID is two or more o A misordered new request, in which the sequence ID is two or more
than (accounting for sequence wraparound) than that previously than (accounting for sequence wraparound) than that previously
seen in the slot. Note that because the sequence ID must seen in the slot. Note that because the sequence ID MUST
wraparound to zero (0) once it reaches 0xFFFFFFFF, a misordered wraparound to zero (0) once it reaches 0xFFFFFFFF, a misordered
new request and a misordered retry cannot be distinguished. Thus, new request and a misordered retry cannot be distinguished. Thus,
the replier MUST return NFS4ERR_SEQ_MISORDERED (as the result from the replier MUST return NFS4ERR_SEQ_MISORDERED (as the result from
SEQUENCE or CB_SEQUENCE). SEQUENCE or CB_SEQUENCE).
Unlike the XID, the slot ID is always within a specific range; this Unlike the XID, the slot ID is always within a specific range; this
has two implications. The first implication is that for a given has two implications. The first implication is that for a given
session, the replier need only cache the results of a limited number session, the replier need only cache the results of a limited number
of COMPOUND requests . The second implication derives from the of COMPOUND requests . The second implication derives from the
first, which is that unlike XID-indexed reply caches (also known as first, which is that unlike XID-indexed reply caches (also known as
skipping to change at page 55, line 12 skipping to change at page 56, line 12
replier's reply cache implementation. This approach is considerably replier's reply cache implementation. This approach is considerably
more portable and completely robust - it is not subject to the more portable and completely robust - it is not subject to the
reassignment of ports as clients reconnect over IP networks. In reassignment of ports as clients reconnect over IP networks. In
addition, the RPC XID is not used in the reply cache, enhancing addition, the RPC XID is not used in the reply cache, enhancing
robustness of the cache in the face of any rapid reuse of XIDs by the robustness of the cache in the face of any rapid reuse of XIDs by the
requester. While the replier does not care about the XID for the requester. While the replier does not care about the XID for the
purposes of reply cache management (but the replier MUST return the purposes of reply cache management (but the replier MUST return the
same XID that was in the request), nonetheless there are same XID that was in the request), nonetheless there are
considerations for the XID in NFSv4.1 that are the same as all other considerations for the XID in NFSv4.1 that are the same as all other
previous versions of NFS. The RPC XID remains in each message and previous versions of NFS. The RPC XID remains in each message and
must be formulated in NFSv4.1 requests as in any other ONC RPC needs to be formulated in NFSv4.1 requests as in any other ONC RPC
request. The reasons include: request. The reasons include:
o The RPC layer retains its existing semantics and implementation. o The RPC layer retains its existing semantics and implementation.
o The requester and replier must be able to interoperate at the RPC o The requester and replier must be able to interoperate at the RPC
layer, prior to the NFSv4.1 decoding of the SEQUENCE or layer, prior to the NFSv4.1 decoding of the SEQUENCE or
CB_SEQUENCE operation. CB_SEQUENCE operation.
o If an operation is being used that does not start with SEQUENCE or o If an operation is being used that does not start with SEQUENCE or
CB_SEQUENCE (e.g. BIND_CONN_TO_SESSION), then the RPC XID is CB_SEQUENCE (e.g. BIND_CONN_TO_SESSION), then the RPC XID is
skipping to change at page 55, line 45 skipping to change at page 56, line 45
multiple sessions. Having the slot ID and sequence ID in the reply multiple sessions. Having the slot ID and sequence ID in the reply
means requester does not have to use the XID to lookup the slot ID means requester does not have to use the XID to lookup the slot ID
and sequence ID. Furthermore, since the XID is only 32 bits, it is and sequence ID. Furthermore, since the XID is only 32 bits, it is
too small to guarantee the re-association of a reply with its request too small to guarantee the re-association of a reply with its request
([36]); having session ID, slot ID, and sequence ID in the reply ([36]); having session ID, slot ID, and sequence ID in the reply
allows the client to validate that the reply in fact belongs to the allows the client to validate that the reply in fact belongs to the
matched request. matched request.
The SEQUENCE (and CB_SEQUENCE) operation also carries a The SEQUENCE (and CB_SEQUENCE) operation also carries a
"highest_slotid" value which carries additional requester slot usage "highest_slotid" value which carries additional requester slot usage
information. The requester must always indicate the slot ID information. The requester MUST always indicate the slot ID
representing the outstanding request with the highest-numbered slot representing the outstanding request with the highest-numbered slot
value. The requester should in all cases provide the most value. The requester should in all cases provide the most
conservative value possible, although it can be increased somewhat conservative value possible, although it can be increased somewhat
above the actual instantaneous usage to maintain some minimum or above the actual instantaneous usage to maintain some minimum or
optimal level. This provides a way for the requester to yield unused optimal level. This provides a way for the requester to yield unused
request slots back to the replier, which in turn can use the request slots back to the replier, which in turn can use the
information to reallocate resources. information to reallocate resources.
The replier responds with both a new target highest_slotid, and an The replier responds with both a new target highest_slotid, and an
enforced highest_slotid, described as follows: enforced highest_slotid, described as follows:
skipping to change at page 66, line 27 skipping to change at page 67, line 27
trade, where latency is present. trade, where latency is present.
The value to choose for padding is subject to a number of criteria. The value to choose for padding is subject to a number of criteria.
A primary source of variable-length data in the RPC header is the A primary source of variable-length data in the RPC header is the
authentication information, the form of which is client-determined, authentication information, the form of which is client-determined,
possibly in response to server specification. The contents of possibly in response to server specification. The contents of
COMPOUNDs, sizes of strings such as those passed to RENAME, etc. all COMPOUNDs, sizes of strings such as those passed to RENAME, etc. all
go into the determination of a maximal NFSv4.1 request size and go into the determination of a maximal NFSv4.1 request size and
therefore minimal buffer size. The client must select its offered therefore minimal buffer size. The client must select its offered
value carefully, so as not to overburden the server, and vice- versa. value carefully, so as not to overburden the server, and vice- versa.
The payoff of an appropriate padding value is higher performance. The benefit of an appropriate padding value is higher performance.
[[Comment.3: RFC editor please keep this diagram on one page.]] [[Comment.3: RFC editor please keep this diagram on one page.]]
Sender gather: Sender gather:
|RPC Request|Pad bytes|Length| -> |User data...| |RPC Request|Pad bytes|Length| -> |User data...|
\------+----------------------/ \ \------+----------------------/ \
\ \ \ \
\ Receiver scatter: \-----------+- ... \ Receiver scatter: \-----------+- ...
/-----+----------------\ \ \ /-----+----------------\ \ \
|RPC Request|Pad|Length| -> |FS buffer|->|FS buffer|->... |RPC Request|Pad|Length| -> |FS buffer|->|FS buffer|->...
skipping to change at page 68, line 50 skipping to change at page 69, line 50
might have to be the same as the one that acquired the state). might have to be the same as the one that acquired the state).
However, the client might not have an RPCSEC_GSS context for such However, the client might not have an RPCSEC_GSS context for such
a principal, and might not be able to create such a context a principal, and might not be able to create such a context
(perhaps because the user has logged off). When the client (perhaps because the user has logged off). When the client
establishes SP4_MACH_CRED or SP4_SSV protection, it can specify a establishes SP4_MACH_CRED or SP4_SSV protection, it can specify a
list of operations that the server MUST allow using the machine list of operations that the server MUST allow using the machine
credential (if SP4_MACH_CRED is used) or the SSV credential (if credential (if SP4_MACH_CRED is used) or the SSV credential (if
SP4_SSV is used). SP4_SSV is used).
The SP4_MACH_CRED state protection option uses a machine credential The SP4_MACH_CRED state protection option uses a machine credential
where the principal that creates the client ID, must also be the where the principal that creates the client ID, MUST also be the
principal that performs client ID and session maintenance operations. principal that performs client ID and session maintenance operations.
The security of the machine credential state protection approach The security of the machine credential state protection approach
depends entirely on safe guarding the per-machine credential. depends entirely on safe guarding the per-machine credential.
Assuming a proper safe guard, using the per-machine credential for Assuming a proper safe guard, using the per-machine credential for
operations like CREATE_SESSION, BIND_CONN_TO_SESSION, operations like CREATE_SESSION, BIND_CONN_TO_SESSION,
DESTROY_SESSION, and DESTROY_CLIENTID will prevent an attacker from DESTROY_SESSION, and DESTROY_CLIENTID will prevent an attacker from
associating a rogue connection with a session, or associating a rogue associating a rogue connection with a session, or associating a rogue
session with a client ID. session with a client ID.
skipping to change at page 69, line 29 skipping to change at page 70, line 29
2. The client is used by a single user, and so the client ID and its 2. The client is used by a single user, and so the client ID and its
sessions are used by just that user. If the user's credential sessions are used by just that user. If the user's credential
expires, then session and client ID maintenance cannot occur, but expires, then session and client ID maintenance cannot occur, but
since the client has a single user, only that user is since the client has a single user, only that user is
inconvenienced. inconvenienced.
3. The physical client has multiple users, but the client 3. The physical client has multiple users, but the client
implementation has a unique client ID for each user. This is implementation has a unique client ID for each user. This is
effectively the same as the second scenario, but a disadvantage effectively the same as the second scenario, but a disadvantage
is that each user must be allocated at least one session each, so is that each user needs to be allocated at least one session
the approach suffers from lack of economy. each, so the approach suffers from lack of economy.
The SP4_SSV protection option uses the SSV (Section 1.5), via The SP4_SSV protection option uses the SSV (Section 1.5), via
RPCSEC_GSS and the SSV GSS mechanism (Section 2.10.9) to protect RPCSEC_GSS and the SSV GSS mechanism (Section 2.10.9) to protect
state from attack. The SP4_SSV protection option is intended for the state from attack. The SP4_SSV protection option is intended for the
situation comprised of a client that has multiple active users, and a situation comprised of a client that has multiple active users, and a
system administrator who wants to avoid the burden of installing a system administrator who wants to avoid the burden of installing a
permanent machine credential on each client. The SSV is established permanent machine credential on each client. The SSV is established
and updated on the server via SET_SSV (see Section 18.47). To and updated on the server via SET_SSV (see Section 18.47). To
prevent eavesdropping, a client SHOULD send SET_SSV via RPCSEC_GSS prevent eavesdropping, a client SHOULD send SET_SSV via RPCSEC_GSS
with the privacy service. Several aspects of the SSV make it with the privacy service. Several aspects of the SSV make it
skipping to change at page 72, line 50 skipping to change at page 73, line 50
that the SSV mechanism is acceptable whenever the client sends a that the SSV mechanism is acceptable whenever the client sends a
SECINFO or SECINFO_NO_NAME operation (see Section 2.6). SECINFO or SECINFO_NO_NAME operation (see Section 2.6).
The SSV mechanism defines four subkeys derived from the SSV value. The SSV mechanism defines four subkeys derived from the SSV value.
Each time SET_SSV is invoked the subkeys are recalculated by the Each time SET_SSV is invoked the subkeys are recalculated by the
client and server. The calculation of each of the four subkeys client and server. The calculation of each of the four subkeys
depends on each of the four respective ssv_subkey4 enumerated values. depends on each of the four respective ssv_subkey4 enumerated values.
The calculation uses the HMAC [11], algorithm, using the current SSV The calculation uses the HMAC [11], algorithm, using the current SSV
as the key, the one way hash algorithm as negotiated by EXCHANGE_ID, as the key, the one way hash algorithm as negotiated by EXCHANGE_ID,
and the input text as represented by the XDR encoded enumeration and the input text as represented by the XDR encoded enumeration
value for that subkey of data type ssv_subkey4. value for that subkey of data type ssv_subkey4. If the length of the
output of the HMAC algorithm exceeds the length of key of encryption
algorithm (which is also negotiated by EXCHANGE_ID), then the subkey
MUST be truncated from the HMAC output, i.e. if the subkey is of N
bytes long, then the first N bytes of the HMAC output MUST be used
for the subkey. The specification of EXCHANGE_ID states that the
length of the output of the HMAC algorithm MUST NOT be less than
length of subkey needed for the encryption algorithm (see
Section 18.35).
/* Input for computing subkeys */ /* Input for computing subkeys */
enum ssv_subkey4 { enum ssv_subkey4 {
SSV4_SUBKEY_MIC_I2T = 1, SSV4_SUBKEY_MIC_I2T = 1,
SSV4_SUBKEY_MIC_T2I = 2, SSV4_SUBKEY_MIC_T2I = 2,
SSV4_SUBKEY_SEAL_I2T = 3, SSV4_SUBKEY_SEAL_I2T = 3,
SSV4_SUBKEY_SEAL_T2I = 4 SSV4_SUBKEY_SEAL_T2I = 4
}; };
The subkey derived from SSV4_SUBKEY_MIC_I2T is used for calculating The subkey derived from SSV4_SUBKEY_MIC_I2T is used for calculating
message integrity codes (MICs) that originate from the NFSv4.1 message integrity codes (MICs) that originate from the NFSv4.1
client, whether as part of a request over the fore channel, or a client, whether as part of a request over the fore channel, or a
response over the backchannel. The subkey derived from SSV4_SUBKEY- response over the backchannel. The subkey derived from
MIST2I is used for MICs originating from the NFSv4.1 server. The SSV4_SUBKEY_MIC_T2I is used for MICs originating from the NFSv4.1
subkey derived from SSV4_SUBKEY_SEAL_I2T is used for encryption text server. The subkey derived from SSV4_SUBKEY_SEAL_I2T is used for
originating from the NFSv4.1 client and the subkey derived from encryption text originating from the NFSv4.1 client and the subkey
SSV4_SUBKEY_SEAL_T2I is used for encryption text originating from the derived from SSV4_SUBKEY_SEAL_T2I is used for encryption text
NFSv4.1 server. originating from the NFSv4.1 server.
The PerMsgToken description is based on an XDR definition: The PerMsgToken description is based on an XDR definition:
/* Input for computing smt_hmac */ /* Input for computing smt_hmac */
struct ssv_mic_plain_tkn4 { struct ssv_mic_plain_tkn4 {
uint32_t smpt_ssv_seq; uint32_t smpt_ssv_seq;
opaque smpt_orig_plain<>; opaque smpt_orig_plain<>;
}; };
/* SSV GSS PerMsgToken token */ /* SSV GSS PerMsgToken token */
skipping to change at page 74, line 4 skipping to change at page 75, line 12
The field smt_hmac is an HMAC calculated by using the subkey derived The field smt_hmac is an HMAC calculated by using the subkey derived
from SSV4_SUBKEY_MIC_I2T or SSV4_SUBKEY_MIC_T2I as the key, the one from SSV4_SUBKEY_MIC_I2T or SSV4_SUBKEY_MIC_T2I as the key, the one
way hash algorithm as negotiated by EXCHANGE_ID, and the input text way hash algorithm as negotiated by EXCHANGE_ID, and the input text
as represented by data of type ssv_mic_plain_tkn4. The field as represented by data of type ssv_mic_plain_tkn4. The field
smpt_ssv_seq is the same as smt_ssv_seq. The field smpt_orig_plain smpt_ssv_seq is the same as smt_ssv_seq. The field smpt_orig_plain
is the "message" input passed to GSS_GetMIC() (see Section 2.3.1 of is the "message" input passed to GSS_GetMIC() (see Section 2.3.1 of
[7]). The caller of GSS_GetMIC() provides a pointer to a buffer [7]). The caller of GSS_GetMIC() provides a pointer to a buffer
containing the plain text. The SSV mechanism's entry point for containing the plain text. The SSV mechanism's entry point for
GSS_GetMIC() encodes this into an opaque array, and the encoding will GSS_GetMIC() encodes this into an opaque array, and the encoding will
include an initial four byte length, plus any necessary padding. include an initial four byte length, plus any necessary padding.
Prepended to this will be the XDR encoded value of smpt_ssv_seq thus Prepended to this will be the XDR encoded value of smpt_ssv_seq thus
making up an XDR encoding of a value of data type ssv_mic_plain_tkn4, making up an XDR encoding of a value of data type ssv_mic_plain_tkn4,
which in turn is the input into the HMAC. which in turn is the input into the HMAC.
The token emitted by GSS_GetMIC() is XDR encoded and of XDR data type The token emitted by GSS_GetMIC() is XDR encoded and of XDR data type
ssv_mic_tkn4. The field smt_ssv_seq comes from the SSV sequence ssv_mic_tkn4. The field smt_ssv_seq comes from the SSV sequence
number which is equal to 1 after SET_SSV (Section 18.47) is called number which is equal to 1 after SET_SSV (Section 18.47) is called
the first time on a client ID. Thereafter, it is incremented on each the first time on a client ID. Thereafter, the SSV sequence number
SET_SSV. Thus smt_ssv_seq represents the version of the SSV at the is incremented on each SET_SSV. Thus smt_ssv_seq represents the
time GSS_GetMIC() was called. As noted in Section 18.35, the client version of the SSV at the time GSS_GetMIC() was called. As noted in
and server can maintain multiple concurrent versions of the SSV. Section 18.35, the client and server can maintain multiple concurrent
This allows the SSV to be changed without serializing all RPC calls versions of the SSV. This allows the SSV to be changed without
that use the SSV mechanism with SET_SSV operations. Once the HMAC is serializing all RPC calls that use the SSV mechanism with SET_SSV
calculated, it is XDR encoded into smt_hmac, which will include an operations. Once the HMAC is calculated, it is XDR encoded into
initial four byte length, and any necessary padding. Prepended to smt_hmac, which will include an initial four byte length, and any
this will be the XDR encoded value of smt_ssv_seq. necessary padding. Prepended to this will be the XDR encoded value
of smt_ssv_seq.
The SealedMessage description is based on an XDR definition: The SealedMessage description is based on an XDR definition:
/* Input for computing ssct_encr_data and ssct_hmac */ /* Input for computing ssct_encr_data and ssct_hmac */
struct ssv_seal_plain_tkn4 { struct ssv_seal_plain_tkn4 {
opaque sspt_confounder<>; opaque sspt_confounder<>;
uint32_t sspt_ssv_seq; uint32_t sspt_ssv_seq;
opaque sspt_orig_plain<>; opaque sspt_orig_plain<>;
opaque sspt_pad<>; opaque sspt_pad<>;
}; };
skipping to change at page 78, line 9 skipping to change at page 79, line 16
server restarted or not, and the client notes this for future server restarted or not, and the client notes this for future
reference. reference.
If the client specified SP4_SSV state protection when the client ID If the client specified SP4_SSV state protection when the client ID
was created, then it SHOULD send SET_SSV in the first COMPOUND after was created, then it SHOULD send SET_SSV in the first COMPOUND after
the session is created. Each time a new principal goes to use the the session is created. Each time a new principal goes to use the
client ID, it SHOULD send a SET_SSV again. client ID, it SHOULD send a SET_SSV again.
If the client wants to use delegations, layouts, directory If the client wants to use delegations, layouts, directory
notifications, or any other state that requires a backchannel, then notifications, or any other state that requires a backchannel, then
it must add a connection to the backchannel if CREATE_SESSION did not it needs to add a connection to the backchannel if CREATE_SESSION did
already do so. The client creates a connection, and calls not already do so. The client creates a connection, and calls
BIND_CONN_TO_SESSION to associate the connection with the session and BIND_CONN_TO_SESSION to associate the connection with the session and
the session's backchannel. If CREATE_SESSION did not already do so, the session's backchannel. If CREATE_SESSION did not already do so,
the client MUST tell the server what security is required in order the client MUST tell the server what security is required in order
for the client to accept callbacks. The client does this via for the client to accept callbacks. The client does this via
BACKCHANNEL_CTL. If the client selected SP4_MACH_CRED or SP4_SSV BACKCHANNEL_CTL. If the client selected SP4_MACH_CRED or SP4_SSV
protection when it called EXCHANGE_ID, then the client SHOULD specify protection when it called EXCHANGE_ID, then the client SHOULD specify
that the backchannel use RPCSEC_GSS contexts for security. that the backchannel use RPCSEC_GSS contexts for security.
If the client wants to use additional connections for the If the client wants to use additional connections for the
backchannel, then it must call BIND_CONN_TO_SESSION on each backchannel, then it needs to call BIND_CONN_TO_SESSION on each
connection it wants to use with the session. If the client wants to connection it wants to use with the session. If the client wants to
use additional connections for the fore channel, then it must call use additional connections for the fore channel, then it needs to
BIND_CONN_TO_SESSION if it specified SP4_SSV or SP4_MACH_CRED state call BIND_CONN_TO_SESSION if it specified SP4_SSV or SP4_MACH_CRED
protection when the client ID was created. state protection when the client ID was created.
At this point the session has reached steady state. At this point the session has reached steady state.
2.10.11. Session Inactivity Timer 2.10.11. Session Inactivity Timer
The server MAY maintain a session inactivity timer for each session. The server MAY maintain a session inactivity timer for each session.
If the session inactivity timer expires, then the server MAY destroy If the session inactivity timer expires, then the server MAY destroy
the session. To avoid losing a session due to inactivity, the client the session. To avoid losing a session due to inactivity, the client
MUST renew the session inactivity timer. The length of session MUST renew the session inactivity timer. The length of session
inactivity timer MUST NOT be less than the lease_time attribute inactivity timer MUST NOT be less than the lease_time attribute
skipping to change at page 79, line 16 skipping to change at page 80, line 22
If all RPCSEC_GSS contexts granted by the client to the server for If all RPCSEC_GSS contexts granted by the client to the server for
callback use have expired, the client MUST establish a new context callback use have expired, the client MUST establish a new context
via BACKCHANNEL_CTL. The sr_status_flags field of the SEQUENCE via BACKCHANNEL_CTL. The sr_status_flags field of the SEQUENCE
results indicates when callback contexts are nearly expired, or fully results indicates when callback contexts are nearly expired, or fully
expired (see Section 18.46.3). expired (see Section 18.46.3).
2.10.12.1.2. Connection Loss 2.10.12.1.2. Connection Loss
If the client loses the last connection of the session, and if wants If the client loses the last connection of the session, and if wants
to retain the session, then it must create a new connection, and if, to retain the session, then it needs to create a new connection, and
when the client ID was created, BIND_CONN_TO_SESSION was specified in if, when the client ID was created, BIND_CONN_TO_SESSION was
the spo_must_enforce list, the client MUST use BIND_CONN_TO_SESSION specified in the spo_must_enforce list, the client MUST use
to associate the connection with the session. BIND_CONN_TO_SESSION to associate the connection with the session.
If there was a request outstanding at the time the of connection If there was a request outstanding at the time the of connection
loss, then if client wants to continue to use the session it MUST loss, then if client wants to continue to use the session it MUST
retry the request, as described in Section 2.10.6.2. Note that it is retry the request, as described in Section 2.10.6.2. Note that it is
not necessary to retry requests over a connection with the same not necessary to retry requests over a connection with the same
source network address or the same destination network address as the source network address or the same destination network address as the
lost connection. As long as the session ID, slot ID, and sequence ID lost connection. As long as the session ID, slot ID, and sequence ID
in the retry match that of the original request, the server will in the retry match that of the original request, the server will
recognize the request as a retry if it executed the request prior to recognize the request as a retry if it executed the request prior to
disconnect. disconnect.
If the connection that was lost was the last one associated with the If the connection that was lost was the last one associated with the
backchannel, and the client wants to retain the backchannel and/or backchannel, and the client wants to retain the backchannel and/or
not put recallable state subject to revocation, the client must not put recallable state subject to revocation, the client needs to
reconnect, and if it does, it MUST associate the connection to the reconnect, and if it does, it MUST associate the connection to the
session and backchannel via BIND_CONN_TO_SESSION. The server SHOULD session and backchannel via BIND_CONN_TO_SESSION. The server SHOULD
indicate when it has no callback connection via the sr_status_flags indicate when it has no callback connection via the sr_status_flags
result from SEQUENCE. result from SEQUENCE.
2.10.12.1.3. Backchannel GSS Context Loss 2.10.12.1.3. Backchannel GSS Context Loss
Via the sr_status_flags result of the SEQUENCE operation or other Via the sr_status_flags result of the SEQUENCE operation or other
means, the client will learn if some or all of the RPCSEC_GSS means, the client will learn if some or all of the RPCSEC_GSS
contexts it assigned to the backchannel have been lost. If the contexts it assigned to the backchannel have been lost. If the
client wants to the retain the backchannel and/or not put recallable client wants to the retain the backchannel and/or not put recallable
state subjection to revocation, the client must use BACKCHANNEL_CTL state subjection to revocation, the client needs to use
to assign new contexts. BACKCHANNEL_CTL to assign new contexts.
2.10.12.1.4. Loss of Session 2.10.12.1.4. Loss of Session
The replier might lose a record of the session. Causes include: The replier might lose a record of the session. Causes include:
o Replier failure and restart o Replier failure and restart
o A catastrophe that causes the reply cache to be corrupted or lost o A catastrophe that causes the reply cache to be corrupted or lost
on the media it was stored on. This applies even if the replier on the media it was stored on. This applies even if the replier
indicated in the CREATE_SESSION results that it would persist the indicated in the CREATE_SESSION results that it would persist the
skipping to change at page 82, line 15 skipping to change at page 83, line 18
the client to the server is RECOMMENDED. the client to the server is RECOMMENDED.
A variation on the above is that after a server's network address A variation on the above is that after a server's network address
moves, there is no NFSv4.1 server listening. E.g. no listener on moves, there is no NFSv4.1 server listening. E.g. no listener on
port 2049, the NFSv4 server returns NFS4ERR_MINOR_VERS_MISMATCH, the port 2049, the NFSv4 server returns NFS4ERR_MINOR_VERS_MISMATCH, the
NFS server returns a PROG_MISMATCH error, the RPC listener on 2049 NFS server returns a PROG_MISMATCH error, the RPC listener on 2049
returns PROG_MISMATCH, or attempts to re-connect to the network returns PROG_MISMATCH, or attempts to re-connect to the network
address timeout. These SHOULD be treated as equivalent to SEQUENCE address timeout. These SHOULD be treated as equivalent to SEQUENCE
returning NFS4ERR_BADSESSION for these purposes. returning NFS4ERR_BADSESSION for these purposes.
When the client detects session loss, it must call CREATE_SESSION to When the client detects session loss, it needs to call CREATE_SESSION
recover. Any non-idempotent operations that were in progress might to recover. Any non-idempotent operations that were in progress
have been performed on the server at the time of session loss. The might have been performed on the server at the time of session loss.
client has no general way to recover from this. The client has no general way to recover from this.
Note that loss of session does not imply loss of lock, open, Note that loss of session does not imply loss of lock, open,
delegation, or layout state because locks, opens, delegations, and delegation, or layout state because locks, opens, delegations, and
layouts are tied to the client ID and depend on the client ID, not layouts are tied to the client ID and depend on the client ID, not
the session. Nor does loss of lock, open, delegation, or layout the session. Nor does loss of lock, open, delegation, or layout
state imply loss of session state, because the session depends on the state imply loss of session state, because the session depends on the
client ID; loss of client ID however does imply loss of session, client ID; loss of client ID however does imply loss of session,
lock, open, delegation, and layout state. See Section 8.4.2. A lock, open, delegation, and layout state. See Section 8.4.2. A
session can survive a server restart, but lock recovery may still be session can survive a server restart, but lock recovery may still be
needed. needed.
skipping to change at page 91, line 43 skipping to change at page 92, line 43
3.3.15. device_addr4 3.3.15. device_addr4
struct device_addr4 { struct device_addr4 {
layouttype4 da_layout_type; layouttype4 da_layout_type;
opaque da_addr_body<>; opaque da_addr_body<>;
}; };
The device address is used to set up a communication channel with the The device address is used to set up a communication channel with the
storage device. Different layout types will require different data storage device. Different layout types will require different data
types to define how they communicate with storage devices. The types to define how they communicate with storage devices. The
opaque da_addr_body field must be interpreted based on the specified opaque da_addr_body field is interpreted based on the specified
da_layout_type field. da_layout_type field.
This document defines the device address for the NFSv4.1 file layout This document defines the device address for the NFSv4.1 file layout
(see Section 13.3), which identifies a storage device by network IP (see Section 13.3), which identifies a storage device by network IP
address and port number. This is sufficient for the clients to address and port number. This is sufficient for the clients to
communicate with the NFSv4.1 storage devices, and may be sufficient communicate with the NFSv4.1 storage devices, and may be sufficient
for other layout types as well. Device types for object storage for other layout types as well. Device types for object storage
devices and block storage devices (e.g., SCSI volume labels) are devices and block storage devices (e.g., SCSI volume labels) are
defined by their respective layout specifications. defined by their respective layout specifications.
3.3.16. layout_content4 3.3.16. layout_content4
struct layout_content4 { struct layout_content4 {
layouttype4 loc_type; layouttype4 loc_type;
opaque loc_body<>; opaque loc_body<>;
}; };
The loc_body field must be interpreted based on the layout type The loc_body field is interpreted based on the layout type
(loc_type). This document defines the loc_body for the NFSv4.1 file (loc_type). This document defines the loc_body for the NFSv4.1 file
layout type is defined; see Section 13.3 for its definition. layout type is defined; see Section 13.3 for its definition.
3.3.17. layout4 3.3.17. layout4
struct layout4 { struct layout4 {
offset4 lo_offset; offset4 lo_offset;
length4 lo_length; length4 lo_length;
layoutiomode4 lo_iomode; layoutiomode4 lo_iomode;
layout_content4 lo_content; layout_content4 lo_content;
skipping to change at page 97, line 39 skipping to change at page 98, line 39
example, if paths /a/b/c and /a/d/c refer to the same file, the example, if paths /a/b/c and /a/d/c refer to the same file, the
server SHOULD return the same filehandle for both path names server SHOULD return the same filehandle for both path names
traversals. traversals.
4.2.2. Persistent Filehandle 4.2.2. Persistent Filehandle
A persistent filehandle is defined as having a fixed value for the A persistent filehandle is defined as having a fixed value for the
lifetime of the file system object to which it refers. Once the lifetime of the file system object to which it refers. Once the
server creates the filehandle for a file system object, the server server creates the filehandle for a file system object, the server
MUST accept the same filehandle for the object for the lifetime of MUST accept the same filehandle for the object for the lifetime of
the object. If the server restarts, the NFS server must honor the the object. If the server restarts, the NFS server MUST honor the
same filehandle value as it did in the server's previous same filehandle value as it did in the server's previous
instantiation. Similarly, if the file system is migrated, the new instantiation. Similarly, if the file system is migrated, the new
NFS server must honor the same filehandle as the old NFS server. NFS server MUST honor the same filehandle as the old NFS server.
The persistent filehandle will be become stale or invalid when the The persistent filehandle will be become stale or invalid when the
file system object is removed. When the server is presented with a file system object is removed. When the server is presented with a
persistent filehandle that refers to a deleted object, it MUST return persistent filehandle that refers to a deleted object, it MUST return
an error of NFS4ERR_STALE. A filehandle may become stale when the an error of NFS4ERR_STALE. A filehandle may become stale when the
file system containing the object is no longer available. The file file system containing the object is no longer available. The file
system may become unavailable if it exists on removable media and the system may become unavailable if it exists on removable media and the
media is no longer available at the server or the file system in media is no longer available at the server or the file system in
whole has been destroyed or the file system has simply been removed whole has been destroyed or the file system has simply been removed
from the server's name space (i.e. unmounted in a UNIX environment). from the server's name space (i.e. unmounted in a UNIX environment).
skipping to change at page 100, line 40 skipping to change at page 101, line 40
LOOKUP B LOOKUP B
GETFH GETFH
Note that the COMPOUND procedure does not provide atomicity. This Note that the COMPOUND procedure does not provide atomicity. This
example only reduces the overhead of recovering from an expired example only reduces the overhead of recovering from an expired
filehandle. filehandle.
5. File Attributes 5. File Attributes
To meet the requirements of extensibility and increased To meet the requirements of extensibility and increased
interoperability with non-UNIX platforms, attributes must be handled interoperability with non-UNIX platforms, attributes need to be
in a flexible manner. The NFSv3 fattr3 structure contains a fixed handled in a flexible manner. The NFSv3 fattr3 structure contains a
list of attributes that not all clients and servers are able to fixed list of attributes that not all clients and servers are able to
support or care about. The fattr3 structure can not be extended as support or care about. The fattr3 structure can not be extended as
new needs arise and it provides no way to indicate non-support. With new needs arise and it provides no way to indicate non-support. With
the NFSv4.1 protocol, the client is able query what attributes the the NFSv4.1 protocol, the client is able query what attributes the
server supports and construct requests with only those supported server supports and construct requests with only those supported
attributes (or a subset thereof). attributes (or a subset thereof).
To this end, attributes are divided into three groups: REQUIRED, To this end, attributes are divided into three groups: REQUIRED,
RECOMMENDED, and named. Both REQUIRED and RECOMMENDED attributes are RECOMMENDED, and named. Both REQUIRED and RECOMMENDED attributes are
supported in the NFSv4.1 protocol by a specific and well-defined supported in the NFSv4.1 protocol by a specific and well-defined
encoding and are identified by number. They are requested by setting encoding and are identified by number. They are requested by setting
skipping to change at page 101, line 37 skipping to change at page 102, line 37
| LOOKUP | "x11icon" | ; look up specific attribute | | LOOKUP | "x11icon" | ; look up specific attribute |
| READ | 0,4096 | ; read stream of bytes | | READ | 0,4096 | ; read stream of bytes |
+----------+-----------+---------------------------------+ +----------+-----------+---------------------------------+
Named attributes are intended for data needed by applications rather Named attributes are intended for data needed by applications rather
than by an NFS client implementation. NFS implementors are strongly than by an NFS client implementation. NFS implementors are strongly
encouraged to define their new attributes as RECOMMENDED attributes encouraged to define their new attributes as RECOMMENDED attributes
by bringing them to the IETF standards-track process. by bringing them to the IETF standards-track process.
The set of attributes which are classified as REQUIRED is The set of attributes which are classified as REQUIRED is
deliberately small since servers must do whatever it takes to support deliberately small since servers need to do whatever it takes to
them. A server should support as many of the RECOMMENDED attributes support them. A server should support as many of the RECOMMENDED
as possible but by their definition, the server is not required to attributes as possible but by their definition, the server is not
support all of them. Attributes are deemed REQUIRED if the data is required to support all of them. Attributes are deemed REQUIRED if
both needed by a large number of clients and is not otherwise the data is both needed by a large number of clients and is not
reasonably computable by the client when support is not provided on otherwise reasonably computable by the client when support is not
the server. provided on the server.
Note that the hidden directory returned by OPENATTR is a convenience Note that the hidden directory returned by OPENATTR is a convenience
for protocol processing. The client should not make any assumptions for protocol processing. The client should not make any assumptions
about the server's implementation of named attributes and whether the about the server's implementation of named attributes and whether the
underlying file system at the server has a named attribute directory underlying file system at the server has a named attribute directory
or not. Therefore, operations such as SETATTR and GETATTR on the or not. Therefore, operations such as SETATTR and GETATTR on the
named attribute directory are undefined. named attribute directory are undefined.
5.1. REQUIRED Attributes 5.1. REQUIRED Attributes
skipping to change at page 102, line 22 skipping to change at page 103, line 22
limited in some ways. A client may ask for any of these attributes limited in some ways. A client may ask for any of these attributes
to be returned by setting a bit in the GETATTR request and the server to be returned by setting a bit in the GETATTR request and the server
must return their value. must return their value.
5.2. RECOMMENDED Attributes 5.2. RECOMMENDED Attributes
These attributes are understood well enough to warrant support in the These attributes are understood well enough to warrant support in the
NFSv4.1 protocol. However, they may not be supported on all clients NFSv4.1 protocol. However, they may not be supported on all clients
and servers. A client may ask for any of these attributes to be and servers. A client may ask for any of these attributes to be
returned by setting a bit in the GETATTR request but must handle the returned by setting a bit in the GETATTR request but must handle the
case where the server does not return them. A client may ask for the case where the server does not return them. A client MAY ask for the
set of attributes the server supports and SHOULD NOT request set of attributes the server supports and SHOULD NOT request
attributes the server does not support. A server should be tolerant attributes the server does not support. A server should be tolerant
of requests for unsupported attributes and simply not return them of requests for unsupported attributes and simply not return them
rather than considering the request an error. It is expected that rather than considering the request an error. It is expected that
servers will support all attributes they comfortably can and only servers will support all attributes they comfortably can and only
fail to support attributes which are difficult to support in their fail to support attributes which are difficult to support in their
operating environments. A server should provide attributes whenever operating environments. A server should provide attributes whenever
they don't have to "tell lies" to the client. For example, a file they don't have to "tell lies" to the client. For example, a file
modification time should be either an accurate time or should not be modification time should be either an accurate time or should not be
supported by the server. This will not always be comfortable to supported by the server. This will not always be comfortable to
skipping to change at page 103, line 7 skipping to change at page 104, line 7
operations that work on more typical directories. In particular, operations that work on more typical directories. In particular,
READDIR may be used to get a list of such named attributes and LOOKUP READDIR may be used to get a list of such named attributes and LOOKUP
and OPEN may select a particular attribute. Creation of a new named and OPEN may select a particular attribute. Creation of a new named
attribute may be the result of an OPEN specifying file creation. attribute may be the result of an OPEN specifying file creation.
Once an OPEN is done, named attributes may be examined and changed by Once an OPEN is done, named attributes may be examined and changed by
normal READ and WRITE operations using the filehandles and stateids normal READ and WRITE operations using the filehandles and stateids
returned by OPEN. returned by OPEN.
Named attributes and the named attribute directory may have their own Named attributes and the named attribute directory may have their own
(non-named) attributes. Each of objects must have all of the (non-named) attributes. Each of these objects MUST have all of the
REQUIRED attributes and may have additional RECOMMENDED attributes. REQUIRED attributes and may have additional RECOMMENDED attributes.
However, the set of attributes for named attributes and the named However, the set of attributes for named attributes and the named
attribute directory need not be as large as, and typically will not attribute directory need not be as large as, and typically will not
be as large as that for other objects in that file system. be as large as that for other objects in that file system.
Named attributes and the named attribute directory may be the target Named attributes and the named attribute directory may be the target
of delegations (in the case of the named attribute directory these of delegations (in the case of the named attribute directory these
will be directory delegations). However, since granting of will be directory delegations). However, since granting of
delegations or not is within the server's discretion, a server need delegations or not is within the server's discretion, a server need
not support delegations on named attributes or the named attribute not support delegations on named attributes or the named attribute
skipping to change at page 118, line 14 skipping to change at page 119, line 14
The "dns_domain" portion of the owner string is meant to be a DNS The "dns_domain" portion of the owner string is meant to be a DNS
domain name. For example, user@example.org. Servers should accept domain name. For example, user@example.org. Servers should accept
as valid a set of users for at least one domain. A server may treat as valid a set of users for at least one domain. A server may treat
other domains as having no valid translations. A more general other domains as having no valid translations. A more general
service is provided when a server is capable of accepting users for service is provided when a server is capable of accepting users for
multiple domains, or for all domains, subject to security multiple domains, or for all domains, subject to security
constraints. constraints.
In the case where there is no translation available to the client or In the case where there is no translation available to the client or
server, the attribute value must be constructed without the "@". server, the attribute value will be constructed without the "@".
Therefore, the absence of the @ from the owner or owner_group Therefore, the absence of the @ from the owner or owner_group
attribute signifies that no translation was available at the sender attribute signifies that no translation was available at the sender
and that the receiver of the attribute should not use that string as and that the receiver of the attribute should not use that string as
a basis for translation into its own internal format. Even though a basis for translation into its own internal format. Even though
the attribute value can not be translated, it may still be useful. the attribute value can not be translated, it may still be useful.
In the case of a client, the attribute string may be used for local In the case of a client, the attribute string may be used for local
display of ownership. display of ownership.
To provide a greater degree of compatibility with NFSv3, which To provide a greater degree of compatibility with NFSv3, which
identified users and groups by 32-bit unsigned user identifiers and identified users and groups by 32-bit unsigned user identifiers and
skipping to change at page 193, line 12 skipping to change at page 194, line 12
The backchannel is established by CREATE_SESSION and The backchannel is established by CREATE_SESSION and
BIND_CONN_TO_SESSION, and the client is required to maintain it. BIND_CONN_TO_SESSION, and the client is required to maintain it.
Because the backchannel may be down, even temporarily, correct Because the backchannel may be down, even temporarily, correct
protocol operation does not depend on them. Preliminary testing of protocol operation does not depend on them. Preliminary testing of
backchannel functionality by means of a CB_COMPOUND procedure with a backchannel functionality by means of a CB_COMPOUND procedure with a
single operation, CB_SEQUENCE, can be used to check the continuity of single operation, CB_SEQUENCE, can be used to check the continuity of
the backchannel. A server avoids delegating responsibilities until the backchannel. A server avoids delegating responsibilities until
it has determined that the backchannel exists. Because the granting it has determined that the backchannel exists. Because the granting
of a delegation is always conditional upon the absence of conflicting of a delegation is always conditional upon the absence of conflicting
access, clients must not assume that a delegation will be granted and access, clients MUST NOT assume that a delegation will be granted and
they must always be prepared for OPENs, WANT_DELEGATIONs, and they MUST always be prepared for OPENs, WANT_DELEGATIONs, and
GET_DIR_DELEGATIONs to be processed without any delegations being GET_DIR_DELEGATIONs to be processed without any delegations being
granted. granted.
Once granted, a delegation behaves in many ways like a lock. There Once granted, a delegation behaves in many ways like a lock. There
is an associated lease that is subject to renewal together with all is an associated lease that is subject to renewal together with all
of the other leases held by that client. of the other leases held by that client.
Unlike locks, an operation by a second client to a delegated file Unlike locks, an operation by a second client to a delegated file
will cause the server to recall a delegation through a callback. For will cause the server to recall a delegation through a callback. For
individual operations, we will describe, under IMPLEMENTATION, when individual operations, we will describe, under IMPLEMENTATION, when
skipping to change at page 193, line 36 skipping to change at page 194, line 36
o The server is free to recall a delegation whenever it feels it is o The server is free to recall a delegation whenever it feels it is
desirable and may do so even if no operations requiring recall are desirable and may do so even if no operations requiring recall are
being done. being done.
o Operations done outside the NFSv4 protocol, due to, for example, o Operations done outside the NFSv4 protocol, due to, for example,
access by other protocols, or by local access, also need to result access by other protocols, or by local access, also need to result
in delegation recall when they make analogous changes to file in delegation recall when they make analogous changes to file
system data. What is crucial is if the change would invalidate system data. What is crucial is if the change would invalidate
the guarantees provided by the delegation. When this is possible, the guarantees provided by the delegation. When this is possible,
the delegation needs to be recalled and must be returned or the delegation needs to be recalled and MUST be returned or
revoked before allowing the operation to proceed. revoked before allowing the operation to proceed.
o The semantics of the file system are crucial in defining when o The semantics of the file system are crucial in defining when
delegation recall is required. If a particular change within a delegation recall is required. If a particular change within a
specific implementation causes change to a file attribute, then specific implementation causes change to a file attribute, then
delegation recall is required, whether that operation has been delegation recall is required, whether that operation has been
specifically listed as requiring delegation recall. Again, what specifically listed as requiring delegation recall. Again, what
is critical is whether the guarantees provided by the delegation is critical is whether the guarantees provided by the delegation
are being invalidated. are being invalidated.
skipping to change at page 194, line 17 skipping to change at page 195, line 17
o For READ, see Section 18.22.4. o For READ, see Section 18.22.4.
o For REMOVE, see Section 18.25.4. o For REMOVE, see Section 18.25.4.
o For RENAME, see Section 18.26.4. o For RENAME, see Section 18.26.4.
o For SETATTR, see Section 18.30.4. o For SETATTR, see Section 18.30.4.
o For WRITE, see Section 18.32.4. o For WRITE, see Section 18.32.4.
On recall, the client holding the delegation must flush modified On recall, the client holding the delegation needs to flush modified
state (such as modified data) to the server and return the state (such as modified data) to the server and return the
delegation. The conflicting request will not be acted on until the delegation. The conflicting request will not be acted on until the
recall is complete. The recall is considered complete when the recall is complete. The recall is considered complete when the
client returns the delegation or the server times its wait for the client returns the delegation or the server times its wait for the
delegation to be returned and revokes the delegation as a result of delegation to be returned and revokes the delegation as a result of
the timeout. In the interim, the server will either delay responding the timeout. In the interim, the server will either delay responding
to conflicting requests or respond to them with NFS4ERR_DELAY. to conflicting requests or respond to them with NFS4ERR_DELAY.
Following the resolution of the recall, the server has the Following the resolution of the recall, the server has the
information necessary to grant or deny the second client's request. information necessary to grant or deny the second client's request.
skipping to change at page 194, line 51 skipping to change at page 195, line 51
deny state for the file allows any particular open until the deny state for the file allows any particular open until the
delegation for the file has been returned. delegation for the file has been returned.
A client failure or a network partition can result in failure to A client failure or a network partition can result in failure to
respond to a recall callback. In this case, the server will revoke respond to a recall callback. In this case, the server will revoke
the delegation which in turn will render useless any modified state the delegation which in turn will render useless any modified state
still on the client. still on the client.
10.2.1. Delegation Recovery 10.2.1. Delegation Recovery
There are three situations that delegation recovery must deal with: There are three situations that delegation recovery needs to deal
with:
o Client restart o Client restart
o Server restart o Server restart
o Network partition (full or backchannel-only) o Network partition (full or backchannel-only)
In the event the client restarts, the failure to renew the lease will In the event the client restarts, the failure to renew the lease will
result in the revocation of byte-range locks and share reservations. result in the revocation of byte-range locks and share reservations.
Delegations, however, may be treated a bit differently. Delegations, however, may be treated a bit differently.
skipping to change at page 305, line 9 skipping to change at page 306, line 9
combination of roles in the request, the server results SHOULD return combination of roles in the request, the server results SHOULD return
only one of the roles from the combination specified by the client only one of the roles from the combination specified by the client
request. If the role specified by the server result does not match request. If the role specified by the server result does not match
the intended use by the client, the client should send the the intended use by the client, the client should send the
EXCHANGE_ID specifying just the interested pNFS role. EXCHANGE_ID specifying just the interested pNFS role.
If a pNFS metadata client gets a layout that refers it to an NFSv4.1 If a pNFS metadata client gets a layout that refers it to an NFSv4.1
data server, it needs a client ID on that data server. If it does data server, it needs a client ID on that data server. If it does
not yet have a client ID from the server that had the not yet have a client ID from the server that had the
EXCHGID4_FLAG_USE_PNFS_DS flag set in the EXCHANGE_ID results, then EXCHGID4_FLAG_USE_PNFS_DS flag set in the EXCHANGE_ID results, then
the client must send an EXCHANGE_ID to the data server, using the the client needs to send an EXCHANGE_ID to the data server, using the
same co_ownerid as it sent to the metadata server, with the same co_ownerid as it sent to the metadata server, with the
EXCHGID4_FLAG_USE_PNFS_DS flag set in the arguments. If the server's EXCHGID4_FLAG_USE_PNFS_DS flag set in the arguments. If the server's
EXCHANGE_ID results have EXCHGID4_FLAG_USE_PNFS_DS set, then the EXCHANGE_ID results have EXCHGID4_FLAG_USE_PNFS_DS set, then the
client may use the client ID to create sessions that will exchange client may use the client ID to create sessions that will exchange
pNFS data operations. The client ID returned by the data server has pNFS data operations. The client ID returned by the data server has
no relationship with the client ID returned by a metadata server no relationship with the client ID returned by a metadata server
unless the client IDs are equal and the server owners and server unless the client IDs are equal and the server owners and server
scopes of the data server and metadata server are equal. scopes of the data server and metadata server are equal.
In NFSv4.1, the session ID in the SEQUENCE operation implies the In NFSv4.1, the session ID in the SEQUENCE operation implies the
skipping to change at page 305, line 33 skipping to change at page 306, line 33
the stateid is associated with client ID on a metadata server, and the stateid is associated with client ID on a metadata server, and
because the session ID in the preceding SEQUENCE operation is tied to because the session ID in the preceding SEQUENCE operation is tied to
the client ID of the data server, the data server has no obvious way the client ID of the data server, the data server has no obvious way
to determine the metadata server from the COMPOUND procedure, and to determine the metadata server from the COMPOUND procedure, and
thus has no way to validate the stateid. One RECOMMENDED approach is thus has no way to validate the stateid. One RECOMMENDED approach is
for pNFS servers to encode metadata server routing and/or identity for pNFS servers to encode metadata server routing and/or identity
information in the data server filehandles as returned in the layout. information in the data server filehandles as returned in the layout.
If metadata server routing and/or identity information is encoded in If metadata server routing and/or identity information is encoded in
data server filehandles, when the metadata server identity or data server filehandles, when the metadata server identity or
location changes, the data server filehandles it gave out must become location changes, the data server filehandles it gave out will become
invalid (stale), and so the metadata server must first recall the invalid (stale), and so the metadata server MUST first recall the
layouts. Invalidating a data server filehandle does not render the layouts. Invalidating a data server filehandle does not render the
NFS client's data cache invalid. The client's cache should map a NFS client's data cache invalid. The client's cache should map a
data server filehandle to a metadata server filehandle, and a data server filehandle to a metadata server filehandle, and a
metadata server filehandle to cached data. metadata server filehandle to cached data.
If a server is both a metadata server and a data server, the server If a server is both a metadata server and a data server, the server
might need to distinguish operations on files that are directed to might need to distinguish operations on files that are directed to
the metadata server from those that are directed to the data server. the metadata server from those that are directed to the data server.
It is RECOMMENDED that the values of the filehandles returned by the It is RECOMMENDED that the values of the filehandles returned by the
LAYOUTGET operation to be different than the value of the filehandle LAYOUTGET operation to be different than the value of the filehandle
skipping to change at page 311, line 15 skipping to change at page 312, line 15
See the discussion on dense packing in Section 13.4.4. See the discussion on dense packing in Section 13.4.4.
The details on the interpretation of the layout are in Section 13.4. The details on the interpretation of the layout are in Section 13.4.
13.4. Interpreting the File Layout 13.4. Interpreting the File Layout
13.4.1. Determining the Stripe Unit Number 13.4.1. Determining the Stripe Unit Number
To find the stripe unit number that corresponds to the client's To find the stripe unit number that corresponds to the client's
logical file offset, the pattern offset must also be used. The i'th logical file offset, the pattern offset will also be used. The i'th
stripe unit (SUi) is: stripe unit (SUi) is:
relative_offset = file_offset - nfl_pattern_offset; relative_offset = file_offset - nfl_pattern_offset;
SUi = floor(relative_offset / stripe_unit_size); SUi = floor(relative_offset / stripe_unit_size);
13.4.2. Interpreting the File Layout Using Sparse Packing 13.4.2. Interpreting the File Layout Using Sparse Packing
When sparse packing is used, the algorithm for determining the When sparse packing is used, the algorithm for determining the
filehandle and set of data server network addresses to write stripe filehandle and set of data server network addresses to write stripe
unit i (SUi) to is: unit i (SUi) to is:
skipping to change at page 317, line 5 skipping to change at page 318, line 5
| 12 | 87 | E | | 12 | 87 | E |
+-----+------------+--------------+ +-----+------------+--------------+
13.4.4. Sparse and Dense Stripe Unit Packing 13.4.4. Sparse and Dense Stripe Unit Packing
The flag NFL4_UFLG_DENSE of the nfl_util4 data type (field nflh_util The flag NFL4_UFLG_DENSE of the nfl_util4 data type (field nflh_util
of the data type nfsv4_1_file_layouthint4 and field nfl_util of data of the data type nfsv4_1_file_layouthint4 and field nfl_util of data
type nfsv4_1_file_layout_ds_addr4) specifies how the data is packed type nfsv4_1_file_layout_ds_addr4) specifies how the data is packed
within the data file on a data server. It allows for two different within the data file on a data server. It allows for two different
data packings: sparse and dense. The packing type determines the data packings: sparse and dense. The packing type determines the
calculation that must be made to map the client visible file offset calculation that will be made to map the client visible file offset
to the offset within the data file located on the data server. to the offset within the data file located on the data server.
If nfl_util & NFL4_UFLG_DENSE is zero, this means that sparse packing If nfl_util & NFL4_UFLG_DENSE is zero, this means that sparse packing
is being used. Hence the logical offsets of the file as viewed by a is being used. Hence the logical offsets of the file as viewed by a
client issuing READs and WRITEs directly to the metadata server are client issuing READs and WRITEs directly to the metadata server are
the same offsets each data server uses when storing a stripe unit. the same offsets each data server uses when storing a stripe unit.
The effect then, for striping patterns consisting of at least two The effect then, for striping patterns consisting of at least two
stripe units, is for each data server file to be sparse or holey. So stripe units, is for each data server file to be sparse or holey. So
for example, suppose there is a pattern with three stripe units, the for example, suppose there is a pattern with three stripe units, the
stripe unit size is a 4096 bytes, and there are three data servers in stripe unit size is a 4096 bytes, and there are three data servers in
skipping to change at page 317, line 34 skipping to change at page 318, line 34
the above example, if data server 3 received a READ or WRITE request the above example, if data server 3 received a READ or WRITE request
for block 4, the data server would return NFS4ERR_PNFS_IO_HOLE. Thus for block 4, the data server would return NFS4ERR_PNFS_IO_HOLE. Thus
data servers need to understand the striping pattern in order to data servers need to understand the striping pattern in order to
support sparse packing. support sparse packing.
If nfl_util & NFL4_UFLG_DENSE is one, this means that dense packing If nfl_util & NFL4_UFLG_DENSE is one, this means that dense packing
is being used and the data server files have no holes. Dense packing is being used and the data server files have no holes. Dense packing
might be selected because the data server does not (efficiently) might be selected because the data server does not (efficiently)
support holey files, or because the data server cannot recognize support holey files, or because the data server cannot recognize
read-ahead unless there are no holes. If dense packing is indicated read-ahead unless there are no holes. If dense packing is indicated
in the layout, the data files must be packed. Using the example in the layout, the data files will be packed. Using the example
striping pattern and stripe unit size that was used for the sparse striping pattern and stripe unit size that was used for the sparse
packing example, the corresponding dense packing would have all packing example, the corresponding dense packing would have all
stripe units of all data files filled. Logical stripe units 0, 3, 6, stripe units of all data files filled. Logical stripe units 0, 3, 6,
... of the file would live on stripe units 0, 1, 2, ... of the file ... of the file would live on stripe units 0, 1, 2, ... of the file
of data server 1, logical stripe units 1, 4, 7, ... of the file would of data server 1, logical stripe units 1, 4, 7, ... of the file would
live on stripe units 0, 1, 2, ... of the file of data server 2, and live on stripe units 0, 1, 2, ... of the file of data server 2, and
logical stripe units 2, 5, 8, ... of the file would live on stripe logical stripe units 2, 5, 8, ... of the file would live on stripe
units 0, 1, 2, ... of the file of data server 3. units 0, 1, 2, ... of the file of data server 3.
Because dense packing does not leave holes on the data servers, the Because dense packing does not leave holes on the data servers, the
skipping to change at page 319, line 9 skipping to change at page 320, line 9
provide fail over, the RECOMMENDED method to offer the addresses is provide fail over, the RECOMMENDED method to offer the addresses is
to provide them in a replacement device ID to device address mapping, to provide them in a replacement device ID to device address mapping,
or a replacement device ID. When a client finds that no data server or a replacement device ID. When a client finds that no data server
in an element of nflda_multipath_ds_list responds, it SHOULD send a in an element of nflda_multipath_ds_list responds, it SHOULD send a
GETDEVICEINFO to attempt to replace the existing device ID to device GETDEVICEINFO to attempt to replace the existing device ID to device
address mappings. If the MDS detects that all data servers address mappings. If the MDS detects that all data servers
represented by an element of nflda_multipath_ds_list are unavailable, represented by an element of nflda_multipath_ds_list are unavailable,
the MDS SHOULD send a CB_NOTIFY_DEVICEID (if the client has indicated the MDS SHOULD send a CB_NOTIFY_DEVICEID (if the client has indicated
it wants device ID notifications for changed device IDs) to change it wants device ID notifications for changed device IDs) to change
the device ID to device address mappings to the available data the device ID to device address mappings to the available data
servers. If the device ID itself must be replaced, the MDS SHOULD servers. If the device ID itself will be replaced, the MDS SHOULD
recall all layouts with the device ID, and thus force the client to recall all layouts with the device ID, and thus force the client to
get new layouts and device ID mappings via LAYOUTGET and get new layouts and device ID mappings via LAYOUTGET and
GETDEVICEINFO. GETDEVICEINFO.
Generally if two network addresses appear in an element of Generally if two network addresses appear in an element of
nflda_multipath_ds_list they will designate the same data server and nflda_multipath_ds_list they will designate the same data server and
the two data server addresses will support the implementation client the two data server addresses will support the implementation client
ID or session trunking (the latter is RECOMMENDED) as defined in ID or session trunking (the latter is RECOMMENDED) as defined in
Section 2.10.5, and the two data server addresses will share the same Section 2.10.5, and the two data server addresses will share the same
server owner, or major ID of the server owner. It is not always server owner, or major ID of the server owner. It is not always
skipping to change at page 319, line 42 skipping to change at page 320, line 42
The first of these operation subsets consist of management The first of these operation subsets consist of management
operations. This subset consists of the BACKCHANNEL_CTL, operations. This subset consists of the BACKCHANNEL_CTL,
BIND_CONN_TO_SESSION, CREATE_SESSION, DESTROY_CLIENTID, BIND_CONN_TO_SESSION, CREATE_SESSION, DESTROY_CLIENTID,
DESTROY_SESSION, EXCHANGE_ID, SECINFO_NO_NAME, SET_SSV, and SEQUENCE DESTROY_SESSION, EXCHANGE_ID, SECINFO_NO_NAME, SET_SSV, and SEQUENCE
operations. The client may use these operations in order to set up operations. The client may use these operations in order to set up
and maintain the appropriate client IDs, sessions, and security and maintain the appropriate client IDs, sessions, and security
contexts involved in communication with the data server. Henceforth contexts involved in communication with the data server. Henceforth
these will be referred to as data-server housekeeping operations. these will be referred to as data-server housekeeping operations.
The second subset consists of COMMIT, READ, WRITE, and PUTFH, These The second subset consists of COMMIT, READ, WRITE, and PUTFH, These
operations must be used with a current filehandle specified by the operations MUST be used with a current filehandle specified by the
layout. In the case of PUTFH, the new current filehandle must be one layout. In the case of PUTFH, the new current filehandle MUST be one
taken from the layout. Henceforth, these will be referred to as taken from the layout. Henceforth, these will be referred to as
data-server I/O operations. As described in Section 12.5.1, a client data-server I/O operations. As described in Section 12.5.1, a client
MUST NOT send an I/O to a data server for which it does not hold a MUST NOT send an I/O to a data server for which it does not hold a
valid layout; the data server MUST reject such an I/O. valid layout; the data server MUST reject such an I/O.
Unless the server has a concurrent non-data-server personality, i.e. Unless the server has a concurrent non-data-server personality, i.e.
EXCHANGE_ID results returned (EXCHGID4_FLAG_USE_PNFS_DS | EXCHANGE_ID results returned (EXCHGID4_FLAG_USE_PNFS_DS |
EXCHGID4_FLAG_USE_PNFS_MDS) or (EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_PNFS_MDS) or (EXCHGID4_FLAG_USE_PNFS_DS |
EXCHGID4_FLAG_USE_NON_PNFS), see Section 13.1, any use of operations EXCHGID4_FLAG_USE_NON_PNFS), see Section 13.1, any attempted use of
other than those specified in the two subsets above MUST return operations against a data server other than those specified in the
NFS4ERR_NOTSUPP to the client. two subsets above MUST return NFS4ERR_NOTSUPP to the client.
When the server has concurrent data server and non-data-server When the server has concurrent data server and non-data-server
personalities, each COMPOUND sent by the client MUST be constructed personalities, each COMPOUND sent by the client MUST be constructed
so that it is appropriate to one of the two personalities, and must so that it is appropriate to one of the two personalities, and MUST
not contain operations directed to a mix of those personalities. The NOT contain operations directed to a mix of those personalities. The
server MUST enforce this. To understand the constraints, operations server MUST enforce this. To understand the constraints, operations
within a COMPOUND are divided into the following three classes: within a COMPOUND are divided into the following three classes:
1. An operation which is ambiguous regarding its personality 1. An operation which is ambiguous regarding its personality
assignment. These include all of the data-server housekeeping assignment. These include all of the data-server housekeeping
operations. Additionally, if the server has assigned filehandles operations. Additionally, if the server has assigned filehandles
so that the ones defined by the layout are the same as those used so that the ones defined by the layout are the same as those used
by the metadata server, all operations in the second class are by the metadata server, all operations using such filehandles are
within this group unless a stateid used is incompatible with a within this class, with the following exception. The exception
data-server personality in that it is a special stateid or has a is that if the operation uses a stateid that is incompatible with
non-zero seqid field. a data-server personality (e.g. a special stateid or the stateid
has a non-zero seqid field, see Section 13.9.1); if so, the
operation is in class 3, as described below. A COMPOUND
containing multiple class 1 operations (and operations of no
other class) MAY be sent to a server with multiple concurrent
data server and non-data-server personalities.
2. An operation which is referable to the data server personality. 2. An operation which is unambiguously referable to the data server
These are data-server I/O operations where the filehandle is one personality. These are data-server I/O operations where the
that can only be validly directed to the data-server personality. filehandle is one that can only be validly directed to the data-
server personality.
3. An operation which is referable to the non-data-server 3. An operation which is unambiguously referable to the non-data-
personality. These include all COMPOUND operations that are server personality. These include all COMPOUND operations that
neither data-server housekeeping nor data-server I/O operations are neither data-server housekeeping nor data-server I/O
plus data-server I/O operations where the current fh (or the one operations plus data-server I/O operations where the current fh
to be made the current fh in the case of PUTFH) is one that is (or the one to be made the current fh in the case of PUTFH) is
only valid on the metadata server or where a stateid is used that one that is only valid on the metadata server or where a stateid
is incompatible with the data server, i.e. is a special stateid is used that is incompatible with the data server, i.e. is a
or has a non-zero seqid value. special stateid or has a non-zero seqid value.
When a COMPOUND first executes an operation from class 3 above, it When a COMPOUND first executes an operation from class 3 above, it
acts as a normal COMPOUND on any other server and the data server acts as a normal COMPOUND on any other server and the data server
personality ceases to be relevant. There are no special restrictions personality ceases to be relevant. There are no special restrictions
on the operations in the COMPOUND to limit them to those for a data on the operations in the COMPOUND to limit them to those for a data
server. When a PUTFH is done, filehandles derived from the layout server. When a PUTFH is done, filehandles derived from the layout
are not valid. If their format is not normally acceptable, then are not valid. If their format is not normally acceptable, then
NFS4ERR_BADHANDLE MUST result. Similarly, current filehandles for NFS4ERR_BADHANDLE MUST result. Similarly, current filehandles for
other operations do not accept filehandles derived from layouts and other operations do not accept filehandles derived from layouts and
are not normally usable on the metadata server. Using these will are not normally usable on the metadata server. Using these will
skipping to change at page 340, line 50 skipping to change at page 341, line 50
15.1.3.1. NFS_OK (Error code 0) 15.1.3.1. NFS_OK (Error code 0)
Indicates the operation completed successfully, in that all of the Indicates the operation completed successfully, in that all of the
constituent operations completed without error. constituent operations completed without error.
15.1.3.2. NFS4ERR_MINOR_VERS_MISMATCH (Error code 10021) 15.1.3.2. NFS4ERR_MINOR_VERS_MISMATCH (Error code 10021)
The minor version specified is not one that the current listener The minor version specified is not one that the current listener
supports. This value is returned in the overall status for the supports. This value is returned in the overall status for the
Compound but is not associated with a specific operation since the Compound but is not associated with a specific operation since the
results must specify a result count of zero. results will specify a result count of zero.
15.1.3.3. NFS4ERR_NOT_ONLY_OP (Error Code 10081) 15.1.3.3. NFS4ERR_NOT_ONLY_OP (Error Code 10081)
Certain operations, which are allowed to be executed outside of a Certain operations, which are allowed to be executed outside of a
session, must be the only operation within a COMPOUND. This error session, MUST be the only operation within a COMPOUND. This error
results when that constraint is not met. results when that constraint is not met.
15.1.3.4. NFS4ERR_OP_ILLEGAL (Error Code 10044) 15.1.3.4. NFS4ERR_OP_ILLEGAL (Error Code 10044)
The operation code is not a valid one for the current Compound The operation code is not a valid one for the current Compound
procedure. The opcode in the result stream matched with this error procedure. The opcode in the result stream matched with this error
is the ILLEGAL value, although the value that appears in the request is the ILLEGAL value, although the value that appears in the request
stream may be different. Where an illegal value appears and the stream may be different. Where an illegal value appears and the
replier pre-parses all operations for a Compound procedure before replier pre-parses all operations for a Compound procedure before
doing any operation execution, an RPC-level XDR error may be returned doing any operation execution, an RPC-level XDR error may be returned
in this case. in this case.
15.1.3.5. NFS4ERR_OP_NOT_IN_SESSION (Error Code 10071) 15.1.3.5. NFS4ERR_OP_NOT_IN_SESSION (Error Code 10071)
Most forward operations and all callback operations are only valid Most forward operations and all callback operations are only valid
within the context of a session, so that the Compound request in within the context of a session, so that the Compound request in
question must begin with a Sequence operation. If an attempt is made question MUST begin with a Sequence operation. If an attempt is made
to execute these operations outside the context of session, this to execute these operations outside the context of session, this
error results. error results.
15.1.3.6. NFS4ERR_REP_TOO_BIG (Error Code 10066) 15.1.3.6. NFS4ERR_REP_TOO_BIG (Error Code 10066)
The reply to a Compound would exceed the channel's negotiated maximum The reply to a Compound would exceed the channel's negotiated maximum
response size. response size.
15.1.3.7. NFS4ERR_REP_TOO_BIG_TO_CACHE (Error Code 10067) 15.1.3.7. NFS4ERR_REP_TOO_BIG_TO_CACHE (Error Code 10067)
skipping to change at page 495, line 9 skipping to change at page 496, line 9
* The OID of the encryption algorithm. This property is * The OID of the encryption algorithm. This property is
represented by one of the algorithms in the ssp_encr_algs field represented by one of the algorithms in the ssp_encr_algs field
of the EXCHANGE_ID arguments. Once the client ID is confirmed, of the EXCHANGE_ID arguments. Once the client ID is confirmed,
this property cannot be updated by subsequent EXCHANGE_ID this property cannot be updated by subsequent EXCHANGE_ID
requests. requests.
* The length of the SSV. This property is represented by the * The length of the SSV. This property is represented by the
spi_ssv_len field in the EXCHANGE_ID results. Once the client spi_ssv_len field in the EXCHANGE_ID results. Once the client
ID is confirmed, this property cannot be updated by subsequent ID is confirmed, this property cannot be updated by subsequent
EXCHANGE_ID requests. The length of SSV MUST be equal to the EXCHANGE_ID requests.
length of the key used by the negotiated encryption algorithm.
There are REQUIRED and RECOMMENDED relationships among the
length of the key of the encryption algorithm ("key length"),
the length of the output of hash algorithm ("hash length"), and
the length of the SSV ("SSV length").
+ key length MUST be <= hash length. This is because the keys
used for the encryption algorithm are actually subkeys
derived from the SSV, and the derivation is via the hash
algorithm. The selection of an encryption algorithm with a
key length that exceeded the length of the output of the
hash algorithm would require padding, and thus weaken the
use of the encryption algorithm.
+ hash length SHOULD be <= SSV length. This is because the
SSV is a key used to derive subkeys via an HMAC, and it is
recommended that the key used as input to an HMAC be at
least as long as the length of the HMAC's hash algorithm's
output (see Section 3 of RFC2104 [11]).
+ key length SHOULD be <= SSV length. This is a transitive
result of the above two invariants.
+ key length SHOULD be >= hash length / 2. This is because
the subkey derivation is via an HMAC and it is recommended
that if the HMAC has to be truncated, it should not be
truncated to less than half the hash length (see Section 4
of RFC2104 [11]).
* Number of concurrent versions of the SSV the client and server * Number of concurrent versions of the SSV the client and server
will support (Section 2.10.9). This property is represented by will support (Section 2.10.9). This property is represented by
spi_window, in the EXCHANGE_ID results. The property may be spi_window, in the EXCHANGE_ID results. The property may be
updated by subsequent EXCHANGE_ID requests. updated by subsequent EXCHANGE_ID requests.
o The client's implementation ID as represented by the o The client's implementation ID as represented by the
eia_client_impl_id field of the arguments. The property may be eia_client_impl_id field of the arguments. The property may be
updated by subsequent EXCHANGE_ID requests. updated by subsequent EXCHANGE_ID requests.
skipping to change at page 497, line 35 skipping to change at page 499, line 14
each role/client ID. each role/client ID.
The spa_how field of the eia_state_protect field specifies how the The spa_how field of the eia_state_protect field specifies how the
client wants to protect its client, locking and session state from client wants to protect its client, locking and session state from
unauthorized changes (Section 2.10.8.3): unauthorized changes (Section 2.10.8.3):
o SP4_NONE. The client does not request the NFSv4.1 server to o SP4_NONE. The client does not request the NFSv4.1 server to
enforce state protection. The NFSv4.1 server MUST NOT enforce enforce state protection. The NFSv4.1 server MUST NOT enforce
state protection for the returned client ID. state protection for the returned client ID.
o SP4_MACH_CRED. This choice is only valid if the client sent the o SP4_MACH_CRED. If spa_how is SP4_MACH_CRED, then the client MUST
request with RPCSEC_GSS as the security flavor, and with a service send the EXCHANGE_ID request with RPCSEC_GSS as the security
of RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY. The client wants flavor, and with a service of RPC_GSS_SVC_INTEGRITY or
to use an RPCSEC_GSS-based machine credential to protect its RPC_GSS_SVC_PRIVACY. If SP4_MACH_CRED is specified, then the
state. The server MUST note the principal the EXCHANGE_ID client wants to use an RPCSEC_GSS-based machine credential to
operation was sent with, and the GSS mechanism used. These notes protect its state. The server MUST note the principal the
collectively comprise the machine credential. EXCHANGE_ID operation was sent with, and the GSS mechanism used.
These notes collectively comprise the machine credential.
After the client ID is confirmed, as long as the lease associated After the client ID is confirmed, as long as the lease associated
with the client ID is unexpired, a subsequent EXCHANGE_ID with the client ID is unexpired, a subsequent EXCHANGE_ID
operation that uses the same eia_clientowner.co_owner as the first operation that uses the same eia_clientowner.co_owner as the first
EXCHANGE_ID, MUST also use the same machine credential as the EXCHANGE_ID, MUST also use the same machine credential as the
first EXCHANGE_ID. The server returns the same client ID for the first EXCHANGE_ID. The server returns the same client ID for the
subsequent EXCHANGE_ID as that returned from the first subsequent EXCHANGE_ID as that returned from the first
EXCHANGE_ID. EXCHANGE_ID.
o SP4_SSV. This choice is only valid if the client sent the request o SP4_SSV. If spa_how is SP4_SSV, then the client MUST send the
with RPCSEC_GSS as the security flavor, and with a service of EXCHANGE_ID request with RPCSEC_GSS as the security flavor, and
RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY. This choice with a service of RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY.
indicates the client wants to use the SSV to protect state. The If SP4_SSV is specified, then the client wants to use the SSV to
server records the credential used in the request as the machine protect its state. The server records the credential used in the
credential (as defined above) for the eia_clientowner.co_owner. request as the machine credential (as defined above) for the
The CREATE_SESSION operation that confirms the client ID MUST use eia_clientowner.co_owner. The CREATE_SESSION operation that
the same machine credential. confirms the client ID MUST use the same machine credential.
When a client specifies SP4_MACH_CRED or SP4_SSV, it also provides When a client specifies SP4_MACH_CRED or SP4_SSV, it also provides
two lists of operations (each expressed as a bit map). The first two lists of operations (each expressed as a bit map). The first
list is spo_must_enforce and consists of those operations the client list is spo_must_enforce and consists of those operations the client
MUST send (subject to the server confirming the list of operations in MUST send (subject to the server confirming the list of operations in
the result of EXCHANGE_ID) with the machine credential (if the result of EXCHANGE_ID) with the machine credential (if
SP4_MACH_CRED protection is specified) or the SSV-based credential SP4_MACH_CRED protection is specified) or the SSV-based credential
(if SP4_SSV protection is used). The client MUST send the operations (if SP4_SSV protection is used). The client MUST send the operations
with RPCSEC_GSS credentials that specify the RPC_GSS_SVC_INTEGRITY or with RPCSEC_GSS credentials that specify the RPC_GSS_SVC_INTEGRITY or
RPC_GSS_SVC_PRIVACY security service. Typically the first list of RPC_GSS_SVC_PRIVACY security service. Typically the first list of
skipping to change at page 499, line 51 skipping to change at page 501, line 31
ssp_encr_algs: ssp_encr_algs:
This is the set of algorithms the client supports for the purpose This is the set of algorithms the client supports for the purpose
of providing privacy protection for the internal SSV GSS of providing privacy protection for the internal SSV GSS
mechanism. Each algorithm is specified as an OID. The REQUIRED mechanism. Each algorithm is specified as an OID. The REQUIRED
algorithm for a server is id-aes256-CBC. The RECOMMENDED algorithm for a server is id-aes256-CBC. The RECOMMENDED
algorithms are id-aes192-CBC and id-aes128-CBC [28]. The selected algorithms are id-aes192-CBC and id-aes128-CBC [28]. The selected
algorithm is returned in spi_encr_alg, an index into algorithm is returned in spi_encr_alg, an index into
ssp_encr_algs. If the server does not support any of the offered ssp_encr_algs. If the server does not support any of the offered
algorithms, it returns NFS4ERR_ENCR_ALG_UNSUPP. If ssp_encr_algs algorithms, it returns NFS4ERR_ENCR_ALG_UNSUPP. If ssp_encr_algs
is empty, the server MUST return NFS4ERR_INVAL. is empty, the server MUST return NFS4ERR_INVAL. Note that due to
previously stated requirements and recommendations on the
relationships between key length and hash length, some
combinations of RECOMMENDED and REQUIRED encryption algorithm and
hash algorithm either SHOULD NOT or MUST NOT be used. Table 12
summarizes the illegal and discouraged combinations.
ssp_window: ssp_window:
This is the number of SSV versions the client wants the server to This is the number of SSV versions the client wants the server to
maintain (i.e. each successful call to SET_SSV produces a new maintain (i.e. each successful call to SET_SSV produces a new
version of the SSV). If ssp_window is zero, the server MUST version of the SSV). If ssp_window is zero, the server MUST
return NFS4ERR_INVAL. The server responds with spi_window, which return NFS4ERR_INVAL. The server responds with spi_window, which
MUST NOT exceed ssp_window, and MUST be at least one (1). Any MUST NOT exceed ssp_window, and MUST be at least one (1). Any
requests on the backchannel or fore channel that are using a requests on the backchannel or fore channel that are using a
version of the SSV that is outside the window will fail with an version of the SSV that is outside the window will fail with an
skipping to change at page 500, line 38 skipping to change at page 502, line 26
EXCHGID4_FLAG_CONFIRMED_R, or upon successful confirmation from EXCHGID4_FLAG_CONFIRMED_R, or upon successful confirmation from
CREATE_SESSION. While a client ID can span all the connections CREATE_SESSION. While a client ID can span all the connections
that are connected to a server sharing the same that are connected to a server sharing the same
eir_server_owner.so_major_id, the RPCSEC_GSS handles returned in eir_server_owner.so_major_id, the RPCSEC_GSS handles returned in
spi_handles can only be used on connections connected to a server spi_handles can only be used on connections connected to a server
that returns the same the eir_server_owner.so_major_id and that returns the same the eir_server_owner.so_major_id and
eir_server_owner.so_minor_id on each connection. It is eir_server_owner.so_minor_id on each connection. It is
permissible for the client to set ssp_num_gss_handles to zero (0); permissible for the client to set ssp_num_gss_handles to zero (0);
the client can create more handles with another EXCHANGE_ID call. the client can create more handles with another EXCHANGE_ID call.
The seq_window (see Section 5.2.3.1 of RFC2203 [4]) of each
RPCSEC_GSS handle in spi_handle MUST be the same as the seq_window
of the RPCSEC_GSS handle used for the credential of the RPC
request that the EXCHANGE_ID request was sent with.
+-------------------+----------------------+------------------------+
| Encryption | MUST NOT be combined | SHOULD NOT be combined |
| Algorithm | with | with |
+-------------------+----------------------+------------------------+
| id-aes128-CBC | | id-sha384, id-sha512 |
| id-aes192-CBC | id-sha1 | id-sha512 |
| id-aes256-CBC | id-sha1, id-sha224 | |
+-------------------+----------------------+------------------------+
Table 12
The arguments include an array of up to one element in length called The arguments include an array of up to one element in length called
eia_client_impl_id. If eia_client_impl_id is present it contains the eia_client_impl_id. If eia_client_impl_id is present it contains the
information identifying the implementation of the client. Similarly, information identifying the implementation of the client. Similarly,
the results include an array of up to one element in length called the results include an array of up to one element in length called
eir_server_impl_id that identifies the implementation of the server. eir_server_impl_id that identifies the implementation of the server.
Servers MUST accept a zero length eia_client_impl_id array, and Servers MUST accept a zero length eia_client_impl_id array, and
clients MUST accept a zero length eir_server_impl_id array. clients MUST accept a zero length eir_server_impl_id array.
An example use for implementation identifiers would be diagnostic An example use for implementation identifiers would be diagnostic
software that extract this information in an attempt to identify software that extract this information in an attempt to identify
skipping to change at page 512, line 18 skipping to change at page 514, line 18
requester within the range 0 to ca_maxrequests - 1 inclusive. requester within the range 0 to ca_maxrequests - 1 inclusive.
ca_rdma_ird: ca_rdma_ird:
This array has a maximum of one element. If this array has one This array has a maximum of one element. If this array has one
element, then the element contains the inbound RDMA read queue element, then the element contains the inbound RDMA read queue
depth (IRD). depth (IRD).
csa_cb_program csa_cb_program
This is the ONC RPC program number the server must use in any This is the ONC RPC program number the server MUST use in any
callbacks sent through the backchannel to the client. The server callbacks sent through the backchannel to the client. The server
MUST specify an ONC RPC program number equal to csa_cb_program and MUST specify an ONC RPC program number equal to csa_cb_program and
an ONC RPC version number equal to 4 in callbacks sent to the an ONC RPC version number equal to 4 in callbacks sent to the
client. If a CB_COMPOUND is sent to the client, the server MUST client. If a CB_COMPOUND is sent to the client, the server MUST
use a minor version number of 1. There is no corresponding use a minor version number of 1. There is no corresponding
result. result.
csa_sec_parms csa_sec_parms
The field csa_sec_parms is an array of acceptable security The field csa_sec_parms is an array of acceptable security
skipping to change at page 513, line 21 skipping to change at page 515, line 20
Security Protocol" of [4]) in callback RPCs. The server MUST use Security Protocol" of [4]) in callback RPCs. The server MUST use
the RPCSEC_GSS security service specified in gcbp_service, i.e. it the RPCSEC_GSS security service specified in gcbp_service, i.e. it
MUST set the "service" field of the rpc_gss_cred_t data type in MUST set the "service" field of the rpc_gss_cred_t data type in
RPCSEC_GSS credential to the value of gcbp_service (see Section RPCSEC_GSS credential to the value of gcbp_service (see Section
5.3.1, "RPC Request Header", of [4]). 5.3.1, "RPC Request Header", of [4]).
If the RPCSEC_GSS handle identified by gcbp_handle_from_server If the RPCSEC_GSS handle identified by gcbp_handle_from_server
does not exist on the server, the server will return does not exist on the server, the server will return
NFS4ERR_NOENT. NFS4ERR_NOENT.
Note that while the GSS context state is shared between the fore Within each element of csa_sec_parms, the fore and back RPCSEC_GSS
and back RPCSEC_GSS contexts, the fore and back RPCSEC_GSS context contexts MUST share the same GSS context and MUST have the same
state are independent of each other as far as the RPCSEC_GSS seq_window (see Section 5.2.3.1 of RFC2203 [4]). The fore and
sequence number (see the seq_num field in the rpc_gss_cred_t data back RPCSEC_GSS context state are independent of each other as far
type of Section 5 and of Section 5.3.1, "RPC Request Header", of as the RPCSEC_GSS sequence number (see the seq_num field in the
[4]). rpc_gss_cred_t data type of Section 5 and of Section 5.3.1, "RPC
Request Header", of RFC2203).
Once the session is created, the first SEQUENCE or CB_SEQUENCE Once the session is created, the first SEQUENCE or CB_SEQUENCE
received on a slot MUST have a sequence ID equal to 1; if not the received on a slot MUST have a sequence ID equal to 1; if not the
server MUST return NFS4ERR_SEQ_MISORDERED. server MUST return NFS4ERR_SEQ_MISORDERED.
18.36.4. IMPLEMENTATION 18.36.4. IMPLEMENTATION
To describe a possible implementation, the same notation for client To describe a possible implementation, the same notation for client
records introduced in the description of EXCHANGE_ID is used with the records introduced in the description of EXCHANGE_ID is used with the
following addition: following addition:
clientid_arg: The value of the csa_clientid field of the clientid_arg: The value of the csa_clientid field of the
CREATE_SESSION4args structure of the current request. CREATE_SESSION4args structure of the current request.
Since CREATE_SESSION is a non-idempotent operation, we must consider Since CREATE_SESSION is a non-idempotent operation, we need to
the possibility that retries may occur as a result of a client consider the possibility that retries may occur as a result of a
restart, network partition, malfunctioning router, etc. For each client restart, network partition, malfunctioning router, etc. For
client ID created by EXCHANGE_ID, the server maintains a separate each client ID created by EXCHANGE_ID, the server maintains a
reply cache (called the CREATE_SESSION reply cache) similar to the separate reply cache (called the CREATE_SESSION reply cache) similar
session reply cache used for SEQUENCE operations, with two to the session reply cache used for SEQUENCE operations, with two
distinctions. distinctions.
o First this is a reply cache just for detecting and processing o First this is a reply cache just for detecting and processing
CREATE_SESSION requests for a given client ID. CREATE_SESSION requests for a given client ID.
o Second, the size of the client ID reply cache is of one slot (and o Second, the size of the client ID reply cache is of one slot (and
as a result, the CREATE_SESSION request does not carry a slot as a result, the CREATE_SESSION request does not carry a slot
number). This means that at most one CREATE_SESSION request for a number). This means that at most one CREATE_SESSION request for a
given client ID can be outstanding. given client ID can be outstanding.
skipping to change at page 516, line 28 skipping to change at page 518, line 28
set and has been accepted by the server) and allocating space for set and has been accepted by the server) and allocating space for
the session reply cache (if there is not enough space, the server the session reply cache (if there is not enough space, the server
returns NFS4ERR_NOSPC). For each slot in the reply cache, the returns NFS4ERR_NOSPC). For each slot in the reply cache, the
server sets the sequence ID to zero (0), and records an entry server sets the sequence ID to zero (0), and records an entry
containing a COMPOUND reply with zero operations and the error containing a COMPOUND reply with zero operations and the error
NFS4ERR_SEQ_MISORDERED. This way, if the first SEQUENCE request NFS4ERR_SEQ_MISORDERED. This way, if the first SEQUENCE request
sent has a sequence ID equal to zero, the server can simply sent has a sequence ID equal to zero, the server can simply
return what is in the reply cache: NFS4ERR_SEQ_MISORDERED. The return what is in the reply cache: NFS4ERR_SEQ_MISORDERED. The
client initializes its reply cache for receiving callbacks in the client initializes its reply cache for receiving callbacks in the
same way, and similarly, the first CB_SEQUENCE operation on a same way, and similarly, the first CB_SEQUENCE operation on a
slot after session creation must have a sequence ID of one. slot after session creation MUST have a sequence ID of one.
6. If the session state is created successfully, the server 6. If the session state is created successfully, the server
associates the session with the client ID provided by the client. associates the session with the client ID provided by the client.
7. When a request that had CREATE_SESSION4_FLAG_CONN_RDMA set needs 7. When a request that had CREATE_SESSION4_FLAG_CONN_RDMA set needs
to be retried, the retry MUST be done on a new connection that is to be retried, the retry MUST be done on a new connection that is
in non-RDMA mode. If properties of the new connection are in non-RDMA mode. If properties of the new connection are
different enough that the arguments to CREATE_SESSION must different enough that the arguments to CREATE_SESSION need to
change, then a non-retry MUST be sent. The server will change, then a non-retry MUST be sent. The server will
eventually dispose of any session that was created on the eventually dispose of any session that was created on the
original connection. original connection.
On the backchannel, the client and server might wish to have many On the backchannel, the client and server might wish to have many
slots, in some cases perhaps more that the fore channel, in to deal slots, in some cases perhaps more that the fore channel, in to deal
with the situations where the network link has high latency and is with the situations where the network link has high latency and is
the primary bottleneck for response to recalls. If so, and if the the primary bottleneck for response to recalls. If so, and if the
client provides too few slots to the backchannel, the server might client provides too few slots to the backchannel, the server might
limit the number of recallable objects it gives to the server. limit the number of recallable objects it gives to the server.
skipping to change at page 532, line 49 skipping to change at page 534, line 49
o If the sum of loga_offset and loga_minlength exceeds o If the sum of loga_offset and loga_minlength exceeds
NFS4_UINT64_MAX, and loga_minlength is not NFS4_UINT64_MAX, the NFS4_UINT64_MAX, and loga_minlength is not NFS4_UINT64_MAX, the
error NFS4ERR_INVAL MUST result. error NFS4ERR_INVAL MUST result.
o If the sum of loga_offset and loga_length exceeds NFS4_UINT64_MAX, o If the sum of loga_offset and loga_length exceeds NFS4_UINT64_MAX,
and loga_length is not NFS4_UINT64_MAX, the error NFS4ERR_INVAL and loga_length is not NFS4_UINT64_MAX, the error NFS4ERR_INVAL
MUST result. MUST result.
After the metadata server has performed the above checks on After the metadata server has performed the above checks on
loga_offset, loga_minlength, and loga_offset, the metadata server loga_offset, loga_minlength, and loga_offset, the metadata server
MUST return a layout according to the rules in Table 12. MUST return a layout according to the rules in Table 13.
Acceptable layouts based on loga_minlength. Note: u64m = Acceptable layouts based on loga_minlength. Note: u64m =
NFS4_UINT64_MAX; a_off = loga_offset; a_minlen = loga_minlength. NFS4_UINT64_MAX; a_off = loga_offset; a_minlen = loga_minlength.
+-----------+-----------+----------+----------+---------------------+ +-----------+-----------+----------+----------+---------------------+
| Layout | Layout | Layout | Layout | Layout length of | | Layout | Layout | Layout | Layout | Layout length of |
| iomode of | a_minlen | iomode | offset | reply | | iomode of | a_minlen | iomode | offset | reply |
| request | of | of reply | of reply | | | request | of | of reply | of reply | |
| | request | | | | | | request | | | |
+-----------+-----------+----------+----------+---------------------+ +-----------+-----------+----------+----------+---------------------+
skipping to change at page 533, line 39 skipping to change at page 535, line 39
| | | _RW | <= a_off | | | | | _RW | <= a_off | |
| _RW | u64m | MUST be | MUST be | MUST be u64m | | _RW | u64m | MUST be | MUST be | MUST be u64m |
| | | _RW | <= a_off | | | | | _RW | <= a_off | |
| _RW | > 0 and < | MUST be | MUST be | MUST be >= a_off - | | _RW | > 0 and < | MUST be | MUST be | MUST be >= a_off - |
| | u64m | _RW | <= a_off | layout offset + | | | u64m | _RW | <= a_off | layout offset + |
| | | | | a_minlen | | | | | | a_minlen |
| _RW | 0 | MUST be | MUST be | MUST be > 0 | | _RW | 0 | MUST be | MUST be | MUST be > 0 |
| | | _RW | <= a_off | | | | | _RW | <= a_off | |
+-----------+-----------+----------+----------+---------------------+ +-----------+-----------+----------+----------+---------------------+
Table 12 Table 13
If loga_minlength is not zero and the metadata server cannot return a If loga_minlength is not zero and the metadata server cannot return a
layout according to the rules in Table 12, then the metadata server layout according to the rules in Table 13, then the metadata server
MUST return the error NFS4ERR_BADLAYOUT. If loga_minlength is zero MUST return the error NFS4ERR_BADLAYOUT. If loga_minlength is zero
and the metadata server cannot or will not return a layout according and the metadata server cannot or will not return a layout according
to the rules in Table 12, then the metadata server MUST return the to the rules in Table 13, then the metadata server MUST return the
error NFS4ERR_LAYOUTTRYLATER. Assuming loga_length is greater than error NFS4ERR_LAYOUTTRYLATER. Assuming loga_length is greater than
loga_minlength or equal to zero, the metadata server SHOULD return a loga_minlength or equal to zero, the metadata server SHOULD return a
layout according to the rules in Table 13. layout according to the rules in Table 14.
Desired layouts based on loga_length. The rules of Table 12 MUST be Desired layouts based on loga_length. The rules of Table 13 MUST be
applied first. Note: u64m = NFS4_UINT64_MAX; a_off = loga_offset; applied first. Note: u64m = NFS4_UINT64_MAX; a_off = loga_offset;
a_len = loga_length. a_len = loga_length.
+------------+------------+-----------+-----------+-----------------+ +------------+------------+-----------+-----------+-----------------+
| Layout | Layout | Layout | Layout | Layout length | | Layout | Layout | Layout | Layout | Layout length |
| iomode of | a_len of | iomode of | offset of | of reply | | iomode of | a_len of | iomode of | offset of | of reply |
| request | request | reply | reply | | | request | request | reply | reply | |
+------------+------------+-----------+-----------+-----------------+ +------------+------------+-----------+-----------+-----------------+
| _READ | u64m | MAY be | MUST be | SHOULD be u64m | | _READ | u64m | MAY be | MUST be | SHOULD be u64m |
| | | _READ | <= a_off | | | | | _READ | <= a_off | |
skipping to change at page 534, line 40 skipping to change at page 536, line 40
| _RW | u64m | MUST be | MUST be | SHOULD be u64m | | _RW | u64m | MUST be | MUST be | SHOULD be u64m |
| | | _RW | <= a_off | | | | | _RW | <= a_off | |
| _RW | > 0 and < | MUST be | MUST be | SHOULD be >= | | _RW | > 0 and < | MUST be | MUST be | SHOULD be >= |
| | u64m | _RW | <= a_off | a_off - layout | | | u64m | _RW | <= a_off | a_off - layout |
| | | | | offset + a_len | | | | | | offset + a_len |
| _RW | 0 | MUST be | MUST be | SHOULD be > | | _RW | 0 | MUST be | MUST be | SHOULD be > |
| | | _RW | <= a_off | a_off - layout | | | | _RW | <= a_off | a_off - layout |
| | | | | offset | | | | | | offset |
+------------+------------+-----------+-----------+-----------------+ +------------+------------+-----------+-----------+-----------------+
Table 13 Table 14
The loga_stateid field specifies a valid stateid. If a layout is not The loga_stateid field specifies a valid stateid. If a layout is not
currently held by the client, the loga_stateid field represents a currently held by the client, the loga_stateid field represents a
stateid reflecting the correspondingly valid open, byte-range lock, stateid reflecting the correspondingly valid open, byte-range lock,
or delegation stateid. Once a layout is held on the file by the or delegation stateid. Once a layout is held on the file by the
client, the loga_stateid field MUST be a stateid as returned from a client, the loga_stateid field MUST be a stateid as returned from a
previous LAYOUTGET or LAYOUTRETURN operation or provided by a previous LAYOUTGET or LAYOUTRETURN operation or provided by a
CB_LAYOUTRECALL operation (see Section 12.5.3). CB_LAYOUTRECALL operation (see Section 12.5.3).
The loga_maxcount field specifies the maximum layout size (in bytes) The loga_maxcount field specifies the maximum layout size (in bytes)
skipping to change at page 535, line 16 skipping to change at page 537, line 16
The returned layout is expressed as an array, logr_layout, with each The returned layout is expressed as an array, logr_layout, with each
element of type layout4. If a file has a single striping pattern, element of type layout4. If a file has a single striping pattern,
then logr_layout SHOULD contain just one entry. Otherwise, if the then logr_layout SHOULD contain just one entry. Otherwise, if the
requested range overlaps more than one striping pattern, logr_layout requested range overlaps more than one striping pattern, logr_layout
will contain the required number of entries. The elements of will contain the required number of entries. The elements of
logr_layout MUST be sorted in ascending order of the value of the logr_layout MUST be sorted in ascending order of the value of the
lo_offset field of each element. There MUST be no gaps or overlaps lo_offset field of each element. There MUST be no gaps or overlaps
in the range between two successive elements of logr_layout. The in the range between two successive elements of logr_layout. The
lo_iomode field in each element of logr_layout MUST be the same. lo_iomode field in each element of logr_layout MUST be the same.
Table 12 and Table 13 both refer to a returned layout iomode, offset, Table 13 and Table 14 both refer to a returned layout iomode, offset,
and length. Because the returned layout is encoded in the and length. Because the returned layout is encoded in the
logr_layout array, more description is required. logr_layout array, more description is required.
iomode iomode
The value of the returned layout iomode listed in Table 12 and The value of the returned layout iomode listed in Table 13 and
Table 13 is equal to the value of the lo_iomode field in each Table 14 is equal to the value of the lo_iomode field in each
element of logr_layout. As shown in Table 12 and Table 13, the element of logr_layout. As shown in Table 13 and Table 14, the
metadata server MAY return a layout with an lo_iomode different metadata server MAY return a layout with an lo_iomode different
from the requested iomode (field loga_iomode of the request). If from the requested iomode (field loga_iomode of the request). If
it does so, it MUST ensure that the lo_iomode is more permissive it does so, it MUST ensure that the lo_iomode is more permissive
than the loga_iomode requested. For example, this behavior allows than the loga_iomode requested. For example, this behavior allows
an implementation to upgrade read-only requests to read/write an implementation to upgrade read-only requests to read/write
requests at its discretion, within the limits of the layout type requests at its discretion, within the limits of the layout type
specific protocol. A lo_iomode of either LAYOUTIOMODE4_READ or specific protocol. A lo_iomode of either LAYOUTIOMODE4_READ or
LAYOUTIOMODE4_RW MUST be returned. LAYOUTIOMODE4_RW MUST be returned.
offset offset
The value of the returned layout offset listed in Table 12 and The value of the returned layout offset listed in Table 13 and
Table 13 is always equal to the lo_offset field of the first Table 14 is always equal to the lo_offset field of the first
element logr_layout. element logr_layout.
length length
When setting the value of the returned layout length, the When setting the value of the returned layout length, the
situation is complicated by the possibility that the special situation is complicated by the possibility that the special
layout length value NFS4_UINT64_MAX is involved. For a layout length value NFS4_UINT64_MAX is involved. For a
logr_layout array of N elements, the lo_length field in the first logr_layout array of N elements, the lo_length field in the first
N-1 elements MUST NOT be NFS4_UINT64_MAX. The lo_length field of N-1 elements MUST NOT be NFS4_UINT64_MAX. The lo_length field of
the last element of logr_layout can be NFS4_UINT64_MAX under some the last element of logr_layout can be NFS4_UINT64_MAX under some
conditions as described in the following list. conditions as described in the following list.
* If an applicable rule of Table 12 states the metadata server * If an applicable rule of Table 13 states the metadata server
MUST return a layout of length NFS4_UINT64_MAX, then lo_length MUST return a layout of length NFS4_UINT64_MAX, then lo_length
field of the last element of logr_layout MUST be field of the last element of logr_layout MUST be
NFS4_UINT64_MAX. NFS4_UINT64_MAX.
* If an applicable rule of Table 12 states the metadata server * If an applicable rule of Table 13 states the metadata server
MUST NOT return a layout of length NFS4_UINT64_MAX, then MUST NOT return a layout of length NFS4_UINT64_MAX, then
lo_length field of the last element of logr_layout MUST NOT be lo_length field of the last element of logr_layout MUST NOT be
NFS4_UINT64_MAX. NFS4_UINT64_MAX.
* If an applicable rule of Table 13 states the metadata server * If an applicable rule of Table 14 states the metadata server
SHOULD return a layout of length NFS4_UINT64_MAX, then SHOULD return a layout of length NFS4_UINT64_MAX, then
lo_length field of the last element of logr_layout SHOULD be lo_length field of the last element of logr_layout SHOULD be
NFS4_UINT64_MAX. NFS4_UINT64_MAX.
* When the value of the returned layout length of Table 12 and * When the value of the returned layout length of Table 13 and
Table 13 is not NFS4_UINT64_MAX, then the returned layout Table 14 is not NFS4_UINT64_MAX, then the returned layout
length is equal to the sum of the lo_length fields of each length is equal to the sum of the lo_length fields of each
element of logr_layout. element of logr_layout.
The logr_return_on_close result field is a directive to return the The logr_return_on_close result field is a directive to return the
layout before closing the file. When the metadata server sets this layout before closing the file. When the metadata server sets this
return value to TRUE, it MUST be prepared to recall the layout in the return value to TRUE, it MUST be prepared to recall the layout in the
case the client fails to return the layout before close. For the case the client fails to return the layout before close. For the
metadata server that knows a layout must be returned before a close metadata server that knows a layout must be returned before a close
of the file, this return value can be used to communicate the desired of the file, this return value can be used to communicate the desired
behavior to the client and thus remove one extra step from the behavior to the client and thus remove one extra step from the
skipping to change at page 537, line 43 skipping to change at page 539, line 43
Typically, LAYOUTGET will be called as part of a COMPOUND request Typically, LAYOUTGET will be called as part of a COMPOUND request
after an OPEN operation and results in the client having location after an OPEN operation and results in the client having location
information for the file; this requires that loga_stateid be set to information for the file; this requires that loga_stateid be set to
the special stateid that tells the metadata server to use the current the special stateid that tells the metadata server to use the current
stateid, which is set by OPEN (see Section 16.2.3.1.2) . A client stateid, which is set by OPEN (see Section 16.2.3.1.2) . A client
may also hold a layout across multiple OPENs. The client specifies a may also hold a layout across multiple OPENs. The client specifies a
layout type that limits what kind of layout the metadata server will layout type that limits what kind of layout the metadata server will
return. This prevents metadata servers from granting layouts that return. This prevents metadata servers from granting layouts that
are unusable by the client. are unusable by the client.
As indicated by Table 12 and Table 13 the specification of LAYOUTGET As indicated by Table 13 and Table 14 the specification of LAYOUTGET
allows a pNFS client and server considerable flexibility. A pNFS allows a pNFS client and server considerable flexibility. A pNFS
client can take several strategies for sending LAYOUTGET. Some client can take several strategies for sending LAYOUTGET. Some
examples are as follows. examples are as follows.
o If LAYOUTGET is preceded by OPEN in the same COMPOUND request, and o If LAYOUTGET is preceded by OPEN in the same COMPOUND request, and
the OPEN requests read access, the client might opt to request a the OPEN requests read access, the client might opt to request a
_READ layout with loga_offset set to zero, loga_minlength set to _READ layout with loga_offset set to zero, loga_minlength set to
zero, and loga_length set to NFS4_UINT64_MAX. If the file has zero, and loga_length set to NFS4_UINT64_MAX. If the file has
space allocated to it, that space is striped over one or more space allocated to it, that space is striped over one or more
storage devices, and there is either no conflicting layout, or the storage devices, and there is either no conflicting layout, or the
skipping to change at page 566, line 27 skipping to change at page 568, line 27
During the processing of the CB_COMPOUND procedure, the client may During the processing of the CB_COMPOUND procedure, the client may
find that it does not have the available resources to execute any or find that it does not have the available resources to execute any or
all of the operations within the CB_COMPOUND sequence. Refer to all of the operations within the CB_COMPOUND sequence. Refer to
Section 2.10.6.4 for details. Section 2.10.6.4 for details.
The minorversion field of the arguments MUST be the same as the The minorversion field of the arguments MUST be the same as the
minorversion of the COMPOUND procedure used to created the client ID minorversion of the COMPOUND procedure used to created the client ID
and session. For NFSv4.1, minorversion MUST be set to 1. and session. For NFSv4.1, minorversion MUST be set to 1.
Contained within the CB_COMPOUND results is a 'status' field. This Contained within the CB_COMPOUND results is a 'status' field. This
status must be equivalent to the status of the last operation that status MUST be equal to the status of the last operation that was
was executed within the CB_COMPOUND procedure. Therefore, if an executed within the CB_COMPOUND procedure. Therefore, if an
operation incurred an error then the 'status' value will be the same operation incurred an error then the 'status' value will be the same
error value as is being returned for the operation that failed. error value as is being returned for the operation that failed.
The "tag" field is handled the same way as that of COMPOUND procedure The "tag" field is handled the same way as that of COMPOUND procedure
(see Section 16.2.3). (see Section 16.2.3).
Illegal operation codes are handled in the same way as they are Illegal operation codes are handled in the same way as they are
handled for the COMPOUND procedure. handled for the COMPOUND procedure.
19.2.4. IMPLEMENTATION 19.2.4. IMPLEMENTATION
skipping to change at page 567, line 28 skipping to change at page 569, line 28
| NFS4ERR_INVAL | The tag argument is not in UTF-8 | | NFS4ERR_INVAL | The tag argument is not in UTF-8 |
| | encoding. | | | encoding. |
| NFS4ERR_MINOR_VERS_MISMATCH | | | NFS4ERR_MINOR_VERS_MISMATCH | |
| NFS4ERR_SERVERFAULT | | | NFS4ERR_SERVERFAULT | |
| NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_TOO_MANY_OPS | |
| NFS4ERR_REP_TOO_BIG | | | NFS4ERR_REP_TOO_BIG | |
| NFS4ERR_REP_TOO_BIG_TO_CACHE | | | NFS4ERR_REP_TOO_BIG_TO_CACHE | |
| NFS4ERR_REQ_TOO_BIG | | | NFS4ERR_REQ_TOO_BIG | |
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
Table 14 Table 15
20. NFSv4.1 Callback Operations 20. NFSv4.1 Callback Operations
20.1. Operation 3: CB_GETATTR - Get Attributes 20.1. Operation 3: CB_GETATTR - Get Attributes
20.1.1. ARGUMENT 20.1.1. ARGUMENT
struct CB_GETATTR4args { struct CB_GETATTR4args {
nfs_fh4 fh; nfs_fh4 fh;
bitmap4 attr_request; bitmap4 attr_request;
skipping to change at page 594, line 30 skipping to change at page 596, line 30
5. The minor versions of NFSv4 that are allowed to the use the 5. The minor versions of NFSv4 that are allowed to the use the
notification. While these are numeric values, IANA will not notification. While these are numeric values, IANA will not
allocate and assign them; the author of the relevant RFCs with allocate and assign them; the author of the relevant RFCs with
IESG Approval assigns these numbers. Each time there is new IESG Approval assigns these numbers. Each time there is new
minor version of NFSv4 approved, a Designated Expert should minor version of NFSv4 approved, a Designated Expert should
review the registry to make recommended updates as needed. review the registry to make recommended updates as needed.
22.2.1. Initial Registry 22.2.1. Initial Registry
The initial registry is in Table 15. Note that next available value The initial registry is in Table 16. Note that next available value
is zero. is zero.
+-------------------------+-------+----------+-----+----------------+ +-------------------------+-------+----------+-----+----------------+
| Notification Name | Value | RFC | How | Minor Versions | | Notification Name | Value | RFC | How | Minor Versions |
+-------------------------+-------+----------+-----+----------------+ +-------------------------+-------+----------+-----+----------------+
| NOTIFY_DEVICEID4_CHANGE | 1 | RFCTBD10 | N | 1 | | NOTIFY_DEVICEID4_CHANGE | 1 | RFCTBD10 | N | 1 |
| NOTIFY_DEVICEID4_DELETE | 2 | RFCTBD10 | N | 1 | | NOTIFY_DEVICEID4_DELETE | 2 | RFCTBD10 | N | 1 |
+-------------------------+-------+----------+-----+----------------+ +-------------------------+-------+----------+-----+----------------+
Table 15: Initial Device ID Notification Assignments Table 16: Initial Device ID Notification Assignments
22.2.2. Updating Registrations 22.2.2. Updating Registrations
The update of a registration will require IESG Approval on the advice The update of a registration will require IESG Approval on the advice
of a Designated Expert. of a Designated Expert.
22.3. Object Recall Types 22.3. Object Recall Types
IANA will create a registry called the "NFSv4.1 Recallable Object IANA will create a registry called the "NFSv4.1 Recallable Object
Types Registry". Types Registry".
skipping to change at page 596, line 7 skipping to change at page 598, line 7
5. The minor versions of NFSv4 that are allowed to the use the 5. The minor versions of NFSv4 that are allowed to the use the
recallable object type. While these are numeric values, IANA recallable object type. While these are numeric values, IANA
will not allocate and assign them; the author of the relevant will not allocate and assign them; the author of the relevant
RFCs with IESG Approval assigns these numbers. Each time there RFCs with IESG Approval assigns these numbers. Each time there
is new minor version of NFSv4 approved, a Designated Expert is new minor version of NFSv4 approved, a Designated Expert
should review the registry to make recommended updates as needed. should review the registry to make recommended updates as needed.
22.3.1. Initial Registry 22.3.1. Initial Registry
The initial registry is in Table 16. Note that next available value The initial registry is in Table 17. Note that next available value
is five. is five.
+-------------------------------+-------+----------+-----+----------+ +-------------------------------+-------+----------+-----+----------+
| Recallable Object Type Name | Value | RFC | How | Minor | | Recallable Object Type Name | Value | RFC | How | Minor |
| | | | | Versions | | | | | | Versions |
+-------------------------------+-------+----------+-----+----------+ +-------------------------------+-------+----------+-----+----------+
| RCA4_TYPE_MASK_RDATA_DLG | 0 | RFCTBD10 | N | 1 | | RCA4_TYPE_MASK_RDATA_DLG | 0 | RFCTBD10 | N | 1 |
| RCA4_TYPE_MASK_WDATA_DLG | 1 | RFCTBD10 | N | 1 | | RCA4_TYPE_MASK_WDATA_DLG | 1 | RFCTBD10 | N | 1 |
| RCA4_TYPE_MASK_DIR_DLG | 2 | RFCTBD10 | N | 1 | | RCA4_TYPE_MASK_DIR_DLG | 2 | RFCTBD10 | N | 1 |
| RCA4_TYPE_MASK_FILE_LAYOUT | 3 | RFCTBD10 | N | 1 | | RCA4_TYPE_MASK_FILE_LAYOUT | 3 | RFCTBD10 | N | 1 |
| RCA4_TYPE_MASK_BLK_LAYOUT | 4 | RFCTBD20 | L | 1 | | RCA4_TYPE_MASK_BLK_LAYOUT | 4 | RFCTBD20 | L | 1 |
| RCA4_TYPE_MASK_OBJ_LAYOUT_MIN | 8 | RFCTBD30 | L | 1 | | RCA4_TYPE_MASK_OBJ_LAYOUT_MIN | 8 | RFCTBD30 | L | 1 |
| RCA4_TYPE_MASK_OBJ_LAYOUT_MAX | 9 | RFCTBD30 | L | 1 | | RCA4_TYPE_MASK_OBJ_LAYOUT_MAX | 9 | RFCTBD30 | L | 1 |
+-------------------------------+-------+----------+-----+----------+ +-------------------------------+-------+----------+-----+----------+
Table 16: Initial Recallable Object Type Assignments Table 17: Initial Recallable Object Type Assignments
22.3.2. Updating Registrations 22.3.2. Updating Registrations
The update of a registration will require IESG Approval on the advice The update of a registration will require IESG Approval on the advice
of a Designated Expert. of a Designated Expert.
22.4. Layout Types 22.4. Layout Types
IANA will create a registry called the "pNFS Layout Types Registry". IANA will create a registry called the "pNFS Layout Types Registry".
skipping to change at page 597, line 27 skipping to change at page 599, line 27
5. The minor versions of NFSv4 that are allowed to the use the 5. The minor versions of NFSv4 that are allowed to the use the
notification. While these are numeric values, IANA will not notification. While these are numeric values, IANA will not
allocate and assign them; the author of the relevant RFCs with allocate and assign them; the author of the relevant RFCs with
IESG Approval assigns these numbers. Each time there is new IESG Approval assigns these numbers. Each time there is new
minor version of NFSv4 approved, a Designated Expert should minor version of NFSv4 approved, a Designated Expert should
review the registry to make recommended updates as needed. review the registry to make recommended updates as needed.
22.4.1. Initial Registry 22.4.1. Initial Registry
The initial registry is in Table 17. The initial registry is in Table 18.
+-----------------------+-------+----------+-----+----------------+ +-----------------------+-------+----------+-----+----------------+
| Layout Type Name | Value | RFC | How | Minor Versions | | Layout Type Name | Value | RFC | How | Minor Versions |
+-----------------------+-------+----------+-----+----------------+ +-----------------------+-------+----------+-----+----------------+
| LAYOUT4_NFSV4_1_FILES | 0x1 | RFCTBD10 | N | 1 | | LAYOUT4_NFSV4_1_FILES | 0x1 | RFCTBD10 | N | 1 |
| LAYOUT4_OSD2_OBJECTS | 0x2 | RFCTBD30 | L | 1 | | LAYOUT4_OSD2_OBJECTS | 0x2 | RFCTBD30 | L | 1 |
| LAYOUT4_BLOCK_VOLUME | 0x3 | RFCTBD20 | L | 1 | | LAYOUT4_BLOCK_VOLUME | 0x3 | RFCTBD20 | L | 1 |
+-----------------------+-------+----------+-----+----------------+ +-----------------------+-------+----------+-----+----------------+
Table 17: Initial Layout Type Assignments Table 18: Initial Layout Type Assignments
22.4.2. Updating Registrations 22.4.2. Updating Registrations
The update of a registration will require IESG Approval on the advice The update of a registration will require IESG Approval on the advice
of a Designated Expert. of a Designated Expert.
22.4.3. Guidelines for Writing Layout Type Specifications 22.4.3. Guidelines for Writing Layout Type Specifications
The author of a new pNFS layout specification must follow these steps The author of a new pNFS layout specification must follow these steps
to obtain acceptance of the layout type as a Standards Track RFC: to obtain acceptance of the layout type as a Standards Track RFC:
skipping to change at page 600, line 32 skipping to change at page 602, line 32
more than 1024 bytes, or more if IANA permits) of the purpose of more than 1024 bytes, or more if IANA permits) of the purpose of
the variable. A reference to the explanation can be substituted. the variable. A reference to the explanation can be substituted.
3. The point of contact, including an email address. The point of 3. The point of contact, including an email address. The point of
contact can consume up to 256 bytes (or more if IANA permits). contact can consume up to 256 bytes (or more if IANA permits).
For assignments made on a Standards Action basis, the point of For assignments made on a Standards Action basis, the point of
contact is always IESG. contact is always IESG.
22.5.1.1.1. Initial Registry 22.5.1.1.1. Initial Registry
The initial registry is in Table 18. The initial registry is in Table 19.
+------------------------+----------+------------------+ +------------------------+----------+------------------+
| Variable Name | RFC | Point of Contact | | Variable Name | RFC | Point of Contact |
+------------------------+----------+------------------+ +------------------------+----------+------------------+
| ${ietf.org:CPU_ARCH} | RFCTBD10 | IESG | | ${ietf.org:CPU_ARCH} | RFCTBD10 | IESG |
| ${ietf.org:OS_TYPE} | RFCTBD10 | IESG | | ${ietf.org:OS_TYPE} | RFCTBD10 | IESG |
| ${ietf.org:OS_VERSION} | RFCTBD10 | IESG | | ${ietf.org:OS_VERSION} | RFCTBD10 | IESG |
+------------------------+----------+------------------+ +------------------------+----------+------------------+
Table 18: Initial List of Path Variables Table 19: Initial List of Path Variables
IANA will need to create registries for the values of the variable IANA will need to create registries for the values of the variable
names ${ietf.org:CPU_ARCH} and ${ietf.org:OS_TYPE}. See names ${ietf.org:CPU_ARCH} and ${ietf.org:OS_TYPE}. See
Section 22.5.2 and Section 22.5.3. Section 22.5.2 and Section 22.5.3.
For the values of the variable ${ietf.org:OS_VERSION}, no registry is For the values of the variable ${ietf.org:OS_VERSION}, no registry is
needed as the specifics of the values of the variable will vary with needed as the specifics of the values of the variable will vary with
the value of ${ietf.org:OS_TYPE}. Thus values for ${ietf.org: the value of ${ietf.org:OS_TYPE}. Thus values for ${ietf.org:
OS_VERSION} are on a Hierarchical Allocation basis and are of no OS_VERSION} are on a Hierarchical Allocation basis and are of no
concern to IANA. concern to IANA.
skipping to change at page 603, line 24 skipping to change at page 605, line 24
April 2008. April 2008.
[10] Recio, P., Metzler, B., Culley, P., Hilland, J., and D. Garcia, [10] Recio, P., Metzler, B., Culley, P., Hilland, J., and D. Garcia,
"A Remote Direct Memory Access Protocol Specification", "A Remote Direct Memory Access Protocol Specification",
RFC 5040, October 2007. RFC 5040, October 2007.
[11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[12] Shepler, S., Eisler, M., and D. Noveck, "NFSv4 Minor Version 1 [12] Shepler, S., Eisler, M., and D. Noveck, "NFSv4 Minor Version 1
XDR Description", draft-ietf-nfsv4-minorversion1-dot-x-11 (work XDR Description", draft-ietf-nfsv4-minorversion1-dot-x-12 (work
in progress), Dec 2008. in progress), Dec 2008.
[13] The Open Group, "Section 3.372 of Chapter 3 of Base Definitions [13] The Open Group, "Section 3.372 of Chapter 3 of Base Definitions
of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, of The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN 2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004. 1931624232", 2004.
[14] Eisler, M., "IANA Considerations for RPC Net Identifiers and [14] Eisler, M., "IANA Considerations for RPC Net Identifiers and
Universal Address Formats", draft-ietf-nfsv4-rpc-netid-04 (work Universal Address Formats", draft-ietf-nfsv4-rpc-netid-04 (work
in progress), December 2008. in progress), December 2008.
skipping to change at page 605, line 40 skipping to change at page 607, line 40
[36] Werme, R., "RPC XID Issues", USENIX Conference Proceedings , [36] Werme, R., "RPC XID Issues", USENIX Conference Proceedings ,
February 1996. February 1996.
[37] Nowicki, B., "NFS: Network File System Protocol specification", [37] Nowicki, B., "NFS: Network File System Protocol specification",
RFC 1094, March 1989. RFC 1094, March 1989.
[38] Bhide, A., Elnozahy, E., and S. Morgan, "A Highly Available [38] Bhide, A., Elnozahy, E., and S. Morgan, "A Highly Available
Network Server", USENIX Conference Proceedings , January 1991. Network Server", USENIX Conference Proceedings , January 1991.
[39] Halevy, B., Welch, B., and J. Zelenka, "Object-based pNFS [39] Halevy, B., Welch, B., and J. Zelenka, "Object-based pNFS
Operations", draft-ietf-nfsv4-pnfs-obj-10 (work in progress), Operations", draft-ietf-nfsv4-pnfs-obj-11 (work in progress),
December 2008. December 2008.
[40] Black, D., Fridella, S., and J. Glasgow, "pNFS Block/Volume [40] Black, D., Fridella, S., and J. Glasgow, "pNFS Block/Volume
Layout", draft-ietf-nfsv4-pnfs-block-10 (work in progress), Layout", draft-ietf-nfsv4-pnfs-block-11 (work in progress),
November 2008. December 2008.
[41] Callaghan, B., "WebNFS Client Specification", RFC 2054, [41] Callaghan, B., "WebNFS Client Specification", RFC 2054,
October 1996. October 1996.
[42] Callaghan, B., "WebNFS Server Specification", RFC 2055, [42] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996. October 1996.
[43] IESG, "IESG Processing of RFC Errata for the IETF Stream", URL [43] IESG, "IESG Processing of RFC Errata for the IETF Stream",
http://www.ietf.org/IESG/STATEMENTS/ July 2008.
iesg-statement-07-30-2008.txt, July 2008.
[44] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, [44] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624,
June 1999. June 1999.
[45] The Open Group, "Protocols for Interworking: XNFS, Version 3W, [45] The Open Group, "Protocols for Interworking: XNFS, Version 3W,
ISBN 1-85912-184-5", February 1998. ISBN 1-85912-184-5", February 1998.
[46] Floyd, S. and V. Jacobson, "The Synchronization of Periodic [46] Floyd, S. and V. Jacobson, "The Synchronization of Periodic
Routing Messages", IEEE/ACM Transactions on Networking 2(2), Routing Messages", IEEE/ACM Transactions on Networking 2(2),
pp. 122-136, April 1994. pp. 122-136, April 1994.
skipping to change at page 608, line 29 skipping to change at page 610, line 29
o NFSv4.1 file layout type, with the following inspectors: Andy o NFSv4.1 file layout type, with the following inspectors: Andy
Adamson, Marc Eshel, Sam Falkner, Garth Goodson, Rahul Iyer, Trond Adamson, Marc Eshel, Sam Falkner, Garth Goodson, Rahul Iyer, Trond
Myklebust, and Lisa Week. Myklebust, and Lisa Week.
o NFSv4.1 locking and directory delegations, with the following o NFSv4.1 locking and directory delegations, with the following
inspectors: Mike Eisler, Pranoop Erasani, Robert Gordon, Saadia inspectors: Mike Eisler, Pranoop Erasani, Robert Gordon, Saadia
Khan, Eric Kustarz, Dave Noveck, Spencer Shepler, and Amy Weaver. Khan, Eric Kustarz, Dave Noveck, Spencer Shepler, and Amy Weaver.
o EXCHANGE_ID and DESTROY_CLIENTID, with the following inspectors: o EXCHANGE_ID and DESTROY_CLIENTID, with the following inspectors:
Mike Eisler, Pranoop Erasani, Robert Gordon, Benny Halevy, Fred Mike Eisler, Pranoop Erasani, Robert Gordon, Benny Halevy, Fred
Isaman, Saadia Khan, Rick Macklem, Spencer Shepler, and Brent Isaman, Saadia Khan, Ricardo Labiaga, Rick Macklem, Trond
Welch. Myklebust, Spencer Shepler, and Brent Welch.
o Final pNFS inspection, with the following inspectors: Andy o Final pNFS inspection, with the following inspectors: Andy
Adamson, Mike Eisler, Mark Eshel, Sam Falkner, Jason Glasgow, Adamson, Mike Eisler, Mark Eshel, Sam Falkner, Jason Glasgow,
Garth Goodson, Robert Gordon, Benny Halevy, Dean Hildebrand, Rahul Garth Goodson, Robert Gordon, Benny Halevy, Dean Hildebrand, Rahul
Iyer, Suchit Kaura, Trond Myklebust, Anatoly Pinchuk, Spencer Iyer, Suchit Kaura, Trond Myklebust, Anatoly Pinchuk, Spencer
Shepler, Renu Tewari, Lisa Week, and Brent Welch. Shepler, Renu Tewari, Lisa Week, and Brent Welch.
A review team worked together to generate the tables of assignments A review team worked together to generate the tables of assignments
of error sets to operations and make sure that each such assignment of error sets to operations and make sure that each such assignment
had two or more people validating it. Participating in the process had two or more people validating it. Participating in the process
were: Andy Adamson, Mike Eisler, Sam Falkner, Garth Goodson, Robert were: Andy Adamson, Mike Eisler, Sam Falkner, Garth Goodson, Robert
Gordon, Trond Myklebust, Dave Noveck, Spencer Shepler, Tom Talpey, Gordon, Trond Myklebust, Dave Noveck, Spencer Shepler, Tom Talpey,
Amy Weaver, and Lisa Week. Amy Weaver, and Lisa Week.
Jari Arkko, David Black, Scott Bradner, Lisa Dusseault, Lars Eggert, Jari Arkko, David Black, Scott Bradner, Lisa Dusseault, Lars Eggert,
Chris Newman, and Tim Polk provided valuable review and guidance. Chris Newman, and Tim Polk provided valuable review and guidance.
Others who provided comments include: Jason Goldschmidt, Vijay K. Olga Kornievskaia found several errors in the SSV specification.
Gurbani, James Lentini, Anshul Madan, Archana Ramani, Jim Rees,
Mahesh Siddheshwar, and Sunil Bhargo. Ricardo Labiaga found several places where the use of RPCSEC_GSS was
underspecified.
Others who provided comments include: Sunil Bhargo, Jason
Goldschmidt, Vijay K. Gurbani, James Lentini, Anshul Madan, Archana
Ramani, Jim Rees, and Mahesh Siddheshwar.
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document] RFC number of this document]
skipping to change at page 609, line 38 skipping to change at page 612, line 4
Authors' Addresses Authors' Addresses
Spencer Shepler Spencer Shepler
Storspeed, Inc. Storspeed, Inc.
7808 Moonflower Drive 7808 Moonflower Drive
Austin, TX 78750 Austin, TX 78750
USA USA
Phone: +1-512-402-5811 ext 8530 Phone: +1-512-402-5811 ext 8530
Email: shepler@storspeed.com Email: shepler@storspeed.com
Mike Eisler Mike Eisler
NetApp NetApp
5765 Chase Point Circle 5765 Chase Point Circle
Colorado Springs, CO 80919 Colorado Springs, CO 80919
USA USA
Phone: +1-719-599-9026 Phone: +1-719-599-9026
Email: mike@eisler.com Email: mike@eisler.com
URI: http://www.eisler.com URI: http://www.eisler.com
David Noveck David Noveck
NetApp NetApp
1601 Trapelo Road, Suite 16 1601 Trapelo Road, Suite 16
Waltham, MA 02454 Waltham, MA 02454
USA USA
Phone: +1-781-768-5347 Phone: +1-781-768-5347
Email: dnoveck@netapp.com Email: dnoveck@netapp.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 134 change blocks. 
567 lines changed or deleted 649 lines changed or added

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