rfc8881.original   rfc8881.txt 
NFSv4 D. Noveck, Ed. Internet Engineering Task Force (IETF) D. Noveck, Ed.
Internet-Draft NetApp Request for Comments: 8881 NetApp
Obsoletes: 5661 (if approved) C. Lever Obsoletes: 5661 C. Lever
Intended status: Standards Track ORACLE Category: Standards Track ORACLE
Expires: July 31, 2020 January 28, 2020 ISSN: 2070-1721 August 2020
Network File System (NFS) Version 4 Minor Version 1 Protocol Network File System (NFS) Version 4 Minor Version 1 Protocol
draft-ietf-nfsv4-rfc5661sesqui-msns-04
Abstract Abstract
This document describes the Network File System (NFS) version 4 minor This document describes the Network File System (NFS) version 4 minor
version 1, including features retained from the base protocol (NFS version 1, including features retained from the base protocol (NFS
version 4 minor version 0, which is specified in RFC 7530) and version 4 minor version 0, which is specified in RFC 7530) and
protocol extensions made subsequently. The later minor version has protocol extensions made subsequently. The later minor version has
no dependencies on NFS version 4 minor version 0, and is considered a no dependencies on NFS version 4 minor version 0, and is considered a
separate protocol. separate protocol.
This document obsoletes RFC5661. It substantially revises the This document obsoletes RFC 5661. It substantially revises the
treatment of features relating to multi-server namespace, superseding treatment of features relating to multi-server namespace, superseding
the description of those features appearing in RFC5661. the description of those features appearing in RFC 5661.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on July 31, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8881.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at line 66
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction
1.1. Introduction to this Update . . . . . . . . . . . . . . . 7 1.1. Introduction to This Update
1.2. The NFS Version 4 Minor Version 1 Protocol . . . . . . . 9 1.2. The NFS Version 4 Minor Version 1 Protocol
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 10 1.3. Requirements Language
1.4. Scope of This Document . . . . . . . . . . . . . . . . . 10 1.4. Scope of This Document
1.5. NFSv4 Goals . . . . . . . . . . . . . . . . . . . . . . . 10 1.5. NFSv4 Goals
1.6. NFSv4.1 Goals . . . . . . . . . . . . . . . . . . . . . . 11 1.6. NFSv4.1 Goals
1.7. General Definitions . . . . . . . . . . . . . . . . . . . 11 1.7. General Definitions
1.8. Overview of NFSv4.1 Features . . . . . . . . . . . . . . 14 1.8. Overview of NFSv4.1 Features
1.9. Differences from NFSv4.0 . . . . . . . . . . . . . . . . 18 1.9. Differences from NFSv4.0
2. Core Infrastructure . . . . . . . . . . . . . . . . . . . . . 19 2. Core Infrastructure
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 19 2.1. Introduction
2.2. RPC and XDR . . . . . . . . . . . . . . . . . . . . . . . 19 2.2. RPC and XDR
2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 22 2.3. COMPOUND and CB_COMPOUND
2.4. Client Identifiers and Client Owners . . . . . . . . . . 23 2.4. Client Identifiers and Client Owners
2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . . 29 2.5. Server Owners
2.6. Security Service Negotiation . . . . . . . . . . . . . . 29 2.6. Security Service Negotiation
2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 35 2.7. Minor Versioning
2.8. Non-RPC-Based Security Services . . . . . . . . . . . . . 37 2.8. Non-RPC-Based Security Services
2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 38 2.9. Transport Layers
2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.10. Session
3. Protocol Constants and Data Types . . . . . . . . . . . . . . 87 3. Protocol Constants and Data Types
3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . . 87 3.1. Basic Constants
3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 88 3.2. Basic Data Types
3.3. Structured Data Types . . . . . . . . . . . . . . . . . . 90 3.3. Structured Data Types
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 98 4. Filehandles
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 99 4.1. Obtaining the First Filehandle
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 100 4.2. Filehandle Types
4.3. One Method of Constructing a Volatile Filehandle . . . . 102 4.3. One Method of Constructing a Volatile Filehandle
4.4. Client Recovery from Filehandle Expiration . . . . . . . 103 4.4. Client Recovery from Filehandle Expiration
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 104 5. File Attributes
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . . 105 5.1. REQUIRED Attributes
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 105 5.2. RECOMMENDED Attributes
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 106 5.3. Named Attributes
5.4. Classification of Attributes . . . . . . . . . . . . . . 107 5.4. Classification of Attributes
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 108 5.5. Set-Only and Get-Only Attributes
5.6. REQUIRED Attributes - List and Definition References . . 108 5.6. REQUIRED Attributes - List and Definition References
5.7. RECOMMENDED Attributes - List and Definition References . 109 5.7. RECOMMENDED Attributes - List and Definition References
5.8. Attribute Definitions . . . . . . . . . . . . . . 111 5.8. Attribute Definitions
5.9. Interpreting owner and owner_group . . . . . . . . . . . 120 5.9. Interpreting owner and owner_group
5.10. Character Case Attributes . . . . . . . . . . . . . . . . 122 5.10. Character Case Attributes
5.11. Directory Notification Attributes . . . . . . . . . . . . 122 5.11. Directory Notification Attributes
5.12. pNFS Attribute Definitions . . . . . . . . . . . . . . . 123 5.12. pNFS Attribute Definitions
5.13. Retention Attributes . . . . . . . . . . . . . . . . . . 124 5.13. Retention Attributes
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 127 6. Access Control Attributes
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.1. Goals
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 128 6.2. File Attributes Discussion
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 145 6.3. Common Methods
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 147 6.4. Requirements
7. Single-Server Namespace . . . . . . . . . . . . . . . . . . . 154 7. Single-Server Namespace
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 154 7.1. Server Exports
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 154 7.2. Browsing Exports
7.3. Server Pseudo File System . . . . . . . . . . . . . . . . 155 7.3. Server Pseudo File System
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 155 7.4. Multiple Roots
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . . 156 7.5. Filehandle Volatility
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . . 156 7.6. Exported Root
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 156 7.7. Mount Point Crossing
7.8. Security Policy and Namespace Presentation . . . . . . . 157 7.8. Security Policy and Namespace Presentation
8. State Management . . . . . . . . . . . . . . . . . . . . . . 158 8. State Management
8.1. Client and Session ID . . . . . . . . . . . . . . . . . . 159 8.1. Client and Session ID
8.2. Stateid Definition . . . . . . . . . . . . . . . . . . . 159 8.2. Stateid Definition
8.3. Lease Renewal . . . . . . . . . . . . . . . . . . . . . . 168 8.3. Lease Renewal
8.4. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 170 8.4. Crash Recovery
8.5. Server Revocation of Locks . . . . . . . . . . . . . . . 181 8.5. Server Revocation of Locks
8.6. Short and Long Leases . . . . . . . . . . . . . . . . . . 182 8.6. Short and Long Leases
8.7. Clocks, Propagation Delay, and Calculating Lease 8.7. Clocks, Propagation Delay, and Calculating Lease Expiration
Expiration . . . . . . . . . . . . . . . . . . . . . . . 183 8.8. Obsolete Locking Infrastructure from NFSv4.0
8.8. Obsolete Locking Infrastructure from NFSv4.0 . . . . . . 183 9. File Locking and Share Reservations
9. File Locking and Share Reservations . . . . . . . . . . . . . 184 9.1. Opens and Byte-Range Locks
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 184 9.2. Lock Ranges
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . . 188 9.3. Upgrading and Downgrading Locks
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . . 189 9.4. Stateid Seqid Values and Byte-Range Locks
9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . . 189 9.5. Issues with Multiple Open-Owners
9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 189 9.6. Blocking Locks
9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 190 9.7. Share Reservations
9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 191 9.8. OPEN/CLOSE Operations
9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . . 192 9.9. Open Upgrade and Downgrade
9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 193 9.10. Parallel OPENs
9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 194 9.11. Reclaim of Open and Byte-Range Locks
9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 194 10. Client-Side Caching
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 195 10.1. Performance Challenges for Client-Side Caching
10.1. Performance Challenges for Client-Side Caching . . . . . 195 10.2. Delegation and Callbacks
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 196 10.3. Data Caching
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 201 10.4. Open Delegation
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 205 10.5. Data Caching and Revocation
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 216 10.6. Attribute Caching
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 218 10.7. Data and Metadata Caching and Memory Mapped Files
10.7. Data and Metadata Caching and Memory Mapped Files . . . 220 10.8. Name and Directory Caching without Directory Delegations
10.8. Name and Directory Caching without Directory Delegations 222 10.9. Directory Delegations
10.9. Directory Delegations . . . . . . . . . . . . . . . . . 224 11. Multi-Server Namespace
11. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 228 11.1. Terminology
11.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 228 11.2. File System Location Attributes
11.2. File System Location Attributes . . . . . . . . . . . . 232 11.3. File System Presence or Absence
11.3. File System Presence or Absence . . . . . . . . . . . . 233 11.4. Getting Attributes for an Absent File System
11.4. Getting Attributes for an Absent File System . . . . . . 234 11.5. Uses of File System Location Information
11.5. Uses of File System Location Information . . . . . . . . 236 11.6. Trunking without File System Location Information
11.6. Trunking without File System Location Information . . . 246 11.7. Users and Groups in a Multi-Server Namespace
11.7. Users and Groups in a Multi-server Namespace . . . . . . 246 11.8. Additional Client-Side Considerations
11.8. Additional Client-Side Considerations . . . . . . . . . 248 11.9. Overview of File Access Transitions
11.9. Overview of File Access Transitions . . . . . . . . . . 248 11.10. Effecting Network Endpoint Transitions
11.10. Effecting Network Endpoint Transitions . . . . . . . . . 249 11.11. Effecting File System Transitions
11.11. Effecting File System Transitions . . . . . . . . . . . 250 11.12. Transferring State upon Migration
11.12. Transferring State upon Migration . . . . . . . . . . . 260 11.13. Client Responsibilities When Access Is Transitioned
11.13. Client Responsibilities when Access is Transitioned . . 261 11.14. Server Responsibilities Upon Migration
11.14. Server Responsibilities Upon Migration . . . . . . . . . 271 11.15. Effecting File System Referrals
11.15. Effecting File System Referrals . . . . . . . . . . . . 277 11.16. The Attribute fs_locations
11.16. The Attribute fs_locations . . . . . . . . . . . . . . . 284 11.17. The Attribute fs_locations_info
11.17. The Attribute fs_locations_info . . . . . . . . . . . . 287 11.18. The Attribute fs_status
11.18. The Attribute fs_status . . . . . . . . . . . . . . . . 300 12. Parallel NFS (pNFS)
12. Parallel NFS (pNFS) . . . . . . . . . . . . . . . . . . . . . 304 12.1. Introduction
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 304 12.2. pNFS Definitions
12.2. pNFS Definitions . . . . . . . . . . . . . . . . . . . . 305 12.3. pNFS Operations
12.3. pNFS Operations . . . . . . . . . . . . . . . . . . . . 311 12.4. pNFS Attributes
12.4. pNFS Attributes . . . . . . . . . . . . . . . . . . . . 312 12.5. Layout Semantics
12.5. Layout Semantics . . . . . . . . . . . . . . . . . . . . 312 12.6. pNFS Mechanics
12.6. pNFS Mechanics . . . . . . . . . . . . . . . . . . . . . 327 12.7. Recovery
12.7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 329 12.8. Metadata and Storage Device Roles
12.8. Metadata and Storage Device Roles . . . . . . . . . . . 334 12.9. Security Considerations for pNFS
12.9. Security Considerations for pNFS . . . . . . . . . . . . 334 13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type
13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type . 336 13.1. Client ID and Session Considerations
13.1. Client ID and Session Considerations . . . . . . . . . . 336 13.2. File Layout Definitions
13.2. File Layout Definitions . . . . . . . . . . . . . . . . 339 13.3. File Layout Data Types
13.3. File Layout Data Types . . . . . . . . . . . . . . . . . 339 13.4. Interpreting the File Layout
13.4. Interpreting the File Layout . . . . . . . . . . . . . . 343 13.5. Data Server Multipathing
13.5. Data Server Multipathing . . . . . . . . . . . . . . . . 351 13.6. Operations Sent to NFSv4.1 Data Servers
13.6. Operations Sent to NFSv4.1 Data Servers . . . . . . . . 352 13.7. COMMIT through Metadata Server
13.7. COMMIT through Metadata Server . . . . . . . . . . . . . 354 13.8. The Layout Iomode
13.8. The Layout Iomode . . . . . . . . . . . . . . . . . . . 355 13.9. Metadata and Data Server State Coordination
13.9. Metadata and Data Server State Coordination . . . . . . 356 13.10. Data Server Component File Size
13.10. Data Server Component File Size . . . . . . . . . . . . 359 13.11. Layout Revocation and Fencing
13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 359 13.12. Security Considerations for the File Layout Type
13.12. Security Considerations for the File Layout Type . . . . 360 14. Internationalization
14. Internationalization . . . . . . . . . . . . . . . . . . . . 361 14.1. Stringprep Profile for the utf8str_cs Type
14.1. Stringprep Profile for the utf8str_cs Type . . . . . . . 362 14.2. Stringprep Profile for the utf8str_cis Type
14.2. Stringprep Profile for the utf8str_cis Type . . . . . . 364 14.3. Stringprep Profile for the utf8str_mixed Type
14.3. Stringprep Profile for the utf8str_mixed Type . . . . . 365 14.4. UTF-8 Capabilities
14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 367 14.5. UTF-8 Related Errors
14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 367 15. Error Values
15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 368 15.1. Error Definitions
15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 368 15.2. Operations and Their Valid Errors
15.2. Operations and Their Valid Errors . . . . . . . . . . . 390 15.3. Callback Operations and Their Valid Errors
15.3. Callback Operations and Their Valid Errors . . . . . . . 406 15.4. Errors and the Operations That Use Them
15.4. Errors and the Operations That Use Them . . . . . . . . 409 16. NFSv4.1 Procedures
16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 423 16.1. Procedure 0: NULL - No Operation
16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 423 16.2. Procedure 1: COMPOUND - Compound Operations
16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 424 17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL
17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 435 18. NFSv4.1 Operations
18. NFSv4.1 Operations . . . . . . . . . . . . . . . . . . . . . 438 18.1. Operation 3: ACCESS - Check Access Rights
18.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 438 18.2. Operation 4: CLOSE - Close File
18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 444 18.3. Operation 5: COMMIT - Commit Cached Data
18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 445 18.4. Operation 6: CREATE - Create a Non-Regular File Object
18.4. Operation 6: CREATE - Create a Non-Regular File Object . 448
18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting 18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 451 Recovery
18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 452 18.6. Operation 8: DELEGRETURN - Return Delegation
18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 452 18.7. Operation 9: GETATTR - Get Attributes
18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 454 18.8. Operation 10: GETFH - Get Current Filehandle
18.9. Operation 11: LINK - Create Link to a File . . . . . . . 455 18.9. Operation 11: LINK - Create Link to a File
18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 458 18.10. Operation 12: LOCK - Create Lock
18.11. Operation 13: LOCKT - Test for Lock . . . . . . . . . . 463 18.11. Operation 13: LOCKT - Test for Lock
18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 464 18.12. Operation 14: LOCKU - Unlock File
18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 466 18.13. Operation 15: LOOKUP - Lookup Filename
18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 468 18.14. Operation 16: LOOKUPP - Lookup Parent Directory
18.15. Operation 17: NVERIFY - Verify Difference in Attributes 469 18.15. Operation 17: NVERIFY - Verify Difference in Attributes
18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 470 18.16. Operation 18: OPEN - Open a Regular File
18.17. Operation 19: OPENATTR - Open Named Attribute Directory 490 18.17. Operation 19: OPENATTR - Open Named Attribute Directory
18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 492 18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access
18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 493 18.19. Operation 22: PUTFH - Set Current Filehandle
18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . 494 18.20. Operation 23: PUTPUBFH - Set Public Filehandle
18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 496 18.21. Operation 24: PUTROOTFH - Set Root Filehandle
18.22. Operation 25: READ - Read from File . . . . . . . . . . 497 18.22. Operation 25: READ - Read from File
18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 499 18.23. Operation 26: READDIR - Read Directory
18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 503 18.24. Operation 27: READLINK - Read Symbolic Link
18.25. Operation 28: REMOVE - Remove File System Object . . . . 504 18.25. Operation 28: REMOVE - Remove File System Object
18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 507 18.26. Operation 29: RENAME - Rename Directory Entry
18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 510 18.27. Operation 31: RESTOREFH - Restore Saved Filehandle
18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 511 18.28. Operation 32: SAVEFH - Save Current Filehandle
18.29. Operation 33: SECINFO - Obtain Available Security . . . 512 18.29. Operation 33: SECINFO - Obtain Available Security
18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 516 18.30. Operation 34: SETATTR - Set Attributes
18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 519 18.31. Operation 37: VERIFY - Verify Same Attributes
18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 520 18.32. Operation 38: WRITE - Write to File
18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control . . 525 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control
18.34. Operation 41: BIND_CONN_TO_SESSION - Associate 18.34. Operation 41: BIND_CONN_TO_SESSION - Associate Connection
Connection with Session . . . . . . . . . . . . . . . . 526 with Session
18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 529 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID
18.36. Operation 43: CREATE_SESSION - Create New Session and 18.36. Operation 43: CREATE_SESSION - Create New Session and
Confirm Client ID . . . . . . . . . . . . . . . . . . . 548 Confirm Client ID
18.37. Operation 44: DESTROY_SESSION - Destroy a Session . . . 558 18.37. Operation 44: DESTROY_SESSION - Destroy a Session
18.38. Operation 45: FREE_STATEID - Free Stateid with No Locks 560 18.38. Operation 45: FREE_STATEID - Free Stateid with No Locks
18.39. Operation 46: GET_DIR_DELEGATION - Get a Directory 18.39. Operation 46: GET_DIR_DELEGATION - Get a Directory
Delegation . . . . . . . . . . . . . . . . . . . . . . . 561 Delegation
18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 565 18.40. Operation 47: GETDEVICEINFO - Get Device Information
18.41. Operation 48: GETDEVICELIST - Get All Device Mappings 18.41. Operation 48: GETDEVICELIST - Get All Device Mappings for
for a File System . . . . . . . . . . . . . . . . . . . 568 a File System
18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made Using a 18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made Using a
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 569 Layout
18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 573 18.43. Operation 50: LAYOUTGET - Get Layout Information
18.44. Operation 51: LAYOUTRETURN - Release Layout Information 583 18.44. Operation 51: LAYOUTRETURN - Release Layout Information
18.45. Operation 52: SECINFO_NO_NAME - Get Security on Unnamed 18.45. Operation 52: SECINFO_NO_NAME - Get Security on Unnamed
Object . . . . . . . . . . . . . . . . . . . . . . . . . 588 Object
18.46. Operation 53: SEQUENCE - Supply Per-Procedure Sequencing 18.46. Operation 53: SEQUENCE - Supply Per-Procedure Sequencing
and Control . . . . . . . . . . . . . . . . . . . . . . 589 and Control
18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 595 18.47. Operation 54: SET_SSV - Update SSV for a Client ID
18.48. Operation 55: TEST_STATEID - Test Stateids for Validity 597 18.48. Operation 55: TEST_STATEID - Test Stateids for Validity
18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 599 18.49. Operation 56: WANT_DELEGATION - Request Delegation
18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID . . 603 18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID
18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims 18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims
Finished . . . . . . . . . . . . . . . . . . . . . . . . 604 Finished
18.52. Operation 10044: ILLEGAL - Illegal Operation . . . . . . 607 18.52. Operation 10044: ILLEGAL - Illegal Operation
19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 608 19. NFSv4.1 Callback Procedures
19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 608 19.1. Procedure 0: CB_NULL - No Operation
19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 608 19.2. Procedure 1: CB_COMPOUND - Compound Operations
20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 613 20. NFSv4.1 Callback Operations
20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 613 20.1. Operation 3: CB_GETATTR - Get Attributes
20.2. Operation 4: CB_RECALL - Recall a Delegation . . . . . . 614 20.2. Operation 4: CB_RECALL - Recall a Delegation
20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from Client 615 20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from Client
20.4. Operation 6: CB_NOTIFY - Notify Client of Directory 20.4. Operation 6: CB_NOTIFY - Notify Client of Directory
Changes . . . . . . . . . . . . . . . . . . . . . . . . 618 Changes
20.5. Operation 7: CB_PUSH_DELEG - Offer Previously Requested 20.5. Operation 7: CB_PUSH_DELEG - Offer Previously Requested
Delegation to Client . . . . . . . . . . . . . . . . . . 622 Delegation to Client
20.6. Operation 8: CB_RECALL_ANY - Keep Any N Recallable 20.6. Operation 8: CB_RECALL_ANY - Keep Any N Recallable Objects
Objects . . . . . . . . . . . . . . . . . . . . . . . . 623
20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal Resources 20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal Resources
for Recallable Objects . . . . . . . . . . . . . . . . . 626 for Recallable Objects
20.8. Operation 10: CB_RECALL_SLOT - Change Flow Control 20.8. Operation 10: CB_RECALL_SLOT - Change Flow Control Limits
Limits . . . . . . . . . . . . . . . . . . . . . . . . . 627 20.9. Operation 11: CB_SEQUENCE - Supply Backchannel Sequencing
20.9. Operation 11: CB_SEQUENCE - Supply Backchannel and Control
Sequencing and Control . . . . . . . . . . . . . . . . . 628
20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending 20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending
Delegation Wants . . . . . . . . . . . . . . . . . . . . 631 Delegation Wants
20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of Possible 20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of Possible
Lock Availability . . . . . . . . . . . . . . . . . . . 632 Lock Availability
20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify Client of 20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify Client of Device
Device ID Changes . . . . . . . . . . . . . . . . . . . 633 ID Changes
20.13. Operation 10044: CB_ILLEGAL - Illegal Callback Operation 635 20.13. Operation 10044: CB_ILLEGAL - Illegal Callback Operation
21. Security Considerations . . . . . . . . . . . . . . . . . . . 636 21. Security Considerations
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 640 22. IANA Considerations
22.1. IANA Actions Needed . . . . . . . . . . . . . . . . . . 641 22.1. IANA Actions
22.2. Named Attribute Definitions . . . . . . . . . . . . . . 641 22.2. Named Attribute Definitions
22.3. Device ID Notifications . . . . . . . . . . . . . . . . 642 22.3. Device ID Notifications
22.4. Object Recall Types . . . . . . . . . . . . . . . . . . 644 22.4. Object Recall Types
22.5. Layout Types . . . . . . . . . . . . . . . . . . . . . . 645 22.5. Layout Types
22.6. Path Variable Definitions . . . . . . . . . . . . . . . 648 22.6. Path Variable Definitions
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 652 23. References
23.1. Normative References . . . . . . . . . . . . . . . . . . 652 23.1. Normative References
23.2. Informative References . . . . . . . . . . . . . . . . . 655 23.2. Informative References
Appendix A. Need for this Update . . . . . . . . . . . . . . . . 659 Appendix A. The Need for This Update
Appendix B. Changes in this Update . . . . . . . . . . . . . . . 661 Appendix B. Changes in This Update
B.1. Revisions Made to Section 11 of RFC5661 . . . . . . . . . 661 B.1. Revisions Made to Section 11 of RFC 5661
B.2. Revisions Made to Operations in RFC5661 . . . . . . . . . 664 B.2. Revisions Made to Operations in RFC 5661
B.3. Revisions Made to Error Definitions in RFC5661 . . . . . 666 B.3. Revisions Made to Error Definitions in RFC 5661
B.4. Other Revisions Made to RFC5661 . . . . . . . . . . . . . 667 B.4. Other Revisions Made to RFC 5661
Appendix C. Security Issues that Need to be Addressed . . . . . 668 Appendix C. Security Issues That Need to Be Addressed
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 670 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 673 Authors' Addresses
1. Introduction 1. Introduction
1.1. Introduction to this Update 1.1. Introduction to This Update
Two important features previously defined in minor version 0 but Two important features previously defined in minor version 0 but
never fully addressed in minor version 1 are trunking, the never fully addressed in minor version 1 are trunking, which is the
simultaneous use of multiple connections between a client and server, simultaneous use of multiple connections between a client and server,
potentially to different network addresses, and transparent state potentially to different network addresses, and Transparent State
migration, which allows a file system to be transferred between Migration, which allows a file system to be transferred between
servers in a way that provides to the client the ability to maintain servers in a way that provides to the client the ability to maintain
its existing locking state across the transfer. its existing locking state across the transfer.
The revised description of the NFS version 4 minor version 1 The revised description of the NFS version 4 minor version 1
(NFSv4.1) protocol presented in this update is necessary to enable (NFSv4.1) protocol presented in this update is necessary to enable
full use of these features together with other multi-server namespace full use of these features together with other multi-server namespace
features. This document is in the form of an updated description of features. This document is in the form of an updated description of
the NFSv4.1 protocol previously defined in RFC5661 [65]. RFC5661 is the NFSv4.1 protocol previously defined in RFC 5661 [66]. RFC 5661
obsoleted by this document. However, the update has a limited scope is obsoleted by this document. However, the update has a limited
and is focused on enabling full use of trunking and transparent state scope and is focused on enabling full use of trunking and Transparent
migration. The need for these changes is discussed in Appendix A. State Migration. The need for these changes is discussed in
Appendix B describes the specific changes made to arrive at the Appendix A. Appendix B describes the specific changes made to arrive
current text. at the current text.
This limited-scope update replaces the current NFSv4.1 RFC with the This limited-scope update replaces the current NFSv4.1 RFC with the
intention of providing an authoritative and complete specification, intention of providing an authoritative and complete specification,
the motivation for which is discussed in [35], addressing the issues the motivation for which is discussed in [36], addressing the issues
within the scope of the update. However, it will not address issues within the scope of the update. However, it will not address issues
that are known but outside of this limited scope as could expected by that are known but outside of this limited scope as could be expected
a full update of the protocol. Below are some areas which are known by a full update of the protocol. Below are some areas that are
to need addressing in a future update of the protocol. known to need addressing in a future update of the protocol:
o Work needs to be done with regard to RFC8178 [66] which * Work needs to be done with regard to RFC 8178 [67], which
establishes NFSv4-wide versioning rules. As RFC5661 is currently establishes NFSv4-wide versioning rules. As RFC 5661 is currently
inconsistent with that document, changes are needed in order to inconsistent with that document, changes are needed in order to
arrive at a situation in which there would be no need for RFC8178 arrive at a situation in which there would be no need for RFC 8178
to update the NFSv4.1 specification. to update the NFSv4.1 specification.
o Work needs to be done with regard to RFC8434 [69], which * Work needs to be done with regard to RFC 8434 [70], which
establishes the requirements for pNFS layout types, which are not establishes the requirements for parallel NFS (pNFS) layout types,
clearly defined in RFC5661. When that work is done and the which are not clearly defined in RFC 5661. When that work is done
resulting documents approved, the new NFSv4.1 specification and the resulting documents approved, the new NFSv4.1
document will provide a clear set of requirements for layout types specification document will provide a clear set of requirements
and a description of the file layout type that conforms to those for layout types and a description of the file layout type that
requirements. Other layout types will have their own conforms to those requirements. Other layout types will have
specification documents that conforms to those requirements as their own specification documents that conform to those
well. requirements as well.
o Work needs to be done to address many errata reports relevant to * Work needs to be done to address many errata reports relevant to
RFC 5661, other than errata report 2006 [63], which is addressed RFC 5661, other than errata report 2006 [64], which is addressed
in this document. Addressing that report was not deferrable in this document. Addressing that report was not deferrable
because of the interaction of the changes suggested there and the because of the interaction of the changes suggested there and the
newly described handling of state and session migration. newly described handling of state and session migration.
The errata reports that have been deferred and that will need to The errata reports that have been deferred and that will need to
be addressed in a later document include reports currently be addressed in a later document include reports currently
assigned a range of statuses in the errata reporting system assigned a range of statuses in the errata reporting system,
including reports marked Accepted and those marked Hold For including reports marked Accepted and those marked Hold For
Document Update because the change was too minor to address Document Update because the change was too minor to address
immediately. immediately.
In addition, there is a set of other reports, including at least In addition, there is a set of other reports, including at least
one in state Rejected, which will need to be addressed in a later one in state Rejected, that will need to be addressed in a later
document. This will involve making changes to consensus decisions document. This will involve making changes to consensus decisions
reflected in RFC 5661, in situation in which the working group has reflected in RFC 5661, in situations in which the working group
decided that the treatment in RFC 5661 is incorrect, and needs to has decided that the treatment in RFC 5661 is incorrect and needs
be revised to reflect the working group's new consensus and ensure to be revised to reflect the working group's new consensus and to
compatibility with existing implementations that do not follow the ensure compatibility with existing implementations that do not
handling described in in RFC 5661. follow the handling described in RFC 5661.
Note that it is expected that all such errata reports will remain Note that it is expected that all such errata reports will remain
relevant to implementers and the authors of an eventual relevant to implementors and the authors of an eventual
rfc5661bis, despite the fact that this document, when approved, rfc5661bis, despite the fact that this document obsoletes RFC 5661
will obsolete RFC 5661 [65]. [66].
o There is a need for a new approach to the description of * There is a need for a new approach to the description of
internationalization since the current internationalization internationalization since the current internationalization
section (Section 14) has never been implemented and does not meet section (Section 14) has never been implemented and does not meet
the needs of the NFSv4 protocol. Possible solutions are to create the needs of the NFSv4 protocol. Possible solutions are to create
a new internationalization section modeled on that in [67] or to a new internationalization section modeled on that in [68] or to
create a new document describing internationalization for all create a new document describing internationalization for all
NFSv4 minor versions and reference that document in the RFCs NFSv4 minor versions and reference that document in the RFCs
defining both NFSv4.0 and NFSv4.1. defining both NFSv4.0 and NFSv4.1.
o There is a need for a revised treatment of security in NFSv4.1. * There is a need for a revised treatment of security in NFSv4.1.
The issues with the existing treatment are discussed in The issues with the existing treatment are discussed in
Appendix C. Appendix C.
Until the above work is done, there will not be a consistent set of Until the above work is done, there will not be a consistent set of
documents providing a description of the NFSv4.1 protocol and any documents that provides a description of the NFSv4.1 protocol, and
full description would involve documents updating other documents any full description would involve documents updating other documents
within the specification. The updates applied by RFC8434 [69] and within the specification. The updates applied by RFC 8434 [70] and
RFC8178 [66] to RFC5661 also apply to this specification, and will RFC 8178 [67] to RFC 5661 also apply to this specification, and will
apply to any subsequent v4.1 specification until that work is done. apply to any subsequent v4.1 specification until that work is done.
1.2. The NFS Version 4 Minor Version 1 Protocol 1.2. 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 now described in RFC 7530 [67]. It generally version, NFSv4.0, is now described in RFC 7530 [68]. It generally
follows the guidelines for minor versioning that are listed in follows the guidelines for minor versioning that are listed in
Section 10 of RFC 3530. However, it diverges from guidelines 11 ("a Section 10 of RFC 3530 [37]. However, it diverges from guidelines 11
client and server that support minor version X must support minor ("a client and server that support minor version X must support minor
versions 0 through X-1") and 12 ("no new features may be introduced versions 0 through X-1") and 12 ("no new features may be introduced
as mandatory in a minor version"). These divergences are due to the as mandatory in a minor version"). These divergences are due to the
introduction of the sessions model for managing non-idempotent introduction of the sessions model for managing non-idempotent
operations and the RECLAIM_COMPLETE operation. These two new operations and the RECLAIM_COMPLETE operation. These two new
features are infrastructural in nature and simplify implementation of features are infrastructural in nature and simplify implementation of
existing and other new features. Making them anything but REQUIRED existing and other new features. Making them anything but REQUIRED
would add undue complexity to protocol definition and implementation. would add undue complexity to protocol definition and implementation.
NFSv4.1 accordingly updates the minor versioning guidelines NFSv4.1 accordingly updates the minor versioning guidelines
(Section 2.7). (Section 2.7).
skipping to change at page 10, line 25 skipping to change at line 448
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].
1.4. Scope of This Document 1.4. Scope of This Document
This document describes the NFSv4.1 protocol. With respect to This document describes the NFSv4.1 protocol. With respect to
NFSv4.0, this document does not: NFSv4.0, this document does not:
o describe the NFSv4.0 protocol, except where needed to contrast * describe the NFSv4.0 protocol, except where needed to contrast
with NFSv4.1. with NFSv4.1.
o modify the specification of the NFSv4.0 protocol. * modify the specification of the NFSv4.0 protocol.
o clarify the NFSv4.0 protocol. * clarify the NFSv4.0 protocol.
1.5. NFSv4 Goals 1.5. NFSv4 Goals
The NFSv4 protocol is a further revision of the NFS protocol defined The NFSv4 protocol is a further revision of the NFS protocol defined
already by NFSv3 [37]. It retains the essential characteristics of already by NFSv3 [38]. It retains the essential characteristics of
previous versions: easy recovery; independence of transport previous versions: easy recovery; independence of transport
protocols, operating systems, and file systems; simplicity; and good protocols, operating systems, and file systems; simplicity; and good
performance. NFSv4 has the following goals: performance. NFSv4 has the following goals:
o Improved access and good performance on the Internet * Improved access and good performance on the Internet
The protocol is designed to transit firewalls easily, perform well The protocol is designed to transit firewalls easily, perform well
where latency is high and bandwidth is low, and scale to very where latency is high and bandwidth is low, and scale to very
large numbers of clients per server. large numbers of clients per server.
o Strong security with negotiation built into the protocol * Strong security with negotiation built into the protocol
The protocol builds on the work of the ONCRPC working group in The protocol builds on the work of the ONCRPC working group in
supporting the RPCSEC_GSS protocol. Additionally, the NFSv4.1 supporting the RPCSEC_GSS protocol. Additionally, the NFSv4.1
protocol provides a mechanism to allow clients and servers the protocol provides a mechanism to allow clients and servers the
ability to negotiate security and require clients and servers to ability to negotiate security and require clients and servers to
support a minimal set of security schemes. support a minimal set of security schemes.
o Good cross-platform interoperability * Good cross-platform interoperability
The protocol features a file system model that provides a useful, The protocol features a file system model that provides a useful,
common set of features that does not unduly favor one file system common set of features that does not unduly favor one file system
or operating system over another. or operating system over another.
o Designed for protocol extensions * Designed for protocol extensions
The protocol is designed to accept standard extensions within a The protocol is designed to accept standard extensions within a
framework that enables and encourages backward compatibility. framework that enables and encourages backward compatibility.
1.6. NFSv4.1 Goals 1.6. NFSv4.1 Goals
NFSv4.1 has the following goals, within the framework established by NFSv4.1 has the following goals, within the framework established by
the overall NFSv4 goals. the overall NFSv4 goals.
o To correct significant structural weaknesses and oversights * To correct significant structural weaknesses and oversights
discovered in the base protocol. discovered in the base protocol.
o To add clarity and specificity to areas left unaddressed or not * To add clarity and specificity to areas left unaddressed or not
addressed in sufficient detail in the base protocol. However, as addressed in sufficient detail in the base protocol. However, as
stated in Section 1.4, it is not a goal to clarify the NFSv4.0 stated in Section 1.4, it is not a goal to clarify the NFSv4.0
protocol in the NFSv4.1 specification. protocol in the NFSv4.1 specification.
o To add specific features based on experience with the existing * To add specific features based on experience with the existing
protocol and recent industry developments. protocol and recent industry developments.
o To provide protocol support to take advantage of clustered server * To provide protocol support to take advantage of clustered server
deployments including the ability to provide scalable parallel deployments including the ability to provide scalable parallel
access to files distributed among multiple servers. access to files distributed among multiple servers.
1.7. General Definitions 1.7. General Definitions
The following definitions provide an appropriate context for the The following definitions provide an appropriate context for the
reader. reader.
Byte: In this document, a byte is an octet, i.e., a datum exactly 8 Byte: In this document, a byte is an octet, i.e., a datum exactly 8
bits in length. bits in length.
skipping to change at page 13, line 14 skipping to change at line 579
Server: The Server is the entity responsible for coordinating client Server: The Server is the entity responsible for coordinating client
access to a set of file systems and is identified by a server access to a set of file systems and is identified by a server
owner. A server can span multiple network addresses. owner. A server can span multiple network addresses.
Server Owner: The server owner identifies the server to the client. Server Owner: The server owner identifies the server to the client.
The server owner consists of a major identifier and a minor The server owner consists of a major identifier and a minor
identifier. When the client has two connections each to a peer identifier. When the client has two connections each to a peer
with the same major identifier, the client assumes that both peers with the same major identifier, the client assumes that both peers
are the same server (the server namespace is the same via each are the same server (the server namespace is the same via each
connection) and that lock state is sharable across both connection) and that lock state is shareable across both
connections. When each peer has both the same major and minor connections. When each peer has both the same major and minor
identifiers, the client assumes that each connection might be identifiers, the client assumes that each connection might be
associable with the same session. associable with the same session.
Stable Storage: Stable storage is storage from which data stored by Stable Storage: Stable storage is storage from which data stored by
an NFSv4.1 server can be recovered without data loss from multiple an NFSv4.1 server can be recovered without data loss from multiple
power failures (including cascading power failures, that is, power failures (including cascading power failures, that is,
several power failures in quick succession), operating system several power failures in quick succession), operating system
failures, and/or hardware failure of components other than the failures, and/or hardware failure of components other than the
storage medium itself (such as disk, nonvolatile RAM, flash storage medium itself (such as disk, nonvolatile RAM, flash
skipping to change at page 16, line 21 skipping to change at line 726
filehandles. filehandles.
1.8.3.2. File Attributes 1.8.3.2. File Attributes
The NFSv4.1 protocol has a rich and extensible file object attribute The NFSv4.1 protocol has a rich and extensible file object attribute
structure, which is divided into REQUIRED, RECOMMENDED, and named structure, which is divided into REQUIRED, RECOMMENDED, and named
attributes (see Section 5). attributes (see Section 5).
Several (but not all) of the REQUIRED attributes are derived from the Several (but not all) of the REQUIRED attributes are derived from the
attributes of NFSv3 (see the definition of the fattr3 data type in attributes of NFSv3 (see the definition of the fattr3 data type in
[37]). An example of a REQUIRED attribute is the file object's type [38]). An example of a REQUIRED attribute is the file object's type
(Section 5.8.1.2) so that regular files can be distinguished from (Section 5.8.1.2) so that regular files can be distinguished from
directories (also known as folders in some operating environments) directories (also known as folders in some operating environments)
and other types of objects. REQUIRED attributes are discussed in and other types of objects. REQUIRED attributes are discussed in
Section 5.1. Section 5.1.
An example of three RECOMMENDED attributes are acl, sacl, and dacl. An example of three RECOMMENDED attributes are acl, sacl, and dacl.
These attributes define an Access Control List (ACL) on a file object These attributes define an Access Control List (ACL) on a file object
(Section 6). An ACL provides directory and file access control (Section 6). An ACL provides directory and file access control
beyond the model used in NFSv3. The ACL definition allows for beyond the model used in NFSv3. The ACL definition allows for
specification of specific sets of permissions for individual users specification of specific sets of permissions for individual users
skipping to change at page 16, line 50 skipping to change at line 755
application-specific data with a regular file or directory. NFSv4.1 application-specific data with a regular file or directory. NFSv4.1
modifies named attributes relative to NFSv4.0 by tightening the modifies named attributes relative to NFSv4.0 by tightening the
allowed operations in order to prevent the development of non- allowed operations in order to prevent the development of non-
interoperable implementations. Named attributes are discussed in interoperable implementations. Named attributes are discussed in
Section 5.3. Section 5.3.
1.8.3.3. Multi-Server Namespace 1.8.3.3. Multi-Server Namespace
NFSv4.1 contains a number of features to allow implementation of NFSv4.1 contains a number of features to allow implementation of
namespaces that cross server boundaries and that allow and facilitate namespaces that cross server boundaries and that allow and facilitate
a non-disruptive transfer of support for individual file systems a nondisruptive transfer of support for individual file systems
between servers. They are all based upon attributes that allow one between servers. They are all based upon attributes that allow one
file system to specify alternate, additional, and new location file system to specify alternate, additional, and new location
information that specifies how the client may access that file information that specifies how the client may access that file
system. system.
These attributes can be used to provide for individual active file These attributes can be used to provide for individual active file
systems: systems:
o Alternate network addresses to access the current file system * Alternate network addresses to access the current file system
instance. instance.
o The locations of alternate file system instances or replicas to be * The locations of alternate file system instances or replicas to be
used in the event that the current file system instance becomes used in the event that the current file system instance becomes
unavailable. unavailable.
These file system location attributes may be used together with the These file system location attributes may be used together with the
concept of absent file systems, in which a position in the server concept of absent file systems, in which a position in the server
namespace is associated with locations on other servers without there namespace is associated with locations on other servers without there
being any corresponding file system instance on the current server. being any corresponding file system instance on the current server.
For example, For example,
o These attributes may be used with absent file systems to implement * These attributes may be used with absent file systems to implement
referrals whereby one server may direct the client to a file referrals whereby one server may direct the client to a file
system provided by another server. This allows extensive multi- system provided by another server. This allows extensive multi-
server namespaces to be constructed. server namespaces to be constructed.
o These attributes may be provided when a previously present file * These attributes may be provided when a previously present file
system becomes absent. This allows non-disruptive migration of system becomes absent. This allows nondisruptive migration of
file systems to alternate servers. file systems to alternate servers.
1.8.4. Locking Facilities 1.8.4. Locking Facilities
As mentioned previously, NFSv4.1 is a single protocol that includes As mentioned previously, NFSv4.1 is a single protocol that includes
locking facilities. These locking facilities include support for locking facilities. These locking facilities include support for
many types of locks including a number of sorts of recallable locks. many types of locks including a number of sorts of recallable locks.
Recallable locks such as delegations allow the client to be assured Recallable locks such as delegations allow the client to be assured
that certain events will not occur so long as that lock is held. that certain events will not occur so long as that lock is held.
When circumstances change, the lock is recalled via a callback When circumstances change, the lock is recalled via a callback
request. The assurances provided by delegations allow more extensive request. The assurances provided by delegations allow more extensive
caching to be done safely when circumstances allow it. caching to be done safely when circumstances allow it.
The types of locks are: The types of locks are:
o Share reservations as established by OPEN operations. * Share reservations as established by OPEN operations.
o Byte-range locks. * Byte-range locks.
o File delegations, which are recallable locks that assure the * File delegations, which are recallable locks that assure the
holder that inconsistent opens and file changes cannot occur so holder that inconsistent opens and file changes cannot occur so
long as the delegation is held. long as the delegation is held.
o Directory delegations, which are recallable locks that assure the * Directory delegations, which are recallable locks that assure the
holder that inconsistent directory modifications cannot occur so holder that inconsistent directory modifications cannot occur so
long as the delegation is held. long as the delegation is held.
o Layouts, which are recallable objects that assure the holder that * Layouts, which are recallable objects that assure the holder that
direct access to the file data may be performed directly by the direct access to the file data may be performed directly by the
client and that no change to the data's location that is client and that no change to the data's location that is
inconsistent with that access may be made so long as the layout is inconsistent with that access may be made so long as the layout is
held. held.
All locks for a given client are tied together under a single client- All locks for a given client are tied together under a single client-
wide lease. All requests made on sessions associated with the client wide lease. All requests made on sessions associated with the client
renew that lease. When the client's lease is not promptly renewed, renew that lease. When the client's lease is not promptly renewed,
the client's locks are subject to revocation. In the event of server the client's locks are subject to revocation. In the event of server
restart, clients have the opportunity to safely reclaim their locks restart, clients have the opportunity to safely reclaim their locks
within a special grace period. within a special grace period.
1.9. Differences from NFSv4.0 1.9. Differences from NFSv4.0
The following summarizes the major differences between minor version The following summarizes the major differences between minor version
1 and the base protocol: 1 and the base protocol:
o Implementation of the sessions model (Section 2.10). * Implementation of the sessions model (Section 2.10).
o Parallel access to data (Section 12). * Parallel access to data (Section 12).
o Addition of the RECLAIM_COMPLETE operation to better structure the * Addition of the RECLAIM_COMPLETE operation to better structure the
lock reclamation process (Section 18.51). lock reclamation process (Section 18.51).
o Enhanced delegation support as follows. * Enhanced delegation support as follows.
* Delegations on directories and other file types in addition to - Delegations on directories and other file types in addition to
regular files (Section 18.39, Section 18.49). regular files (Section 18.39, Section 18.49).
* Operations to optimize acquisition of recalled or denied - Operations to optimize acquisition of recalled or denied
delegations (Section 18.49, Section 20.5, Section 20.7). delegations (Section 18.49, Section 20.5, Section 20.7).
* Notifications of changes to files and directories - Notifications of changes to files and directories
(Section 18.39, Section 20.4). (Section 18.39, Section 20.4).
* A method to allow a server to indicate that it is recalling one - A method to allow a server to indicate that it is recalling one
or more delegations for resource management reasons, and thus a or more delegations for resource management reasons, and thus a
method to allow the client to pick which delegations to return method to allow the client to pick which delegations to return
(Section 20.6). (Section 20.6).
o Attributes can be set atomically during exclusive file create via * Attributes can be set atomically during exclusive file create via
the OPEN operation (see the new EXCLUSIVE4_1 creation method in the OPEN operation (see the new EXCLUSIVE4_1 creation method in
Section 18.16). Section 18.16).
o Open files can be preserved if removed and the hard link count * Open files can be preserved if removed and the hard link count
("hard link" is defined in an Open Group [6] standard) goes to ("hard link" is defined in an Open Group [6] standard) goes to
zero, thus obviating the need for clients to rename deleted files zero, thus obviating the need for clients to rename deleted files
to partially hidden names -- colloquially called "silly rename" to partially hidden names -- colloquially called "silly rename"
(see the new OPEN4_RESULT_PRESERVE_UNLINKED reply flag in (see the new OPEN4_RESULT_PRESERVE_UNLINKED reply flag in
Section 18.16). Section 18.16).
o Improved compatibility with Microsoft Windows for Access Control * Improved compatibility with Microsoft Windows for Access Control
Lists (Section 6.2.3, Section 6.2.2, Section 6.4.3.2). Lists (Section 6.2.3, Section 6.2.2, Section 6.4.3.2).
o Data retention (Section 5.13). * Data retention (Section 5.13).
o Identification of the implementation of the NFS client and server * Identification of the implementation of the NFS client and server
(Section 18.35). (Section 18.35).
o Support for notification of the availability of byte-range locks * Support for notification of the availability of byte-range locks
(see the new OPEN4_RESULT_MAY_NOTIFY_LOCK reply flag in (see the new OPEN4_RESULT_MAY_NOTIFY_LOCK reply flag in
Section 18.16 and see Section 20.11). Section 18.16 and see Section 20.11).
o In NFSv4.1, LIPKEY and SPKM-3 are not required security mechanisms * In NFSv4.1, LIPKEY and SPKM-3 are not required security mechanisms
[38]. [39].
2. Core Infrastructure 2. Core Infrastructure
2.1. Introduction 2.1. Introduction
NFSv4.1 relies on core infrastructure common to nearly every NFSv4.1 relies on core infrastructure common to nearly every
operation. This core infrastructure is described in the remainder of operation. This core infrastructure is described in the remainder of
this section. this section.
2.2. RPC and XDR 2.2. RPC and XDR
skipping to change at page 20, line 12 skipping to change at line 908
forms of RPC authentication, AUTH_SYS, had no strong authentication forms of RPC authentication, AUTH_SYS, had no strong authentication
and required a host-based authentication approach. NFSv4.1 also and required a host-based authentication approach. NFSv4.1 also
depends on RPC for basic security services and mandates RPC support depends on RPC for basic security services and mandates RPC support
for a user-based authentication model. The user-based authentication for a user-based authentication model. The user-based authentication
model has user principals authenticated by a server, and in turn the model has user principals authenticated by a server, and in turn the
server authenticated by user principals. RPC provides some basic server authenticated by user principals. RPC provides some basic
security services that are used by NFSv4.1. security services that are used by NFSv4.1.
2.2.1.1. RPC Security Flavors 2.2.1.1. RPC Security Flavors
As described in Section 7.2 ("Authentication") of [3], RPC security As described in "Authentication", Section 7 of [3], RPC security is
is encapsulated in the RPC header, via a security or authentication encapsulated in the RPC header, via a security or authentication
flavor, and information specific to the specified security flavor. flavor, and information specific to the specified security flavor.
Every RPC header conveys information used to identify and Every RPC header conveys information used to identify and
authenticate a client and server. As discussed in Section 2.2.1.1.1, authenticate a client and server. As discussed in Section 2.2.1.1.1,
some security flavors provide additional security services. some security flavors provide additional security services.
NFSv4.1 clients and servers MUST implement RPCSEC_GSS. (This NFSv4.1 clients and servers MUST implement RPCSEC_GSS. (This
requirement to implement is not a requirement to use.) Other requirement to implement is not a requirement to use.) Other
flavors, such as AUTH_NONE and AUTH_SYS, MAY be implemented as well. flavors, such as AUTH_NONE and AUTH_SYS, MAY be implemented as well.
2.2.1.1.1. RPCSEC_GSS and Security Services 2.2.1.1.1. RPCSEC_GSS and Security Services
skipping to change at page 21, line 52 skipping to change at line 995
------------------------------------------------------------------ ------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 rpc_gss_svc_none yes yes 390003 krb5 1.2.840.113554.1.2.2 rpc_gss_svc_none yes yes
390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes 390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes
390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes 390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes
Note that the number and name of the pseudo flavor are presented here Note that the number and name of the pseudo flavor are presented here
as a mapping aid to the implementor. Because the NFSv4.1 protocol as a mapping aid to the implementor. Because the NFSv4.1 protocol
includes a method to negotiate security and it understands the GSS- includes a method to negotiate security and it understands the GSS-
API mechanism, the pseudo flavor is not needed. The pseudo flavor is API mechanism, the pseudo flavor is not needed. The pseudo flavor is
needed for the NFSv3 since the security negotiation is done via the needed for the NFSv3 since the security negotiation is done via the
MOUNT protocol as described in [39]. MOUNT protocol as described in [40].
At the time NFSv4.1 was specified, the Advanced Encryption Standard At the time NFSv4.1 was specified, the Advanced Encryption Standard
(AES) with HMAC-SHA1 was a REQUIRED algorithm set for Kerberos V5. (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Kerberos V5.
In contrast, when NFSv4.0 was specified, weaker algorithm sets were In contrast, when NFSv4.0 was specified, weaker algorithm sets were
REQUIRED for Kerberos V5, and were REQUIRED in the NFSv4.0 REQUIRED for Kerberos V5, and were REQUIRED in the NFSv4.0
specification, because the Kerberos V5 specification at the time did specification, because the Kerberos V5 specification at the time did
not specify stronger algorithms. The NFSv4.1 specification does not not specify stronger algorithms. The NFSv4.1 specification does not
specify REQUIRED algorithms for Kerberos V5, and instead, the specify REQUIRED algorithms for Kerberos V5, and instead, the
implementor is expected to track the evolution of the Kerberos V5 implementor is expected to track the evolution of the Kerberos V5
standard if and when stronger algorithms are specified. standard if and when stronger algorithms are specified.
skipping to change at page 24, line 38 skipping to change at line 1126
Client identification is encapsulated in the following client owner Client identification is encapsulated in the following client owner
data type: data type:
struct client_owner4 { struct client_owner4 {
verifier4 co_verifier; verifier4 co_verifier;
opaque co_ownerid<NFS4_OPAQUE_LIMIT>; opaque co_ownerid<NFS4_OPAQUE_LIMIT>;
}; };
The first field, co_verifier, is a client incarnation verifier, The first field, co_verifier, is a client incarnation verifier,
allowing the server to distinguish successive incarnations (e.g. allowing the server to distinguish successive incarnations (e.g.,
reboots) of the same client. The server will start the process of reboots) of the same client. The server will start the process of
canceling the client's leased state if co_verifier is different than canceling the client's leased state if co_verifier is different than
what the server has previously recorded for the identified client (as what the server has previously recorded for the identified client (as
specified in the co_ownerid field). specified in the co_ownerid field).
The second field, co_ownerid, is a variable length string that The second field, co_ownerid, is a variable length string that
uniquely defines the client so that subsequent instances of the same uniquely defines the client so that subsequent instances of the same
client bear the same co_ownerid with a different verifier. client bear the same co_ownerid with a different verifier.
There are several considerations for how the client generates the There are several considerations for how the client generates the
co_ownerid string: co_ownerid string:
o The string should be unique so that multiple clients do not * The string should be unique so that multiple clients do not
present the same string. The consequences of two clients present the same string. The consequences of two clients
presenting the same string range from one client getting an error presenting the same string range from one client getting an error
to one client having its leased state abruptly and unexpectedly to one client having its leased state abruptly and unexpectedly
cancelled. cancelled.
o The string should be selected so that subsequent incarnations * The string should be selected so that subsequent incarnations
(e.g., restarts) of the same client cause the client to present (e.g., restarts) of the same client cause the client to present
the same string. The implementor is cautioned from an approach the same string. The implementor is cautioned from an approach
that requires the string to be recorded in a local file because that requires the string to be recorded in a local file because
this precludes the use of the implementation in an environment this precludes the use of the implementation in an environment
where there is no local disk and all file access is from an where there is no local disk and all file access is from an
NFSv4.1 server. NFSv4.1 server.
o The string should be the same for each server network address that * The string should be the same for each server network address that
the client accesses. This way, if a server has multiple the client accesses. This way, if a server has multiple
interfaces, the client can trunk traffic over multiple network interfaces, the client can trunk traffic over multiple network
paths as described in Section 2.10.5. (Note: the precise opposite paths as described in Section 2.10.5. (Note: the precise opposite
was advised in the NFSv4.0 specification [36].) was advised in the NFSv4.0 specification [37].)
o The algorithm for generating the string should not assume that the * The algorithm for generating the string should not assume that the
client's network address will not change, unless the client client's network address will not change, unless the client
implementation knows it is using statically assigned network implementation knows it is using statically assigned network
addresses. This includes changes between client incarnations and addresses. This includes changes between client incarnations and
even changes while the client is still running in its current even changes while the client is still running in its current
incarnation. Thus, with dynamic address assignment, if the client incarnation. Thus, with dynamic address assignment, if the client
includes just the client's network address in the co_ownerid includes just the client's network address in the co_ownerid
string, there is a real risk that after the client gives up the string, there is a real risk that after the client gives up the
network address, another client, using a similar algorithm for network address, another client, using a similar algorithm for
generating the co_ownerid string, would generate a conflicting generating the co_ownerid string, would generate a conflicting
co_ownerid string. co_ownerid string.
Given the above considerations, an example of a well-generated Given the above considerations, an example of a well-generated
co_ownerid string is one that includes: co_ownerid string is one that includes:
o If applicable, the client's statically assigned network address. * If applicable, the client's statically assigned network address.
o Additional information that tends to be unique, such as one or * Additional information that tends to be unique, such as one or
more of: more of:
* The client machine's serial number (for privacy reasons, it is - The client machine's serial number (for privacy reasons, it is
best to perform some one-way function on the serial number). best to perform some one-way function on the serial number).
* A Media Access Control (MAC) address (again, a one-way function - A Media Access Control (MAC) address (again, a one-way function
should be performed). should be performed).
* The timestamp of when the NFSv4.1 software was first installed - The timestamp of when the NFSv4.1 software was first installed
on the client (though this is subject to the previously on the client (though this is subject to the previously
mentioned caution about using information that is stored in a mentioned caution about using information that is stored in a
file, because the file might only be accessible over NFSv4.1). file, because the file might only be accessible over NFSv4.1).
* A true random number. However, since this number ought to be - A true random number. However, since this number ought to be
the same between client incarnations, this shares the same the same between client incarnations, this shares the same
problem as that of using the timestamp of the software problem as that of using the timestamp of the software
installation. installation.
o For a user-level NFSv4.1 client, it should contain additional * For a user-level NFSv4.1 client, it should contain additional
information to distinguish the client from other user-level information to distinguish the client from other user-level
clients running on the same host, such as a process identifier or clients running on the same host, such as a process identifier or
other unique sequence. other unique sequence.
The client ID is assigned by the server (the eir_clientid result from The client ID is assigned by the server (the eir_clientid result from
EXCHANGE_ID) and should be chosen so that it will not conflict with a EXCHANGE_ID) and should be chosen so that it will not conflict with a
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
skipping to change at page 27, line 26 skipping to change at line 1258
To facilitate upgrade from NFSv4.0 to NFSv4.1, a server may compare a To facilitate upgrade from NFSv4.0 to NFSv4.1, a server may compare a
value of data type client_owner4 in an EXCHANGE_ID with a value of value of data type client_owner4 in an EXCHANGE_ID with a value of
data type nfs_client_id4 that was established using the SETCLIENTID data type nfs_client_id4 that was established using the SETCLIENTID
operation of NFSv4.0. A server that does so will allow an upgraded operation of NFSv4.0. A server that does so will allow an upgraded
client to avoid waiting until the lease (i.e., the lease established client to avoid waiting until the lease (i.e., the lease established
by the NFSv4.0 instance client) expires. This requires that the by the NFSv4.0 instance client) expires. This requires that the
value of data type client_owner4 be constructed the same way as the value of data type client_owner4 be constructed the same way as the
value of data type nfs_client_id4. If the latter's contents included value of data type nfs_client_id4. If the latter's contents included
the server's network address (per the recommendations of the NFSv4.0 the server's network address (per the recommendations of the NFSv4.0
specification [36]), and the NFSv4.1 client does not wish to use a specification [37]), and the NFSv4.1 client does not wish to use a
client ID that prevents trunking, it should send two EXCHANGE_ID client ID that prevents trunking, it should send two EXCHANGE_ID
operations. The first EXCHANGE_ID will have a client_owner4 equal to operations. The first EXCHANGE_ID will have a client_owner4 equal to
the nfs_client_id4. This will clear the state created by the NFSv4.0 the nfs_client_id4. This will clear the state created by the NFSv4.0
client. The second EXCHANGE_ID will not have the server's network client. The second EXCHANGE_ID will not have the server's network
address. The state created for the second EXCHANGE_ID will not have address. The state created for the second EXCHANGE_ID will not have
to wait for lease expiration, because there will be no state to to wait for lease expiration, because there will be no state to
expire. expire.
2.4.2. Server Release of Client ID 2.4.2. Server Release of Client ID
skipping to change at page 28, line 24 skipping to change at line 1304
has no state, or that has state but the lease has expired, the server has no state, or that has state but the lease has expired, the server
MUST allow the EXCHANGE_ID and confirm the new client ID if followed MUST allow the EXCHANGE_ID and confirm the new client ID if followed
by the appropriate CREATE_SESSION. by the appropriate CREATE_SESSION.
When the server gets an EXCHANGE_ID for a new incarnation of a client When the server gets an EXCHANGE_ID for a new incarnation of a client
owner that currently has an old incarnation with state and an owner that currently has an old incarnation with state and an
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 is previous incarnation of the client owner if one of the following is
true: true:
o The principal that created the client ID for the client owner is * The principal that created the client ID for the client owner is
the same as the principal that is sending the EXCHANGE_ID the same as the principal that is sending the EXCHANGE_ID
operation. Note that if the client ID was created with operation. Note that if the client ID was created with
SP4_MACH_CRED state protection (Section 18.35), the principal MUST SP4_MACH_CRED state protection (Section 18.35), the principal MUST
be based on RPCSEC_GSS authentication, the RPCSEC_GSS service used be based on RPCSEC_GSS authentication, the RPCSEC_GSS service used
MUST be integrity or privacy, and the same GSS mechanism and MUST be integrity or privacy, and the same GSS mechanism and
principal MUST be used as that used when the client ID was principal MUST be used as that used when the client ID was
created. created.
o The client ID was established with SP4_SSV protection * 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 * 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
client sends EXCHANGE_ID to a server it does not have an SSV, the client sends EXCHANGE_ID to a server it does not have an SSV, the
client MAY send the subsequent EXCHANGE_ID without an SSV client MAY send the subsequent EXCHANGE_ID without an SSV
RPCSEC_GSS handle. Instead, as with SP4_MACH_CRED protection, the RPCSEC_GSS handle. Instead, as with SP4_MACH_CRED protection, the
principal MUST be based on RPCSEC_GSS authentication, the principal MUST be based on RPCSEC_GSS authentication, the
RPCSEC_GSS service used MUST be integrity or privacy, and the same RPCSEC_GSS service used MUST be integrity or privacy, and the same
GSS mechanism and principal MUST be used as that used when the GSS mechanism and principal MUST be used as that used when the
client ID was created. client ID was created.
skipping to change at page 34, line 51 skipping to change at line 1617
but not bFH's policy. The server returns NFS4ERR_WRONGSEC on the but not bFH's policy. The server returns NFS4ERR_WRONGSEC on the
RENAME operation. RENAME operation.
To prevent a client from an endless sequence of a request containing To prevent a client from an endless sequence of a request containing
LINK or RENAME, followed by a request containing SECINFO_NO_NAME or LINK or RENAME, followed by a request containing SECINFO_NO_NAME or
SECINFO, the server MUST detect when the security policies of the SECINFO, the server MUST detect when the security policies of the
current and saved filehandles have no mutually acceptable security current and saved filehandles have no mutually acceptable security
tuple, and MUST NOT return NFS4ERR_WRONGSEC from LINK or RENAME in tuple, and MUST NOT return NFS4ERR_WRONGSEC from LINK or RENAME in
that situation. Instead the server MUST do one of two things: that situation. Instead the server MUST do one of two things:
o The server can return NFS4ERR_XDEV. * The server can return NFS4ERR_XDEV.
o The server can allow the security policy of the current filehandle * The server can allow the security policy of the current filehandle
to override that of the saved filehandle, and so return NFS4_OK. to override that of the saved filehandle, and so return NFS4_OK.
2.7. Minor Versioning 2.7. Minor Versioning
To address the requirement of an NFS protocol that can evolve as the To address the requirement of an NFS protocol that can evolve as the
need arises, the NFSv4.1 protocol contains the rules and framework to need arises, the NFSv4.1 protocol contains the rules and framework to
allow for future minor changes or versioning. allow for future minor changes or versioning.
The base assumption with respect to minor versioning is that any The base assumption with respect to minor versioning is that any
future accepted minor version will be documented in one or more future accepted minor version will be documented in one or more
Standards Track RFCs. Minor version 0 of the NFSv4 protocol is Standards Track RFCs. Minor version 0 of the NFSv4 protocol is
represented by [36], and minor version 1 is represented by this RFC. represented by [37], and minor version 1 is represented by this RFC.
The COMPOUND and CB_COMPOUND procedures support the encoding of the The COMPOUND and CB_COMPOUND procedures support the encoding of the
minor version being requested by the client. minor version being requested by the client.
The following items represent the basic rules for the development of The following items represent the basic rules for the development of
minor versions. Note that a future minor version may modify or add minor versions. Note that a future minor version may modify or add
to the following rules as part of the minor version definition. to the following rules as part of the minor version definition.
1. Procedures are not added or deleted. 1. Procedures are not added or deleted.
To maintain the general RPC model, NFSv4 minor versions will not To maintain the general RPC model, NFSv4 minor versions will not
skipping to change at page 38, line 22 skipping to change at line 1782
this specification to specify heuristics for detecting intrusion via this specification to specify heuristics for detecting intrusion via
alarms. alarms.
2.9. Transport Layers 2.9. Transport Layers
2.9.1. REQUIRED and RECOMMENDED Properties of Transports 2.9.1. REQUIRED and RECOMMENDED Properties of Transports
NFSv4.1 works over Remote Direct Memory Access (RDMA) and non-RDMA- NFSv4.1 works over Remote Direct Memory Access (RDMA) and non-RDMA-
based transports with the following attributes: based transports with the following attributes:
o The transport supports reliable delivery of data, which NFSv4.1 * The transport supports reliable delivery of data, which NFSv4.1
requires but neither NFSv4.1 nor RPC has facilities for ensuring requires but neither NFSv4.1 nor RPC has facilities for ensuring
[40]. [41].
o The transport delivers data in the order it was sent. Ordered * The transport delivers data in the order it was sent. Ordered
delivery simplifies detection of transmit errors, and simplifies delivery simplifies detection of transmit errors, and simplifies
the sending of arbitrary sized requests and responses via the the sending of arbitrary sized requests and responses via the
record marking protocol [3]. record marking protocol [3].
Where an NFSv4.1 implementation supports operation over the IP Where an NFSv4.1 implementation supports operation over the IP
network protocol, any transport used between NFS and IP MUST be among network protocol, any transport used between NFS and IP MUST be among
the IETF-approved congestion control transport protocols. At the the IETF-approved congestion control transport protocols. At the
time this document was written, the only two transports that had the time this document was written, the only two transports that had the
above attributes were TCP and the Stream Control Transmission above attributes were TCP and the Stream Control Transmission
Protocol (SCTP). To enhance the possibilities for interoperability, Protocol (SCTP). To enhance the possibilities for interoperability,
skipping to change at page 39, line 24 skipping to change at line 1831
2. This will improve performance for the WAN environment by 2. This will improve performance for the WAN environment by
eliminating the need for connection setup handshakes. eliminating the need for connection setup handshakes.
3. The NFSv4.1 callback model differs from NFSv4.0, and requires the 3. The NFSv4.1 callback model differs from NFSv4.0, and requires the
client and server to maintain a client-created backchannel (see client and server to maintain a client-created backchannel (see
Section 2.10.3.1) for the server to use. Section 2.10.3.1) for the server to use.
In order to reduce congestion, if a connection-oriented transport is In order to reduce congestion, if a connection-oriented transport is
used, and the request is not the NULL procedure: used, and the request is not the NULL procedure:
o A requester MUST NOT retry a request unless the connection the * A requester MUST NOT retry a request unless the connection the
request was sent over was lost before the reply was received. request was sent over was lost before the reply was received.
o A replier MUST NOT silently drop a request, even if the request is * A replier MUST NOT silently drop a request, even if the request is
a retry. (The silent drop behavior of RPCSEC_GSS [4] does not a retry. (The silent drop behavior of RPCSEC_GSS [4] does not
apply because this behavior happens at the RPCSEC_GSS layer, a apply because this behavior happens at the RPCSEC_GSS layer, a
lower layer in the request processing.) Instead, the replier lower layer in the request processing.) Instead, the replier
SHOULD return an appropriate error (see Section 2.10.6.1), or it SHOULD return an appropriate error (see Section 2.10.6.1), or it
MAY disconnect the connection. MAY disconnect the connection.
When sending a reply, the replier MUST send the reply to the same When sending a reply, the replier MUST send the reply to the same
full network address (e.g., if using an IP-based transport, the full network address (e.g., if using an IP-based transport, the
source port of the requester is part of the full network address) source port of the requester is part of the full network address)
from which the requester sent the request. If using a connection- from which the requester sent the request. If using a connection-
skipping to change at page 40, line 5 skipping to change at line 1860
reply. If a connection is established with the same source and reply. If a connection is established with the same source and
destination full network address as the dropped connection, then the destination full network address as the dropped connection, then the
replier MUST NOT send the reply until the requester retries the replier MUST NOT send the reply until the requester retries the
request. The reason for this prohibition is that the requester MAY request. The reason for this prohibition is that the requester MAY
retry a request over a different connection (provided that connection retry a request over a different connection (provided that connection
is associated with the original request's session). is associated with the original request's session).
When using RDMA transports, there are other reasons for not When using RDMA transports, there are other reasons for not
tolerating retries over the same connection: tolerating retries over the same connection:
o RDMA transports use "credits" to enforce flow control, where a * RDMA transports use "credits" to enforce flow control, where a
credit is a right to a peer to transmit a message. If one peer credit is a right to a peer to transmit a message. If one peer
were to retransmit a request (or reply), it would consume an were to retransmit a request (or reply), it would consume an
additional credit. If the replier retransmitted a reply, it would additional credit. If the replier retransmitted a reply, it would
certainly result in an RDMA connection loss, since the requester certainly result in an RDMA connection loss, since the requester
would typically only post a single receive buffer for each would typically only post a single receive buffer for each
request. If the requester retransmitted a request, the additional request. If the requester retransmitted a request, the additional
credit consumed on the server might lead to RDMA connection credit consumed on the server might lead to RDMA connection
failure unless the client accounted for it and decreased its failure unless the client accounted for it and decreased its
available credit, leading to wasted resources. available credit, leading to wasted resources.
o RDMA credits present a new issue to the reply cache in NFSv4.1. * RDMA credits present a new issue to the reply cache in NFSv4.1.
The reply cache may be used when a connection within a session is The reply cache may be used when a connection within a session is
lost, such as after the client reconnects. Credit information is lost, such as after the client reconnects. Credit information is
a dynamic property of the RDMA connection, and stale values must a dynamic property of the RDMA connection, and stale values must
not be replayed from the cache. This implies that the reply cache not be replayed from the cache. This implies that the reply cache
contents must not be blindly used when replies are sent from it, contents must not be blindly used when replies are sent from it,
and credit information appropriate to the channel must be and credit information appropriate to the channel must be
refreshed by the RPC layer. refreshed by the RPC layer.
In addition, as described in Section 2.10.6.2, while a session is In addition, as described in Section 2.10.6.2, while a session is
active, the NFSv4.1 requester MUST NOT stop waiting for a reply. active, the NFSv4.1 requester MUST NOT stop waiting for a reply.
2.9.3. Ports 2.9.3. Ports
Historically, NFSv3 servers have listened over TCP port 2049. The Historically, NFSv3 servers have listened over TCP port 2049. The
registered port 2049 [41] for the NFS protocol should be the default registered port 2049 [42] for the NFS protocol should be the default
configuration. NFSv4.1 clients SHOULD NOT use the RPC binding configuration. NFSv4.1 clients SHOULD NOT use the RPC binding
protocols as described in [42]. protocols as described in [43].
2.10. Session 2.10. Session
NFSv4.1 clients and servers MUST support and MUST use the session NFSv4.1 clients and servers MUST support and MUST use the session
feature as described in this section. feature as described in this section.
2.10.1. Motivation and Overview 2.10.1. Motivation and Overview
Previous versions and minor versions of NFS have suffered from the Previous versions and minor versions of NFS have suffered from the
following: following:
o Lack of support for Exactly Once Semantics (EOS). This includes * Lack of support for Exactly Once Semantics (EOS). This includes
lack of support for EOS through server failure and recovery. lack of support for EOS through server failure and recovery.
o Limited callback support, including no support for sending * Limited callback support, including no support for sending
callbacks through firewalls, and races between replies to normal callbacks through firewalls, and races between replies to normal
requests and callbacks. requests and callbacks.
o Limited trunking over multiple network paths. * Limited trunking over multiple network paths.
o Requiring machine credentials for fully secure operation. * Requiring machine credentials for fully secure operation.
Through the introduction of a session, NFSv4.1 addresses the above Through the introduction of a session, NFSv4.1 addresses the above
shortfalls with practical solutions: shortfalls with practical solutions:
o EOS is enabled by a reply cache with a bounded size, making it * EOS is enabled by a reply cache with a bounded size, making it
feasible to keep the cache in persistent storage and enable EOS feasible to keep the cache in persistent storage and enable EOS
through server failure and recovery. One reason that previous through server failure and recovery. One reason that previous
revisions of NFS did not support EOS was because some EOS revisions of NFS did not support EOS was because some EOS
approaches often limited parallelism. As will be explained in approaches often limited parallelism. As will be explained in
Section 2.10.6, NFSv4.1 supports both EOS and unlimited Section 2.10.6, NFSv4.1 supports both EOS and unlimited
parallelism. parallelism.
o The NFSv4.1 client (defined in Section 1.7, Paragraph 2) creates * The NFSv4.1 client (defined in Section 1.7) creates transport
transport connections and provides them to the server to use for connections and provides them to the server to use for sending
sending callback requests, thus solving the firewall issue callback requests, thus solving the firewall issue
(Section 18.34). Races between responses from client requests and (Section 18.34). Races between responses from client requests and
callbacks caused by the requests are detected via the session's callbacks caused by the requests are detected via the session's
sequencing properties that are a consequence of EOS sequencing properties that are a consequence of EOS
(Section 2.10.6.3). (Section 2.10.6.3).
o The NFSv4.1 client can associate an arbitrary number of * The NFSv4.1 client can associate an arbitrary number of
connections with the session, and thus provide trunking connections with the session, and thus provide trunking
(Section 2.10.5). (Section 2.10.5).
o The NFSv4.1 client and server produce a session key independent of * The NFSv4.1 client and server produce a session key independent of
client and server machine credentials which can be used to compute client and server machine credentials which can be used to compute
a digest for protecting critical session management operations a digest for protecting critical session management operations
(Section 2.10.8.3). (Section 2.10.8.3).
o The NFSv4.1 client can also create secure RPCSEC_GSS contexts for * The NFSv4.1 client can also create secure RPCSEC_GSS contexts for
use by the session's backchannel that do not require the server to use by the session's backchannel that do not require the server to
authenticate to a client machine principal (Section 2.10.8.2). authenticate to a client machine principal (Section 2.10.8.2).
A session is a dynamically created, long-lived server object created A session is a dynamically created, long-lived server object created
by a client and used over time from one or more transport by a client and used over time from one or more transport
connections. Its function is to maintain the server's state relative connections. Its function is to maintain the server's state relative
to the connection(s) belonging to a client instance. This state is to the connection(s) belonging to a client instance. This state is
entirely independent of the connection itself, and indeed the state entirely independent of the connection itself, and indeed the state
exists whether or not the connection exists. A client may have one exists whether or not the connection exists. A client may have one
or more sessions associated with it so that client-associated state or more sessions associated with it so that client-associated state
skipping to change at page 44, line 8 skipping to change at line 2055
The backchannel is used for callback requests from server to client, The backchannel is used for callback requests from server to client,
and carries CB_COMPOUND requests and responses. Whether or not there and carries CB_COMPOUND requests and responses. Whether or not there
is a backchannel is decided by the client; however, many features of is a backchannel is decided by the client; however, many features of
NFSv4.1 require a backchannel. NFSv4.1 servers MUST support NFSv4.1 require a backchannel. NFSv4.1 servers MUST support
backchannels. backchannels.
Each session has resources for each channel, including separate reply Each session has resources for each channel, including separate reply
caches (see Section 2.10.6.1). Note that even the backchannel caches (see Section 2.10.6.1). Note that even the backchannel
requires a reply cache (or, at least, a slot table in order to detect requires a reply cache (or, at least, a slot table in order to detect
retries) because some callback operations are nonidempotent. retries) because some callback operations are non-idempotent.
2.10.3.1. Association of Connections, Channels, and Sessions 2.10.3.1. Association of Connections, Channels, and Sessions
Each channel is associated with zero or more transport connections Each channel is associated with zero or more transport connections
(whether of the same transport protocol or different transport (whether of the same transport protocol or different transport
protocols). A connection can be associated with one channel or both protocols). A connection can be associated with one channel or both
channels of a session; the client and server negotiate whether a channels of a session; the client and server negotiate whether a
connection will carry traffic for one channel or both channels via connection will carry traffic for one channel or both channels via
the CREATE_SESSION (Section 18.36) and the BIND_CONN_TO_SESSION the CREATE_SESSION (Section 18.36) and the BIND_CONN_TO_SESSION
(Section 18.34) operations. When a session is created via (Section 18.34) operations. When a session is created via
skipping to change at page 45, line 21 skipping to change at line 2117
The use of such compatible values does not imply that a value The use of such compatible values does not imply that a value
generated by one server will always be accepted by another. In most generated by one server will always be accepted by another. In most
cases, it will not. However, a server will not inadvertently accept cases, it will not. However, a server will not inadvertently accept
a value generated by another server. When it does accept it, it will a value generated by another server. When it does accept it, it will
be because it is recognized as valid and carrying the same meaning as be because it is recognized as valid and carrying the same meaning as
on another server of the same scope. on another server of the same scope.
When servers are of the same server scope, this compatibility of When servers are of the same server scope, this compatibility of
values applies to the following identifiers: values applies to the following identifiers:
o Filehandle values. A filehandle value accepted by two servers of * Filehandle values. A filehandle value accepted by two servers of
the same server scope denotes the same object. A WRITE operation the same server scope denotes the same object. A WRITE operation
sent to one server is reflected immediately in a READ sent to the sent to one server is reflected immediately in a READ sent to the
other. other.
o Server owner values. When the server scope values are the same, * Server owner values. When the server scope values are the same,
server owner value may be validly compared. In cases where the server owner value may be validly compared. In cases where the
server scope values are different, server owner values are treated server scope values are different, server owner values are treated
as different even if they contain identical strings of bytes. as different even if they contain identical strings of bytes.
The coordination among servers required to provide such compatibility The coordination among servers required to provide such compatibility
can be quite minimal, and limited to a simple partition of the ID can be quite minimal, and limited to a simple partition of the ID
space. The recognition of common values requires additional space. The recognition of common values requires additional
implementation, but this can be tailored to the specific situations implementation, but this can be tailored to the specific situations
in which that recognition is desired. in which that recognition is desired.
Clients will have occasion to compare the server scope values of Clients will have occasion to compare the server scope values of
multiple servers under a number of circumstances, each of which will multiple servers under a number of circumstances, each of which will
be discussed under the appropriate functional section: be discussed under the appropriate functional section:
o When server owner values received in response to EXCHANGE_ID * When server owner values received in response to EXCHANGE_ID
operations sent to multiple network addresses are compared for the operations sent to multiple network addresses are compared for the
purpose of determining the validity of various forms of trunking, purpose of determining the validity of various forms of trunking,
as described in Section 11.5.2. . as described in Section 11.5.2.
o When network or server reconfiguration causes the same network * When network or server reconfiguration causes the same network
address to possibly be directed to different servers, with the address to possibly be directed to different servers, with the
necessity for the client to determine when lock reclaim should be necessity for the client to determine when lock reclaim should be
attempted, as described in Section 8.4.2.1. attempted, as described in Section 8.4.2.1.
When two replies from EXCHANGE_ID, each from two different server When two replies from EXCHANGE_ID, each from two different server
network addresses, have the same server scope, there are a number of network addresses, have the same server scope, there are a number of
ways a client can validate that the common server scope is due to two ways a client can validate that the common server scope is due to two
servers cooperating in a group. servers cooperating in a group.
o If both EXCHANGE_ID requests were sent with RPCSEC_GSS ([4], [9], * If both EXCHANGE_ID requests were sent with RPCSEC_GSS ([4], [9],
[27]) authentication and the server principal is the same for both [27]) authentication and the server principal is the same for both
targets, the equality of server scope is validated. It is targets, the equality of server scope is validated. It is
RECOMMENDED that two servers intending to share the same server RECOMMENDED that two servers intending to share the same server
scope and server_owner major_id also share the same principal scope and server_owner major_id also share the same principal
name. In some cases, this simplifies the client's task of name. In some cases, this simplifies the client's task of
validating server scope. validating server scope.
o The client may accept the appearance of the second server in the * The client may accept the appearance of the second server in the
fs_locations or fs_locations_info attribute for a relevant file fs_locations or fs_locations_info attribute for a relevant file
system. For example, if there is a migration event for a system. For example, if there is a migration event for a
particular file system or there are locks to be reclaimed on a particular file system or there are locks to be reclaimed on a
particular file system, the attributes for that particular file particular file system, the attributes for that particular file
system may be used. The client sends the GETATTR request to the system may be used. The client sends the GETATTR request to the
first server for the fs_locations or fs_locations_info attribute first server for the fs_locations or fs_locations_info attribute
with RPCSEC_GSS authentication. It may need to do this in advance with RPCSEC_GSS authentication. It may need to do this in advance
of the need to verify the common server scope. If the client of the need to verify the common server scope. If the client
successfully authenticates the reply to GETATTR, and the GETATTR successfully authenticates the reply to GETATTR, and the GETATTR
request and reply containing the fs_locations or fs_locations_info request and reply containing the fs_locations or fs_locations_info
skipping to change at page 46, line 42 skipping to change at line 2184
system involved (e.g. a file system being migrated). system involved (e.g. a file system being migrated).
2.10.5. Trunking 2.10.5. Trunking
Trunking is the use of multiple connections between a client and Trunking is the use of multiple connections between a client and
server in order to increase the speed of data transfer. NFSv4.1 server in order to increase the speed of data transfer. NFSv4.1
supports two types of trunking: session trunking and client ID supports two types of trunking: session trunking and client ID
trunking. trunking.
In the context of a single server network address, it can be assumed In the context of a single server network address, it can be assumed
that all connections are accessing the same server and NFSv4.1 that all connections are accessing the same server, and NFSv4.1
servers MUST support both forms of trunking. When multiple servers MUST support both forms of trunking. When multiple
connections use a set of network addresses accessing the same server, connections use a set of network addresses to access the same server,
the server MUST support both forms of trunking. NFSv4.1 servers in a the server MUST support both forms of trunking. NFSv4.1 servers in a
clustered configuration MAY allow network addresses for different clustered configuration MAY allow network addresses for different
servers to use client ID trunking. servers to use client ID trunking.
Clients may use either form of trunking as long as they do not, when Clients may use either form of trunking as long as they do not, when
trunking between different server network addresses, violate the trunking between different server network addresses, violate the
servers' mandates as to the kinds of trunking to be allowed (see servers' mandates as to the kinds of trunking to be allowed (see
below). With regard to callback channels, the client MUST allow the below). With regard to callback channels, the client MUST allow the
server to choose among all callback channels valid for a given client server to choose among all callback channels valid for a given client
ID and MUST support trunking when the connections supporting the ID and MUST support trunking when the connections supporting the
skipping to change at page 48, line 39 skipping to change at line 2278
When doing client ID trunking, locking state is shared across When doing client ID trunking, locking state is shared across
sessions associated with that same client ID. This requires the sessions associated with that same client ID. This requires the
server to coordinate state across sessions and the client to be server to coordinate state across sessions and the client to be
able to associate the same locking state with multiple sessions. able to associate the same locking state with multiple sessions.
It is always possible that, as a result of various sorts of It is always possible that, as a result of various sorts of
reconfiguration events, eir_server_scope and eir_server_owner values reconfiguration events, eir_server_scope and eir_server_owner values
may be different on subsequent EXCHANGE_ID requests made to the same may be different on subsequent EXCHANGE_ID requests made to the same
network address. network address.
In most cases such reconfiguration events will be disruptive and In most cases, such reconfiguration events will be disruptive and
indicate that an IP address formerly connected to one server is now indicate that an IP address formerly connected to one server is now
connected to an entirely different one. connected to an entirely different one.
Some guidelines on client handling of such situations follow: Some guidelines on client handling of such situations follow:
o When eir_server_scope changes, the client has no assurance that * When eir_server_scope changes, the client has no assurance that
any id's it obtained previously (e.g. file handles) can be validly any IDs that it obtained previously (e.g., filehandles) can be
used on the new server, and, even if the new server accepts them, validly used on the new server, and, even if the new server
there is no assurance that this is not due to accident. Thus, it accepts them, there is no assurance that this is not due to
is best to treat all such state as lost/stale although a client accident. Thus, it is best to treat all such state as lost or
may assume that the probability of inadvertent acceptance is low stale, although a client may assume that the probability of
and treat this situation as within the next case. inadvertent acceptance is low and treat this situation as within
the next case.
o When eir_server_scope remains the same and * When eir_server_scope remains the same and
eir_server_owner.so_major_id changes, the client can use the eir_server_owner.so_major_id changes, the client can use the
filehandles it has, consider its locking state lost, and attempt filehandles it has, consider its locking state lost, and attempt
to reclaim or otherwise re-obtain its locks. It might find that to reclaim or otherwise re-obtain its locks. It might find that
its file handle is now stale. However, if NFS4ERR_STALE is not its filehandle is now stale. However, if NFS4ERR_STALE is not
returned, it can proceed to reclaim or otherwise re-obtain its returned, it can proceed to reclaim or otherwise re-obtain its
open locking state. open locking state.
o When eir_server_scope and eir_server_owner.so_major_id remain the * When eir_server_scope and eir_server_owner.so_major_id remain the
same, the client has to use the now-current values of same, the client has to use the now-current values of
eir_server_owner.so_minor_id in deciding on appropriate forms of eir_server_owner.so_minor_id in deciding on appropriate forms of
trunking. This may result in connections being dropped or new trunking. This may result in connections being dropped or new
sessions being created. sessions being created.
2.10.5.1. Verifying Claims of Matching Server Identity 2.10.5.1. Verifying Claims of Matching Server Identity
When the server responds using two different connections claiming When the server responds using two different connections that claim
matching or partially matching eir_server_owner, eir_server_scope, matching or partially matching eir_server_owner, eir_server_scope,
and eir_clientid values, the client does not have to trust the and eir_clientid values, the client does not have to trust the
servers' claims. The client may verify these claims before trunking servers' claims. The client may verify these claims before trunking
traffic in the following ways: traffic in the following ways:
o For session trunking, clients SHOULD reliably verify if * For session trunking, clients SHOULD reliably verify if
connections between different network paths are in fact associated connections between different network paths are in fact associated
with the same NFSv4.1 server and usable on the same session, and with the same NFSv4.1 server and usable on the same session, and
servers MUST allow clients to perform reliable verification. When servers MUST allow clients to perform reliable verification. When
a client ID is created, the client SHOULD specify that a client ID is created, the client SHOULD specify that
BIND_CONN_TO_SESSION is to be verified according to the SP4_SSV or BIND_CONN_TO_SESSION is to be verified according to the SP4_SSV or
SP4_MACH_CRED (Section 18.35) state protection options. For SP4_MACH_CRED (Section 18.35) state protection options. For
SP4_SSV, reliable verification depends on a shared secret (the SP4_SSV, reliable verification depends on a shared secret (the
SSV) that is established via the SET_SSV (see Section 18.47) SSV) that is established via the SET_SSV (see Section 18.47)
operation. operation.
skipping to change at page 50, line 17 skipping to change at line 2351
not be verified by the client, so the client will know it cannot not be verified by the client, so the client will know it cannot
use the connection for trunking the specified session. use the connection for trunking the specified session.
If the client specified SP4_MACH_CRED state protection, the If the client specified SP4_MACH_CRED state protection, the
BIND_CONN_TO_SESSION operation will use RPCSEC_GSS integrity or BIND_CONN_TO_SESSION operation will use RPCSEC_GSS integrity or
privacy, using the same credential that was used when the client privacy, using the same credential that was used when the client
ID was created. Mutual authentication via RPCSEC_GSS assures the ID was created. Mutual authentication via RPCSEC_GSS assures the
client that the connection is associated with the correct session client that the connection is associated with the correct session
of the correct server. of the correct server.
o For client ID trunking, the client has at least two options for * For client ID trunking, the client has at least two options for
verifying that the same client ID obtained from two different verifying that the same client ID obtained from two different
EXCHANGE_ID operations came from the same server. The first EXCHANGE_ID operations came from the same server. The first
option is to use RPCSEC_GSS authentication when sending each option is to use RPCSEC_GSS authentication when sending each
EXCHANGE_ID operation. Each time an EXCHANGE_ID is sent with EXCHANGE_ID operation. Each time an EXCHANGE_ID is sent with
RPCSEC_GSS authentication, the client notes the principal name of RPCSEC_GSS authentication, the client notes the principal name of
the GSS target. If the EXCHANGE_ID results indicate that client the GSS target. If the EXCHANGE_ID results indicate that client
ID trunking is possible, and the GSS targets' principal names are ID trunking is possible, and the GSS targets' principal names are
the same, the servers are the same and client ID trunking is the same, the servers are the same and client ID trunking is
allowed. allowed.
skipping to change at page 51, line 14 skipping to change at line 2394
Each COMPOUND or CB_COMPOUND request that is sent with a leading Each COMPOUND or CB_COMPOUND request that is sent with a leading
SEQUENCE or CB_SEQUENCE operation MUST be executed by the receiver SEQUENCE or CB_SEQUENCE operation MUST be executed by the receiver
exactly once. This requirement holds regardless of whether the exactly once. This requirement holds regardless of whether the
request is sent with reply caching specified (see request is sent with reply caching specified (see
Section 2.10.6.1.3). The requirement holds even if the requester is Section 2.10.6.1.3). The requirement holds even if the requester is
sending the request over a session created between a pNFS data client sending the request over a session created between a pNFS data client
and pNFS data server. To understand the rationale for this and pNFS data server. To understand the rationale for this
requirement, divide the requests into three classifications: requirement, divide the requests into three classifications:
o Non-idempotent requests. * Non-idempotent requests.
o Idempotent modifying requests. * Idempotent modifying requests.
o Idempotent non-modifying requests. * Idempotent non-modifying requests.
An example of a non-idempotent request is RENAME. Obviously, if a An example of a non-idempotent request is RENAME. Obviously, if a
replier executes the same RENAME request twice, and the first replier executes the same RENAME request twice, and the first
execution succeeds, the re-execution will fail. If the replier execution succeeds, the re-execution will fail. If the replier
returns the result from the re-execution, this result is incorrect. returns the result from the re-execution, this result is incorrect.
Therefore, EOS is required for non-idempotent requests. Therefore, EOS is required for non-idempotent requests.
An example of an idempotent modifying request is a COMPOUND request An example of an idempotent modifying request is a COMPOUND request
containing a WRITE operation. Repeated execution of the same WRITE containing a WRITE operation. Repeated execution of the same WRITE
has the same effect as execution of that WRITE a single time. has the same effect as execution of that WRITE a single time.
skipping to change at page 52, line 33 skipping to change at line 2460
cannot be interpreted by the replier except to test for equality with cannot be interpreted by the replier except to test for equality with
previously sent requests. When consulting an RPC-based duplicate previously sent requests. When consulting an RPC-based duplicate
request cache, the opaqueness of the XID requires a computationally request cache, the opaqueness of the XID requires a computationally
expensive look up (often via a hash that includes XID and source expensive look up (often via a hash that includes XID and source
address). NFSv4.1 requests use a non-opaque slot ID, which is an address). NFSv4.1 requests use a non-opaque slot ID, which is an
index into a slot table, which is far more efficient. Second, index into a slot table, which is far more efficient. Second,
because RPC requests can be executed by the replier in any order, because RPC requests can be executed by the replier in any order,
there is no bound on the number of requests that may be outstanding there is no bound on the number of requests that may be outstanding
at any time. To achieve perfect EOS, using ONC RPC would require at any time. To achieve perfect EOS, using ONC RPC would require
storing all replies in the reply cache. XIDs are 32 bits; storing storing all replies in the reply cache. XIDs are 32 bits; storing
over four billion (2^32) replies in the reply cache is not practical. over four billion (2^(32)) replies in the reply cache is not
In practice, previous versions of NFS have chosen to store a fixed practical. In practice, previous versions of NFS have chosen to
number of replies in the cache, and to use a least recently used store a fixed number of replies in the cache, and to use a least
(LRU) approach to replacing cache entries with new entries when the recently used (LRU) approach to replacing cache entries with new
cache is full. In NFSv4.1, the number of outstanding requests is entries when the cache is full. In NFSv4.1, the number of
bounded by the size of the slot table, and a sequence ID per slot is outstanding requests is bounded by the size of the slot table, and a
used to tell the replier when it is safe to delete a cached reply. sequence ID per slot is used to tell the replier when it is safe to
delete a cached reply.
In the NFSv4.1 reply cache, when the requester sends a new request, In the NFSv4.1 reply cache, when the requester sends a new request,
it selects a slot ID in the range 0..N, where N is the replier's it selects a slot ID in the range 0..N, where N is the replier's
current maximum slot ID granted to the requester on the session over current maximum slot ID granted to the requester on the session over
which the request is to be sent. The value of N starts out as equal which the request is to be sent. The value of N starts out as equal
to ca_maxrequests - 1 (Section 18.36), but can be adjusted by the to ca_maxrequests - 1 (Section 18.36), but can be adjusted by the
response to SEQUENCE or CB_SEQUENCE as described later in this response to SEQUENCE or CB_SEQUENCE as described later in this
section. The slot ID must be unused by any of the requests that the section. The slot ID must be unused by any of the requests that the
requester has already active on the session. "Unused" here means the requester has already active on the session. "Unused" here means the
requester has no outstanding request for that slot ID. requester has no outstanding request for that slot ID.
A slot contains a sequence ID and the cached reply corresponding to A slot contains a sequence ID and the cached reply corresponding to
the request sent with that sequence ID. The sequence ID is a 32-bit the request sent with that sequence ID. The sequence ID is a 32-bit
unsigned value, and is therefore in the range 0..0xFFFFFFFF (2^32 - unsigned value, and is therefore in the range 0..0xFFFFFFFF (2^(32) -
1). The first time a slot is used, the requester MUST specify a 1). The first time a slot is used, the requester MUST specify a
sequence ID of one (Section 18.36). Each time a slot is reused, the sequence ID of one (Section 18.36). Each time a slot is reused, the
request MUST specify a sequence ID that is one greater than that of request MUST specify a sequence ID that is one greater than that of
the previous request on the slot. If the previous sequence ID was the previous request on the slot. If the previous sequence ID was
0xFFFFFFFF, then the next request for the slot MUST have the sequence 0xFFFFFFFF, then the next request for the slot MUST have the sequence
ID set to zero (i.e., (2^32 - 1) + 1 mod 2^32). ID set to zero (i.e., (2^(32) - 1) + 1 mod 2^(32)).
The sequence ID accompanies the slot ID in each request. It is for The sequence ID accompanies the slot ID in each request. It is for
the critical check at the replier: it used to efficiently determine the critical check at the replier: it used to efficiently determine
whether a request using a certain slot ID is a retransmit or a new, whether a request using a certain slot ID is a retransmit or a new,
never-before-seen request. It is not feasible for the requester to never-before-seen request. It is not feasible for the requester to
assert that it is retransmitting to implement this, because for any assert that it is retransmitting to implement this, because for any
given request the requester cannot know whether the replier has seen given request the requester cannot know whether the replier has seen
it unless the replier actually replies. Of course, if the requester it unless the replier actually replies. Of course, if the requester
has seen the reply, the requester would not retransmit. has seen the reply, the requester would not retransmit.
The replier compares each received request's sequence ID with the The replier compares each received request's sequence ID with the
last one previously received for that slot ID, to see if the new last one previously received for that slot ID, to see if the new
request is: request is:
o A new request, in which the sequence ID is one greater than that * A new request, in which the sequence ID is one greater than that
previously seen in the slot (accounting for sequence wraparound). previously seen in the slot (accounting for sequence wraparound).
The replier proceeds to execute the new request, and the replier The replier proceeds to execute the new request, and the replier
MUST increase the slot's sequence ID by one. MUST increase the slot's sequence ID by one.
o A retransmitted request, in which the sequence ID is equal to that * A retransmitted request, in which the sequence ID is equal to that
currently recorded in the slot. If the original request has currently recorded in the slot. If the original request has
executed to completion, the replier returns the cached reply. See executed to completion, the replier returns the cached reply. See
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 * 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 * A misordered new request, in which the sequence ID is two or more
than (accounting for sequence wraparound) that previously seen in than (accounting for sequence wraparound) that previously seen in
the slot. Note that because the sequence ID MUST wrap around to the slot. Note that because the sequence ID MUST wrap around to
zero once it reaches 0xFFFFFFFF, a misordered new request and a zero once it reaches 0xFFFFFFFF, a misordered new request and a
misordered retry cannot be distinguished. Thus, the replier MUST misordered retry cannot be distinguished. Thus, the replier MUST
return NFS4ERR_SEQ_MISORDERED (as the result from SEQUENCE or return NFS4ERR_SEQ_MISORDERED (as the result from SEQUENCE or
CB_SEQUENCE). 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
skipping to change at page 54, line 28 skipping to change at line 2553
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
needs to 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. * The RPC layer retains its existing semantics and implementation.
o The requester and replier must be able to interoperate at the RPC * 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 * 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
needed for correct operation to match the reply to the request. needed for correct operation to match the reply to the request.
o The SEQUENCE or CB_SEQUENCE operation may generate an error. If * The SEQUENCE or CB_SEQUENCE operation may generate an error. If
so, the embedded slot ID, sequence ID, and session ID (if present) so, the embedded slot ID, sequence ID, and session ID (if present)
in the request will not be in the reply, and the requester has in the request will not be in the reply, and the requester has
only the XID to match the reply to the request. only the XID to match the reply to the request.
Given that well-formulated XIDs continue to be required, this raises Given that well-formulated XIDs continue to be required, this raises
the question: why do SEQUENCE and CB_SEQUENCE replies have a session the question: why do SEQUENCE and CB_SEQUENCE replies have a session
ID, slot ID, and sequence ID? Having the session ID in the reply ID, slot ID, and sequence ID? Having the session ID in the reply
means that the requester does not have to use the XID to look up the means that the requester does not have to use the XID to look up the
session ID, which would be necessary if the connection were session ID, which would be necessary if the connection were
associated with multiple sessions. Having the slot ID and sequence associated with multiple sessions. Having the slot ID and sequence
ID in the reply means that the requester does not have to use the XID ID in the reply means that the requester does not have to use the XID
to look up the slot ID and sequence ID. Furthermore, since the XID to look up the slot ID and sequence ID. Furthermore, since the XID
is only 32 bits, it is too small to guarantee the re-association of a is only 32 bits, it is too small to guarantee the re-association of a
reply with its request [43]; having session ID, slot ID, and sequence reply with its request [44]; having session ID, slot ID, and sequence
ID in the reply allows the client to validate that the reply in fact ID in the reply allows the client to validate that the reply in fact
belongs to the matched request. belongs to the 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:
o The target highest_slotid is an indication to the requester of the * The target highest_slotid is an indication to the requester of the
highest_slotid the replier wishes the requester to be using. This highest_slotid the replier wishes the requester to be using. This
permits the replier to withdraw (or add) resources from a permits the replier to withdraw (or add) resources from a
requester that has been found to not be using them, in order to requester that has been found to not be using them, in order to
more fairly share resources among a varying level of demand from more fairly share resources among a varying level of demand from
other requesters. The requester must always comply with the other requesters. The requester must always comply with the
replier's value updates, since they indicate newly established replier's value updates, since they indicate newly established
hard limits on the requester's access to session resources. hard limits on the requester's access to session resources.
However, because of request pipelining, the requester may have However, because of request pipelining, the requester may have
active requests in flight reflecting prior values; therefore, the active requests in flight reflecting prior values; therefore, the
replier must not immediately require the requester to comply. replier must not immediately require the requester to comply.
o The enforced highest_slotid indicates the highest slot ID the * The enforced highest_slotid indicates the highest slot ID the
requester is permitted to use on a subsequent SEQUENCE or requester is permitted to use on a subsequent SEQUENCE or
CB_SEQUENCE operation. The replier's enforced highest_slotid CB_SEQUENCE operation. The replier's enforced highest_slotid
SHOULD be no less than the highest_slotid the requester indicated SHOULD be no less than the highest_slotid the requester indicated
in the SEQUENCE or CB_SEQUENCE arguments. in the SEQUENCE or CB_SEQUENCE arguments.
A requester can be intransigent with respect to lowering its A requester can be intransigent with respect to lowering its
highest_slotid argument to a Sequence operation, i.e. the highest_slotid argument to a Sequence operation, i.e. the
requester continues to ignore the target highest_slotid in the requester continues to ignore the target highest_slotid in the
response to a Sequence operation, and continues to set its response to a Sequence operation, and continues to set its
highest_slotid argument to be higher than the target highest_slotid argument to be higher than the target
skipping to change at page 56, line 28 skipping to change at line 2647
enforced highest_slotid, the requester is only allowed to send enforced highest_slotid, the requester is only allowed to send
retries on slots that exceed the replier's highest_slotid. If a retries on slots that exceed the replier's highest_slotid. If a
request is received with a slot ID that is higher than the new request is received with a slot ID that is higher than the new
enforced highest_slotid, and the sequence ID is one higher than enforced highest_slotid, and the sequence ID is one higher than
what is in the slot's reply cache, then the server can both retire what is in the slot's reply cache, then the server can both retire
the slot and return NFS4ERR_BADSLOT (however, the server MUST NOT the slot and return NFS4ERR_BADSLOT (however, the server MUST NOT
do one and not the other). The reason it is safe to retire the do one and not the other). The reason it is safe to retire the
slot is because by using the next sequence ID, the requester is slot is because by using the next sequence ID, the requester is
indicating it has received the previous reply for the slot. indicating it has received the previous reply for the slot.
o The requester SHOULD use the lowest available slot when sending a * The requester SHOULD use the lowest available slot when sending a
new request. This way, the replier may be able to retire slot new request. This way, the replier may be able to retire slot
entries faster. However, where the replier is actively adjusting entries faster. However, where the replier is actively adjusting
its granted highest_slotid, it will not be able to use only the its granted highest_slotid, it will not be able to use only the
receipt of the slot ID and highest_slotid in the request. Neither receipt of the slot ID and highest_slotid in the request. Neither
the slot ID nor the highest_slotid used in a request may reflect the slot ID nor the highest_slotid used in a request may reflect
the replier's current idea of the requester's session limit, the replier's current idea of the requester's session limit,
because the request may have been sent from the requester before because the request may have been sent from the requester before
the update was received. Therefore, in the downward adjustment the update was received. Therefore, in the downward adjustment
case, the replier may have to retain a number of reply cache case, the replier may have to retain a number of reply cache
entries at least as large as the old value of maximum requests entries at least as large as the old value of maximum requests
skipping to change at page 57, line 41 skipping to change at line 2706
cache entry for the slot whenever an error is returned from SEQUENCE cache entry for the slot whenever an error is returned from SEQUENCE
or CB_SEQUENCE. or CB_SEQUENCE.
2.10.6.1.3. Optional Reply Caching 2.10.6.1.3. Optional Reply Caching
On a per-request basis, the requester can choose to direct the On a per-request basis, the requester can choose to direct the
replier to cache the reply to all operations after the first replier to cache the reply to all operations after the first
operation (SEQUENCE or CB_SEQUENCE) via the sa_cachethis or operation (SEQUENCE or CB_SEQUENCE) via the sa_cachethis or
csa_cachethis fields of the arguments to SEQUENCE or CB_SEQUENCE. csa_cachethis fields of the arguments to SEQUENCE or CB_SEQUENCE.
The reason it would not direct the replier to cache the entire reply The reason it would not direct the replier to cache the entire reply
is that the request is composed of all idempotent operations [40]. is that the request is composed of all idempotent operations [41].
Caching the reply may offer little benefit. If the reply is too Caching the reply may offer little benefit. If the reply is too
large (see Section 2.10.6.4), it may not be cacheable anyway. Even large (see Section 2.10.6.4), it may not be cacheable anyway. Even
if the reply to idempotent request is small enough to cache, if the reply to idempotent request is small enough to cache,
unnecessarily caching the reply slows down the server and increases unnecessarily caching the reply slows down the server and increases
RPC latency. RPC latency.
Whether or not the requester requests the reply to be cached has no Whether or not the requester requests the reply to be cached has no
effect on the slot processing. If the result of SEQUENCE or effect on the slot processing. If the result of SEQUENCE or
CB_SEQUENCE is NFS4_OK, then the slot's sequence ID MUST be CB_SEQUENCE is NFS4_OK, then the slot's sequence ID MUST be
incremented by one. If a requester does not direct the replier to incremented by one. If a requester does not direct the replier to
cache the reply, the replier MUST do one of following: cache the reply, the replier MUST do one of following:
o The replier can cache the entire original reply. Even though * The replier can cache the entire original reply. Even though
sa_cachethis or csa_cachethis is FALSE, the replier is always free sa_cachethis or csa_cachethis is FALSE, the replier is always free
to cache. It may choose this approach in order to simplify to cache. It may choose this approach in order to simplify
implementation. implementation.
o The replier enters into its reply cache a reply consisting of the * The replier enters into its reply cache a reply consisting of the
original results to the SEQUENCE or CB_SEQUENCE operation, and original results to the SEQUENCE or CB_SEQUENCE operation, and
with the next operation in COMPOUND or CB_COMPOUND having the with the next operation in COMPOUND or CB_COMPOUND having the
error NFS4ERR_RETRY_UNCACHED_REP. Thus, if the requester later error NFS4ERR_RETRY_UNCACHED_REP. Thus, if the requester later
retries the request, it will get NFS4ERR_RETRY_UNCACHED_REP. If a retries the request, it will get NFS4ERR_RETRY_UNCACHED_REP. If a
replier receives a retried Sequence operation where the reply to replier receives a retried Sequence operation where the reply to
the COMPOUND or CB_COMPOUND was not cached, then the replier, the COMPOUND or CB_COMPOUND was not cached, then the replier,
* MAY return NFS4ERR_RETRY_UNCACHED_REP in reply to a Sequence - MAY return NFS4ERR_RETRY_UNCACHED_REP in reply to a Sequence
operation if the Sequence operation is not the first operation operation if the Sequence operation is not the first operation
(granted, a requester that does so is in violation of the (granted, a requester that does so is in violation of the
NFSv4.1 protocol). NFSv4.1 protocol).
* MUST NOT return NFS4ERR_RETRY_UNCACHED_REP in reply to a - MUST NOT return NFS4ERR_RETRY_UNCACHED_REP in reply to a
Sequence operation if the Sequence operation is the first Sequence operation if the Sequence operation is the first
operation. operation.
o If the second operation is an illegal operation, or an operation * If the second operation is an illegal operation, or an operation
that was legal in a previous minor version of NFSv4 and MUST NOT that was legal in a previous minor version of NFSv4 and MUST NOT
be supported in the current minor version (e.g., SETCLIENTID), the be supported in the current minor version (e.g., SETCLIENTID), the
replier MUST NOT ever return NFS4ERR_RETRY_UNCACHED_REP. Instead replier MUST NOT ever return NFS4ERR_RETRY_UNCACHED_REP. Instead
the replier MUST return NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR or the replier MUST return NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR or
NFS4ERR_NOTSUPP as appropriate. NFS4ERR_NOTSUPP as appropriate.
o If the second operation can result in another error status, the * If the second operation can result in another error status, the
replier MAY return a status other than NFS4ERR_RETRY_UNCACHED_REP, replier MAY return a status other than NFS4ERR_RETRY_UNCACHED_REP,
provided the operation is not executed in such a way that the provided the operation is not executed in such a way that the
state of the replier is changed. Examples of such an error status state of the replier is changed. Examples of such an error status
include: NFS4ERR_NOTSUPP returned for an operation that is legal include: NFS4ERR_NOTSUPP returned for an operation that is legal
but not REQUIRED in the current minor versions, and thus not but not REQUIRED in the current minor versions, and thus not
supported by the replier; NFS4ERR_SEQUENCE_POS; and supported by the replier; NFS4ERR_SEQUENCE_POS; and
NFS4ERR_REQ_TOO_BIG. NFS4ERR_REQ_TOO_BIG.
The discussion above assumes that the retried request matches the The discussion above assumes that the retried request matches the
original one. Section 2.10.6.1.3.1 discusses what the replier might original one. Section 2.10.6.1.3.1 discusses what the replier might
do, and MUST do when original and retried requests do not match. do, and MUST do when original and retried requests do not match.
Since the replier may only cache a small amount of the information Since the replier may only cache a small amount of the information
that would be required to determine whether this is a case of a false that would be required to determine whether this is a case of a false
retry, the replier may send to the client any of the following retry, the replier may send to the client any of the following
responses: responses:
o The cached reply to the original request (if the replier has * The cached reply to the original request (if the replier has
cached it in its entirety and the users of the original request cached it in its entirety and the users of the original request
and retry match). and retry match).
o A reply that consists only of the Sequence operation with the * A reply that consists only of the Sequence operation with the
error NFS4ERR_FALSE_RETRY. error NFS4ERR_SEQ_FALSE_RETRY.
o A reply consisting of the response to Sequence with the status * A reply consisting of the response to Sequence with the status
NFS4_OK, together with the second operation as it appeared in the NFS4_OK, together with the second operation as it appeared in the
retried request with an error of NFS4ERR_RETRY_UNCACHED_REP or retried request with an error of NFS4ERR_RETRY_UNCACHED_REP or
other error as described above. other error as described above.
o A reply that consists of the response to Sequence with the status * A reply that consists of the response to Sequence with the status
NFS4_OK, together with the second operation as it appeared in the NFS4_OK, together with the second operation as it appeared in the
original request with an error of NFS4ERR_RETRY_UNCACHED_REP or original request with an error of NFS4ERR_RETRY_UNCACHED_REP or
other error as described above. other error as described above.
2.10.6.1.3.1. False Retry 2.10.6.1.3.1. False Retry
If a requester sent a Sequence operation with a slot ID and sequence If a requester sent a Sequence operation with a slot ID and sequence
ID that are in the reply cache but the replier detected that the ID that are in the reply cache but the replier detected that the
retried request is not the same as the original request, including a retried request is not the same as the original request, including a
retry that has different operations or different arguments in the retry that has different operations or different arguments in the
operations from the original and a retry that uses a different operations from the original and a retry that uses a different
principal in the RPC request's credential field that translates to a principal in the RPC request's credential field that translates to a
different user, then this is a false retry. When the replier detects different user, then this is a false retry. When the replier detects
a false retry, it is permitted (but not always obligated) to return a false retry, it is permitted (but not always obligated) to return
NFS4ERR_FALSE_RETRY in response to the Sequence operation when it NFS4ERR_SEQ_FALSE_RETRY in response to the Sequence operation when it
detects a false retry. detects a false retry.
Translations of particularly privileged user values to other users Translations of particularly privileged user values to other users
due to the lack of appropriately secure credentials, as configured on due to the lack of appropriately secure credentials, as configured on
the replier, should be applied before determining whether the users the replier, should be applied before determining whether the users
are the same or different. If the replier determines the users are are the same or different. If the replier determines the users are
different between the original request and a retry, then the replier different between the original request and a retry, then the replier
MUST return NFS4ERR_FALSE_RETRY. MUST return NFS4ERR_SEQ_FALSE_RETRY.
If an operation of the retry is an illegal operation, or an operation If an operation of the retry is an illegal operation, or an operation
that was legal in a previous minor version of NFSv4 and MUST NOT be that was legal in a previous minor version of NFSv4 and MUST NOT be
supported in the current minor version (e.g., SETCLIENTID), the supported in the current minor version (e.g., SETCLIENTID), the
replier MAY return NFS4ERR_FALSE_RETRY (and MUST do so if the users replier MAY return NFS4ERR_SEQ_FALSE_RETRY (and MUST do so if the
of the original request and retry differ). Otherwise, the replier users of the original request and retry differ). Otherwise, the
MAY return NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR or NFS4ERR_NOTSUPP as replier MAY return NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR or
appropriate. Note that the handling is in contrast for how the NFS4ERR_NOTSUPP as appropriate. Note that the handling is in
replier deals with retries requests with no cached reply. The contrast for how the replier deals with retries requests with no
difference is due to NFS4ERR_FALSE_RETRY being a valid error for only cached reply. The difference is due to NFS4ERR_SEQ_FALSE_RETRY being
Sequence operations, whereas NFS4ERR_RETRY_UNCACHED_REP is a valid a valid error for only Sequence operations, whereas
error for all operations except illegal operations and operations NFS4ERR_RETRY_UNCACHED_REP is a valid error for all operations except
that MUST NOT be supported in the current minor version of NFSv4. illegal operations and operations that MUST NOT be supported in the
current minor version of NFSv4.
2.10.6.2. Retry and Replay of Reply 2.10.6.2. Retry and Replay of Reply
A requester MUST NOT retry a request, unless the connection it used A requester MUST NOT retry a request, unless the connection it used
to send the request disconnects. The requester can then reconnect to send the request disconnects. The requester can then reconnect
and re-send the request, or it can re-send the request over a and re-send the request, or it can re-send the request over a
different connection that is associated with the same session. different connection that is associated with the same session.
If the requester is a server wanting to re-send a callback operation If the requester is a server wanting to re-send a callback operation
over the backchannel of a session, the requester of course cannot over the backchannel of a session, the requester of course cannot
skipping to change at page 63, line 31 skipping to change at line 2983
A client needs to take care that, when sending operations that change A client needs to take care that, when sending operations that change
the current filehandle (except for PUTFH, PUTPUBFH, PUTROOTFH, and the current filehandle (except for PUTFH, PUTPUBFH, PUTROOTFH, and
RESTOREFH), it does not exceed the maximum reply buffer before the RESTOREFH), it does not exceed the maximum reply buffer before the
GETFH operation. Otherwise, the client will have to retry the GETFH operation. Otherwise, the client will have to retry the
operation that changed the current filehandle, in order to obtain the operation that changed the current filehandle, in order to obtain the
desired filehandle. For the OPEN operation (see Section 18.16), desired filehandle. For the OPEN operation (see Section 18.16),
retry is not always available as an option. The following guidelines retry is not always available as an option. The following guidelines
for the handling of filehandle-changing operations are advised: for the handling of filehandle-changing operations are advised:
o Within the same COMPOUND procedure, a client SHOULD send GETFH * Within the same COMPOUND procedure, a client SHOULD send GETFH
immediately after a current filehandle-changing operation. A immediately after a current filehandle-changing operation. A
client MUST send GETFH after a current filehandle-changing client MUST send GETFH after a current filehandle-changing
operation that is also non-idempotent (e.g., the OPEN operation), operation that is also non-idempotent (e.g., the OPEN operation),
unless the operation is RESTOREFH. RESTOREFH is an exception, unless the operation is RESTOREFH. RESTOREFH is an exception,
because even though it is non-idempotent, the filehandle RESTOREFH because even though it is non-idempotent, the filehandle RESTOREFH
produced originated from an operation that is either idempotent produced originated from an operation that is either idempotent
(e.g., PUTFH, LOOKUP), or non-idempotent (e.g., OPEN, CREATE). If (e.g., PUTFH, LOOKUP), or non-idempotent (e.g., OPEN, CREATE). If
the origin is non-idempotent, then because the client MUST send the origin is non-idempotent, then because the client MUST send
GETFH after the origin operation, the client can recover if GETFH after the origin operation, the client can recover if
RESTOREFH returns an error. RESTOREFH returns an error.
o A server MAY return NFS4ERR_REP_TOO_BIG or * A server MAY return NFS4ERR_REP_TOO_BIG or
NFS4ERR_REP_TOO_BIG_TO_CACHE (if sa_cachethis is TRUE) on a NFS4ERR_REP_TOO_BIG_TO_CACHE (if sa_cachethis is TRUE) on a
filehandle-changing operation if the reply would be too large on filehandle-changing operation if the reply would be too large on
the next operation. the next operation.
o A server SHOULD return NFS4ERR_REP_TOO_BIG or * A server SHOULD return NFS4ERR_REP_TOO_BIG or
NFS4ERR_REP_TOO_BIG_TO_CACHE (if sa_cachethis is TRUE) on a NFS4ERR_REP_TOO_BIG_TO_CACHE (if sa_cachethis is TRUE) on a
filehandle-changing, non-idempotent operation if the reply would filehandle-changing, non-idempotent operation if the reply would
be too large on the next operation, especially if the operation is be too large on the next operation, especially if the operation is
OPEN. OPEN.
o A server MAY return NFS4ERR_UNSAFE_COMPOUND to a non-idempotent * A server MAY return NFS4ERR_UNSAFE_COMPOUND to a non-idempotent
current filehandle-changing operation, if it looks at the next current filehandle-changing operation, if it looks at the next
operation (in the same COMPOUND procedure) and finds it is not operation (in the same COMPOUND procedure) and finds it is not
GETFH. The server SHOULD do this if it is unable to determine in GETFH. The server SHOULD do this if it is unable to determine in
advance whether the total response size would exceed advance whether the total response size would exceed
ca_maxresponsesize_cached or ca_maxresponsesize. ca_maxresponsesize_cached or ca_maxresponsesize.
2.10.6.5. Persistence 2.10.6.5. Persistence
Since the reply cache is bounded, it is practical for the reply cache Since the reply cache is bounded, it is practical for the reply cache
to persist across server restarts. The replier MUST persist the to persist across server restarts. The replier MUST persist the
following information if it agreed to persist the session (when the following information if it agreed to persist the session (when the
session was created; see Section 18.36): session was created; see Section 18.36):
o The session ID. * The session ID.
o The slot table including the sequence ID and cached reply for each * The slot table including the sequence ID and cached reply for each
slot. slot.
The above are sufficient for a replier to provide EOS semantics for The above are sufficient for a replier to provide EOS semantics for
any requests that were sent and executed before the server restarted. any requests that were sent and executed before the server restarted.
If the replier is a client, then there is no need for it to persist If the replier is a client, then there is no need for it to persist
any more information, unless the client will be persisting all other any more information, unless the client will be persisting all other
state across client restart, in which case, the server will never see state across client restart, in which case, the server will never see
any NFSv4.1-level protocol manifestation of a client restart. If the any NFSv4.1-level protocol manifestation of a client restart. If the
replier is a server, with just the slot table and session ID replier is a server, with just the slot table and session ID
persisting, any requests the client retries after the server restart persisting, any requests the client retries after the server restart
will return the results that are cached in the reply cache, and any will return the results that are cached in the reply cache, and any
new requests (i.e., the sequence ID is one greater than the slot's new requests (i.e., the sequence ID is one greater than the slot's
sequence ID) MUST be rejected with NFS4ERR_DEADSESSION (returned by sequence ID) MUST be rejected with NFS4ERR_DEADSESSION (returned by
SEQUENCE). Such a session is considered dead. A server MAY re- SEQUENCE). Such a session is considered dead. A server MAY re-
animate a session after a server restart so that the session will animate a session after a server restart so that the session will
accept new requests as well as retries. To re-animate a session, the accept new requests as well as retries. To re-animate a session, the
server needs to persist additional information through server server needs to persist additional information through server
restart: restart:
o The client ID. This is a prerequisite to let the client create * The client ID. This is a prerequisite to let the client create
more sessions associated with the same client ID as the re- more sessions associated with the same client ID as the re-
animated session. animated session.
o The client ID's sequence ID that is used for creating sessions * The client ID's sequence ID that is used for creating sessions
(see Sections 18.35 and 18.36). This is a prerequisite to let the (see Sections 18.35 and 18.36). This is a prerequisite to let the
client create more sessions. client create more sessions.
o The principal that created the client ID. This allows the server * The principal that created the client ID. This allows the server
to authenticate the client when it sends EXCHANGE_ID. to authenticate the client when it sends EXCHANGE_ID.
o The SSV, if SP4_SSV state protection was specified when the client * The SSV, if SP4_SSV state protection was specified when the client
ID was created (see Section 18.35). This lets the client create ID was created (see Section 18.35). This lets the client create
new sessions, and associate connections with the new and existing new sessions, and associate connections with the new and existing
sessions. sessions.
o The properties of the client ID as defined in Section 18.35. * The properties of the client ID as defined in Section 18.35.
A persistent reply cache places certain demands on the server. The A persistent reply cache places certain demands on the server. The
execution of the sequence of operations (starting with SEQUENCE) and execution of the sequence of operations (starting with SEQUENCE) and
placement of its results in the persistent cache MUST be atomic. If placement of its results in the persistent cache MUST be atomic. If
a client retries a sequence of operations that was previously a client retries a sequence of operations that was previously
executed on the server, the only acceptable outcomes are either the executed on the server, the only acceptable outcomes are either the
original cached reply or an indication that the client ID or session original cached reply or an indication that the client ID or session
has been lost (indicating a catastrophic loss of the reply cache or a has been lost (indicating a catastrophic loss of the reply cache or a
session that has been deleted because the client failed to use the session that has been deleted because the client failed to use the
session for an extended period of time). session for an extended period of time).
skipping to change at page 65, line 39 skipping to change at line 3084
view the problem is as a single transaction consisting of each view the problem is as a single transaction consisting of each
operation in the COMPOUND followed by storing the result in operation in the COMPOUND followed by storing the result in
persistent storage, then finally a transaction commit. If there is a persistent storage, then finally a transaction commit. If there is a
failure before the transaction is committed, then the server rolls failure before the transaction is committed, then the server rolls
back the transaction. If the server itself fails, then when it back the transaction. If the server itself fails, then when it
restarts, its recovery logic could roll back the transaction before restarts, its recovery logic could roll back the transaction before
starting the NFSv4.1 server. starting the NFSv4.1 server.
While the description of the implementation for atomic execution of While the description of the implementation for atomic execution of
the request and caching of the reply is beyond the scope of this the request and caching of the reply is beyond the scope of this
document, an example implementation for NFSv2 [44] is described in document, an example implementation for NFSv2 [45] is described in
[45]. [46].
2.10.7. RDMA Considerations 2.10.7. RDMA Considerations
A complete discussion of the operation of RPC-based protocols over A complete discussion of the operation of RPC-based protocols over
RDMA transports is in [32]. A discussion of the operation of NFSv4, RDMA transports is in [32]. A discussion of the operation of NFSv4,
including NFSv4.1, over RDMA is in [33]. Where RDMA is considered, including NFSv4.1, over RDMA is in [33]. Where RDMA is considered,
this specification assumes the use of such a layering; it addresses this specification assumes the use of such a layering; it addresses
only the upper-layer issues relevant to making best use of RPC/RDMA. only the upper-layer issues relevant to making best use of RPC/RDMA.
2.10.7.1. RDMA Connection Resources 2.10.7.1. RDMA Connection Resources
skipping to change at page 69, line 7 skipping to change at line 3236
2.10.8.2. Backchannel RPC Security 2.10.8.2. Backchannel RPC Security
When the NFSv4.1 client establishes the backchannel, it informs the When the NFSv4.1 client establishes the backchannel, it informs the
server of the security flavors and principals to use when sending server of the security flavors and principals to use when sending
requests. If the security flavor is RPCSEC_GSS, the client expresses requests. If the security flavor is RPCSEC_GSS, the client expresses
the principal in the form of an established RPCSEC_GSS context. The the principal in the form of an established RPCSEC_GSS context. The
server is free to use any of the flavor/principal combinations the server is free to use any of the flavor/principal combinations the
client offers, but it MUST NOT use unoffered combinations. This way, client offers, but it MUST NOT use unoffered combinations. This way,
the client need not provide a target GSS principal for the the client need not provide a target GSS principal for the
backchannel as it did with NFSv4.0, nor does the server have to backchannel as it did with NFSv4.0, nor does the server have to
implement an RPCSEC_GSS initiator as it did with NFSv4.0 [36]. implement an RPCSEC_GSS initiator as it did with NFSv4.0 [37].
The CREATE_SESSION (Section 18.36) and BACKCHANNEL_CTL The CREATE_SESSION (Section 18.36) and BACKCHANNEL_CTL
(Section 18.33) operations allow the client to specify flavor/ (Section 18.33) operations allow the client to specify flavor/
principal combinations. principal combinations.
Also note that the SP4_SSV state protection mode (see Sections 18.35 Also note that the SP4_SSV state protection mode (see Sections 18.35
and 2.10.8.3) has the side benefit of providing SSV-derived and 2.10.8.3) has the side benefit of providing SSV-derived
RPCSEC_GSS contexts (Section 2.10.9). RPCSEC_GSS contexts (Section 2.10.9).
2.10.8.3. Protection from Unauthorized State Changes 2.10.8.3. Protection from Unauthorized State Changes
skipping to change at page 69, line 46 skipping to change at line 3275
NFSv4.1 provides three options to a client for state protection, NFSv4.1 provides three options to a client for state protection,
which are specified when a client creates a client ID via EXCHANGE_ID which are specified when a client creates a client ID via EXCHANGE_ID
(Section 18.35). (Section 18.35).
The first (SP4_NONE) is to simply waive state protection. The first (SP4_NONE) is to simply waive state protection.
The other two options (SP4_MACH_CRED and SP4_SSV) share several The other two options (SP4_MACH_CRED and SP4_SSV) share several
traits: traits:
o An RPCSEC_GSS-based credential is used to authenticate client ID * An RPCSEC_GSS-based credential is used to authenticate client ID
and session maintenance operations, including creating and and session maintenance operations, including creating and
destroying a session, associating a connection with the session, destroying a session, associating a connection with the session,
and destroying the client ID. and destroying the client ID.
o Because RPCSEC_GSS is used to authenticate client ID and session * Because RPCSEC_GSS is used to authenticate client ID and session
maintenance, the attacker cannot associate a rogue connection with maintenance, the attacker cannot associate a rogue connection with
a legitimate session, or associate a rogue session with a a legitimate session, or associate a rogue session with a
legitimate client ID in order to maliciously alter the client ID's legitimate client ID in order to maliciously alter the client ID's
lock state via CLOSE, LOCKU, DELEGRETURN, LAYOUTRETURN, etc. lock state via CLOSE, LOCKU, DELEGRETURN, LAYOUTRETURN, etc.
o In cases where the server's security policies on a portion of its * In cases where the server's security policies on a portion of its
namespace require RPCSEC_GSS authentication, a client may have to namespace require RPCSEC_GSS authentication, a client may have to
use an RPCSEC_GSS credential to remove per-file state (e.g., use an RPCSEC_GSS credential to remove per-file state (e.g.,
LOCKU, CLOSE, etc.). The server may require that the principal LOCKU, CLOSE, etc.). The server may require that the principal
that removes the state match certain criteria (e.g., the principal that removes the state match certain criteria (e.g., the principal
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
skipping to change at page 71, line 20 skipping to change at line 3343
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
intractable for an attacker to guess the SSV, and thus associate intractable for an attacker to guess the SSV, and thus associate
rogue connections with a session, and rogue sessions with a client rogue connections with a session, and rogue sessions with a client
ID: ID:
o The arguments to and results of SET_SSV include digests of the old * The arguments to and results of SET_SSV include digests of the old
and new SSV, respectively. and new SSV, respectively.
o Because the initial value of the SSV is zero, therefore known, the * Because the initial value of the SSV is zero, therefore known, the
client that opts for SP4_SSV protection and opts to apply SP4_SSV client that opts for SP4_SSV protection and opts to apply SP4_SSV
protection to BIND_CONN_TO_SESSION and CREATE_SESSION MUST send at protection to BIND_CONN_TO_SESSION and CREATE_SESSION MUST send at
least one SET_SSV operation before the first BIND_CONN_TO_SESSION least one SET_SSV operation before the first BIND_CONN_TO_SESSION
operation or before the second CREATE_SESSION operation on a operation or before the second CREATE_SESSION operation on a
client ID. If it does not, the SSV mechanism will not generate client ID. If it does not, the SSV mechanism will not generate
tokens (Section 2.10.9). A client SHOULD send SET_SSV as soon as tokens (Section 2.10.9). A client SHOULD send SET_SSV as soon as
a session is created. a session is created.
o A SET_SSV request does not replace the SSV with the argument to * A SET_SSV request does not replace the SSV with the argument to
SET_SSV. Instead, the current SSV on the server is logically SET_SSV. Instead, the current SSV on the server is logically
exclusive ORed (XORed) with the argument to SET_SSV. Each time a exclusive ORed (XORed) with the argument to SET_SSV. Each time a
new principal uses a client ID for the first time, the client new principal uses a client ID for the first time, the client
SHOULD send a SET_SSV with that principal's RPCSEC_GSS SHOULD send a SET_SSV with that principal's RPCSEC_GSS
credentials, with RPCSEC_GSS service set to RPC_GSS_SVC_PRIVACY. credentials, with RPCSEC_GSS service set to RPC_GSS_SVC_PRIVACY.
Here are the types of attacks that can be attempted by an attacker Here are the types of attacks that can be attempted by an attacker
named Eve on a victim named Bob, and how SP4_SSV protection foils named Eve on a victim named Bob, and how SP4_SSV protection foils
each attack: each attack:
o Suppose Eve is the first user to log into a legitimate client. * Suppose Eve is the first user to log into a legitimate client.
Eve's use of an NFSv4.1 file system will cause the legitimate Eve's use of an NFSv4.1 file system will cause the legitimate
client to create a client ID with SP4_SSV protection, specifying client to create a client ID with SP4_SSV protection, specifying
that the BIND_CONN_TO_SESSION operation MUST use the SSV that the BIND_CONN_TO_SESSION operation MUST use the SSV
credential. Eve's use of the file system also causes an SSV to be credential. Eve's use of the file system also causes an SSV to be
created. The SET_SSV operation that creates the SSV will be created. The SET_SSV operation that creates the SSV will be
protected by the RPCSEC_GSS context created by the legitimate protected by the RPCSEC_GSS context created by the legitimate
client, which uses Eve's GSS principal and credentials. Eve can client, which uses Eve's GSS principal and credentials. Eve can
eavesdrop on the network while her RPCSEC_GSS context is created eavesdrop on the network while her RPCSEC_GSS context is created
and the SET_SSV using her context is sent. Even if the legitimate and the SET_SSV using her context is sent. Even if the legitimate
client sends the SET_SSV with RPC_GSS_SVC_PRIVACY, because Eve client sends the SET_SSV with RPC_GSS_SVC_PRIVACY, because Eve
skipping to change at page 72, line 31 skipping to change at line 3402
the legitimate client, but she cannot disrupt Bob. Moreover, the legitimate client, but she cannot disrupt Bob. Moreover,
because the client SHOULD have modified the SSV due to Eve using because the client SHOULD have modified the SSV due to Eve using
the new session, Bob cannot get revenge on Eve by associating a the new session, Bob cannot get revenge on Eve by associating a
rogue connection with the session. rogue connection with the session.
The question is how did the legitimate client detect that Eve has The question is how did the legitimate client detect that Eve has
hijacked the old session? When the client detects that a new hijacked the old session? When the client detects that a new
principal, Bob, wants to use the session, it SHOULD have sent a principal, Bob, wants to use the session, it SHOULD have sent a
SET_SSV, which leads to the following sub-scenarios: SET_SSV, which leads to the following sub-scenarios:
* Let us suppose that from the rogue connection, Eve sent a - Let us suppose that from the rogue connection, Eve sent a
SET_SSV with the same slot ID and sequence ID that the SET_SSV with the same slot ID and sequence ID that the
legitimate client later uses. The server will assume the legitimate client later uses. The server will assume the
SET_SSV sent with Bob's credentials is a retry, and return to SET_SSV sent with Bob's credentials is a retry, and return to
the legitimate client the reply it sent Eve. However, unless the legitimate client the reply it sent Eve. However, unless
Eve can correctly guess the SSV the legitimate client will use, Eve can correctly guess the SSV the legitimate client will use,
the digest verification checks in the SET_SSV response will the digest verification checks in the SET_SSV response will
fail. That is an indication to the client that the session has fail. That is an indication to the client that the session has
apparently been hijacked. apparently been hijacked.
* Alternatively, Eve sent a SET_SSV with a different slot ID than - Alternatively, Eve sent a SET_SSV with a different slot ID than
the legitimate client uses for its SET_SSV. Then the digest the legitimate client uses for its SET_SSV. Then the digest
verification of the SET_SSV sent with Bob's credentials fails verification of the SET_SSV sent with Bob's credentials fails
on the server, and the error returned to the client makes it on the server, and the error returned to the client makes it
apparent that the session has been hijacked. apparent that the session has been hijacked.
* Alternatively, Eve sent an operation other than SET_SSV, but - Alternatively, Eve sent an operation other than SET_SSV, but
with the same slot ID and sequence that the legitimate client with the same slot ID and sequence that the legitimate client
uses for its SET_SSV. The server returns to the legitimate uses for its SET_SSV. The server returns to the legitimate
client the response it sent Eve. The client sees that the client the response it sent Eve. The client sees that the
response is not at all what it expects. The client assumes response is not at all what it expects. The client assumes
either session hijacking or a server bug, and either way either session hijacking or a server bug, and either way
destroys the old session. destroys the old session.
o Eve associates a rogue connection with the session as above, and * Eve associates a rogue connection with the session as above, and
then destroys the session. Again, Bob goes to use the server from then destroys the session. Again, Bob goes to use the server from
the legitimate client, which sends a SET_SSV using Bob's the legitimate client, which sends a SET_SSV using Bob's
credentials. The client receives an error that indicates that the credentials. The client receives an error that indicates that the
session does not exist. When the client tries to create a new session does not exist. When the client tries to create a new
session, this will fail because the SSV it has does not match that session, this will fail because the SSV it has does not match that
which the server has, and now the client knows the session was which the server has, and now the client knows the session was
hijacked. The legitimate client establishes a new client ID. hijacked. The legitimate client establishes a new client ID.
o If Eve creates a connection before the legitimate client * If Eve creates a connection before the legitimate client
establishes an SSV, because the initial value of the SSV is zero establishes an SSV, because the initial value of the SSV is zero
and therefore known, Eve can send a SET_SSV that will pass the and therefore known, Eve can send a SET_SSV that will pass the
digest verification check. However, because the new connection digest verification check. However, because the new connection
has not been associated with the session, the SET_SSV is rejected has not been associated with the session, the SET_SSV is rejected
for that reason. for that reason.
In summary, an attacker's disruption of state when SP4_SSV protection In summary, an attacker's disruption of state when SP4_SSV protection
is in use is limited to the formative period of a client ID, its is in use is limited to the formative period of a client ID, its
first session, and the establishment of the SSV. Once a non- first session, and the establishment of the SSV. Once a non-
malicious user uses the client ID, the client quickly detects any malicious user uses the client ID, the client quickly detects any
skipping to change at page 74, line 28 skipping to change at line 3484
iso.org.dod.internet.private.enterprise.Michael Eisler.nfs.ssv_mech iso.org.dod.internet.private.enterprise.Michael Eisler.nfs.ssv_mech
(1.3.6.1.4.1.28882.1.1). While the SSV mechanism does not define any (1.3.6.1.4.1.28882.1.1). While the SSV mechanism does not define any
initial context tokens, the OID can be used to let servers indicate initial context tokens, the OID can be used to let servers indicate
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 [51] algorithm, using the current SSV The calculation uses the HMAC [52] 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. If the length of the 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 the output of the HMAC algorithm exceeds the length of key of the
encryption algorithm (which is also negotiated by EXCHANGE_ID), then encryption algorithm (which is also negotiated by EXCHANGE_ID), then
the subkey MUST be truncated from the HMAC output, i.e., if the 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 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 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 that the length of the output of the HMAC algorithm MUST NOT be less
than the length of subkey needed for the encryption algorithm (see than the length of subkey needed for the encryption algorithm (see
skipping to change at page 78, line 23 skipping to change at line 3660
time, and the EXCHANGE_ID operation can be used to create more SSV time, and the EXCHANGE_ID operation can be used to create more SSV
RPCSEC_GSS handles. Expiration of SSV RPCSEC_GSS handles does not RPCSEC_GSS handles. Expiration of SSV RPCSEC_GSS handles does not
imply that the SSV or its GSS context has expired. imply that the SSV or its GSS context has expired.
The client MUST establish an SSV via SET_SSV before the SSV GSS The client MUST establish an SSV via SET_SSV before the SSV GSS
context can be used to emit tokens from GSS_Wrap() and GSS_GetMIC(). context can be used to emit tokens from GSS_Wrap() and GSS_GetMIC().
If SET_SSV has not been successfully called, attempts to emit tokens If SET_SSV has not been successfully called, attempts to emit tokens
MUST fail. MUST fail.
The SSV mechanism does not support replay detection and sequencing in The SSV mechanism does not support replay detection and sequencing in
its tokens because RPCSEC_GSS does not use those features (See its tokens because RPCSEC_GSS does not use those features (see
Section 5.2.2, "Context Creation Requests", in [4]). However, "Context Creation Requests", Section 5.2.2 of [4]). However,
Section 2.10.10 discusses special considerations for the SSV Section 2.10.10 discusses special considerations for the SSV
mechanism when used with RPCSEC_GSS. mechanism when used with RPCSEC_GSS.
2.10.10. Security Considerations for RPCSEC_GSS When Using the SSV 2.10.10. Security Considerations for RPCSEC_GSS When Using the SSV
Mechanism Mechanism
When a client ID is created with SP4_SSV state protection (see When a client ID is created with SP4_SSV state protection (see
Section 18.35), the client is permitted to associate multiple Section 18.35), the client is permitted to associate multiple
RPCSEC_GSS handles with the single SSV GSS context (see RPCSEC_GSS handles with the single SSV GSS context (see
Section 2.10.9). Because of the way RPCSEC_GSS (both version 1 and Section 2.10.9). Because of the way RPCSEC_GSS (both version 1 and
skipping to change at page 78, line 49 skipping to change at line 3686
value of the seq_num field of the RPCSEC_GSS credential (data type value of the seq_num field of the RPCSEC_GSS credential (data type
rpc_gss_cred_ver_1_t) (see Section 5.3.3.2 of [4]). If multiple rpc_gss_cred_ver_1_t) (see Section 5.3.3.2 of [4]). If multiple
RPCSEC_GSS handles share the same GSS context, then if one handle is RPCSEC_GSS handles share the same GSS context, then if one handle is
used to send a request with the same seq_num value as another handle, used to send a request with the same seq_num value as another handle,
an attacker could block the reply, and replace it with the verifier an attacker could block the reply, and replace it with the verifier
used for the other handle. used for the other handle.
There are multiple ways to prevent the attack on the SSV RPCSEC_GSS There are multiple ways to prevent the attack on the SSV RPCSEC_GSS
verifier in the reply. The simplest is believed to be as follows. verifier in the reply. The simplest is believed to be as follows.
o Each time one or more new SSV RPCSEC_GSS handles are created via * Each time one or more new SSV RPCSEC_GSS handles are created via
EXCHANGE_ID, the client SHOULD send a SET_SSV operation to modify EXCHANGE_ID, the client SHOULD send a SET_SSV operation to modify
the SSV. By changing the SSV, the new handles will not result in the SSV. By changing the SSV, the new handles will not result in
the re-use of an SSV RPCSEC_GSS verifier in a reply. the re-use of an SSV RPCSEC_GSS verifier in a reply.
o When a requester decides to use N SSV RPCSEC_GSS handles, it * When a requester decides to use N SSV RPCSEC_GSS handles, it
SHOULD assign a unique and non-overlapping range of seq_nums to SHOULD assign a unique and non-overlapping range of seq_nums to
each SSV RPCSEC_GSS handle. The size of each range SHOULD be each SSV RPCSEC_GSS handle. The size of each range SHOULD be
equal to MAXSEQ / N (see Section 5 of [4] for the definition of equal to MAXSEQ / N (see Section 5 of [4] for the definition of
MAXSEQ). When an SSV RPCSEC_GSS handle reaches its maximum, it MAXSEQ). When an SSV RPCSEC_GSS handle reaches its maximum, it
SHOULD force the replier to destroy the handle by sending a NULL SHOULD force the replier to destroy the handle by sending a NULL
RPC request with seq_num set to MAXSEQ + 1 (see Section 5.3.3.3 of RPC request with seq_num set to MAXSEQ + 1 (see Section 5.3.3.3 of
[4]). [4]).
o When the requester wants to increase or decrease N, it SHOULD * When the requester wants to increase or decrease N, it SHOULD
force the replier to destroy all N handles by sending a NULL RPC force the replier to destroy all N handles by sending a NULL RPC
request on each handle with seq_num set to MAXSEQ + 1. If the request on each handle with seq_num set to MAXSEQ + 1. If the
requester is the client, it SHOULD send a SET_SSV operation before requester is the client, it SHOULD send a SET_SSV operation before
using new handles. If the requester is the server, then the using new handles. If the requester is the server, then the
client SHOULD send a SET_SSV operation when it detects that the client SHOULD send a SET_SSV operation when it detects that the
server has forced it to destroy a backchannel's SSV RPCSEC_GSS server has forced it to destroy a backchannel's SSV RPCSEC_GSS
handle. By sending a SET_SSV operation, the SSV will change, and handle. By sending a SET_SSV operation, the SSV will change, and
so the attacker will be unavailable to successfully replay a so the attacker will be unavailable to successfully replay a
previous verifier in a reply to the requester. previous verifier in a reply to the requester.
skipping to change at page 80, line 10 skipping to change at line 3737
backchannel resources that the client has created for the server backchannel resources that the client has created for the server
(RPCSEC_GSS contexts and backchannel connections). If these (RPCSEC_GSS contexts and backchannel connections). If these
resources vanish, the server takes action as specified in resources vanish, the server takes action as specified in
Section 2.10.13.2. Section 2.10.13.2.
2.10.11.2. Obligations of the Client 2.10.11.2. Obligations of the Client
The client SHOULD honor the following obligations in order to utilize The client SHOULD honor the following obligations in order to utilize
the session: the session:
o Keep a necessary session from going idle on the server. A client * Keep a necessary session from going idle on the server. A client
that requires a session but nonetheless is not sending operations that requires a session but nonetheless is not sending operations
risks having the session be destroyed by the server. This is risks having the session be destroyed by the server. This is
because sessions consume resources, and resource limitations may because sessions consume resources, and resource limitations may
force the server to cull an inactive session. A server MAY force the server to cull an inactive session. A server MAY
consider a session to be inactive if the client has not used the consider a session to be inactive if the client has not used the
session before the session inactivity timer (Section 2.10.12) has session before the session inactivity timer (Section 2.10.12) has
expired. expired.
o Destroy the session when not needed. If a client has multiple * Destroy the session when not needed. If a client has multiple
sessions, one of which has no requests waiting for replies, and sessions, one of which has no requests waiting for replies, and
has been idle for some period of time, it SHOULD destroy the has been idle for some period of time, it SHOULD destroy the
session. session.
o Maintain GSS contexts and RPCSEC_GSS handles for the backchannel. * Maintain GSS contexts and RPCSEC_GSS handles for the backchannel.
If the client requires the server to use the RPCSEC_GSS security If the client requires the server to use the RPCSEC_GSS security
flavor for callbacks, then it needs to be sure the RPCSEC_GSS flavor for callbacks, then it needs to be sure the RPCSEC_GSS
handles and/or their GSS contexts that are handed to the server handles and/or their GSS contexts that are handed to the server
via BACKCHANNEL_CTL or CREATE_SESSION are unexpired. via BACKCHANNEL_CTL or CREATE_SESSION are unexpired.
o Preserve a connection for a backchannel. The server requires a * Preserve a connection for a backchannel. The server requires a
backchannel in order to gracefully recall recallable state or backchannel in order to gracefully recall recallable state or
notify the client of certain events. Note that if the connection notify the client of certain events. Note that if the connection
is not being used for the fore channel, there is no way for the is not being used for the fore channel, there is no way for the
client to tell if the connection is still alive (e.g., the server client to tell if the connection is still alive (e.g., the server
restarted without sending a disconnect). The onus is on the restarted without sending a disconnect). The onus is on the
server, not the client, to determine if the backchannel's server, not the client, to determine if the backchannel's
connection is alive, and to indicate in the response to a SEQUENCE connection is alive, and to indicate in the response to a SEQUENCE
operation when the last connection associated with a session's operation when the last connection associated with a session's
backchannel has disconnected. backchannel has disconnected.
skipping to change at page 83, line 9 skipping to change at line 3878
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 retain the backchannel and/or not put recallable client wants to retain the backchannel and/or not put recallable
state subject to revocation, the client needs to use BACKCHANNEL_CTL state subject to revocation, the client needs to use BACKCHANNEL_CTL
to assign new contexts. to assign new contexts.
2.10.13.1.4. Loss of Session 2.10.13.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. * Replier failure and restart.
o A catastrophe that causes the reply cache to be corrupted or lost * A catastrophe that causes the reply cache to be corrupted or lost
on the media on which it was stored. This applies even if the on the media on which it was stored. This applies even if the
replier indicated in the CREATE_SESSION results that it would replier indicated in the CREATE_SESSION results that it would
persist the cache. persist the cache.
o The server purges the session of a client that has been inactive * The server purges the session of a client that has been inactive
for a very extended period of time. for a very extended period of time.
o As a result of configuration changes among a set of clustered * As a result of configuration changes among a set of clustered
servers, a network address previously connected to one server servers, a network address previously connected to one server
becomes connected to a different server that has no knowledge of becomes connected to a different server that has no knowledge of
the session in question. Such a configuration change will the session in question. Such a configuration change will
generally only happen when the original server ceases to function generally only happen when the original server ceases to function
for a time. for a time.
Loss of reply cache is equivalent to loss of session. The replier Loss of reply cache is equivalent to loss of session. The replier
indicates loss of session to the requester by returning indicates loss of session to the requester by returning
NFS4ERR_BADSESSION on the next operation that uses the session ID NFS4ERR_BADSESSION on the next operation that uses the session ID
that refers to the lost session. that refers to the lost session.
skipping to change at page 84, line 9 skipping to change at line 3927
1. If the client has other connections to other server network 1. If the client has other connections to other server network
addresses associated with the same session, attempt a COMPOUND addresses associated with the same session, attempt a COMPOUND
with a single operation, SEQUENCE, on each of the other with a single operation, SEQUENCE, on each of the other
connections. connections.
2. If the attempts succeed, the session is still alive, and this is 2. If the attempts succeed, the session is still alive, and this is
a strong indicator that the server's network address has moved. a strong indicator that the server's network address has moved.
The client might send an EXCHANGE_ID on the connection that The client might send an EXCHANGE_ID on the connection that
returned NFS4ERR_BADSESSION to see if there are opportunities for returned NFS4ERR_BADSESSION to see if there are opportunities for
client ID trunking (i.e., the same client ID and so_major value client ID trunking (i.e., the same client ID and so_major_id
are returned). The client might use DNS to see if the moved value are returned). The client might use DNS to see if the
network address was replaced with another, so that the moved network address was replaced with another, so that the
performance and availability benefits of session trunking can performance and availability benefits of session trunking can
continue. continue.
3. If the SEQUENCE requests fail with NFS4ERR_BADSESSION, then the 3. If the SEQUENCE requests fail with NFS4ERR_BADSESSION, then the
session no longer exists on any of the server network addresses session no longer exists on any of the server network addresses
for which the client has connections associated with that session for which the client has connections associated with that session
ID. It is possible the session is still alive and available on ID. It is possible the session is still alive and available on
other network addresses. The client sends an EXCHANGE_ID on all other network addresses. The client sends an EXCHANGE_ID on all
the connections to see if the server owner is still listening on the connections to see if the server owner is still listening on
those network addresses. If the same server owner is returned those network addresses. If the same server owner is returned
skipping to change at page 87, line 20 skipping to change at line 4079
EXCHGID4_FLAG_USE_PNFS_MDS, and EXCHGID4_FLAG_USE_PNFS_DS flags (not EXCHGID4_FLAG_USE_PNFS_MDS, and EXCHGID4_FLAG_USE_PNFS_DS flags (not
mutually exclusive) are passed in the EXCHANGE_ID arguments and mutually exclusive) are passed in the EXCHANGE_ID arguments and
results to allow the client to indicate how it wants to use sessions results to allow the client to indicate how it wants to use sessions
created under the client ID, and to allow the server to indicate how created under the client ID, and to allow the server to indicate how
it will allow the sessions to be used. See Section 13.1 for pNFS it will allow the sessions to be used. See Section 13.1 for pNFS
sessions considerations. sessions considerations.
3. Protocol Constants and Data Types 3. Protocol Constants and Data Types
The syntax and semantics to describe the data types of the NFSv4.1 The syntax and semantics to describe the data types of the NFSv4.1
protocol are defined in the XDR RFC 4506 [2] and RPC RFC 5531 [3] protocol are defined in the XDR (RFC 4506 [2]) and RPC (RFC 5531 [3])
documents. The next sections build upon the XDR data types to define documents. The next sections build upon the XDR data types to define
constants, types, and structures specific to this protocol. The full constants, types, and structures specific to this protocol. The full
list of XDR data types is in [10]. list of XDR data types is in [10].
3.1. Basic Constants 3.1. Basic Constants
const NFS4_FHSIZE = 128; const NFS4_FHSIZE = 128;
const NFS4_VERIFIER_SIZE = 8; const NFS4_VERIFIER_SIZE = 8;
const NFS4_OPAQUE_LIMIT = 1024; const NFS4_OPAQUE_LIMIT = 1024;
const NFS4_SESSIONID_SIZE = 16; const NFS4_SESSIONID_SIZE = 16;
skipping to change at page 87, line 42 skipping to change at line 4101
const NFS4_INT64_MAX = 0x7fffffffffffffff; const NFS4_INT64_MAX = 0x7fffffffffffffff;
const NFS4_UINT64_MAX = 0xffffffffffffffff; const NFS4_UINT64_MAX = 0xffffffffffffffff;
const NFS4_INT32_MAX = 0x7fffffff; const NFS4_INT32_MAX = 0x7fffffff;
const NFS4_UINT32_MAX = 0xffffffff; const NFS4_UINT32_MAX = 0xffffffff;
const NFS4_MAXFILELEN = 0xffffffffffffffff; const NFS4_MAXFILELEN = 0xffffffffffffffff;
const NFS4_MAXFILEOFF = 0xfffffffffffffffe; const NFS4_MAXFILEOFF = 0xfffffffffffffffe;
Except where noted, all these constants are defined in bytes. Except where noted, all these constants are defined in bytes.
o NFS4_FHSIZE is the maximum size of a filehandle. * NFS4_FHSIZE is the maximum size of a filehandle.
o NFS4_VERIFIER_SIZE is the fixed size of a verifier. * NFS4_VERIFIER_SIZE is the fixed size of a verifier.
o NFS4_OPAQUE_LIMIT is the maximum size of certain opaque * NFS4_OPAQUE_LIMIT is the maximum size of certain opaque
information. information.
o NFS4_SESSIONID_SIZE is the fixed size of a session identifier. * NFS4_SESSIONID_SIZE is the fixed size of a session identifier.
o NFS4_INT64_MAX is the maximum value of a signed 64-bit integer. * NFS4_INT64_MAX is the maximum value of a signed 64-bit integer.
o NFS4_UINT64_MAX is the maximum value of an unsigned 64-bit * NFS4_UINT64_MAX is the maximum value of an unsigned 64-bit
integer. integer.
o NFS4_INT32_MAX is the maximum value of a signed 32-bit integer. * NFS4_INT32_MAX is the maximum value of a signed 32-bit integer.
o NFS4_UINT32_MAX is the maximum value of an unsigned 32-bit * NFS4_UINT32_MAX is the maximum value of an unsigned 32-bit
integer. integer.
o NFS4_MAXFILELEN is the maximum length of a regular file. * NFS4_MAXFILELEN is the maximum length of a regular file.
o NFS4_MAXFILEOFF is the maximum offset into a regular file. * NFS4_MAXFILEOFF is the maximum offset into a regular file.
3.2. Basic Data Types 3.2. Basic Data Types
These are the base NFSv4.1 data types. These are the base NFSv4.1 data types.
+---------------+---------------------------------------------------+ +===============+==============================================+
| Data Type | Definition | | Data Type | Definition |
+---------------+---------------------------------------------------+ +===============+==============================================+
| int32_t | typedef int int32_t; | | int32_t | typedef int int32_t; |
| uint32_t | typedef unsigned int uint32_t; | +---------------+----------------------------------------------+
| int64_t | typedef hyper int64_t; | | uint32_t | typedef unsigned int uint32_t; |
| uint64_t | typedef unsigned hyper uint64_t; | +---------------+----------------------------------------------+
| attrlist4 | typedef opaque attrlist4<>; | | int64_t | typedef hyper int64_t; |
| | Used for file/directory attributes. | +---------------+----------------------------------------------+
| bitmap4 | typedef uint32_t bitmap4<>; | | uint64_t | typedef unsigned hyper uint64_t; |
| | Used in attribute array encoding. | +---------------+----------------------------------------------+
| changeid4 | typedef uint64_t changeid4; | | attrlist4 | typedef opaque attrlist4<>; |
| | Used in the definition of change_info4. | | | |
| clientid4 | typedef uint64_t clientid4; | | | Used for file/directory attributes. |
| | Shorthand reference to client identification. | +---------------+----------------------------------------------+
| count4 | typedef uint32_t count4; | | bitmap4 | typedef uint32_t bitmap4<>; |
| | Various count parameters (READ, WRITE, COMMIT). | | | |
| length4 | typedef uint64_t length4; | | | Used in attribute array encoding. |
| | The length of a byte-range within a file. | +---------------+----------------------------------------------+
| mode4 | typedef uint32_t mode4; | | changeid4 | typedef uint64_t changeid4; |
| | Mode attribute data type. | | | |
| nfs_cookie4 | typedef uint64_t nfs_cookie4; | | | Used in the definition of change_info4. |
| | Opaque cookie value for READDIR. | +---------------+----------------------------------------------+
| nfs_fh4 | typedef opaque nfs_fh4<NFS4_FHSIZE>; | | clientid4 | typedef uint64_t clientid4; |
| | Filehandle definition. | | | |
| nfs_ftype4 | enum nfs_ftype4; | | | Shorthand reference to client |
| | Various defined file types. | | | identification. |
| nfsstat4 | enum nfsstat4; | +---------------+----------------------------------------------+
| | Return value for operations. | | count4 | typedef uint32_t count4; |
| offset4 | typedef uint64_t offset4; | | | |
| | Various offset designations (READ, WRITE, LOCK, | | | Various count parameters (READ, WRITE, |
| | COMMIT). | | | COMMIT). |
| qop4 | typedef uint32_t qop4; | +---------------+----------------------------------------------+
| | Quality of protection designation in SECINFO. | | length4 | typedef uint64_t length4; |
| sec_oid4 | typedef opaque sec_oid4<>; | | | |
| | Security Object Identifier. The sec_oid4 data | | | The length of a byte-range within a file. |
| | type is not really opaque. Instead, it contains | +---------------+----------------------------------------------+
| | an ASN.1 OBJECT IDENTIFIER as used by GSS-API in | | mode4 | typedef uint32_t mode4; |
| | the mech_type argument to GSS_Init_sec_context. | | | |
| | See [7] for details. | | | Mode attribute data type. |
| sequenceid4 | typedef uint32_t sequenceid4; | +---------------+----------------------------------------------+
| | Sequence number used for various session | | nfs_cookie4 | typedef uint64_t nfs_cookie4; |
| | operations (EXCHANGE_ID, CREATE_SESSION, | | | |
| | SEQUENCE, CB_SEQUENCE). | | | Opaque cookie value for READDIR. |
| seqid4 | typedef uint32_t seqid4; | +---------------+----------------------------------------------+
| | Sequence identifier used for locking. | | nfs_fh4 | typedef opaque nfs_fh4<NFS4_FHSIZE>; |
| sessionid4 | typedef opaque sessionid4[NFS4_SESSIONID_SIZE]; | | | |
| | Session identifier. | | | Filehandle definition. |
| slotid4 | typedef uint32_t slotid4; | +---------------+----------------------------------------------+
| | Sequencing artifact for various session | | nfs_ftype4 | enum nfs_ftype4; |
| | operations (SEQUENCE, CB_SEQUENCE). | | | |
| utf8string | typedef opaque utf8string<>; | | | Various defined file types. |
| | UTF-8 encoding for strings. | +---------------+----------------------------------------------+
| utf8str_cis | typedef utf8string utf8str_cis; | | nfsstat4 | enum nfsstat4; |
| | Case-insensitive UTF-8 string. | | | |
| utf8str_cs | typedef utf8string utf8str_cs; | | | Return value for operations. |
| | Case-sensitive UTF-8 string. | +---------------+----------------------------------------------+
| utf8str_mixed | typedef utf8string utf8str_mixed; | | offset4 | typedef uint64_t offset4; |
| | UTF-8 strings with a case-sensitive prefix and a | | | |
| | case-insensitive suffix. | | | Various offset designations (READ, WRITE, |
| component4 | typedef utf8str_cs component4; | | | LOCK, COMMIT). |
| | Represents pathname components. | +---------------+----------------------------------------------+
| linktext4 | typedef utf8str_cs linktext4; | | qop4 | typedef uint32_t qop4; |
| | Symbolic link contents ("symbolic link" is | | | |
| | defined in an Open Group [11] standard). | | | Quality of protection designation in |
| pathname4 | typedef component4 pathname4<>; | | | SECINFO. |
| | Represents pathname for fs_locations. | +---------------+----------------------------------------------+
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; | | sec_oid4 | typedef opaque sec_oid4<>; |
| | Verifier used for various operations (COMMIT, | | | |
| | CREATE, EXCHANGE_ID, OPEN, READDIR, WRITE) | | | Security Object Identifier. The sec_oid4 |
| | NFS4_VERIFIER_SIZE is defined as 8. | | | data type is not really opaque. Instead, it |
+---------------+---------------------------------------------------+ | | contains an ASN.1 OBJECT IDENTIFIER as used |
| | by GSS-API in the mech_type argument to |
| | GSS_Init_sec_context. See [7] for details. |
+---------------+----------------------------------------------+
| sequenceid4 | typedef uint32_t sequenceid4; |
| | |
| | Sequence number used for various session |
| | operations (EXCHANGE_ID, CREATE_SESSION, |
| | SEQUENCE, CB_SEQUENCE). |
+---------------+----------------------------------------------+
| seqid4 | typedef uint32_t seqid4; |
| | |
| | Sequence identifier used for locking. |
+---------------+----------------------------------------------+
| sessionid4 | typedef opaque |
| | sessionid4[NFS4_SESSIONID_SIZE]; |
| | |
| | Session identifier. |
+---------------+----------------------------------------------+
| slotid4 | typedef uint32_t slotid4; |
| | |
| | Sequencing artifact for various session |
| | operations (SEQUENCE, CB_SEQUENCE). |
+---------------+----------------------------------------------+
| utf8string | typedef opaque utf8string<>; |
| | |
| | UTF-8 encoding for strings. |
+---------------+----------------------------------------------+
| utf8str_cis | typedef utf8string utf8str_cis; |
| | |
| | Case-insensitive UTF-8 string. |
+---------------+----------------------------------------------+
| utf8str_cs | typedef utf8string utf8str_cs; |
| | |
| | Case-sensitive UTF-8 string. |
+---------------+----------------------------------------------+
| utf8str_mixed | typedef utf8string utf8str_mixed; |
| | |
| | UTF-8 strings with a case-sensitive prefix |
| | and a case-insensitive suffix. |
+---------------+----------------------------------------------+
| component4 | typedef utf8str_cs component4; |
| | |
| | Represents pathname components. |
+---------------+----------------------------------------------+
| linktext4 | typedef utf8str_cs linktext4; |
| | |
| | Symbolic link contents ("symbolic link" is |
| | defined in an Open Group [11] standard). |
+---------------+----------------------------------------------+
| pathname4 | typedef component4 pathname4<>; |
| | |
| | Represents pathname for fs_locations. |
+---------------+----------------------------------------------+
| verifier4 | typedef opaque |
| | verifier4[NFS4_VERIFIER_SIZE]; |
| | |
| | Verifier used for various operations |
| | (COMMIT, CREATE, EXCHANGE_ID, OPEN, READDIR, |
| | WRITE) NFS4_VERIFIER_SIZE is defined as 8. |
+---------------+----------------------------------------------+
End of Base Data Types Table 1
Table 1 End of Base Data Types
3.3. Structured Data Types 3.3. Structured Data Types
3.3.1. nfstime4 3.3.1. nfstime4
struct nfstime4 { struct nfstime4 {
int64_t seconds; int64_t seconds;
uint32_t nseconds; uint32_t nseconds;
}; };
skipping to change at page 92, line 5 skipping to change at line 4360
}; };
The fattr4 data type is used to represent file and directory The fattr4 data type is used to represent file and directory
attributes. attributes.
The bitmap is a counted array of 32-bit integers used to contain bit The bitmap is a counted array of 32-bit integers used to contain bit
values. The position of the integer in the array that contains bit n values. The position of the integer in the array that contains bit n
can be computed from the expression (n / 32), and its bit within that can be computed from the expression (n / 32), and its bit within that
integer is (n mod 32). integer is (n mod 32).
0 1 0 1
+-----------+-----------+-----------+-- +-----------+-----------+-----------+--
| count | 31 .. 0 | 63 .. 32 | | count | 31 .. 0 | 63 .. 32 |
+-----------+-----------+-----------+-- +-----------+-----------+-----------+--
3.3.8. change_info4 3.3.8. change_info4
struct change_info4 { struct change_info4 {
bool atomic; bool atomic;
changeid4 before; changeid4 before;
changeid4 after; changeid4 after;
skipping to change at page 92, line 35 skipping to change at line 4390
struct netaddr4 { struct netaddr4 {
/* see struct rpcb in RFC 1833 */ /* see struct rpcb in RFC 1833 */
string na_r_netid<>; /* network id */ string na_r_netid<>; /* network id */
string na_r_addr<>; /* universal address */ string na_r_addr<>; /* universal address */
}; };
The netaddr4 data type is used to identify network transport The netaddr4 data type is used to identify network transport
endpoints. The na_r_netid and na_r_addr fields respectively contain endpoints. The na_r_netid and na_r_addr fields respectively contain
a netid and uaddr. The netid and uaddr concepts are defined in [12]. a netid and uaddr. The netid and uaddr concepts are defined in [12].
The netid and uaddr formats for TCP over IPv4 and TCP over IPv6 are The netid and uaddr formats for TCP over IPv4 and TCP over IPv6 are
defined in [12], specifically Tables 2 and 3 and Sections 5.2.3.3 and defined in [12], specifically Tables 2 and 3 and in Sections 5.2.3.3
5.2.3.4. and 5.2.3.4.
3.3.10. state_owner4 3.3.10. state_owner4
struct state_owner4 { struct state_owner4 {
clientid4 clientid; clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>; opaque owner<NFS4_OPAQUE_LIMIT>;
}; };
typedef state_owner4 open_owner4; typedef state_owner4 open_owner4;
typedef state_owner4 lock_owner4; typedef state_owner4 lock_owner4;
skipping to change at page 94, line 20 skipping to change at line 4470
The layouttype4 data type is 32 bits in length. The range The layouttype4 data type is 32 bits in length. The range
represented by the layout type is split into three parts. Type 0x0 represented by the layout type is split into three parts. Type 0x0
is reserved. Types within the range 0x00000001-0x7FFFFFFF are is reserved. Types within the range 0x00000001-0x7FFFFFFF are
globally unique and are assigned according to the description in globally unique and are assigned according to the description in
Section 22.5; they are maintained by IANA. Types within the range Section 22.5; they are maintained by IANA. Types within the range
0x80000000-0xFFFFFFFF are site specific and for private use only. 0x80000000-0xFFFFFFFF are site specific and for private use only.
The LAYOUT4_NFSV4_1_FILES enumeration specifies that the NFSv4.1 file The LAYOUT4_NFSV4_1_FILES enumeration specifies that the NFSv4.1 file
layout type, as defined in Section 13, is to be used. The layout type, as defined in Section 13, is to be used. The
LAYOUT4_OSD2_OBJECTS enumeration specifies that the object layout, as LAYOUT4_OSD2_OBJECTS enumeration specifies that the object layout, as
defined in [46], is to be used. Similarly, the LAYOUT4_BLOCK_VOLUME defined in [47], is to be used. Similarly, the LAYOUT4_BLOCK_VOLUME
enumeration specifies that the block/volume layout, as defined in enumeration specifies that the block/volume layout, as defined in
[47], is to be used. [48], is to be used.
3.3.14. deviceid4 3.3.14. deviceid4
const NFS4_DEVICEID4_SIZE = 16; const NFS4_DEVICEID4_SIZE = 16;
typedef opaque deviceid4[NFS4_DEVICEID4_SIZE]; typedef opaque deviceid4[NFS4_DEVICEID4_SIZE];
Layout information includes device IDs that specify a storage device Layout information includes device IDs that specify a storage device
through a compact handle. Addressing and type information is through a compact handle. Addressing and type information is
obtained with the GETDEVICEINFO operation. Device IDs are not obtained with the GETDEVICEINFO operation. Device IDs are not
skipping to change at page 98, line 5 skipping to change at line 4624
helping the client determine when it should send I/O directly through helping the client determine when it should send I/O directly through
the metadata server versus the storage devices. The data type the metadata server versus the storage devices. The data type
consists of the layout type (thi_layout_type), a bitmap (thi_hintset) consists of the layout type (thi_layout_type), a bitmap (thi_hintset)
describing the set of hints supported by the server (they may differ describing the set of hints supported by the server (they may differ
based on the layout type), and a list of hints (thi_hintlist) whose based on the layout type), and a list of hints (thi_hintlist) whose
content is determined by the hintset bitmap. See the mdsthreshold content is determined by the hintset bitmap. See the mdsthreshold
attribute for more details. attribute for more details.
The thi_hintset field is a bitmap of the following values: The thi_hintset field is a bitmap of the following values:
+-------------------------+---+---------+---------------------------+ +=========================+===+=========+===========================+
| name | # | Data | Description | | name | # | Data | Description |
| | | Type | | | | | Type | |
+-------------------------+---+---------+---------------------------+ +=========================+===+=========+===========================+
| threshold4_read_size | 0 | length4 | If a file's length is | | threshold4_read_size | 0 | length4 | If a file's length is |
| | | | less than the value of | | | | | less than the value of |
| | | | threshold4_read_size, | | | | | threshold4_read_size, |
| | | | then it is RECOMMENDED | | | | | then it is RECOMMENDED |
| | | | that the client read from | | | | | that the client read |
| | | | the file via the MDS and | | | | | from the file via the |
| | | | not a storage device. | | | | | MDS and not a storage |
| | | | device. |
+-------------------------+---+---------+---------------------------+
| threshold4_write_size | 1 | length4 | If a file's length is | | threshold4_write_size | 1 | length4 | If a file's length is |
| | | | less than the value of | | | | | less than the value of |
| | | | threshold4_write_size, | | | | | threshold4_write_size, |
| | | | then it is RECOMMENDED | | | | | then it is RECOMMENDED |
| | | | that the client write to | | | | | that the client write |
| | | | the file via the MDS and | | | | | to the file via the |
| | | | not a storage device. | | | | | MDS and not a storage |
| threshold4_read_iosize | 2 | length4 | For read I/O sizes below | | | | | device. |
| | | | this threshold, it is | +-------------------------+---+---------+---------------------------+
| | | | RECOMMENDED to read data | | threshold4_read_iosize | 2 | length4 | For read I/O sizes |
| | | | through the MDS. | | | | | below this threshold, |
| threshold4_write_iosize | 3 | length4 | For write I/O sizes below | | | | | it is RECOMMENDED to |
| | | | this threshold, it is | | | | | read data through the |
| | | | RECOMMENDED to write data | | | | | MDS. |
| | | | through the MDS. |
+-------------------------+---+---------+---------------------------+ +-------------------------+---+---------+---------------------------+
| threshold4_write_iosize | 3 | length4 | For write I/O sizes |
| | | | below this threshold, |
| | | | it is RECOMMENDED to |
| | | | write data through the |
| | | | MDS. |
+-------------------------+---+---------+---------------------------+
Table 2
3.3.23. mdsthreshold4 3.3.23. mdsthreshold4
struct mdsthreshold4 { struct mdsthreshold4 {
threshold_item4 mth_hints<>; threshold_item4 mth_hints<>;
}; };
This data type holds an array of elements of data type This data type holds an array of elements of data type
threshold_item4, each of which is valid for a particular layout type. threshold_item4, each of which is valid for a particular layout type.
An array is necessary because a server can support multiple layout An array is necessary because a server can support multiple layout
skipping to change at page 99, line 10 skipping to change at line 4685
for a file system object. The contents of the filehandle are opaque for a file system object. The contents of the filehandle are opaque
to the client. Therefore, the server is responsible for translating to the client. Therefore, the server is responsible for translating
the filehandle to an internal representation of the file system the filehandle to an internal representation of the file system
object. object.
4.1. Obtaining the First Filehandle 4.1. Obtaining the First Filehandle
The operations of the NFS protocol are defined in terms of one or The operations of the NFS protocol are defined in terms of one or
more filehandles. Therefore, the client needs a filehandle to more filehandles. Therefore, the client needs a filehandle to
initiate communication with the server. With the NFSv3 protocol (RFC initiate communication with the server. With the NFSv3 protocol (RFC
1813 [37]), there exists an ancillary protocol to obtain this first 1813 [38]), there exists an ancillary protocol to obtain this first
filehandle. The MOUNT protocol, RPC program number 100005, provides filehandle. The MOUNT protocol, RPC program number 100005, provides
the mechanism of translating a string-based file system pathname to a the mechanism of translating a string-based file system pathname to a
filehandle, which can then be used by the NFS protocols. filehandle, which can then be used by the NFS protocols.
The MOUNT protocol has deficiencies in the area of security and use The MOUNT protocol has deficiencies in the area of security and use
via firewalls. This is one reason that the use of the public via firewalls. This is one reason that the use of the public
filehandle was introduced in RFC 2054 [48] and RFC 2055 [49]. With filehandle was introduced in RFC 2054 [49] and RFC 2055 [50]. With
the use of the public filehandle in combination with the LOOKUP the use of the public filehandle in combination with the LOOKUP
operation in the NFSv3 protocol, it has been demonstrated that the operation in the NFSv3 protocol, it has been demonstrated that the
MOUNT protocol is unnecessary for viable interaction between NFS MOUNT protocol is unnecessary for viable interaction between NFS
client and server. client and server.
Therefore, the NFSv4.1 protocol will not use an ancillary protocol Therefore, the NFSv4.1 protocol will not use an ancillary protocol
for translation from string-based pathnames to a filehandle. Two for translation from string-based pathnames to a filehandle. Two
special filehandles will be used as starting points for the NFS special filehandles will be used as starting points for the NFS
client. client.
skipping to change at page 103, line 6 skipping to change at line 4867
Volatile filehandles are especially suitable for implementation of Volatile filehandles are especially suitable for implementation of
the pseudo file systems used to bridge exports. See Section 7.5 for the pseudo file systems used to bridge exports. See Section 7.5 for
a discussion of this. a discussion of this.
4.3. One Method of Constructing a Volatile Filehandle 4.3. One Method of Constructing a Volatile Filehandle
A volatile filehandle, while opaque to the client, could contain: A volatile filehandle, while opaque to the client, could contain:
[volatile bit = 1 | server boot time | slot | generation number] [volatile bit = 1 | server boot time | slot | generation number]
o slot is an index in the server volatile filehandle table
o generation number is the generation number for the table entry/ * slot is an index in the server volatile filehandle table
* generation number is the generation number for the table entry/
slot slot
When the client presents a volatile filehandle, the server makes the When the client presents a volatile filehandle, the server makes the
following checks, which assume that the check for the volatile bit following checks, which assume that the check for the volatile bit
has passed. If the server boot time is less than the current server has passed. If the server boot time is less than the current server
boot time, return NFS4ERR_FHEXPIRED. If slot is out of range, return boot time, return NFS4ERR_FHEXPIRED. If slot is out of range, return
NFS4ERR_BADHANDLE. If the generation number does not match, return NFS4ERR_BADHANDLE. If the generation number does not match, return
NFS4ERR_FHEXPIRED. NFS4ERR_FHEXPIRED.
When the server restarts, the table is gone (it is volatile). When the server restarts, the table is gone (it is volatile).
skipping to change at page 104, line 48 skipping to change at line 4958
accesses a hidden directory of attributes associated with a file accesses a hidden directory of attributes associated with a file
system object. OPENATTR takes a filehandle for the object and system object. OPENATTR takes a filehandle for the object and
returns the filehandle for the attribute hierarchy. The filehandle returns the filehandle for the attribute hierarchy. The filehandle
for the named attributes is a directory object accessible by LOOKUP for the named attributes is a directory object accessible by LOOKUP
or READDIR and contains files whose names represent the named or READDIR and contains files whose names represent the named
attributes and whose data bytes are the value of the attribute. For attributes and whose data bytes are the value of the attribute. For
example: example:
+----------+-----------+---------------------------------+ +----------+-----------+---------------------------------+
| LOOKUP | "foo" | ; look up file | | LOOKUP | "foo" | ; look up file |
+----------+-----------+---------------------------------+
| GETATTR | attrbits | | | GETATTR | attrbits | |
+----------+-----------+---------------------------------+
| OPENATTR | | ; access foo's named attributes | | OPENATTR | | ; access foo's named attributes |
+----------+-----------+---------------------------------+
| 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 |
+----------+-----------+---------------------------------+ +----------+-----------+---------------------------------+
Table 3
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 that are classified as REQUIRED is deliberately The set of attributes that are classified as REQUIRED is deliberately
small since servers need to do whatever it takes to support them. A small since servers need to do whatever it takes to support them. A
server should support as many of the RECOMMENDED attributes as server should support as many of the RECOMMENDED attributes as
possible but, by their definition, the server is not required to possible but, by their definition, the server is not required to
support all of them. Attributes are deemed REQUIRED if the data is support all of them. Attributes are deemed REQUIRED if the data is
skipping to change at page 107, line 10 skipping to change at line 5072
well. well.
In NFSv4.1, the structure of named attribute directories is In NFSv4.1, the structure of named attribute directories is
restricted in a number of ways, in order to prevent the development restricted in a number of ways, in order to prevent the development
of non-interoperable implementations in which some servers support a of non-interoperable implementations in which some servers support a
fully general hierarchical directory structure for named attributes fully general hierarchical directory structure for named attributes
while others support a limited but adequate structure for named while others support a limited but adequate structure for named
attributes. In such an environment, clients or applications might attributes. In such an environment, clients or applications might
come to depend on non-portable extensions. The restrictions are: come to depend on non-portable extensions. The restrictions are:
o CREATE is not allowed in a named attribute directory. Thus, such * CREATE is not allowed in a named attribute directory. Thus, such
objects as symbolic links and special files are not allowed to be objects as symbolic links and special files are not allowed to be
named attributes. Further, directories may not be created in a named attributes. Further, directories may not be created in a
named attribute directory, so no hierarchical structure of named named attribute directory, so no hierarchical structure of named
attributes for a single object is allowed. attributes for a single object is allowed.
o If OPENATTR is done on a named attribute directory or on a named * If OPENATTR is done on a named attribute directory or on a named
attribute, the server MUST return NFS4ERR_WRONG_TYPE. attribute, the server MUST return NFS4ERR_WRONG_TYPE.
o Doing a RENAME of a named attribute to a different named attribute * Doing a RENAME of a named attribute to a different named attribute
directory or to an ordinary (i.e., non-named-attribute) directory directory or to an ordinary (i.e., non-named-attribute) directory
is not allowed. is not allowed.
o Creating hard links between named attribute directories or between * Creating hard links between named attribute directories or between
named attribute directories and ordinary directories is not named attribute directories and ordinary directories is not
allowed. allowed.
Names of attributes will not be controlled by this document or other Names of attributes will not be controlled by this document or other
IETF Standards Track documents. See Section 22.2 for further IETF Standards Track documents. See Section 22.2 for further
discussion. discussion.
5.4. Classification of Attributes 5.4. Classification of Attributes
Each of the REQUIRED and RECOMMENDED attributes can be classified in Each of the REQUIRED and RECOMMENDED attributes can be classified in
skipping to change at page 107, line 47 skipping to change at line 5109
system (i.e., the value of the attribute will be the same for some or system (i.e., the value of the attribute will be the same for some or
all file objects that share the same fsid attribute (Section 5.8.1.9) all file objects that share the same fsid attribute (Section 5.8.1.9)
and server owner), or per file system object. Note that it is and server owner), or per file system object. Note that it is
possible that some per file system attributes may vary within the possible that some per file system attributes may vary within the
file system, depending on the value of the "homogeneous" file system, depending on the value of the "homogeneous"
(Section 5.8.2.16) attribute. Note that the attributes (Section 5.8.2.16) attribute. Note that the attributes
time_access_set and time_modify_set are not listed in this section time_access_set and time_modify_set are not listed in this section
because they are write-only attributes corresponding to time_access because they are write-only attributes corresponding to time_access
and time_modify, and are used in a special instance of SETATTR. and time_modify, and are used in a special instance of SETATTR.
o The per-server attribute is: * The per-server attribute is:
lease_time lease_time
o The per-file system attributes are: * The per-file system attributes are:
supported_attrs, suppattr_exclcreat, fh_expire_type, supported_attrs, suppattr_exclcreat, fh_expire_type,
link_support, symlink_support, unique_handles, aclsupport, link_support, symlink_support, unique_handles, aclsupport,
cansettime, case_insensitive, case_preserving, cansettime, case_insensitive, case_preserving,
chown_restricted, files_avail, files_free, files_total, chown_restricted, files_avail, files_free, files_total,
fs_locations, homogeneous, maxfilesize, maxname, maxread, fs_locations, homogeneous, maxfilesize, maxname, maxread,
maxwrite, no_trunc, space_avail, space_free, space_total, maxwrite, no_trunc, space_avail, space_free, space_total,
time_delta, change_policy, fs_status, fs_layout_type, time_delta, change_policy, fs_status, fs_layout_type,
fs_locations_info, fs_charset_cap fs_locations_info, fs_charset_cap
o The per-file system object attributes are: * The per-file system object attributes are:
type, change, size, named_attr, fsid, rdattr_error, filehandle, type, change, size, named_attr, fsid, rdattr_error, filehandle,
acl, archive, fileid, hidden, maxlink, mimetype, mode, acl, archive, fileid, hidden, maxlink, mimetype, mode,
numlinks, owner, owner_group, rawdev, space_used, system, numlinks, owner, owner_group, rawdev, space_used, system,
time_access, time_backup, time_create, time_metadata, time_access, time_backup, time_create, time_metadata,
time_modify, mounted_on_fileid, dir_notif_delay, time_modify, mounted_on_fileid, dir_notif_delay,
dirent_notif_delay, dacl, sacl, layout_type, layout_hint, dirent_notif_delay, dacl, sacl, layout_type, layout_hint,
layout_blksize, layout_alignment, mdsthreshold, retention_get, layout_blksize, layout_alignment, mdsthreshold, retention_get,
retention_set, retentevt_get, retentevt_set, retention_hold, retention_set, retentevt_get, retentevt_set, retention_hold,
mode_set_masked mode_set_masked
skipping to change at page 108, line 40 skipping to change at line 5150
Some REQUIRED and RECOMMENDED attributes are set-only; i.e., they can Some REQUIRED and RECOMMENDED attributes are set-only; i.e., they can
be set via SETATTR but not retrieved via GETATTR. Similarly, some be set via SETATTR but not retrieved via GETATTR. Similarly, some
REQUIRED and RECOMMENDED attributes are get-only; i.e., they can be REQUIRED and RECOMMENDED attributes are get-only; i.e., they can be
retrieved via GETATTR but not set via SETATTR. If a client attempts retrieved via GETATTR but not set via SETATTR. If a client attempts
to set a get-only attribute or get a set-only attributes, the server to set a get-only attribute or get a set-only attributes, the server
MUST return NFS4ERR_INVAL. MUST return NFS4ERR_INVAL.
5.6. REQUIRED Attributes - List and Definition References 5.6. REQUIRED Attributes - List and Definition References
The list of REQUIRED attributes appears in Table 2. The meaning of The list of REQUIRED attributes appears in Table 4. The meaning of
the columns of the table are: the columns of the table are:
o Name: The name of the attribute. Name: The name of the attribute.
o Id: The number assigned to the attribute. In the event of Id: The number assigned to the attribute. In the event of conflicts
conflicts between the assigned number and [10], the latter is between the assigned number and [10], the latter is likely
likely authoritative, but should be resolved with Errata to this authoritative, but should be resolved with Errata to this document
document and/or [10]. See [50] for the Errata process. and/or [10]. See [51] for the Errata process.
o Data Type: The XDR data type of the attribute. Data Type: The XDR data type of the attribute.
o Acc: Access allowed to the attribute. R means read-only (GETATTR Acc: Access allowed to the attribute. R means read-only (GETATTR
may retrieve, SETATTR may not set). W means write-only (SETATTR may retrieve, SETATTR may not set). W means write-only (SETATTR
may set, GETATTR may not retrieve). R W means read/write (GETATTR may set, GETATTR may not retrieve). R W means read/write (GETATTR
may retrieve, SETATTR may set). may retrieve, SETATTR may set).
o Defined in: The section of this specification that describes the Defined in: The section of this specification that describes the
attribute. attribute.
+--------------------+----+------------+-----+-------------------+ +====================+====+============+=====+==================+
| Name | Id | Data Type | Acc | Defined in: | | Name | Id | Data Type | Acc | Defined in: |
+--------------------+----+------------+-----+-------------------+ +====================+====+============+=====+==================+
| supported_attrs | 0 | bitmap4 | R | Section 5.8.1.1 | | supported_attrs | 0 | bitmap4 | R | Section 5.8.1.1 |
| type | 1 | nfs_ftype4 | R | Section 5.8.1.2 | +--------------------+----+------------+-----+------------------+
| fh_expire_type | 2 | uint32_t | R | Section 5.8.1.3 | | type | 1 | nfs_ftype4 | R | Section 5.8.1.2 |
| change | 3 | uint64_t | R | Section 5.8.1.4 | +--------------------+----+------------+-----+------------------+
| size | 4 | uint64_t | R W | Section 5.8.1.5 | | fh_expire_type | 2 | uint32_t | R | Section 5.8.1.3 |
| link_support | 5 | bool | R | Section 5.8.1.6 | +--------------------+----+------------+-----+------------------+
| symlink_support | 6 | bool | R | Section 5.8.1.7 | | change | 3 | uint64_t | R | Section 5.8.1.4 |
| named_attr | 7 | bool | R | Section 5.8.1.8 | +--------------------+----+------------+-----+------------------+
| fsid | 8 | fsid4 | R | Section 5.8.1.9 | | size | 4 | uint64_t | R W | Section 5.8.1.5 |
| unique_handles | 9 | bool | R | Section 5.8.1.10 | +--------------------+----+------------+-----+------------------+
| lease_time | 10 | nfs_lease4 | R | Section 5.8.1.11 | | link_support | 5 | bool | R | Section 5.8.1.6 |
| rdattr_error | 11 | enum | R | Section 5.8.1.12 | +--------------------+----+------------+-----+------------------+
| filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 | | symlink_support | 6 | bool | R | Section 5.8.1.7 |
| suppattr_exclcreat | 75 | bitmap4 | R | Section 5.8.1.14 | +--------------------+----+------------+-----+------------------+
+--------------------+----+------------+-----+-------------------+ | named_attr | 7 | bool | R | Section 5.8.1.8 |
+--------------------+----+------------+-----+------------------+
| fsid | 8 | fsid4 | R | Section 5.8.1.9 |
+--------------------+----+------------+-----+------------------+
| unique_handles | 9 | bool | R | Section 5.8.1.10 |
+--------------------+----+------------+-----+------------------+
| lease_time | 10 | nfs_lease4 | R | Section 5.8.1.11 |
+--------------------+----+------------+-----+------------------+
| rdattr_error | 11 | enum | R | Section 5.8.1.12 |
+--------------------+----+------------+-----+------------------+
| filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 |
+--------------------+----+------------+-----+------------------+
| suppattr_exclcreat | 75 | bitmap4 | R | Section 5.8.1.14 |
+--------------------+----+------------+-----+------------------+
Table 2 Table 4
5.7. RECOMMENDED Attributes - List and Definition References 5.7. RECOMMENDED Attributes - List and Definition References
The RECOMMENDED attributes are defined in Table 3. The meanings of The RECOMMENDED attributes are defined in Table 5. The meanings of
the column headers are the same as Table 2; see Section 5.6 for the the column headers are the same as Table 4; see Section 5.6 for the
meanings. meanings.
+--------------------+----+----------------+-----+------------------+ +====================+====+====================+=====+=============+
| Name | Id | Data Type | Acc | Defined in: | | Name | Id | Data Type | Acc | Defined in: |
+--------------------+----+----------------+-----+------------------+ +====================+====+====================+=====+=============+
| acl | 12 | nfsace4<> | R W | Section 6.2.1 | | acl | 12 | nfsace4<> | R W | Section |
| aclsupport | 13 | uint32_t | R | Section 6.2.1.2 | | | | | | 6.2.1 |
| archive | 14 | bool | R W | Section 5.8.2.1 | +--------------------+----+--------------------+-----+-------------+
| cansettime | 15 | bool | R | Section 5.8.2.2 | | aclsupport | 13 | uint32_t | R | Section |
| case_insensitive | 16 | bool | R | Section 5.8.2.3 | | | | | | 6.2.1.2 |
| case_preserving | 17 | bool | R | Section 5.8.2.4 | +--------------------+----+--------------------+-----+-------------+
| change_policy | 60 | chg_policy4 | R | Section 5.8.2.5 | | archive | 14 | bool | R W | Section |
| chown_restricted | 18 | bool | R | Section 5.8.2.6 | | | | | | 5.8.2.1 |
| dacl | 58 | nfsacl41 | R W | Section 6.2.2 | +--------------------+----+--------------------+-----+-------------+
| dir_notif_delay | 56 | nfstime4 | R | Section 5.11.1 | | cansettime | 15 | bool | R | Section |
| dirent_notif_delay | 57 | nfstime4 | R | Section 5.11.2 | | | | | | 5.8.2.2 |
| fileid | 20 | uint64_t | R | Section 5.8.2.7 | +--------------------+----+--------------------+-----+-------------+
| files_avail | 21 | uint64_t | R | Section 5.8.2.8 | | case_insensitive | 16 | bool | R | Section |
| files_free | 22 | uint64_t | R | Section 5.8.2.9 | | | | | | 5.8.2.3 |
| files_total | 23 | uint64_t | R | Section 5.8.2.10 | +--------------------+----+--------------------+-----+-------------+
| fs_charset_cap | 76 | uint32_t | R | Section 5.8.2.11 | | case_preserving | 17 | bool | R | Section |
| fs_layout_type | 62 | layouttype4<> | R | Section 5.12.1 | | | | | | 5.8.2.4 |
| fs_locations | 24 | fs_locations | R | Section 5.8.2.12 | +--------------------+----+--------------------+-----+-------------+
| fs_locations_info | 67 | * | R | Section 5.8.2.13 | | change_policy | 60 | chg_policy4 | R | Section |
| fs_status | 61 | fs4_status | R | Section 5.8.2.14 | | | | | | 5.8.2.5 |
| hidden | 25 | bool | R W | Section 5.8.2.15 | +--------------------+----+--------------------+-----+-------------+
| homogeneous | 26 | bool | R | Section 5.8.2.16 | | chown_restricted | 18 | bool | R | Section |
| layout_alignment | 66 | uint32_t | R | Section 5.12.2 | | | | | | 5.8.2.6 |
| layout_blksize | 65 | uint32_t | R | Section 5.12.3 | +--------------------+----+--------------------+-----+-------------+
| layout_hint | 63 | layouthint4 | W | Section 5.12.4 | | dacl | 58 | nfsacl41 | R W | Section |
| layout_type | 64 | layouttype4<> | R | Section 5.12.5 | | | | | | 6.2.2 |
| maxfilesize | 27 | uint64_t | R | Section 5.8.2.17 | +--------------------+----+--------------------+-----+-------------+
| maxlink | 28 | uint32_t | R | Section 5.8.2.18 | | dir_notif_delay | 56 | nfstime4 | R | Section |
| maxname | 29 | uint32_t | R | Section 5.8.2.19 | | | | | | 5.11.1 |
| maxread | 30 | uint64_t | R | Section 5.8.2.20 | +--------------------+----+--------------------+-----+-------------+
| maxwrite | 31 | uint64_t | R | Section 5.8.2.21 | | dirent_notif_delay | 57 | nfstime4 | R | Section |
| mdsthreshold | 68 | mdsthreshold4 | R | Section 5.12.6 | | | | | | 5.11.2 |
| mimetype | 32 | utf8str_cs | R W | Section 5.8.2.22 | +--------------------+----+--------------------+-----+-------------+
| mode | 33 | mode4 | R W | Section 6.2.4 | | fileid | 20 | uint64_t | R | Section |
| mode_set_masked | 74 | mode_masked4 | W | Section 6.2.5 | | | | | | 5.8.2.7 |
| mounted_on_fileid | 55 | uint64_t | R | Section 5.8.2.23 | +--------------------+----+--------------------+-----+-------------+
| no_trunc | 34 | bool | R | Section 5.8.2.24 | | files_avail | 21 | uint64_t | R | Section |
| numlinks | 35 | uint32_t | R | Section 5.8.2.25 | | | | | | 5.8.2.8 |
| owner | 36 | utf8str_mixed | R W | Section 5.8.2.26 | +--------------------+----+--------------------+-----+-------------+
| owner_group | 37 | utf8str_mixed | R W | Section 5.8.2.27 | | files_free | 22 | uint64_t | R | Section |
| quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.28 | | | | | | 5.8.2.9 |
| quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.29 | +--------------------+----+--------------------+-----+-------------+
| quota_used | 40 | uint64_t | R | Section 5.8.2.30 | | files_total | 23 | uint64_t | R | Section |
| rawdev | 41 | specdata4 | R | Section 5.8.2.31 | | | | | | 5.8.2.10 |
| retentevt_get | 71 | retention_get4 | R | Section 5.13.3 | +--------------------+----+--------------------+-----+-------------+
| retentevt_set | 72 | retention_set4 | W | Section 5.13.4 | | fs_charset_cap | 76 | uint32_t | R | Section |
| retention_get | 69 | retention_get4 | R | Section 5.13.1 | | | | | | 5.8.2.11 |
| retention_hold | 73 | uint64_t | R W | Section 5.13.5 | +--------------------+----+--------------------+-----+-------------+
| retention_set | 70 | retention_set4 | W | Section 5.13.2 | | fs_layout_type | 62 | layouttype4<> | R | Section |
| sacl | 59 | nfsacl41 | R W | Section 6.2.3 | | | | | | 5.12.1 |
| space_avail | 42 | uint64_t | R | Section 5.8.2.32 | +--------------------+----+--------------------+-----+-------------+
| space_free | 43 | uint64_t | R | Section 5.8.2.33 | | fs_locations | 24 | fs_locations | R | Section |
| space_total | 44 | uint64_t | R | Section 5.8.2.34 | | | | | | 5.8.2.12 |
| space_used | 45 | uint64_t | R | Section 5.8.2.35 | +--------------------+----+--------------------+-----+-------------+
| system | 46 | bool | R W | Section 5.8.2.36 | | fs_locations_info | 67 | fs_locations_info4 | R | Section |
| time_access | 47 | nfstime4 | R | Section 5.8.2.37 | | | | | | 5.8.2.13 |
| time_access_set | 48 | settime4 | W | Section 5.8.2.38 | +--------------------+----+--------------------+-----+-------------+
| time_backup | 49 | nfstime4 | R W | Section 5.8.2.39 | | fs_status | 61 | fs4_status | R | Section |
| time_create | 50 | nfstime4 | R W | Section 5.8.2.40 | | | | | | 5.8.2.14 |
| time_delta | 51 | nfstime4 | R | Section 5.8.2.41 | +--------------------+----+--------------------+-----+-------------+
| time_metadata | 52 | nfstime4 | R | Section 5.8.2.42 | | hidden | 25 | bool | R W | Section |
| time_modify | 53 | nfstime4 | R | Section 5.8.2.43 | | | | | | 5.8.2.15 |
| time_modify_set | 54 | settime4 | W | Section 5.8.2.44 | +--------------------+----+--------------------+-----+-------------+
+--------------------+----+----------------+-----+------------------+ | homogeneous | 26 | bool | R | Section |
| | | | | 5.8.2.16 |
Table 3 +--------------------+----+--------------------+-----+-------------+
| layout_alignment | 66 | uint32_t | R | Section |
| | | | | 5.12.2 |
+--------------------+----+--------------------+-----+-------------+
| layout_blksize | 65 | uint32_t | R | Section |
| | | | | 5.12.3 |
+--------------------+----+--------------------+-----+-------------+
| layout_hint | 63 | layouthint4 | W | Section |
| | | | | 5.12.4 |
+--------------------+----+--------------------+-----+-------------+
| layout_type | 64 | layouttype4<> | R | Section |
| | | | | 5.12.5 |
+--------------------+----+--------------------+-----+-------------+
| maxfilesize | 27 | uint64_t | R | Section |
| | | | | 5.8.2.17 |
+--------------------+----+--------------------+-----+-------------+
| maxlink | 28 | uint32_t | R | Section |
| | | | | 5.8.2.18 |
+--------------------+----+--------------------+-----+-------------+
| maxname | 29 | uint32_t | R | Section |
| | | | | 5.8.2.19 |
+--------------------+----+--------------------+-----+-------------+
| maxread | 30 | uint64_t | R | Section |
| | | | | 5.8.2.20 |
+--------------------+----+--------------------+-----+-------------+
| maxwrite | 31 | uint64_t | R | Section |
| | | | | 5.8.2.21 |
+--------------------+----+--------------------+-----+-------------+
| mdsthreshold | 68 | mdsthreshold4 | R | Section |
| | | | | 5.12.6 |
+--------------------+----+--------------------+-----+-------------+
| mimetype | 32 | utf8str_cs | R W | Section |
| | | | | 5.8.2.22 |
+--------------------+----+--------------------+-----+-------------+
| mode | 33 | mode4 | R W | Section |
| | | | | 6.2.4 |
+--------------------+----+--------------------+-----+-------------+
| mode_set_masked | 74 | mode_masked4 | W | Section |
| | | | | 6.2.5 |
+--------------------+----+--------------------+-----+-------------+
| mounted_on_fileid | 55 | uint64_t | R | Section |
| | | | | 5.8.2.23 |
+--------------------+----+--------------------+-----+-------------+
| no_trunc | 34 | bool | R | Section |
| | | | | 5.8.2.24 |
+--------------------+----+--------------------+-----+-------------+
| numlinks | 35 | uint32_t | R | Section |
| | | | | 5.8.2.25 |
+--------------------+----+--------------------+-----+-------------+
| owner | 36 | utf8str_mixed | R W | Section |
| | | | | 5.8.2.26 |
+--------------------+----+--------------------+-----+-------------+
| owner_group | 37 | utf8str_mixed | R W | Section |
| | | | | 5.8.2.27 |
+--------------------+----+--------------------+-----+-------------+
| quota_avail_hard | 38 | uint64_t | R | Section |
| | | | | 5.8.2.28 |
+--------------------+----+--------------------+-----+-------------+
| quota_avail_soft | 39 | uint64_t | R | Section |
| | | | | 5.8.2.29 |
+--------------------+----+--------------------+-----+-------------+
| quota_used | 40 | uint64_t | R | Section |
| | | | | 5.8.2.30 |
+--------------------+----+--------------------+-----+-------------+
| rawdev | 41 | specdata4 | R | Section |
| | | | | 5.8.2.31 |
+--------------------+----+--------------------+-----+-------------+
| retentevt_get | 71 | retention_get4 | R | Section |
| | | | | 5.13.3 |
+--------------------+----+--------------------+-----+-------------+
| retentevt_set | 72 | retention_set4 | W | Section |
| | | | | 5.13.4 |
+--------------------+----+--------------------+-----+-------------+
| retention_get | 69 | retention_get4 | R | Section |
| | | | | 5.13.1 |
+--------------------+----+--------------------+-----+-------------+
| retention_hold | 73 | uint64_t | R W | Section |
| | | | | 5.13.5 |
+--------------------+----+--------------------+-----+-------------+
| retention_set | 70 | retention_set4 | W | Section |
| | | | | 5.13.2 |
+--------------------+----+--------------------+-----+-------------+
| sacl | 59 | nfsacl41 | R W | Section |
| | | | | 6.2.3 |
+--------------------+----+--------------------+-----+-------------+
| space_avail | 42 | uint64_t | R | Section |
| | | | | 5.8.2.32 |
+--------------------+----+--------------------+-----+-------------+
| space_free | 43 | uint64_t | R | Section |
| | | | | 5.8.2.33 |
+--------------------+----+--------------------+-----+-------------+
| space_total | 44 | uint64_t | R | Section |
| | | | | 5.8.2.34 |
+--------------------+----+--------------------+-----+-------------+
| space_used | 45 | uint64_t | R | Section |
| | | | | 5.8.2.35 |
+--------------------+----+--------------------+-----+-------------+
| system | 46 | bool | R W | Section |
| | | | | 5.8.2.36 |
+--------------------+----+--------------------+-----+-------------+
| time_access | 47 | nfstime4 | R | Section |
| | | | | 5.8.2.37 |
+--------------------+----+--------------------+-----+-------------+
| time_access_set | 48 | settime4 | W | Section |
| | | | | 5.8.2.38 |
+--------------------+----+--------------------+-----+-------------+
| time_backup | 49 | nfstime4 | R W | Section |
| | | | | 5.8.2.39 |
+--------------------+----+--------------------+-----+-------------+
| time_create | 50 | nfstime4 | R W | Section |
| | | | | 5.8.2.40 |
+--------------------+----+--------------------+-----+-------------+
| time_delta | 51 | nfstime4 | R | Section |
| | | | | 5.8.2.41 |
+--------------------+----+--------------------+-----+-------------+
| time_metadata | 52 | nfstime4 | R | Section |
| | | | | 5.8.2.42 |
+--------------------+----+--------------------+-----+-------------+
| time_modify | 53 | nfstime4 | R | Section |
| | | | | 5.8.2.43 |
+--------------------+----+--------------------+-----+-------------+
| time_modify_set | 54 | settime4 | W | Section |
| | | | | 5.8.2.44 |
+--------------------+----+--------------------+-----+-------------+
* fs_locations_info4 Table 5
5.8. Attribute Definitions 5.8. Attribute Definitions
5.8.1. Definitions of REQUIRED Attributes 5.8.1. Definitions of REQUIRED Attributes
5.8.1.1. Attribute 0: supported_attrs 5.8.1.1. Attribute 0: supported_attrs
The bit vector that would retrieve all REQUIRED and RECOMMENDED The bit vector that would retrieve all REQUIRED and RECOMMENDED
attributes that are supported for this object. The scope of this attributes that are supported for this object. The scope of this
attribute applies to all objects with a matching fsid. attribute applies to all objects with a matching fsid.
5.8.1.2. Attribute 1: type 5.8.1.2. Attribute 1: type
Designates the type of an object in terms of one of a number of Designates the type of an object in terms of one of a number of
special constants: special constants:
o NF4REG designates a regular file. * NF4REG designates a regular file.
o NF4DIR designates a directory. * NF4DIR designates a directory.
o NF4BLK designates a block device special file. * NF4BLK designates a block device special file.
o NF4CHR designates a character device special file. * NF4CHR designates a character device special file.
o NF4LNK designates a symbolic link. * NF4LNK designates a symbolic link.
o NF4SOCK designates a named socket special file. * NF4SOCK designates a named socket special file.
o NF4FIFO designates a fifo special file. * NF4FIFO designates a fifo special file.
o NF4ATTRDIR designates a named attribute directory. * NF4ATTRDIR designates a named attribute directory.
o NF4NAMEDATTR designates a named attribute. * NF4NAMEDATTR designates a named attribute.
Within the explanatory text and operation descriptions, the following Within the explanatory text and operation descriptions, the following
phrases will be used with the meanings given below: phrases will be used with the meanings given below:
o The phrase "is a directory" means that the object's type attribute * The phrase "is a directory" means that the object's type attribute
is NF4DIR or NF4ATTRDIR. is NF4DIR or NF4ATTRDIR.
o The phrase "is a special file" means that the object's type * The phrase "is a special file" means that the object's type
attribute is NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO. attribute is NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO.
o The phrases "is an ordinary file" and "is a regular file" mean * The phrases "is an ordinary file" and "is a regular file" mean
that the object's type attribute is NF4REG or NF4NAMEDATTR. that the object's type attribute is NF4REG or NF4NAMEDATTR.
5.8.1.3. Attribute 2: fh_expire_type 5.8.1.3. Attribute 2: fh_expire_type
Server uses this to specify filehandle expiration behavior to the Server uses this to specify filehandle expiration behavior to the
client. See Section 4 for additional description. client. See Section 4 for additional description.
5.8.1.4. Attribute 3: change 5.8.1.4. Attribute 3: change
A value created by the server that the client can use to determine if A value created by the server that the client can use to determine if
skipping to change at page 120, line 27 skipping to change at line 5832
5.8.2.44. Attribute 54: time_modify_set 5.8.2.44. Attribute 54: time_modify_set
Sets the time of last modification to the object. SETATTR use only. Sets the time of last modification to the object. SETATTR use only.
5.9. Interpreting owner and owner_group 5.9. Interpreting owner and owner_group
The RECOMMENDED attributes "owner" and "owner_group" (and also users The RECOMMENDED attributes "owner" and "owner_group" (and also users
and groups within the "acl" attribute) are represented in terms of a and groups within the "acl" attribute) are represented in terms of a
UTF-8 string. To avoid a representation that is tied to a particular UTF-8 string. To avoid a representation that is tied to a particular
underlying implementation at the client or server, the use of the underlying implementation at the client or server, the use of the
UTF-8 string has been chosen. Note that Section 6.1 of RFC 2624 [52] UTF-8 string has been chosen. Note that Section 6.1 of RFC 2624 [53]
provides additional rationale. It is expected that the client and provides additional rationale. It is expected that the client and
server will have their own local representation of owner and server will have their own local representation of owner and
owner_group that is used for local storage or presentation to the end owner_group that is used for local storage or presentation to the end
user. Therefore, it is expected that when these attributes are user. Therefore, it is expected that when these attributes are
transferred between the client and server, the local representation transferred between the client and server, the local representation
is translated to a syntax of the form "user@dns_domain". This will is translated to a syntax of the form "user@dns_domain". This will
allow for a client and server that do not use the same local allow for a client and server that do not use the same local
representation the ability to translate to a common syntax that can representation the ability to translate to a common syntax that can
be interpreted by both. be interpreted by both.
skipping to change at page 126, line 17 skipping to change at line 6107
If retention is enabled, with no duration specified in either this If retention is enabled, with no duration specified in either this
SETATTR or a previous SETATTR, the duration defaults to zero seconds. SETATTR or a previous SETATTR, the duration defaults to zero seconds.
The server MAY restrict the enabling of retention or the duration of The server MAY restrict the enabling of retention or the duration of
retention on the basis of the ACE4_WRITE_RETENTION ACL permission. retention on the basis of the ACE4_WRITE_RETENTION ACL permission.
The enabling of retention MUST NOT prevent the enabling of event- The enabling of retention MUST NOT prevent the enabling of event-
based retention or the modification of the retention_hold attribute. based retention or the modification of the retention_hold attribute.
The following rules apply to both the retention_set and retentevt_set The following rules apply to both the retention_set and retentevt_set
attributes. attributes.
o As long as retention is not enabled, the client is permitted to * As long as retention is not enabled, the client is permitted to
decrease the duration. decrease the duration.
o The duration can always be set to an equal or higher value, even * The duration can always be set to an equal or higher value, even
if retention is enabled. Note that once retention is enabled, the if retention is enabled. Note that once retention is enabled, the
actual duration (as returned by the retention_get or retentevt_get actual duration (as returned by the retention_get or retentevt_get
attributes; see Section 5.13.1 or Section 5.13.3) is constantly attributes; see Section 5.13.1 or Section 5.13.3) is constantly
counting down to zero (one unit per second), unless the duration counting down to zero (one unit per second), unless the duration
was set to RET4_DURATION_INFINITE. Thus, it will not be possible was set to RET4_DURATION_INFINITE. Thus, it will not be possible
for the client to precisely extend the duration on a file that has for the client to precisely extend the duration on a file that has
retention enabled. retention enabled.
o While retention is enabled, attempts to disable retention or * While retention is enabled, attempts to disable retention or
decrease the retention's duration MUST fail with the error decrease the retention's duration MUST fail with the error
NFS4ERR_INVAL. NFS4ERR_INVAL.
o If the principal attempting to change retention_set or * If the principal attempting to change retention_set or
retentevt_set does not have ACE4_WRITE_RETENTION permissions, the retentevt_set does not have ACE4_WRITE_RETENTION permissions, the
attempt MUST fail with NFS4ERR_ACCESS. attempt MUST fail with NFS4ERR_ACCESS.
5.13.3. Attribute 71: retentevt_get 5.13.3. Attribute 71: retentevt_get
Gets the event-based retention duration, and if enabled, the event- Gets the event-based retention duration, and if enabled, the event-
based retention begin time of the file object. This attribute is based retention begin time of the file object. This attribute is
like retention_get, but refers to event-based retention. The event like retention_get, but refers to event-based retention. The event
that triggers event-based retention is not defined by the NFSv4.1 that triggers event-based retention is not defined by the NFSv4.1
specification. specification.
skipping to change at page 127, line 46 skipping to change at line 6184
"sacl", "aclsupport", "mode", and "mode_set_masked" file attributes "sacl", "aclsupport", "mode", and "mode_set_masked" file attributes
and their interactions. Note that file attributes may apply to any and their interactions. Note that file attributes may apply to any
file system object. file system object.
6.1. Goals 6.1. Goals
ACLs and modes represent two well-established models for specifying ACLs and modes represent two well-established models for specifying
permissions. This section specifies requirements that attempt to permissions. This section specifies requirements that attempt to
meet the following goals: meet the following goals:
o If a server supports the mode attribute, it should provide * If a server supports the mode attribute, it should provide
reasonable semantics to clients that only set and retrieve the reasonable semantics to clients that only set and retrieve the
mode attribute. mode attribute.
o If a server supports ACL attributes, it should provide reasonable * If a server supports ACL attributes, it should provide reasonable
semantics to clients that only set and retrieve those attributes. semantics to clients that only set and retrieve those attributes.
o On servers that support the mode attribute, if ACL attributes have * On servers that support the mode attribute, if ACL attributes have
never been set on an object, via inheritance or explicitly, the never been set on an object, via inheritance or explicitly, the
behavior should be traditional UNIX-like behavior. behavior should be traditional UNIX-like behavior.
o On servers that support the mode attribute, if the ACL attributes * On servers that support the mode attribute, if the ACL attributes
have been previously set on an object, either explicitly or via have been previously set on an object, either explicitly or via
inheritance: inheritance:
* Setting only the mode attribute should effectively control the - Setting only the mode attribute should effectively control the
traditional UNIX-like permissions of read, write, and execute traditional UNIX-like permissions of read, write, and execute
on owner, owner_group, and other. on owner, owner_group, and other.
* Setting only the mode attribute should provide reasonable - Setting only the mode attribute should provide reasonable
security. For example, setting a mode of 000 should be enough security. For example, setting a mode of 000 should be enough
to ensure that future OPEN operations for to ensure that future OPEN operations for
OPEN4_SHARE_ACCESS_READ or OPEN4_SHARE_ACCESS_WRITE by any OPEN4_SHARE_ACCESS_READ or OPEN4_SHARE_ACCESS_WRITE by any
principal fail, regardless of a previously existing or principal fail, regardless of a previously existing or
inherited ACL. inherited ACL.
o NFSv4.1 may introduce different semantics relating to the mode and * NFSv4.1 may introduce different semantics relating to the mode and
ACL attributes, but it does not render invalid any previously ACL attributes, but it does not render invalid any previously
existing implementations. Additionally, this section provides existing implementations. Additionally, this section provides
clarifications based on previous implementations and discussions clarifications based on previous implementations and discussions
around them. around them.
o On servers that support both the mode and the acl or dacl * On servers that support both the mode and the acl or dacl
attributes, the server must keep the two consistent with each attributes, the server must keep the two consistent with each
other. The value of the mode attribute (with the exception of the other. The value of the mode attribute (with the exception of the
three high-order bits described in Section 6.2.4) must be three high-order bits described in Section 6.2.4) must be
determined entirely by the value of the ACL, so that use of the determined entirely by the value of the ACL, so that use of the
mode is never required for anything other than setting the three mode is never required for anything other than setting the three
high-order bits. See Section 6.4.1 for exact requirements. high-order bits. See Section 6.4.1 for exact requirements.
o When a mode attribute is set on an object, the ACL attributes may * When a mode attribute is set on an object, the ACL attributes may
need to be modified in order to not conflict with the new mode. need to be modified in order to not conflict with the new mode.
In such cases, it is desirable that the ACL keep as much In such cases, it is desirable that the ACL keep as much
information as possible. This includes information about information as possible. This includes information about
inheritance, AUDIT and ALARM ACEs, and permissions granted and inheritance, AUDIT and ALARM ACEs, and permissions granted and
denied that do not conflict with the new mode. denied that do not conflict with the new mode.
6.2. File Attributes Discussion 6.2. File Attributes Discussion
6.2.1. Attribute 12: acl 6.2.1. Attribute 12: acl
skipping to change at page 131, line 5 skipping to change at line 6320
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000;
const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001;
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002;
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003;
Only the ALLOWED and DENIED bits may be used in the dacl attribute, Only the ALLOWED and DENIED bits may be used in the dacl attribute,
and only the AUDIT and ALARM bits may be used in the sacl attribute. and only the AUDIT and ALARM bits may be used in the sacl attribute.
All four are permitted in the acl attribute. All four are permitted in the acl attribute.
+------------------------------+--------------+---------------------+ +==============================+==============+=====================+
| Value | Abbreviation | Description | | Value | Abbreviation | Description |
+------------------------------+--------------+---------------------+ +==============================+==============+=====================+
| ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants | | ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants |
| | | the access defined | | | | the access |
| | | in acemask4 to the | | | | defined in |
| | | file or directory. | | | | acemask4 to the |
| | | file or |
| | | directory. |
+------------------------------+--------------+---------------------+
| ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies | | ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies |
| | | the access defined | | | | the access |
| | | in acemask4 to the | | | | defined in |
| | | file or directory. | | | | acemask4 to the |
| | | file or |
| | | directory. |
+------------------------------+--------------+---------------------+
| ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | Log (in a system- | | ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | Log (in a system- |
| | | dependent way) any | | | | dependent way) |
| | | access attempt to a | | | | any access |
| | | file or directory | | | | attempt to a file |
| | | that uses any of | | | | or directory that |
| | | the access methods | | | | uses any of the |
| | | access methods |
| | | specified in | | | | specified in |
| | | acemask4. | | | | acemask4. |
+------------------------------+--------------+---------------------+
| ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generate an alarm | | ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generate an alarm |
| | | (in a system- | | | | (in a system- |
| | | dependent way) when | | | | dependent way) |
| | | any access attempt | | | | when any access |
| | | is made to a file | | | | attempt is made |
| | | or directory for | | | | to a file or |
| | | the access methods | | | | directory for the |
| | | access methods |
| | | specified in | | | | specified in |
| | | acemask4. | | | | acemask4. |
+------------------------------+--------------+---------------------+ +------------------------------+--------------+---------------------+
Table 6
The "Abbreviation" column denotes how the types will be referred to The "Abbreviation" column denotes how the types will be referred to
throughout the rest of this section. throughout the rest of this section.
6.2.1.2. Attribute 13: aclsupport 6.2.1.2. Attribute 13: aclsupport
A server need not support all of the above ACE types. This attribute A server need not support all of the above ACE types. This attribute
indicates which ACE types are supported for the current file system. indicates which ACE types are supported for the current file system.
The bitmask constants used to represent the above definitions within The bitmask constants used to represent the above definitions within
the aclsupport attribute are as follows: the aclsupport attribute are as follows:
skipping to change at page 134, line 39 skipping to change at line 6500
The ability to modify a file's data, but only starting at EOF. The ability to modify a file's data, but only starting at EOF.
This allows for the notion of append-only files, by allowing This allows for the notion of append-only files, by allowing
ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to the same user ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to the same user
or group. If a file has an ACL such as the one described above or group. If a file has an ACL such as the one described above
and a WRITE request is made for somewhere other than EOF, the and a WRITE request is made for somewhere other than EOF, the
server SHOULD return NFS4ERR_ACCESS. server SHOULD return NFS4ERR_ACCESS.
ACE4_ADD_SUBDIRECTORY ACE4_ADD_SUBDIRECTORY
Operation(s) affected: Operation(s) affected:
CREATE CREATE
RENAME RENAME
Discussion: Discussion:
Permission to create a subdirectory in a directory. The CREATE Permission to create a subdirectory in a directory. The CREATE
operation is affected when nfs_ftype4 is NF4DIR. The RENAME operation is affected when nfs_ftype4 is NF4DIR. The RENAME
operation is always affected. operation is always affected.
ACE4_READ_NAMED_ATTRS ACE4_READ_NAMED_ATTRS
Operation(s) affected:
Operation(s) affected:
OPENATTR OPENATTR
Discussion: Discussion:
Permission to read the named attributes of a file or to look up Permission to read the named attributes of a file or to look up
the named attribute directory. OPENATTR is affected when it is the named attribute directory. OPENATTR is affected when it is
not used to create a named attribute directory. This is when not used to create a named attribute directory. This is when
1) createdir is TRUE, but a named attribute directory already 1) createdir is TRUE, but a named attribute directory already
exists, or 2) createdir is FALSE. exists, or 2) createdir is FALSE.
ACE4_WRITE_NAMED_ATTRS ACE4_WRITE_NAMED_ATTRS
Operation(s) affected: Operation(s) affected:
OPENATTR OPENATTR
Discussion: Discussion:
Permission to write the named attributes of a file or to create Permission to write the named attributes of a file or to create
a named attribute directory. OPENATTR is affected when it is a named attribute directory. OPENATTR is affected when it is
used to create a named attribute directory. This is when used to create a named attribute directory. This is when
createdir is TRUE and no named attribute directory exists. The createdir is TRUE and no named attribute directory exists. The
ability to check whether or not a named attribute directory ability to check whether or not a named attribute directory
exists depends on the ability to look it up; therefore, users exists depends on the ability to look it up; therefore, users
also need the ACE4_READ_NAMED_ATTRS permission in order to also need the ACE4_READ_NAMED_ATTRS permission in order to
create a named attribute directory. create a named attribute directory.
ACE4_EXECUTE ACE4_EXECUTE
skipping to change at page 136, line 21 skipping to change at line 6568
and ACE4_READ_DATA bits identically when deciding to permit a and ACE4_READ_DATA bits identically when deciding to permit a
READ operation, it SHOULD still allow the two bits to be set READ operation, it SHOULD still allow the two bits to be set
independently in ACLs, and MUST distinguish between them when independently in ACLs, and MUST distinguish between them when
replying to ACCESS operations. In particular, servers SHOULD replying to ACCESS operations. In particular, servers SHOULD
NOT silently turn on one of the two bits when the other is set, NOT silently turn on one of the two bits when the other is set,
as that would make it impossible for the client to correctly as that would make it impossible for the client to correctly
enforce the distinction between read and execute permissions. enforce the distinction between read and execute permissions.
As an example, following a SETATTR of the following ACL: As an example, following a SETATTR of the following ACL:
nfsuser:ACE4_EXECUTE:ALLOW nfsuser:ACE4_EXECUTE:ALLOW
A subsequent GETATTR of ACL for that file SHOULD return: A subsequent GETATTR of ACL for that file SHOULD return:
nfsuser:ACE4_EXECUTE:ALLOW nfsuser:ACE4_EXECUTE:ALLOW
Rather than: Rather than:
nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW
ACE4_EXECUTE ACE4_EXECUTE
Operation(s) affected: Operation(s) affected:
LOOKUP LOOKUP
Discussion: Discussion:
Permission to traverse/search a directory. Permission to traverse/search a directory.
ACE4_DELETE_CHILD ACE4_DELETE_CHILD
Operation(s) affected: Operation(s) affected:
REMOVE REMOVE
RENAME RENAME
Discussion: Discussion:
Permission to delete a file or directory within a directory. Permission to delete a file or directory within a directory.
See Section 6.2.1.3.2 for information on ACE4_DELETE and See Section 6.2.1.3.2 for information on ACE4_DELETE and
ACE4_DELETE_CHILD interact. ACE4_DELETE_CHILD interact.
ACE4_READ_ATTRIBUTES ACE4_READ_ATTRIBUTES
Operation(s) affected: Operation(s) affected:
GETATTR of file system object attributes GETATTR of file system object attributes
VERIFY VERIFY
NVERIFY NVERIFY
READDIR READDIR
Discussion: Discussion:
The ability to read basic attributes (non-ACLs) of a file. On The ability to read basic attributes (non-ACLs) of a file. On
a UNIX system, basic attributes can be thought of as the stat- a UNIX system, basic attributes can be thought of as the stat-
level attributes. Allowing this access mask bit would mean level attributes. Allowing this access mask bit would mean
that the entity can execute "ls -l" and stat. If a READDIR that the entity can execute "ls -l" and stat. If a READDIR
operation requests attributes, this mask must be allowed for operation requests attributes, this mask must be allowed for
the READDIR to succeed. the READDIR to succeed.
ACE4_WRITE_ATTRIBUTES ACE4_WRITE_ATTRIBUTES
Operation(s) affected: Operation(s) affected:
skipping to change at page 142, line 12 skipping to change at line 6825
trigger log or alarm events. Such ACEs only take effect once they trigger log or alarm events. Such ACEs only take effect once they
are applied (with this bit cleared) to newly created files and are applied (with this bit cleared) to newly created files and
directories as specified by the ACE4_FILE_INHERIT_ACE and directories as specified by the ACE4_FILE_INHERIT_ACE and
ACE4_DIRECTORY_INHERIT_ACE flags. ACE4_DIRECTORY_INHERIT_ACE flags.
If this flag is present on an ACE, but neither If this flag is present on an ACE, but neither
ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present, ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present,
then an operation attempting to set such an attribute SHOULD fail then an operation attempting to set such an attribute SHOULD fail
with NFS4ERR_ATTRNOTSUPP. with NFS4ERR_ATTRNOTSUPP.
ACE4_SUCCESSFUL_ACCESS_ACE_FLAG ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG
ACE4_FAILED_ACCESS_ACE_FLAG
The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and
ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on
ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE
(ALARM) ACE types. If during the processing of the file's ACL, (ALARM) ACE types. If during the processing of the file's ACL,
the server encounters an AUDIT or ALARM ACE that matches the the server encounters an AUDIT or ALARM ACE that matches the
principal attempting the OPEN, the server notes that fact, and the principal attempting the OPEN, the server notes that fact, and the
presence, if any, of the SUCCESS and FAILED flags encountered in presence, if any, of the SUCCESS and FAILED flags encountered in
the AUDIT or ALARM ACE. Once the server completes the ACL the AUDIT or ALARM ACE. Once the server completes the ACL
processing, it then notes if the operation succeeded or failed. processing, it then notes if the operation succeeded or failed.
If the operation succeeded, and if the SUCCESS flag was set for a If the operation succeeded, and if the SUCCESS flag was set for a
skipping to change at page 143, line 20 skipping to change at line 6878
which. which.
There are several special identifiers that need to be understood There are several special identifiers that need to be understood
universally, rather than in the context of a particular DNS domain. universally, rather than in the context of a particular DNS domain.
Some of these identifiers cannot be understood when an NFS client Some of these identifiers cannot be understood when an NFS client
accesses the server, but have meaning when a local process accesses accesses the server, but have meaning when a local process accesses
the file. The ability to display and modify these permissions is the file. The ability to display and modify these permissions is
permitted over NFS, even if none of the access methods on the server permitted over NFS, even if none of the access methods on the server
understands the identifiers. understands the identifiers.
+---------------+---------------------------------------------------+ +===============+==================================================+
| Who | Description | | Who | Description |
+---------------+---------------------------------------------------+ +===============+==================================================+
| OWNER | The owner of the file. | | OWNER | The owner of the file. |
| GROUP | The group associated with the file. | +---------------+--------------------------------------------------+
| EVERYONE | The world, including the owner and owning group. | | GROUP | The group associated with the file. |
| INTERACTIVE | Accessed from an interactive terminal. | +---------------+--------------------------------------------------+
| NETWORK | Accessed via the network. | | EVERYONE | The world, including the owner and owning group. |
| DIALUP | Accessed as a dialup user to the server. | +---------------+--------------------------------------------------+
| BATCH | Accessed from a batch job. | | INTERACTIVE | Accessed from an interactive terminal. |
| ANONYMOUS | Accessed without any authentication. | +---------------+--------------------------------------------------+
| AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS). | | NETWORK | Accessed via the network. |
| SERVICE | Access from a system service. | +---------------+--------------------------------------------------+
+---------------+---------------------------------------------------+ | DIALUP | Accessed as a dialup user to the server. |
+---------------+--------------------------------------------------+
| BATCH | Accessed from a batch job. |
+---------------+--------------------------------------------------+
| ANONYMOUS | Accessed without any authentication. |
+---------------+--------------------------------------------------+
| AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS). |
+---------------+--------------------------------------------------+
| SERVICE | Access from a system service. |
+---------------+--------------------------------------------------+
Table 4 Table 7
To avoid conflict, these special identifiers are distinguished by an To avoid conflict, these special identifiers are distinguished by an
appended "@" and should appear in the form "xxxx@" (with no domain appended "@" and should appear in the form "xxxx@" (with no domain
name after the "@"), for example, ANONYMOUS@. name after the "@"), for example, ANONYMOUS@.
The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these
special identifiers. When encoding entries with these special special identifiers. When encoding entries with these special
identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero. identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero.
6.2.1.5.1. Discussion of EVERYONE@ 6.2.1.5.1. Discussion of EVERYONE@
skipping to change at page 145, line 49 skipping to change at line 7007
sections, especially Section 6.4. sections, especially Section 6.4.
6.3.1. Interpreting an ACL 6.3.1. Interpreting an ACL
6.3.1.1. Server Considerations 6.3.1.1. Server Considerations
The server uses the algorithm described in Section 6.2.1 to determine The server uses the algorithm described in Section 6.2.1 to determine
whether an ACL allows access to an object. However, the ACL might whether an ACL allows access to an object. However, the ACL might
not be the sole determiner of access. For example: not be the sole determiner of access. For example:
o In the case of a file system exported as read-only, the server may * In the case of a file system exported as read-only, the server may
deny write access even though an object's ACL grants it. deny write access even though an object's ACL grants it.
o Server implementations MAY grant ACE4_WRITE_ACL and ACE4_READ_ACL * Server implementations MAY grant ACE4_WRITE_ACL and ACE4_READ_ACL
permissions to prevent a situation from arising in which there is permissions to prevent a situation from arising in which there is
no valid way to ever modify the ACL. no valid way to ever modify the ACL.
o All servers will allow a user the ability to read the data of the * All servers will allow a user the ability to read the data of the
file when only the execute permission is granted (i.e., if the ACL file when only the execute permission is granted (i.e., if the ACL
denies the user the ACE4_READ_DATA access and allows the user denies the user the ACE4_READ_DATA access and allows the user
ACE4_EXECUTE, the server will allow the user to read the data of ACE4_EXECUTE, the server will allow the user to read the data of
the file). the file).
o Many servers have the notion of owner-override in which the owner * Many servers have the notion of owner-override in which the owner
of the object is allowed to override accesses that are denied by of the object is allowed to override accesses that are denied by
the ACL. This may be helpful, for example, to allow users the ACL. This may be helpful, for example, to allow users
continued access to open files on which the permissions have continued access to open files on which the permissions have
changed. changed.
o Many servers have the notion of a "superuser" that has privileges * Many servers have the notion of a "superuser" that has privileges
beyond an ordinary user. The superuser may be able to read or beyond an ordinary user. The superuser may be able to read or
write data or metadata in ways that would not be permitted by the write data or metadata in ways that would not be permitted by the
ACL. ACL.
o A retention attribute might also block access otherwise allowed by * A retention attribute might also block access otherwise allowed by
ACLs (see Section 5.13). ACLs (see Section 5.13).
6.3.1.2. Client Considerations 6.3.1.2. Client Considerations
Clients SHOULD NOT do their own access checks based on their Clients SHOULD NOT do their own access checks based on their
interpretation of the ACL, but rather use the OPEN and ACCESS interpretation of the ACL, but rather use the OPEN and ACCESS
operations to do access checks. This allows the client to act on the operations to do access checks. This allows the client to act on the
results of having the server determine whether or not access should results of having the server determine whether or not access should
be granted based on its interpretation of the ACL. be granted based on its interpretation of the ACL.
skipping to change at page 158, line 20 skipping to change at line 7597
clients should use strong security mechanisms to access the pseudo clients should use strong security mechanisms to access the pseudo
file system in order to prevent man-in-the-middle attacks. file system in order to prevent man-in-the-middle attacks.
8. State Management 8. State Management
Integrating locking into the NFS protocol necessarily causes it to be Integrating locking into the NFS protocol necessarily causes it to be
stateful. With the inclusion of such features as share reservations, stateful. With the inclusion of such features as share reservations,
file and directory delegations, recallable layouts, and support for file and directory delegations, recallable layouts, and support for
mandatory byte-range locking, the protocol becomes substantially more mandatory byte-range locking, the protocol becomes substantially more
dependent on proper management of state than the traditional dependent on proper management of state than the traditional
combination of NFS and NLM (Network Lock Manager) [53]. These combination of NFS and NLM (Network Lock Manager) [54]. These
features include expanded locking facilities, which provide some features include expanded locking facilities, which provide some
measure of inter-client exclusion, but the state also offers features measure of inter-client exclusion, but the state also offers features
not readily providable using a stateless model. There are three not readily providable using a stateless model. There are three
components to making this state manageable: components to making this state manageable:
o clear division between client and server * clear division between client and server
o ability to reliably detect inconsistency in state between client * ability to reliably detect inconsistency in state between client
and server and server
o simple and robust recovery mechanisms * simple and robust recovery mechanisms
In this model, the server owns the state information. The client In this model, the server owns the state information. The client
requests changes in locks and the server responds with the changes requests changes in locks and the server responds with the changes
made. Non-client-initiated changes in locking state are infrequent. made. Non-client-initiated changes in locking state are infrequent.
The client receives prompt notification of such changes and can The client receives prompt notification of such changes and can
adjust its view of the locking state to reflect the server's changes. adjust its view of the locking state to reflect the server's changes.
Individual pieces of state created by the server and passed to the Individual pieces of state created by the server and passed to the
client at its request are represented by 128-bit stateids. These client at its request are represented by 128-bit stateids. These
stateids may represent a particular open file, a set of byte-range stateids may represent a particular open file, a set of byte-range
skipping to change at page 160, line 14 skipping to change at line 7684
8.2.1. Stateid Types 8.2.1. Stateid Types
With the exception of special stateids (see Section 8.2.3), each With the exception of special stateids (see Section 8.2.3), each
stateid represents locking objects of one of a set of types defined stateid represents locking objects of one of a set of types defined
by the NFSv4.1 protocol. Note that in all these cases, where we by the NFSv4.1 protocol. Note that in all these cases, where we
speak of guarantee, it is understood there are situations such as a speak of guarantee, it is understood there are situations such as a
client restart, or lock revocation, that allow the guarantee to be client restart, or lock revocation, that allow the guarantee to be
voided. voided.
o Stateids may represent opens of files. * Stateids may represent opens of files.
Each stateid in this case represents the OPEN state for a given Each stateid in this case represents the OPEN state for a given
client ID/open-owner/filehandle triple. Such stateids are subject client ID/open-owner/filehandle triple. Such stateids are subject
to change (with consequent incrementing of the stateid's seqid) in to change (with consequent incrementing of the stateid's seqid) in
response to OPENs that result in upgrade and OPEN_DOWNGRADE response to OPENs that result in upgrade and OPEN_DOWNGRADE
operations. operations.
o Stateids may represent sets of byte-range locks. * Stateids may represent sets of byte-range locks.
All locks held on a particular file by a particular owner and All locks held on a particular file by a particular owner and
gotten under the aegis of a particular open file are associated gotten under the aegis of a particular open file are associated
with a single stateid with the seqid being incremented whenever with a single stateid with the seqid being incremented whenever
LOCK and LOCKU operations affect that set of locks. LOCK and LOCKU operations affect that set of locks.
o Stateids may represent file delegations, which are recallable * Stateids may represent file delegations, which are recallable
guarantees by the server to the client that other clients will not guarantees by the server to the client that other clients will not
reference or modify a particular file, until the delegation is reference or modify a particular file, until the delegation is
returned. In NFSv4.1, file delegations may be obtained on both returned. In NFSv4.1, file delegations may be obtained on both
regular and non-regular files. regular and non-regular files.
A stateid represents a single delegation held by a client for a A stateid represents a single delegation held by a client for a
particular filehandle. particular filehandle.
o Stateids may represent directory delegations, which are recallable * Stateids may represent directory delegations, which are recallable
guarantees by the server to the client that other clients will not guarantees by the server to the client that other clients will not
modify the directory, until the delegation is returned. modify the directory, until the delegation is returned.
A stateid represents a single delegation held by a client for a A stateid represents a single delegation held by a client for a
particular directory filehandle. particular directory filehandle.
o Stateids may represent layouts, which are recallable guarantees by * Stateids may represent layouts, which are recallable guarantees by
the server to the client that particular files may be accessed via the server to the client that particular files may be accessed via
an alternate data access protocol at specific locations. Such an alternate data access protocol at specific locations. Such
access is limited to particular sets of byte-ranges and may access is limited to particular sets of byte-ranges and may
proceed until those byte-ranges are reduced or the layout is proceed until those byte-ranges are reduced or the layout is
returned. returned.
A stateid represents the set of all layouts held by a particular A stateid represents the set of all layouts held by a particular
client for a particular filehandle with a given layout type. The client for a particular filehandle with a given layout type. The
seqid is updated as the layouts of that set of byte-ranges change, seqid is updated as the layouts of that set of byte-ranges change,
via layout stateid changing operations such as LAYOUTGET and via layout stateid changing operations such as LAYOUTGET and
skipping to change at page 162, line 43 skipping to change at line 7809
Stateid values whose "other" field is either all zeros or all ones Stateid values whose "other" field is either all zeros or all ones
are reserved. They may not be assigned by the server but have are reserved. They may not be assigned by the server but have
special meanings defined by the protocol. The particular meaning special meanings defined by the protocol. The particular meaning
depends on whether the "other" field is all zeros or all ones and the depends on whether the "other" field is all zeros or all ones and the
specific value of the "seqid" field. specific value of the "seqid" field.
The following combinations of "other" and "seqid" are defined in The following combinations of "other" and "seqid" are defined in
NFSv4.1: NFSv4.1:
o When "other" and "seqid" are both zero, the stateid is treated as * When "other" and "seqid" are both zero, the stateid is treated as
a special anonymous stateid, which can be used in READ, WRITE, and a special anonymous stateid, which can be used in READ, WRITE, and
SETATTR requests to indicate the absence of any OPEN state SETATTR requests to indicate the absence of any OPEN state
associated with the request. When an anonymous stateid value is associated with the request. When an anonymous stateid value is
used and an existing open denies the form of access requested, used and an existing open denies the form of access requested,
then access will be denied to the request. This stateid MUST NOT then access will be denied to the request. This stateid MUST NOT
be used on operations to data servers (Section 13.6). be used on operations to data servers (Section 13.6).
o When "other" and "seqid" are both all ones, the stateid is a * When "other" and "seqid" are both all ones, the stateid is a
special READ bypass stateid. When this value is used in WRITE or special READ bypass stateid. When this value is used in WRITE or
SETATTR, it is treated like the anonymous value. When used in SETATTR, it is treated like the anonymous value. When used in
READ, the server MAY grant access, even if access would normally READ, the server MAY grant access, even if access would normally
be denied to READ operations. This stateid MUST NOT be used on be denied to READ operations. This stateid MUST NOT be used on
operations to data servers. operations to data servers.
o When "other" is zero and "seqid" is one, the stateid represents * When "other" is zero and "seqid" is one, the stateid represents
the current stateid, which is whatever value is the last stateid the current stateid, which is whatever value is the last stateid
returned by an operation within the COMPOUND. In the case of an returned by an operation within the COMPOUND. In the case of an
OPEN, the stateid returned for the open file and not the OPEN, the stateid returned for the open file and not the
delegation is used. The stateid passed to the operation in place delegation is used. The stateid passed to the operation in place
of the special value has its "seqid" value set to zero, except of the special value has its "seqid" value set to zero, except
when the current stateid is used by the operation CLOSE or when the current stateid is used by the operation CLOSE or
OPEN_DOWNGRADE. If there is no operation in the COMPOUND that has OPEN_DOWNGRADE. If there is no operation in the COMPOUND that has
returned a stateid value, the server MUST return the error returned a stateid value, the server MUST return the error
NFS4ERR_BAD_STATEID. As illustrated in Figure 6, if the value of NFS4ERR_BAD_STATEID. As illustrated in Figure 6, if the value of
a current stateid is a special stateid and the stateid of an a current stateid is a special stateid and the stateid of an
operation's arguments has "other" set to zero and "seqid" set to operation's arguments has "other" set to zero and "seqid" set to
one, then the server MUST return the error NFS4ERR_BAD_STATEID. one, then the server MUST return the error NFS4ERR_BAD_STATEID.
o When "other" is zero and "seqid" is NFS4_UINT32_MAX, the stateid * When "other" is zero and "seqid" is NFS4_UINT32_MAX, the stateid
represents a reserved stateid value defined to be invalid. When represents a reserved stateid value defined to be invalid. When
this stateid is used, the server MUST return the error this stateid is used, the server MUST return the error
NFS4ERR_BAD_STATEID. NFS4ERR_BAD_STATEID.
If a stateid value is used that has all zeros or all ones in the If a stateid value is used that has all zeros or all ones in the
"other" field but does not match one of the cases above, the server "other" field but does not match one of the cases above, the server
MUST return the error NFS4ERR_BAD_STATEID. MUST return the error NFS4ERR_BAD_STATEID.
Special stateids, unlike other stateids, are not associated with Special stateids, unlike other stateids, are not associated with
individual client IDs or filehandles and can be used with all valid individual client IDs or filehandles and can be used with all valid
skipping to change at page 164, line 26 skipping to change at line 7887
An "other" value must never be reused for a different purpose (i.e., An "other" value must never be reused for a different purpose (i.e.,
different filehandle, owner, or type of locks) within the context of different filehandle, owner, or type of locks) within the context of
a single client ID. A server may retain the "other" value for the a single client ID. A server may retain the "other" value for the
same purpose beyond the point where it may otherwise be freed, but if same purpose beyond the point where it may otherwise be freed, but if
it does so, it must maintain "seqid" continuity with previous values. it does so, it must maintain "seqid" continuity with previous values.
One mechanism that may be used to satisfy the requirement that the One mechanism that may be used to satisfy the requirement that the
server recognize invalid and out-of-date stateids is for the server server recognize invalid and out-of-date stateids is for the server
to divide the "other" field of the stateid into two fields. to divide the "other" field of the stateid into two fields.
o an index into a table of locking-state structures. * an index into a table of locking-state structures.
o a generation number that is incremented on each allocation of a * a generation number that is incremented on each allocation of a
table entry for a particular use. table entry for a particular use.
And then store in each table entry, And then store in each table entry,
o the client ID with which the stateid is associated. * the client ID with which the stateid is associated.
o the current generation number for the (at most one) valid stateid * the current generation number for the (at most one) valid stateid
sharing this index value. sharing this index value.
o the filehandle of the file on which the locks are taken. * the filehandle of the file on which the locks are taken.
o an indication of the type of stateid (open, byte-range lock, file * an indication of the type of stateid (open, byte-range lock, file
delegation, directory delegation, layout). delegation, directory delegation, layout).
o the last "seqid" value returned corresponding to the current * the last "seqid" value returned corresponding to the current
"other" value. "other" value.
o an indication of the current status of the locks associated with * an indication of the current status of the locks associated with
this stateid, in particular, whether these have been revoked and this stateid, in particular, whether these have been revoked and
if so, for what reason. if so, for what reason.
With this information, an incoming stateid can be validated and the With this information, an incoming stateid can be validated and the
appropriate error returned when necessary. Special and non-special appropriate error returned when necessary. Special and non-special
stateids are handled separately. (See Section 8.2.3 for a discussion stateids are handled separately. (See Section 8.2.3 for a discussion
of special stateids.) of special stateids.)
Note that stateids are implicitly qualified by the current client ID, Note that stateids are implicitly qualified by the current client ID,
as derived from the client ID associated with the current session. as derived from the client ID associated with the current session.
skipping to change at page 165, line 28 skipping to change at line 7937
session and all leased state has been lost, then the session in session and all leased state has been lost, then the session in
question will, although valid, be marked as dead, and any operation question will, although valid, be marked as dead, and any operation
not satisfied by means of the reply cache will receive the error not satisfied by means of the reply cache will receive the error
NFS4ERR_DEADSESSION, and thus not be processed as indicated below. NFS4ERR_DEADSESSION, and thus not be processed as indicated below.
When a stateid is being tested and the "other" field is all zeros or When a stateid is being tested and the "other" field is all zeros or
all ones, a check that the "other" and "seqid" fields match a defined all ones, a check that the "other" and "seqid" fields match a defined
combination for a special stateid is done and the results determined combination for a special stateid is done and the results determined
as follows: as follows:
o If the "other" and "seqid" fields do not match a defined * If the "other" and "seqid" fields do not match a defined
combination associated with a special stateid, the error combination associated with a special stateid, the error
NFS4ERR_BAD_STATEID is returned. NFS4ERR_BAD_STATEID is returned.
o If the special stateid is one designating the current stateid and * If the special stateid is one designating the current stateid and
there is a current stateid, then the current stateid is there is a current stateid, then the current stateid is
substituted for the special stateid and the checks appropriate to substituted for the special stateid and the checks appropriate to
non-special stateids are performed. non-special stateids are performed.
o If the combination is valid in general but is not appropriate to * If the combination is valid in general but is not appropriate to
the context in which the stateid is used (e.g., an all-zero the context in which the stateid is used (e.g., an all-zero
stateid is used when an OPEN stateid is required in a LOCK stateid is used when an OPEN stateid is required in a LOCK
operation), the error NFS4ERR_BAD_STATEID is also returned. operation), the error NFS4ERR_BAD_STATEID is also returned.
o Otherwise, the check is completed and the special stateid is * Otherwise, the check is completed and the special stateid is
accepted as valid. accepted as valid.
When a stateid is being tested, and the "other" field is neither all When a stateid is being tested, and the "other" field is neither all
zeros nor all ones, the following procedure could be used to validate zeros nor all ones, the following procedure could be used to validate
an incoming stateid and return an appropriate error, when necessary, an incoming stateid and return an appropriate error, when necessary,
assuming that the "other" field would be divided into a table index assuming that the "other" field would be divided into a table index
and an entry generation. and an entry generation.
o If the table index field is outside the range of the associated * If the table index field is outside the range of the associated
table, return NFS4ERR_BAD_STATEID. table, return NFS4ERR_BAD_STATEID.
o If the selected table entry is of a different generation than that * If the selected table entry is of a different generation than that
specified in the incoming stateid, return NFS4ERR_BAD_STATEID. specified in the incoming stateid, return NFS4ERR_BAD_STATEID.
o If the selected table entry does not match the current filehandle, * If the selected table entry does not match the current filehandle,
return NFS4ERR_BAD_STATEID. return NFS4ERR_BAD_STATEID.
o If the client ID in the table entry does not match the client ID * If the client ID in the table entry does not match the client ID
associated with the current session, return NFS4ERR_BAD_STATEID. associated with the current session, return NFS4ERR_BAD_STATEID.
o If the stateid represents revoked state, then return * If the stateid represents revoked state, then return
NFS4ERR_EXPIRED, NFS4ERR_ADMIN_REVOKED, or NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, NFS4ERR_ADMIN_REVOKED, or NFS4ERR_DELEG_REVOKED,
as appropriate. as appropriate.
o If the stateid type is not valid for the context in which the * If the stateid type is not valid for the context in which the
stateid appears, return NFS4ERR_BAD_STATEID. Note that a stateid stateid appears, return NFS4ERR_BAD_STATEID. Note that a stateid
may be valid in general, as would be reported by the TEST_STATEID may be valid in general, as would be reported by the TEST_STATEID
operation, but be invalid for a particular operation, as, for operation, but be invalid for a particular operation, as, for
example, when a stateid that doesn't represent byte-range locks is example, when a stateid that doesn't represent byte-range locks is
passed to the non-from_open case of LOCK or to LOCKU, or when a passed to the non-from_open case of LOCK or to LOCKU, or when a
stateid that does not represent an open is passed to CLOSE or stateid that does not represent an open is passed to CLOSE or
OPEN_DOWNGRADE. In such cases, the server MUST return OPEN_DOWNGRADE. In such cases, the server MUST return
NFS4ERR_BAD_STATEID. NFS4ERR_BAD_STATEID.
o If the "seqid" field is not zero and it is greater than the * If the "seqid" field is not zero and it is greater than the
current sequence value corresponding to the current "other" field, current sequence value corresponding to the current "other" field,
return NFS4ERR_BAD_STATEID. return NFS4ERR_BAD_STATEID.
o If the "seqid" field is not zero and it is less than the current * If the "seqid" field is not zero and it is less than the current
sequence value corresponding to the current "other" field, return sequence value corresponding to the current "other" field, return
NFS4ERR_OLD_STATEID. NFS4ERR_OLD_STATEID.
o Otherwise, the stateid is valid and the table entry should contain * Otherwise, the stateid is valid and the table entry should contain
any additional information about the type of stateid and any additional information about the type of stateid and
information associated with that particular type of stateid, such information associated with that particular type of stateid, such
as the associated set of locks, e.g., open-owner and lock-owner as the associated set of locks, e.g., open-owner and lock-owner
information, as well as information on the specific locks, e.g., information, as well as information on the specific locks, e.g.,
open modes and byte-ranges. open modes and byte-ranges.
8.2.5. Stateid Use for I/O Operations 8.2.5. Stateid Use for I/O Operations
Clients performing I/O operations need to select an appropriate Clients performing I/O operations need to select an appropriate
stateid based on the locks (including opens and delegations) held by stateid based on the locks (including opens and delegations) held by
skipping to change at page 167, line 12 skipping to change at line 8016
requests. SETATTR operations that change the file size are treated requests. SETATTR operations that change the file size are treated
like I/O operations in this regard. like I/O operations in this regard.
The following rules, applied in order of decreasing priority, govern The following rules, applied in order of decreasing priority, govern
the selection of the appropriate stateid. In following these rules, the selection of the appropriate stateid. In following these rules,
the client will only consider locks of which it has actually received the client will only consider locks of which it has actually received
notification by an appropriate operation response or callback. Note notification by an appropriate operation response or callback. Note
that the rules are slightly different in the case of I/O to data that the rules are slightly different in the case of I/O to data
servers when file layouts are being used (see Section 13.9.1). servers when file layouts are being used (see Section 13.9.1).
o If the client holds a delegation for the file in question, the * If the client holds a delegation for the file in question, the
delegation stateid SHOULD be used. delegation stateid SHOULD be used.
o Otherwise, if the entity corresponding to the lock-owner (e.g., a * Otherwise, if the entity corresponding to the lock-owner (e.g., a
process) sending the I/O has a byte-range lock stateid for the process) sending the I/O has a byte-range lock stateid for the
associated open file, then the byte-range lock stateid for that associated open file, then the byte-range lock stateid for that
lock-owner and open file SHOULD be used. lock-owner and open file SHOULD be used.
o If there is no byte-range lock stateid, then the OPEN stateid for * If there is no byte-range lock stateid, then the OPEN stateid for
the open file in question SHOULD be used. the open file in question SHOULD be used.
o Finally, if none of the above apply, then a special stateid SHOULD * Finally, if none of the above apply, then a special stateid SHOULD
be used. be used.
Ignoring these rules may result in situations in which the server Ignoring these rules may result in situations in which the server
does not have information necessary to properly process the request. does not have information necessary to properly process the request.
For example, when mandatory byte-range locks are in effect, if the For example, when mandatory byte-range locks are in effect, if the
stateid does not indicate the proper lock-owner, via a lock stateid, stateid does not indicate the proper lock-owner, via a lock stateid,
a request might be avoidably rejected. a request might be avoidably rejected.
The server however should not try to enforce these ordering rules and The server however should not try to enforce these ordering rules and
should use whatever information is available to properly process I/O should use whatever information is available to properly process I/O
skipping to change at page 168, line 43 skipping to change at line 8095
operation, the server MAY renew the lease; this depends on whether operation, the server MAY renew the lease; this depends on whether
any state was revoked as a result of the client's failure to renew any state was revoked as a result of the client's failure to renew
the lease before expiration. the lease before expiration.
Absent other activity that would renew the lease, a COMPOUND Absent other activity that would renew the lease, a COMPOUND
consisting of a single SEQUENCE operation will suffice. The client consisting of a single SEQUENCE operation will suffice. The client
should also take communication-related delays into account and take should also take communication-related delays into account and take
steps to ensure that the renewal messages actually reach the server steps to ensure that the renewal messages actually reach the server
in good time. For example: in good time. For example:
o When trunking is in effect, the client should consider sending * When trunking is in effect, the client should consider sending
multiple requests on different connections, in order to ensure multiple requests on different connections, in order to ensure
that renewal occurs, even in the event of blockage in the path that renewal occurs, even in the event of blockage in the path
used for one of those connections. used for one of those connections.
o Transport retransmission delays might become so large as to * Transport retransmission delays might become so large as to
approach or exceed the length of the lease period. This may be approach or exceed the length of the lease period. This may be
particularly likely when the server is unresponsive due to a particularly likely when the server is unresponsive due to a
restart; see Section 8.4.2.1. If the client implementation is not restart; see Section 8.4.2.1. If the client implementation is not
careful, transport retransmission delays can result in the client careful, transport retransmission delays can result in the client
failing to detect a server restart before the grace period ends. failing to detect a server restart before the grace period ends.
The scenario is that the client is using a transport with The scenario is that the client is using a transport with
exponential backoff, such that the maximum retransmission timeout exponential backoff, such that the maximum retransmission timeout
exceeds both the grace period and the lease_time attribute. A exceeds both the grace period and the lease_time attribute. A
network partition causes the client's connection's retransmission network partition causes the client's connection's retransmission
interval to back off, and even after the partition heals, the next interval to back off, and even after the partition heals, the next
skipping to change at page 169, line 46 skipping to change at line 8146
no active COMPOUND operations on any such sessions. no active COMPOUND operations on any such sessions.
Because the SEQUENCE operation is the basic mechanism to renew a Because the SEQUENCE operation is the basic mechanism to renew a
lease, and because it must be done at least once for each lease lease, and because it must be done at least once for each lease
period, it is the natural mechanism whereby the server will inform period, it is the natural mechanism whereby the server will inform
the client of changes in the lease status that the client needs to be the client of changes in the lease status that the client needs to be
informed of. The client should inspect the status flags informed of. The client should inspect the status flags
(sr_status_flags) returned by sequence and take the appropriate (sr_status_flags) returned by sequence and take the appropriate
action (see Section 18.46.3 for details). action (see Section 18.46.3 for details).
o The status bits SEQ4_STATUS_CB_PATH_DOWN and * The status bits SEQ4_STATUS_CB_PATH_DOWN and
SEQ4_STATUS_CB_PATH_DOWN_SESSION indicate problems with the SEQ4_STATUS_CB_PATH_DOWN_SESSION indicate problems with the
backchannel that the client may need to address in order to backchannel that the client may need to address in order to
receive callback requests. receive callback requests.
o The status bits SEQ4_STATUS_CB_GSS_CONTEXTS_EXPIRING and * The status bits SEQ4_STATUS_CB_GSS_CONTEXTS_EXPIRING and
SEQ4_STATUS_CB_GSS_CONTEXTS_EXPIRED indicate problems with GSS SEQ4_STATUS_CB_GSS_CONTEXTS_EXPIRED indicate problems with GSS
contexts or RPCSEC_GSS handles for the backchannel that the client contexts or RPCSEC_GSS handles for the backchannel that the client
might have to address in order to allow callback requests to be might have to address in order to allow callback requests to be
sent. sent.
o The status bits SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED, * The status bits SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED,
SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED, SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED,
SEQ4_STATUS_ADMIN_STATE_REVOKED, and SEQ4_STATUS_ADMIN_STATE_REVOKED, and
SEQ4_STATUS_RECALLABLE_STATE_REVOKED notify the client of lock SEQ4_STATUS_RECALLABLE_STATE_REVOKED notify the client of lock
revocation events. When these bits are set, the client should use revocation events. When these bits are set, the client should use
TEST_STATEID to find what stateids have been revoked and use TEST_STATEID to find what stateids have been revoked and use
FREE_STATEID to acknowledge loss of the associated state. FREE_STATEID to acknowledge loss of the associated state.
o The status bit SEQ4_STATUS_LEASE_MOVE indicates that * The status bit SEQ4_STATUS_LEASE_MOVE indicates that
responsibility for lease renewal has been transferred to one or responsibility for lease renewal has been transferred to one or
more new servers. more new servers.
o The status bit SEQ4_STATUS_RESTART_RECLAIM_NEEDED indicates that * The status bit SEQ4_STATUS_RESTART_RECLAIM_NEEDED indicates that
due to server restart the client must reclaim locking state. due to server restart the client must reclaim locking state.
o The status bit SEQ4_STATUS_BACKCHANNEL_FAULT indicates that the * The status bit SEQ4_STATUS_BACKCHANNEL_FAULT indicates that the
server has encountered an unrecoverable fault with the backchannel server has encountered an unrecoverable fault with the backchannel
(e.g., it has lost track of a sequence ID for a slot in the (e.g., it has lost track of a sequence ID for a slot in the
backchannel). backchannel).
8.4. Crash Recovery 8.4. Crash Recovery
A critical requirement in crash recovery is that both the client and A critical requirement in crash recovery is that both the client and
the server know when the other has failed. Additionally, it is the server know when the other has failed. Additionally, it is
required that a client sees a consistent view of data across server required that a client sees a consistent view of data across server
restarts. All READ and WRITE operations that may have been queued restarts. All READ and WRITE operations that may have been queued
within the client or network buffers must wait until the client has within the client or network buffers must wait until the client has
successfully recovered the locks protecting the READ and WRITE successfully recovered the locks protecting the READ and WRITE
operations. Any that reach the server before the server can safely operations. Any that reach the server before the server can safely
determine that the client has recovered enough locking state to be determine that the client has recovered enough locking state to be
sure that such operations can be safely processed must be rejected. sure that such operations can be safely processed must be rejected.
This will happen because either: This will happen because either:
o The state presented is no longer valid since it is associated with * The state presented is no longer valid since it is associated with
a now invalid client ID. In this case, the client will receive a now invalid client ID. In this case, the client will receive
either an NFS4ERR_BADSESSION or NFS4ERR_DEADSESSION error, and any either an NFS4ERR_BADSESSION or NFS4ERR_DEADSESSION error, and any
attempt to attach a new session to that invalid client ID will attempt to attach a new session to that invalid client ID will
result in an NFS4ERR_STALE_CLIENTID error. result in an NFS4ERR_STALE_CLIENTID error.
o Subsequent recovery of locks may make execution of the operation * Subsequent recovery of locks may make execution of the operation
inappropriate (NFS4ERR_GRACE). inappropriate (NFS4ERR_GRACE).
8.4.1. Client Failure and Recovery 8.4.1. Client Failure and Recovery
In the event that a client fails, the server may release the client's In the event that a client fails, the server may release the client's
locks when the associated lease has expired. Conflicting locks from locks when the associated lease has expired. Conflicting locks from
another client may only be granted after this lease expiration. As another client may only be granted after this lease expiration. As
discussed in Section 8.3, when a client has not failed and re- discussed in Section 8.3, when a client has not failed and re-
establishes its lease before expiration occurs, requests for establishes its lease before expiration occurs, requests for
conflicting locks will not be granted. conflicting locks will not be granted.
skipping to change at page 175, line 10 skipping to change at line 8394
requests to be processed during the grace period, it MUST determine requests to be processed during the grace period, it MUST determine
that no lock subsequently reclaimed will be rejected and that no lock that no lock subsequently reclaimed will be rejected and that no lock
subsequently reclaimed would have prevented any I/O operation subsequently reclaimed would have prevented any I/O operation
processed during the grace period. processed during the grace period.
Clients should be prepared for the return of NFS4ERR_GRACE errors for Clients should be prepared for the return of NFS4ERR_GRACE errors for
non-reclaim lock and I/O requests. In this case, the client should non-reclaim lock and I/O requests. In this case, the client should
employ a retry mechanism for the request. A delay (on the order of employ a retry mechanism for the request. A delay (on the order of
several seconds) between retries should be used to avoid overwhelming several seconds) between retries should be used to avoid overwhelming
the server. Further discussion of the general issue is included in the server. Further discussion of the general issue is included in
[54]. The client must account for the server that can perform I/O [55]. The client must account for the server that can perform I/O
and non-reclaim locking requests within the grace period as well as and non-reclaim locking requests within the grace period as well as
those that cannot do so. those that cannot do so.
A reclaim-type locking request outside the server's grace period can A reclaim-type locking request outside the server's grace period can
only succeed if the server can guarantee that no conflicting lock or only succeed if the server can guarantee that no conflicting lock or
I/O request has been granted since restart. I/O request has been granted since restart.
A server may, upon restart, establish a new value for the lease A server may, upon restart, establish a new value for the lease
period. Therefore, clients should, once a new client ID is period. Therefore, clients should, once a new client ID is
established, refetch the lease_time attribute and use it as the basis established, refetch the lease_time attribute and use it as the basis
skipping to change at page 175, line 35 skipping to change at line 8419
previous server instance to be reliably re-established. previous server instance to be reliably re-established.
The possibility exists that, because of server configuration events, The possibility exists that, because of server configuration events,
the client will be communicating with a server different than the one the client will be communicating with a server different than the one
on which the locks were obtained, as shown by the combination of on which the locks were obtained, as shown by the combination of
eir_server_scope and eir_server_owner. This leads to the issue of if eir_server_scope and eir_server_owner. This leads to the issue of if
and when the client should attempt to reclaim locks previously and when the client should attempt to reclaim locks previously
obtained on what is being reported as a different server. The rules obtained on what is being reported as a different server. The rules
to resolve this question are as follows: to resolve this question are as follows:
o If the server scope is different, the client should not attempt to * If the server scope is different, the client should not attempt to
reclaim locks. In this situation, no lock reclaim is possible. reclaim locks. In this situation, no lock reclaim is possible.
Any attempt to re-obtain the locks with non-reclaim operations is Any attempt to re-obtain the locks with non-reclaim operations is
problematic since there is no guarantee that the existing problematic since there is no guarantee that the existing
filehandles will be recognized by the new server, or that if filehandles will be recognized by the new server, or that if
recognized, they denote the same objects. It is best to treat the recognized, they denote the same objects. It is best to treat the
locks as having been revoked by the reconfiguration event. locks as having been revoked by the reconfiguration event.
o If the server scope is the same, the client should attempt to * If the server scope is the same, the client should attempt to
reclaim locks, even if the eir_server_owner value is different. reclaim locks, even if the eir_server_owner value is different.
In this situation, it is the responsibility of the server to In this situation, it is the responsibility of the server to
return NFS4ERR_NO_GRACE if it cannot provide correct support for return NFS4ERR_NO_GRACE if it cannot provide correct support for
lock reclaim operations, including the prevention of edge lock reclaim operations, including the prevention of edge
conditions. conditions.
The eir_server_owner field is not used in making this determination. The eir_server_owner field is not used in making this determination.
Its function is to specify trunking possibilities for the client (see Its function is to specify trunking possibilities for the client (see
Section 2.10.5) and not to control lock reclaim. Section 2.10.5) and not to control lock reclaim.
skipping to change at page 179, line 47 skipping to change at line 8624
inverse proportion to how harsh the server intends to be whenever inverse proportion to how harsh the server intends to be whenever
edge conditions arise. The server that is completely tolerant of all edge conditions arise. The server that is completely tolerant of all
edge conditions will record in stable storage every lock that is edge conditions will record in stable storage every lock that is
acquired, removing the lock record from stable storage only when the acquired, removing the lock record from stable storage only when the
lock is released. For the two edge conditions discussed above, the lock is released. For the two edge conditions discussed above, the
harshest a server can be, and still support a grace period for harshest a server can be, and still support a grace period for
reclaims, requires that the server record in stable storage some reclaims, requires that the server record in stable storage some
minimal information. For example, a server implementation could, for minimal information. For example, a server implementation could, for
each client, save in stable storage a record containing: each client, save in stable storage a record containing:
o the co_ownerid field from the client_owner4 presented in the * the co_ownerid field from the client_owner4 presented in the
EXCHANGE_ID operation. EXCHANGE_ID operation.
o a boolean that indicates if the client's lease expired or if there * a boolean that indicates if the client's lease expired or if there
was administrative intervention (see Section 8.5) to revoke a was administrative intervention (see Section 8.5) to revoke a
byte-range lock, share reservation, or delegation and there has byte-range lock, share reservation, or delegation and there has
been no acknowledgment, via FREE_STATEID, of such revocation. been no acknowledgment, via FREE_STATEID, of such revocation.
o a boolean that indicates whether the client may have locks that it * a boolean that indicates whether the client may have locks that it
believes to be reclaimable in situations in which the grace period believes to be reclaimable in situations in which the grace period
was terminated, making the server's view of lock reclaimability was terminated, making the server's view of lock reclaimability
suspect. The server will set this for any client record in stable suspect. The server will set this for any client record in stable
storage where the client has not done a suitable RECLAIM_COMPLETE storage where the client has not done a suitable RECLAIM_COMPLETE
(global or file system-specific depending on the target of the (global or file system-specific depending on the target of the
lock request) before it grants any new (i.e., not reclaimed) lock lock request) before it grants any new (i.e., not reclaimed) lock
to any client. to any client.
Assuming the above record keeping, for the first edge condition, Assuming the above record keeping, for the first edge condition,
after the server restarts, the record that client A's lease expired after the server restarts, the record that client A's lease expired
skipping to change at page 182, line 32 skipping to change at line 8753
within the lease period, it is up to the client to determine which within the lease period, it is up to the client to determine which
locks have been revoked and which have not. It does this by using locks have been revoked and which have not. It does this by using
the TEST_STATEID operation on the appropriate set of stateids. Once the TEST_STATEID operation on the appropriate set of stateids. Once
the set of revoked locks has been determined, the applications can be the set of revoked locks has been determined, the applications can be
notified, and the invalidated stateids can be freed and lock notified, and the invalidated stateids can be freed and lock
revocation acknowledged by using FREE_STATEID. revocation acknowledged by using FREE_STATEID.
8.6. Short and Long Leases 8.6. Short and Long Leases
When determining the time period for the server lease, the usual When determining the time period for the server lease, the usual
lease tradeoffs apply. A short lease is good for fast server lease trade-offs apply. A short lease is good for fast server
recovery at a cost of increased operations to effect lease renewal recovery at a cost of increased operations to effect lease renewal
(when there are no other operations during the period to effect lease (when there are no other operations during the period to effect lease
renewal as a side effect). A long lease is certainly kinder and renewal as a side effect). A long lease is certainly kinder and
gentler to servers trying to handle very large numbers of clients. gentler to servers trying to handle very large numbers of clients.
The number of extra requests to effect lock renewal drops in inverse The number of extra requests to effect lock renewal drops in inverse
proportion to the lease time. The disadvantages of a long lease proportion to the lease time. The disadvantages of a long lease
include the possibility of slower recovery after certain failures. include the possibility of slower recovery after certain failures.
After server failure, a longer grace period may be required when some After server failure, a longer grace period may be required when some
clients do not promptly reclaim their locks and do a global clients do not promptly reclaim their locks and do a global
RECLAIM_COMPLETE. In the event of client failure, the longer period RECLAIM_COMPLETE. In the event of client failure, the longer period
skipping to change at page 183, line 47 skipping to change at line 8813
There are a number of operations and fields within existing There are a number of operations and fields within existing
operations that no longer have a function in NFSv4.1. In one way or operations that no longer have a function in NFSv4.1. In one way or
another, these changes are all due to the implementation of sessions another, these changes are all due to the implementation of sessions
that provide client context and exactly once semantics as a base that provide client context and exactly once semantics as a base
feature of the protocol, separate from locking itself. feature of the protocol, separate from locking itself.
The following NFSv4.0 operations MUST NOT be implemented in NFSv4.1. The following NFSv4.0 operations MUST NOT be implemented in NFSv4.1.
The server MUST return NFS4ERR_NOTSUPP if these operations are found The server MUST return NFS4ERR_NOTSUPP if these operations are found
in an NFSv4.1 COMPOUND. in an NFSv4.1 COMPOUND.
o SETCLIENTID since its function has been replaced by EXCHANGE_ID. * SETCLIENTID since its function has been replaced by EXCHANGE_ID.
o SETCLIENTID_CONFIRM since client ID confirmation now happens by * SETCLIENTID_CONFIRM since client ID confirmation now happens by
means of CREATE_SESSION. means of CREATE_SESSION.
o OPEN_CONFIRM because state-owner-based seqids have been replaced * OPEN_CONFIRM because state-owner-based seqids have been replaced
by the sequence ID in the SEQUENCE operation. by the sequence ID in the SEQUENCE operation.
o RELEASE_LOCKOWNER because lock-owners with no associated locks do * RELEASE_LOCKOWNER because lock-owners with no associated locks do
not have any sequence-related state and so can be deleted by the not have any sequence-related state and so can be deleted by the
server at will. server at will.
o RENEW because every SEQUENCE operation for a session causes lease * RENEW because every SEQUENCE operation for a session causes lease
renewal, making a separate operation superfluous. renewal, making a separate operation superfluous.
Also, there are a number of fields, present in existing operations, Also, there are a number of fields, present in existing operations,
related to locking that have no use in minor version 1. They were related to locking that have no use in minor version 1. They were
used in minor version 0 to perform functions now provided in a used in minor version 0 to perform functions now provided in a
different fashion. different fashion.
o Sequence ids used to sequence requests for a given state-owner and * Sequence ids used to sequence requests for a given state-owner and
to provide retry protection, now provided via sessions. to provide retry protection, now provided via sessions.
o Client IDs used to identify the client associated with a given * Client IDs used to identify the client associated with a given
request. Client identification is now available using the client request. Client identification is now available using the client
ID associated with the current session, without needing an ID associated with the current session, without needing an
explicit client ID field. explicit client ID field.
Such vestigial fields in existing operations have no function in Such vestigial fields in existing operations have no function in
NFSv4.1 and are ignored by the server. Note that client IDs in NFSv4.1 and are ignored by the server. Note that client IDs in
operations new to NFSv4.1 (such as CREATE_SESSION and operations new to NFSv4.1 (such as CREATE_SESSION and
DESTROY_CLIENTID) are not ignored. DESTROY_CLIENTID) are not ignored.
9. File Locking and Share Reservations 9. File Locking and Share Reservations
skipping to change at page 187, line 7 skipping to change at line 8964
Thus, the LOCK operation does not need to distinguish between Thus, the LOCK operation does not need to distinguish between
advisory and mandatory byte-range locks. It is the server's advisory and mandatory byte-range locks. It is the server's
processing of the READ and WRITE operations that introduces the processing of the READ and WRITE operations that introduces the
distinction. distinction.
Every stateid that is validly passed to READ, WRITE, or SETATTR, with Every stateid that is validly passed to READ, WRITE, or SETATTR, with
the exception of special stateid values, defines an access mode for the exception of special stateid values, defines an access mode for
the file (i.e., OPEN4_SHARE_ACCESS_READ, OPEN4_SHARE_ACCESS_WRITE, or the file (i.e., OPEN4_SHARE_ACCESS_READ, OPEN4_SHARE_ACCESS_WRITE, or
OPEN4_SHARE_ACCESS_BOTH). OPEN4_SHARE_ACCESS_BOTH).
o For stateids associated with opens, this is the mode defined by * For stateids associated with opens, this is the mode defined by
the original OPEN that caused the allocation of the OPEN stateid the original OPEN that caused the allocation of the OPEN stateid
and as modified by subsequent OPENs and OPEN_DOWNGRADEs for the and as modified by subsequent OPENs and OPEN_DOWNGRADEs for the
same open-owner/file pair. same open-owner/file pair.
o For stateids returned by byte-range LOCK operations, the * For stateids returned by byte-range LOCK operations, the
appropriate mode is the access mode for the OPEN stateid appropriate mode is the access mode for the OPEN stateid
associated with the lock set represented by the stateid. associated with the lock set represented by the stateid.
o For delegation stateids, the access mode is based on the type of * For delegation stateids, the access mode is based on the type of
delegation. delegation.
When a READ, WRITE, or SETATTR (that specifies the size attribute) When a READ, WRITE, or SETATTR (that specifies the size attribute)
operation is done, the operation is subject to checking against the operation is done, the operation is subject to checking against the
access mode to verify that the operation is appropriate given the access mode to verify that the operation is appropriate given the
stateid with which the operation is associated. stateid with which the operation is associated.
In the case of WRITE-type operations (i.e., WRITEs and SETATTRs that In the case of WRITE-type operations (i.e., WRITEs and SETATTRs that
set size), the server MUST verify that the access mode allows writing set size), the server MUST verify that the access mode allows writing
and MUST return an NFS4ERR_OPENMODE error if it does not. In the and MUST return an NFS4ERR_OPENMODE error if it does not. In the
skipping to change at page 188, line 5 skipping to change at line 9010
this special stateid is used. However, WRITE operations with this this special stateid is used. However, WRITE operations with this
special stateid value MUST NOT bypass locking checks and are treated special stateid value MUST NOT bypass locking checks and are treated
exactly the same as if a special stateid for anonymous state were exactly the same as if a special stateid for anonymous state were
used. used.
A lock may not be granted while a READ or WRITE operation using one A lock may not be granted while a READ or WRITE operation using one
of the special stateids is being performed and the scope of the lock of the special stateids is being performed and the scope of the lock
to be granted would conflict with the READ or WRITE operation. This to be granted would conflict with the READ or WRITE operation. This
can occur when: can occur when:
o A mandatory byte-range lock is requested with a byte-range that * A mandatory byte-range lock is requested with a byte-range that
conflicts with the byte-range of the READ or WRITE operation. For conflicts with the byte-range of the READ or WRITE operation. For
the purposes of this paragraph, a conflict occurs when a shared the purposes of this paragraph, a conflict occurs when a shared
lock is requested and a WRITE operation is being performed, or an lock is requested and a WRITE operation is being performed, or an
exclusive lock is requested and either a READ or a WRITE operation exclusive lock is requested and either a READ or a WRITE operation
is being performed. is being performed.
o A share reservation is requested that denies reading and/or * A share reservation is requested that denies reading and/or
writing and the corresponding operation is being performed. writing and the corresponding operation is being performed.
o A delegation is to be granted and the delegation type would * A delegation is to be granted and the delegation type would
prevent the I/O operation, i.e., READ and WRITE conflict with an prevent the I/O operation, i.e., READ and WRITE conflict with an
OPEN_DELEGATE_WRITE delegation and WRITE conflicts with an OPEN_DELEGATE_WRITE delegation and WRITE conflicts with an
OPEN_DELEGATE_READ delegation. OPEN_DELEGATE_READ delegation.
When a client holds a delegation, it needs to ensure that the stateid When a client holds a delegation, it needs to ensure that the stateid
sent conveys the association of operation with the delegation, to sent conveys the association of operation with the delegation, to
avoid the delegation from being avoidably recalled. When the avoid the delegation from being avoidably recalled. When the
delegation stateid, a stateid open associated with that delegation, delegation stateid, a stateid open associated with that delegation,
or a stateid representing byte-range locks derived from such an open or a stateid representing byte-range locks derived from such an open
is used, the server knows that the READ, WRITE, or SETATTR does not is used, the server knows that the READ, WRITE, or SETATTR does not
skipping to change at page 194, line 44 skipping to change at line 9329
OPEN_DOWNGRADEs should generally be sent with a non-zero seqid in the OPEN_DOWNGRADEs should generally be sent with a non-zero seqid in the
stateid, to avoid the possibility that the status change associated stateid, to avoid the possibility that the status change associated
with an open upgrade is not inadvertently lost. with an open upgrade is not inadvertently lost.
9.11. Reclaim of Open and Byte-Range Locks 9.11. Reclaim of Open and Byte-Range Locks
Special forms of the LOCK and OPEN operations are provided when it is Special forms of the LOCK and OPEN operations are provided when it is
necessary to re-establish byte-range locks or opens after a server necessary to re-establish byte-range locks or opens after a server
failure. failure.
o To reclaim existing opens, an OPEN operation is performed using a * To reclaim existing opens, an OPEN operation is performed using a
CLAIM_PREVIOUS. Because the client, in this type of situation, CLAIM_PREVIOUS. Because the client, in this type of situation,
will have already opened the file and have the filehandle of the will have already opened the file and have the filehandle of the
target file, this operation requires that the current filehandle target file, this operation requires that the current filehandle
be the target file, rather than a directory, and no file name is be the target file, rather than a directory, and no file name is
specified. specified.
o To reclaim byte-range locks, a LOCK operation with the reclaim * To reclaim byte-range locks, a LOCK operation with the reclaim
parameter set to true is used. parameter set to true is used.
Reclaims of opens associated with delegations are discussed in Reclaims of opens associated with delegations are discussed in
Section 10.2.1. Section 10.2.1.
10. Client-Side Caching 10. Client-Side Caching
Client-side caching of data, of file attributes, and of file names is Client-side caching of data, of file attributes, and of file names is
essential to providing good performance with the NFS protocol. essential to providing good performance with the NFS protocol.
Providing distributed cache coherence is a difficult problem, and Providing distributed cache coherence is a difficult problem, and
skipping to change at page 196, line 19 skipping to change at line 9399
Sending LOCK and LOCKU operations as well as the READ and WRITE Sending LOCK and LOCKU operations as well as the READ and WRITE
operations necessary to make data caching consistent with the locking operations necessary to make data caching consistent with the locking
semantics (see Section 10.3.2) can severely limit performance. When semantics (see Section 10.3.2) can severely limit performance. When
locking is used to provide protection against infrequent conflicts, a locking is used to provide protection against infrequent conflicts, a
large penalty is incurred. This penalty may discourage the use of large penalty is incurred. This penalty may discourage the use of
byte-range locking by applications. byte-range locking by applications.
The NFSv4.1 protocol provides more aggressive caching strategies with The NFSv4.1 protocol provides more aggressive caching strategies with
the following design goals: the following design goals:
o Compatibility with a large range of server semantics. * Compatibility with a large range of server semantics.
o Providing the same caching benefits as previous versions of the * Providing the same caching benefits as previous versions of the
NFS protocol when unable to support the more aggressive model. NFS protocol when unable to support the more aggressive model.
o Requirements for aggressive caching are organized so that a large * Requirements for aggressive caching are organized so that a large
portion of the benefit can be obtained even when not all of the portion of the benefit can be obtained even when not all of the
requirements can be met. requirements can be met.
The appropriate requirements for the server are discussed in later The appropriate requirements for the server are discussed in later
sections in which specific forms of caching are covered (see sections in which specific forms of caching are covered (see
Section 10.4). Section 10.4).
10.2. Delegation and Callbacks 10.2. Delegation and Callbacks
Recallable delegation of server responsibilities for a file to a Recallable delegation of server responsibilities for a file to a
skipping to change at page 197, line 25 skipping to change at line 9452
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.
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
such operations are required to effect a recall. A number of points such operations are required to effect a recall. A number of points
should be noted, however. should be noted, however.
o The server is free to recall a delegation whenever it feels it is * 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.1 protocol, due to, for example, * Operations done outside the NFSv4.1 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 * 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.
Despite those caveats, the implementation sections for a number of Despite those caveats, the implementation sections for a number of
operations describe situations in which delegation recall would be operations describe situations in which delegation recall would be
required under some common circumstances: required under some common circumstances:
o For GETATTR, see Section 18.7.4. * For GETATTR, see Section 18.7.4.
o For OPEN, see Section 18.16.4. * For OPEN, see Section 18.16.4.
o For READ, see Section 18.22.4. * For READ, see Section 18.22.4.
o For REMOVE, see Section 18.25.4. * For REMOVE, see Section 18.25.4.
o For RENAME, see Section 18.26.4. * For RENAME, see Section 18.26.4.
o For SETATTR, see Section 18.30.4. * For SETATTR, see Section 18.30.4.
o For WRITE, see Section 18.32.4. * For WRITE, see Section 18.32.4.
On recall, the client holding the delegation needs to 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
skipping to change at page 198, line 52 skipping to change at line 9527
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 needs to deal There are three situations that delegation recovery needs to deal
with: with:
o client restart * client restart
o server restart
o network partition (full or backchannel-only) * server restart
* 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.
There will be situations in which delegations will need to be re- There will be situations in which delegations will need to be re-
established after a client restarts. The reason for this is that the established after a client restarts. The reason for this is that the
client may have file data stored locally and this data was associated client may have file data stored locally and this data was associated
with the previously held delegations. The client will need to re- with the previously held delegations. The client will need to re-
establish the appropriate file state on the server. establish the appropriate file state on the server.
skipping to change at page 200, line 7 skipping to change at line 9580
difference. In the normal case, if the server decides that a difference. In the normal case, if the server decides that a
delegation should not be granted, it performs the requested action delegation should not be granted, it performs the requested action
(e.g., OPEN) without granting any delegation. For reclaim, the (e.g., OPEN) without granting any delegation. For reclaim, the
server grants the delegation but a special designation is applied so server grants the delegation but a special designation is applied so
that the client treats the delegation as having been granted but that the client treats the delegation as having been granted but
recalled by the server. Because of this, the client has the duty to recalled by the server. Because of this, the client has the duty to
write all modified state to the server and then return the write all modified state to the server and then return the
delegation. This process of handling delegation reclaim reconciles delegation. This process of handling delegation reclaim reconciles
three principles of the NFSv4.1 protocol: three principles of the NFSv4.1 protocol:
o Upon reclaim, a client reporting resources assigned to it by an * Upon reclaim, a client reporting resources assigned to it by an
earlier server instance must be granted those resources. earlier server instance must be granted those resources.
o The server has unquestionable authority to determine whether * The server has unquestionable authority to determine whether
delegations are to be granted and, once granted, whether they are delegations are to be granted and, once granted, whether they are
to be continued. to be continued.
o The use of callbacks should not be depended upon until the client * The use of callbacks should not be depended upon until the client
has proven its ability to receive them. has proven its ability to receive them.
When a client needs to reclaim a delegation and there is no When a client needs to reclaim a delegation and there is no
associated open, the client may use the CLAIM_PREVIOUS variant of the associated open, the client may use the CLAIM_PREVIOUS variant of the
WANT_DELEGATION operation. However, since the server is not required WANT_DELEGATION operation. However, since the server is not required
to support this operation, an alternative is to reclaim via a dummy to support this operation, an alternative is to reclaim via a dummy
OPEN together with the delegation using an OPEN of type OPEN together with the delegation using an OPEN of type
CLAIM_PREVIOUS. The dummy open file can be released using a CLOSE to CLAIM_PREVIOUS. The dummy open file can be released using a CLOSE to
re-establish the original state to be reclaimed, a delegation without re-establish the original state to be reclaimed, a delegation without
an associated open. an associated open.
skipping to change at page 201, line 36 skipping to change at line 9657
In order to avoid invalidating the sharing assumptions on which In order to avoid invalidating the sharing assumptions on which
applications rely, NFSv4.1 clients should not provide cached data to applications rely, NFSv4.1 clients should not provide cached data to
applications or modify it on behalf of an application when it would applications or modify it on behalf of an application when it would
not be valid to obtain or modify that same data via a READ or WRITE not be valid to obtain or modify that same data via a READ or WRITE
operation. operation.
Furthermore, in the absence of an OPEN delegation (see Section 10.4), Furthermore, in the absence of an OPEN delegation (see Section 10.4),
two additional rules apply. Note that these rules are obeyed in two additional rules apply. Note that these rules are obeyed in
practice by many NFSv3 clients. practice by many NFSv3 clients.
o First, cached data present on a client must be revalidated after * First, cached data present on a client must be revalidated after
doing an OPEN. Revalidating means that the client fetches the doing an OPEN. Revalidating means that the client fetches the
change attribute from the server, compares it with the cached change attribute from the server, compares it with the cached
change attribute, and if different, declares the cached data (as change attribute, and if different, declares the cached data (as
well as the cached attributes) as invalid. This is to ensure that well as the cached attributes) as invalid. This is to ensure that
the data for the OPENed file is still correctly reflected in the the data for the OPENed file is still correctly reflected in the
client's cache. This validation must be done at least when the client's cache. This validation must be done at least when the
client's OPEN operation includes a deny of OPEN4_SHARE_DENY_WRITE client's OPEN operation includes a deny of OPEN4_SHARE_DENY_WRITE
or OPEN4_SHARE_DENY_BOTH, thus terminating a period in which other or OPEN4_SHARE_DENY_BOTH, thus terminating a period in which other
clients may have had the opportunity to open the file with clients may have had the opportunity to open the file with
OPEN4_SHARE_ACCESS_WRITE/OPEN4_SHARE_ACCESS_BOTH access. Clients OPEN4_SHARE_ACCESS_WRITE/OPEN4_SHARE_ACCESS_BOTH access. Clients
skipping to change at page 202, line 18 skipping to change at line 9686
cached data, so that metadata changes do not spuriously invalidate cached data, so that metadata changes do not spuriously invalidate
clean data. The implementor is cautioned in this approach. The clean data. The implementor is cautioned in this approach. The
change attribute is guaranteed to change for each update to the change attribute is guaranteed to change for each update to the
file, whereas time_modify is guaranteed to change only at the file, whereas time_modify is guaranteed to change only at the
granularity of the time_delta attribute. Use by the client's data granularity of the time_delta attribute. Use by the client's data
cache validation logic of time_modify and not change runs the risk cache validation logic of time_modify and not change runs the risk
of the client incorrectly marking stale data as valid. Thus, any of the client incorrectly marking stale data as valid. Thus, any
cache validation approach by the client MUST include the use of cache validation approach by the client MUST include the use of
the change attribute. the change attribute.
o Second, modified data must be flushed to the server before closing * Second, modified data must be flushed to the server before closing
a file OPENed for OPEN4_SHARE_ACCESS_WRITE. This is complementary a file OPENed for OPEN4_SHARE_ACCESS_WRITE. This is complementary
to the first rule. If the data is not flushed at CLOSE, the to the first rule. If the data is not flushed at CLOSE, the
revalidation done after the client OPENs a file is unable to revalidation done after the client OPENs a file is unable to
achieve its purpose. The other aspect to flushing the data before achieve its purpose. The other aspect to flushing the data before
close is that the data must be committed to stable storage, at the close is that the data must be committed to stable storage, at the
server, before the CLOSE operation is requested by the client. In server, before the CLOSE operation is requested by the client. In
the case of a server restart and a CLOSEd file, it may not be the case of a server restart and a CLOSEd file, it may not be
possible to retransmit the data to be written to the file, hence, possible to retransmit the data to be written to the file, hence,
this requirement. this requirement.
skipping to change at page 202, line 51 skipping to change at line 9719
the file would represent the right to perform READ and WRITE the file would represent the right to perform READ and WRITE
operations on the first byte-range. A WRITE_LT lock on byte one of operations on the first byte-range. A WRITE_LT lock on byte one of
the file would represent the right to perform READ and WRITE the file would represent the right to perform READ and WRITE
operations on the second byte-range. As long as all applications operations on the second byte-range. As long as all applications
manipulating the file obey this convention, they will work on a local manipulating the file obey this convention, they will work on a local
file system. However, they may not work with the NFSv4.1 protocol file system. However, they may not work with the NFSv4.1 protocol
unless clients refrain from data caching. unless clients refrain from data caching.
The rules for data caching in the byte-range locking environment are: The rules for data caching in the byte-range locking environment are:
o First, when a client obtains a byte-range lock for a particular * First, when a client obtains a byte-range lock for a particular
byte-range, the data cache corresponding to that byte-range (if byte-range, the data cache corresponding to that byte-range (if
any cache data exists) must be revalidated. If the change any cache data exists) must be revalidated. If the change
attribute indicates that the file may have been updated since the attribute indicates that the file may have been updated since the
cached data was obtained, the client must flush or invalidate the cached data was obtained, the client must flush or invalidate the
cached data for the newly locked byte-range. A client might cached data for the newly locked byte-range. A client might
choose to invalidate all of the non-modified cached data that it choose to invalidate all of the non-modified cached data that it
has for the file, but the only requirement for correct operation has for the file, but the only requirement for correct operation
is to invalidate all of the data in the newly locked byte-range. is to invalidate all of the data in the newly locked byte-range.
o Second, before releasing a WRITE_LT lock for a byte-range, all * Second, before releasing a WRITE_LT lock for a byte-range, all
modified data for that byte-range must be flushed to the server. modified data for that byte-range must be flushed to the server.
The modified data must also be written to stable storage. The modified data must also be written to stable storage.
Note that flushing data to the server and the invalidation of cached Note that flushing data to the server and the invalidation of cached
data must reflect the actual byte-ranges locked or unlocked. data must reflect the actual byte-ranges locked or unlocked.
Rounding these up or down to reflect client cache block boundaries Rounding these up or down to reflect client cache block boundaries
will cause problems if not carefully done. For example, writing a will cause problems if not carefully done. For example, writing a
modified block when only half of that block is within an area being modified block when only half of that block is within an area being
unlocked may cause invalid modification to the byte-range outside the unlocked may cause invalid modification to the byte-range outside the
unlocked area. This, in turn, may be part of a byte-range locked by unlocked area. This, in turn, may be part of a byte-range locked by
skipping to change at page 205, line 12 skipping to change at line 9825
with the NFSv3 protocol. Without this method, caching with the NFSv3 protocol. Without this method, caching
inconsistencies within the same client could occur, and this has not inconsistencies within the same client could occur, and this has not
been present in previous versions of the NFS protocol. Note that it been present in previous versions of the NFS protocol. Note that it
is possible to have such inconsistencies with applications executing is possible to have such inconsistencies with applications executing
on multiple clients, but that is not the issue being addressed here. on multiple clients, but that is not the issue being addressed here.
For the purposes of data caching, the following steps allow an For the purposes of data caching, the following steps allow an
NFSv4.1 client to determine whether two distinct filehandles denote NFSv4.1 client to determine whether two distinct filehandles denote
the same server-side object: the same server-side object:
o If GETATTR directed to two filehandles returns different values of * If GETATTR directed to two filehandles returns different values of
the fsid attribute, then the filehandles represent distinct the fsid attribute, then the filehandles represent distinct
objects. objects.
o If GETATTR for any file with an fsid that matches the fsid of the * If GETATTR for any file with an fsid that matches the fsid of the
two filehandles in question returns a unique_handles attribute two filehandles in question returns a unique_handles attribute
with a value of TRUE, then the two objects are distinct. with a value of TRUE, then the two objects are distinct.
o If GETATTR directed to the two filehandles does not return the * If GETATTR directed to the two filehandles does not return the
fileid attribute for both of the handles, then it cannot be fileid attribute for both of the handles, then it cannot be
determined whether the two objects are the same. Therefore, determined whether the two objects are the same. Therefore,
operations that depend on that knowledge (e.g., client-side data operations that depend on that knowledge (e.g., client-side data
caching) cannot be done reliably. Note that if GETATTR does not caching) cannot be done reliably. Note that if GETATTR does not
return the fileid attribute for both filehandles, it will return return the fileid attribute for both filehandles, it will return
it for neither of the filehandles, since the fsid for both it for neither of the filehandles, since the fsid for both
filehandles is the same. filehandles is the same.
o If GETATTR directed to the two filehandles returns different * If GETATTR directed to the two filehandles returns different
values for the fileid attribute, then they are distinct objects. values for the fileid attribute, then they are distinct objects.
o Otherwise, they are the same object. * Otherwise, they are the same object.
10.4. Open Delegation 10.4. Open Delegation
When a file is being OPENed, the server may delegate further handling When a file is being OPENed, the server may delegate further handling
of opens and closes for that file to the opening client. Any such of opens and closes for that file to the opening client. Any such
delegation is recallable since the circumstances that allowed for the delegation is recallable since the circumstances that allowed for the
delegation are subject to change. In particular, if the server delegation are subject to change. In particular, if the server
receives a conflicting OPEN from another client, the server must receives a conflicting OPEN from another client, the server must
recall the delegation before deciding whether the OPEN from the other recall the delegation before deciding whether the OPEN from the other
client may be granted. Making a delegation is up to the server, and client may be granted. Making a delegation is up to the server, and
clients should not assume that any particular OPEN either will or clients should not assume that any particular OPEN either will or
will not result in an OPEN delegation. The following is a typical will not result in an OPEN delegation. The following is a typical
set of conditions that servers might use in deciding whether an OPEN set of conditions that servers might use in deciding whether an OPEN
should be delegated: should be delegated:
o The client must be able to respond to the server's callback * The client must be able to respond to the server's callback
requests. If a backchannel has been established, the server will requests. If a backchannel has been established, the server will
send a CB_COMPOUND request, containing a single operation, send a CB_COMPOUND request, containing a single operation,
CB_SEQUENCE, for a test of backchannel availability. CB_SEQUENCE, for a test of backchannel availability.
o The client must have responded properly to previous recalls. * The client must have responded properly to previous recalls.
o There must be no current OPEN conflicting with the requested * There must be no current OPEN conflicting with the requested
delegation. delegation.
o There should be no current delegation that conflicts with the * There should be no current delegation that conflicts with the
delegation being requested. delegation being requested.
o The probability of future conflicting open requests should be low * The probability of future conflicting open requests should be low
based on the recent history of the file. based on the recent history of the file.
o The existence of any server-specific semantics of OPEN/CLOSE that * The existence of any server-specific semantics of OPEN/CLOSE that
would make the required handling incompatible with the prescribed would make the required handling incompatible with the prescribed
handling that the delegated client would apply (see below). handling that the delegated client would apply (see below).
There are two types of OPEN delegations: OPEN_DELEGATE_READ and There are two types of OPEN delegations: OPEN_DELEGATE_READ and
OPEN_DELEGATE_WRITE. An OPEN_DELEGATE_READ delegation allows a OPEN_DELEGATE_WRITE. An OPEN_DELEGATE_READ delegation allows a
client to handle, on its own, requests to open a file for reading client to handle, on its own, requests to open a file for reading
that do not deny OPEN4_SHARE_ACCESS_READ access to others. Multiple that do not deny OPEN4_SHARE_ACCESS_READ access to others. Multiple
OPEN_DELEGATE_READ delegations may be outstanding simultaneously and OPEN_DELEGATE_READ delegations may be outstanding simultaneously and
do not conflict. An OPEN_DELEGATE_WRITE delegation allows the client do not conflict. An OPEN_DELEGATE_WRITE delegation allows the client
to handle, on its own, all opens. Only OPEN_DELEGATE_WRITE to handle, on its own, all opens. Only one OPEN_DELEGATE_WRITE
delegation may exist for a given file at a given time, and it is delegation may exist for a given file at a given time, and it is
inconsistent with any OPEN_DELEGATE_READ delegations. inconsistent with any OPEN_DELEGATE_READ delegations.
When a client has an OPEN_DELEGATE_READ delegation, it is assured When a client has an OPEN_DELEGATE_READ delegation, it is assured
that neither the contents, the attributes (with the exception of that neither the contents, the attributes (with the exception of
time_access), nor the names of any links to the file will change time_access), nor the names of any links to the file will change
without its knowledge, so long as the delegation is held. When a without its knowledge, so long as the delegation is held. When a
client has an OPEN_DELEGATE_WRITE delegation, it may modify the file client has an OPEN_DELEGATE_WRITE delegation, it may modify the file
data locally since no other client will be accessing the file's data. data locally since no other client will be accessing the file's data.
The client holding an OPEN_DELEGATE_WRITE delegation may only locally The client holding an OPEN_DELEGATE_WRITE delegation may only locally
skipping to change at page 206, line 51 skipping to change at line 9912
When a client has an OPEN delegation, it does not need to send OPENs When a client has an OPEN delegation, it does not need to send OPENs
or CLOSEs to the server. Instead, the client may update the or CLOSEs to the server. Instead, the client may update the
appropriate status internally. For an OPEN_DELEGATE_READ delegation, appropriate status internally. For an OPEN_DELEGATE_READ delegation,
opens that cannot be handled locally (opens that are for opens that cannot be handled locally (opens that are for
OPEN4_SHARE_ACCESS_WRITE/OPEN4_SHARE_ACCESS_BOTH or that deny OPEN4_SHARE_ACCESS_WRITE/OPEN4_SHARE_ACCESS_BOTH or that deny
OPEN4_SHARE_ACCESS_READ access) must be sent to the server. OPEN4_SHARE_ACCESS_READ access) must be sent to the server.
When an OPEN delegation is made, the reply to the OPEN contains an When an OPEN delegation is made, the reply to the OPEN contains an
OPEN delegation structure that specifies the following: OPEN delegation structure that specifies the following:
o the type of delegation (OPEN_DELEGATE_READ or * the type of delegation (OPEN_DELEGATE_READ or
OPEN_DELEGATE_WRITE). OPEN_DELEGATE_WRITE).
o space limitation information to control flushing of data on close * space limitation information to control flushing of data on close
(OPEN_DELEGATE_WRITE delegation only; see Section 10.4.1) (OPEN_DELEGATE_WRITE delegation only; see Section 10.4.1)
o an nfsace4 specifying read and write permissions * an nfsace4 specifying read and write permissions
o a stateid to represent the delegation * a stateid to represent the delegation
The delegation stateid is separate and distinct from the stateid for The delegation stateid is separate and distinct from the stateid for
the OPEN proper. The standard stateid, unlike the delegation the OPEN proper. The standard stateid, unlike the delegation
stateid, is associated with a particular lock-owner and will continue stateid, is associated with a particular lock-owner and will continue
to be valid after the delegation is recalled and the file remains to be valid after the delegation is recalled and the file remains
open. open.
When a request internal to the client is made to open a file and an When a request internal to the client is made to open a file and an
OPEN delegation is in effect, it will be accepted or rejected solely OPEN delegation is in effect, it will be accepted or rejected solely
on the basis of the following conditions. Any requirement for other on the basis of the following conditions. Any requirement for other
checks to be made by the delegate should result in the OPEN checks to be made by the delegate should result in the OPEN
delegation being denied so that the checks can be made by the server delegation being denied so that the checks can be made by the server
itself. itself.
o The access and deny bits for the request and the file as described * The access and deny bits for the request and the file as described
in Section 9.7. in Section 9.7.
o The read and write permissions as determined below. * The read and write permissions as determined below.
The nfsace4 passed with delegation can be used to avoid frequent The nfsace4 passed with delegation can be used to avoid frequent
ACCESS calls. The permission check should be as follows: ACCESS calls. The permission check should be as follows:
o If the nfsace4 indicates that the open may be done, then it should * If the nfsace4 indicates that the open may be done, then it should
be granted without reference to the server. be granted without reference to the server.
o If the nfsace4 indicates that the open may not be done, then an * If the nfsace4 indicates that the open may not be done, then an
ACCESS request must be sent to the server to obtain the definitive ACCESS request must be sent to the server to obtain the definitive
answer. answer.
The server may return an nfsace4 that is more restrictive than the The server may return an nfsace4 that is more restrictive than the
actual ACL of the file. This includes an nfsace4 that specifies actual ACL of the file. This includes an nfsace4 that specifies
denial of all access. Note that some common practices such as denial of all access. Note that some common practices such as
mapping the traditional user "root" to the user "nobody" (see mapping the traditional user "root" to the user "nobody" (see
Section 5.9) may make it incorrect to return the actual ACL of the Section 5.9) may make it incorrect to return the actual ACL of the
file in the delegation response. file in the delegation response.
skipping to change at page 210, line 27 skipping to change at line 10082
Since the form of the change attribute is determined by the server Since the form of the change attribute is determined by the server
and is opaque to the client, the client and server need to agree on a and is opaque to the client, the client and server need to agree on a
method of communicating the modified state of the file. For the size method of communicating the modified state of the file. For the size
attribute, the client will report its current view of the file size. attribute, the client will report its current view of the file size.
For the change attribute, the handling is more involved. For the change attribute, the handling is more involved.
For the client, the following steps will be taken when receiving an For the client, the following steps will be taken when receiving an
OPEN_DELEGATE_WRITE delegation: OPEN_DELEGATE_WRITE delegation:
o The value of the change attribute will be obtained from the server * The value of the change attribute will be obtained from the server
and cached. Let this value be represented by c. and cached. Let this value be represented by c.
o The client will create a value greater than c that will be used * The client will create a value greater than c that will be used
for communicating that modified data is held at the client. Let for communicating that modified data is held at the client. Let
this value be represented by d. this value be represented by d.
o When the client is queried via CB_GETATTR for the change * When the client is queried via CB_GETATTR for the change
attribute, it checks to see if it holds modified data. If the attribute, it checks to see if it holds modified data. If the
file is modified, the value d is returned for the change attribute file is modified, the value d is returned for the change attribute
value. If this file is not currently modified, the client returns value. If this file is not currently modified, the client returns
the value c for the change attribute. the value c for the change attribute.
For simplicity of implementation, the client MAY for each CB_GETATTR For simplicity of implementation, the client MAY for each CB_GETATTR
return the same value d. This is true even if, between successive return the same value d. This is true even if, between successive
CB_GETATTR operations, the client again modifies the file's data or CB_GETATTR operations, the client again modifies the file's data or
metadata in its cache. The client can return the same value because metadata in its cache. The client can return the same value because
the only requirement is that the client be able to indicate to the the only requirement is that the client be able to indicate to the
skipping to change at page 211, line 14 skipping to change at line 10117
of the client's changes to that integer. Therefore, the server MUST of the client's changes to that integer. Therefore, the server MUST
encode the change attribute in network order when sending it to the encode the change attribute in network order when sending it to the
client. The client MUST decode it from network order to its native client. The client MUST decode it from network order to its native
order when receiving it, and the client MUST encode it in network order when receiving it, and the client MUST encode it in network
order when sending it to the server. For this reason, change is order when sending it to the server. For this reason, change is
defined as an unsigned integer rather than an opaque array of bytes. defined as an unsigned integer rather than an opaque array of bytes.
For the server, the following steps will be taken when providing an For the server, the following steps will be taken when providing an
OPEN_DELEGATE_WRITE delegation: OPEN_DELEGATE_WRITE delegation:
o Upon providing an OPEN_DELEGATE_WRITE delegation, the server will * Upon providing an OPEN_DELEGATE_WRITE delegation, the server will
cache a copy of the change attribute in the data structure it uses cache a copy of the change attribute in the data structure it uses
to record the delegation. Let this value be represented by sc. to record the delegation. Let this value be represented by sc.
o When a second client sends a GETATTR operation on the same file to * When a second client sends a GETATTR operation on the same file to
the server, the server obtains the change attribute from the first the server, the server obtains the change attribute from the first
client. Let this value be cc. client. Let this value be cc.
o If the value cc is equal to sc, the file is not modified and the * If the value cc is equal to sc, the file is not modified and the
server returns the current values for change, time_metadata, and server returns the current values for change, time_metadata, and
time_modify (for example) to the second client. time_modify (for example) to the second client.
o If the value cc is NOT equal to sc, the file is currently modified * If the value cc is NOT equal to sc, the file is currently modified
at the first client and most likely will be modified at the server at the first client and most likely will be modified at the server
at a future time. The server then uses its current time to at a future time. The server then uses its current time to
construct attribute values for time_metadata and time_modify. A construct attribute values for time_metadata and time_modify. A
new value of sc, which we will call nsc, is computed by the new value of sc, which we will call nsc, is computed by the
server, such that nsc >= sc + 1. The server then returns the server, such that nsc >= sc + 1. The server then returns the
constructed time_metadata, time_modify, and nsc values to the constructed time_metadata, time_modify, and nsc values to the
requester. The server replaces sc in the delegation record with requester. The server replaces sc in the delegation record with
nsc. To prevent the possibility of time_modify, time_metadata, nsc. To prevent the possibility of time_modify, time_metadata,
and change from appearing to go backward (which would happen if and change from appearing to go backward (which would happen if
the client holding the delegation fails to write its modified data the client holding the delegation fails to write its modified data
skipping to change at page 212, line 47 skipping to change at line 10198
down. down.
It should be noted that the server is under no obligation to use It should be noted that the server is under no obligation to use
CB_GETATTR, and therefore the server MAY simply recall the delegation CB_GETATTR, and therefore the server MAY simply recall the delegation
to avoid its use. to avoid its use.
10.4.4. Recall of Open Delegation 10.4.4. Recall of Open Delegation
The following events necessitate recall of an OPEN delegation: The following events necessitate recall of an OPEN delegation:
o potentially conflicting OPEN request (or a READ or WRITE operation * potentially conflicting OPEN request (or a READ or WRITE operation
done with a special stateid) done with a special stateid)
o SETATTR sent by another client * SETATTR sent by another client
o REMOVE request for the file
o RENAME request for the file as either the source or target of the * REMOVE request for the file
* RENAME request for the file as either the source or target of the
RENAME RENAME
Whether a RENAME of a directory in the path leading to the file Whether a RENAME of a directory in the path leading to the file
results in recall of an OPEN delegation depends on the semantics of results in recall of an OPEN delegation depends on the semantics of
the server's file system. If that file system denies such RENAMEs the server's file system. If that file system denies such RENAMEs
when a file is open, the recall must be performed to determine when a file is open, the recall must be performed to determine
whether the file in question is, in fact, open. whether the file in question is, in fact, open.
In addition to the situations above, the server may choose to recall In addition to the situations above, the server may choose to recall
OPEN delegations at any time if resource constraints make it OPEN delegations at any time if resource constraints make it
advisable to do so. Clients should always be prepared for the advisable to do so. Clients should always be prepared for the
possibility of recall. possibility of recall.
When a client receives a recall for an OPEN delegation, it needs to When a client receives a recall for an OPEN delegation, it needs to
update state on the server before returning the delegation. These update state on the server before returning the delegation. These
same updates must be done whenever a client chooses to return a same updates must be done whenever a client chooses to return a
delegation voluntarily. The following items of state need to be delegation voluntarily. The following items of state need to be
dealt with: dealt with:
o If the file associated with the delegation is no longer open and * If the file associated with the delegation is no longer open and
no previous CLOSE operation has been sent to the server, a CLOSE no previous CLOSE operation has been sent to the server, a CLOSE
operation must be sent to the server. operation must be sent to the server.
o If a file has other open references at the client, then OPEN * If a file has other open references at the client, then OPEN
operations must be sent to the server. The appropriate stateids operations must be sent to the server. The appropriate stateids
will be provided by the server for subsequent use by the client will be provided by the server for subsequent use by the client
since the delegation stateid will no longer be valid. These OPEN since the delegation stateid will no longer be valid. These OPEN
requests are done with the claim type of CLAIM_DELEGATE_CUR. This requests are done with the claim type of CLAIM_DELEGATE_CUR. This
will allow the presentation of the delegation stateid so that the will allow the presentation of the delegation stateid so that the
client can establish the appropriate rights to perform the OPEN. client can establish the appropriate rights to perform the OPEN.
(see Section 18.16, which describes the OPEN operation, for (See Section 18.16, which describes the OPEN operation, for
details.) details.)
o If there are granted byte-range locks, the corresponding LOCK * If there are granted byte-range locks, the corresponding LOCK
operations need to be performed. This applies to the operations need to be performed. This applies to the
OPEN_DELEGATE_WRITE delegation case only. OPEN_DELEGATE_WRITE delegation case only.
o For an OPEN_DELEGATE_WRITE delegation, if at the time of recall * For an OPEN_DELEGATE_WRITE delegation, if at the time of recall
the file is not open for OPEN4_SHARE_ACCESS_WRITE/ the file is not open for OPEN4_SHARE_ACCESS_WRITE/
OPEN4_SHARE_ACCESS_BOTH, all modified data for the file must be OPEN4_SHARE_ACCESS_BOTH, all modified data for the file must be
flushed to the server. If the delegation had not existed, the flushed to the server. If the delegation had not existed, the
client would have done this data flush before the CLOSE operation. client would have done this data flush before the CLOSE operation.
o For an OPEN_DELEGATE_WRITE delegation when a file is still open at * For an OPEN_DELEGATE_WRITE delegation when a file is still open at
the time of recall, any modified data for the file needs to be the time of recall, any modified data for the file needs to be
flushed to the server. flushed to the server.
o With the OPEN_DELEGATE_WRITE delegation in place, it is possible * With the OPEN_DELEGATE_WRITE delegation in place, it is possible
that the file was truncated during the duration of the delegation. that the file was truncated during the duration of the delegation.
For example, the truncation could have occurred as a result of an For example, the truncation could have occurred as a result of an
OPEN UNCHECKED with a size attribute value of zero. Therefore, if OPEN UNCHECKED with a size attribute value of zero. Therefore, if
a truncation of the file has occurred and this operation has not a truncation of the file has occurred and this operation has not
been propagated to the server, the truncation must occur before been propagated to the server, the truncation must occur before
any modified data is written to the server. any modified data is written to the server.
In the case of OPEN_DELEGATE_WRITE delegation, byte-range locking In the case of OPEN_DELEGATE_WRITE delegation, byte-range locking
imposes some additional requirements. To precisely maintain the imposes some additional requirements. To precisely maintain the
associated invariant, it is required to flush any modified data in associated invariant, it is required to flush any modified data in
skipping to change at page 218, line 46 skipping to change at line 10483
Changes made in one order on the server may be seen in a different Changes made in one order on the server may be seen in a different
order on one client and in a third order on another client. order on one client and in a third order on another client.
The typical file system application programming interfaces do not The typical file system application programming interfaces do not
provide means to atomically modify or interrogate attributes for provide means to atomically modify or interrogate attributes for
multiple files at the same time. The following rules provide an multiple files at the same time. The following rules provide an
environment where the potential incoherencies mentioned above can be environment where the potential incoherencies mentioned above can be
reasonably managed. These rules are derived from the practice of reasonably managed. These rules are derived from the practice of
previous NFS protocols. previous NFS protocols.
o All attributes for a given file (per-fsid attributes excepted) are * All attributes for a given file (per-fsid attributes excepted) are
cached as a unit at the client so that no non-serializability can cached as a unit at the client so that no non-serializability can
arise within the context of a single file. arise within the context of a single file.
o An upper time boundary is maintained on how long a client cache * An upper time boundary is maintained on how long a client cache
entry can be kept without being refreshed from the server. entry can be kept without being refreshed from the server.
o When operations are performed that change attributes at the * When operations are performed that change attributes at the
server, the updated attribute set is requested as part of the server, the updated attribute set is requested as part of the
containing RPC. This includes directory operations that update containing RPC. This includes directory operations that update
attributes indirectly. This is accomplished by following the attributes indirectly. This is accomplished by following the
modifying operation with a GETATTR operation and then using the modifying operation with a GETATTR operation and then using the
results of the GETATTR to update the client's cached attributes. results of the GETATTR to update the client's cached attributes.
Note that if the full set of attributes to be cached is requested by Note that if the full set of attributes to be cached is requested by
READDIR, the results can be cached by the client on the same basis as READDIR, the results can be cached by the client on the same basis as
attributes obtained via GETATTR. attributes obtained via GETATTR.
skipping to change at page 220, line 27 skipping to change at line 10561
As long as each memory-mapped access to the file requires a page As long as each memory-mapped access to the file requires a page
fault, the relevant attributes of the file that are used to detect fault, the relevant attributes of the file that are used to detect
access and modification (time_access, time_metadata, time_modify, and access and modification (time_access, time_metadata, time_modify, and
change) will be updated. However, in many operating environments, change) will be updated. However, in many operating environments,
when page faults are not required, these attributes will not be when page faults are not required, these attributes will not be
updated on reads or updates to the file via memory access (regardless updated on reads or updates to the file via memory access (regardless
of whether the file is local or is accessed remotely). A client or of whether the file is local or is accessed remotely). A client or
server MAY fail to update attributes of a file that is being accessed server MAY fail to update attributes of a file that is being accessed
via memory-mapped I/O. This has several implications: via memory-mapped I/O. This has several implications:
o If there is an application on the server that has memory mapped a * If there is an application on the server that has memory mapped a
file that a client is also accessing, the client may not be able file that a client is also accessing, the client may not be able
to get a consistent value of the change attribute to determine to get a consistent value of the change attribute to determine
whether or not its cache is stale. A server that knows that the whether or not its cache is stale. A server that knows that the
file is memory-mapped could always pessimistically return updated file is memory-mapped could always pessimistically return updated
values for change so as to force the application to always get the values for change so as to force the application to always get the
most up-to-date data and metadata for the file. However, due to most up-to-date data and metadata for the file. However, due to
the negative performance implications of this, such behavior is the negative performance implications of this, such behavior is
OPTIONAL. OPTIONAL.
o If the memory-mapped file is not being modified on the server, and * If the memory-mapped file is not being modified on the server, and
instead is just being read by an application via the memory-mapped instead is just being read by an application via the memory-mapped
interface, the client will not see an updated time_access interface, the client will not see an updated time_access
attribute. However, in many operating environments, neither will attribute. However, in many operating environments, neither will
any process running on the server. Thus, NFS clients are at no any process running on the server. Thus, NFS clients are at no
disadvantage with respect to local processes. disadvantage with respect to local processes.
o If there is another client that is memory mapping the file, and if * If there is another client that is memory mapping the file, and if
that client is holding an OPEN_DELEGATE_WRITE delegation, the same that client is holding an OPEN_DELEGATE_WRITE delegation, the same
set of issues as discussed in the previous two bullet points set of issues as discussed in the previous two bullet points
apply. So, when a server does a CB_GETATTR to a file that the apply. So, when a server does a CB_GETATTR to a file that the
client has modified in its cache, the reply from CB_GETATTR will client has modified in its cache, the reply from CB_GETATTR will
not necessarily be accurate. As discussed earlier, the client's not necessarily be accurate. As discussed earlier, the client's
obligation is to report that the file has been modified since the obligation is to report that the file has been modified since the
delegation was granted, not whether it has been modified again delegation was granted, not whether it has been modified again
between successive CB_GETATTR calls, and the server MUST assume between successive CB_GETATTR calls, and the server MUST assume
that any file the client has modified in cache has been modified that any file the client has modified in cache has been modified
again between successive CB_GETATTR calls. Depending on the again between successive CB_GETATTR calls. Depending on the
nature of the client's memory management system, this weak nature of the client's memory management system, this weak
obligation may not be possible. A client MAY return stale obligation may not be possible. A client MAY return stale
information in CB_GETATTR whenever the file is memory-mapped. information in CB_GETATTR whenever the file is memory-mapped.
o The mixture of memory mapping and byte-range locking on the same * The mixture of memory mapping and byte-range locking on the same
file is problematic. Consider the following scenario, where a file is problematic. Consider the following scenario, where a
page size on each client is 8192 bytes. page size on each client is 8192 bytes.
* Client A memory maps the first page (8192 bytes) of file X. - Client A memory maps the first page (8192 bytes) of file X.
* Client B memory maps the first page (8192 bytes) of file X. - Client B memory maps the first page (8192 bytes) of file X.
* Client A WRITE_LT locks the first 4096 bytes. - Client A WRITE_LT locks the first 4096 bytes.
* Client B WRITE_LT locks the second 4096 bytes. - Client B WRITE_LT locks the second 4096 bytes.
* Client A, via a STORE instruction, modifies part of its locked - Client A, via a STORE instruction, modifies part of its locked
byte-range. byte-range.
* Simultaneous to client A, client B executes a STORE on part of - Simultaneous to client A, client B executes a STORE on part of
its locked byte-range. its locked byte-range.
Here the challenge is for each client to resynchronize to get a Here the challenge is for each client to resynchronize to get a
correct view of the first page. In many operating environments, the correct view of the first page. In many operating environments, the
virtual memory management systems on each client only know a page is virtual memory management systems on each client only know a page is
modified, not that a subset of the page corresponding to the modified, not that a subset of the page corresponding to the
respective lock byte-ranges has been modified. So it is not possible respective lock byte-ranges has been modified. So it is not possible
for each client to do the right thing, which is to write to the for each client to do the right thing, which is to write to the
server only that portion of the page that is locked. For example, if server only that portion of the page that is locked. For example, if
client A simply writes out the page, and then client B writes out the client A simply writes out the page, and then client B writes out the
skipping to change at page 222, line 5 skipping to change at line 10634
the entire page. Each client then tries to extend their locked range the entire page. Each client then tries to extend their locked range
to the entire page, which results in a deadlock. Communicating the to the entire page, which results in a deadlock. Communicating the
NFS4ERR_DEADLOCK error to a STORE instruction is difficult at best. NFS4ERR_DEADLOCK error to a STORE instruction is difficult at best.
If a client is locking the entire memory-mapped file, there is no If a client is locking the entire memory-mapped file, there is no
problem with advisory or mandatory byte-range locking, at least until problem with advisory or mandatory byte-range locking, at least until
the client unlocks a byte-range in the middle of the file. the client unlocks a byte-range in the middle of the file.
Given the above issues, the following are permitted: Given the above issues, the following are permitted:
o Clients and servers MAY deny memory mapping a file for which they * Clients and servers MAY deny memory mapping a file for which they
know there are byte-range locks. know there are byte-range locks.
o Clients and servers MAY deny a byte-range lock on a file they know * Clients and servers MAY deny a byte-range lock on a file they know
is memory-mapped. is memory-mapped.
o A client MAY deny memory mapping a file that it knows requires * A client MAY deny memory mapping a file that it knows requires
mandatory locking for I/O. If mandatory locking is enabled after mandatory locking for I/O. If mandatory locking is enabled after
the file is opened and mapped, the client MAY deny the application the file is opened and mapped, the client MAY deny the application
further access to its mapped file. further access to its mapped file.
10.8. Name and Directory Caching without Directory Delegations 10.8. Name and Directory Caching without Directory Delegations
The NFSv4.1 directory delegation facility (described in Section 10.9 The NFSv4.1 directory delegation facility (described in Section 10.9
below) is OPTIONAL for servers to implement. Even where it is below) is OPTIONAL for servers to implement. Even where it is
implemented, it may not always be functional because of resource implemented, it may not always be functional because of resource
availability issues or other constraints. Thus, it is important to availability issues or other constraints. Thus, it is important to
skipping to change at page 224, line 14 skipping to change at line 10739
10.8.2. Directory Caching 10.8.2. Directory Caching
The results of READDIR operations may be used to avoid subsequent The results of READDIR operations may be used to avoid subsequent
READDIR operations. Just as in the cases of attribute and name READDIR operations. Just as in the cases of attribute and name
caching, inconsistencies may arise among the various client caches. caching, inconsistencies may arise among the various client caches.
To mitigate the effects of these inconsistencies, and given the To mitigate the effects of these inconsistencies, and given the
context of typical file system APIs, the following rules should be context of typical file system APIs, the following rules should be
followed: followed:
o Cached READDIR information for a directory that is not obtained in * Cached READDIR information for a directory that is not obtained in
a single READDIR operation must always be a consistent snapshot of a single READDIR operation must always be a consistent snapshot of
directory contents. This is determined by using a GETATTR before directory contents. This is determined by using a GETATTR before
the first READDIR and after the last READDIR that contributes to the first READDIR and after the last READDIR that contributes to
the cache. the cache.
o An upper time boundary is maintained to indicate the length of * An upper time boundary is maintained to indicate the length of
time a directory cache entry is considered valid before the client time a directory cache entry is considered valid before the client
must revalidate the cached information. must revalidate the cached information.
The revalidation technique parallels that discussed in the case of The revalidation technique parallels that discussed in the case of
name caching. When the client is not changing the directory in name caching. When the client is not changing the directory in
question, checking the change attribute of the directory with GETATTR question, checking the change attribute of the directory with GETATTR
is adequate. The lifetime of the cache entry can be extended at is adequate. The lifetime of the cache entry can be extended at
these checkpoints. When a client is modifying the directory, the these checkpoints. When a client is modifying the directory, the
client needs to use the change_info4 data to determine whether there client needs to use the change_info4 data to determine whether there
are other clients modifying the directory. If it is determined that are other clients modifying the directory. If it is determined that
skipping to change at page 227, line 31 skipping to change at line 10898
not hand out delegations for that directory and/or recall those not hand out delegations for that directory and/or recall those
already granted. If a client tries to remove the directory for which already granted. If a client tries to remove the directory for which
a delegation has been granted, the server will recall all associated a delegation has been granted, the server will recall all associated
delegations. delegations.
The implementation sections for a number of operations describe The implementation sections for a number of operations describe
situations in which notification or delegation recall would be situations in which notification or delegation recall would be
required under some common circumstances. In this regard, a similar required under some common circumstances. In this regard, a similar
set of caveats to those listed in Section 10.2 apply. set of caveats to those listed in Section 10.2 apply.
o For CREATE, see Section 18.4.4. * For CREATE, see Section 18.4.4.
o For LINK, see Section 18.9.4. * For LINK, see Section 18.9.4.
o For OPEN, see Section 18.16.4. * For OPEN, see Section 18.16.4.
o For REMOVE, see Section 18.25.4. * For REMOVE, see Section 18.25.4.
o For RENAME, see Section 18.26.4. * For RENAME, see Section 18.26.4.
o For SETATTR, see Section 18.30.4. * For SETATTR, see Section 18.30.4.
10.9.5. Directory Delegation Recovery 10.9.5. Directory Delegation Recovery
Recovery from client or server restart for state on regular files has Recovery from client or server restart for state on regular files has
two main goals: avoiding the necessity of breaking application two main goals: avoiding the necessity of breaking application
guarantees with respect to locked files and delivery of updates guarantees with respect to locked files and delivery of updates
cached at the client. Neither of these goals applies to directories cached at the client. Neither of these goals applies to directories
protected by OPEN_DELEGATE_READ delegations and notifications. Thus, protected by OPEN_DELEGATE_READ delegations and notifications. Thus,
no provision is made for reclaiming directory delegations in the no provision is made for reclaiming directory delegations in the
event of client or server restart. The client can simply establish a event of client or server restart. The client can simply establish a
directory delegation in the same fashion as was done initially. directory delegation in the same fashion as was done initially.
11. Multi-Server Namespace 11. Multi-Server Namespace
NFSv4.1 supports attributes that allow a namespace to extend beyond NFSv4.1 supports attributes that allow a namespace to extend beyond
the boundaries of a single server. It is desirable that clients and the boundaries of a single server. It is desirable that clients and
servers support construction of such multi-server namespaces. Use of servers support construction of such multi-server namespaces. Use of
such multi-server namespaces is OPTIONAL however, and for many such multi-server namespaces is OPTIONAL; however, and for many
purposes, single-server namespaces are perfectly acceptable. Use of purposes, single-server namespaces are perfectly acceptable. The use
multi-server namespaces can provide many advantages, by separating a of multi-server namespaces can provide many advantages by separating
file system's logical position in a namespace from the (possibly a file system's logical position in a namespace from the (possibly
changing) logistical and administrative considerations that result in changing) logistical and administrative considerations that cause a
particular file systems being located on particular servers via a particular file system to be located on a particular server via a
single network access paths known in advance or determined using DNS. single network access path that has to be known in advance or
determined using DNS.
11.1. Terminology 11.1. Terminology
In this section as a whole (i.e. within all of Section 11), the In this section as a whole (i.e., within all of Section 11), the
phrase "client ID" always refers to the 64-bit shorthand identifier phrase "client ID" always refers to the 64-bit shorthand identifier
assigned by the server (a clientid4) and never to the structure which assigned by the server (a clientid4) and never to the structure that
the client uses to identify itself to the server (called an the client uses to identify itself to the server (called an
nfs_client_id4 or client_owner in NFSv4.0 and NFSv4.1 respectively). nfs_client_id4 or client_owner in NFSv4.0 and NFSv4.1, respectively).
The opaque identifier within those structures is referred to as a The opaque identifier within those structures is referred to as a
"client id string". "client id string".
11.1.1. Terminology Related to Trunking 11.1.1. Terminology Related to Trunking
It is particularly important to clarify the distinction between It is particularly important to clarify the distinction between
trunking detection and trunking discovery. The definitions we trunking detection and trunking discovery. The definitions we
present are applicable to all minor versions of NFSv4, but we will present are applicable to all minor versions of NFSv4, but we will
focus on how these terms apply to NFS version 4.1. focus on how these terms apply to NFS version 4.1.
o Trunking detection refers to ways of deciding whether two specific * Trunking detection refers to ways of deciding whether two specific
network addresses are connected to the same NFSv4 server. The network addresses are connected to the same NFSv4 server. The
means available to make this determination depends on the protocol means available to make this determination depends on the protocol
version, and, in some cases, on the client implementation. version, and, in some cases, on the client implementation.
In the case of NFS version 4.1 and later minor versions, the means In the case of NFS version 4.1 and later minor versions, the means
of trunking detection are as described in this document and are of trunking detection are as described in this document and are
available to every client. Two network addresses connected to the available to every client. Two network addresses connected to the
same server can always be used together to access a particular same server can always be used together to access a particular
server but cannot necessarily be used together to access a single server but cannot necessarily be used together to access a single
session. See below for definitions of the terms "server- session. See below for definitions of the terms "server-
trunkable" and "session-trunkable" trunkable" and "session-trunkable".
o Trunking discovery is a process by which a client using one * Trunking discovery is a process by which a client using one
network address can obtain other addresses that are connected to network address can obtain other addresses that are connected to
the same server. Typically, it builds on a trunking detection the same server. Typically, it builds on a trunking detection
facility by providing one or more methods by which candidate facility by providing one or more methods by which candidate
addresses are made available to the client who can then use addresses are made available to the client, who can then use
trunking detection to appropriately filter them. trunking detection to appropriately filter them.
Despite the support for trunking detection there was no Despite the support for trunking detection, there was no
description of trunking discovery provided in RFC5661 [65], making description of trunking discovery provided in RFC 5661 [66],
it necessary to provide those means in this document. making it necessary to provide those means in this document.
The combination of a server network address and a particular The combination of a server network address and a particular
connection type to be used by a connection is referred to as a connection type to be used by a connection is referred to as a
"server endpoint". Although using different connection types may "server endpoint". Although using different connection types may
result in different ports being used, the use of different ports by result in different ports being used, the use of different ports by
multiple connections to the same network address in such cases is not multiple connections to the same network address in such cases is not
the essence of the distinction between the two endpoints used. This the essence of the distinction between the two endpoints used. This
is in contrast to the case of port-specific endpoints, in which the is in contrast to the case of port-specific endpoints, in which the
explicit specification of port numbers within network addresses is explicit specification of port numbers within network addresses is
used to allow a single server node to support multiple NFS servers. used to allow a single server node to support multiple NFS servers.
Two network addresses connected to the same server are said to be Two network addresses connected to the same server are said to be
server-trunkable. Two such addresses support the use of clientid ID server-trunkable. Two such addresses support the use of client ID
trunking, as described in Section 2.10.5. trunking, as described in Section 2.10.5.
Two network addresses connected to the same server such that those Two network addresses connected to the same server such that those
addresses can be used to support a single common session are referred addresses can be used to support a single common session are referred
to as session-trunkable. Note that two addresses may be server- to as session-trunkable. Note that two addresses may be server-
trunkable without being session-trunkable and that when two trunkable without being session-trunkable, and that, when two
connections of different connection types are made to the same connections of different connection types are made to the same
network address and are based on a single file system location entry network address and are based on a single file system location entry,
they are always session-trunkable, independent of the connection they are always session-trunkable, independent of the connection
type, as specified by Section 2.10.5, since their derivation from the type, as specified by Section 2.10.5, since their derivation from the
same file system location entry together with the identity of their same file system location entry, together with the identity of their
network addresses assures that both connections are to the same network addresses, assures that both connections are to the same
server and will return server-owner information allowing session server and will return server-owner information, allowing session
trunking to be used. trunking to be used.
11.1.2. Terminology Related to File System Location 11.1.2. Terminology Related to File System Location
Regarding terminology relating to the construction of multi-server Regarding the terminology that relates to the construction of multi-
namespaces out of a set of local per-server namespaces: server namespaces out of a set of local per-server namespaces:
o Each server has a set of exported file systems which may be * Each server has a set of exported file systems that may be
accessed by NFSv4 clients. Typically, this is done by assigning accessed by NFSv4 clients. Typically, this is done by assigning
each file system a name within the pseudo-fs associated with the each file system a name within the pseudo-fs associated with the
server, although the pseudo-fs may be dispensed with if there is server, although the pseudo-fs may be dispensed with if there is
only a single exported file system. Each such file system is part only a single exported file system. Each such file system is part
of the server's local namespace, and can be considered as a file of the server's local namespace, and can be considered as a file
system instance within a larger multi-server namespace. system instance within a larger multi-server namespace.
o The set of all exported file systems for a given server * The set of all exported file systems for a given server
constitutes that server's local namespace. constitutes that server's local namespace.
o In some cases, a server will have a namespace more extensive than * In some cases, a server will have a namespace more extensive than
its local namespace by using features associated with attributes its local namespace by using features associated with attributes
that provide file system location information. These features, that provide file system location information. These features,
which allow construction of a multi-server namespace, are all which allow construction of a multi-server namespace, are all
described in individual sections below and include referrals described in individual sections below and include referrals
(described in Section 11.5.6), migration (described in (Section 11.5.6), migration (Section 11.5.5), and replication
Section 11.5.5), and replication (described in Section 11.5.4). (Section 11.5.4).
o A file system present in a server's pseudo-fs may have multiple * A file system present in a server's pseudo-fs may have multiple
file system instances on different servers associated with it. file system instances on different servers associated with it.
All such instances are considered replicas of one another. All such instances are considered replicas of one another.
Whether such replicas can be used simultaneously is discussed in Whether such replicas can be used simultaneously is discussed in
Section 11.11.1, while the level of co-ordination between them Section 11.11.1, while the level of coordination between them
(important when switching between them) is discussed in Sections (important when switching between them) is discussed in Sections
11.11.2 through 11.11.8 below. 11.11.2 through 11.11.8 below.
o When a file system is present in a server's pseudo-fs, but there * When a file system is present in a server's pseudo-fs, but there
is no corresponding local file system, it is said to be "absent". is no corresponding local file system, it is said to be "absent".
In such cases, all associated instances will be accessed on other In such cases, all associated instances will be accessed on other
servers. servers.
Regarding terminology relating to attributes used in trunking Regarding the terminology that relates to attributes used in trunking
discovery and other multi-server namespace features: discovery and other multi-server namespace features:
o File system location attributes include the fs_locations and * File system location attributes include the fs_locations and
fs_locations_info attributes. fs_locations_info attributes.
o File system location entries provide the individual file system * File system location entries provide the individual file system
locations within the file system location attributes. Each such locations within the file system location attributes. Each such
entry specifies a server, in the form of a host name or an entry specifies a server, in the form of a hostname or an address,
address, and an fs name, which designates the location of the file and an fs name, which designates the location of the file system
system within the server's local namespace. A file system within the server's local namespace. A file system location entry
location entry designates a set of server endpoints to which the designates a set of server endpoints to which the client may
client may establish connections. There may be multiple endpoints establish connections. There may be multiple endpoints because a
because a host name may map to multiple network addresses and hostname may map to multiple network addresses and because
because multiple connection types may be used to communicate with multiple connection types may be used to communicate with a single
a single network address. However, except where an explicit port network address. However, except where explicit port numbers are
numbers are used to designate a set of server within a single used to designate a set of servers within a single server node,
server node, all such endpoints MUST designate a way of connecting all such endpoints MUST designate a way of connecting to a single
to a single server. The exact form of the location entry varies server. The exact form of the location entry varies with the
with the particular file system location attribute used, as particular file system location attribute used, as described in
described in Section 11.2. Section 11.2.
The network addresses used in file system location entries The network addresses used in file system location entries
typically appear without port number indications and are used to typically appear without port number indications and are used to
designate a server at one of the standard ports for NFS access, designate a server at one of the standard ports for NFS access,
e.g., 2049 for TCP, or 20049 for use with RPC-over-RDMA. Port e.g., 2049 for TCP or 20049 for use with RPC-over-RDMA. Port
numbers may be used in file system location entries to designate numbers may be used in file system location entries to designate
servers (typically user-level ones) accessed using other port servers (typically user-level ones) accessed using other port
numbers. In the case where network addresses indicate trunking numbers. In the case where network addresses indicate trunking
relationships, use of an explicit port number is inappropriate relationships, the use of an explicit port number is inappropriate
since trunking is a relationship between network addresses. See since trunking is a relationship between network addresses. See
Section 11.5.2 for details. Section 11.5.2 for details.
o File system location elements are derived from location entries * File system location elements are derived from location entries,
and each describes a particular network access path, consisting of and each describes a particular network access path consisting of
a network address and a location within the server's local a network address and a location within the server's local
namespace. Such location elements need not appear within a file namespace. Such location elements need not appear within a file
system location attribute, but the existence of each location system location attribute, but the existence of each location
element derives from a corresponding location entry. When a element derives from a corresponding location entry. When a
location entry specifies an IP address there is only a single location entry specifies an IP address, there is only a single
corresponding location element. File system location entries that corresponding location element. File system location entries that
contain a host name are resolved using DNS, and may result in one contain a hostname are resolved using DNS, and may result in one
or more location elements. All location elements consist of a or more location elements. All location elements consist of a
location address which includes the IP address of an interface to location address that includes the IP address of an interface to a
a server and an fs name which is the location of the file system server and an fs name, which is the location of the file system
within the server's local namespace. The fs name can be empty if within the server's local namespace. The fs name can be empty if
the server has no pseudo-fs and only a single exported file system the server has no pseudo-fs and only a single exported file system
at the root filehandle. at the root filehandle.
o Two file system location elements are said to be server-trunkable * Two file system location elements are said to be server-trunkable
if they specify the same fs name and the location addresses are if they specify the same fs name and the location addresses are
such that the location addresses are server-trunkable. When the such that the location addresses are server-trunkable. When the
corresponding network paths are used, the client will always be corresponding network paths are used, the client will always be
able to use client ID trunking, but will only be able to use able to use client ID trunking, but will only be able to use
session trunking if the paths are also session-trunkable. session trunking if the paths are also session-trunkable.
o Two file system location elements are said to be session-trunkable * Two file system location elements are said to be session-trunkable
if they specify the same fs name and the location addresses are if they specify the same fs name and the location addresses are
such that the location addresses are session-trunkable. When the such that the location addresses are session-trunkable. When the
corresponding network paths are used, the client will be able to corresponding network paths are used, the client will be able to
able to use either client ID trunking or session trunking. able to use either client ID trunking or session trunking.
Discussion of the term "replica" is complicated by the fact that the Discussion of the term "replica" is complicated by the fact that the
term was used in RFC5661 [65], with a meaning different from that in term was used in RFC 5661 [66] with a meaning different from that
this document. In short, in [65] each replica is identified by a used in this document. In short, in [66] each replica is identified
single network access path while, in the current document a set of by a single network access path, while in the current document, a set
network access paths which have server-trunkable network addresses of network access paths that have server-trunkable network addresses
and the same root-relative file system pathname is considered to be a and the same root-relative file system pathname is considered to be a
single replica with multiple network access paths. single replica with multiple network access paths.
Each set of server-trunkable location elements defines a set of Each set of server-trunkable location elements defines a set of
available network access paths to a particular file system. When available network access paths to a particular file system. When
there are multiple such file systems, each of which contains the same there are multiple such file systems, each of which containing the
data, these file systems are considered replicas of one another. same data, these file systems are considered replicas of one another.
Logically, such replication is symmetric, since the fs currently in Logically, such replication is symmetric, since the fs currently in
use and an alternate fs are replicas of each other. Often, in other use and an alternate fs are replicas of each other. Often, in other
documents, the term "replica" is not applied to the fs currently in documents, the term "replica" is not applied to the fs currently in
use, despite the fact that the replication relation is inherently use, despite the fact that the replication relation is inherently
symmetric. symmetric.
11.2. File System Location Attributes 11.2. File System Location Attributes
NFSv4.1 contains attributes that provide information about how (i.e., NFSv4.1 contains attributes that provide information about how a
at what network address and namespace position) a given file system given file system may be accessed (i.e., at what network address and
may be accessed. As a result, file systems in the namespace of one namespace position). As a result, file systems in the namespace of
server can be associated with one or more instances of that file one server can be associated with one or more instances of that file
system on other servers. These attributes contain file system system on other servers. These attributes contain file system
location entries specifying a server address target (either as a DNS location entries specifying a server address target (either as a DNS
name representing one or more IP addresses or as a specific IP name representing one or more IP addresses or as a specific IP
address) together with the pathname of that file system within the address) together with the pathname of that file system within the
associated single-server namespace. associated single-server namespace.
The fs_locations_info RECOMMENDED attribute allows specification of The fs_locations_info RECOMMENDED attribute allows specification of
one or more file system instance locations where the data one or more file system instance locations where the data
corresponding to a given file system may be found. This attribute corresponding to a given file system may be found. In addition to
provides to the client, in addition to specification of file system the specification of file system instance locations, this attribute
instance locations, other helpful information such as: provides helpful information to do the following:
o Information guiding choices among the various file system * Guide choices among the various file system instances provided
instances provided (e.g., priority for use, writability, currency, (e.g., priority for use, writability, currency, etc.).
etc.).
o Information to help the client efficiently effect as seamless a * Help the client efficiently effect as seamless a transition as
transition as possible among multiple file system instances, when possible among multiple file system instances, when and if that
and if that should be necessary. should be necessary.
o Information helping to guide the selection of the appropriate * Guide the selection of the appropriate connection type to be used
connection type to be used when establishing a connection. when establishing a connection.
Within the fs_locations_info attribute, each fs_locations_server4 Within the fs_locations_info attribute, each fs_locations_server4
entry corresponds to a file system location entry with the fls_server entry corresponds to a file system location entry: the fls_server
field designating the server, with the location pathname within the field designates the server, and the fl_rootpath field of the
server's pseudo-fs given by the fl_rootpath field of the encompassing encompassing fs_locations_item4 gives the location pathname within
fs_locations_item4. the server's pseudo-fs.
The fs_locations attribute defined in NFSv4.0 is also a part of The fs_locations attribute defined in NFSv4.0 is also a part of
NFSv4.1. This attribute only allows specification of the file system NFSv4.1. This attribute only allows specification of the file system
locations where the data corresponding to a given file system may be locations where the data corresponding to a given file system may be
found. Servers SHOULD make this attribute available whenever found. Servers SHOULD make this attribute available whenever
fs_locations_info is supported, but client use of fs_locations_info fs_locations_info is supported, but client use of fs_locations_info
is preferable, as it provides more information. is preferable because it provides more information.
Within the fs_location attribute, each fs_location4 contains a file Within the fs_locations attribute, each fs_location4 contains a file
system location entry with the server field designating the server system location entry with the server field designating the server
and the rootpath field giving the location pathname within the and the rootpath field giving the location pathname within the
server's pseudo-fs. server's pseudo-fs.
11.3. File System Presence or Absence 11.3. File System Presence or Absence
A given location in an NFSv4.1 namespace (typically but not A given location in an NFSv4.1 namespace (typically but not
necessarily a multi-server namespace) can have a number of file necessarily a multi-server namespace) can have a number of file
system instance locations associated with it (via the fs_locations or system instance locations associated with it (via the fs_locations or
fs_locations_info attribute). There may also be an actual current fs_locations_info attribute). There may also be an actual current
skipping to change at page 235, line 44 skipping to change at line 11294
A READDIR performed when the current filehandle is within an absent A READDIR performed when the current filehandle is within an absent
file system will result in an NFS4ERR_MOVED error, since, unlike the file system will result in an NFS4ERR_MOVED error, since, unlike the
case of GETATTR, no such exception is made for READDIR. case of GETATTR, no such exception is made for READDIR.
Attributes for an absent file system may be fetched via a READDIR for Attributes for an absent file system may be fetched via a READDIR for
a directory in a present file system, when that directory contains a directory in a present file system, when that directory contains
the root directories of one or more absent file systems. In this the root directories of one or more absent file systems. In this
case, the handling is as follows: case, the handling is as follows:
o If the attribute set requested includes one of the attributes * If the attribute set requested includes one of the attributes
fs_locations, fs_locations_info, or fs_status, then fetching of fs_locations, fs_locations_info, or fs_status, then fetching of
attributes proceeds normally and no NFS4ERR_MOVED indication is attributes proceeds normally and no NFS4ERR_MOVED indication is
returned, even when the rdattr_error attribute is requested. returned, even when the rdattr_error attribute is requested.
o If the attribute set requested does not include one of the * If the attribute set requested does not include one of the
attributes fs_locations, fs_locations_info, or fs_status, then if attributes fs_locations, fs_locations_info, or fs_status, then if
the rdattr_error attribute is requested, each directory entry for the rdattr_error attribute is requested, each directory entry for
the root of an absent file system will report NFS4ERR_MOVED as the the root of an absent file system will report NFS4ERR_MOVED as the
value of the rdattr_error attribute. value of the rdattr_error attribute.
o If the attribute set requested does not include any of the * If the attribute set requested does not include any of the
attributes fs_locations, fs_locations_info, fs_status, or attributes fs_locations, fs_locations_info, fs_status, or
rdattr_error, then the occurrence of the root of an absent file rdattr_error, then the occurrence of the root of an absent file
system within the directory will result in the READDIR failing system within the directory will result in the READDIR failing
with an NFS4ERR_MOVED error. with an NFS4ERR_MOVED error.
o The unavailability of an attribute because of a file system's * The unavailability of an attribute because of a file system's
absence, even one that is ordinarily REQUIRED, does not result in absence, even one that is ordinarily REQUIRED, does not result in
any error indication. The set of attributes returned for the root any error indication. The set of attributes returned for the root
directory of the absent file system in that case is simply directory of the absent file system in that case is simply
restricted to those actually available. restricted to those actually available.
11.5. Uses of File System Location Information 11.5. Uses of File System Location Information
The file system location attributes (i.e. fs_locations and The file system location attributes (i.e., fs_locations and
fs_locations_info), together with the possibility of absent file fs_locations_info), together with the possibility of absent file
systems, provide a number of important facilities in providing systems, provide a number of important facilities for reliable,
reliable, manageable, and scalable data access. manageable, and scalable data access.
When a file system is present, these attributes can provide When a file system is present, these attributes can provide the
following:
o The locations of alternative replicas, to be used to access the * The locations of alternative replicas to be used to access the
same data in the event of server failures, communications same data in the event of server failures, communications
problems, or other difficulties that make continued access to the problems, or other difficulties that make continued access to the
current replica impossible or otherwise impractical. Provision current replica impossible or otherwise impractical. Provisioning
and use of such alternate replicas is referred to as "replication" and use of such alternate replicas is referred to as "replication"
and is discussed in Section 11.5.4 below. and is discussed in Section 11.5.4 below.
o The network address(es) to be used to access the current file * The network address(es) to be used to access the current file
system instance or replicas of it. Client use of this information system instance or replicas of it. Client use of this information
is discussed in Section 11.5.2 below. is discussed in Section 11.5.2 below.
Under some circumstances, multiple replicas may be used Under some circumstances, multiple replicas may be used
simultaneously to provide higher-performance access to the file simultaneously to provide higher-performance access to the file
system in question, although the lack of state sharing between system in question, although the lack of state sharing between
servers may be an impediment to such use. servers may be an impediment to such use.
When a file system is present and becomes absent, clients can be When a file system is present but becomes absent, clients can be
given the opportunity to have continued access to their data, using a given the opportunity to have continued access to their data using a
different replica. In this case, a continued attempt to use the data different replica. In this case, a continued attempt to use the data
in the now-absent file system will result in an NFS4ERR_MOVED error in the now-absent file system will result in an NFS4ERR_MOVED error,
and, at that point, the successor replica or set of possible replica and then the successor replica or set of possible replica choices can
choices can be fetched and used to continue access. Transfer of be fetched and used to continue access. Transfer of access to the
access to the new replica location is referred to as "migration", and new replica location is referred to as "migration" and is discussed
is discussed in Section 11.5.4 below. in Section 11.5.4 below.
Where a file system is currently absent, specification of file system When a file system is currently absent, specification of file system
location provides a means by which file systems located on one server location provides a means by which file systems located on one server
can be associated with a namespace defined by another server, thus can be associated with a namespace defined by another server, thus
allowing a general multi-server namespace facility. A designation of allowing a general multi-server namespace facility. A designation of
such a remote instance, in place of a file system not previously such a remote instance, in place of a file system not previously
present, is called a "pure referral" and is discussed in present, is called a "pure referral" and is discussed in
Section 11.5.6 below. Section 11.5.6 below.
Because client support for attributes related to file system location Because client support for attributes related to file system location
is OPTIONAL, a server may choose to take action to hide migration and is OPTIONAL, a server may choose to take action to hide migration and
referral events from such clients, by acting as a proxy, for example. referral events from such clients, by acting as a proxy, for example.
The server can determine the presence of client support from the The server can determine the presence of client support from the
arguments of the EXCHANGE_ID operation (see Section 18.35.3). arguments of the EXCHANGE_ID operation (see Section 18.35.3).
11.5.1. Combining Multiple Uses in a Single Attribute 11.5.1. Combining Multiple Uses in a Single Attribute
A file system location attribute will sometimes contain information A file system location attribute will sometimes contain information
relating to the location of multiple replicas which may be used in relating to the location of multiple replicas, which may be used in
different ways. different ways:
o File system location entries that relate to the file system * File system location entries that relate to the file system
instance currently in use provide trunking information, allowing instance currently in use provide trunking information, allowing
the client to find additional network addresses by which the the client to find additional network addresses by which the
instance may be accessed. instance may be accessed.
o File system location entries that provide information about * File system location entries that provide information about
replicas to which access is to be transferred. replicas to which access is to be transferred.
o Other file system location entries that relate to replicas that * Other file system location entries that relate to replicas that
are available to use in the event that access to the current are available to use in the event that access to the current
replica becomes unsatisfactory. replica becomes unsatisfactory.
In order to simplify client handling and allow the best choice of In order to simplify client handling and to allow the best choice of
replicas to access, the server should adhere to the following replicas to access, the server should adhere to the following
guidelines. guidelines:
o All file system location entries that relate to a single file * All file system location entries that relate to a single file
system instance should be adjacent. system instance should be adjacent.
o File system location entries that relate to the instance currently * File system location entries that relate to the instance currently
in use should appear first. in use should appear first.
o File system location entries that relate to replica(s) to which * File system location entries that relate to replica(s) to which
migration is occurring should appear before replicas which are migration is occurring should appear before replicas that are
available for later use if the current replica should become available for later use if the current replica should become
inaccessible. inaccessible.
11.5.2. File System Location Attributes and Trunking 11.5.2. File System Location Attributes and Trunking
Trunking is the use of multiple connections between a client and Trunking is the use of multiple connections between a client and
server in order to increase the speed of data transfer. A client may server in order to increase the speed of data transfer. A client may
determine the set of network addresses to use to access a given file determine the set of network addresses to use to access a given file
system in a number of ways: system in a number of ways:
o When the name of the server is known to the client, it may use DNS * When the name of the server is known to the client, it may use DNS
to obtain a set of network addresses to use in accessing the to obtain a set of network addresses to use in accessing the
server. server.
o The client may fetch the file system location attribute for the * The client may fetch the file system location attribute for the
file system. This will provide either the name of the server file system. This will provide either the name of the server
(which can be turned into a set of network addresses using DNS), (which can be turned into a set of network addresses using DNS) or
or a set of server-trunkable location entries. Using the latter a set of server-trunkable location entries. Using the latter
alternative, the server can provide addresses it regards as alternative, the server can provide addresses it regards as
desirable to use to access the file system in question. Although desirable to use to access the file system in question. Although
these entries can contain port numbers, these port numbers are not these entries can contain port numbers, these port numbers are not
used in determining trunking relationships. Once the candidate used in determining trunking relationships. Once the candidate
addresses have been determined and EXCHANGE_ID done to the proper addresses have been determined and EXCHANGE_ID done to the proper
server, only the value of the so_major field returned by the server, only the value of the so_major_id field returned by the
servers in question determines whether a trunking relationship servers in question determines whether a trunking relationship
actually exists. actually exists.
It should be noted that the client, when it fetches a location When the client fetches a location attribute for a file system, it
attribute for a file system, may encounter multiple entries for a should be noted that the client may encounter multiple entries for a
number of reasons, so that, when determining trunking information, it number of reasons, such that when it determines trunking information,
may have to bypass addresses not trunkable with one already known. it may need to bypass addresses not trunkable with one already known.
The server can provide location entries that include either names or The server can provide location entries that include either names or
network addresses. It might use the latter form because of DNS- network addresses. It might use the latter form because of DNS-
related security concerns or because the set of addresses to be used related security concerns or because the set of addresses to be used
might require active management by the server. might require active management by the server.
Location entries used to discover candidate addresses for use in Location entries used to discover candidate addresses for use in
trunking are subject to change, as discussed in Section 11.5.7 below. trunking are subject to change, as discussed in Section 11.5.7 below.
The client may respond to such changes by using additional addresses The client may respond to such changes by using additional addresses
once they are verified or by ceasing to use existing ones. The once they are verified or by ceasing to use existing ones. The
server can force the client to cease using an address by returning server can force the client to cease using an address by returning
NFS4ERR_MOVED when that address is used to access a file system. NFS4ERR_MOVED when that address is used to access a file system.
This allows a transfer of client access which is similar to This allows a transfer of client access that is similar to migration,
migration, although the same file system instance is accessed although the same file system instance is accessed throughout.
throughout.
11.5.3. File System Location Attributes and Connection Type Selection 11.5.3. File System Location Attributes and Connection Type Selection
Because of the need to support multiple types of connections, clients Because of the need to support multiple types of connections, clients
face the issue of determining the proper connection type to use when face the issue of determining the proper connection type to use when
establishing a connection to a given server network address. In some establishing a connection to a given server network address. In some
cases, this issue can be addressed through the use of the connection cases, this issue can be addressed through the use of the connection
"step-up" facility described in Section 18.36. However, because "step-up" facility described in Section 18.36. However, because
there are cases is which that facility is not available, the client there are cases in which that facility is not available, the client
may have to choose a connection type with no possibility of changing may have to choose a connection type with no possibility of changing
it within the scope of a single connection. it within the scope of a single connection.
The two file system location attributes differ as to the information The two file system location attributes differ as to the information
made available in this regard. Fs_locations provides no information made available in this regard. The fs_locations attribute provides
to support connection type selection. As a result, clients no information to support connection type selection. As a result,
supporting multiple connection types would need to attempt to clients supporting multiple connection types would need to attempt to
establish connections using multiple connection types until the one establish connections using multiple connection types until the one
preferred by the client is successfully established. preferred by the client is successfully established.
Fs_locations_info includes a flag, FSLI4TF_RDMA, which, when set The fs_locations_info attribute includes the FSLI4TF_RDMA flag, which
indicates that RPC-over-RDMA support is available using the specified is convenient for a client wishing to use RDMA. When this flag is
location entry, by "stepping up" an existing TCP connection to set, it indicates that RPC-over-RDMA support is available using the
include support for RDMA operation. This flag makes it convenient specified location entry. A client can establish a TCP connection
for a client wishing to use RDMA. When this flag is set, it can and then convert that connection to use RDMA by using the step-up
establish a TCP connection and then convert that connection to use facility.
RDMA by using the step-up facility.
Irrespective of the particular attribute used, when there is no Irrespective of the particular attribute used, when there is no
indication that a step-up operation can be performed, a client indication that a step-up operation can be performed, a client
supporting RDMA operation can establish a new RDMA connection and it supporting RDMA operation can establish a new RDMA connection, and it
can be bound to the session already established by the TCP can be bound to the session already established by the TCP
connection, allowing the TCP connection to be dropped and the session connection, allowing the TCP connection to be dropped and the session
converted to further use in RDMA mode, if the server supports that. converted to further use in RDMA mode, if the server supports that.
11.5.4. File System Replication 11.5.4. File System Replication
The fs_locations and fs_locations_info attributes provide alternative The fs_locations and fs_locations_info attributes provide alternative
file system locations, to be used to access data in place of or in file system locations, to be used to access data in place of or in
addition to the current file system instance. On first access to a addition to the current file system instance. On first access to a
file system, the client should obtain the set of alternate locations file system, the client should obtain the set of alternate locations
skipping to change at page 240, line 12 skipping to change at line 11495
file system impossible or otherwise impractical, the client can use file system impossible or otherwise impractical, the client can use
the alternate locations as a way to get continued access to its data. the alternate locations as a way to get continued access to its data.
The alternate locations may be physical replicas of the (typically The alternate locations may be physical replicas of the (typically
read-only) file system data supplemented by possible asynchronous read-only) file system data supplemented by possible asynchronous
propagation of updates. Alternatively, they may provide for the use propagation of updates. Alternatively, they may provide for the use
of various forms of server clustering in which multiple servers of various forms of server clustering in which multiple servers
provide alternate ways of accessing the same physical file system. provide alternate ways of accessing the same physical file system.
How the difference between replicas affects file system transitions How the difference between replicas affects file system transitions
can be represented within the fs_locations and fs_locations_info can be represented within the fs_locations and fs_locations_info
attributes and how the client deals with file system transition attributes, and how the client deals with file system transition
issues will be discussed in detail in later sections. issues will be discussed in detail in later sections.
Although the location attributes provide some information about the Although the location attributes provide some information about the
nature of the inter-replica transition, many aspects of the semantics nature of the inter-replica transition, many aspects of the semantics
of possible asynchronous updates are not currently described by the of possible asynchronous updates are not currently described by the
protocol, making it necessary that clients using replication to protocol, which makes it necessary for clients using replication to
switch among replicas undergoing change familiarize themselves with switch among replicas undergoing change to familiarize themselves
the semantics of the update approach used. Because of this lack of with the semantics of the update approach used. Due to this lack of
specificity, many applications may find use of migration more specificity, many applications may find the use of migration more
appropriate, since, in that case, the server, when effecting the appropriate because a server can propagate all updates made before an
transition, has established a point in time such that all updates established point in time to the new replica as part of the migration
made before that can propagated to the new replica as part of the event.
migration event.
11.5.4.1. File System Trunking Presented as Replication 11.5.4.1. File System Trunking Presented as Replication
In some situations, a file system location entry may indicate a file In some situations, a file system location entry may indicate a file
system access path to be used as an alternate location, where system access path to be used as an alternate location, where
trunking, rather than replication, is to be used. The situations in trunking, rather than replication, is to be used. The situations in
which this is appropriate are limited to those in which both of the which this is appropriate are limited to those in which both of the
following are true. following are true:
o The two file system locations (i.e., the one on which the location * The two file system locations (i.e., the one on which the location
attribute is obtained and the one specified in the file system attribute is obtained and the one specified in the file system
location entry) designate the same locations within their location entry) designate the same locations within their
respective single-server namespaces. respective single-server namespaces.
o The two server network addresses (i.e., the one being used to * The two server network addresses (i.e., the one being used to
obtain the location attribute and the one specified in the file obtain the location attribute and the one specified in the file
system location entry) designate the same server (as indicated by system location entry) designate the same server (as indicated by
the same value of the so_major_id field of the eir_server_owner the same value of the so_major_id field of the eir_server_owner
field returned in response to EXCHANGE_ID). field returned in response to EXCHANGE_ID).
When these conditions hold, operations using both access paths are When these conditions hold, operations using both access paths are
generally trunked, although, when the attribute fs_locations_info is generally trunked, although trunking may be disallowed when the
used, trunking may be disallowed: attribute fs_locations_info is used:
o When the fs_locations_info attribute shows the two entries as not * When the fs_locations_info attribute shows the two entries as not
having the same simultaneous-use class, trunking is inhibited and having the same simultaneous-use class, trunking is inhibited, and
the two access paths cannot be used together. the two access paths cannot be used together.
In this case the two paths can be used serially with no transition In this case, the two paths can be used serially with no
activity required on the part of the client. In this case, any transition activity required on the part of the client, and any
transition between access paths is transparent, and the client, in transition between access paths is transparent. In transferring
transferring access from one to the other, is acting as it would access from one to the other, the client acts as if communication
in the event that communication is interrupted, with a new were interrupted, establishing a new connection and possibly a new
connection and possibly a new session being established to session to continue access to the same file system.
continue access to the same file system.
o Note that for two such location entries, any information within * Note that for two such location entries, any information within
the fs_locations_info attribute that indicates the need for the fs_locations_info attribute that indicates the need for
special transition activity, i.e., the appearance of the two file special transition activity, i.e., the appearance of the two file
system location entries with different handle, fileid, write- system location entries with different handle, fileid, write-
verifier, change, and readdir classes, indicates a serious verifier, change, and readdir classes, indicates a serious
problem. The client, if it allows transition to the file system problem. The client, if it allows transition to the file system
instance at all, must not treat any transition as a transparent instance at all, must not treat any transition as a transparent
one. The server SHOULD NOT indicate that these two entries (for one. The server SHOULD NOT indicate that these two entries (for
the same file system on the same server) belong to different the same file system on the same server) belong to different
handle, fileid, write-verifier, change, and readdir classes, handle, fileid, write-verifier, change, and readdir classes,
whether or not the two entries are shown belonging to the same whether or not the two entries are shown belonging to the same
simultaneous-use class. simultaneous-use class.
These situations were recognized by [65], even though that document These situations were recognized by [66], even though that document
made no explicit mention of trunking. made no explicit mention of trunking:
o It treated the situation that we describe as trunking as one of * It treated the situation that we describe as trunking as one of
simultaneous use of two distinct file system instances, even simultaneous use of two distinct file system instances, even
though, in the explanatory framework now used to describe the though, in the explanatory framework now used to describe the
situation, the case is one in which a single file system is situation, the case is one in which a single file system is
accessed by two different trunked addresses. accessed by two different trunked addresses.
o It treated the situation in which two paths are to be used * It treated the situation in which two paths are to be used
serially as a special sort of "transparent transition". however, serially as a special sort of "transparent transition". However,
in the descriptive framework now used to categorize transition in the descriptive framework now used to categorize transition
situations, this is considered a case of a "network endpoint situations, this is considered a case of a "network endpoint
transition" (see Section 11.9). transition" (see Section 11.9).
11.5.5. File System Migration 11.5.5. File System Migration
When a file system is present and becomes inaccessible using the When a file system is present and becomes inaccessible using the
current access path, the NFSv4.1 protocol provides a means by which current access path, the NFSv4.1 protocol provides a means by which
clients can be given the opportunity to have continued access to clients can be given the opportunity to have continued access to
their data. This may involve use of a different access path to the their data. This may involve using a different access path to the
existing replica or by providing a path to a different replica. The existing replica or providing a path to a different replica. The new
new access path or the location of the new replica is specified by a access path or the location of the new replica is specified by a file
file system location attribute. The ensuing migration of access system location attribute. The ensuing migration of access includes
includes the ability to retain locks across the transition. the ability to retain locks across the transition. Depending on
Depending on circumstances, this can involve: circumstances, this can involve:
o The continued use of the existing clientid when accessing the * The continued use of the existing clientid when accessing the
current replica using a new access path. current replica using a new access path.
o Use of lock reclaim, taking advantage of a per-fs grace period. * Use of lock reclaim, taking advantage of a per-fs grace period.
o Use of Transparent State Migration. * Use of Transparent State Migration.
Typically, a client will be accessing the file system in question, Typically, a client will be accessing the file system in question,
get an NFS4ERR_MOVED error, and then use a file system location get an NFS4ERR_MOVED error, and then use a file system location
attribute to determine the new access path for the data. When attribute to determine the new access path for the data. When
fs_locations_info is used, additional information will be available fs_locations_info is used, additional information will be available
that will define the nature of the client's handling of the that will define the nature of the client's handling of the
transition to a new server. transition to a new server.
In most instances, servers will choose to migrate all clients using a In most instances, servers will choose to migrate all clients using a
particular file system to a successor replica at the same time to particular file system to a successor replica at the same time to
avoid cases in which different clients are updating different avoid cases in which different clients are updating different
replicas. However migration of individual client can be helpful in replicas. However, migration of an individual client can be helpful
providing load balancing, as long as the replicas in question are in providing load balancing, as long as the replicas in question are
such that they represent the same data as described in such that they represent the same data as described in
Section 11.11.8. Section 11.11.8.
o In the case in which there is no transition between replicas * In the case in which there is no transition between replicas
(i.e., only a change in access path), there are no special (i.e., only a change in access path), there are no special
difficulties in using of this mechanism to effect load balancing. difficulties in using of this mechanism to effect load balancing.
o In the case in which the two replicas are sufficiently co- * In the case in which the two replicas are sufficiently coordinated
ordinated as to allow coherent simultaneous access to both by a as to allow a single client coherent, simultaneous access to both,
single client, there is, in general, no obstacle to use of there is, in general, no obstacle to the use of migration of
migration of particular clients to effect load balancing. particular clients to effect load balancing. Generally, such
Generally, such simultaneous use involves co-operation between simultaneous use involves cooperation between servers to ensure
servers to ensure that locks granted on two co-ordinated replicas that locks granted on two coordinated replicas cannot conflict and
cannot conflict and can remain effective when transferred to a can remain effective when transferred to a common replica.
common replica.
o In the case in which a large set of clients are accessing a file * In the case in which a large set of clients is accessing a file
system in a read-only fashion, in can be helpful to migrate all system in a read-only fashion, it can be helpful to migrate all
clients with writable access simultaneously, while using load clients with writable access simultaneously, while using load
balancing on the set of read-only copies, as long as the rules balancing on the set of read-only copies, as long as the rules in
appearing in Section 11.11.8, designed to prevent data reversion Section 11.11.8, which are designed to prevent data reversion, are
are adhered to. followed.
In other cases, the client might not have sufficient guarantees of In other cases, the client might not have sufficient guarantees of
data similarity/coherence to function properly (e.g. the data in the data similarity or coherence to function properly (e.g., the data in
two replicas is similar but not identical), and the possibility that the two replicas is similar but not identical), and the possibility
different clients are updating different replicas can exacerbate the that different clients are updating different replicas can exacerbate
difficulties, making use of load balancing in such situations a the difficulties, making the use of load balancing in such situations
perilous enterprise. a perilous enterprise.
The protocol does not specify how the file system will be moved The protocol does not specify how the file system will be moved
between servers or how updates to multiple replicas will be co- between servers or how updates to multiple replicas will be
ordinated. It is anticipated that a number of different server-to- coordinated. It is anticipated that a number of different server-to-
server co-ordination mechanisms might be used with the choice left to server coordination mechanisms might be used, with the choice left to
the server implementer. The NFSv4.1 protocol specifies the method the server implementer. The NFSv4.1 protocol specifies the method
used to communicate the migration event between client and server. used to communicate the migration event between client and server.
The new location may be, in the case of various forms of server In the case of various forms of server clustering, the new location
clustering, another server providing access to the same physical file may be another server providing access to the same physical file
system. The client's responsibilities in dealing with this system. The client's responsibilities in dealing with this
transition will depend on whether a switch between replicas has transition will depend on whether a switch between replicas has
occurred and the means the server has chosen to provide continuity of occurred and the means the server has chosen to provide continuity of
locking state. These issues will be discussed in detail below. locking state. These issues will be discussed in detail below.
Although a single successor location is typical, multiple locations Although a single successor location is typical, multiple locations
may be provided. When multiple locations are provided, the client may be provided. When multiple locations are provided, the client
will typically use the first one provided. If that is inaccessible will typically use the first one provided. If that is inaccessible
for some reason, later ones can be used. In such cases the client for some reason, later ones can be used. In such cases, the client
might consider the transition to the new replica to be a migration might consider the transition to the new replica to be a migration
event, even though some of the servers involved might not be aware of event, even though some of the servers involved might not be aware of
the use of the server which was inaccessible. In such a case, a the use of the server that was inaccessible. In such a case, a
client might lose access to locking state as a result of the access client might lose access to locking state as a result of the access
transfer. transfer.
When an alternate location is designated as the target for migration, When an alternate location is designated as the target for migration,
it must designate the same data (with metadata being the same to the it must designate the same data (with metadata being the same to the
degree indicated by the fs_locations_info attribute). Where file degree indicated by the fs_locations_info attribute). Where file
systems are writable, a change made on the original file system must systems are writable, a change made on the original file system must
be visible on all migration targets. Where a file system is not be visible on all migration targets. Where a file system is not
writable but represents a read-only copy (possibly periodically writable but represents a read-only copy (possibly periodically
updated) of a writable file system, similar requirements apply to the updated) of a writable file system, similar requirements apply to the
skipping to change at page 244, line 5 skipping to change at line 11680
located on one server with a file system located on another server. located on one server with a file system located on another server.
When this includes the use of pure referrals, servers are provided a When this includes the use of pure referrals, servers are provided a
way of placing a file system in a location within the namespace way of placing a file system in a location within the namespace
essentially without respect to its physical location on a particular essentially without respect to its physical location on a particular
server. This allows a single server or a set of servers to present a server. This allows a single server or a set of servers to present a
multi-server namespace that encompasses file systems located on a multi-server namespace that encompasses file systems located on a
wider range of servers. Some likely uses of this facility include wider range of servers. Some likely uses of this facility include
establishment of site-wide or organization-wide namespaces, with the establishment of site-wide or organization-wide namespaces, with the
eventual possibility of combining such together into a truly global eventual possibility of combining such together into a truly global
namespace, such as the one provided by AFS (the Andrew File System) namespace, such as the one provided by AFS (the Andrew File System)
[64]. [65].
Referrals occur when a client determines, upon first referencing a Referrals occur when a client determines, upon first referencing a
position in the current namespace, that it is part of a new file position in the current namespace, that it is part of a new file
system and that the file system is absent. When this occurs, system and that the file system is absent. When this occurs,
typically upon receiving the error NFS4ERR_MOVED, the actual location typically upon receiving the error NFS4ERR_MOVED, the actual location
or locations of the file system can be determined by fetching a or locations of the file system can be determined by fetching a
locations attribute. locations attribute.
The file system location attribute may designate a single file system The file system location attribute may designate a single file system
location or multiple file system locations, to be selected based on location or multiple file system locations, to be selected based on
skipping to change at page 244, line 29 skipping to change at line 11704
to different locations as reported to individual clients, in order to to different locations as reported to individual clients, in order to
adapt to client physical location or to effect load balancing. When adapt to client physical location or to effect load balancing. When
both read-only and read-write file systems are present, some of the both read-only and read-write file systems are present, some of the
read-only locations might not be absolutely up-to-date (as they would read-only locations might not be absolutely up-to-date (as they would
have to be in the case of replication and migration). Servers may have to be in the case of replication and migration). Servers may
also specify file system locations that include client-substituted also specify file system locations that include client-substituted
variables so that different clients are referred to different file variables so that different clients are referred to different file
systems (with different data contents) based on client attributes systems (with different data contents) based on client attributes
such as CPU architecture. such as CPU architecture.
When the fs_locations_info attribute is such that that there are If the fs_locations_info attribute lists multiple possible targets,
multiple possible targets listed, the relationships among them may be the relationships among them may be important to the client in
important to the client in selecting which one to use. The same selecting which one to use. The same rules specified in
rules specified in Section 11.5.5 below regarding multiple migration Section 11.5.5 below regarding multiple migration targets apply to
targets apply to these multiple replicas as well. For example, the these multiple replicas as well. For example, the client might
client might prefer a writable target on a server that has additional prefer a writable target on a server that has additional writable
writable replicas to which it subsequently might switch. Note that, replicas to which it subsequently might switch. Note that, as
as distinguished from the case of replication, there is no need to distinguished from the case of replication, there is no need to deal
deal with the case of propagation of updates made by the current with the case of propagation of updates made by the current client,
client, since the current client has not accessed the file system in since the current client has not accessed the file system in
question. question.
Use of multi-server namespaces is enabled by NFSv4.1 but is not Use of multi-server namespaces is enabled by NFSv4.1 but is not
required. The use of multi-server namespaces and their scope will required. The use of multi-server namespaces and their scope will
depend on the applications used and system administration depend on the applications used and system administration
preferences. preferences.
Multi-server namespaces can be established by a single server Multi-server namespaces can be established by a single server
providing a large set of pure referrals to all of the included file providing a large set of pure referrals to all of the included file
systems. Alternatively, a single multi-server namespace may be systems. Alternatively, a single multi-server namespace may be
skipping to change at page 245, line 16 skipping to change at line 11738
Generally, multi-server namespaces are for the most part uniform, in Generally, multi-server namespaces are for the most part uniform, in
that the same data made available to one client at a given location that the same data made available to one client at a given location
in the namespace is made available to all clients at that namespace in the namespace is made available to all clients at that namespace
location. However, there are facilities provided that allow location. However, there are facilities provided that allow
different clients to be directed to different sets of data, for different clients to be directed to different sets of data, for
reasons such as enabling adaptation to such client characteristics as reasons such as enabling adaptation to such client characteristics as
CPU architecture. These facilities are described in Section 11.17.3. CPU architecture. These facilities are described in Section 11.17.3.
Note that it is possible, when providing a uniform namespace, to Note that it is possible, when providing a uniform namespace, to
provide different location entries to different clients, in order to provide different location entries to different clients in order to
provide each client with a copy of the data physically closest to it, provide each client with a copy of the data physically closest to it
or otherwise optimize access (e.g. provide load balancing). or otherwise optimize access (e.g., provide load balancing).
11.5.7. Changes in a File System Location Attribute 11.5.7. Changes in a File System Location Attribute
Although clients will typically fetch a file system location Although clients will typically fetch a file system location
attribute when first accessing a file system and when NFS4ERR_MOVED attribute when first accessing a file system and when NFS4ERR_MOVED
is returned, a client can choose to fetch the attribute periodically, is returned, a client can choose to fetch the attribute periodically,
in which case the value fetched may change over time. in which case, the value fetched may change over time.
For clients not prepared to access multiple replicas simultaneously For clients not prepared to access multiple replicas simultaneously
(see Section 11.11.1), the handling of the various cases of location (see Section 11.11.1), the handling of the various cases of location
change are as follows: change are as follows:
o Changes in the list of replicas or in the network addresses * Changes in the list of replicas or in the network addresses
associated with replicas do not require immediate action. The associated with replicas do not require immediate action. The
client will typically update its list of replicas to reflect the client will typically update its list of replicas to reflect the
new information. new information.
o Additions to the list of network addresses for the current file * Additions to the list of network addresses for the current file
system instance need not be acted on promptly. However, to system instance need not be acted on promptly. However, to
prepare for the case in which a migration event occurs prepare for a subsequent migration event, the client can choose to
subsequently, the client can choose to take note of the new take note of the new address and then use it whenever it needs to
address and then use it whenever it needs to switch access to a switch access to a new replica.
new replica.
o Deletions from the list of network addresses for the current file * Deletions from the list of network addresses for the current file
system instance do not need to be acted on immediately by ceasing system instance do not require the client to immediately cease use
use of existing access paths although new connections are not to of existing access paths, although new connections are not to be
be established on addresses that have been deleted. However, established on addresses that have been deleted. However, clients
clients can choose to act on such deletions by making preparations can choose to act on such deletions by preparing for an eventual
for an eventual shift in access which would become unavoidable as shift in access, which becomes unavoidable as soon as the server
soon as the server indicates that a particular network access path returns NFS4ERR_MOVED to indicate that a particular network access
is not usable to access the current file system, by returning path is not usable to access the current file system.
NFS4ERR_MOVED.
For clients that are prepared to access several replicas For clients that are prepared to access several replicas
simultaneously, the following additional cases need to be addressed. simultaneously, the following additional cases need to be addressed.
As in the cases discussed above, changes in the set of replicas need As in the cases discussed above, changes in the set of replicas need
not be acted upon promptly, although the client has the option of not be acted upon promptly, although the client has the option of
adjusting its access even in the absence of difficulties that would adjusting its access even in the absence of difficulties that would
lead to a new replica to be selected. lead to the selection of a new replica.
o When a new replica is added which may be accessed simultaneously * When a new replica is added, which may be accessed simultaneously
with one currently in use, the client is free to use the new with one currently in use, the client is free to use the new
replica immediately. replica immediately.
o When a replica currently in use is deleted from the list, the * When a replica currently in use is deleted from the list, the
client need not cease using it immediately. However, since the client need not cease using it immediately. However, since the
server may subsequently force such use to cease (by returning server may subsequently force such use to cease (by returning
NFS4ERR_MOVED), clients might decide to limit the need for later NFS4ERR_MOVED), clients might decide to limit the need for later
state transfer. For example, new opens might be done on other state transfer. For example, new opens might be done on other
replicas, rather than on one not present in the list. replicas, rather than on one not present in the list.
11.6. Trunking without File System Location Information 11.6. Trunking without File System Location Information
In situations in which a file system is accessed using two server- In situations in which a file system is accessed using two server-
trunkable addresses (as indicated by the same value of the trunkable addresses (as indicated by the same value of the
so_major_id field of the eir_server_owner field returned in response so_major_id field of the eir_server_owner field returned in response
to EXCHANGE_ID), trunked access is allowed even though there might to EXCHANGE_ID), trunked access is allowed even though there might
not be any location entries specifically indicating the use of not be any location entries specifically indicating the use of
trunking for that file system. trunking for that file system.
This situation was recognized by [65], even though that document made This situation was recognized by [66], although that document made no
no explicit mention of trunking and treated the situation as one of explicit mention of trunking and treated the situation as one of
simultaneous use of two distinct file system instances, even though, simultaneous use of two distinct file system instances. In the
in the explanatory framework now used to describe the situation, the explanatory framework now used to describe the situation, the case is
case is one in which a single file system is accessed by two one in which a single file system is accessed by two different
different trunked addresses. trunked addresses.
11.7. Users and Groups in a Multi-server Namespace 11.7. Users and Groups in a Multi-Server Namespace
As in the case of a single-server environment (see Section 5.9, when As in the case of a single-server environment (see Section 5.9), when
an owner or group name of the form "id@domain" is assigned to a file, an owner or group name of the form "id@domain" is assigned to a file,
there is an implicit promise to return that same string when the there is an implicit promise to return that same string when the
corresponding attribute is interrogated subsequently. In the case of corresponding attribute is interrogated subsequently. In the case of
a multi-server namespace, that same promise applies even if server a multi-server namespace, that same promise applies even if server
boundaries have been crossed. Similarly, when the owner attribute of boundaries have been crossed. Similarly, when the owner attribute of
a file is derived from the security principal which created the file, a file is derived from the security principal that created the file,
that attribute should have the same value even if the interrogation that attribute should have the same value even if the interrogation
occurs on a different server from the file creation. occurs on a different server from the file creation.
Similarly, the set of security principals recognized by all the Similarly, the set of security principals recognized by all the
participating servers needs to be the same, with each such principal participating servers needs to be the same, with each such principal
having the same credentials, regardless of the particular server having the same credentials, regardless of the particular server
being accessed. being accessed.
In order to meet these requirements, those setting up multi-server In order to meet these requirements, those setting up multi-server
namespaces will need to limit the servers included so that: namespaces will need to limit the servers included so that:
o In all cases in which more than a single domain is supported, the * In all cases in which more than a single domain is supported, the
requirements stated in RFC8000 [31] are to be respected. requirements stated in RFC 8000 [31] are to be respected.
o All servers support a common set of domains which includes all of * All servers support a common set of domains that includes all of
the domains clients use and expect to see returned as the domain the domains clients use and expect to see returned as the domain
portion of an owner or group in the form "id@domain". Note that portion of an owner or group in the form "id@domain". Note that,
although this set most often consists of a single domain, it is although this set most often consists of a single domain, it is
possible for multiple domains to be supported. possible for multiple domains to be supported.
o All servers, for each domain that they support, accept the same * All servers, for each domain that they support, accept the same
set of user and group ids as valid. set of user and group ids as valid.
o All servers recognize the same set of security principals. For * All servers recognize the same set of security principals. For
each principal, the same credential is required, independent of each principal, the same credential is required, independent of
the server being accessed. In addition, the group membership for the server being accessed. In addition, the group membership for
each such principal is to be the same, independent of the server each such principal is to be the same, independent of the server
accessed. accessed.
Note that there is no requirement in general that the users Note that there is no requirement in general that the users
corresponding to particular security principals have the same local corresponding to particular security principals have the same local
representation on each server, even though it is most often the case representation on each server, even though it is most often the case
that this is so. that this is so.
When AUTH_SYS is used, the following additional requirements must be When AUTH_SYS is used, the following additional requirements must be
met: met:
o Only a single NFSv4 domain can be supported through use of * Only a single NFSv4 domain can be supported through the use of
AUTH_SYS. AUTH_SYS.
o The "local" representation of all owners and groups must be the * The "local" representation of all owners and groups must be the
same on all servers. The word "local" is used here since that is same on all servers. The word "local" is used here since that is
the way that numeric user and group ids are described in the way that numeric user and group ids are described in
Section 5.9. However, when AUTH_SYS or stringified numeric owners Section 5.9. However, when AUTH_SYS or stringified numeric owners
or groups are used, these identifiers are not truly local, since or groups are used, these identifiers are not truly local, since
they are known to the clients as well as the server. they are known to the clients as well as to the server.
Similarly, when stringified numeric user and group ids are used, the Similarly, when stringified numeric user and group ids are used, the
"local" representation of all owners and groups must be the same on "local" representation of all owners and groups must be the same on
all servers, even when AUTH_SYS is not used. all servers, even when AUTH_SYS is not used.
11.8. Additional Client-Side Considerations 11.8. Additional Client-Side Considerations
When clients make use of servers that implement referrals, When clients make use of servers that implement referrals,
replication, and migration, care should be taken that a user who replication, and migration, care should be taken that a user who
mounts a given file system that includes a referral or a relocated mounts a given file system that includes a referral or a relocated
skipping to change at page 248, line 45 skipping to change at line 11907
periodically purge this data for referral points in order to detect periodically purge this data for referral points in order to detect
changes in location information. When the change_policy attribute changes in location information. When the change_policy attribute
changes for directories that hold referral entries or for the changes for directories that hold referral entries or for the
referral entries themselves, clients should consider any associated referral entries themselves, clients should consider any associated
cached referral information to be out of date. cached referral information to be out of date.
11.9. Overview of File Access Transitions 11.9. Overview of File Access Transitions
File access transitions are of two types: File access transitions are of two types:
o Those that involve a transition from accessing the current replica * Those that involve a transition from accessing the current replica
to another one in connection with either replication or migration. to another one in connection with either replication or migration.
How these are dealt with is discussed in Section 11.11. How these are dealt with is discussed in Section 11.11.
o Those in which access to the current file system instance is * Those in which access to the current file system instance is
retained, while the network path used to access that instance is retained, while the network path used to access that instance is
changed. This case is discussed in Section 11.10. changed. This case is discussed in Section 11.10.
11.10. Effecting Network Endpoint Transitions 11.10. Effecting Network Endpoint Transitions
The endpoints used to access a particular file system instance may The endpoints used to access a particular file system instance may
change in a number of ways, as listed below. In each of these cases, change in a number of ways, as listed below. In each of these cases,
the same fsid, filehandles, stateids, client IDs and are used to the same fsid, client IDs, filehandles, and stateids are used to
continue access, with a continuity of lock state. In many cases, the continue access, with a continuity of lock state. In many cases, the
same sessions can also be used. same sessions can also be used.
The appropriate action depends on the set of replacement addresses The appropriate action depends on the set of replacement addresses
(i.e. server endpoints which are server-trunkable with one previously that are available for use (i.e., server endpoints that are server-
being used) which are available for use. trunkable with one previously being used).
o When use of a particular address is to cease and there is also * When use of a particular address is to cease, and there is also
another one currently in use which is server-trunkable with it, another address currently in use that is server-trunkable with it,
requests that would have been issued on the address whose use is requests that would have been issued on the address whose use is
to be discontinued can be issued on the remaining address(es). to be discontinued can be issued on the remaining address(es).
When an address is server-trunkable but not session-trunkable with When an address is server-trunkable but not session-trunkable with
the address whose use is to be discontinued, the request might the address whose use is to be discontinued, the request might
need to be modified to reflect the fact that a different session need to be modified to reflect the fact that a different session
will be used. will be used.
o When use of a particular connection is to cease, as indicated by * When use of a particular connection is to cease, as indicated by
receiving NFS4ERR_MOVED when using that connection but that receiving NFS4ERR_MOVED when using that connection, but that
address is still indicated as accessible according to the address is still indicated as accessible according to the
appropriate file system location entries, it is likely that appropriate file system location entries, it is likely that
requests can be issued on a new connection of a different requests can be issued on a new connection of a different
connection type, once that connection is established. Since any connection type once that connection is established. Since any
two, non-port-specific server endpoints that share a network two non-port-specific server endpoints that share a network
address are inherently session-trunkable, the client can use address are inherently session-trunkable, the client can use
BIND_CONN_TO_SESSION to access the existing session using the new BIND_CONN_TO_SESSION to access the existing session with the new
connection and proceed to access the file system using the new
connection. connection.
o When there are no potential replacement addresses in use but there * When there are no potential replacement addresses in use, but
are valid addresses session-trunkable with the one whose use is to there are valid addresses session-trunkable with the one whose use
be discontinued, the client can use BIND_CONN_TO_SESSION to access is to be discontinued, the client can use BIND_CONN_TO_SESSION to
the existing session using the new address. Although the target access the existing session using the new address. Although the
session will generally be accessible, there may be rare situations target session will generally be accessible, there may be rare
in which that session is no longer accessible, when an attempt is situations in which that session is no longer accessible when an
made to bind the new connection to it. In this case, the client attempt is made to bind the new connection to it. In this case,
can create a new session to enable continued access to the the client can create a new session to enable continued access to
existing instance using the new connection, providing for use of the existing instance using the new connection, providing for the
existing filehandles, stateids, and client ids while providing use of existing filehandles, stateids, and client ids while
continuity of locking state. supplying continuity of locking state.
o When there is no potential replacement address in use and there * When there is no potential replacement address in use, and there
are no valid addresses session-trunkable with the one whose use is are no valid addresses session-trunkable with the one whose use is
to be discontinued, other server-trunkable addresses may be used to be discontinued, other server-trunkable addresses may be used
to provide continued access. Although use of CREATE_SESSION is to provide continued access. Although the use of CREATE_SESSION
available to provide continued access to the existing instance, is available to provide continued access to the existing instance,
servers have the option of providing continued access to the servers have the option of providing continued access to the
existing session through the new network access path in a fashion existing session through the new network access path in a fashion
similar to that provided by session migration (see Section 11.12). similar to that provided by session migration (see Section 11.12).
To take advantage of this possibility, clients can perform an To take advantage of this possibility, clients can perform an
initial BIND_CONN_TO_SESSION, as in the previous case, and use initial BIND_CONN_TO_SESSION, as in the previous case, and use
CREATE_SESSION only if that fails. CREATE_SESSION only if that fails.
11.11. Effecting File System Transitions 11.11. Effecting File System Transitions
There are a range of situations in which there is a change to be There are a range of situations in which there is a change to be
skipping to change at page 250, line 30 skipping to change at line 11988
For reasons explained in that section, most transitions will involve For reasons explained in that section, most transitions will involve
a transition from a single replica to a corresponding replacement a transition from a single replica to a corresponding replacement
replica. When effecting replica transition, some types of sharing replica. When effecting replica transition, some types of sharing
between the replicas may affect handling of the transition as between the replicas may affect handling of the transition as
described in Sections 11.11.2 through 11.11.8 below. The attribute described in Sections 11.11.2 through 11.11.8 below. The attribute
fs_locations_info provides helpful information to allow the client to fs_locations_info provides helpful information to allow the client to
determine the degree of inter-replica sharing. determine the degree of inter-replica sharing.
With regard to some types of state, the degree of continuity across With regard to some types of state, the degree of continuity across
the transition depends on the occasion prompting the transition, with the transition depends on the occasion prompting the transition, with
transitions initiated by the servers (i.e. migration) offering much transitions initiated by the servers (i.e., migration) offering much
more scope for a non-disruptive transition than cases in which the more scope for a nondisruptive transition than cases in which the
client on its own shifts its access to another replica (i.e. client on its own shifts its access to another replica (i.e.,
replication). This issue potentially applies to locking state and to replication). This issue potentially applies to locking state and to
session state, which are dealt with below as follows: session state, which are dealt with below as follows:
o An introduction to the possible means of providing continuity in * An introduction to the possible means of providing continuity in
these areas appears in Section 11.11.9 below. these areas appears in Section 11.11.9 below.
o Transparent State Migration is introduced in Section 11.12. The * Transparent State Migration is introduced in Section 11.12. The
possible transfer of session state is addressed there as well. possible transfer of session state is addressed there as well.
o The client handling of transitions, including determining how to * The client handling of transitions, including determining how to
deal with the various means that the server might take to supply deal with the various means that the server might take to supply
effective continuity of locking state is discussed in effective continuity of locking state, is discussed in
Section 11.13. Section 11.13.
o The servers' (source and destination) responsibilities in * The source and destination servers' responsibilities in effecting
effecting Transparent Migration of locking and session state are Transparent State Migration of locking and session state are
discussed in Section 11.14. discussed in Section 11.14.
11.11.1. File System Transitions and Simultaneous Access 11.11.1. File System Transitions and Simultaneous Access
The fs_locations_info attribute (described in Section 11.17) may The fs_locations_info attribute (described in Section 11.17) may
indicate that two replicas may be used simultaneously, although some indicate that two replicas may be used simultaneously, although some
situations in which such simultaneous access is permitted are more situations in which such simultaneous access is permitted are more
appropriately described as instances of trunking (see appropriately described as instances of trunking (see
Section 11.5.4.1). Although situations in which multiple replicas Section 11.5.4.1). Although situations in which multiple replicas
may be accessed simultaneously are somewhat similar to those in which may be accessed simultaneously are somewhat similar to those in which
a single replica is accessed by multiple network addresses, there are a single replica is accessed by multiple network addresses, there are
important differences, since locking state is not shared among important differences since locking state is not shared among
multiple replicas. multiple replicas.
Because of this difference in state handling, many clients will not Because of this difference in state handling, many clients will not
have the ability to take advantage of the fact that such replicas have the ability to take advantage of the fact that such replicas
represent the same data. Such clients will not be prepared to use represent the same data. Such clients will not be prepared to use
multiple replicas simultaneously but will access each file system multiple replicas simultaneously but will access each file system
using only a single replica, although the replica selected might make using only a single replica, although the replica selected might make
multiple server-trunkable addresses available. multiple server-trunkable addresses available.
Clients who are prepared to use multiple replicas simultaneously will Clients who are prepared to use multiple replicas simultaneously can
divide opens among replicas however they choose. Once that choice is divide opens among replicas however they choose. Once that choice is
made, any subsequent transitions will treat the set of locking state made, any subsequent transitions will treat the set of locking state
associated with each replica as a single entity. associated with each replica as a single entity.
For example, if one of the replicas become unavailable, access will For example, if one of the replicas become unavailable, access will
be transferred to a different replica, also capable of simultaneous be transferred to a different replica, which is also capable of
access with the one still in use. simultaneous access with the one still in use.
When there is no such replica, the transition may be to the replica When there is no such replica, the transition may be to the replica
already in use. At this point, the client has a choice between already in use. At this point, the client has a choice between
merging the locking state for the two replicas under the aegis of the merging the locking state for the two replicas under the aegis of the
sole replica in use or treating these separately, until another sole replica in use or treating these separately until another
replica capable of simultaneous access presents itself. replica capable of simultaneous access presents itself.
11.11.2. Filehandles and File System Transitions 11.11.2. Filehandles and File System Transitions
There are a number of ways in which filehandles can be handled across There are a number of ways in which filehandles can be handled across
a file system transition. These can be divided into two broad a file system transition. These can be divided into two broad
classes depending upon whether the two file systems across which the classes depending upon whether the two file systems across which the
transition happens share sufficient state to effect some sort of transition happens share sufficient state to effect some sort of
continuity of file system handling. continuity of file system handling.
skipping to change at page 254, line 34 skipping to change at line 12180
When the two file systems have consistent change attribute formats, When the two file systems have consistent change attribute formats,
and this fact is communicated to the client by reporting in the same and this fact is communicated to the client by reporting in the same
change class, the client may assume a continuity of change attribute change class, the client may assume a continuity of change attribute
construction and handle this situation just as it would be handled construction and handle this situation just as it would be handled
without any file system transition. without any file system transition.
11.11.6. Write Verifiers and File System Transitions 11.11.6. Write Verifiers and File System Transitions
In a file system transition, the two file systems might be In a file system transition, the two file systems might be
cooperating in the handling of unstably written data. Clients can cooperating in the handling of unstably written data. Clients can
determine if this is the case, by seeing if the two file systems determine if this is the case by seeing if the two file systems
belong to the same write-verifier class. When this is the case, belong to the same write-verifier class. When this is the case,
write verifiers returned from one system may be compared to those write verifiers returned from one system may be compared to those
returned by the other and superfluous writes avoided. returned by the other and superfluous writes can be avoided.
When two file systems belong to different write-verifier classes, any When two file systems belong to different write-verifier classes, any
verifier generated by one must not be compared to one provided by the verifier generated by one must not be compared to one provided by the
other. Instead, the two verifiers should be treated as not equal other. Instead, the two verifiers should be treated as not equal
even when the values are identical. even when the values are identical.
11.11.7. Readdir Cookies and Verifiers and File System Transitions 11.11.7. READDIR Cookies and Verifiers and File System Transitions
In a file system transition, the two file systems might be consistent In a file system transition, the two file systems might be consistent
in their handling of READDIR cookies and verifiers. Clients can in their handling of READDIR cookies and verifiers. Clients can
determine if this is the case, by seeing if the two file systems determine if this is the case by seeing if the two file systems
belong to the same readdir class. When this is the case, readdir belong to the same readdir class. When this is the case, readdir
class, READDIR cookies and verifiers from one system will be class, READDIR cookies, and verifiers from one system will be
recognized by the other and READDIR operations started on one server recognized by the other, and READDIR operations started on one server
can be validly continued on the other, simply by presenting the can be validly continued on the other simply by presenting the cookie
cookie and verifier returned by a READDIR operation done on the first and verifier returned by a READDIR operation done on the first file
file system to the second. system to the second.
When two file systems belong to different readdir classes, any When two file systems belong to different readdir classes, any
READDIR cookie and verifier generated by one is not valid on the READDIR cookie and verifier generated by one is not valid on the
second, and must not be presented to that server by the client. The second and must not be presented to that server by the client. The
client should act as if the verifier were rejected. client should act as if the verifier were rejected.
11.11.8. File System Data and File System Transitions 11.11.8. File System Data and File System Transitions
When multiple replicas exist and are used simultaneously or in When multiple replicas exist and are used simultaneously or in
succession by a client, applications using them will normally expect succession by a client, applications using them will normally expect
that they contain either the same data or data that is consistent that they contain either the same data or data that is consistent
with the normal sorts of changes that are made by other clients with the normal sorts of changes that are made by other clients
updating the data of the file system (with metadata being the same to updating the data of the file system (with metadata being the same to
the degree indicated by the fs_locations_info attribute). However, the degree indicated by the fs_locations_info attribute). However,
when multiple file systems are presented as replicas of one another, when multiple file systems are presented as replicas of one another,
the precise relationship between the data of one and the data of the precise relationship between the data of one and the data of
another is not, as a general matter, specified by the NFSv4.1 another is not, as a general matter, specified by the NFSv4.1
protocol. It is quite possible to present as replicas file systems protocol. It is quite possible to present as replicas file systems
where the data of those file systems is sufficiently different that where the data of those file systems is sufficiently different that
some applications have problems dealing with the transition between some applications have problems dealing with the transition between
replicas. The namespace will typically be constructed so that replicas. The namespace will typically be constructed so that
applications can choose an appropriate level of support, so that in applications can choose an appropriate level of support, so that in
one position in the namespace a varied set of replicas might be one position in the namespace, a varied set of replicas might be
listed, while in another only those that are up-to-date would be listed, while in another, only those that are up-to-date would be
considered replicas. The protocol does define three special cases of considered replicas. The protocol does define three special cases of
the relationship among replicas to be specified by the server and the relationship among replicas to be specified by the server and
relied upon by clients: relied upon by clients:
o When multiple replicas exist and are used simultaneously by a * When multiple replicas exist and are used simultaneously by a
client (see the FSLIB4_CLSIMUL definition within client (see the FSLIB4_CLSIMUL definition within
fs_locations_info), they must designate the same data. Where file fs_locations_info), they must designate the same data. Where file
systems are writable, a change made on one instance must be systems are writable, a change made on one instance must be
visible on all instances at the same time, regardless of whether visible on all instances at the same time, regardless of whether
the interrogated instance is the one on which the modification was the interrogated instance is the one on which the modification was
done. This allows a client to use these replicas simultaneously done. This allows a client to use these replicas simultaneously
without any special adaptation to the fact that there are multiple without any special adaptation to the fact that there are multiple
replicas, beyond adapting to the fact that locks obtained on one replicas, beyond adapting to the fact that locks obtained on one
replica are maintained separately (i.e. under a different client replica are maintained separately (i.e., under a different client
ID). In this case, locks (whether share reservations or byte- ID). In this case, locks (whether share reservations or byte-
range locks) and delegations obtained on one replica are range locks) and delegations obtained on one replica are
immediately reflected on all replicas, in the sense that access immediately reflected on all replicas, in the sense that access
from all other servers is prevented regardless of the replica from all other servers is prevented regardless of the replica
used. However, because the servers are not required to treat two used. However, because the servers are not required to treat two
associated client IDs as representing the same client, it is best associated client IDs as representing the same client, it is best
to access each file using only a single client ID. to access each file using only a single client ID.
o When one replica is designated as the successor instance to * When one replica is designated as the successor instance to
another existing instance after return NFS4ERR_MOVED (i.e., the another existing instance after the return of NFS4ERR_MOVED (i.e.,
case of migration), the client may depend on the fact that all the case of migration), the client may depend on the fact that all
changes written to stable storage on the original instance are changes written to stable storage on the original instance are
written to stable storage of the successor (uncommitted writes are written to stable storage of the successor (uncommitted writes are
dealt with in Section 11.11.6 above). dealt with in Section 11.11.6 above).
o Where a file system is not writable but represents a read-only * Where a file system is not writable but represents a read-only
copy (possibly periodically updated) of a writable file system, copy (possibly periodically updated) of a writable file system,
clients have similar requirements with regard to the propagation clients have similar requirements with regard to the propagation
of updates. They may need a guarantee that any change visible on of updates. They may need a guarantee that any change visible on
the original file system instance must be immediately visible on the original file system instance must be immediately visible on
any replica before the client transitions access to that replica, any replica before the client transitions access to that replica,
in order to avoid any possibility that a client, in effecting a in order to avoid any possibility that a client, in effecting a
transition to a replica, will see any reversion in file system transition to a replica, will see any reversion in file system
state. The specific means of this guarantee varies based on the state. The specific means of this guarantee varies based on the
value of the fss_type field that is reported as part of the value of the fss_type field that is reported as part of the
fs_status attribute (see Section 11.18). Since these file systems fs_status attribute (see Section 11.18). Since these file systems
are presumed to be unsuitable for simultaneous use, there is no are presumed to be unsuitable for simultaneous use, there is no
specification of how locking is handled; in general, locks specification of how locking is handled; in general, locks
obtained on one file system will be separate from those on others. obtained on one file system will be separate from those on others.
Since these are expected to be read-only file systems, this is not Since these are expected to be read-only file systems, this is not
likely to pose an issue for clients or applications. likely to pose an issue for clients or applications.
When none of these special situations apply, there is no basis, When none of these special situations applies, there is no basis
within the protocol for the client to make assumptions about the within the protocol for the client to make assumptions about the
contents of a replica file system or its relationship to previous contents of a replica file system or its relationship to previous
file system instances. Thus switching between nominally identical file system instances. Thus, switching between nominally identical
read-write file systems would not be possible, because either the read-write file systems would not be possible because either the
client does not use or the server does not support the client does not use the fs_locations_info attribute, or the server
fs_locations_info attribute. does not support it.
11.11.9. Lock State and File System Transitions 11.11.9. Lock State and File System Transitions
While accessing a file system, clients obtain locks enforced by the While accessing a file system, clients obtain locks enforced by the
server which may prevent actions by other clients that are server, which may prevent actions by other clients that are
inconsistent with those locks. inconsistent with those locks.
When access is transferred between replicas, clients need to be When access is transferred between replicas, clients need to be
assured that the actions disallowed by holding these locks cannot assured that the actions disallowed by holding these locks cannot
have occurred during the transition. This can be ensured by the have occurred during the transition. This can be ensured by the
methods below. Unless at least one of these is implemented, clients methods below. Unless at least one of these is implemented, clients
will not be assured of continuity of lock possession across a will not be assured of continuity of lock possession across a
migration event. migration event:
o Providing the client an opportunity to re-obtain his locks via a * Providing the client an opportunity to re-obtain his locks via a
per-fs grace period on the destination server, denying all clients per-fs grace period on the destination server, denying all clients
using the destination file system the opportunity to obtain new using the destination file system the opportunity to obtain new
locks that conflict which those held by the transferred client as locks that conflict with those held by the transferred client as
long as that client has not completed its per-fs grace period. long as that client has not completed its per-fs grace period.
Because the lock reclaim mechanism was originally defined to Because the lock reclaim mechanism was originally defined to
support server reboot, it implicitly assumes that file handles support server reboot, it implicitly assumes that filehandles
will, upon reclaim, will be the same as those at open. In the will, upon reclaim, be the same as those at open. In the case of
case of migration, this requires that source and destination migration, this requires that source and destination servers use
servers use the same filehandles, as evidenced by using the same the same filehandles, as evidenced by using the same server scope
server scope (see Section 2.10.4) or by showing this agreement (see Section 2.10.4) or by showing this agreement using
using fs_locations_info (see Section 11.11.2 above). fs_locations_info (see Section 11.11.2 above).
Note that such a grace period can be implemented without Note that such a grace period can be implemented without
interfering with the ability of non-transferred clients to obtain interfering with the ability of non-transferred clients to obtain
new locks while it is going on. As long as the destination server new locks while it is going on. As long as the destination server
is aware of the transferred locks, it can distinguish requests to is aware of the transferred locks, it can distinguish requests to
obtain new locks that contrast with existing locks from those that obtain new locks that contrast with existing locks from those that
do not, allowing it to treat such client requests without do not, allowing it to treat such client requests without
reference to the ongoing grace period. reference to the ongoing grace period.
o Locking state can be transferred as part of the transition by * Locking state can be transferred as part of the transition by
providing Transparent State Migration as described in providing Transparent State Migration as described in
Section 11.12. Section 11.12.
Of these, Transparent State Migration provides the smoother Of these, Transparent State Migration provides the smoother
experience for clients in that there is no need to go through a experience for clients in that there is no need to go through a
reclaim process before new locks can be obtained. However, it reclaim process before new locks can be obtained; however, it
requires a greater degree of inter-server co-ordination. In general, requires a greater degree of inter-server coordination. In general,
the servers taking part in migration are free to provide either the servers taking part in migration are free to provide either
facility. However, when the filehandles can differ across the facility. However, when the filehandles can differ across the
migration event, Transparent State Migration is the only available migration event, Transparent State Migration is the only available
means of providing the needed functionality. means of providing the needed functionality.
It should be noted that these two methods are not mutually exclusive It should be noted that these two methods are not mutually exclusive
and that a server might well provide both. In particular, if there and that a server might well provide both. In particular, if there
is some circumstance preventing a specific lock from being is some circumstance preventing a specific lock from being
transferred transparently, the destination server can allow it to be transferred transparently, the destination server can allow it to be
reclaimed, by implementing a per-fs grace period for the migrated reclaimed by implementing a per-fs grace period for the migrated file
file system. system.
11.11.9.1. Security Consideration Related to Reclaiming Lock State 11.11.9.1. Security Consideration Related to Reclaiming Lock State
after File System Transitions after File System Transitions
Although it is possible for a client reclaiming state to misrepresent Although it is possible for a client reclaiming state to misrepresent
its state, in the same fashion as described in Section 8.4.2.1.1, its state in the same fashion as described in Section 8.4.2.1.1, most
most implementations providing for such reclamation in the case of implementations providing for such reclamation in the case of file
file system transitions will have the ability to detect such system transitions will have the ability to detect such
misrepresentations. This limits the ability of unauthenticated misrepresentations. This limits the ability of unauthenticated
clients to execute denial-of-service attacks in these circumstances. clients to execute denial-of-service attacks in these circumstances.
Nevertheless, the rules stated in Section 8.4.2.1.1, regarding Nevertheless, the rules stated in Section 8.4.2.1.1 regarding
principal verification for reclaim requests, apply in this situation principal verification for reclaim requests apply in this situation
as well. as well.
Typically, implementations that support file system transitions will Typically, implementations that support file system transitions will
have extensive information about the locks to be transferred. This have extensive information about the locks to be transferred. This
is because: is because of the following:
o Since failure is not involved, there is no need store to locking * Since failure is not involved, there is no need to store locking
information in persistent storage. information in persistent storage.
o There is no need, as there is in the failure case, to update * There is no need, as there is in the failure case, to update
multiple repositories containing locking state to keep them in multiple repositories containing locking state to keep them in
sync. Instead, there is a one-time communication of locking state sync. Instead, there is a one-time communication of locking state
from the source to the destination server. from the source to the destination server.
o Providing this information avoids potential interference with * Providing this information avoids potential interference with
existing clients using the destination file system, by denying existing clients using the destination file system by denying them
them the ability to obtain new locks during the grace period. the ability to obtain new locks during the grace period.
When such detailed locking information, not necessarily including the When such detailed locking information, not necessarily including the
associated stateids, is available: associated stateids, is available:
o It is possible to detect reclaim requests that attempt to reclaim * It is possible to detect reclaim requests that attempt to reclaim
locks that did not exist before the transfer, rejecting them with locks that did not exist before the transfer, rejecting them with
NFS4ERR_RECLAIM_BAD (Section 15.1.9.4). NFS4ERR_RECLAIM_BAD (Section 15.1.9.4).
o It is possible when dealing with non-reclaim requests, to * It is possible when dealing with non-reclaim requests, to
determine whether they conflict with existing locks, eliminating determine whether they conflict with existing locks, eliminating
the need to return NFS4ERR_GRACE ((Section 15.1.9.2) on non- the need to return NFS4ERR_GRACE (Section 15.1.9.2) on non-reclaim
reclaim requests. requests.
It is possible for implementations of grace periods in connection It is possible for implementations of grace periods in connection
with file system transitions not to have detailed locking information with file system transitions not to have detailed locking information
available at the destination server, in which case the security available at the destination server, in which case, the security
situation is exactly as described in Section 8.4.2.1.1. situation is exactly as described in Section 8.4.2.1.1.
11.11.9.2. Leases and File System Transitions 11.11.9.2. Leases and File System Transitions
In the case of lease renewal, the client may not be submitting In the case of lease renewal, the client may not be submitting
requests for a file system that has been transferred to another requests for a file system that has been transferred to another
server. This can occur because of the lease renewal mechanism. The server. This can occur because of the lease renewal mechanism. The
client renews the lease associated with all file systems when client renews the lease associated with all file systems when
submitting a request on an associated session, regardless of the submitting a request on an associated session, regardless of the
specific file system being referenced. specific file system being referenced.
skipping to change at page 260, line 21 skipping to change at line 12456
new server, the client should fetch the value of lease_time on the new server, the client should fetch the value of lease_time on the
new (i.e., destination) server, and use it for subsequent locking new (i.e., destination) server, and use it for subsequent locking
requests. However, the server must respect a grace period of at requests. However, the server must respect a grace period of at
least as long as the lease_time on the source server, in order to least as long as the lease_time on the source server, in order to
ensure that clients have ample time to reclaim their lock before ensure that clients have ample time to reclaim their lock before
potentially conflicting non-reclaimed locks are granted. potentially conflicting non-reclaimed locks are granted.
11.12. Transferring State upon Migration 11.12. Transferring State upon Migration
When the transition is a result of a server-initiated decision to When the transition is a result of a server-initiated decision to
transition access and the source and destination servers have transition access, and the source and destination servers have
implemented appropriate co-operation, it is possible to: implemented appropriate cooperation, it is possible to do the
following:
o Transfer locking state from the source to the destination server, * Transfer locking state from the source to the destination server
in a fashion similar to that provided by Transparent State in a fashion similar to that provided by Transparent State
Migration in NFSv4.0, as described in [68]. Server Migration in NFSv4.0, as described in [69]. Server
responsibilities are described in Section 11.14.2. responsibilities are described in Section 11.14.2.
o Transfer session state from the source to the destination server. * Transfer session state from the source to the destination server.
Server responsibilities in effecting such a transfer are described Server responsibilities in effecting such a transfer are described
in Section 11.14.3. in Section 11.14.3.
The means by which the client determines which of these transfer The means by which the client determines which of these transfer
events has occurred are described in Section 11.13. events has occurred are described in Section 11.13.
11.12.1. Transparent State Migration and pNFS 11.12.1. Transparent State Migration and pNFS
When pNFS is involved, the protocol is capable of supporting: When pNFS is involved, the protocol is capable of supporting:
o Migration of the Metadata Server (MDS), leaving the Data Servers * Migration of the Metadata Server (MDS), leaving the Data Servers
(DS's) in place. (DSs) in place.
o Migration of the file system as a whole, including the MDS and * Migration of the file system as a whole, including the MDS and
associated DS's. associated DSs.
o Replacement of one DS by another. * Replacement of one DS by another.
o Migration of a pNFS file system to one in which pNFS is not used. * Migration of a pNFS file system to one in which pNFS is not used.
o Migration of a file system not using pNFS to one in which layouts * Migration of a file system not using pNFS to one in which layouts
are available. are available.
Note that migration per se is only involved in the transfer of the Note that migration, per se, is only involved in the transfer of the
MDS function. Although the servicing of a layout may be transferred MDS function. Although the servicing of a layout may be transferred
from one data server to another, this not done using the file system from one data server to another, this not done using the file system
location attributes. The MDS can effect such transfers by recalling/ location attributes. The MDS can effect such transfers by recalling
revoking existing layouts and granting new ones on a different data or revoking existing layouts and granting new ones on a different
server. data server.
Migration of the MDS function is directly supported by Transparent Migration of the MDS function is directly supported by Transparent
State Migration. Layout state will normally be transparently State Migration. Layout state will normally be transparently
transferred, just as other state is. As a result, Transparent State transferred, just as other state is. As a result, Transparent State
Migration provides a framework in which, given appropriate inter-MDS Migration provides a framework in which, given appropriate inter-MDS
data transfer, one MDS can be substituted for another. data transfer, one MDS can be substituted for another.
Migration of the file system function as a whole can be accomplished Migration of the file system function as a whole can be accomplished
by recalling all layouts as part of the initial phase of the by recalling all layouts as part of the initial phase of the
migration process. As a result, IO will be done through the MDS migration process. As a result, I/O will be done through the MDS
during the migration process, and new layouts can be granted once the during the migration process, and new layouts can be granted once the
client is interacting with the new MDS. An MDS can also effect this client is interacting with the new MDS. An MDS can also effect this
sort of transition by revoking all layouts as part of Transparent sort of transition by revoking all layouts as part of Transparent
State Migration, as long as the client is notified about the loss of State Migration, as long as the client is notified about the loss of
locking state. locking state.
In order to allow migration to a file system on which pNFS is not In order to allow migration to a file system on which pNFS is not
supported, clients need to be prepared for a situation in which supported, clients need to be prepared for a situation in which
layouts are not available or supported on the destination file system layouts are not available or supported on the destination file system
and so direct IO requests to the destination server, rather than and so direct I/O requests to the destination server, rather than
depending on layouts being available. depending on layouts being available.
Replacement of one DS by another is not addressed by migration as Replacement of one DS by another is not addressed by migration as
such but can be effected by an MDS recalling layouts for the DS to be such but can be effected by an MDS recalling layouts for the DS to be
replaced and issuing new ones to be served by the successor DS. replaced and issuing new ones to be served by the successor DS.
Migration may transfer a file system from a server which does not Migration may transfer a file system from a server that does not
support pNFS to one which does. In order to properly adapt to this support pNFS to one that does. In order to properly adapt to this
situation, clients which support pNFS, but function adequately in its situation, clients that support pNFS, but function adequately in its
absence should check for pNFS support when a file system is migrated absence, should check for pNFS support when a file system is migrated
and be prepared to use pNFS when support is available on the and be prepared to use pNFS when support is available on the
destination. destination.
11.13. Client Responsibilities when Access is Transitioned 11.13. Client Responsibilities When Access Is Transitioned
For a client to respond to an access transition, it must become aware For a client to respond to an access transition, it must become aware
of it. The ways in which this can happen are discussed in of it. The ways in which this can happen are discussed in
Section 11.13.1 which discusses indications that a specific file Section 11.13.1, which discusses indications that a specific file
system access path has transitioned as well as situations in which system access path has transitioned as well as situations in which
additional activity is necessary to determine the set of file systems additional activity is necessary to determine the set of file systems
that have been migrated. Section 11.13.2 goes on to complete the that have been migrated. Section 11.13.2 goes on to complete the
discussion of how the set of migrated file systems might be discussion of how the set of migrated file systems might be
determined. Sections 11.13.3 through 11.13.5 discuss how the client determined. Sections 11.13.3 through 11.13.5 discuss how the client
should deal with each transition it becomes aware of, either directly should deal with each transition it becomes aware of, either directly
or as a result of migration discovery. or as a result of migration discovery.
The following terms are used to describe client activities: The following terms are used to describe client activities:
o "Transition recovery" refers to the process of restoring access to * "Transition recovery" refers to the process of restoring access to
a file system on which NFS4ERR_MOVED was received. a file system on which NFS4ERR_MOVED was received.
o "Migration recovery" to that subset of transition recovery which * "Migration recovery" refers to that subset of transition recovery
applies when the file system has migrated to a different replica. that applies when the file system has migrated to a different
replica.
o "Migration discovery" refers to the process of determining which * "Migration discovery" refers to the process of determining which
file system(s) have been migrated. It is necessary to avoid a file system(s) have been migrated. It is necessary to avoid a
situation in which leases could expire when a file system is not situation in which leases could expire when a file system is not
accessed for a long period of time, since a client unaware of the accessed for a long period of time, since a client unaware of the
migration might be referencing an unmigrated file system and not migration might be referencing an unmigrated file system and not
renewing the lease associated with the migrated file system. renewing the lease associated with the migrated file system.
11.13.1. Client Transition Notifications 11.13.1. Client Transition Notifications
When there is a change in the network access path which a client is When there is a change in the network access path that a client is to
to use to access a file system, there are a number of related status use to access a file system, there are a number of related status
indications with which clients need to deal: indications with which clients need to deal:
o If an attempt is made to use or return a filehandle within a file * If an attempt is made to use or return a filehandle within a file
system that is no longer accessible at the address previously used system that is no longer accessible at the address previously used
to access it, the error NFS4ERR_MOVED is returned. to access it, the error NFS4ERR_MOVED is returned.
Exceptions are made to allow such file handles to be used when Exceptions are made to allow such filehandles to be used when
interrogating a file system location attribute. This enables a interrogating a file system location attribute. This enables a
client to determine a new replica's location or a new network client to determine a new replica's location or a new network
access path. access path.
This condition continues on subsequent attempts to access the file This condition continues on subsequent attempts to access the file
system in question. The only way the client can avoid the error system in question. The only way the client can avoid the error
is to cease accessing the file system in question at its old is to cease accessing the file system in question at its old
server location and access it instead using a different address at server location and access it instead using a different address at
which it is now available. which it is now available.
o Whenever a SEQUENCE operation is sent by a client to a server * Whenever a client sends a SEQUENCE operation to a server that
which generated state held on that client which is associated with generated state held on that client and associated with a file
a file system that is no longer accessible on the server at which system no longer accessible on that server, the response will
it was previously available, the response will contain a lease- contain the status bit SEQ4_STATUS_LEASE_MOVED, indicating that
migrated indication, with the SEQ4_STATUS_LEASE_MOVED status bit there has been a lease migration.
being set.
This condition continues until the client acknowledges the This condition continues until the client acknowledges the
notification by fetching a file system location attribute for the notification by fetching a file system location attribute for the
file system whose network access path is being changed. When file system whose network access path is being changed. When
there are multiple such file systems, a location attribute for there are multiple such file systems, a location attribute for
each such file system needs to be fetched. The location attribute each such file system needs to be fetched. The location attribute
for all migrated file system needs to be fetched in order to clear for all migrated file systems needs to be fetched in order to
the condition. Even after the condition is cleared, the client clear the condition. Even after the condition is cleared, the
needs to respond by using the location information to access the client needs to respond by using the location information to
file system at its new location to ensure that leases are not access the file system at its new location to ensure that leases
needlessly expired. are not needlessly expired.
Unlike the case of NFSv4.0, in which the corresponding conditions are Unlike NFSv4.0, in which the corresponding conditions are both errors
both errors and thus mutually exclusive, in NFSv4.1 the client can, and thus mutually exclusive, in NFSv4.1 the client can, and often
and often will, receive both indications on the same request. As a will, receive both indications on the same request. As a result,
result, implementations need to address the question of how to co- implementations need to address the question of how to coordinate the
ordinate the necessary recovery actions when both indications arrive necessary recovery actions when both indications arrive in the
in the response to the same request. It should be noted that when response to the same request. It should be noted that when
processing an NFSv4 COMPOUND, the server will normally decide whether processing an NFSv4 COMPOUND, the server will normally decide whether
SEQ4_STATUS_LEASE_MOVED is to be set before it determines which file SEQ4_STATUS_LEASE_MOVED is to be set before it determines which file
system will be referenced or whether NFS4ERR_MOVED is to be returned. system will be referenced or whether NFS4ERR_MOVED is to be returned.
Since these indications are not mutually exclusive in NFSv4.1, the Since these indications are not mutually exclusive in NFSv4.1, the
following combinations are possible results when a COMPOUND is following combinations are possible results when a COMPOUND is
issued: issued:
o The COMPOUND status is NFS4ERR_MOVED and SEQ4_STATUS_LEASE_MOVED * The COMPOUND status is NFS4ERR_MOVED, and SEQ4_STATUS_LEASE_MOVED
is asserted. is asserted.
In this case, transition recovery is required. While it is In this case, transition recovery is required. While it is
possible that migration discovery is needed in addition, it is possible that migration discovery is needed in addition, it is
likely that only the accessed file system has transitioned. In likely that only the accessed file system has transitioned. In
any case, because addressing NFS4ERR_MOVED is necessary to allow any case, because addressing NFS4ERR_MOVED is necessary to allow
the rejected requests to be processed on the target, dealing with the rejected requests to be processed on the target, dealing with
it will typically have priority over migration discovery. it will typically have priority over migration discovery.
o The COMPOUND status is NFS4ERR_MOVED and SEQ4_STATUS_LEASE_MOVED * The COMPOUND status is NFS4ERR_MOVED, and SEQ4_STATUS_LEASE_MOVED
is clear. is clear.
In this case, transition recovery is also required. It is clear In this case, transition recovery is also required. It is clear
that migration discovery is not needed to find file systems that that migration discovery is not needed to find file systems that
have been migrated other that the one returning NFS4ERR_MOVED. have been migrated other than the one returning NFS4ERR_MOVED.
Cases in which this result can arise include a referral or a Cases in which this result can arise include a referral or a
migration for which there is no associated locking state. This migration for which there is no associated locking state. This
can also arise in cases in which an access path transition other can also arise in cases in which an access path transition other
than migration occurs within the same server. In such a case, than migration occurs within the same server. In such a case,
there is no need to set SEQ4_STATUS_LEASE_MOVED, since the lease there is no need to set SEQ4_STATUS_LEASE_MOVED, since the lease
remains associated with the current server even though the access remains associated with the current server even though the access
path has changed. path has changed.
o The COMPOUND status is not NFS4ERR_MOVED and * The COMPOUND status is not NFS4ERR_MOVED, and
SEQ4_STATUS_LEASE_MOVED is asserted. SEQ4_STATUS_LEASE_MOVED is asserted.
In this case, no transition recovery activity is required on the In this case, no transition recovery activity is required on the
file system(s) accessed by the request. However, to prevent file system(s) accessed by the request. However, to prevent
avoidable lease expiration, migration discovery needs to be done avoidable lease expiration, migration discovery needs to be done.
o The COMPOUND status is not NFS4ERR_MOVED and * The COMPOUND status is not NFS4ERR_MOVED, and
SEQ4_STATUS_LEASE_MOVED is clear. SEQ4_STATUS_LEASE_MOVED is clear.
In this case, neither transition-related activity nor migration In this case, neither transition-related activity nor migration
discovery is required. discovery is required.
Note that the specified actions only need to be taken if they are not Note that the specified actions only need to be taken if they are not
already going on. For example, when NFS4ERR_MOVED is received when already going on. For example, when NFS4ERR_MOVED is received while
accessing a file system for which transition recovery already going accessing a file system for which transition recovery is already
on, the client merely waits for that recovery to be completed while occurring, the client merely waits for that recovery to be completed,
the receipt of SEQ4_STATUS_LEASE_MOVED indication only needs to while the receipt of the SEQ4_STATUS_LEASE_MOVED indication only
initiate migration discovery for a server if such discovery is not needs to initiate migration discovery for a server if such discovery
already underway for that server. is not already underway for that server.
The fact that a lease-migrated condition does not result in an error The fact that a lease-migrated condition does not result in an error
in NFSv4.1 has a number of important consequences. In addition to in NFSv4.1 has a number of important consequences. In addition to
the fact, discussed above, that the two indications are not mutually the fact that the two indications are not mutually exclusive, as
exclusive, there are number of issues that are important in discussed above, there are number of issues that are important in
considering implementation of migration discovery, as discussed in considering implementation of migration discovery, as discussed in
Section 11.13.2. Section 11.13.2.
Because SEQ4_STATUS_LEASE_MOVED is not an error condition", it is Because SEQ4_STATUS_LEASE_MOVED is not an error condition, it is
possible for file systems whose access paths have not changed to be possible for file systems whose access paths have not changed to be
successfully accessed on a given server even though recovery is successfully accessed on a given server even though recovery is
necessary for other file systems on the same server. As a result, necessary for other file systems on the same server. As a result,
access can go on while, access can take place while:
o The migration discovery process is going on for that server. * The migration discovery process is happening for that server.
o The transition recovery process is going on for other file systems * The transition recovery process is happening for other file
connected to that server. systems connected to that server.
11.13.2. Performing Migration Discovery 11.13.2. Performing Migration Discovery
Migration discovery can be performed in the same context as Migration discovery can be performed in the same context as
transition recovery, allowing recovery for each migrated file system transition recovery, allowing recovery for each migrated file system
to be invoked as it is discovered. Alternatively, it may be done in to be invoked as it is discovered. Alternatively, it may be done in
a separate migration discovery thread, allowing migration discovery a separate migration discovery thread, allowing migration discovery
to be done in parallel with one or more instances of transition to be done in parallel with one or more instances of transition
recovery. recovery.
In either case, because the lease-migrated indication does not result In either case, because the lease-migrated indication does not result
in an error. other access to file systems on the server can proceed in an error, other access to file systems on the server can proceed
normally, with the possibility that further such indications will be normally, with the possibility that further such indications will be
received, raising the issue of how such indications are to be dealt received, raising the issue of how such indications are to be dealt
with. In general, with. In general:
o No action needs to be taken for such indications received by any * No action needs to be taken for such indications received by any
threads performing migration discovery, since continuation of that threads performing migration discovery, since continuation of that
work will address the issue. work will address the issue.
o In other cases in which migration discovery is currently being * In other cases in which migration discovery is currently being
performed, nothing further needs to be done to respond to such performed, nothing further needs to be done to respond to such
lease migration indications, as long as one can be certain that lease migration indications, as long as one can be certain that
the migration discovery process would deal with those indications. the migration discovery process would deal with those indications.
See below for details. See below for details.
o For such indications received in all other contexts, the * For such indications received in all other contexts, the
appropriate response is to initiate or otherwise provide for the appropriate response is to initiate or otherwise provide for the
execution of migration discovery for file systems associated with execution of migration discovery for file systems associated with
the server IP address returning the indication. the server IP address returning the indication.
This leaves a potential difficulty in situations in which the This leaves a potential difficulty in situations in which the
migration discovery process is near to completion but is still migration discovery process is near to completion but is still
operating. One should not ignore a LEASE_MOVED indication if the operating. One should not ignore a SEQ4_STATUS_LEASE_MOVED
migration discovery process is not able to respond to the discovery indication if the migration discovery process is not able to respond
of additional migrating file systems without additional aid. A to the discovery of additional migrating file systems without
further complexity relevant in addressing such situations is that a additional aid. A further complexity relevant in addressing such
lease-migrated indication may reflect the server's state at the time situations is that a lease-migrated indication may reflect the
the SEQUENCE operation was processed, which may be different from server's state at the time the SEQUENCE operation was processed,
that in effect at the time the response is received. Because new which may be different from that in effect at the time the response
migration events may occur at any time, and because a LEASE_MOVED is received. Because new migration events may occur at any time, and
indication may reflect the situation in effect a considerable time because a SEQ4_STATUS_LEASE_MOVED indication may reflect the
before the indication is received, special care needs to be taken to situation in effect a considerable time before the indication is
ensure that LEASE_MOVED indications are not inappropriately ignored. received, special care needs to be taken to ensure that
SEQ4_STATUS_LEASE_MOVED indications are not inappropriately ignored.
A useful approach to this issue involves the use of separate A useful approach to this issue involves the use of separate
externally-visible migration discovery states for each server. externally-visible migration discovery states for each server.
Separate values could represent the various possible states for the Separate values could represent the various possible states for the
migration discovery process for a server: migration discovery process for a server:
o non-operation, in which migration discovery is not being performed * Non-operation, in which migration discovery is not being
performed.
o normal operation, in which there is an ongoing scan for migrated * Normal operation, in which there is an ongoing scan for migrated
file systems. file systems.
o completion/verification of migration discovery processing, in * Completion/verification of migration discovery processing, in
which the possible completion of migration discovery processing which the possible completion of migration discovery processing
needs to be verified. needs to be verified.
Given that framework, migration discovery processing would proceed as Given that framework, migration discovery processing would proceed as
follows. follows:
o While in the normal-operation state, the thread performing * While in the normal-operation state, the thread performing
discovery would fetch, for successive file systems known to the discovery would fetch, for successive file systems known to the
client on the server being worked on, a file system location client on the server being worked on, a file system location
attribute plus the fs_status attribute. attribute plus the fs_status attribute.
o If the fs_status attribute indicates that the file system is a * If the fs_status attribute indicates that the file system is a
migrated one (i.e. fss_absent is true and fss_type != migrated one (i.e., fss_absent is true, and fss_type !=
STATUS4_REFERRAL) then a migrated file system has been found. In STATUS4_REFERRAL), then a migrated file system has been found. In
this situation, it is likely that the fetch of the file system this situation, it is likely that the fetch of the file system
location attribute has cleared one the file systems contributing location attribute has cleared one of the file systems
to the lease-migrated indication. contributing to the lease-migrated indication.
o In cases in which that happened, the thread cannot know whether * In cases in which that happened, the thread cannot know whether
the lease-migrated indication has been cleared and so it enters the lease-migrated indication has been cleared, and so it enters
the completion/verification state and proceeds to issue a COMPOUND the completion/verification state and proceeds to issue a COMPOUND
to see if the LEASE_MOVED indication has been cleared. to see if the SEQ4_STATUS_LEASE_MOVED indication has been cleared.
o When the discovery process is in the completion/verification * When the discovery process is in the completion/verification
state, if other requests get a lease-migrated indication they note state, if other requests get a lease-migrated indication, they
that it was received. Later, the existence of such indications is note that it was received. Later, the existence of such
used when the request completes, as described below. indications is used when the request completes, as described
below.
When the request used in the completion/verification state completes: When the request used in the completion/verification state completes:
o If a lease-migrated indication is returned, the discovery * If a lease-migrated indication is returned, the discovery
continues normally. Note that this is so even if all file systems continues normally. Note that this is so even if all file systems
have traversed, since new migrations could have occurred while the have been traversed, since new migrations could have occurred
process was going on. while the process was going on.
o Otherwise, if there is any record that other requests saw a lease- * Otherwise, if there is any record that other requests saw a lease-
migrated indication while the request was going on, that record is migrated indication while the request was occurring, that record
cleared and the verification request retried. The discovery is cleared, and the verification request is retried. The
process remains in completion/verification state. discovery process remains in the completion/verification state.
o If there have been no lease-migrated indications, the work of * If there have been no lease-migrated indications, the work of
migration discovery is considered completed and it enters the non- migration discovery is considered completed, and it enters the
operating state. Once it enters this state, subsequent lease- non-operating state. Once it enters this state, subsequent lease-
migrated indication will trigger a new migration discovery migrated indications will trigger a new migration discovery
process. process.
It should be noted that the process described above is not guaranteed It should be noted that the process described above is not guaranteed
to terminate, as a long series of new migration events might to terminate, as a long series of new migration events might
continually delay the clearing of the LEASE_MOVED indication. To continually delay the clearing of the SEQ4_STATUS_LEASE_MOVED
prevent unnecessary lease expiration, it is appropriate for clients indication. To prevent unnecessary lease expiration, it is
to use the discovery of migrations to effect lease renewal appropriate for clients to use the discovery of migrations to effect
immediately, rather than waiting for clearing of the LEASE_MOVED lease renewal immediately, rather than waiting for the clearing of
indication when the complete set of migrations is available. the SEQ4_STATUS_LEASE_MOVED indication when the complete set of
migrations is available.
Lease discovery needs to be provided as described above. This Lease discovery needs to be provided as described above. This
ensures that the client discovers file system migrations soon enough ensures that the client discovers file system migrations soon enough
to renew its leases on each destination server before they expire. to renew its leases on each destination server before they expire.
Non-renewal of leases can lead to loss of locking state. While the Non-renewal of leases can lead to loss of locking state. While the
consequences of such loss can be ameliorated through implementations consequences of such loss can be ameliorated through implementations
of courtesy locks, servers are under no obligation to do so, and a of courtesy locks, servers are under no obligation to do so, and a
conflicting lock request may mean that a lock is revoked conflicting lock request may mean that a lock is revoked
unexpectedly. Clients should be aware of this possibility. unexpectedly. Clients should be aware of this possibility.
11.13.3. Overview of Client Response to NFS4ERR_MOVED 11.13.3. Overview of Client Response to NFS4ERR_MOVED
This section outlines a way in which a client that receives This section outlines a way in which a client that receives
NFS4ERR_MOVED can effect transition recovery by using a new server or NFS4ERR_MOVED can effect transition recovery by using a new server or
server endpoint if one is available. As part of that process, it server endpoint if one is available. As part of that process, it
will determine: will determine:
o Whether the NFS4ERR_MOVED indicates migration has occurred, or * Whether the NFS4ERR_MOVED indicates migration has occurred, or
whether it indicates another sort of file system access transition whether it indicates another sort of file system access transition
as discussed in Section 11.10 above. as discussed in Section 11.10 above.
o In the case of migration, whether Transparent State Migration has * In the case of migration, whether Transparent State Migration has
occurred. occurred.
o Whether any state has been lost during the process of Transparent * Whether any state has been lost during the process of Transparent
State Migration. State Migration.
o Whether sessions have been transferred as part of Transparent * Whether sessions have been transferred as part of Transparent
State Migration. State Migration.
During the first phase of this process, the client proceeds to During the first phase of this process, the client proceeds to
examine file system location entries to find the initial network examine file system location entries to find the initial network
address it will use to continue access to the file system or its address it will use to continue access to the file system or its
replacement. For each location entry that the client examines, the replacement. For each location entry that the client examines, the
process consists of five steps: process consists of five steps:
1. Performing an EXCHANGE_ID directed at the location address. This 1. Performing an EXCHANGE_ID directed at the location address. This
operation is used to register the client owner (in the form of a operation is used to register the client owner (in the form of a
client_owner4) with the server, to obtain a client ID to be use client_owner4) with the server, to obtain a client ID to be used
subsequently to communicate with it, to obtain that client ID's subsequently to communicate with it, to obtain that client ID's
confirmation status, and to determine server_owner and scope for confirmation status, and to determine server_owner4 and scope for
the purpose of determining if the entry is trunkable with that the purpose of determining if the entry is trunkable with the
previously being used to access the file system (i.e. that it address previously being used to access the file system (i.e.,
represents another network access path to the same file system that it represents another network access path to the same file
and can share locking state with it). system and can share locking state with it).
2. Making an initial determination of whether migration has 2. Making an initial determination of whether migration has
occurred. The initial determination will be based on whether the occurred. The initial determination will be based on whether the
EXCHANGE_ID results indicate that the current location element is EXCHANGE_ID results indicate that the current location element is
server-trunkable with that used to access the file system when server-trunkable with that used to access the file system when
access was terminated by receiving NFS4ERR_MOVED. If it is, then access was terminated by receiving NFS4ERR_MOVED. If it is, then
migration has not occurred. In that case, the transition is migration has not occurred. In that case, the transition is
dealt with, at least initially, as one involving continued access dealt with, at least initially, as one involving continued access
to the same file system on the same server through a new network to the same file system on the same server through a new network
address. address.
3. Obtaining access to existing session state or creating new 3. Obtaining access to existing session state or creating new
sessions. How this is done depends on the initial determination sessions. How this is done depends on the initial determination
of whether migration has occurred and can be done as described in of whether migration has occurred and can be done as described in
Section 11.13.4 below in the case of migration or as described in Section 11.13.4 below in the case of migration or as described in
Section 11.13.5 below in the case of a network address transfer Section 11.13.5 below in the case of a network address transfer
without migration. without migration.
4. Verification of the trunking relationship assumed in step 2 as 4. Verifying the trunking relationship assumed in step 2 as
discussed in Section 2.10.5.1. Although this step will generally discussed in Section 2.10.5.1. Although this step will generally
confirm the initial determination, it is possible for confirm the initial determination, it is possible for
verification to fail with the result that an initial verification to invalidate the initial determination of network
determination that a network address shift (without migration) address shift (without migration) and instead determine that
has occurred may be invalidated and migration determined to have migration had occurred. There is no need to redo step 3 above,
occurred. There is no need to redo step 3 above, since it will since it will be possible to continue use of the session
be possible to continue use of the session established already. established already.
5. Obtaining access to existing locking state and/or reobtaining it. 5. Obtaining access to existing locking state and/or re-obtaining
How this is done depends on the final determination of whether it. How this is done depends on the final determination of
migration has occurred and can be done as described below in whether migration has occurred and can be done as described below
Section 11.13.4 in the case of migration or as described in in Section 11.13.4 in the case of migration or as described in
Section 11.13.5 in the case of a network address transfer without Section 11.13.5 in the case of a network address transfer without
migration. migration.
Once the initial address has been determined, clients are free to Once the initial address has been determined, clients are free to
apply an abbreviated process to find additional addresses trunkable apply an abbreviated process to find additional addresses trunkable
with it (clients may seek session-trunkable or server-trunkable with it (clients may seek session-trunkable or server-trunkable
addresses depending on whether they support clientid trunking). addresses depending on whether they support client ID trunking).
During this later phase of the process, further location entries are During this later phase of the process, further location entries are
examined using the abbreviated procedure specified below: examined using the abbreviated procedure specified below:
A: Before the EXCHANGE_ID, the fs name of the location entry is A: Before the EXCHANGE_ID, the fs name of the location entry is
examined and if it does not match that currently being used, the examined, and if it does not match that currently being used, the
entry is ignored. otherwise, one proceeds as specified by step 1 entry is ignored. Otherwise, one proceeds as specified by step 1
above. above.
B: In the case that the network address is session-trunkable with B: In the case that the network address is session-trunkable with
one used previously a BIND_CONN_TO_SESSION is used to access that one used previously, a BIND_CONN_TO_SESSION is used to access
session using the new network address. Otherwise, or if the bind that session using the new network address. Otherwise, or if the
operation fails, a CREATE_SESSION is done. bind operation fails, a CREATE_SESSION is done.
C: The verification procedure referred to in step 4 above is used. C: The verification procedure referred to in step 4 above is used.
However, if it fails, the entry is ignored and the next available However, if it fails, the entry is ignored and the next available
entry is used. entry is used.
11.13.4. Obtaining Access to Sessions and State after Migration 11.13.4. Obtaining Access to Sessions and State after Migration
In the event that migration has occurred, migration recovery will In the event that migration has occurred, migration recovery will
involve determining whether Transparent State Migration has occurred. involve determining whether Transparent State Migration has occurred.
This decision is made based on the client ID returned by the This decision is made based on the client ID returned by the
EXCHANGE_ID and the reported confirmation status. EXCHANGE_ID and the reported confirmation status.
o If the client ID is an unconfirmed client ID not previously known * If the client ID is an unconfirmed client ID not previously known
to the client, then Transparent State Migration has not occurred. to the client, then Transparent State Migration has not occurred.
o If the client ID is a confirmed client ID previously known to the * If the client ID is a confirmed client ID previously known to the
client, then any transferred state would have been merged with an client, then any transferred state would have been merged with an
existing client ID representing the client to the destination existing client ID representing the client to the destination
server. In this state merger case, Transparent State Migration server. In this state merger case, Transparent State Migration
might or might not have occurred and a determination as to whether might or might not have occurred, and a determination as to
it has occurred is deferred until sessions are established and the whether it has occurred is deferred until sessions are established
client is ready to begin state recovery. and the client is ready to begin state recovery.
o If the client ID is a confirmed client ID not previously known to * If the client ID is a confirmed client ID not previously known to
the client, then the client can conclude that the client ID was the client, then the client can conclude that the client ID was
transferred as part of Transparent State Migration. In this transferred as part of Transparent State Migration. In this
transferred client ID case, Transparent State Migration has transferred client ID case, Transparent State Migration has
occurred although some state might have been lost. occurred, although some state might have been lost.
Once the client ID has been obtained, it is necessary to obtain Once the client ID has been obtained, it is necessary to obtain
access to sessions to continue communication with the new server. In access to sessions to continue communication with the new server. In
any of the cases in which Transparent State Migration has occurred, any of the cases in which Transparent State Migration has occurred,
it is possible that a session was transferred as well. To deal with it is possible that a session was transferred as well. To deal with
that possibility, clients can, after doing the EXCHANGE_ID, issue a that possibility, clients can, after doing the EXCHANGE_ID, issue a
BIND_CONN_TO_SESSION to connect the transferred session to a BIND_CONN_TO_SESSION to connect the transferred session to a
connection to the new server. If that fails, it is an indication connection to the new server. If that fails, it is an indication
that the session was not transferred and that a new session needs to that the session was not transferred and that a new session needs to
be created to take its place. be created to take its place.
In some situations, it is possible for a BIND_CONN_TO_SESSION to In some situations, it is possible for a BIND_CONN_TO_SESSION to
succeed without session migration having occurred. If state merger succeed without session migration having occurred. If state merger
has taken place then the associated client ID may have already had a has taken place, then the associated client ID may have already had a
set of existing sessions, with it being possible that the sessionid set of existing sessions, with it being possible that the session ID
of a given session is the same as one that might have been migrated. of a given session is the same as one that might have been migrated.
In that event, a BIND_CONN_TO_SESSION might succeed, even though In that event, a BIND_CONN_TO_SESSION might succeed, even though
there could have been no migration of the session with that there could have been no migration of the session with that session
sessionid. In such cases, the client will receive sequence errors ID. In such cases, the client will receive sequence errors when the
when the slot sequence values used are not appropriate on the new slot sequence values used are not appropriate on the new session.
session. When this occurs, the client can create a new a session and When this occurs, the client can create a new a session and cease
cease using the existing one. using the existing one.
Once the client has determined the initial migration status, and Once the client has determined the initial migration status, and
determined that there was a shift to a new server, it needs to re- determined that there was a shift to a new server, it needs to re-
establish its locking state, if possible. To enable this to happen establish its locking state, if possible. To enable this to happen
without loss of the guarantees normally provided by locking, the without loss of the guarantees normally provided by locking, the
destination server needs to implement a per-fs grace period in all destination server needs to implement a per-fs grace period in all
cases in which lock state was lost, including those in which cases in which lock state was lost, including those in which
Transparent State Migration was not implemented. Each client for Transparent State Migration was not implemented. Each client for
which there was a transfer of locking state to the new server will which there was a transfer of locking state to the new server will
have the duration of the grace period to reclaim its locks, from the have the duration of the grace period to reclaim its locks, from the
time its locks were transferred. time its locks were transferred.
Clients need to deal with the following cases: Clients need to deal with the following cases:
o In the state merger case, it is possible that the server has not * In the state merger case, it is possible that the server has not
attempted Transparent State Migration, in which case state may attempted Transparent State Migration, in which case state may
have been lost without it being reflected in the SEQ4_STATUS bits. have been lost without it being reflected in the SEQ4_STATUS bits.
To determine whether this has happened, the client can use To determine whether this has happened, the client can use
TEST_STATEID to check whether the stateids created on the source TEST_STATEID to check whether the stateids created on the source
server are still accessible on the destination server. Once a server are still accessible on the destination server. Once a
single stateid is found to have been successfully transferred, the single stateid is found to have been successfully transferred, the
client can conclude that Transparent State Migration was begun and client can conclude that Transparent State Migration was begun,
any failure to transport all of the stateids will be reflected in and any failure to transport all of the stateids will be reflected
the SEQ4_STATUS bits. Otherwise, Transparent State Migration has in the SEQ4_STATUS bits. Otherwise, Transparent State Migration
not occurred. has not occurred.
o In a case in which Transparent State Migration has not occurred, * In a case in which Transparent State Migration has not occurred,
the client can use the per-fs grace period provided by the the client can use the per-fs grace period provided by the
destination server to reclaim locks that were held on the source destination server to reclaim locks that were held on the source
server. server.
o In a case in which Transparent State Migration has occurred, and * In a case in which Transparent State Migration has occurred, and
no lock state was lost (as shown by SEQ4_STATUS flags), no lock no lock state was lost (as shown by SEQ4_STATUS flags), no lock
reclaim is necessary. reclaim is necessary.
o In a case in which Transparent State Migration has occurred, and * In a case in which Transparent State Migration has occurred, and
some lock state was lost (as shown by SEQ4_STATUS flags), existing some lock state was lost (as shown by SEQ4_STATUS flags), existing
stateids need to be checked for validity using TEST_STATEID, and stateids need to be checked for validity using TEST_STATEID, and
reclaim used to re-establish any that were not transferred. reclaim used to re-establish any that were not transferred.
For all of the cases above, RECLAIM_COMPLETE with an rca_one_fs value For all of the cases above, RECLAIM_COMPLETE with an rca_one_fs value
of TRUE needs to be done before normal use of the file system of TRUE needs to be done before normal use of the file system,
including obtaining new locks for the file system. This applies even including obtaining new locks for the file system. This applies even
if no locks were lost and there was no need for any to be reclaimed. if no locks were lost and there was no need for any to be reclaimed.
11.13.5. Obtaining Access to Sessions and State after Network Address 11.13.5. Obtaining Access to Sessions and State after Network Address
Transfer Transfer
The case in which there is a transfer to a new network address The case in which there is a transfer to a new network address
without migration is similar to that described in Section 11.13.4 without migration is similar to that described in Section 11.13.4
above in that there is a need to obtain access to needed sessions and above in that there is a need to obtain access to needed sessions and
locking state. However, the details are simpler and will vary locking state. However, the details are simpler and will vary
depending on the type of trunking between the address receiving depending on the type of trunking between the address receiving
NFS4ERR_MOVED and that to which the transfer is to be made NFS4ERR_MOVED and that to which the transfer is to be made.
To make a session available for use, a BIND_CONN_TO_SESSION should be To make a session available for use, a BIND_CONN_TO_SESSION should be
used to obtain access to the session previously in use. Only if this used to obtain access to the session previously in use. Only if this
fails, should a CREATE_SESSION be done. While this procedure mirrors fails, should a CREATE_SESSION be done. While this procedure mirrors
that in Section 11.13.4 above, there is an important difference in that in Section 11.13.4 above, there is an important difference in
that preservation of the session is not purely optional but depends that preservation of the session is not purely optional but depends
on the type of trunking. on the type of trunking.
Access to appropriate locking state will generally need no actions Access to appropriate locking state will generally need no actions
beyond access to the session. However, the SEQ4_STATUS bits need to beyond access to the session. However, the SEQ4_STATUS bits need to
be checked for lost locking state, including the need to reclaim be checked for lost locking state, including the need to reclaim
locks after a server reboot, since there is always a possibility of locks after a server reboot, since there is always a possibility of
locking state being lost. locking state being lost.
11.14. Server Responsibilities Upon Migration 11.14. Server Responsibilities Upon Migration
In the event of file system migration, when the client connects to In the event of file system migration, when the client connects to
the destination server, that server needs to be able to provide the the destination server, that server needs to be able to provide the
client continued to access the files it had open on the source client continued access to the files it had open on the source
server. There are two ways to provide this: server. There are two ways to provide this:
o By provision of an fs-specific grace period, allowing the client * By provision of an fs-specific grace period, allowing the client
the ability to reclaim its locks, in a fashion similar to what the ability to reclaim its locks, in a fashion similar to what
would have been done in the case of recovery from a server would have been done in the case of recovery from a server
restart. See Section 11.14.1 for a more complete discussion. restart. See Section 11.14.1 for a more complete discussion.
o By implementing Transparent State Migration possibly in connection * By implementing Transparent State Migration possibly in connection
with session migration, the server can provide the client with session migration, the server can provide the client
immediate access to the state built up on the source server, on immediate access to the state built up on the source server on the
the destination. destination server.
These features are discussed separately in Sections 11.14.2 and These features are discussed separately in Sections 11.14.2 and
11.14.3, which discuss Transparent State Migration and session 11.14.3, which discuss Transparent State Migration and session
migration respectively. migration, respectively.
All the features described above can involve transfer of lock-related All the features described above can involve transfer of lock-related
information between source and destination servers. In some cases, information between source and destination servers. In some cases,
this transfer is a necessary part of the implementation while in this transfer is a necessary part of the implementation, while in
other cases it is a helpful implementation aid which servers might or other cases, it is a helpful implementation aid, which servers might
might not use. The sub-sections below discuss the information which or might not use. The subsections below discuss the information that
would be transferred but do not define the specifics of the transfer would be transferred but do not define the specifics of the transfer
protocol. This is left as an implementation choice although protocol. This is left as an implementation choice, although
standards in this area could be developed at a later time. standards in this area could be developed at a later time.
11.14.1. Server Responsibilities in Effecting State Reclaim after 11.14.1. Server Responsibilities in Effecting State Reclaim after
Migration Migration
In this case, the destination server needs no knowledge of the locks In this case, the destination server needs no knowledge of the locks
held on the source server. It relies on the clients to accurately held on the source server. It relies on the clients to accurately
report (via reclaim operations) the locks previously held, and does report (via reclaim operations) the locks previously held, and does
not allow new locks to be granted on migrated file systems until the not allow new locks to be granted on migrated file systems until the
grace period expires. Disallowing of new locks applies to all grace period expires. Disallowing of new locks applies to all
clients accessing these file system, while grace period expiration clients accessing these file systems, while grace period expiration
occurs for each migrated client independently. occurs for each migrated client independently.
During this grace period clients have the opportunity to use reclaim During this grace period, clients have the opportunity to use reclaim
operations to obtain locks for file system objects within the operations to obtain locks for file system objects within the
migrated file system, in the same way that they do when recovering migrated file system, in the same way that they do when recovering
from server restart, and the servers typically rely on clients to from server restart, and the servers typically rely on clients to
accurately report their locks, although they have the option of accurately report their locks, although they have the option of
subjecting these requests to verification. If the clients only subjecting these requests to verification. If the clients only
reclaim locks held on the source server, no conflict can arise. Once reclaim locks held on the source server, no conflict can arise. Once
the client has reclaimed its locks, it indicates the completion of the client has reclaimed its locks, it indicates the completion of
lock reclamation by performing a RECLAIM_COMPLETE specifying lock reclamation by performing a RECLAIM_COMPLETE specifying
rca_one_fs as TRUE. rca_one_fs as TRUE.
While it is not necessary for source and destination servers to co- While it is not necessary for source and destination servers to
operate to transfer information about locks, implementations are cooperate to transfer information about locks, implementations are
well-advised to consider transferring the following useful well advised to consider transferring the following useful
information: information:
o If information about the set of clients that have locking state * If information about the set of clients that have locking state
for the transferred file system is made available, the destination for the transferred file system is made available, the destination
server will be able to terminate the grace period once all such server will be able to terminate the grace period once all such
clients have reclaimed their locks, allowing normal locking clients have reclaimed their locks, allowing normal locking
activity to resume earlier than it would have otherwise. activity to resume earlier than it would have otherwise.
o Locking summary information for individual clients (at various * Locking summary information for individual clients (at various
possible levels of detail) can detect some instances in which possible levels of detail) can detect some instances in which
clients do not accurately represent the locks held on the source clients do not accurately represent the locks held on the source
server. server.
11.14.2. Server Responsibilities in Effecting Transparent State 11.14.2. Server Responsibilities in Effecting Transparent State
Migration Migration
The basic responsibility of the source server in effecting The basic responsibility of the source server in effecting
Transparent State Migration is to make available to the destination Transparent State Migration is to make available to the destination
server a description of each piece of locking state associated with server a description of each piece of locking state associated with
the file system being migrated. In addition to client id string and the file system being migrated. In addition to client id string and
verifier, the source server needs to provide, for each stateid: verifier, the source server needs to provide for each stateid:
o The stateid including the current sequence value. * The stateid including the current sequence value.
o The associated client ID. * The associated client ID.
o The handle of the associated file. * The handle of the associated file.
o The type of the lock, such as open, byte-range lock, delegation, * The type of the lock, such as open, byte-range lock, delegation,
or layout. or layout.
o For locks such as opens and byte-range locks, there will be * For locks such as opens and byte-range locks, there will be
information about the owner(s) of the lock. information about the owner(s) of the lock.
o For recallable/revocable lock types, the current recall status * For recallable/revocable lock types, the current recall status
needs to be included. needs to be included.
o For each lock type, there will be type-specific information, such * For each lock type, there will be associated type-specific
as share and deny modes for opens and type and byte ranges for information. For opens, this will include share and deny mode
byte-range locks and layouts. while for byte-range locks and layouts, there will be a type and a
byte-range.
Such information will most probably be organized by client id string Such information will most probably be organized by client id string
on the destination server so that it can be used to provide on the destination server so that it can be used to provide
appropriate context to each client when it makes itself known to the appropriate context to each client when it makes itself known to the
client. Issues connected with a client impersonating another by client. Issues connected with a client impersonating another by
presenting another client's client id string can be addressed using presenting another client's client id string can be addressed using
NFSv4.1 state protection features, as described in Section 21. NFSv4.1 state protection features, as described in Section 21.
A further server responsibility concerns locks that are revoked or A further server responsibility concerns locks that are revoked or
otherwise lost during the process of file system migration. Because otherwise lost during the process of file system migration. Because
locks that appear to be lost during the process of migration will be locks that appear to be lost during the process of migration will be
reclaimed by the client, the servers have to take steps to ensure reclaimed by the client, the servers have to take steps to ensure
that locks revoked soon before or soon after migration are not that locks revoked soon before or soon after migration are not
inadvertently allowed to be reclaimed in situations in which the inadvertently allowed to be reclaimed in situations in which the
continuity of lock possession cannot be assured. continuity of lock possession cannot be assured.
o For locks lost on the source but whose loss has not yet been * For locks lost on the source but whose loss has not yet been
acknowledged by the client (by using FREE_STATEID), the acknowledged by the client (by using FREE_STATEID), the
destination must be aware of this loss so that it can deny a destination must be aware of this loss so that it can deny a
request to reclaim them. request to reclaim them.
o For locks lost on the destination after the state transfer but * For locks lost on the destination after the state transfer but
before the client's RECLAIM_COMPLTE is done, the destination before the client's RECLAIM_COMPLETE is done, the destination
server should note these and not allow them to be reclaimed. server should note these and not allow them to be reclaimed.
An additional responsibility of the cooperating servers concerns An additional responsibility of the cooperating servers concerns
situations in which a stateid cannot be transferred transparently situations in which a stateid cannot be transferred transparently
because it conflicts with an existing stateid held by the client and because it conflicts with an existing stateid held by the client and
associated with a different file system. In this case there are two associated with a different file system. In this case, there are two
valid choices: valid choices:
o Treat the transfer, as in NFSv4.0, as one without Transparent * Treat the transfer, as in NFSv4.0, as one without Transparent
State Migration. In this case, conflicting locks cannot be State Migration. In this case, conflicting locks cannot be
granted until the client does a RECLAIM_COMPLETE, after reclaiming granted until the client does a RECLAIM_COMPLETE, after reclaiming
the locks it had, with the exception of reclaims denied because the locks it had, with the exception of reclaims denied because
they were attempts to reclaim locks that had been lost. they were attempts to reclaim locks that had been lost.
o Implement Transparent State Migration, except for the lock with * Implement Transparent State Migration, except for the lock with
the conflicting stateid. In this case, the client will be aware the conflicting stateid. In this case, the client will be aware
of a lost lock (through the SEQ4_STATUS flags) and be allowed to of a lost lock (through the SEQ4_STATUS flags) and be allowed to
reclaim it. reclaim it.
When transferring state between the source and destination, the When transferring state between the source and destination, the
issues discussed in Section 7.2 of [68] must still be attended to. issues discussed in Section 7.2 of [69] must still be attended to.
In this case, the use of NFS4ERR_DELAY may still necessary in In this case, the use of NFS4ERR_DELAY may still be necessary in
NFSv4.1, as it was in NFSv4.0, to prevent locking state changing NFSv4.1, as it was in NFSv4.0, to prevent locking state changing
while it is being transferred. See Section 15.1.1.3 for information while it is being transferred. See Section 15.1.1.3 for information
about appropriate client retry approaches in the event that about appropriate client retry approaches in the event that
NFS4ERR_DELAY is returned. NFS4ERR_DELAY is returned.
There are a number of important differences in the NFS4.1 context: There are a number of important differences in the NFS4.1 context:
o The absence of RELEASE_LOCKOWNER means that the one case in which * The absence of RELEASE_LOCKOWNER means that the one case in which
an operation could not be deferred by use of NFS4ERR_DELAY no an operation could not be deferred by use of NFS4ERR_DELAY no
longer exists. longer exists.
o Sequencing of operations is no longer done using owner-based * Sequencing of operations is no longer done using owner-based
operation sequences numbers. Instead, sequencing is session- operation sequences numbers. Instead, sequencing is session-
based based.
As a result, when sessions are not transferred, the techniques As a result, when sessions are not transferred, the techniques
discussed in Section 7.2 of [68] are adequate and will not be further discussed in Section 7.2 of [69] are adequate and will not be further
discussed. discussed.
11.14.3. Server Responsibilities in Effecting Session Transfer 11.14.3. Server Responsibilities in Effecting Session Transfer
The basic responsibility of the source server in effecting session The basic responsibility of the source server in effecting session
transfer is to make available to the destination server a description transfer is to make available to the destination server a description
of the current state of each slot with the session, including: of the current state of each slot with the session, including the
following:
o The last sequence value received for that slot. * The last sequence value received for that slot.
o Whether there is cached reply data for the last request executed * Whether there is cached reply data for the last request executed
and, if so, the cached reply. and, if so, the cached reply.
When sessions are transferred, there are a number of issues that pose When sessions are transferred, there are a number of issues that pose
challenges in terms of making the transferred state unmodifiable challenges in terms of making the transferred state unmodifiable
during the period it is gathered up and transferred to the during the period it is gathered up and transferred to the
destination server. destination server:
o A single session may be used to access multiple file systems, not * A single session may be used to access multiple file systems, not
all of which are being transferred. all of which are being transferred.
o Requests made on a session may, even if rejected, affect the state * Requests made on a session may, even if rejected, affect the state
of the session by advancing the sequence number associated with of the session by advancing the sequence number associated with
the slot used. the slot used.
As a result, when the file system state might otherwise be considered As a result, when the file system state might otherwise be considered
unmodifiable, the client might have any number of in-flight requests, unmodifiable, the client might have any number of in-flight requests,
each of which is capable of changing session state, which may be of a each of which is capable of changing session state, which may be of a
number of types: number of types:
1. Those requests that were processed on the migrating file system, 1. Those requests that were processed on the migrating file system
before migration began. before migration began.
2. Those requests which got the error NFS4ERR_DELAY because the file 2. Those requests that received the error NFS4ERR_DELAY because the
system being accessed was in the process of being migrated. file system being accessed was in the process of being migrated.
3. Those requests which got the error NFS4ERR_MOVED because the file 3. Those requests that received the error NFS4ERR_MOVED because the
system being accessed had been migrated. file system being accessed had been migrated.
4. Those requests that accessed the migrating file system, in order 4. Those requests that accessed the migrating file system in order
to obtain location or status information. to obtain location or status information.
5. Those requests that did not reference the migrating file system. 5. Those requests that did not reference the migrating file system.
It should be noted that the history of any particular slot is likely It should be noted that the history of any particular slot is likely
to include a number of these request classes. In the case in which a to include a number of these request classes. In the case in which a
session which is migrated is used by file systems other than the one session that is migrated is used by file systems other than the one
migrated, requests of class 5 may be common and be the last request migrated, requests of class 5 may be common and may be the last
processed, for many slots. request processed for many slots.
Since session state can change even after the locking state has been Since session state can change even after the locking state has been
fixed as part of the migration process, the session state known to fixed as part of the migration process, the session state known to
the client could be different from that on the destination server, the client could be different from that on the destination server,
which necessarily reflects the session state on the source server, at which necessarily reflects the session state on the source server at
an earlier time. In deciding how to deal with this situation, it is an earlier time. In deciding how to deal with this situation, it is
helpful to distinguish between two sorts of behavioral consequences helpful to distinguish between two sorts of behavioral consequences
of the choice of initial sequence ID values. of the choice of initial sequence ID values:
o The error NFS4ERR_SEQ_MISORDERED is returned when the sequence ID * The error NFS4ERR_SEQ_MISORDERED is returned when the sequence ID
in a request is neither equal to the last one seen for the current in a request is neither equal to the last one seen for the current
slot nor the next greater one. slot nor the next greater one.
In view of the difficulty of arriving at a mutually acceptable In view of the difficulty of arriving at a mutually acceptable
value for the correct last sequence value at the point of value for the correct last sequence value at the point of
migration, it may be necessary for the server to show some degree migration, it may be necessary for the server to show some degree
of forbearance, when the sequence ID is one that would be of forbearance when the sequence ID is one that would be
considered unacceptable if session migration were not involved. considered unacceptable if session migration were not involved.
o Returning the cached reply for a previously executed request when * Returning the cached reply for a previously executed request when
the sequence ID in the request matches the last value recorded for the sequence ID in the request matches the last value recorded for
the slot. the slot.
In the cases in which an error is returned and there is no In the cases in which an error is returned and there is no
possibility of any non-idempotent operation having been executed, possibility of any non-idempotent operation having been executed,
it may not be necessary to adhere to this as strictly as might be it may not be necessary to adhere to this as strictly as might be
proper if session migration were not involved. For example, the proper if session migration were not involved. For example, the
fact that the error NFS4ERR_DELAY was returned may not assist the fact that the error NFS4ERR_DELAY was returned may not assist the
client in any material way, while the fact that NFS4ERR_MOVED was client in any material way, while the fact that NFS4ERR_MOVED was
returned by the source server may not be relevant when the request returned by the source server may not be relevant when the request
was reissued, directed to the destination server. was reissued and directed to the destination server.
An important issue is that the specification needs to take note of An important issue is that the specification needs to take note of
all potential COMPOUNDs, even if they might be unlikely in practice. all potential COMPOUNDs, even if they might be unlikely in practice.
For example, a COMPOUND is allowed to access multiple file systems For example, a COMPOUND is allowed to access multiple file systems
and might perform non-idempotent operations in some of them before and might perform non-idempotent operations in some of them before
accessing a file system being migrated. Also, a COMPOUND may return accessing a file system being migrated. Also, a COMPOUND may return
considerable data in the response, before being rejected with considerable data in the response before being rejected with
NFS4ERR_DELAY or NFS4ERR_MOVED, and may in addition be marked as NFS4ERR_DELAY or NFS4ERR_MOVED, and may in addition be marked as
sa_cachethis. However, note that if the client and server adhere to sa_cachethis. However, note that if the client and server adhere to
rules in Section 15.1.1.3, there is no possibility of non-idempotent rules in Section 15.1.1.3, there is no possibility of non-idempotent
operations being spuriously reissued after receiving NFS4ERR_DELAY operations being spuriously reissued after receiving NFS4ERR_DELAY
response. response.
To address these issues, a destination server MAY do any of the To address these issues, a destination server MAY do any of the
following when implementing session transfer. following when implementing session transfer:
o Avoid enforcing any sequencing semantics for a particular slot * Avoid enforcing any sequencing semantics for a particular slot
until the client has established the starting sequence for that until the client has established the starting sequence for that
slot on the destination server. slot on the destination server.
o For each slot, avoid returning a cached reply returning * For each slot, avoid returning a cached reply returning
NFS4ERR_DELAY or NFS4ERR_MOVED until the client has established NFS4ERR_DELAY or NFS4ERR_MOVED until the client has established
the starting sequence for that slot on the destination server. the starting sequence for that slot on the destination server.
o Until the client has established the starting sequence for a * Until the client has established the starting sequence for a
particular slot on the destination server, avoid reporting particular slot on the destination server, avoid reporting
NFS4ERR_SEQ_MISORDERED or returning a cached reply returning NFS4ERR_SEQ_MISORDERED or returning a cached reply that contains
NFS4ERR_DELAY or NFS4ERR_MOVED, where the reply consists solely of either NFS4ERR_DELAY or NFS4ERR_MOVED and consists solely of a
a series of operations where the response is NFS4_OK until the series of operations where the response is NFS4_OK until the final
final error. error.
Because of the considerations mentioned above including the rules for Because of the considerations mentioned above, including the rules
the handling of NFS4ERR_DELAY included in Section 15.1.1.3, the for the handling of NFS4ERR_DELAY included in Section 15.1.1.3, the
destination server can respond appropriately to SEQUENCE operations destination server can respond appropriately to SEQUENCE operations
received from the client by adopting the three policies listed below: received from the client by adopting the three policies listed below:
o Not responding with NFS4ERR_SEQ_MISORDERED for the initial request * Not responding with NFS4ERR_SEQ_MISORDERED for the initial request
on a slot within a transferred session, since the destination on a slot within a transferred session because the destination
server cannot be aware of requests made by the client after the server cannot be aware of requests made by the client after the
server handoff but before the client became aware of the shift. server handoff but before the client became aware of the shift.
In cases in which NFS4ERR_SEQ_MISORDERED would normally have been In cases in which NFS4ERR_SEQ_MISORDERED would normally have been
reported, the request is to be processed normally, as a new reported, the request is to be processed normally as a new
request. request.
o Replying as it would for a retry whenever the sequence matches * Replying as it would for a retry whenever the sequence matches
that transferred by the source server, even though this would not that transferred by the source server, even though this would not
provide retry handling for requests issued after the server provide retry handling for requests issued after the server
handoff, under the assumption that when such requests are issued handoff, under the assumption that, when such requests are issued,
they will never be responded to in a state-changing fashion, they will never be responded to in a state-changing fashion,
making retry support for them unnecessary. making retry support for them unnecessary.
o Once a non-retry SEQUENCE is received for a given slot, using that * Once a non-retry SEQUENCE is received for a given slot, using that
as the basis for further sequence checking, with no further as the basis for further sequence checking, with no further
reference to the sequence value transferred by the source. reference to the sequence value transferred by the source server.
server.
11.15. Effecting File System Referrals 11.15. Effecting File System Referrals
Referrals are effected when an absent file system is encountered and Referrals are effected when an absent file system is encountered and
one or more alternate locations are made available by the one or more alternate locations are made available by the
fs_locations or fs_locations_info attributes. The client will fs_locations or fs_locations_info attributes. The client will
typically get an NFS4ERR_MOVED error, fetch the appropriate location typically get an NFS4ERR_MOVED error, fetch the appropriate location
information, and proceed to access the file system on a different information, and proceed to access the file system on a different
server, even though it retains its logical position within the server, even though it retains its logical position within the
original namespace. Referrals differ from migration events in that original namespace. Referrals differ from migration events in that
they happen only when the client has not previously referenced the they happen only when the client has not previously referenced the
file system in question (so there is nothing to transition). file system in question (so there is nothing to transition).
Referrals can only come into effect when an absent file system is Referrals can only come into effect when an absent file system is
encountered at its root. encountered at its root.
The examples given in the sections below are somewhat artificial in The examples given in the sections below are somewhat artificial in
that an actual client will not typically do a multi-component look that an actual client will not typically do a multi-component look
up, but will have cached information regarding the upper levels of up, but will have cached information regarding the upper levels of
the name hierarchy. However, these examples are chosen to make the the name hierarchy. However, these examples are chosen to make the
required behavior clear and easy to put within the scope of a small required behavior clear and easy to put within the scope of a small
number of requests, without getting a discussion of the details of number of requests, without getting into a discussion of the details
how specific clients might choose to cache things. of how specific clients might choose to cache things.
11.15.1. Referral Example (LOOKUP) 11.15.1. Referral Example (LOOKUP)
Let us suppose that the following COMPOUND is sent in an environment Let us suppose that the following COMPOUND is sent in an environment
in which /this/is/the/path is absent from the target server. This in which /this/is/the/path is absent from the target server. This
may be for a number of reasons. It may be that the file system has may be for a number of reasons. It may be that the file system has
moved, or it may be that the target server is functioning mainly, or moved, or it may be that the target server is functioning mainly, or
solely, to refer clients to the servers on which various file systems solely, to refer clients to the servers on which various file systems
are located. are located.
o PUTROOTFH * PUTROOTFH
o LOOKUP "this" * LOOKUP "this"
o LOOKUP "is" * LOOKUP "is"
o LOOKUP "the" * LOOKUP "the"
o LOOKUP "path" * LOOKUP "path"
o GETFH * GETFH
o GETATTR (fsid, fileid, size, time_modify) * GETATTR (fsid, fileid, size, time_modify)
Under the given circumstances, the following will be the result. Under the given circumstances, the following will be the result.
o PUTROOTFH --> NFS_OK. The current fh is now the root of the * PUTROOTFH --> NFS_OK. The current fh is now the root of the
pseudo-fs. pseudo-fs.
o LOOKUP "this" --> NFS_OK. The current fh is for /this and is * LOOKUP "this" --> NFS_OK. The current fh is for /this and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is * LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and * LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and
is within the pseudo-fs. is within the pseudo-fs.
o LOOKUP "path" --> NFS_OK. The current fh is for /this/is/the/path * LOOKUP "path" --> NFS_OK. The current fh is for /this/is/the/path
and is within a new, absent file system, but ... the client will and is within a new, absent file system, but ... the client will
never see the value of that fh. never see the value of that fh.
o GETFH --> NFS4ERR_MOVED. Fails because current fh is in an absent * GETFH --> NFS4ERR_MOVED. Fails because current fh is in an absent
file system at the start of the operation, and the specification file system at the start of the operation, and the specification
makes no exception for GETFH. makes no exception for GETFH.
o GETATTR (fsid, fileid, size, time_modify). Not executed because * GETATTR (fsid, fileid, size, time_modify). Not executed because
the failure of the GETFH stops processing of the COMPOUND. the failure of the GETFH stops processing of the COMPOUND.
Given the failure of the GETFH, the client has the job of determining Given the failure of the GETFH, the client has the job of determining
the root of the absent file system and where to find that file the root of the absent file system and where to find that file
system, i.e., the server and path relative to that server's root fh. system, i.e., the server and path relative to that server's root fh.
Note that in this example, the client did not obtain filehandles and Note that in this example, the client did not obtain filehandles and
attribute information (e.g., fsid) for the intermediate directories, attribute information (e.g., fsid) for the intermediate directories,
so that it would not be sure where the absent file system starts. It so that it would not be sure where the absent file system starts. It
could be the case, for example, that /this/is/the is the root of the could be the case, for example, that /this/is/the is the root of the
moved file system and that the reason that the look up of "path" moved file system and that the reason that the look up of "path"
skipping to change at page 279, line 36 skipping to change at line 13385
In order to get the necessary information, let us re-send the chain In order to get the necessary information, let us re-send the chain
of LOOKUPs with GETFHs and GETATTRs to at least get the fsids so we of LOOKUPs with GETFHs and GETATTRs to at least get the fsids so we
can be sure where the appropriate file system boundaries are. The can be sure where the appropriate file system boundaries are. The
client could choose to get fs_locations_info at the same time but in client could choose to get fs_locations_info at the same time but in
most cases the client will have a good guess as to where file system most cases the client will have a good guess as to where file system
boundaries are (because of where NFS4ERR_MOVED was, and was not, boundaries are (because of where NFS4ERR_MOVED was, and was not,
received) making fetching of fs_locations_info unnecessary. received) making fetching of fs_locations_info unnecessary.
OP01: PUTROOTFH --> NFS_OK OP01: PUTROOTFH --> NFS_OK
- Current fh is root of pseudo-fs. * Current fh is root of pseudo-fs.
OP02: GETATTR(fsid) --> NFS_OK OP02: GETATTR(fsid) --> NFS_OK
- Just for completeness. Normally, clients will know the fsid of * Just for completeness. Normally, clients will know the fsid of
the pseudo-fs as soon as they establish communication with a the pseudo-fs as soon as they establish communication with a
server. server.
OP03: LOOKUP "this" --> NFS_OK OP03: LOOKUP "this" --> NFS_OK
OP04: GETATTR(fsid) --> NFS_OK OP04: GETATTR(fsid) --> NFS_OK
- Get current fsid to see where file system boundaries are. The * Get current fsid to see where file system boundaries are. The
fsid will be that for the pseudo-fs in this example, so no fsid will be that for the pseudo-fs in this example, so no
boundary. boundary.
OP05: GETFH --> NFS_OK OP05: GETFH --> NFS_OK
- Current fh is for /this and is within pseudo-fs.
* Current fh is for /this and is within pseudo-fs.
OP06: LOOKUP "is" --> NFS_OK OP06: LOOKUP "is" --> NFS_OK
- Current fh is for /this/is and is within pseudo-fs. * Current fh is for /this/is and is within pseudo-fs.
OP07: GETATTR(fsid) --> NFS_OK OP07: GETATTR(fsid) --> NFS_OK
- Get current fsid to see where file system boundaries are. The * Get current fsid to see where file system boundaries are. The
fsid will be that for the pseudo-fs in this example, so no fsid will be that for the pseudo-fs in this example, so no
boundary. boundary.
OP08: GETFH --> NFS_OK OP08: GETFH --> NFS_OK
- Current fh is for /this/is and is within pseudo-fs. * Current fh is for /this/is and is within pseudo-fs.
OP09: LOOKUP "the" --> NFS_OK OP09: LOOKUP "the" --> NFS_OK
- Current fh is for /this/is/the and is within pseudo-fs. * Current fh is for /this/is/the and is within pseudo-fs.
OP10: GETATTR(fsid) --> NFS_OK OP10: GETATTR(fsid) --> NFS_OK
- Get current fsid to see where file system boundaries are. The * Get current fsid to see where file system boundaries are. The
fsid will be that for the pseudo-fs in this example, so no fsid will be that for the pseudo-fs in this example, so no
boundary. boundary.
OP11: GETFH --> NFS_OK OP11: GETFH --> NFS_OK
- Current fh is for /this/is/the and is within pseudo-fs. * Current fh is for /this/is/the and is within pseudo-fs.
OP12: LOOKUP "path" --> NFS_OK OP12: LOOKUP "path" --> NFS_OK
- Current fh is for /this/is/the/path and is within a new, absent * Current fh is for /this/is/the/path and is within a new, absent
file system, but ... file system, but ...
- The client will never see the value of that fh. * The client will never see the value of that fh.
OP13: GETATTR(fsid, fs_locations_info) --> NFS_OK OP13: GETATTR(fsid, fs_locations_info) --> NFS_OK
- We are getting the fsid to know where the file system boundaries * We are getting the fsid to know where the file system
are. In this operation, the fsid will be different than that of boundaries are. In this operation, the fsid will be different
the parent directory (which in turn was retrieved in OP10). Note than that of the parent directory (which in turn was retrieved
that the fsid we are given will not necessarily be preserved at in OP10). Note that the fsid we are given will not necessarily
the new location. That fsid might be different, and in fact the be preserved at the new location. That fsid might be
fsid we have for this file system might be a valid fsid of a different, and in fact the fsid we have for this file system
different file system on that new server. might be a valid fsid of a different file system on that new
server.
- In this particular case, we are pretty sure anyway that what has * In this particular case, we are pretty sure anyway that what
moved is /this/is/the/path rather than /this/is/the since we have has moved is /this/is/the/path rather than /this/is/the since
the fsid of the latter and it is that of the pseudo-fs, which we have the fsid of the latter and it is that of the pseudo-fs,
presumably cannot move. However, in other examples, we might not which presumably cannot move. However, in other examples, we
have this kind of information to rely on (e.g., /this/is/the might might not have this kind of information to rely on (e.g.,
be a non-pseudo file system separate from /this/is/the/path), so /this/is/the might be a non-pseudo file system separate from
we need to have other reliable source information on the boundary /this/is/the/path), so we need to have other reliable source
of the file system that is moved. If, for example, the file information on the boundary of the file system that is moved.
system /this/is had moved, we would have a case of migration If, for example, the file system /this/is had moved, we would
rather than referral, and once the boundaries of the migrated file have a case of migration rather than referral, and once the
system was clear we could fetch fs_locations_info. boundaries of the migrated file system was clear we could fetch
fs_locations_info.
- We are fetching fs_locations_info because the fact that we got an * We are fetching fs_locations_info because the fact that we got
NFS4ERR_MOVED at this point means that it is most likely that this an NFS4ERR_MOVED at this point means that it is most likely
is a referral and we need the destination. Even if it is the case that this is a referral and we need the destination. Even if
that /this/is/the is a file system that has migrated, we will it is the case that /this/is/the is a file system that has
still need the location information for that file system. migrated, we will still need the location information for that
file system.
OP14: GETFH --> NFS4ERR_MOVED OP14: GETFH --> NFS4ERR_MOVED
- Fails because current fh is in an absent file system at the start * Fails because current fh is in an absent file system at the
of the operation, and the specification makes no exception for start of the operation, and the specification makes no
GETFH. Note that this means the server will never send the client exception for GETFH. Note that this means the server will
a filehandle from within an absent file system. never send the client a filehandle from within an absent file
system.
Given the above, the client knows where the root of the absent file Given the above, the client knows where the root of the absent file
system is (/this/is/the/path) by noting where the change of fsid system is (/this/is/the/path) by noting where the change of fsid
occurred (between "the" and "path"). The fs_locations_info attribute occurred (between "the" and "path"). The fs_locations_info attribute
also gives the client the actual location of the absent file system, also gives the client the actual location of the absent file system,
so that the referral can proceed. The server gives the client the so that the referral can proceed. The server gives the client the
bare minimum of information about the absent file system so that bare minimum of information about the absent file system so that
there will be very little scope for problems of conflict between there will be very little scope for problems of conflict between
information sent by the referring server and information of the file information sent by the referring server and information of the file
system's home. No filehandles and very few attributes are present on system's home. No filehandles and very few attributes are present on
skipping to change at page 281, line 50 skipping to change at line 13499
transient information with the function of enabling the referral. transient information with the function of enabling the referral.
11.15.2. Referral Example (READDIR) 11.15.2. Referral Example (READDIR)
Another context in which a client may encounter referrals is when it Another context in which a client may encounter referrals is when it
does a READDIR on a directory in which some of the sub-directories does a READDIR on a directory in which some of the sub-directories
are the roots of absent file systems. are the roots of absent file systems.
Suppose such a directory is read as follows: Suppose such a directory is read as follows:
o PUTROOTFH * PUTROOTFH
o LOOKUP "this" * LOOKUP "this"
o LOOKUP "is"
o LOOKUP "the" * LOOKUP "is"
o READDIR (fsid, size, time_modify, mounted_on_fileid) * LOOKUP "the"
* READDIR (fsid, size, time_modify, mounted_on_fileid)
In this case, because rdattr_error is not requested, In this case, because rdattr_error is not requested,
fs_locations_info is not requested, and some of the attributes cannot fs_locations_info is not requested, and some of the attributes cannot
be provided, the result will be an NFS4ERR_MOVED error on the be provided, the result will be an NFS4ERR_MOVED error on the
READDIR, with the detailed results as follows: READDIR, with the detailed results as follows:
o PUTROOTFH --> NFS_OK. The current fh is at the root of the * PUTROOTFH --> NFS_OK. The current fh is at the root of the
pseudo-fs. pseudo-fs.
o LOOKUP "this" --> NFS_OK. The current fh is for /this and is * LOOKUP "this" --> NFS_OK. The current fh is for /this and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is * LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and * LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and
is within the pseudo-fs. is within the pseudo-fs.
o READDIR (fsid, size, time_modify, mounted_on_fileid) --> * READDIR (fsid, size, time_modify, mounted_on_fileid) -->
NFS4ERR_MOVED. Note that the same error would have been returned NFS4ERR_MOVED. Note that the same error would have been returned
if /this/is/the had migrated, but it is returned because the if /this/is/the had migrated, but it is returned because the
directory contains the root of an absent file system. directory contains the root of an absent file system.
So now suppose that we re-send with rdattr_error: So now suppose that we re-send with rdattr_error:
o PUTROOTFH * PUTROOTFH
o LOOKUP "this" * LOOKUP "this"
o LOOKUP "is" * LOOKUP "is"
o LOOKUP "the" * LOOKUP "the"
o READDIR (rdattr_error, fsid, size, time_modify, mounted_on_fileid) * READDIR (rdattr_error, fsid, size, time_modify, mounted_on_fileid)
The results will be: The results will be:
o PUTROOTFH --> NFS_OK. The current fh is at the root of the * PUTROOTFH --> NFS_OK. The current fh is at the root of the
pseudo-fs. pseudo-fs.
o LOOKUP "this" --> NFS_OK. The current fh is for /this and is * LOOKUP "this" --> NFS_OK. The current fh is for /this and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is * LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and * LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and
is within the pseudo-fs. is within the pseudo-fs.
o READDIR (rdattr_error, fsid, size, time_modify, mounted_on_fileid) * READDIR (rdattr_error, fsid, size, time_modify, mounted_on_fileid)
--> NFS_OK. The attributes for directory entry with the component --> NFS_OK. The attributes for directory entry with the component
named "path" will only contain rdattr_error with the value named "path" will only contain rdattr_error with the value
NFS4ERR_MOVED, together with an fsid value and a value for NFS4ERR_MOVED, together with an fsid value and a value for
mounted_on_fileid. mounted_on_fileid.
Suppose we do another READDIR to get fs_locations_info (although we Suppose we do another READDIR to get fs_locations_info (although we
could have used a GETATTR directly, as in Section 11.15.1). could have used a GETATTR directly, as in Section 11.15.1).
o PUTROOTFH * PUTROOTFH
o LOOKUP "this" * LOOKUP "this"
o LOOKUP "is" * LOOKUP "is"
o LOOKUP "the" * LOOKUP "the"
o READDIR (rdattr_error, fs_locations_info, mounted_on_fileid, fsid, * READDIR (rdattr_error, fs_locations_info, mounted_on_fileid, fsid,
size, time_modify) size, time_modify)
The results would be: The results would be:
o PUTROOTFH --> NFS_OK. The current fh is at the root of the * PUTROOTFH --> NFS_OK. The current fh is at the root of the
pseudo-fs. pseudo-fs.
o LOOKUP "this" --> NFS_OK. The current fh is for /this and is * LOOKUP "this" --> NFS_OK. The current fh is for /this and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is * LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and * LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and
is within the pseudo-fs. is within the pseudo-fs.
o READDIR (rdattr_error, fs_locations_info, mounted_on_fileid, fsid, * READDIR (rdattr_error, fs_locations_info, mounted_on_fileid, fsid,
size, time_modify) --> NFS_OK. The attributes will be as shown size, time_modify) --> NFS_OK. The attributes will be as shown
below. below.
The attributes for the directory entry with the component named The attributes for the directory entry with the component named
"path" will only contain: "path" will only contain:
o rdattr_error (value: NFS_OK) * rdattr_error (value: NFS_OK)
o fs_locations_info
o mounted_on_fileid (value: unique fileid within referring file * fs_locations_info
* mounted_on_fileid (value: unique fileid within referring file
system) system)
o fsid (value: unique value within referring server) * fsid (value: unique value within referring server)
The attributes for entry "path" will not contain size or time_modify The attributes for entry "path" will not contain size or time_modify
because these attributes are not available within an absent file because these attributes are not available within an absent file
system. system.
11.16. The Attribute fs_locations 11.16. The Attribute fs_locations
The fs_locations attribute is structured in the following way: The fs_locations attribute is structured in the following way:
struct fs_location4 { struct fs_location4 {
skipping to change at page 286, line 23 skipping to change at line 13715
Since the fs_locations attribute lacks information defining various Since the fs_locations attribute lacks information defining various
attributes of the various file system choices presented, it SHOULD attributes of the various file system choices presented, it SHOULD
only be interrogated and used when fs_locations_info is not only be interrogated and used when fs_locations_info is not
available. When fs_locations is used, information about the specific available. When fs_locations is used, information about the specific
locations should be assumed based on the following rules. locations should be assumed based on the following rules.
The following rules are general and apply irrespective of the The following rules are general and apply irrespective of the
context. context.
o All listed file system instances should be considered as of the * All listed file system instances should be considered as of the
same handle class, if and only if, the current fh_expire_type same handle class, if and only if, the current fh_expire_type
attribute does not include the FH4_VOL_MIGRATION bit. Note that attribute does not include the FH4_VOL_MIGRATION bit. Note that
in the case of referral, filehandle issues do not apply since in the case of referral, filehandle issues do not apply since
there can be no filehandles known within the current file system, there can be no filehandles known within the current file system,
nor is there any access to the fh_expire_type attribute on the nor is there any access to the fh_expire_type attribute on the
referring (absent) file system. referring (absent) file system.
o All listed file system instances should be considered as of the * All listed file system instances should be considered as of the
same fileid class if and only if the fh_expire_type attribute same fileid class if and only if the fh_expire_type attribute
indicates persistent filehandles and does not include the indicates persistent filehandles and does not include the
FH4_VOL_MIGRATION bit. Note that in the case of referral, fileid FH4_VOL_MIGRATION bit. Note that in the case of referral, fileid
issues do not apply since there can be no fileids known within the issues do not apply since there can be no fileids known within the
referring (absent) file system, nor is there any access to the referring (absent) file system, nor is there any access to the
fh_expire_type attribute. fh_expire_type attribute.
o All file system instances servers should be considered as of * All file system instances servers should be considered as of
different change classes. different change classes.
For other class assignments, handling of file system transitions For other class assignments, handling of file system transitions
depends on the reasons for the transition: depends on the reasons for the transition:
o When the transition is due to migration, that is, the client was * When the transition is due to migration, that is, the client was
directed to a new file system after receiving an NFS4ERR_MOVED directed to a new file system after receiving an NFS4ERR_MOVED
error, the target should be treated as being of the same write- error, the target should be treated as being of the same write-
verifier class as the source. verifier class as the source.
o When the transition is due to failover to another replica, that * When the transition is due to failover to another replica, that
is, the client selected another replica without receiving an is, the client selected another replica without receiving an
NFS4ERR_MOVED error, the target should be treated as being of a NFS4ERR_MOVED error, the target should be treated as being of a
different write-verifier class from the source. different write-verifier class from the source.
The specific choices reflect typical implementation patterns for The specific choices reflect typical implementation patterns for
failover and controlled migration, respectively. Since other choices failover and controlled migration, respectively. Since other choices
are possible and useful, this information is better obtained by using are possible and useful, this information is better obtained by using
fs_locations_info. When a server implementation needs to communicate fs_locations_info. When a server implementation needs to communicate
other choices, it MUST support the fs_locations_info attribute. other choices, it MUST support the fs_locations_info attribute.
See Section 21 for a discussion on the recommendations for the See Section 21 for a discussion on the recommendations for the
security flavor to be used by any GETATTR operation that requests the security flavor to be used by any GETATTR operation that requests the
"fs_locations" attribute. fs_locations attribute.
11.17. The Attribute fs_locations_info 11.17. The Attribute fs_locations_info
The fs_locations_info attribute is intended as a more functional The fs_locations_info attribute is intended as a more functional
replacement for the fs_locations attribute which will continue to replacement for the fs_locations attribute, which will continue to
exist and be supported. Clients can use it to get a more complete exist and be supported. Clients can use it to get a more complete
set of data about alternative file system locations, including set of data about alternative file system locations, including
additional network paths to access replicas in use and additional additional network paths to access replicas in use and additional
replicas. When the server does not support fs_locations_info, replicas. When the server does not support fs_locations_info,
fs_locations can be used to get a subset of the data. A server that fs_locations can be used to get a subset of the data. A server that
supports fs_locations_info MUST support fs_locations as well. supports fs_locations_info MUST support fs_locations as well.
There is additional data present in fs_locations_info, that is not There is additional data present in fs_locations_info that is not
available in fs_locations: available in fs_locations:
o Attribute continuity information. This information will allow a * Attribute continuity information. This information will allow a
client to select a replica that meets the transparency client to select a replica that meets the transparency
requirements of the applications accessing the data and to requirements of the applications accessing the data and to
leverage optimizations due to the server guarantees of attribute leverage optimizations due to the server guarantees of attribute
continuity (e.g., if the change attribute of a file of the file continuity (e.g., if the change attribute of a file of the file
system is continuous between multiple replicas, the client does system is continuous between multiple replicas, the client does
not have to invalidate the file's cache when switching to a not have to invalidate the file's cache when switching to a
different replica). different replica).
o File system identity information that indicates when multiple * File system identity information that indicates when multiple
replicas, from the client's point of view, correspond to the same replicas, from the client's point of view, correspond to the same
target file system, allowing them to be used interchangeably, target file system, allowing them to be used interchangeably,
without disruption, as distinct synchronized replicas of the same without disruption, as distinct synchronized replicas of the same
file data. file data.
Note that having two replicas with common identity information is Note that having two replicas with common identity information is
distinct from the case of two (trunked) paths to the same replica. distinct from the case of two (trunked) paths to the same replica.
o Information that will bear on the suitability of various replicas, * Information that will bear on the suitability of various replicas,
depending on the use that the client intends. For example, many depending on the use that the client intends. For example, many
applications need an absolutely up-to-date copy (e.g., those that applications need an absolutely up-to-date copy (e.g., those that
write), while others may only need access to the most up-to-date write), while others may only need access to the most up-to-date
copy reasonably available. copy reasonably available.
o Server-derived preference information for replicas, which can be * Server-derived preference information for replicas, which can be
used to implement load-balancing while giving the client the used to implement load-balancing while giving the client the
entire file system list to be used in case the primary fails. entire file system list to be used in case the primary fails.
The fs_locations_info attribute is structured similarly to the The fs_locations_info attribute is structured similarly to the
fs_locations attribute. A top-level structure (fs_locations_info4) fs_locations attribute. A top-level structure (fs_locations_info4)
contains the entire attribute including the root pathname of the file contains the entire attribute including the root pathname of the file
system and an array of lower-level structures that define replicas system and an array of lower-level structures that define replicas
that share a common rootpath on their respective servers. The lower- that share a common rootpath on their respective servers. The lower-
level structure in turn (fs_locations_item4) contains a specific level structure in turn (fs_locations_item4) contains a specific
pathname and information on one or more individual network access pathname and information on one or more individual network access
paths. For that last lowest level, fs_locations_info has an paths. For that last, lowest level, fs_locations_info has an
fs_locations_server4 structure that contains per-server-replica fs_locations_server4 structure that contains per-server-replica
information in addition to the file system location entry. This per- information in addition to the file system location entry. This per-
server-replica information includes a nominally opaque array, server-replica information includes a nominally opaque array,
fls_info, within which specific pieces of information are located at fls_info, within which specific pieces of information are located at
the specific indices listed below. the specific indices listed below.
Two fs_location_server4 entries that are within different Two fs_location_server4 entries that are within different
fs_location_item4 structures are never trunkable, while two entries fs_location_item4 structures are never trunkable, while two entries
within in the same fs_location_item4 structure might or might not be within in the same fs_location_item4 structure might or might not be
trunkable. Two entries that are trunkable will have identical trunkable. Two entries that are trunkable will have identical
skipping to change at page 290, line 49 skipping to change at line 13933
The data presented in the fs_locations_info attribute may be obtained The data presented in the fs_locations_info attribute may be obtained
by the server in any number of ways, including specification by the by the server in any number of ways, including specification by the
administrator or by current protocols for transferring data among administrator or by current protocols for transferring data among
replicas and protocols not yet developed. NFSv4.1 only defines how replicas and protocols not yet developed. NFSv4.1 only defines how
this information is presented by the server to the client. this information is presented by the server to the client.
11.17.1. The fs_locations_server4 Structure 11.17.1. The fs_locations_server4 Structure
The fs_locations_server4 structure consists of the following items in The fs_locations_server4 structure consists of the following items in
addition to the fls_server field which specifies a network address or addition to the fls_server field, which specifies a network address
set of addresses to be used to access the specified file system. or set of addresses to be used to access the specified file system.
Note that both of these items (i.e., fls_currency and flinfo) specify Note that both of these items (i.e., fls_currency and fls_info)
attributes of the file system replica and should not be different specify attributes of the file system replica and should not be
when there are multiple fs_locations_server4 structures for the same different when there are multiple fs_locations_server4 structures,
replica, each specifying a network path to the chosen replica. each specifying a network path to the chosen replica, for the same
replica.
When these values are different in two fs_locations_server4 When these values are different in two fs_locations_server4
structures, a client has no basis for choosing one over the other and structures, a client has no basis for choosing one over the other and
is best off simply ignoring both entries, whether these entries apply is best off simply ignoring both entries, whether these entries apply
to migration replication or referral. When there are more than two to migration replication or referral. When there are more than two
such entries, majority voting can be used to exclude a single such entries, majority voting can be used to exclude a single
erroneous entry from consideration. In the case in which trunking erroneous entry from consideration. In the case in which trunking
information is provided for a replica currently being accessed, the information is provided for a replica currently being accessed, the
additional trunked addresses can be ignored while access continues on additional trunked addresses can be ignored while access continues on
the address currently being used, even if the entry corresponding to the address currently being used, even if the entry corresponding to
that path might be considered invalid. that path might be considered invalid.
o An indication of how up-to-date the file system is (fls_currency) * An indication of how up-to-date the file system is (fls_currency)
in seconds. This value is relative to the master copy. A in seconds. This value is relative to the master copy. A
negative value indicates that the server is unable to give any negative value indicates that the server is unable to give any
reasonably useful value here. A value of zero indicates that the reasonably useful value here. A value of zero indicates that the
file system is the actual writable data or a reliably coherent and file system is the actual writable data or a reliably coherent and
fully up-to-date copy. Positive values indicate how out-of-date fully up-to-date copy. Positive values indicate how out-of-date
this copy can normally be before it is considered for update. this copy can normally be before it is considered for update.
Such a value is not a guarantee that such updates will always be Such a value is not a guarantee that such updates will always be
performed on the required schedule but instead serves as a hint performed on the required schedule but instead serves as a hint
about how far the copy of the data would be expected to be behind about how far the copy of the data would be expected to be behind
the most up-to-date copy. the most up-to-date copy.
o A counted array of one-byte values (fls_info) containing * A counted array of one-byte values (fls_info) containing
information about the particular file system instance. This data information about the particular file system instance. This data
includes general flags, transport capability flags, file system includes general flags, transport capability flags, file system
equivalence class information, and selection priority information. equivalence class information, and selection priority information.
The encoding will be discussed below. The encoding will be discussed below.
o The server string (fls_server). For the case of the replica * The server string (fls_server). For the case of the replica
currently being accessed (via GETATTR), a zero-length string MAY currently being accessed (via GETATTR), a zero-length string MAY
be used to indicate the current address being used for the RPC be used to indicate the current address being used for the RPC
call. The fls_server field can also be an IPv4 or IPv6 address, call. The fls_server field can also be an IPv4 or IPv6 address,
formatted the same way as an IPv4 or IPv6 address in the "server" formatted the same way as an IPv4 or IPv6 address in the "server"
field of the fs_location4 data type (see Section 11.16). field of the fs_location4 data type (see Section 11.16).
With the exception of the transport-flag field (at offset With the exception of the transport-flag field (at offset
FSLI4BX_TFLAGS with the fls_info array), all of this data defined in FSLI4BX_TFLAGS with the fls_info array), all of this data defined in
this specification applies to the replica specified by the entry, this specification applies to the replica specified by the entry,
rather that the specific network path used to access it. The rather than the specific network path used to access it. The
classification of data in extensions to this data is discussed below. classification of data in extensions to this data is discussed below.
Data within the fls_info array is in the form of 8-bit data items Data within the fls_info array is in the form of 8-bit data items
with constants giving the offsets within the array of various values with constants giving the offsets within the array of various values
describing this particular file system instance. This style of describing this particular file system instance. This style of
definition was chosen, in preference to explicit XDR structure definition was chosen, in preference to explicit XDR structure
definitions for these values, for a number of reasons. definitions for these values, for a number of reasons.
o The kinds of data in the fls_info array, representing flags, file * The kinds of data in the fls_info array, representing flags, file
system classes, and priorities among sets of file systems system classes, and priorities among sets of file systems
representing the same data, are such that 8 bits provide a quite representing the same data, are such that 8 bits provide a quite
acceptable range of values. Even where there might be more than acceptable range of values. Even where there might be more than
256 such file system instances, having more than 256 distinct 256 such file system instances, having more than 256 distinct
classes or priorities is unlikely. classes or priorities is unlikely.
o Explicit definition of the various specific data items within XDR * Explicit definition of the various specific data items within XDR
would limit expandability in that any extension within would would limit expandability in that any extension within would
require yet another attribute, leading to specification and require yet another attribute, leading to specification and
implementation clumsiness. In the context of the NFSv4 extension implementation clumsiness. In the context of the NFSv4 extension
model in effect at the time fs_locations_info was designed (i.e. model in effect at the time fs_locations_info was designed (i.e.,
that described in RFC5661 [65]), this would necessitate a new that which is described in RFC 5661 [66]), this would necessitate
minor version to effect any Standards Track extension to the data a new minor version to effect any Standards Track extension to the
in in fls_info. data in fls_info.
The set of fls_info data is subject to expansion in a future minor The set of fls_info data is subject to expansion in a future minor
version, or in a Standards Track RFC, within the context of a single version or in a Standards Track RFC within the context of a single
minor version. The server SHOULD NOT send and the client MUST NOT minor version. The server SHOULD NOT send and the client MUST NOT
use indices within the fls_info array or flag bits that are not use indices within the fls_info array or flag bits that are not
defined in Standards Track RFCs. defined in Standards Track RFCs.
In light of the new extension model defined in RFC8178 [66] and the In light of the new extension model defined in RFC 8178 [67] and the
fact that the individual items within fls_info are not explicitly fact that the individual items within fls_info are not explicitly
referenced in the XDR, the following practices should be followed referenced in the XDR, the following practices should be followed
when extending or otherwise changing the structure of the data when extending or otherwise changing the structure of the data
returned in fls_info within the scope of a single minor version. returned in fls_info within the scope of a single minor version:
o All extensions need to be described by Standards Track documents. * All extensions need to be described by Standards Track documents.
There is no need for such documents to be marked as updating There is no need for such documents to be marked as updating RFC
RFC5661 [65] or this document. 5661 [66] or this document.
o It needs to be made clear whether the information in any added * It needs to be made clear whether the information in any added
data items applies to the replica specified by the entry or to the data items applies to the replica specified by the entry or to the
specific network paths specified in the entry. specific network paths specified in the entry.
o There needs to be a reliable way defined to determine whether the * There needs to be a reliable way defined to determine whether the
server is aware of the extension. This may be based on the length server is aware of the extension. This may be based on the length
field of the fls_info array, but it is more flexible to provide field of the fls_info array, but it is more flexible to provide
fs-scope or server-scope attributes to indicate what extensions fs-scope or server-scope attributes to indicate what extensions
are provided. are provided.
This encoding scheme can be adapted to the specification of multi- This encoding scheme can be adapted to the specification of multi-
byte numeric values, even though none are currently defined. If byte numeric values, even though none are currently defined. If
extensions are made via Standards Track RFCs, multi-byte quantities extensions are made via Standards Track RFCs, multi-byte quantities
will be encoded as a range of bytes with a range of indices, with the will be encoded as a range of bytes with a range of indices, with the
byte interpreted in big-endian byte order. Further, any such index byte interpreted in big-endian byte order. Further, any such index
assignments will be constrained by the need for the relevant assignments will be constrained by the need for the relevant
quantities not to cross XDR word boundaries. quantities not to cross XDR word boundaries.
The fls_info array currently contains: The fls_info array currently contains:
o Two 8-bit flag fields, one devoted to general file-system * Two 8-bit flag fields, one devoted to general file-system
characteristics and a second reserved for transport-related characteristics and a second reserved for transport-related
capabilities. capabilities.
o Six 8-bit class values that define various file system equivalence * Six 8-bit class values that define various file system equivalence
classes as explained below. classes as explained below.
o Four 8-bit priority values that govern file system selection as * Four 8-bit priority values that govern file system selection as
explained below. explained below.
The general file system characteristics flag (at byte index The general file system characteristics flag (at byte index
FSLI4BX_GFLAGS) has the following bits defined within it: FSLI4BX_GFLAGS) has the following bits defined within it:
o FSLI4GF_WRITABLE indicates that this file system target is * FSLI4GF_WRITABLE indicates that this file system target is
writable, allowing it to be selected by clients that may need to writable, allowing it to be selected by clients that may need to
write on this file system. When the current file system instance write on this file system. When the current file system instance
is writable and is defined as of the same simultaneous use class is writable and is defined as of the same simultaneous use class
(as specified by the value at index FSLI4BX_CLSIMUL) to which the (as specified by the value at index FSLI4BX_CLSIMUL) to which the
client was previously writing, then it must incorporate within its client was previously writing, then it must incorporate within its
data any committed write made on the source file system instance. data any committed write made on the source file system instance.
See Section 11.11.6, which discusses the write-verifier class. See Section 11.11.6, which discusses the write-verifier class.
While there is no harm in not setting this flag for a file system While there is no harm in not setting this flag for a file system
that turns out to be writable, turning the flag on for a read-only that turns out to be writable, turning the flag on for a read-only
file system can cause problems for clients that select a migration file system can cause problems for clients that select a migration
or replication target based on the flag and then find themselves or replication target based on the flag and then find themselves
unable to write. unable to write.
o FSLI4GF_CUR_REQ indicates that this replica is the one on which * FSLI4GF_CUR_REQ indicates that this replica is the one on which
the request is being made. Only a single server entry may have the request is being made. Only a single server entry may have
this flag set and, in the case of a referral, no entry will have this flag set and, in the case of a referral, no entry will have
it set. Note that this flag might be set even if the request was it set. Note that this flag might be set even if the request was
made on a network access path different from any of those made on a network access path different from any of those
specified in the current entry. specified in the current entry.
o FSLI4GF_ABSENT indicates that this entry corresponds to an absent * FSLI4GF_ABSENT indicates that this entry corresponds to an absent
file system replica. It can only be set if FSLI4GF_CUR_REQ is file system replica. It can only be set if FSLI4GF_CUR_REQ is
set. When both such bits are set, it indicates that a file system set. When both such bits are set, it indicates that a file system
instance is not usable but that the information in the entry can instance is not usable but that the information in the entry can
be used to determine the sorts of continuity available when be used to determine the sorts of continuity available when
switching from this replica to other possible replicas. Since switching from this replica to other possible replicas. Since
this bit can only be true if FSLI4GF_CUR_REQ is true, the value this bit can only be true if FSLI4GF_CUR_REQ is true, the value
could be determined using the fs_status attribute, but the could be determined using the fs_status attribute, but the
information is also made available here for the convenience of the information is also made available here for the convenience of the
client. An entry with this bit, since it represents a true file client. An entry with this bit, since it represents a true file
system (albeit absent), does not appear in the event of a system (albeit absent), does not appear in the event of a
referral, but only when a file system has been accessed at this referral, but only when a file system has been accessed at this
location and has subsequently been migrated. location and has subsequently been migrated.
o FSLI4GF_GOING indicates that a replica, while still available, * FSLI4GF_GOING indicates that a replica, while still available,
should not be used further. The client, if using it, should make should not be used further. The client, if using it, should make
an orderly transfer to another file system instance as an orderly transfer to another file system instance as
expeditiously as possible. It is expected that file systems going expeditiously as possible. It is expected that file systems going
out of service will be announced as FSLI4GF_GOING some time before out of service will be announced as FSLI4GF_GOING some time before
the actual loss of service. It is also expected that the the actual loss of service. It is also expected that the
fli_valid_for value will be sufficiently small to allow clients to fli_valid_for value will be sufficiently small to allow clients to
detect and act on scheduled events, while large enough that the detect and act on scheduled events, while large enough that the
cost of the requests to fetch the fs_locations_info values will cost of the requests to fetch the fs_locations_info values will
not be excessive. Values on the order of ten minutes seem not be excessive. Values on the order of ten minutes seem
reasonable. reasonable.
When this flag is seen as part of a transition into a new file When this flag is seen as part of a transition into a new file
system, a client might choose to transfer immediately to another system, a client might choose to transfer immediately to another
replica, or it may reference the current file system and only replica, or it may reference the current file system and only
transition when a migration event occurs. Similarly, when this transition when a migration event occurs. Similarly, when this
flag appears as a replica in the referral, clients would likely flag appears as a replica in the referral, clients would likely
avoid being referred to this instance whenever there is another avoid being referred to this instance whenever there is another
choice. choice.
This flag, like the other items within fls_info applies to the This flag, like the other items within fls_info, applies to the
replica, rather than to a particular path to that replica. When replica rather than to a particular path to that replica. When it
it appears, a transition to a new replica rather than to a appears, a transition to a new replica, rather than to a different
different path to the same replica, is indicated. path to the same replica, is indicated.
o FSLI4GF_SPLIT indicates that when a transition occurs from the * FSLI4GF_SPLIT indicates that when a transition occurs from the
current file system instance to this one, the replacement may current file system instance to this one, the replacement may
consist of multiple file systems. In this case, the client has to consist of multiple file systems. In this case, the client has to
be prepared for the possibility that objects on the same file be prepared for the possibility that objects on the same file
system before migration will be on different ones after. Note system before migration will be on different ones after. Note
that FSLI4GF_SPLIT is not incompatible with the file systems that FSLI4GF_SPLIT is not incompatible with the file systems
belonging to the same fileid class since, if one has a set of belonging to the same fileid class since, if one has a set of
fileids that are unique within a file system, each subset assigned fileids that are unique within a file system, each subset assigned
to a smaller file system after migration would not have any to a smaller file system after migration would not have any
conflicts internal to that file system. conflicts internal to that file system.
skipping to change at page 295, line 33 skipping to change at line 14158
the server to determine when the need for emulating two file the server to determine when the need for emulating two file
systems as one is over. systems as one is over.
Although it is possible for this flag to be present in the event Although it is possible for this flag to be present in the event
of referral, it would generally be of little interest to the of referral, it would generally be of little interest to the
client, since the client is not expected to have information client, since the client is not expected to have information
regarding the current contents of the absent file system. regarding the current contents of the absent file system.
The transport-flag field (at byte index FSLI4BX_TFLAGS) contains the The transport-flag field (at byte index FSLI4BX_TFLAGS) contains the
following bits related to the transport capabilities of the specific following bits related to the transport capabilities of the specific
network path(s) specified by the entry. network path(s) specified by the entry:
o FSLI4TF_RDMA indicates that any specified network paths provide * FSLI4TF_RDMA indicates that any specified network paths provide
NFSv4.1 clients access using an RDMA-capable transport. NFSv4.1 clients access using an RDMA-capable transport.
Attribute continuity and file system identity information are Attribute continuity and file system identity information are
expressed by defining equivalence relations on the sets of file expressed by defining equivalence relations on the sets of file
systems presented to the client. Each such relation is expressed as systems presented to the client. Each such relation is expressed as
a set of file system equivalence classes. For each relation, a file a set of file system equivalence classes. For each relation, a file
system has an 8-bit class number. Two file systems belong to the system has an 8-bit class number. Two file systems belong to the
same class if both have identical non-zero class numbers. Zero is same class if both have identical non-zero class numbers. Zero is
treated as non-matching. Most often, the relevant question for the treated as non-matching. Most often, the relevant question for the
client will be whether a given replica is identical to / continuous client will be whether a given replica is identical to / continuous
skipping to change at page 296, line 18 skipping to change at line 14191
to one another; conversely, file systems that have the specified to one another; conversely, file systems that have the specified
relationship to one another share a common class value. As each relationship to one another share a common class value. As each
instance entry is added, the relationships of this instance to instance entry is added, the relationships of this instance to
previously entered instances can be consulted, and if one is found previously entered instances can be consulted, and if one is found
that bears the specified relationship, that entry's class value can that bears the specified relationship, that entry's class value can
be copied to the new entry. When no such previous entry exists, a be copied to the new entry. When no such previous entry exists, a
new value for that byte index (not previously used) can be selected, new value for that byte index (not previously used) can be selected,
most likely by incrementing the value of the last class value most likely by incrementing the value of the last class value
assigned for that index. assigned for that index.
o The field with byte index FSLI4BX_CLSIMUL defines the * The field with byte index FSLI4BX_CLSIMUL defines the
simultaneous-use class for the file system. simultaneous-use class for the file system.
o The field with byte index FSLI4BX_CLHANDLE defines the handle * The field with byte index FSLI4BX_CLHANDLE defines the handle
class for the file system. class for the file system.
o The field with byte index FSLI4BX_CLFILEID defines the fileid * The field with byte index FSLI4BX_CLFILEID defines the fileid
class for the file system. class for the file system.
o The field with byte index FSLI4BX_CLWRITEVER defines the write- * The field with byte index FSLI4BX_CLWRITEVER defines the write-
verifier class for the file system. verifier class for the file system.
o The field with byte index FSLI4BX_CLCHANGE defines the change * The field with byte index FSLI4BX_CLCHANGE defines the change
class for the file system. class for the file system.
o The field with byte index FSLI4BX_CLREADDIR defines the readdir * The field with byte index FSLI4BX_CLREADDIR defines the readdir
class for the file system. class for the file system.
Server-specified preference information is also provided via 8-bit Server-specified preference information is also provided via 8-bit
values within the fls_info array. The values provide a rank and an values within the fls_info array. The values provide a rank and an
order (see below) to be used with separate values specifiable for the order (see below) to be used with separate values specifiable for the
cases of read-only and writable file systems. These values are cases of read-only and writable file systems. These values are
compared for different file systems to establish the server-specified compared for different file systems to establish the server-specified
preference, with lower values indicating "more preferred". preference, with lower values indicating "more preferred".
Rank is used to express a strict server-imposed ordering on clients, Rank is used to express a strict server-imposed ordering on clients,
skipping to change at page 297, line 15 skipping to change at line 14236
Within a rank, the order value is used to specify the server's Within a rank, the order value is used to specify the server's
preference to guide the client's selection when the client's own preference to guide the client's selection when the client's own
preferences are not controlling, with lower values of order preferences are not controlling, with lower values of order
indicating "more preferred". If replicas are approximately equal in indicating "more preferred". If replicas are approximately equal in
all respects, clients should defer to the order specified by the all respects, clients should defer to the order specified by the
server. When clients look at server latency as part of their server. When clients look at server latency as part of their
selection, they are free to use this criterion, but it is suggested selection, they are free to use this criterion, but it is suggested
that when latency differences are not significant, the server- that when latency differences are not significant, the server-
specified order should guide selection. specified order should guide selection.
o The field at byte index FSLI4BX_READRANK gives the rank value to * The field at byte index FSLI4BX_READRANK gives the rank value to
be used for read-only access. be used for read-only access.
o The field at byte index FSLI4BX_READORDER gives the order value to * The field at byte index FSLI4BX_READORDER gives the order value to
be used for read-only access. be used for read-only access.
o The field at byte index FSLI4BX_WRITERANK gives the rank value to * The field at byte index FSLI4BX_WRITERANK gives the rank value to
be used for writable access. be used for writable access.
o The field at byte index FSLI4BX_WRITEORDER gives the order value * The field at byte index FSLI4BX_WRITEORDER gives the order value
to be used for writable access. to be used for writable access.
Depending on the potential need for write access by a given client, Depending on the potential need for write access by a given client,
one of the pairs of rank and order values is used. The read rank and one of the pairs of rank and order values is used. The read rank and
order should only be used if the client knows that only reading will order should only be used if the client knows that only reading will
ever be done or if it is prepared to switch to a different replica in ever be done or if it is prepared to switch to a different replica in
the event that any write access capability is required in the future. the event that any write access capability is required in the future.
11.17.2. The fs_locations_info4 Structure 11.17.2. The fs_locations_info4 Structure
The fs_locations_info4 structure, encoding the fs_locations_info The fs_locations_info4 structure, encoding the fs_locations_info
attribute, contains the following: attribute, contains the following:
o The fli_flags field, which contains general flags that affect the * The fli_flags field, which contains general flags that affect the
interpretation of this fs_locations_info4 structure and all interpretation of this fs_locations_info4 structure and all
fs_locations_item4 structures within it. The only flag currently fs_locations_item4 structures within it. The only flag currently
defined is FSLI4IF_VAR_SUB. All bits in the fli_flags field that defined is FSLI4IF_VAR_SUB. All bits in the fli_flags field that
are not defined should always be returned as zero. are not defined should always be returned as zero.
o The fli_fs_root field, which contains the pathname of the root of * The fli_fs_root field, which contains the pathname of the root of
the current file system on the current server, just as it does in the current file system on the current server, just as it does in
the fs_locations4 structure. the fs_locations4 structure.
o An array called fli_items of fs_locations4_item structures, which * An array called fli_items of fs_locations4_item structures, which
contain information about replicas of the current file system. contain information about replicas of the current file system.
Where the current file system is actually present, or has been Where the current file system is actually present, or has been
present, i.e., this is not a referral situation, one of the present, i.e., this is not a referral situation, one of the
fs_locations_item4 structures will contain an fs_locations_server4 fs_locations_item4 structures will contain an fs_locations_server4
for the current server. This structure will have FSLI4GF_ABSENT for the current server. This structure will have FSLI4GF_ABSENT
set if the current file system is absent, i.e., normal access to set if the current file system is absent, i.e., normal access to
it will return NFS4ERR_MOVED. it will return NFS4ERR_MOVED.
o The fli_valid_for field specifies a time in seconds for which it * The fli_valid_for field specifies a time in seconds for which it
is reasonable for a client to use the fs_locations_info attribute is reasonable for a client to use the fs_locations_info attribute
without refetch. The fli_valid_for value does not provide a without refetch. The fli_valid_for value does not provide a
guarantee of validity since servers can unexpectedly go out of guarantee of validity since servers can unexpectedly go out of
service or become inaccessible for any number of reasons. Clients service or become inaccessible for any number of reasons. Clients
are well-advised to refetch this information for an actively are well-advised to refetch this information for an actively
accessed file system at every fli_valid_for seconds. This is accessed file system at every fli_valid_for seconds. This is
particularly important when file system replicas may go out of particularly important when file system replicas may go out of
service in a controlled way using the FSLI4GF_GOING flag to service in a controlled way using the FSLI4GF_GOING flag to
communicate an ongoing change. The server should set communicate an ongoing change. The server should set
fli_valid_for to a value that allows well-behaved clients to fli_valid_for to a value that allows well-behaved clients to
skipping to change at page 301, line 37 skipping to change at line 14442
the fs4_status reflects that last valid when the file system was the fs4_status reflects that last valid when the file system was
present. present.
The fss_type field indicates the kind of file system image The fss_type field indicates the kind of file system image
represented. This is of particular importance when using the version represented. This is of particular importance when using the version
values to determine appropriate succession of file system images. values to determine appropriate succession of file system images.
When fss_absent is set, and the file system was previously present, When fss_absent is set, and the file system was previously present,
the value of fss_type reflected is that when the file was last the value of fss_type reflected is that when the file was last
present. Five values are distinguished: present. Five values are distinguished:
o STATUS4_FIXED, which indicates a read-only image in the sense that * STATUS4_FIXED, which indicates a read-only image in the sense that
it will never change. The possibility is allowed that, as a it will never change. The possibility is allowed that, as a
result of migration or switch to a different image, changed data result of migration or switch to a different image, changed data
can be accessed, but within the confines of this instance, no can be accessed, but within the confines of this instance, no
change is allowed. The client can use this fact to cache change is allowed. The client can use this fact to cache
aggressively. aggressively.
o STATUS4_VERSIONED, which indicates that the image, like the * STATUS4_VERSIONED, which indicates that the image, like the
STATUS4_UPDATED case, is updated externally, but it provides a STATUS4_UPDATED case, is updated externally, but it provides a
guarantee that the server will carefully update an associated guarantee that the server will carefully update an associated
version value so that the client can protect itself from a version value so that the client can protect itself from a
situation in which it reads data from one version of the file situation in which it reads data from one version of the file
system and then later reads data from an earlier version of the system and then later reads data from an earlier version of the
same file system. See below for a discussion of how this can be same file system. See below for a discussion of how this can be
done. done.
o STATUS4_UPDATED, which indicates an image that cannot be updated * STATUS4_UPDATED, which indicates an image that cannot be updated
by the user writing to it but that may be changed externally, by the user writing to it but that may be changed externally,
typically because it is a periodically updated copy of another typically because it is a periodically updated copy of another
writable file system somewhere else. In this case, version writable file system somewhere else. In this case, version
information is not provided, and the client does not have the information is not provided, and the client does not have the
responsibility of making sure that this version only advances upon responsibility of making sure that this version only advances upon
a file system instance transition. In this case, it is the a file system instance transition. In this case, it is the
responsibility of the server to make sure that the data presented responsibility of the server to make sure that the data presented
after a file system instance transition is a proper successor after a file system instance transition is a proper successor
image and includes all changes seen by the client and any change image and includes all changes seen by the client and any change
made before all such changes. made before all such changes.
o STATUS4_WRITABLE, which indicates that the file system is an * STATUS4_WRITABLE, which indicates that the file system is an
actual writable one. The client need not, of course, actually actual writable one. The client need not, of course, actually
write to the file system, but once it does, it should not accept a write to the file system, but once it does, it should not accept a
transition to anything other than a writable instance of that same transition to anything other than a writable instance of that same
file system. file system.
o STATUS4_REFERRAL, which indicates that the file system in question * STATUS4_REFERRAL, which indicates that the file system in question
is absent and has never been present on this server. is absent and has never been present on this server.
Note that in the STATUS4_UPDATED and STATUS4_VERSIONED cases, the Note that in the STATUS4_UPDATED and STATUS4_VERSIONED cases, the
server is responsible for the appropriate handling of locks that are server is responsible for the appropriate handling of locks that are
inconsistent with external changes to delegations. If a server gives inconsistent with external changes to delegations. If a server gives
out delegations, they SHOULD be recalled before an inconsistent out delegations, they SHOULD be recalled before an inconsistent
change is made to the data, and MUST be revoked if this is not change is made to the data, and MUST be revoked if this is not
possible. Similarly, if an OPEN is inconsistent with data that is possible. Similarly, if an OPEN is inconsistent with data that is
changed (the OPEN has OPEN4_SHARE_DENY_WRITE/OPEN4_SHARE_DENY_BOTH changed (the OPEN has OPEN4_SHARE_DENY_WRITE/OPEN4_SHARE_DENY_BOTH
and the data is changed), that OPEN SHOULD be considered and the data is changed), that OPEN SHOULD be considered
skipping to change at page 305, line 23 skipping to change at line 14616
||| | ||| |
||| | ||| |
||| Storage +-----------+ | ||| Storage +-----------+ |
||| Protocol |+-----------+ | ||| Protocol |+-----------+ |
||+----------------||+-----------+ Control | ||+----------------||+-----------+ Control |
|+-----------------||| | Protocol| |+-----------------||| | Protocol|
+------------------+|| Storage |------------+ +------------------+|| Storage |------------+
+| Devices | +| Devices |
+-----------+ +-----------+
Figure 1 Figure 1
In this model, the clients, server, and storage devices are In this model, the clients, server, and storage devices are
responsible for managing file access. This is in contrast to NFSv4 responsible for managing file access. This is in contrast to NFSv4
without pNFS, where it is primarily the server's responsibility; some without pNFS, where it is primarily the server's responsibility; some
of this responsibility may be delegated to the client under strictly of this responsibility may be delegated to the client under strictly
specified conditions. See Section 12.2.5 for a discussion of the specified conditions. See Section 12.2.5 for a discussion of the
Storage Protocol. See Section 12.2.6 for a discussion of the Control Storage Protocol. See Section 12.2.6 for a discussion of the Control
Protocol. Protocol.
pNFS takes the form of OPTIONAL operations that manage protocol pNFS takes the form of OPTIONAL operations that manage protocol
skipping to change at page 307, line 15 skipping to change at line 14704
12.2.5. Storage Protocol 12.2.5. Storage Protocol
As noted in Figure 1, the storage protocol is the method used by the As noted in Figure 1, the storage protocol is the method used by the
client to store and retrieve data directly from the storage devices. client to store and retrieve data directly from the storage devices.
The NFSv4.1 pNFS feature has been structured to allow for a variety The NFSv4.1 pNFS feature has been structured to allow for a variety
of storage protocols to be defined and used. One example storage of storage protocols to be defined and used. One example storage
protocol is NFSv4.1 itself (as documented in Section 13). Other protocol is NFSv4.1 itself (as documented in Section 13). Other
options for the storage protocol are described elsewhere and include: options for the storage protocol are described elsewhere and include:
o Block/volume protocols such as Internet SCSI (iSCSI) [55] and FCP * Block/volume protocols such as Internet SCSI (iSCSI) [56] and FCP
[56]. The block/volume protocol support can be independent of the [57]. The block/volume protocol support can be independent of the
addressing structure of the block/volume protocol used, allowing addressing structure of the block/volume protocol used, allowing
more than one protocol to access the same file data and enabling more than one protocol to access the same file data and enabling
extensibility to other block/volume protocols. See [47] for a extensibility to other block/volume protocols. See [48] for a
layout specification that allows pNFS to use block/volume storage layout specification that allows pNFS to use block/volume storage
protocols. protocols.
o Object protocols such as OSD over iSCSI or Fibre Channel [57]. * Object protocols such as OSD over iSCSI or Fibre Channel [58].
See [46] for a layout specification that allows pNFS to use object See [47] for a layout specification that allows pNFS to use object
storage protocols. storage protocols.
It is possible that various storage protocols are available to both It is possible that various storage protocols are available to both
client and server and it may be possible that a client and server do client and server and it may be possible that a client and server do
not have a matching storage protocol available to them. Because of not have a matching storage protocol available to them. Because of
this, the pNFS server MUST support normal NFSv4.1 access to any file this, the pNFS server MUST support normal NFSv4.1 access to any file
accessible by the pNFS feature; this will allow for continued accessible by the pNFS feature; this will allow for continued
interoperability between an NFSv4.1 client and server. interoperability between an NFSv4.1 client and server.
12.2.6. Control Protocol 12.2.6. Control Protocol
skipping to change at page 307, line 51 skipping to change at line 14740
state required by the storage devices to perform client access state required by the storage devices to perform client access
control, and, depending on the storage protocol, the enforcement of control, and, depending on the storage protocol, the enforcement of
authentication and authorization so that restrictions that would be authentication and authorization so that restrictions that would be
enforced by the metadata server are also enforced by the storage enforced by the metadata server are also enforced by the storage
device. device.
A particular control protocol is not REQUIRED by NFSv4.1 but A particular control protocol is not REQUIRED by NFSv4.1 but
requirements are placed on the control protocol for maintaining requirements are placed on the control protocol for maintaining
attributes like modify time, the change attribute, and the end-of- attributes like modify time, the change attribute, and the end-of-
file (EOF) position. Note that if pNFS is layered over a clustered, file (EOF) position. Note that if pNFS is layered over a clustered,
parallel file system (e.g., PVFS [58]), the mechanisms that enable parallel file system (e.g., PVFS [59]), the mechanisms that enable
clustering and parallelism in that file system can be considered the clustering and parallelism in that file system can be considered the
control protocol. control protocol.
12.2.7. Layout Types 12.2.7. Layout Types
A layout describes the mapping of a file's data to the storage A layout describes the mapping of a file's data to the storage
devices that hold the data. A layout is said to belong to a specific devices that hold the data. A layout is said to belong to a specific
layout type (data type layouttype4, see Section 3.3.13). The layout layout type (data type layouttype4, see Section 3.3.13). The layout
type allows for variants to handle different storage protocols, such type allows for variants to handle different storage protocols, such
as those associated with block/volume [47], object [46], and file as those associated with block/volume [48], object [47], and file
(Section 13) layout types. A metadata server, along with its control (Section 13) layout types. A metadata server, along with its control
protocol, MUST support at least one layout type. A private sub-range protocol, MUST support at least one layout type. A private sub-range
of the layout type namespace is also defined. Values from the of the layout type namespace is also defined. Values from the
private layout type range MAY be used for internal testing or private layout type range MAY be used for internal testing or
experimentation (see Section 3.3.13). experimentation (see Section 3.3.13).
As an example, the organization of the file layout type could be an As an example, the organization of the file layout type could be an
array of tuples (e.g., device ID, filehandle), along with a array of tuples (e.g., device ID, filehandle), along with a
definition of how the data is stored across the devices (e.g., definition of how the data is stored across the devices (e.g.,
striping). A block/volume layout might be an array of tuples that striping). A block/volume layout might be an array of tuples that
skipping to change at page 311, line 4 skipping to change at line 14883
The NFSv4.1 protocol has no optimal way to recall all layouts that The NFSv4.1 protocol has no optimal way to recall all layouts that
referred to a particular device ID (unless the server associates a referred to a particular device ID (unless the server associates a
single device ID with a single fsid or a single client ID; in which single device ID with a single fsid or a single client ID; in which
case, CB_LAYOUTRECALL has options for recalling all layouts case, CB_LAYOUTRECALL has options for recalling all layouts
associated with the fsid, client ID pair, or just the client ID). associated with the fsid, client ID pair, or just the client ID).
Via a notification mechanism (see Section 20.12), device ID to device Via a notification mechanism (see Section 20.12), device ID to device
address mappings can change over the duration of server operation address mappings can change over the duration of server operation
without recalling or revoking the layouts that refer to device ID. without recalling or revoking the layouts that refer to device ID.
The notification mechanism can also delete a device ID, but only if The notification mechanism can also delete a device ID, but only if
the client has no layouts referring to the device ID. A notification the client has no layouts referring to the device ID. A notification
of a change to a device ID to device address mapping will immediately of a change to a device ID to device address mapping will immediately
or eventually invalidate some or all of the device ID's mappings. or eventually invalidate some or all of the device ID's mappings.
The server MUST support notifications and the client must request The server MUST support notifications and the client must request
them before they can be used. For further information about the them before they can be used. For further information about the
notification types Section 20.12. notification types, see Section 20.12.
12.3. pNFS Operations 12.3. pNFS Operations
NFSv4.1 has several operations that are needed for pNFS servers, NFSv4.1 has several operations that are needed for pNFS servers,
regardless of layout type or storage protocol. These operations are regardless of layout type or storage protocol. These operations are
all sent to a metadata server and summarized here. While pNFS is an all sent to a metadata server and summarized here. While pNFS is an
OPTIONAL feature, if pNFS is implemented, some operations are OPTIONAL feature, if pNFS is implemented, some operations are
REQUIRED in order to comply with pNFS. See Section 17. REQUIRED in order to comply with pNFS. See Section 17.
These are the fore channel pNFS operations: These are the fore channel pNFS operations:
skipping to change at page 312, line 50 skipping to change at line 14974
file for which a layout is held does not necessarily conflict with file for which a layout is held does not necessarily conflict with
the holding of the layout that describes the file being modified. the holding of the layout that describes the file being modified.
Therefore, it is the requirement of the storage protocol or layout Therefore, it is the requirement of the storage protocol or layout
type that determines the necessary behavior. For example, block/ type that determines the necessary behavior. For example, block/
volume layout types require that the layout's iomode agree with the volume layout types require that the layout's iomode agree with the
type of I/O being performed. type of I/O being performed.
Depending upon the layout type and storage protocol in use, storage Depending upon the layout type and storage protocol in use, storage
device access permissions may be granted by LAYOUTGET and may be device access permissions may be granted by LAYOUTGET and may be
encoded within the type-specific layout. For an example of storage encoded within the type-specific layout. For an example of storage
device access permissions, see an object-based protocol such as [57]. device access permissions, see an object-based protocol such as [58].
If access permissions are encoded within the layout, the metadata If access permissions are encoded within the layout, the metadata
server SHOULD recall the layout when those permissions become invalid server SHOULD recall the layout when those permissions become invalid
for any reason -- for example, when a file becomes unwritable or for any reason -- for example, when a file becomes unwritable or
inaccessible to a client. Note, clients are still required to inaccessible to a client. Note, clients are still required to
perform the appropriate OPEN, LOCK, and ACCESS operations as perform the appropriate OPEN, LOCK, and ACCESS operations as
described above. The degree to which it is possible for the client described above. The degree to which it is possible for the client
to circumvent these operations and the consequences of doing so must to circumvent these operations and the consequences of doing so must
be clearly specified by the individual layout type specifications. be clearly specified by the individual layout type specifications.
In addition, these specifications must be clear about the In addition, these specifications must be clear about the
requirements and non-requirements for the checking performed by the requirements and non-requirements for the checking performed by the
skipping to change at page 314, line 25 skipping to change at line 15044
client can set at file creation time to provide a hint to the server client can set at file creation time to provide a hint to the server
for new files. Setting this attribute separately, after the file has for new files. Setting this attribute separately, after the file has
been created might make it difficult, or impossible, for the server been created might make it difficult, or impossible, for the server
implementation to comply. implementation to comply.
Because the EXCLUSIVE4 createmode4 does not allow the setting of Because the EXCLUSIVE4 createmode4 does not allow the setting of
attributes at file creation time, NFSv4.1 introduces the EXCLUSIVE4_1 attributes at file creation time, NFSv4.1 introduces the EXCLUSIVE4_1
createmode4, which does allow attributes to be set at file creation createmode4, which does allow attributes to be set at file creation
time. In addition, if the session is created with persistent reply time. In addition, if the session is created with persistent reply
caches, EXCLUSIVE4_1 is neither necessary nor allowed. Instead, caches, EXCLUSIVE4_1 is neither necessary nor allowed. Instead,
GUARDED4 both works better and is prescribed. Table 10 in GUARDED4 both works better and is prescribed. Table 18 in
Section 18.16.3 summarizes how a client is allowed to send an Section 18.16.3 summarizes how a client is allowed to send an
exclusive create. exclusive create.
12.5.3. Layout Stateid 12.5.3. Layout Stateid
As with all other stateids, the layout stateid consists of a "seqid" As with all other stateids, the layout stateid consists of a "seqid"
and "other" field. Once a layout stateid is established, the "other" and "other" field. Once a layout stateid is established, the "other"
field will stay constant unless the stateid is revoked or the client field will stay constant unless the stateid is revoked or the client
returns all layouts on the file and the server disposes of the returns all layouts on the file and the server disposes of the
stateid. The "seqid" field is initially set to one, and is never stateid. The "seqid" field is initially set to one, and is never
skipping to change at page 320, line 23 skipping to change at line 15329
12.5.5.1. Layout Recall Callback Robustness 12.5.5.1. Layout Recall Callback Robustness
It has been assumed thus far that pNFS client state (layout ranges It has been assumed thus far that pNFS client state (layout ranges
and iomode) for a file exactly matches that of the pNFS server for and iomode) for a file exactly matches that of the pNFS server for
that file. This assumption leads to the implication that any that file. This assumption leads to the implication that any
callback results in a LAYOUTRETURN or set of LAYOUTRETURNs that callback results in a LAYOUTRETURN or set of LAYOUTRETURNs that
exactly match the range in the callback, since both client and server exactly match the range in the callback, since both client and server
agree about the state being maintained. However, it can be useful if agree about the state being maintained. However, it can be useful if
this assumption does not always hold. For example: this assumption does not always hold. For example:
o If conflicts that require callbacks are very rare, and a server * If conflicts that require callbacks are very rare, and a server
can use a multi-file callback to recover per-client resources can use a multi-file callback to recover per-client resources
(e.g., via an FSID recall or a multi-file recall within a single (e.g., via an FSID recall or a multi-file recall within a single
CB_COMPOUND), the result may be significantly less client-server CB_COMPOUND), the result may be significantly less client-server
pNFS traffic. pNFS traffic.
o It may be useful for servers to maintain information about what * It may be useful for servers to maintain information about what
ranges are held by a client on a coarse-grained basis, leading to ranges are held by a client on a coarse-grained basis, leading to
the server's layout ranges being beyond those actually held by the the server's layout ranges being beyond those actually held by the
client. In the extreme, a server could manage conflicts on a per- client. In the extreme, a server could manage conflicts on a per-
file basis, only sending whole-file callbacks even though clients file basis, only sending whole-file callbacks even though clients
may request and be granted sub-file ranges. may request and be granted sub-file ranges.
o It may be useful for clients to "forget" details about what * It may be useful for clients to "forget" details about what
layouts and ranges the client actually has, leading to the layouts and ranges the client actually has, leading to the
server's layout ranges being beyond those that the client "thinks" server's layout ranges being beyond those that the client "thinks"
it has. As long as the client does not assume it has layouts that it has. As long as the client does not assume it has layouts that
are beyond what the server has granted, this is a safe practice. are beyond what the server has granted, this is a safe practice.
When a client forgets what ranges and layouts it has, and it When a client forgets what ranges and layouts it has, and it
receives a CB_LAYOUTRECALL operation, the client MUST follow up receives a CB_LAYOUTRECALL operation, the client MUST follow up
with a LAYOUTRETURN for what the server recalled, or alternatively with a LAYOUTRETURN for what the server recalled, or alternatively
return the NFS4ERR_NOMATCHING_LAYOUT error if it has no layout to return the NFS4ERR_NOMATCHING_LAYOUT error if it has no layout to
return in the recalled range. return in the recalled range.
o In order to avoid errors, it is vital that a client not assign * In order to avoid errors, it is vital that a client not assign
itself layout permissions beyond what the server has granted, and itself layout permissions beyond what the server has granted, and
that the server not forget layout permissions that have been that the server not forget layout permissions that have been
granted. On the other hand, if a server believes that a client granted. On the other hand, if a server believes that a client
holds a layout that the client does not know about, it is useful holds a layout that the client does not know about, it is useful
for the client to cleanly indicate completion of the requested for the client to cleanly indicate completion of the requested
recall either by sending a LAYOUTRETURN operation for the entire recall either by sending a LAYOUTRETURN operation for the entire
requested range or by returning an NFS4ERR_NOMATCHING_LAYOUT error requested range or by returning an NFS4ERR_NOMATCHING_LAYOUT error
to the CB_LAYOUTRECALL. to the CB_LAYOUTRECALL.
Thus, in light of the above, it is useful for a server to be able to Thus, in light of the above, it is useful for a server to be able to
skipping to change at page 325, line 49 skipping to change at line 15592
following, all arithmetic is the modulo arithmetic as described following, all arithmetic is the modulo arithmetic as described
above. above.
The server MUST support a minimum VALID_SEQID_RANGE. The minimum is The server MUST support a minimum VALID_SEQID_RANGE. The minimum is
defined as: VALID_SEQID_RANGE = summation over 1..N of defined as: VALID_SEQID_RANGE = summation over 1..N of
(ca_maxoperations(i) - 1), where N is the number of session fore (ca_maxoperations(i) - 1), where N is the number of session fore
channels and ca_maxoperations(i) is the value of the ca_maxoperations channels and ca_maxoperations(i) is the value of the ca_maxoperations
returned from CREATE_SESSION of the i'th session. The reason for "- returned from CREATE_SESSION of the i'th session. The reason for "-
1" is to allow for the required SEQUENCE operation. The server MAY 1" is to allow for the required SEQUENCE operation. The server MAY
support a VALID_SEQID_RANGE value larger than the minimum. The support a VALID_SEQID_RANGE value larger than the minimum. The
maximum VALID_SEQID_RANGE is (2 ^ 32 - 2) (accounting for zero not maximum VALID_SEQID_RANGE is (2^(32) - 2) (accounting for zero not
being a valid "seqid" value). being a valid "seqid" value).
If the server finds the "seqid" is zero, the NFS4ERR_BAD_STATEID If the server finds the "seqid" is zero, the NFS4ERR_BAD_STATEID
error is returned to the client. The server further validates the error is returned to the client. The server further validates the
"seqid" to ensure it is within the range of parallelism, "seqid" to ensure it is within the range of parallelism,
VALID_SEQID_RANGE. If the "seqid" value is outside of that range, VALID_SEQID_RANGE. If the "seqid" value is outside of that range,
the error NFS4ERR_OLD_STATEID is returned to the client. Upon the error NFS4ERR_OLD_STATEID is returned to the client. Upon
receipt of NFS4ERR_OLD_STATEID, the client updates the stateid in the receipt of NFS4ERR_OLD_STATEID, the client updates the stateid in the
layout request based on processing of other layout requests and re- layout request based on processing of other layout requests and re-
sends the operation to the server. sends the operation to the server.
skipping to change at page 328, line 22 skipping to change at line 15710
persistent, the client will use EXCLUSIVE4_1 for exclusive creates. persistent, the client will use EXCLUSIVE4_1 for exclusive creates.
If a file is to be created on a pNFS-enabled file system, the client If a file is to be created on a pNFS-enabled file system, the client
uses the OPEN operation. With the normal set of attributes that may uses the OPEN operation. With the normal set of attributes that may
be provided upon OPEN used for creation, there is an OPTIONAL be provided upon OPEN used for creation, there is an OPTIONAL
layout_hint attribute. The client's use of layout_hint allows the layout_hint attribute. The client's use of layout_hint allows the
client to express its preference for a layout type and its associated client to express its preference for a layout type and its associated
layout details. The use of a createmode4 of UNCHECKED4, GUARDED4, or layout details. The use of a createmode4 of UNCHECKED4, GUARDED4, or
EXCLUSIVE4_1 will allow the client to provide the layout_hint EXCLUSIVE4_1 will allow the client to provide the layout_hint
attribute at create time. The client MUST NOT use EXCLUSIVE4 (see attribute at create time. The client MUST NOT use EXCLUSIVE4 (see
Table 10). The client is RECOMMENDED to combine a GETATTR operation Table 18). The client is RECOMMENDED to combine a GETATTR operation
after the OPEN within the same COMPOUND. The GETATTR may then after the OPEN within the same COMPOUND. The GETATTR may then
retrieve the layout_type attribute for the newly created file. The retrieve the layout_type attribute for the newly created file. The
client will then know what layout type the server has chosen for the client will then know what layout type the server has chosen for the
file and therefore what storage protocol the client must use. file and therefore what storage protocol the client must use.
If the client wants to open an existing file, then it also includes a If the client wants to open an existing file, then it also includes a
GETATTR to determine what layout type the file supports. GETATTR to determine what layout type the file supports.
The GETATTR in either the file creation or plain file open case can The GETATTR in either the file creation or plain file open case can
also include the layout_blksize and layout_alignment attributes so also include the layout_blksize and layout_alignment attributes so
skipping to change at page 331, line 10 skipping to change at line 15834
storage device. Thus, the metadata server and/or storage devices are storage device. Thus, the metadata server and/or storage devices are
responsible for protecting themselves from I/Os that are both sent responsible for protecting themselves from I/Os that are both sent
before the lease expires and arrive after the lease expires. See before the lease expires and arrive after the lease expires. See
Section 12.7.3. Section 12.7.3.
12.7.3. Dealing with Loss of Layout State on the Metadata Server 12.7.3. Dealing with Loss of Layout State on the Metadata Server
This is a description of the case where all of the following are This is a description of the case where all of the following are
true: true:
o the metadata server has not restarted * the metadata server has not restarted
o a pNFS client's layouts have been discarded (usually because the * a pNFS client's layouts have been discarded (usually because the
client's lease expired) and are invalid client's lease expired) and are invalid
o an I/O from the pNFS client arrives at the storage device * an I/O from the pNFS client arrives at the storage device
The metadata server and its storage devices MUST solve this by The metadata server and its storage devices MUST solve this by
fencing the client. In other words, they MUST solve this by fencing the client. In other words, they MUST solve this by
preventing the execution of I/O operations from the client to the preventing the execution of I/O operations from the client to the
storage devices after layout state loss. The details of how fencing storage devices after layout state loss. The details of how fencing
is done are specific to the layout type. The solution for NFSv4.1 is done are specific to the layout type. The solution for NFSv4.1
file-based layouts is described in (Section 13.11), and solutions for file-based layouts is described in (Section 13.11), and solutions for
other layout types are in their respective external specification other layout types are in their respective external specification
documents. documents.
skipping to change at page 331, line 38 skipping to change at line 15862
The pNFS client will discover that the metadata server has restarted The pNFS client will discover that the metadata server has restarted
via the methods described in Section 8.4.2 and discussed in a pNFS- via the methods described in Section 8.4.2 and discussed in a pNFS-
specific context in Section 12.7.2, Paragraph 2. The client MUST specific context in Section 12.7.2, Paragraph 2. The client MUST
stop using layouts and delete the device ID to device address stop using layouts and delete the device ID to device address
mappings it previously received from the metadata server. Having mappings it previously received from the metadata server. Having
done that, if the client wrote data to the storage device without done that, if the client wrote data to the storage device without
committing the layouts via LAYOUTCOMMIT, then the client has committing the layouts via LAYOUTCOMMIT, then the client has
additional work to do in order to have the client, metadata server, additional work to do in order to have the client, metadata server,
and storage device(s) all synchronized on the state of the data. and storage device(s) all synchronized on the state of the data.
o If the client has data still modified and unwritten in the * If the client has data still modified and unwritten in the
client's memory, the client has only two choices. client's memory, the client has only two choices.
1. The client can obtain a layout via LAYOUTGET after the 1. The client can obtain a layout via LAYOUTGET after the
server's grace period and write the data to the storage server's grace period and write the data to the storage
devices. devices.
2. The client can WRITE that data through the metadata server 2. The client can WRITE that data through the metadata server
using the WRITE (Section 18.32) operation, and then obtain using the WRITE (Section 18.32) operation, and then obtain
layouts as desired. layouts as desired.
o If the client asynchronously wrote data to the storage device, but * If the client asynchronously wrote data to the storage device, but
still has a copy of the data in its memory, then it has available still has a copy of the data in its memory, then it has available
to it the recovery options listed above in the previous bullet to it the recovery options listed above in the previous bullet
point. If the metadata server is also in its grace period, the point. If the metadata server is also in its grace period, the
client has available to it the options below in the next bullet client has available to it the options below in the next bullet
point. point.
o The client does not have a copy of the data in its memory and the * The client does not have a copy of the data in its memory and the
metadata server is still in its grace period. The client cannot metadata server is still in its grace period. The client cannot
use LAYOUTGET (within or outside the grace period) to reclaim a use LAYOUTGET (within or outside the grace period) to reclaim a
layout because the contents of the response from LAYOUTGET may not layout because the contents of the response from LAYOUTGET may not
match what it had previously. The range might be different or the match what it had previously. The range might be different or the
client might get the same range but the content of the layout client might get the same range but the content of the layout
might be different. Even if the content of the layout appears to might be different. Even if the content of the layout appears to
be the same, the device IDs may map to different device addresses, be the same, the device IDs may map to different device addresses,
and even if the device addresses are the same, the device and even if the device addresses are the same, the device
addresses could have been assigned to a different storage device. addresses could have been assigned to a different storage device.
The option of retrieving the data from the storage device and The option of retrieving the data from the storage device and
skipping to change at page 333, line 16 skipping to change at line 15937
rejects the LAYOUTCOMMIT operation and makes no changes to the rejects the LAYOUTCOMMIT operation and makes no changes to the
file system. However, any time LAYOUTCOMMIT with loca_reclaim file system. However, any time LAYOUTCOMMIT with loca_reclaim
TRUE fails, the pNFS client has lost all the data in the range TRUE fails, the pNFS client has lost all the data in the range
defined by <loca_offset, loca_length>. A client can defend defined by <loca_offset, loca_length>. A client can defend
against this risk by caching all data, whether written against this risk by caching all data, whether written
synchronously or asynchronously in its memory, and by not synchronously or asynchronously in its memory, and by not
releasing the cached data until a successful LAYOUTCOMMIT. This releasing the cached data until a successful LAYOUTCOMMIT. This
condition does not hold true for all layout types; for example, condition does not hold true for all layout types; for example,
file-based storage devices need not suffer from this limitation. file-based storage devices need not suffer from this limitation.
o The client does not have a copy of the data in its memory and the * The client does not have a copy of the data in its memory and the
metadata server is no longer in its grace period; i.e., the metadata server is no longer in its grace period; i.e., the
metadata server returns NFS4ERR_NO_GRACE. As with the scenario in metadata server returns NFS4ERR_NO_GRACE. As with the scenario in
the above bullet point, the failure of LAYOUTCOMMIT means the data the above bullet point, the failure of LAYOUTCOMMIT means the data
in the range <loca_offset, loca_length> lost. The defense against in the range <loca_offset, loca_length> lost. The defense against
the risk is the same -- cache all written data on the client until the risk is the same -- cache all written data on the client until
a successful LAYOUTCOMMIT. a successful LAYOUTCOMMIT.
12.7.5. Operations during Metadata Server Grace Period 12.7.5. Operations during Metadata Server Grace Period
Some of the recovery scenarios thus far noted that some operations Some of the recovery scenarios thus far noted that some operations
skipping to change at page 335, line 50 skipping to change at line 16066
misbehaving client obtaining unauthorized access is an important misbehaving client obtaining unauthorized access is an important
consideration in determining when it is appropriate to use such a consideration in determining when it is appropriate to use such a
pNFS configuration. Such layout types SHOULD NOT be used when pNFS configuration. Such layout types SHOULD NOT be used when
client-only access checks do not provide sufficient assurance that client-only access checks do not provide sufficient assurance that
NFSv4.1 access control is being applied correctly. (This is not a NFSv4.1 access control is being applied correctly. (This is not a
problem for the file layout type described in Section 13 because the problem for the file layout type described in Section 13 because the
storage access protocol for LAYOUT4_NFSV4_1_FILES is NFSv4.1, and storage access protocol for LAYOUT4_NFSV4_1_FILES is NFSv4.1, and
thus the security model for storage device access via thus the security model for storage device access via
LAYOUT4_NFSv4_1_FILES is the same as that of the metadata server.) LAYOUT4_NFSv4_1_FILES is the same as that of the metadata server.)
For handling of access control specific to a layout, the reader For handling of access control specific to a layout, the reader
should examine the layout specification, such as the NFSv4.1/file- should examine the layout specification, such as the NFSv4.1/
based layout (Section 13) of this document, the blocks layout [47], file-based layout (Section 13) of this document, the blocks layout
and objects layout [46]. [48], and objects layout [47].
13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type 13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type
This section describes the semantics and format of NFSv4.1 file-based This section describes the semantics and format of NFSv4.1 file-based
layouts for pNFS. NFSv4.1 file-based layouts use the layouts for pNFS. NFSv4.1 file-based layouts use the
LAYOUT4_NFSV4_1_FILES layout type. The LAYOUT4_NFSV4_1_FILES type LAYOUT4_NFSV4_1_FILES layout type. The LAYOUT4_NFSV4_1_FILES type
defines striping data across multiple NFSv4.1 data servers. defines striping data across multiple NFSv4.1 data servers.
13.1. Client ID and Session Considerations 13.1. Client ID and Session Considerations
Sessions are a REQUIRED feature of NFSv4.1, and this extends to both Sessions are a REQUIRED feature of NFSv4.1, and this extends to both
the metadata server and file-based (NFSv4.1-based) data servers. the metadata server and file-based (NFSv4.1-based) data servers.
The role a server plays in pNFS is determined by the result it The role a server plays in pNFS is determined by the result it
returns from EXCHANGE_ID. The roles are: returns from EXCHANGE_ID. The roles are:
o Metadata server (EXCHGID4_FLAG_USE_PNFS_MDS is set in the result * Metadata server (EXCHGID4_FLAG_USE_PNFS_MDS is set in the result
eir_flags). eir_flags).
o Data server (EXCHGID4_FLAG_USE_PNFS_DS). * Data server (EXCHGID4_FLAG_USE_PNFS_DS).
o Non-metadata server (EXCHGID4_FLAG_USE_NON_PNFS). This is an * Non-metadata server (EXCHGID4_FLAG_USE_NON_PNFS). This is an
NFSv4.1 server that does not support operations (e.g., LAYOUTGET) NFSv4.1 server that does not support operations (e.g., LAYOUTGET)
or attributes that pertain to pNFS. or attributes that pertain to pNFS.
The client MAY request zero or more of EXCHGID4_FLAG_USE_NON_PNFS, The client MAY request zero or more of EXCHGID4_FLAG_USE_NON_PNFS,
EXCHGID4_FLAG_USE_PNFS_DS, or EXCHGID4_FLAG_USE_PNFS_MDS, even though EXCHGID4_FLAG_USE_PNFS_DS, or EXCHGID4_FLAG_USE_PNFS_MDS, even though
some combinations (e.g., EXCHGID4_FLAG_USE_NON_PNFS | some combinations (e.g., EXCHGID4_FLAG_USE_NON_PNFS |
EXCHGID4_FLAG_USE_PNFS_MDS) are contradictory. However, the server EXCHGID4_FLAG_USE_PNFS_MDS) are contradictory. However, the server
MUST only return the following acceptable combinations: MUST only return the following acceptable combinations:
+---------------------------------------------------------+ +========================================================+
| Acceptable Results from EXCHANGE_ID | | Acceptable Results from EXCHANGE_ID |
+---------------------------------------------------------+ +========================================================+
| EXCHGID4_FLAG_USE_PNFS_MDS | | EXCHGID4_FLAG_USE_PNFS_MDS |
| EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_PNFS_DS | +--------------------------------------------------------+
| EXCHGID4_FLAG_USE_PNFS_DS | | EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_PNFS_DS |
| EXCHGID4_FLAG_USE_NON_PNFS | +--------------------------------------------------------+
| EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_NON_PNFS | | EXCHGID4_FLAG_USE_PNFS_DS |
+---------------------------------------------------------+ +--------------------------------------------------------+
| EXCHGID4_FLAG_USE_NON_PNFS |
+--------------------------------------------------------+
| EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_NON_PNFS |
+--------------------------------------------------------+
Table 8
As the above table implies, a server can have one or two roles. A As the above table implies, a server can have one or two roles. A
server can be both a metadata server and a data server, or it can be server can be both a metadata server and a data server, or it can be
both a data server and non-metadata server. In addition to returning both a data server and non-metadata server. In addition to returning
two roles in the EXCHANGE_ID's results, and thus serving both roles two roles in the EXCHANGE_ID's results, and thus serving both roles
via a common client ID, a server can serve two roles by returning a via a common client ID, a server can serve two roles by returning a
unique client ID and server owner for each role in each of two unique client ID and server owner for each role in each of two
EXCHANGE_ID results, with each result indicating each role. EXCHANGE_ID results, with each result indicating each role.
In the case of a server with concurrent pNFS roles that are served by In the case of a server with concurrent pNFS roles that are served by
skipping to change at page 342, line 46 skipping to change at line 16402
pattern start at offset zero. pattern start at offset zero.
5. nfl_fh_list: An array of data server filehandles for each list of 5. nfl_fh_list: An array of data server filehandles for each list of
data servers in each element of the nflda_multipath_ds_list data servers in each element of the nflda_multipath_ds_list
array. The number of elements in nfl_fh_list depends on whether array. The number of elements in nfl_fh_list depends on whether
sparse or dense packing is being used. sparse or dense packing is being used.
* If sparse packing is being used, the number of elements in * If sparse packing is being used, the number of elements in
nfl_fh_list MUST be one of three values: nfl_fh_list MUST be one of three values:
+ Zero. This means that filehandles used for each data - Zero. This means that filehandles used for each data
server are the same as the filehandle returned by the OPEN server are the same as the filehandle returned by the OPEN
operation from the metadata server. operation from the metadata server.
+ One. This means that every data server uses the same - One. This means that every data server uses the same
filehandle: what is specified in nfl_fh_list[0]. filehandle: what is specified in nfl_fh_list[0].
+ The same number of elements in nflda_multipath_ds_list. - The same number of elements in nflda_multipath_ds_list.
Thus, in this case, when sending an I/O operation to any Thus, in this case, when sending an I/O operation to any
data server in nflda_multipath_ds_list[X], the filehandle data server in nflda_multipath_ds_list[X], the filehandle
in nfl_fh_list[X] MUST be used. in nfl_fh_list[X] MUST be used.
See the discussion on sparse packing in Section 13.4.4. See the discussion on sparse packing in Section 13.4.4.
* If dense packing is being used, the number of elements in * If dense packing is being used, the number of elements in
nfl_fh_list MUST be the same as the number of elements in nfl_fh_list MUST be the same as the number of elements in
nflda_stripe_indices. Thus, when sending an I/O operation to nflda_stripe_indices. Thus, when sending an I/O operation to
any data server in any data server in
skipping to change at page 346, line 7 skipping to change at line 16550
nflda_multipath_ds_list[1] = { E } nflda_multipath_ds_list[1] = { E }
and and
nfl_fh_list[1] = { 0x87 } nfl_fh_list[1] = { 0x87 }
The client can thus write SU0 to { 0x87, { E } }. The client can thus write SU0 to { 0x87, { E } }.
The destinations of the first 13 storage units are: The destinations of the first 13 storage units are:
+-----+------------+--------------+ +=====+============+==============+
| SUi | filehandle | data servers | | SUi | filehandle | data servers |
+-----+------------+--------------+ +=====+============+==============+
| 0 | 87 | E | | 0 | 87 | E |
+-----+------------+--------------+
| 1 | 36 | A,B,C,D | | 1 | 36 | A,B,C,D |
+-----+------------+--------------+
| 2 | 67 | F,G | | 2 | 67 | F,G |
+-----+------------+--------------+
| 3 | 36 | A,B,C,D | | 3 | 36 | A,B,C,D |
| | | | +-----+------------+--------------+
+-----+------------+--------------+
| 4 | 87 | E | | 4 | 87 | E |
+-----+------------+--------------+
| 5 | 36 | A,B,C,D | | 5 | 36 | A,B,C,D |
+-----+------------+--------------+
| 6 | 67 | F,G | | 6 | 67 | F,G |
+-----+------------+--------------+
| 7 | 36 | A,B,C,D | | 7 | 36 | A,B,C,D |
| | | | +-----+------------+--------------+
+-----+------------+--------------+
| 8 | 87 | E | | 8 | 87 | E |
+-----+------------+--------------+
| 9 | 36 | A,B,C,D | | 9 | 36 | A,B,C,D |
+-----+------------+--------------+
| 10 | 67 | F,G | | 10 | 67 | F,G |
+-----+------------+--------------+
| 11 | 36 | A,B,C,D | | 11 | 36 | A,B,C,D |
| | | | +-----+------------+--------------+
+-----+------------+--------------+
| 12 | 87 | E | | 12 | 87 | E |
+-----+------------+--------------+ +-----+------------+--------------+
Table 9
13.4.3. Interpreting the File Layout Using Dense Packing 13.4.3. Interpreting the File Layout Using Dense Packing
When dense packing is used, the algorithm for determining the When dense 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:
stripe_count = number of elements in nflda_stripe_indices; stripe_count = number of elements in nflda_stripe_indices;
j = (SUi + nfl_first_stripe_index) % stripe_count; j = (SUi + nfl_first_stripe_index) % stripe_count;
skipping to change at page 349, line 5 skipping to change at line 16684
nfl_fh_list[3] = { 0x36 } nfl_fh_list[3] = { 0x36 }
The client can thus write SU1 to { 0x36, { A, B, C, D } }. The client can thus write SU1 to { 0x36, { A, B, C, D } }.
For SU3, j = (3 + 2) % 4 = 1, and nflda_stripe_indices[1] = 0. Then For SU3, j = (3 + 2) % 4 = 1, and nflda_stripe_indices[1] = 0. Then
nflda_multipath_ds_list[0] = { A, B, C, D }, and nfl_fh_list[1] = nflda_multipath_ds_list[0] = { A, B, C, D }, and nfl_fh_list[1] =
0x37. The client can thus write SU3 to { 0x37, { A, B, C, D } }. 0x37. The client can thus write SU3 to { 0x37, { A, B, C, D } }.
The destinations of the first 13 storage units are: The destinations of the first 13 storage units are:
+-----+------------+--------------+ +=====+============+==============+
| SUi | filehandle | data servers | | SUi | filehandle | data servers |
+-----+------------+--------------+ +=====+============+==============+
| 0 | 87 | E | | 0 | 87 | E |
+-----+------------+--------------+
| 1 | 36 | A,B,C,D | | 1 | 36 | A,B,C,D |
+-----+------------+--------------+
| 2 | 67 | F,G | | 2 | 67 | F,G |
+-----+------------+--------------+
| 3 | 37 | A,B,C,D | | 3 | 37 | A,B,C,D |
| | | | +-----+------------+--------------+
+-----+------------+--------------+
| 4 | 87 | E | | 4 | 87 | E |
+-----+------------+--------------+
| 5 | 36 | A,B,C,D | | 5 | 36 | A,B,C,D |
+-----+------------+--------------+
| 6 | 67 | F,G | | 6 | 67 | F,G |
+-----+------------+--------------+
| 7 | 37 | A,B,C,D | | 7 | 37 | A,B,C,D |
| | | | +-----+------------+--------------+
+-----+------------+--------------+
| 8 | 87 | E | | 8 | 87 | E |
+-----+------------+--------------+
| 9 | 36 | A,B,C,D | | 9 | 36 | A,B,C,D |
+-----+------------+--------------+
| 10 | 67 | F,G | | 10 | 67 | F,G |
+-----+------------+--------------+
| 11 | 37 | A,B,C,D | | 11 | 37 | A,B,C,D |
| | | | +-----+------------+--------------+
+-----+------------+--------------+
| 12 | 87 | E | | 12 | 87 | E |
+-----+------------+--------------+ +-----+------------+--------------+
Table 10
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 will 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.
skipping to change at page 350, line 19 skipping to change at line 16761
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 is being used, and the data server files have no holes. Dense
packing might be selected because the data server does not packing might be selected because the data server does not
(efficiently) support holey files or because the data server cannot (efficiently) support holey files or because the data server cannot
recognize read-ahead unless there are no holes. If dense packing is recognize read-ahead unless there are no holes. If dense packing is
indicated in the layout, the data files will be packed. Using the indicated in the layout, the data files will be packed. Using the
same striping pattern and stripe unit size that were used for the same striping pattern and stripe unit size that were used for the
sparse packing example, the corresponding dense packing example would sparse packing example, the corresponding dense packing example would
have all stripe units of all data files filled as follows: have all stripe units of all data files filled as follows:
o Logical stripe units 0, 3, 6, ... of the file would live on stripe * Logical stripe units 0, 3, 6, ... of the file would live on stripe
units 0, 1, 2, ... of the file of data server 1. units 0, 1, 2, ... of the file of data server 1.
o Logical stripe units 1, 4, 7, ... of the file would live on stripe * Logical stripe units 1, 4, 7, ... of the file would live on stripe
units 0, 1, 2, ... of the file of data server 2. units 0, 1, 2, ... of the file of data server 2.
o 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
pNFS client is allowed to write to any offset of any data file of any pNFS client is allowed to write to any offset of any data file of any
data server in the stripe. Thus, the data servers need not know the data server in the stripe. Thus, the data servers need not know the
file's striping pattern. file's striping pattern.
The calculation to determine the byte offset within the data file for The calculation to determine the byte offset within the data file for
dense data server layouts is: dense data server layouts is:
skipping to change at page 354, line 37 skipping to change at line 16971
The file layout provides two alternate means of providing for the The file layout provides two alternate means of providing for the
commit of data written through data servers. The flag commit of data written through data servers. The flag
NFL4_UFLG_COMMIT_THRU_MDS in the field nfl_util of the file layout NFL4_UFLG_COMMIT_THRU_MDS in the field nfl_util of the file layout
(data type nfsv4_1_file_layout4) is an indication from the metadata (data type nfsv4_1_file_layout4) is an indication from the metadata
server to the client of the REQUIRED way of performing COMMIT, either server to the client of the REQUIRED way of performing COMMIT, either
by sending the COMMIT to the data server or the metadata server. by sending the COMMIT to the data server or the metadata server.
These two methods of dealing with the issue correspond to broad These two methods of dealing with the issue correspond to broad
styles of implementation for a pNFS server supporting the file layout styles of implementation for a pNFS server supporting the file layout
type. type.
o When the flag is FALSE, COMMIT operations MUST to be sent to the * When the flag is FALSE, COMMIT operations MUST to be sent to the
data server to which the corresponding WRITE operations were sent. data server to which the corresponding WRITE operations were sent.
This approach is sometimes useful when file striping is This approach is sometimes useful when file striping is
implemented within the pNFS server (instead of the file system), implemented within the pNFS server (instead of the file system),
with the individual data servers each implementing their own file with the individual data servers each implementing their own file
systems. systems.
o When the flag is TRUE, COMMIT operations MUST be sent to the * When the flag is TRUE, COMMIT operations MUST be sent to the
metadata server, rather than to the individual data servers. This metadata server, rather than to the individual data servers. This
approach is sometimes useful when file striping is implemented approach is sometimes useful when file striping is implemented
within the clustered file system that is the backend to the pNFS within the clustered file system that is the backend to the pNFS
server. In such an implementation, each COMMIT to each data server. In such an implementation, each COMMIT to each data
server might result in repeated writes of metadata blocks to the server might result in repeated writes of metadata blocks to the
detriment of write performance. Sending a single COMMIT to the detriment of write performance. Sending a single COMMIT to the
metadata server can be more efficient when there exists a metadata server can be more efficient when there exists a
clustered file system capable of implementing such a coordinated clustered file system capable of implementing such a coordinated
COMMIT. COMMIT.
skipping to change at page 356, line 45 skipping to change at line 17075
Clients performing I/O operations need to select an appropriate Clients performing I/O operations need to select an appropriate
stateid based on the locks (including opens and delegations) held by stateid based on the locks (including opens and delegations) held by
the client and the various types of state-owners sending the I/O the client and the various types of state-owners sending the I/O
requests. The rules for doing so when referencing data servers are requests. The rules for doing so when referencing data servers are
somewhat different from those discussed in Section 8.2.5, which apply somewhat different from those discussed in Section 8.2.5, which apply
when accessing metadata servers. when accessing metadata servers.
The following rules, applied in order of decreasing priority, govern The following rules, applied in order of decreasing priority, govern
the selection of the appropriate stateid: the selection of the appropriate stateid:
o If the client holds a delegation for the file in question, the * If the client holds a delegation for the file in question, the
delegation stateid should be used. delegation stateid should be used.
o Otherwise, there must be an OPEN stateid for the current open- * Otherwise, there must be an OPEN stateid for the current open-
owner, and that OPEN stateid for the open file in question is owner, and that OPEN stateid for the open file in question is
used, unless mandatory locking prevents that. See below. used, unless mandatory locking prevents that. See below.
o If the data server had previously responded with NFS4ERR_LOCKED to * If the data server had previously responded with NFS4ERR_LOCKED to
use of the OPEN stateid, then the client should use the byte-range use of the OPEN stateid, then the client should use the byte-range
lock stateid whenever one exists for that open file with the lock stateid whenever one exists for that open file with the
current lock-owner. current lock-owner.
o Special stateids should never be used. If they are used, the data * Special stateids should never be used. If they are used, the data
server MUST reject the I/O with an NFS4ERR_BAD_STATEID error. server MUST reject the I/O with an NFS4ERR_BAD_STATEID error.
13.9.2. Data Server State Propagation 13.9.2. Data Server State Propagation
Since the metadata server, which handles byte-range lock and open- Since the metadata server, which handles byte-range lock and open-
mode state changes as well as ACLs, might not be co-located with the mode state changes as well as ACLs, might not be co-located with the
data servers where I/O accesses are validated, the server data servers where I/O accesses are validated, the server
implementation MUST take care of propagating changes of this state to implementation MUST take care of propagating changes of this state to
the data servers. Once the propagation to the data servers is the data servers. Once the propagation to the data servers is
complete, the full effect of those changes MUST be in effect at the complete, the full effect of those changes MUST be in effect at the
skipping to change at page 360, line 34 skipping to change at line 17255
additionally, make the data filehandle stale if the layout specified additionally, make the data filehandle stale if the layout specified
a data filehandle that is different from the metadata server's a data filehandle that is different from the metadata server's
filehandle for the file (see the nfl_fh_list description in filehandle for the file (see the nfl_fh_list description in
Section 13.3). Section 13.3).
Before the metadata server takes any action to revoke layout state Before the metadata server takes any action to revoke layout state
given out by a previous instance, it must make sure that all layout given out by a previous instance, it must make sure that all layout
state from that previous instance are invalidated at the data state from that previous instance are invalidated at the data
servers. This has the following implications. servers. This has the following implications.
o The metadata server must not restripe a file until it has * The metadata server must not restripe a file until it has
contacted all of the data servers to invalidate the layouts from contacted all of the data servers to invalidate the layouts from
the previous instance. the previous instance.
o The metadata server must not give out mandatory locks that * The metadata server must not give out mandatory locks that
conflict with layouts from the previous instance without either conflict with layouts from the previous instance without either
doing a specific layout invalidation (as it would have to do doing a specific layout invalidation (as it would have to do
anyway) or doing a global data server invalidation. anyway) or doing a global data server invalidation.
13.12. Security Considerations for the File Layout Type 13.12. Security Considerations for the File Layout Type
The NFSv4.1 file layout type MUST adhere to the security The NFSv4.1 file layout type MUST adhere to the security
considerations outlined in Section 12.9. NFSv4.1 data servers MUST considerations outlined in Section 12.9. NFSv4.1 data servers MUST
make all of the required access checks on each READ or WRITE I/O as make all of the required access checks on each READ or WRITE I/O as
determined by the NFSv4.1 protocol. If the metadata server would determined by the NFSv4.1 protocol. If the metadata server would
skipping to change at page 362, line 9 skipping to change at line 17324
that make sense for typical users throughout the world". A protocol that make sense for typical users throughout the world". A protocol
must define a profile of stringprep "in order to fully specify the must define a profile of stringprep "in order to fully specify the
processing options". The remainder of this section defines the processing options". The remainder of this section defines the
NFSv4.1 stringprep profiles. Much of the terminology used for the NFSv4.1 stringprep profiles. Much of the terminology used for the
remainder of this section comes from stringprep. remainder of this section comes from stringprep.
There are three UTF-8 string types defined for NFSv4.1: utf8str_cs, There are three UTF-8 string types defined for NFSv4.1: utf8str_cs,
utf8str_cis, and utf8str_mixed. Separate profiles are defined for utf8str_cis, and utf8str_mixed. Separate profiles are defined for
each. Each profile defines the following, as required by stringprep: each. Each profile defines the following, as required by stringprep:
o The intended applicability of the profile. * The intended applicability of the profile.
o The character repertoire that is the input and output to * The character repertoire that is the input and output to
stringprep (which is Unicode 3.2 for the referenced version of stringprep (which is Unicode 3.2 for the referenced version of
stringprep). However, NFSv4.1 implementations are not limited to stringprep). However, NFSv4.1 implementations are not limited to
3.2. 3.2.
o The mapping tables from stringprep used (as described in Section 3 * The mapping tables from stringprep used (as described in Section 3
of stringprep). of stringprep).
o Any additional mapping tables specific to the profile. * Any additional mapping tables specific to the profile.
o The Unicode normalization used, if any (as described in Section 4 * The Unicode normalization used, if any (as described in Section 4
of stringprep). of stringprep).
o The tables from the stringprep listing of characters that are * The tables from the stringprep listing of characters that are
prohibited as output (as described in Section 5 of stringprep). prohibited as output (as described in Section 5 of stringprep).
o The bidirectional string testing used, if any (as described in * The bidirectional string testing used, if any (as described in
Section 6 of stringprep). Section 6 of stringprep).
o Any additional characters that are prohibited as output specific * Any additional characters that are prohibited as output specific
to the profile. to the profile.
Stringprep discusses Unicode characters, whereas NFSv4.1 renders Stringprep discusses Unicode characters, whereas NFSv4.1 renders
UTF-8 characters. Since there is a one-to-one mapping from UTF-8 to UTF-8 characters. Since there is a one-to-one mapping from UTF-8 to
Unicode, when the remainder of this document refers to Unicode, the Unicode, when the remainder of this document refers to Unicode, the
reader should assume UTF-8. reader should assume UTF-8.
Much of the text for the profiles comes from RFC 3491 [20]. Much of the text for the profiles comes from RFC 3491 [20].
14.1. Stringprep Profile for the utf8str_cs Type 14.1. Stringprep Profile for the utf8str_cs Type
skipping to change at page 363, line 5 skipping to change at line 17369
14.1.1. Intended Applicability of the nfs4_cs_prep Profile 14.1.1. Intended Applicability of the nfs4_cs_prep Profile
The utf8str_cs type is a case-sensitive string of UTF-8 characters. The utf8str_cs type is a case-sensitive string of UTF-8 characters.
Its primary use in NFSv4.1 is for naming components and pathnames. Its primary use in NFSv4.1 is for naming components and pathnames.
Components and pathnames are stored on the server's file system. Two Components and pathnames are stored on the server's file system. Two
valid distinct UTF-8 strings might be the same after processing via valid distinct UTF-8 strings might be the same after processing via
the utf8str_cs profile. If the strings are two names inside a the utf8str_cs profile. If the strings are two names inside a
directory, the NFSv4.1 server will need to either: directory, the NFSv4.1 server will need to either:
o disallow the creation of a second name if its post-processed form * disallow the creation of a second name if its post-processed form
collides with that of an existing name, or collides with that of an existing name, or
o allow the creation of the second name, but arrange so that after * allow the creation of the second name, but arrange so that after
post-processing, the second name is different than the post- post-processing, the second name is different than the post-
processed form of the first name. processed form of the first name.
14.1.2. Character Repertoire of nfs4_cs_prep 14.1.2. Character Repertoire of nfs4_cs_prep
The nfs4_cs_prep profile uses Unicode 3.2, as defined in stringprep's The nfs4_cs_prep profile uses Unicode 3.2, as defined in stringprep's
Appendix A.1. However, NFSv4.1 implementations are not limited to Appendix A.1. However, NFSv4.1 implementations are not limited to
3.2. 3.2.
14.1.3. Mapping Used by nfs4_cs_prep 14.1.3. Mapping Used by nfs4_cs_prep
skipping to change at page 367, line 31 skipping to change at line 17577
arguments convert the strings to UTF-8. The second flag is arguments convert the strings to UTF-8. The second flag is
FSCHARSET_CAP4_ALLOWS_ONLY_UTF8, which, if set to one, indicates that FSCHARSET_CAP4_ALLOWS_ONLY_UTF8, which, if set to one, indicates that
the server will accept (and generate) only UTF-8 characters on the the server will accept (and generate) only UTF-8 characters on the
file system. If FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 is set to one, file system. If FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 is set to one,
FSCHARSET_CAP4_CONTAINS_NON_UTF8 MUST be set to zero. FSCHARSET_CAP4_CONTAINS_NON_UTF8 MUST be set to zero.
FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 SHOULD always be set to one. FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 SHOULD always be set to one.
14.5. UTF-8 Related Errors 14.5. UTF-8 Related Errors
Where the client sends an invalid UTF-8 string, the server should Where the client sends an invalid UTF-8 string, the server should
return NFS4ERR_INVAL (see Table 5). This includes cases in which return NFS4ERR_INVAL (see Table 11). This includes cases in which
inappropriate prefixes are detected and where the count includes inappropriate prefixes are detected and where the count includes
trailing bytes that do not constitute a full UCS character. trailing bytes that do not constitute a full UCS character.
Where the client-supplied string is valid UTF-8 but contains Where the client-supplied string is valid UTF-8 but contains
characters that are not supported by the server as a value for that characters that are not supported by the server as a value for that
string (e.g., names containing characters outside of Unicode plane 0 string (e.g., names containing characters outside of Unicode plane 0
on file systems that fail to support such characters despite their on file systems that fail to support such characters despite their
presence in the Unicode standard), the server should return presence in the Unicode standard), the server should return
NFS4ERR_BADCHAR. NFS4ERR_BADCHAR.
Where a UTF-8 string is used as a file name, and the file system Where a UTF-8 string is used as a file name, and the file system
(while supporting all of the characters within the name) does not (while supporting all of the characters within the name) does not
allow that particular name to be used, the server should return the allow that particular name to be used, the server should return the
error NFS4ERR_BADNAME (Table 5). This includes situations in which error NFS4ERR_BADNAME (Table 11). This includes situations in which
the server file system imposes a normalization constraint on name the server file system imposes a normalization constraint on name
strings, but will also include such situations as file system strings, but will also include such situations as file system
prohibitions of "." and ".." as file names for certain operations, prohibitions of "." and ".." as file names for certain operations,
and other such constraints. and other such constraints.
15. Error Values 15. Error Values
NFS error numbers are assigned to failed operations within a Compound NFS error numbers are assigned to failed operations within a Compound
(COMPOUND or CB_COMPOUND) request. A Compound request contains a (COMPOUND or CB_COMPOUND) request. A Compound request contains a
number of NFS operations that have their results encoded in sequence number of NFS operations that have their results encoded in sequence
in a Compound reply. The results of successful operations will in a Compound reply. The results of successful operations will
consist of an NFS4_OK status followed by the encoded results of the consist of an NFS4_OK status followed by the encoded results of the
operation. If an NFS operation fails, an error status will be operation. If an NFS operation fails, an error status will be
entered in the reply and the Compound request will be terminated. entered in the reply and the Compound request will be terminated.
15.1. Error Definitions 15.1. Error Definitions
Protocol Error Definitions +===================================+========+===================+
+-----------------------------------+--------+-------------------+
| Error | Number | Description | | Error | Number | Description |
+-----------------------------------+--------+-------------------+ +===================================+========+===================+
| NFS4_OK | 0 | Section 15.1.3.1 | | NFS4_OK | 0 | Section 15.1.3.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_ACCESS | 13 | Section 15.1.6.1 | | NFS4ERR_ACCESS | 13 | Section 15.1.6.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_ATTRNOTSUPP | 10032 | Section 15.1.15.1 | | NFS4ERR_ATTRNOTSUPP | 10032 | Section 15.1.15.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_ADMIN_REVOKED | 10047 | Section 15.1.5.1 | | NFS4ERR_ADMIN_REVOKED | 10047 | Section 15.1.5.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BACK_CHAN_BUSY | 10057 | Section 15.1.12.1 | | NFS4ERR_BACK_CHAN_BUSY | 10057 | Section 15.1.12.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADCHAR | 10040 | Section 15.1.7.1 | | NFS4ERR_BADCHAR | 10040 | Section 15.1.7.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADHANDLE | 10001 | Section 15.1.2.1 | | NFS4ERR_BADHANDLE | 10001 | Section 15.1.2.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADIOMODE | 10049 | Section 15.1.10.1 | | NFS4ERR_BADIOMODE | 10049 | Section 15.1.10.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADLAYOUT | 10050 | Section 15.1.10.2 | | NFS4ERR_BADLAYOUT | 10050 | Section 15.1.10.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADNAME | 10041 | Section 15.1.7.2 | | NFS4ERR_BADNAME | 10041 | Section 15.1.7.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADOWNER | 10039 | Section 15.1.15.2 | | NFS4ERR_BADOWNER | 10039 | Section 15.1.15.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADSESSION | 10052 | Section 15.1.11.1 | | NFS4ERR_BADSESSION | 10052 | Section 15.1.11.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADSLOT | 10053 | Section 15.1.11.2 | | NFS4ERR_BADSLOT | 10053 | Section 15.1.11.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADTYPE | 10007 | Section 15.1.4.1 | | NFS4ERR_BADTYPE | 10007 | Section 15.1.4.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BADXDR | 10036 | Section 15.1.1.1 | | NFS4ERR_BADXDR | 10036 | Section 15.1.1.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BAD_COOKIE | 10003 | Section 15.1.1.2 | | NFS4ERR_BAD_COOKIE | 10003 | Section 15.1.1.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BAD_HIGH_SLOT | 10077 | Section 15.1.11.3 | | NFS4ERR_BAD_HIGH_SLOT | 10077 | Section 15.1.11.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BAD_RANGE | 10042 | Section 15.1.8.1 | | NFS4ERR_BAD_RANGE | 10042 | Section 15.1.8.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BAD_SEQID | 10026 | Section 15.1.16.1 | | NFS4ERR_BAD_SEQID | 10026 | Section 15.1.16.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BAD_SESSION_DIGEST | 10051 | Section 15.1.12.2 | | NFS4ERR_BAD_SESSION_DIGEST | 10051 | Section 15.1.12.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_BAD_STATEID | 10025 | Section 15.1.5.2 | | NFS4ERR_BAD_STATEID | 10025 | Section 15.1.5.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_CB_PATH_DOWN | 10048 | Section 15.1.11.4 | | NFS4ERR_CB_PATH_DOWN | 10048 | Section 15.1.11.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_CLID_INUSE | 10017 | Section 15.1.13.2 | | NFS4ERR_CLID_INUSE | 10017 | Section 15.1.13.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_CLIENTID_BUSY | 10074 | Section 15.1.13.1 | | NFS4ERR_CLIENTID_BUSY | 10074 | Section 15.1.13.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_COMPLETE_ALREADY | 10054 | Section 15.1.9.1 | | NFS4ERR_COMPLETE_ALREADY | 10054 | Section 15.1.9.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_CONN_NOT_BOUND_TO_SESSION | 10055 | Section 15.1.11.6 | | NFS4ERR_CONN_NOT_BOUND_TO_SESSION | 10055 | Section 15.1.11.6 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_DEADLOCK | 10045 | Section 15.1.8.2 | | NFS4ERR_DEADLOCK | 10045 | Section 15.1.8.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_DEADSESSION | 10078 | Section 15.1.11.5 | | NFS4ERR_DEADSESSION | 10078 | Section 15.1.11.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_DELAY | 10008 | Section 15.1.1.3 | | NFS4ERR_DELAY | 10008 | Section 15.1.1.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_DELEG_ALREADY_WANTED | 10056 | Section 15.1.14.1 | | NFS4ERR_DELEG_ALREADY_WANTED | 10056 | Section 15.1.14.1 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_DELEG_REVOKED | 10087 | Section 15.1.5.3 | | NFS4ERR_DELEG_REVOKED | 10087 | Section 15.1.5.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_DENIED | 10010 | Section 15.1.8.3 | | NFS4ERR_DENIED | 10010 | Section 15.1.8.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_DIRDELEG_UNAVAIL | 10084 | Section 15.1.14.2 | | NFS4ERR_DIRDELEG_UNAVAIL | 10084 | Section 15.1.14.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_DQUOT | 69 | Section 15.1.4.2 | | NFS4ERR_DQUOT | 69 | Section 15.1.4.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_ENCR_ALG_UNSUPP | 10079 | Section 15.1.13.3 | | NFS4ERR_ENCR_ALG_UNSUPP | 10079 | Section 15.1.13.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_EXIST | 17 | Section 15.1.4.3 | | NFS4ERR_EXIST | 17 | Section 15.1.4.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_EXPIRED | 10011 | Section 15.1.5.4 | | NFS4ERR_EXPIRED | 10011 | Section 15.1.5.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_FBIG | 27 | Section 15.1.4.4 | | NFS4ERR_FBIG | 27 | Section 15.1.4.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_FHEXPIRED | 10014 | Section 15.1.2.2 | | NFS4ERR_FHEXPIRED | 10014 | Section 15.1.2.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_FILE_OPEN | 10046 | Section 15.1.4.5 | | NFS4ERR_FILE_OPEN | 10046 | Section 15.1.4.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_GRACE | 10013 | Section 15.1.9.2 | | NFS4ERR_GRACE | 10013 | Section 15.1.9.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_HASH_ALG_UNSUPP | 10072 | Section 15.1.13.4 | | NFS4ERR_HASH_ALG_UNSUPP | 10072 | Section 15.1.13.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_INVAL | 22 | Section 15.1.1.4 | | NFS4ERR_INVAL | 22 | Section 15.1.1.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_IO | 5 | Section 15.1.4.6 | | NFS4ERR_IO | 5 | Section 15.1.4.6 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_ISDIR | 21 | Section 15.1.2.3 | | NFS4ERR_ISDIR | 21 | Section 15.1.2.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_LAYOUTTRYLATER | 10058 | Section 15.1.10.3 | | NFS4ERR_LAYOUTTRYLATER | 10058 | Section 15.1.10.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_LAYOUTUNAVAILABLE | 10059 | Section 15.1.10.4 | | NFS4ERR_LAYOUTUNAVAILABLE | 10059 | Section 15.1.10.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_LEASE_MOVED | 10031 | Section 15.1.16.2 | | NFS4ERR_LEASE_MOVED | 10031 | Section 15.1.16.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_LOCKED | 10012 | Section 15.1.8.4 | | NFS4ERR_LOCKED | 10012 | Section 15.1.8.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_LOCKS_HELD | 10037 | Section 15.1.8.5 | | NFS4ERR_LOCKS_HELD | 10037 | Section 15.1.8.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_LOCK_NOTSUPP | 10043 | Section 15.1.8.6 | | NFS4ERR_LOCK_NOTSUPP | 10043 | Section 15.1.8.6 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_LOCK_RANGE | 10028 | Section 15.1.8.7 | | NFS4ERR_LOCK_RANGE | 10028 | Section 15.1.8.7 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_MINOR_VERS_MISMATCH | 10021 | Section 15.1.3.2 | | NFS4ERR_MINOR_VERS_MISMATCH | 10021 | Section 15.1.3.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_MLINK | 31 | Section 15.1.4.7 | | NFS4ERR_MLINK | 31 | Section 15.1.4.7 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_MOVED | 10019 | Section 15.1.2.4 | | NFS4ERR_MOVED | 10019 | Section 15.1.2.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NAMETOOLONG | 63 | Section 15.1.7.3 | | NFS4ERR_NAMETOOLONG | 63 | Section 15.1.7.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NOENT | 2 | Section 15.1.4.8 | | NFS4ERR_NOENT | 2 | Section 15.1.4.8 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NOFILEHANDLE | 10020 | Section 15.1.2.5 | | NFS4ERR_NOFILEHANDLE | 10020 | Section 15.1.2.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NOMATCHING_LAYOUT | 10060 | Section 15.1.10.5 | | NFS4ERR_NOMATCHING_LAYOUT | 10060 | Section 15.1.10.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NOSPC | 28 | Section 15.1.4.9 | | NFS4ERR_NOSPC | 28 | Section 15.1.4.9 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NOTDIR | 20 | Section 15.1.2.6 | | NFS4ERR_NOTDIR | 20 | Section 15.1.2.6 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NOTEMPTY | 66 | Section 15.1.4.10 | | NFS4ERR_NOTEMPTY | 66 | Section 15.1.4.10 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NOTSUPP | 10004 | Section 15.1.1.5 | | NFS4ERR_NOTSUPP | 10004 | Section 15.1.1.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NOT_ONLY_OP | 10081 | Section 15.1.3.3 | | NFS4ERR_NOT_ONLY_OP | 10081 | Section 15.1.3.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NOT_SAME | 10027 | Section 15.1.15.3 | | NFS4ERR_NOT_SAME | 10027 | Section 15.1.15.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NO_GRACE | 10033 | Section 15.1.9.3 | | NFS4ERR_NO_GRACE | 10033 | Section 15.1.9.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_NXIO | 6 | Section 15.1.16.3 | | NFS4ERR_NXIO | 6 | Section 15.1.16.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_OLD_STATEID | 10024 | Section 15.1.5.5 | | NFS4ERR_OLD_STATEID | 10024 | Section 15.1.5.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_OPENMODE | 10038 | Section 15.1.8.8 | | NFS4ERR_OPENMODE | 10038 | Section 15.1.8.8 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_OP_ILLEGAL | 10044 | Section 15.1.3.4 | | NFS4ERR_OP_ILLEGAL | 10044 | Section 15.1.3.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_OP_NOT_IN_SESSION | 10071 | Section 15.1.3.5 | | NFS4ERR_OP_NOT_IN_SESSION | 10071 | Section 15.1.3.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_PERM | 1 | Section 15.1.6.2 | | NFS4ERR_PERM | 1 | Section 15.1.6.2 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_PNFS_IO_HOLE | 10075 | Section 15.1.10.6 | | NFS4ERR_PNFS_IO_HOLE | 10075 | Section 15.1.10.6 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_PNFS_NO_LAYOUT | 10080 | Section 15.1.10.7 | | NFS4ERR_PNFS_NO_LAYOUT | 10080 | Section 15.1.10.7 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_RECALLCONFLICT | 10061 | Section 15.1.14.3 | | NFS4ERR_RECALLCONFLICT | 10061 | Section 15.1.14.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_RECLAIM_BAD | 10034 | Section 15.1.9.4 | | NFS4ERR_RECLAIM_BAD | 10034 | Section 15.1.9.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_RECLAIM_CONFLICT | 10035 | Section 15.1.9.5 | | NFS4ERR_RECLAIM_CONFLICT | 10035 | Section 15.1.9.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_REJECT_DELEG | 10085 | Section 15.1.14.4 | | NFS4ERR_REJECT_DELEG | 10085 | Section 15.1.14.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_REP_TOO_BIG | 10066 | Section 15.1.3.6 | | NFS4ERR_REP_TOO_BIG | 10066 | Section 15.1.3.6 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_REP_TOO_BIG_TO_CACHE | 10067 | Section 15.1.3.7 | | NFS4ERR_REP_TOO_BIG_TO_CACHE | 10067 | Section 15.1.3.7 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_REQ_TOO_BIG | 10065 | Section 15.1.3.8 | | NFS4ERR_REQ_TOO_BIG | 10065 | Section 15.1.3.8 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_RESTOREFH | 10030 | Section 15.1.16.4 | | NFS4ERR_RESTOREFH | 10030 | Section 15.1.16.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_RETRY_UNCACHED_REP | 10068 | Section 15.1.3.9 | | NFS4ERR_RETRY_UNCACHED_REP | 10068 | Section 15.1.3.9 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_RETURNCONFLICT | 10086 | Section 15.1.10.8 | | NFS4ERR_RETURNCONFLICT | 10086 | Section 15.1.10.8 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_ROFS | 30 | Section 15.1.4.11 | | NFS4ERR_ROFS | 30 | Section 15.1.4.11 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_SAME | 10009 | Section 15.1.15.4 | | NFS4ERR_SAME | 10009 | Section 15.1.15.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_SHARE_DENIED | 10015 | Section 15.1.8.9 | | NFS4ERR_SHARE_DENIED | 10015 | Section 15.1.8.9 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_SEQUENCE_POS | 10064 | Section 15.1.3.10 | | NFS4ERR_SEQUENCE_POS | 10064 | Section 15.1.3.10 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_SEQ_FALSE_RETRY | 10076 | Section 15.1.11.7 | | NFS4ERR_SEQ_FALSE_RETRY | 10076 | Section 15.1.11.7 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_SEQ_MISORDERED | 10063 | Section 15.1.11.8 | | NFS4ERR_SEQ_MISORDERED | 10063 | Section 15.1.11.8 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_SERVERFAULT | 10006 | Section 15.1.1.6 | | NFS4ERR_SERVERFAULT | 10006 | Section 15.1.1.6 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_STALE | 70 | Section 15.1.2.7 | | NFS4ERR_STALE | 70 | Section 15.1.2.7 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_STALE_CLIENTID | 10022 | Section 15.1.13.5 | | NFS4ERR_STALE_CLIENTID | 10022 | Section 15.1.13.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_STALE_STATEID | 10023 | Section 15.1.16.5 | | NFS4ERR_STALE_STATEID | 10023 | Section 15.1.16.5 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_SYMLINK | 10029 | Section 15.1.2.8 | | NFS4ERR_SYMLINK | 10029 | Section 15.1.2.8 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_TOOSMALL | 10005 | Section 15.1.1.7 | | NFS4ERR_TOOSMALL | 10005 | Section 15.1.1.7 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_TOO_MANY_OPS | 10070 | Section 15.1.3.11 | | NFS4ERR_TOO_MANY_OPS | 10070 | Section 15.1.3.11 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_UNKNOWN_LAYOUTTYPE | 10062 | Section 15.1.10.9 | | NFS4ERR_UNKNOWN_LAYOUTTYPE | 10062 | Section 15.1.10.9 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_UNSAFE_COMPOUND | 10069 | Section 15.1.3.12 | | NFS4ERR_UNSAFE_COMPOUND | 10069 | Section 15.1.3.12 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_WRONGSEC | 10016 | Section 15.1.6.3 | | NFS4ERR_WRONGSEC | 10016 | Section 15.1.6.3 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_WRONG_CRED | 10082 | Section 15.1.6.4 | | NFS4ERR_WRONG_CRED | 10082 | Section 15.1.6.4 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_WRONG_TYPE | 10083 | Section 15.1.2.9 | | NFS4ERR_WRONG_TYPE | 10083 | Section 15.1.2.9 |
+-----------------------------------+--------+-------------------+
| NFS4ERR_XDEV | 18 | Section 15.1.4.12 | | NFS4ERR_XDEV | 18 | Section 15.1.4.12 |
+-----------------------------------+--------+-------------------+ +-----------------------------------+--------+-------------------+
Table 5 Table 11: Protocol Error Definitions
15.1.1. General Errors 15.1.1. General Errors
This section deals with errors that are applicable to a broad set of This section deals with errors that are applicable to a broad set of
different purposes. different purposes.
15.1.1.1. NFS4ERR_BADXDR (Error Code 10036) 15.1.1.1. NFS4ERR_BADXDR (Error Code 10036)
The arguments for this operation do not match those specified in the The arguments for this operation do not match those specified in the
XDR definition. This includes situations in which the request ends XDR definition. This includes situations in which the request ends
skipping to change at page 371, line 15 skipping to change at line 17851
purpose, this error results. purpose, this error results.
15.1.1.3. NFS4ERR_DELAY (Error Code 10008) 15.1.1.3. NFS4ERR_DELAY (Error Code 10008)
For any of a number of reasons, the replier could not process this For any of a number of reasons, the replier could not process this
operation in what was deemed a reasonable time. The client should operation in what was deemed a reasonable time. The client should
wait and then try the request with a new slot and sequence value. wait and then try the request with a new slot and sequence value.
Some examples of scenarios that might lead to this situation: Some examples of scenarios that might lead to this situation:
o A server that supports hierarchical storage receives a request to * A server that supports hierarchical storage receives a request to
process a file that had been migrated. process a file that had been migrated.
o An operation requires a delegation recall to proceed, so that the * An operation requires a delegation recall to proceed, but the need
need to wait for this delegation to be recalled and returned makes to wait for this delegation to be recalled and returned makes
processing this request in a timely fashion impossible. processing this request in a timely fashion impossible.
o A request is being performed on a session being migrated from * A request is being performed on a session being migrated from
another server as described in Section 11.14.3, and the lack of another server as described in Section 11.14.3, and the lack of
full information about the state of the session on the source full information about the state of the session on the source
makes it impossible to process the request immediately. makes it impossible to process the request immediately.
In such cases, returning the error NFS4ERR_DELAY allows necessary In such cases, returning the error NFS4ERR_DELAY allows necessary
preparatory operations to proceed without holding up requester preparatory operations to proceed without holding up requester
resources such as a session slot. After delaying for period of time, resources such as a session slot. After delaying for period of time,
the client can then re-send the operation in question, often as part the client can then re-send the operation in question, often as part
of a nearly identical request. Because of the need to avoid spurious of a nearly identical request. Because of the need to avoid spurious
reissues of non-idempotent operations and to avoid acting in response reissues of non-idempotent operations and to avoid acting in response
to NFS4ERR_DELAY errors returned on responses returned from the to NFS4ERR_DELAY errors returned on responses returned from the
replier's replay cache, integration with the session-provided replay replier's reply cache, integration with the session-provided reply
cache is necessary. There are a number of cases to deal with, each cache is necessary. There are a number of cases to deal with, each
of which requires different sorts of handling by the requester and of which requires different sorts of handling by the requester and
replier: replier:
o If NFS4ERR_DELAY is returned on a SEQUENCE operation, the request * If NFS4ERR_DELAY is returned on a SEQUENCE operation, the request
is retried in full with the SEQUENCE operation containing the same is retried in full with the SEQUENCE operation containing the same
slot and sequence values. In this case, the replier MUST avoid slot and sequence values. In this case, the replier MUST avoid
returning a response containing NFS4ERR_DELAY as the response to returning a response containing NFS4ERR_DELAY as the response to
SEQUENCE solely on the basis of its presence in the replay cache. SEQUENCE solely because an earlier instance of the same request
If the replier did this, the retries would not be effective as returned that error and it was stored in the reply cache. If the
there would be no opportunity for the replier to see whether the replier did this, the retries would not be effective as there
would be no opportunity for the replier to see whether the
condition that generated the NFS4ERR_DELAY had been rectified condition that generated the NFS4ERR_DELAY had been rectified
during the interim between the original request and the retry. during the interim between the original request and the retry.
o If NFS4ERR_DELAY is returned on an operation other than SEQUENCE * If NFS4ERR_DELAY is returned on an operation other than SEQUENCE
which validly appears as the first operation of a request, that validly appears as the first operation of a request, the
handling is similar. The request can be retried in full without handling is similar. The request can be retried in full without
modification. In this case as well, the replier MUST avoid modification. In this case as well, the replier MUST avoid
returning a response containing NFS4ERR_DELAY as the response to returning a response containing NFS4ERR_DELAY as the response to
an initial operation of a request solely on the basis of its an initial operation of a request solely on the basis of its
presence in the replay cache. If the replier did this, the presence in the reply cache. If the replier did this, the retries
retries would not be effective as there would be no opportunity would not be effective as there would be no opportunity for the
for the replier to see whether the condition that generated the replier to see whether the condition that generated the
NFS4ERR_DELAY had been rectified during the interim between the NFS4ERR_DELAY had been rectified during the interim between the
original request and the retry. original request and the retry.
o If NFS4ERR_DELAY is returned on an operation other than the first * If NFS4ERR_DELAY is returned on an operation other than the first
in the request, the request when retried MUST contain a SEQUENCE in the request, the request when retried MUST contain a SEQUENCE
operation which is different than the original one, with either operation that is different than the original one, with either the
the bin id or the sequence value different from that in the slot ID or the sequence value different from that in the original
original request. Because requesters do this, there is no need request. Because requesters do this, there is no need for the
for the replier to take special care to avoid returning an replier to take special care to avoid returning an NFS4ERR_DELAY
NFS4ERR_DELAY error, obtained from the replay cache. When no non- error obtained from the reply cache. When no non-idempotent
idempotent operations have been processed before the NFS4ERR_DELAY operations have been processed before the NFS4ERR_DELAY was
was returned, the requester should retry the request in full, with returned, the requester should retry the request in full, with the
the only difference from the original request being the only difference from the original request being the modification
modification to the slot id or sequence value in the reissued to the slot ID or sequence value in the reissued SEQUENCE
SEQUENCE operation. operation.
o When NFS4ERR_DELAY is returned on an operation other than the * When NFS4ERR_DELAY is returned on an operation other than the
first within a request and there has been a non-idempotent first within a request and there has been a non-idempotent
operation processed before the NFS4ERR_DELAY was returned, operation processed before the NFS4ERR_DELAY was returned,
reissuing the request as is normally done would incorrectly cause reissuing the request as is normally done would incorrectly cause
the re-execution of the non-idempotent operation. the re-execution of the non-idempotent operation.
To avoid this situation, the client should reissue the request To avoid this situation, the client should reissue the request
without the non-idempotent operation. The request still must use without the non-idempotent operation. The request still must use
a SEQUENCE operation with either a different slot id or sequence a SEQUENCE operation with either a different slot ID or sequence
value from the SEQUENCE in the original request. Because this is value from the SEQUENCE in the original request. Because this is
done, there is no way the replier could avoid spuriously re- done, there is no way the replier could avoid spuriously re-
executing the non-idempotent operation since the different executing the non-idempotent operation since the different
SEQUENCE parameters prevent the requester from recognizing that SEQUENCE parameters prevent the requester from recognizing that
the non-idempotent operation is being retried. the non-idempotent operation is being retried.
Note that without the ability to return NFS4ERR_DELAY and the Note that without the ability to return NFS4ERR_DELAY and the
requester's willingness to re-send when receiving it, deadlock might requester's willingness to re-send when receiving it, deadlock might
result. For example, if a recall is done, and if the delegation result. For example, if a recall is done, and if the delegation
return or operations preparatory to delegation return are held up by return or operations preparatory to delegation return are held up by
skipping to change at page 373, line 45 skipping to change at line 17973
in which the filehandle is a valid filehandle in general but is not in which the filehandle is a valid filehandle in general but is not
of the appropriate object type for the current operation. of the appropriate object type for the current operation.
Where the error description indicates a problem with the current or Where the error description indicates a problem with the current or
saved filehandle, it is to be understood that filehandles are only saved filehandle, it is to be understood that filehandles are only
checked for the condition if they are implicit arguments of the checked for the condition if they are implicit arguments of the
operation in question. operation in question.
15.1.2.1. NFS4ERR_BADHANDLE (Error Code 10001) 15.1.2.1. NFS4ERR_BADHANDLE (Error Code 10001)
Illegal NFS filehandle for the current server. The current file Illegal NFS filehandle for the current server. The current
handle failed internal consistency checks. Once accepted as valid filehandle failed internal consistency checks. Once accepted as
(by PUTFH), no subsequent status change can cause the filehandle to valid (by PUTFH), no subsequent status change can cause the
generate this error. filehandle to generate this error.
15.1.2.2. NFS4ERR_FHEXPIRED (Error Code 10014) 15.1.2.2. NFS4ERR_FHEXPIRED (Error Code 10014)
A current or saved filehandle that is an argument to the current A current or saved filehandle that is an argument to the current
operation is volatile and has expired at the server. operation is volatile and has expired at the server.
15.1.2.3. NFS4ERR_ISDIR (Error Code 21) 15.1.2.3. NFS4ERR_ISDIR (Error Code 21)
The current or saved filehandle designates a directory when the The current or saved filehandle designates a directory when the
current operation does not allow a directory to be accepted as the current operation does not allow a directory to be accepted as the
target of this operation. target of this operation.
15.1.2.4. NFS4ERR_MOVED (Error Code 10019) 15.1.2.4. NFS4ERR_MOVED (Error Code 10019)
The file system that contains the current filehandle object is not The file system that contains the current filehandle object is not
present at the server, or is not accessible using the network address present at the server or is not accessible with the network address
used. It may have been made accessible on a different set of network used. It may have been made accessible on a different set of network
addresses, relocated or migrated to another server, or it may have addresses, relocated or migrated to another server, or it may have
never been present. The client may obtain the new file system never been present. The client may obtain the new file system
location by obtaining the "fs_locations" or "fs_locations_info" location by obtaining the fs_locations or fs_locations_info attribute
attribute for the current filehandle. For further discussion, refer for the current filehandle. For further discussion, refer to
to Section 11.3. Section 11.3.
As with the case of NFS4ERR_DELAY, it is possible that one or more As with the case of NFS4ERR_DELAY, it is possible that one or more
non-idempotent operations may have been successfully executed within non-idempotent operations may have been successfully executed within
a COMPOUND before NFS4ERR_MOVED is returned. Because of this, once a COMPOUND before NFS4ERR_MOVED is returned. Because of this, once
the new location is determined, the original request which received the new location is determined, the original request that received
the NFS4ERR_MOVED should not be re-executed in full. Instead, the the NFS4ERR_MOVED should not be re-executed in full. Instead, the
client should send a new COMPOUND, with any successfully executed client should send a new COMPOUND with any successfully executed non-
non-idempotent operations removed. When the client uses the same idempotent operations removed. When the client uses the same session
session for the new COMPOUND, its SEQUENCE operation should use a for the new COMPOUND, its SEQUENCE operation should use a different
different slot id or sequence. slot ID or sequence.
15.1.2.5. NFS4ERR_NOFILEHANDLE (Error Code 10020) 15.1.2.5. NFS4ERR_NOFILEHANDLE (Error Code 10020)
The logical current or saved filehandle value is required by the The logical current or saved filehandle value is required by the
current operation and is not set. This may be a result of a current operation and is not set. This may be a result of a
malformed COMPOUND operation (i.e., no PUTFH or PUTROOTFH before an malformed COMPOUND operation (i.e., no PUTFH or PUTROOTFH before an
operation that requires the current filehandle be set). operation that requires the current filehandle be set).
15.1.2.6. NFS4ERR_NOTDIR (Error Code 20) 15.1.2.6. NFS4ERR_NOTDIR (Error Code 20)
skipping to change at page 377, line 30 skipping to change at line 18140
feature. feature.
15.1.4.1. NFS4ERR_BADTYPE (Error Code 10007) 15.1.4.1. NFS4ERR_BADTYPE (Error Code 10007)
An attempt was made to create an object with an inappropriate type An attempt was made to create an object with an inappropriate type
specified to CREATE. This may be because the type is undefined, specified to CREATE. This may be because the type is undefined,
because the type is not supported by the server, or because the type because the type is not supported by the server, or because the type
is not intended to be created by CREATE (such as a regular file or is not intended to be created by CREATE (such as a regular file or
named attribute, for which OPEN is used to do the file creation). named attribute, for which OPEN is used to do the file creation).
15.1.4.2. NFS4ERR_DQUOT (Error Code 19) 15.1.4.2. NFS4ERR_DQUOT (Error Code 69)
Resource (quota) hard limit exceeded. The user's resource limit on Resource (quota) hard limit exceeded. The user's resource limit on
the server has been exceeded. the server has been exceeded.
15.1.4.3. NFS4ERR_EXIST (Error Code 17) 15.1.4.3. NFS4ERR_EXIST (Error Code 17)
A file of the specified target name (when creating, renaming, or A file of the specified target name (when creating, renaming, or
linking) already exists. linking) already exists.
15.1.4.4. NFS4ERR_FBIG (Error Code 27) 15.1.4.4. NFS4ERR_FBIG (Error Code 27)
skipping to change at page 378, line 40 skipping to change at line 18196
Indicates a read-only file system. A modifying operation was Indicates a read-only file system. A modifying operation was
attempted on a read-only file system. attempted on a read-only file system.
15.1.4.12. NFS4ERR_XDEV (Error Code 18) 15.1.4.12. NFS4ERR_XDEV (Error Code 18)
Indicates an attempt to do an operation, such as linking, that Indicates an attempt to do an operation, such as linking, that
inappropriately crosses a boundary. This may be due to such inappropriately crosses a boundary. This may be due to such
boundaries as: boundaries as:
o that between file systems (where the fsids are different). * that between file systems (where the fsids are different).
o that between different named attribute directories or between a * that between different named attribute directories or between a
named attribute directory and an ordinary directory. named attribute directory and an ordinary directory.
o that between byte-ranges of a file system that the file system * that between byte-ranges of a file system that the file system
implementation treats as separate (for example, for space implementation treats as separate (for example, for space
accounting purposes), and where cross-connection between the byte- accounting purposes), and where cross-connection between the byte-
ranges are not allowed. ranges are not allowed.
15.1.5. State Management Errors 15.1.5. State Management Errors
These errors indicate problems with the stateid (or one of the These errors indicate problems with the stateid (or one of the
stateids) passed to a given operation. This includes situations in stateids) passed to a given operation. This includes situations in
which the stateid is invalid as well as situations in which the which the stateid is invalid as well as situations in which the
stateid is valid but designates locking state that has been revoked. stateid is valid but designates locking state that has been revoked.
skipping to change at page 381, line 42 skipping to change at line 18335
condition, the client is encouraged to re-send the lock request (but condition, the client is encouraged to re-send the lock request (but
not with the same slot ID and sequence ID; one or both MUST be not with the same slot ID and sequence ID; one or both MUST be
different on the re-send) until the lock is accepted. See different on the re-send) until the lock is accepted. See
Section 9.6 for a discussion of the re-send. Section 9.6 for a discussion of the re-send.
15.1.8.4. NFS4ERR_LOCKED (Error Code 10012) 15.1.8.4. NFS4ERR_LOCKED (Error Code 10012)
A READ or WRITE operation was attempted on a file where there was a A READ or WRITE operation was attempted on a file where there was a
conflict between the I/O and an existing lock: conflict between the I/O and an existing lock:
o There is a share reservation inconsistent with the I/O being done. * There is a share reservation inconsistent with the I/O being done.
o The range to be read or written intersects an existing mandatory * The range to be read or written intersects an existing mandatory
byte-range lock. byte-range lock.
15.1.8.5. NFS4ERR_LOCKS_HELD (Error Code 10037) 15.1.8.5. NFS4ERR_LOCKS_HELD (Error Code 10037)
An operation was prevented by the unexpected presence of locks. An operation was prevented by the unexpected presence of locks.
15.1.8.6. NFS4ERR_LOCK_NOTSUPP (Error Code 10043) 15.1.8.6. NFS4ERR_LOCK_NOTSUPP (Error Code 10043)
A LOCK operation was attempted that would require the upgrade or A LOCK operation was attempted that would require the upgrade or
downgrade of a byte-range lock range already held by the owner, and downgrade of a byte-range lock range already held by the owner, and
skipping to change at page 382, line 50 skipping to change at line 18389
specifying the same scope, whether that scope is global or for the specifying the same scope, whether that scope is global or for the
same file system in the case of a per-fs RECLAIM_COMPLETE. An same file system in the case of a per-fs RECLAIM_COMPLETE. An
additional RECLAIM_COMPLETE operation is not necessary and results in additional RECLAIM_COMPLETE operation is not necessary and results in
this error. this error.
15.1.9.2. NFS4ERR_GRACE (Error Code 10013) 15.1.9.2. NFS4ERR_GRACE (Error Code 10013)
This error is returned when the server is in its grace period with This error is returned when the server is in its grace period with
regard to the file system object for which the lock was requested. regard to the file system object for which the lock was requested.
In this situation, a non-reclaim locking request cannot be granted. In this situation, a non-reclaim locking request cannot be granted.
This can occur because either This can occur because either:
o The server does not have sufficient information about locks that
* The server does not have sufficient information about locks that
might be potentially reclaimed to determine whether the lock could might be potentially reclaimed to determine whether the lock could
be granted. be granted.
o The request is made by a client responsible for reclaiming its * The request is made by a client responsible for reclaiming its
locks that has not yet done the appropriate RECLAIM_COMPLETE locks that has not yet done the appropriate RECLAIM_COMPLETE
operation, allowing it to proceed to obtain new locks. operation, allowing it to proceed to obtain new locks.
In the case of a per-fs grace period, there may be clients, (i.e., In the case of a per-fs grace period, there may be clients (i.e.,
those currently using the destination file system) who might be those currently using the destination file system) who might be
unaware of the circumstances resulting in the initiation of the grace unaware of the circumstances resulting in the initiation of the grace
period. Such clients need to periodically retry the request until period. Such clients need to periodically retry the request until
the grace period is over, just as other clients do. the grace period is over, just as other clients do.
15.1.9.3. NFS4ERR_NO_GRACE (Error Code 10033) 15.1.9.3. NFS4ERR_NO_GRACE (Error Code 10033)
A reclaim of client state was attempted in circumstances in which the A reclaim of client state was attempted in circumstances in which the
server cannot guarantee that conflicting state has not been provided server cannot guarantee that conflicting state has not been provided
to another client. This occurs in any of the following situations. to another client. This occurs in any of the following situations:
o There is no active grace period applying to the file system object * There is no active grace period applying to the file system object
for which the request was made. for which the request was made.
o The client making the request has no current role in reclaiming * The client making the request has no current role in reclaiming
locks. locks.
o Previous operations have created a situation in which the server * Previous operations have created a situation in which the server
is not able to determine that a reclaim-interfering edge condition is not able to determine that a reclaim-interfering edge condition
does not exist. does not exist.
15.1.9.4. NFS4ERR_RECLAIM_BAD (Error Code 10034) 15.1.9.4. NFS4ERR_RECLAIM_BAD (Error Code 10034)
The server has determined that a reclaim attempted by the client is The server has determined that a reclaim attempted by the client is
not valid, i.e. the lock specified as being reclaimed could not not valid, i.e., the lock specified as being reclaimed could not
possibly have existed before the server restart or file system possibly have existed before the server restart or file system
migration event. A server is not obliged to make this determination migration event. A server is not obliged to make this determination
and will typically rely on the client to only reclaim locks that the and will typically rely on the client to only reclaim locks that the
client was granted prior to restart. However, when a server does client was granted prior to restart. However, when a server does
have reliable information to enable it to make this determination, have reliable information to enable it to make this determination,
this error indicates that the reclaim has been rejected as invalid. this error indicates that the reclaim has been rejected as invalid.
This is as opposed to the error NFS4ERR_RECLAIM_CONFLICT (see This is as opposed to the error NFS4ERR_RECLAIM_CONFLICT (see
Section 15.1.9.5) where the server can only determine that there has Section 15.1.9.5) where the server can only determine that there has
been an invalid reclaim, but cannot determine which request is been an invalid reclaim, but cannot determine which request is
invalid. invalid.
skipping to change at page 389, line 10 skipping to change at line 18678
This error is returned by the NVERIFY operation to signify that the This error is returned by the NVERIFY operation to signify that the
attributes compared were the same as those provided in the client's attributes compared were the same as those provided in the client's
request. request.
15.1.16. Obsoleted Errors 15.1.16. Obsoleted Errors
These errors MUST NOT be generated by any NFSv4.1 operation. This These errors MUST NOT be generated by any NFSv4.1 operation. This
can be for a number of reasons. can be for a number of reasons.
o The function provided by the error has been superseded by one of * The function provided by the error has been superseded by one of
the status bits returned by the SEQUENCE operation. the status bits returned by the SEQUENCE operation.
o The new session structure and associated change in locking have * The new session structure and associated change in locking have
made the error unnecessary. made the error unnecessary.
o There has been a restructuring of some errors for NFSv4.1 that * There has been a restructuring of some errors for NFSv4.1 that
resulted in the elimination of certain errors. resulted in the elimination of certain errors.
15.1.16.1. NFS4ERR_BAD_SEQID (Error Code 10026) 15.1.16.1. NFS4ERR_BAD_SEQID (Error Code 10026)
The sequence number (seqid) in a locking request is neither the next The sequence number (seqid) in a locking request is neither the next
expected number or the last number processed. These seqids are expected number or the last number processed. These seqids are
ignored in NFSv4.1. ignored in NFSv4.1.
15.1.16.2. NFS4ERR_LEASE_MOVED (Error Code 10031) 15.1.16.2. NFS4ERR_LEASE_MOVED (Error Code 10031)
skipping to change at page 390, line 12 skipping to change at line 18726
instance is detected by the session infrastructure that supports instance is detected by the session infrastructure that supports
SEQUENCE. SEQUENCE.
15.2. Operations and Their Valid Errors 15.2. Operations and Their Valid Errors
This section contains a table that gives the valid error returns for This section contains a table that gives the valid error returns for
each protocol operation. The error code NFS4_OK (indicating no each protocol operation. The error code NFS4_OK (indicating no
error) is not listed but should be understood to be returnable by all error) is not listed but should be understood to be returnable by all
operations with two important exceptions: operations with two important exceptions:
o The operations that MUST NOT be implemented: OPEN_CONFIRM, * The operations that MUST NOT be implemented: OPEN_CONFIRM,
RELEASE_LOCKOWNER, RENEW, SETCLIENTID, and SETCLIENTID_CONFIRM. RELEASE_LOCKOWNER, RENEW, SETCLIENTID, and SETCLIENTID_CONFIRM.
o The invalid operation: ILLEGAL. * The invalid operation: ILLEGAL.
Valid Error Returns for Each Protocol Operation
+----------------------+--------------------------------------------+ +======================+========================================+
| Operation | Errors | | Operation | Errors |
+----------------------+--------------------------------------------+ +======================+========================================+
| ACCESS | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | | ACCESS | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | 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, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_TOO_MANY_OPS |
| | | +----------------------+----------------------------------------+
| BACKCHANNEL_CTL | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, | | BACKCHANNEL_CTL | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, | | | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_NOENT, NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_NOENT, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | | | | NFS4ERR_TOO_MANY_OPS |
| BIND_CONN_TO_SESSION | NFS4ERR_BADSESSION, NFS4ERR_BADXDR, | +----------------------+----------------------------------------+
| | NFS4ERR_BAD_SESSION_DIGEST, | | BIND_CONN_TO_SESSION | NFS4ERR_BADSESSION, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_BAD_SESSION_DIGEST, |
| | NFS4ERR_INVAL, NFS4ERR_NOT_ONLY_OP, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_INVAL, NFS4ERR_NOT_ONLY_OP, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | | | | NFS4ERR_SERVERFAULT, |
| CLOSE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, | | | NFS4ERR_TOO_MANY_OPS |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, | +----------------------+----------------------------------------+
| | NFS4ERR_DELAY, NFS4ERR_EXPIRED, | | CLOSE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_LOCKS_HELD, | | | NFS4ERR_BAD_STATEID, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_OLD_STATEID, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_LOCKS_HELD, NFS4ERR_MOVED, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_OLD_STATEID, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_CRED | | | NFS4ERR_REQ_TOO_BIG, |
| | | | | NFS4ERR_RETRY_UNCACHED_REP, |
| COMMIT | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_IO, | | | NFS4ERR_WRONG_CRED |
| | NFS4ERR_ISDIR, NFS4ERR_MOVED, | +----------------------+----------------------------------------+
| | NFS4ERR_NOFILEHANDLE, | | COMMIT | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_FHEXPIRED, NFS4ERR_IO, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_WRONG_TYPE | | | NFS4ERR_REQ_TOO_BIG, |
| | | | | NFS4ERR_RETRY_UNCACHED_REP, |
| CREATE | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADNAME, | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_BADOWNER, NFS4ERR_BADTYPE, | | | NFS4ERR_WRONG_TYPE |
| | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, | +----------------------+----------------------------------------+
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, | | CREATE | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, | | | NFS4ERR_BADCHAR, NFS4ERR_BADNAME, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MLINK, | | | NFS4ERR_BADOWNER, NFS4ERR_BADTYPE, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_NOTDIR, NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_MLINK, NFS4ERR_MOVED, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_NOTDIR, |
| | NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_UNSAFE_COMPOUND | | | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, |
| | | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| CREATE_SESSION | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_INVAL, NFS4ERR_NOENT, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_NOT_ONLY_OP, NFS4ERR_NOSPC, | | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_UNSAFE_COMPOUND |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | +----------------------+----------------------------------------+
| | NFS4ERR_REQ_TOO_BIG, | | CREATE_SESSION | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_SEQ_MISORDERED, | | | NFS4ERR_INVAL, NFS4ERR_NOENT, |
| | NFS4ERR_SERVERFAULT, | | | NFS4ERR_NOT_ONLY_OP, NFS4ERR_NOSPC, |
| | NFS4ERR_STALE_CLIENTID, NFS4ERR_TOOSMALL, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_CRED | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | | | | NFS4ERR_REQ_TOO_BIG, |
| DELEGPURGE | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_DELAY, NFS4ERR_NOTSUPP, | | | NFS4ERR_SEQ_MISORDERED, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_STALE_CLIENTID, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_TOOSMALL, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_WRONG_CRED |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS, | +----------------------+----------------------------------------+
| | NFS4ERR_WRONG_CRED | | DELEGPURGE | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, |
| | | | | NFS4ERR_DELAY, NFS4ERR_NOTSUPP, |
| DELEGRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_INVAL, NFS4ERR_MOVED, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_OLD_STATEID, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_WRONG_CRED |
| | NFS4ERR_REP_TOO_BIG, | +----------------------+----------------------------------------+
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | DELEGRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_BAD_STATEID, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_DELEG_REVOKED, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_CRED | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | | | | NFS4ERR_INVAL, NFS4ERR_MOVED, |
| DESTROY_CLIENTID | NFS4ERR_BADXDR, NFS4ERR_CLIENTID_BUSY, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_OLD_STATEID, |
| | NFS4ERR_NOT_ONLY_OP, NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_STALE_CLIENTID, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_CRED | | | NFS4ERR_TOO_MANY_OPS, |
| | | | | NFS4ERR_WRONG_CRED |
| DESTROY_SESSION | NFS4ERR_BACK_CHAN_BUSY, | +----------------------+----------------------------------------+
| | NFS4ERR_BADSESSION, NFS4ERR_BADXDR, | | DESTROY_CLIENTID | NFS4ERR_BADXDR, NFS4ERR_CLIENTID_BUSY, |
| | NFS4ERR_CB_PATH_DOWN, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_CONN_NOT_BOUND_TO_SESSION, | | | NFS4ERR_NOT_ONLY_OP, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_NOT_ONLY_OP, NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_SERVERFAULT, | | | NFS4ERR_STALE_CLIENTID, |
| | NFS4ERR_STALE_CLIENTID, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_CRED | | | NFS4ERR_WRONG_CRED |
| | | +----------------------+----------------------------------------+
| EXCHANGE_ID | NFS4ERR_BADCHAR, NFS4ERR_BADXDR, | | DESTROY_SESSION | NFS4ERR_BACK_CHAN_BUSY, |
| | NFS4ERR_CLID_INUSE, NFS4ERR_DEADSESSION, | | | NFS4ERR_BADSESSION, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_ENCR_ALG_UNSUPP, | | | NFS4ERR_CB_PATH_DOWN, |
| | NFS4ERR_HASH_ALG_UNSUPP, NFS4ERR_INVAL, | | | NFS4ERR_CONN_NOT_BOUND_TO_SESSION, |
| | NFS4ERR_NOENT, NFS4ERR_NOT_ONLY_OP, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_NOT_SAME, NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_NOT_ONLY_OP, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | | | | NFS4ERR_SERVERFAULT, |
| FREE_STATEID | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_STALE_CLIENTID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_LOCKS_HELD, NFS4ERR_OLD_STATEID, | | | NFS4ERR_WRONG_CRED |
| | NFS4ERR_OP_NOT_IN_SESSION, | +----------------------+----------------------------------------+
| | NFS4ERR_REP_TOO_BIG, | | EXCHANGE_ID | NFS4ERR_BADCHAR, NFS4ERR_BADXDR, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_CLID_INUSE, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_ENCR_ALG_UNSUPP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_HASH_ALG_UNSUPP, |
| | NFS4ERR_WRONG_CRED | | | NFS4ERR_INVAL, NFS4ERR_NOENT, |
| | | | | NFS4ERR_NOT_ONLY_OP, NFS4ERR_NOT_SAME, |
| GET_DIR_DELEGATION | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_DIRDELEG_UNAVAIL, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_TOO_MANY_OPS |
| | NFS4ERR_NOTSUPP, | +----------------------+----------------------------------------+
| | NFS4ERR_OP_NOT_IN_SESSION, | | FREE_STATEID | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_LOCKS_HELD, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_OLD_STATEID, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | | | | NFS4ERR_REQ_TOO_BIG, |
| GETATTR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_WRONG_CRED |
| | NFS4ERR_NOFILEHANDLE, | +----------------------+----------------------------------------+
| | NFS4ERR_OP_NOT_IN_SESSION, | | GET_DIR_DELEGATION | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_DIRDELEG_UNAVAIL, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE | | | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, |
| | | | | NFS4ERR_OP_NOT_IN_SESSION, |
| GETDEVICEINFO | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_NOENT, NFS4ERR_NOTSUPP, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_TOO_MANY_OPS |
| | NFS4ERR_REQ_TOO_BIG, | +----------------------+----------------------------------------+
| | NFS4ERR_RETRY_UNCACHED_REP, | | GETATTR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOOSMALL, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE | | | NFS4ERR_INVAL, NFS4ERR_IO, |
| | | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| GETDEVICELIST | NFS4ERR_BADXDR, NFS4ERR_BAD_COOKIE, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_IO, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_NOTSUPP, NFS4ERR_NOT_SAME, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_WRONG_TYPE |
| | NFS4ERR_REQ_TOO_BIG, | +----------------------+----------------------------------------+
| | NFS4ERR_RETRY_UNCACHED_REP, | | GETDEVICEINFO | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE | | | NFS4ERR_NOENT, NFS4ERR_NOTSUPP, |
| | | | | NFS4ERR_OP_NOT_IN_SESSION, |
| GETFH | NFS4ERR_FHEXPIRED, NFS4ERR_MOVED, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_STALE | | | NFS4ERR_REQ_TOO_BIG, |
| | | | | NFS4ERR_RETRY_UNCACHED_REP, |
| ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL | | | NFS4ERR_SERVERFAULT, NFS4ERR_TOOSMALL, |
| | | | | NFS4ERR_TOO_MANY_OPS, |
| LAYOUTCOMMIT | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE |
| | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADIOMODE, | +----------------------+----------------------------------------+
| | NFS4ERR_BADLAYOUT, NFS4ERR_BADXDR, | | GETDEVICELIST | NFS4ERR_BADXDR, NFS4ERR_BAD_COOKIE, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, | | | NFS4ERR_IO, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_NOTSUPP, NFS4ERR_NOT_SAME, |
| | NFS4ERR_ISDIR NFS4ERR_MOVED, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_NO_GRACE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RECLAIM_BAD, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_RECLAIM_CONFLICT, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE |
| | NFS4ERR_REQ_TOO_BIG, | +----------------------+----------------------------------------+
| | NFS4ERR_RETRY_UNCACHED_REP, | | GETFH | NFS4ERR_FHEXPIRED, NFS4ERR_MOVED, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_STALE |
| | NFS4ERR_WRONG_CRED | +----------------------+----------------------------------------+
| | | | ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL |
| LAYOUTGET | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | +----------------------+----------------------------------------+
| | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT, | | LAYOUTCOMMIT | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | | | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_LAYOUTTRYLATER, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, | | | NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_ISDIR NFS4ERR_MOVED, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_NO_GRACE, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_RECALLCONFLICT, | | | NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_RECLAIM_CONFLICT, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, |
| | | | | NFS4ERR_WRONG_CRED |
| LAYOUTRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, | +----------------------+----------------------------------------+
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, | | LAYOUTGET | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, | | | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_ISDIR, NFS4ERR_MOVED, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, | | | NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_LAYOUTTRYLATER, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_LAYOUTUNAVAILABLE, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_LOCKED, NFS4ERR_MOVED, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_OPENMODE, |
| | NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_RECALLCONFLICT, |
| | NFS4ERR_WRONG_CRED, NFS4ERR_WRONG_TYPE | | | NFS4ERR_REP_TOO_BIG, |
| | | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| LINK | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_BADNAME, NFS4ERR_BADXDR, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_DQUOT, NFS4ERR_EXIST, | | | NFS4ERR_TOOSMALL, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, |
| | NFS4ERR_ISDIR, NFS4ERR_IO, NFS4ERR_MLINK, | | | NFS4ERR_WRONG_TYPE |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | +----------------------+----------------------------------------+
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | LAYOUTRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, | | | NFS4ERR_BAD_STATEID, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_DELEG_REVOKED, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_WRONGSEC, NFS4ERR_WRONG_TYPE, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_XDEV | | | NFS4ERR_REP_TOO_BIG, |
| | | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| LOCK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_RANGE, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADLOCK, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_DENIED, NFS4ERR_EXPIRED, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_WRONG_CRED, NFS4ERR_WRONG_TYPE |
| | NFS4ERR_INVAL, NFS4ERR_ISDIR, | +----------------------+----------------------------------------+
| | NFS4ERR_LOCK_NOTSUPP, NFS4ERR_LOCK_RANGE, | | LINK | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_BADNAME, NFS4ERR_BADXDR, |
| | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_OPENMODE, | | | NFS4ERR_DQUOT, NFS4ERR_EXIST, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_RECLAIM_BAD, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_RECLAIM_CONFLICT, | | | NFS4ERR_ISDIR, NFS4ERR_IO, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_MLINK, NFS4ERR_MOVED, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_WRONG_CRED, NFS4ERR_WRONG_TYPE | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | | | | NFS4ERR_REQ_TOO_BIG, |
| LOCKT | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_BAD_RANGE, NFS4ERR_DEADSESSION, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_DELAY, NFS4ERR_DENIED, | | | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_INVAL, NFS4ERR_ISDIR, | | | NFS4ERR_WRONGSEC, NFS4ERR_WRONG_TYPE, |
| | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, | | | NFS4ERR_XDEV |
| | NFS4ERR_NOFILEHANDLE, | +----------------------+----------------------------------------+
| | NFS4ERR_OP_NOT_IN_SESSION, | | LOCK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_RANGE, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_BAD_STATEID, NFS4ERR_DEADLOCK, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_DENIED, NFS4ERR_EXPIRED, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_CRED, | | | NFS4ERR_INVAL, NFS4ERR_ISDIR, |
| | NFS4ERR_WRONG_TYPE | | | NFS4ERR_LOCK_NOTSUPP, |
| | | | | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, |
| LOCKU | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_RANGE, | | | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, | | | NFS4ERR_OPENMODE, |
| | NFS4ERR_DELAY, NFS4ERR_EXPIRED, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, | | | NFS4ERR_RECLAIM_CONFLICT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_CRED | | | NFS4ERR_WRONG_CRED, NFS4ERR_WRONG_TYPE |
| | | +----------------------+----------------------------------------+
| LOOKUP | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | LOCKT | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_BADNAME, NFS4ERR_BADXDR, | | | NFS4ERR_BAD_RANGE, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_DENIED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, | | | NFS4ERR_ISDIR, NFS4ERR_LOCK_RANGE, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | 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, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_ROFS, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONGSEC | | | NFS4ERR_WRONG_CRED, NFS4ERR_WRONG_TYPE |
| | | +----------------------+----------------------------------------+
| LOOKUPP | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, | | LOCKU | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_RANGE, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, | | | NFS4ERR_BAD_STATEID, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_INVAL, NFS4ERR_LOCK_RANGE, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_OLD_STATEID, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_WRONGSEC | | | NFS4ERR_REQ_TOO_BIG, |
| | | | | NFS4ERR_RETRY_UNCACHED_REP, |
| NVERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADXDR, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_WRONG_CRED |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | +----------------------+----------------------------------------+
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | LOOKUP | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_BADNAME, NFS4ERR_BADXDR, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_SAME, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_WRONG_TYPE | | | NFS4ERR_REQ_TOO_BIG, |
| | | | | NFS4ERR_RETRY_UNCACHED_REP, |
| OPEN | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_BADNAME, NFS4ERR_BADOWNER, | | | NFS4ERR_WRONGSEC |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | +----------------------+----------------------------------------+
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | LOOKUPP | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, |
| | NFS4ERR_DELEG_ALREADY_WANTED, | | | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | | | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_EXIST, NFS4ERR_EXPIRED, | | | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, | | | NFS4ERR_NOTDIR, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_ISDIR, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_NOTDIR, NFS4ERR_NO_GRACE, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_OLD_STATEID, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM, | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_RECLAIM_BAD, | | | NFS4ERR_WRONGSEC |
| | NFS4ERR_RECLAIM_CONFLICT, | +----------------------+----------------------------------------+
| | NFS4ERR_REP_TOO_BIG, | | NVERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_BADCHAR, NFS4ERR_BADXDR, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_SHARE_DENIED, | | | NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_UNSAFE_COMPOUND, NFS4ERR_WRONGSEC, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_WRONG_TYPE | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | | | | NFS4ERR_REQ_TOO_BIG, |
| OPEN_CONFIRM | NFS4ERR_NOTSUPP | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | | | | NFS4ERR_SAME, NFS4ERR_SERVERFAULT, |
| OPEN_DOWNGRADE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, | | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, |
| | NFS4ERR_DELAY, NFS4ERR_EXPIRED, | | | NFS4ERR_WRONG_TYPE |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | +----------------------+----------------------------------------+
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | OPEN | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_OLD_STATEID, | | | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_BADNAME, NFS4ERR_BADOWNER, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_DELEG_ALREADY_WANTED, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_EXIST, NFS4ERR_EXPIRED, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_CRED | | | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, |
| | | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| OPENATTR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | | | NFS4ERR_ISDIR, NFS4ERR_IO, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_DQUOT, NFS4ERR_FHEXPIRED, | | | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, | | | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_NOTSUPP, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_PERM, NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_RECLAIM_CONFLICT, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_UNSAFE_COMPOUND, | | | NFS4ERR_SHARE_DENIED, NFS4ERR_STALE, |
| | NFS4ERR_WRONG_TYPE | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | | | | NFS4ERR_UNSAFE_COMPOUND, |
| PUTFH | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, | | | NFS4ERR_WRONGSEC, NFS4ERR_WRONG_TYPE |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | +----------------------+----------------------------------------+
| | NFS4ERR_MOVED, NFS4ERR_OP_NOT_IN_SESSION, | | OPEN_CONFIRM | NFS4ERR_NOTSUPP |
| | NFS4ERR_REP_TOO_BIG, | +----------------------+----------------------------------------+
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | OPEN_DOWNGRADE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_BAD_STATEID, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONGSEC | | | NFS4ERR_INVAL, NFS4ERR_MOVED, |
| | | | | NFS4ERR_NOFILEHANDLE, |
| PUTPUBFH | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | 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, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_WRONGSEC | | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, |
| | | | | NFS4ERR_WRONG_CRED |
| PUTROOTFH | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | +----------------------+----------------------------------------+
| | NFS4ERR_OP_NOT_IN_SESSION, | | OPENATTR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_DQUOT, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, |
| | NFS4ERR_WRONGSEC | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | | | | NFS4ERR_REP_TOO_BIG, |
| READ | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_INVAL, NFS4ERR_ISDIR, NFS4ERR_IO, | | | NFS4ERR_UNSAFE_COMPOUND, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, | | | NFS4ERR_WRONG_TYPE |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, | +----------------------+----------------------------------------+
| | NFS4ERR_OPENMODE, | | PUTFH | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_PNFS_IO_HOLE, | | | NFS4ERR_MOVED, |
| | NFS4ERR_PNFS_NO_LAYOUT, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | 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, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONGSEC |
| | NFS4ERR_WRONG_TYPE | +----------------------+----------------------------------------+
| | | | PUTPUBFH | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| READDIR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_BAD_COOKIE, NFS4ERR_DEADSESSION, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_NOT_SAME, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONGSEC |
| | NFS4ERR_REP_TOO_BIG, | +----------------------+----------------------------------------+
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | PUTROOTFH | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_REQ_TOO_BIG, |
| | | | | NFS4ERR_RETRY_UNCACHED_REP, |
| READLINK | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, | | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONGSEC |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | +----------------------+----------------------------------------+
| | NFS4ERR_NOFILEHANDLE, | | READ | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_DELEG_REVOKED, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_ISDIR, NFS4ERR_IO, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE | | | NFS4ERR_LOCKED, NFS4ERR_MOVED, |
| | | | | NFS4ERR_NOFILEHANDLE, |
| RECLAIM_COMPLETE | NFS4ERR_BADXDR, NFS4ERR_COMPLETE_ALREADY, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_PNFS_NO_LAYOUT, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | 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, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_CRED, | | | NFS4ERR_WRONG_TYPE |
| | NFS4ERR_WRONG_TYPE | +----------------------+----------------------------------------+
| | | | READDIR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| RELEASE_LOCKOWNER | NFS4ERR_NOTSUPP | | | NFS4ERR_BAD_COOKIE, |
| | | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| REMOVE | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_BADNAME, NFS4ERR_BADXDR, | | | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, | | | NFS4ERR_NOT_SAME, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_NOTDIR, NFS4ERR_NOTEMPTY, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS |
| | NFS4ERR_REQ_TOO_BIG, | +----------------------+----------------------------------------+
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | READLINK | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_INVAL, NFS4ERR_IO, |
| | | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| RENAME | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_BADNAME, NFS4ERR_BADXDR, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_DQUOT, NFS4ERR_EXIST, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_MLINK, NFS4ERR_MOVED, | | | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, | | | NFS4ERR_WRONG_TYPE |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | +----------------------+----------------------------------------+
| | NFS4ERR_NOTDIR, NFS4ERR_NOTEMPTY, | | RECLAIM_COMPLETE | NFS4ERR_BADXDR, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_COMPLETE_ALREADY, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONGSEC, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_XDEV | | | NFS4ERR_REQ_TOO_BIG, |
| | | | | NFS4ERR_RETRY_UNCACHED_REP, |
| RENEW | NFS4ERR_NOTSUPP | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | | | | NFS4ERR_TOO_MANY_OPS, |
| RESTOREFH | NFS4ERR_DEADSESSION, NFS4ERR_FHEXPIRED, | | | NFS4ERR_WRONG_CRED, NFS4ERR_WRONG_TYPE |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | +----------------------+----------------------------------------+
| | NFS4ERR_OP_NOT_IN_SESSION, | | RELEASE_LOCKOWNER | NFS4ERR_NOTSUPP |
| | NFS4ERR_REP_TOO_BIG, | +----------------------+----------------------------------------+
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | REMOVE | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_BADNAME, NFS4ERR_BADXDR, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONGSEC | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | | | | NFS4ERR_IO, NFS4ERR_MOVED, |
| SAVEFH | NFS4ERR_DEADSESSION, NFS4ERR_FHEXPIRED, | | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_NOTEMPTY, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | | | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS |
| SECINFO | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | +----------------------+----------------------------------------+
| | NFS4ERR_BADNAME, NFS4ERR_BADXDR, | | RENAME | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_BADNAME, NFS4ERR_BADXDR, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | | NFS4ERR_DQUOT, NFS4ERR_EXIST, |
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_NOTDIR, NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_IO, NFS4ERR_MLINK, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_NOTEMPTY, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | | | | NFS4ERR_REP_TOO_BIG, |
| SECINFO_NO_NAME | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_MOVED, NFS4ERR_NOENT, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_NOTSUPP, | | | NFS4ERR_WRONGSEC, NFS4ERR_XDEV |
| | NFS4ERR_OP_NOT_IN_SESSION, | +----------------------+----------------------------------------+
| | NFS4ERR_REP_TOO_BIG, | | RENEW | NFS4ERR_NOTSUPP |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | +----------------------+----------------------------------------+
| | NFS4ERR_REQ_TOO_BIG, | | RESTOREFH | NFS4ERR_DEADSESSION, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_FHEXPIRED, NFS4ERR_MOVED, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | | | | NFS4ERR_REP_TOO_BIG, |
| SEQUENCE | NFS4ERR_BADSESSION, NFS4ERR_BADSLOT, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_HIGH_SLOT, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_CONN_NOT_BOUND_TO_SESSION, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONGSEC |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | +----------------------+----------------------------------------+
| | NFS4ERR_REQ_TOO_BIG, | | SAVEFH | NFS4ERR_DEADSESSION, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_FHEXPIRED, NFS4ERR_MOVED, |
| | NFS4ERR_SEQUENCE_POS, | | | NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_SEQ_FALSE_RETRY, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SEQ_MISORDERED, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | | | | NFS4ERR_REQ_TOO_BIG, |
| SET_SSV | NFS4ERR_BADXDR, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_BAD_SESSION_DIGEST, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_TOO_MANY_OPS |
| | NFS4ERR_INVAL, NFS4ERR_OP_NOT_IN_SESSION, | +----------------------+----------------------------------------+
| | NFS4ERR_REP_TOO_BIG, | | SECINFO | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_BADNAME, NFS4ERR_BADXDR, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | | | | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| SETATTR | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_NOTDIR, |
| | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_BADOWNER, NFS4ERR_BADXDR, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_DQUOT, NFS4ERR_EXPIRED, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_TOO_MANY_OPS |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, | +----------------------+----------------------------------------+
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | SECINFO_NO_NAME | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_MOVED, NFS4ERR_NOENT, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_NOTSUPP, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_WRONG_TYPE | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| SETCLIENTID | NFS4ERR_NOTSUPP | | | NFS4ERR_TOO_MANY_OPS |
| | | +----------------------+----------------------------------------+
| SETCLIENTID_CONFIRM | NFS4ERR_NOTSUPP | | SEQUENCE | NFS4ERR_BADSESSION, NFS4ERR_BADSLOT, |
| | | | | NFS4ERR_BADXDR, NFS4ERR_BAD_HIGH_SLOT, |
| TEST_STATEID | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, | | | NFS4ERR_CONN_NOT_BOUND_TO_SESSION, |
| | NFS4ERR_DELAY, NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | 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, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_SEQUENCE_POS, |
| | | | | NFS4ERR_SEQ_FALSE_RETRY, |
| VERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, | | | NFS4ERR_SEQ_MISORDERED, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADXDR, | | | NFS4ERR_TOO_MANY_OPS |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | +----------------------+----------------------------------------+
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | SET_SSV | NFS4ERR_BADXDR, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_BAD_SESSION_DIGEST, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOT_SAME, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_INVAL, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_TOO_MANY_OPS |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, | +----------------------+----------------------------------------+
| | NFS4ERR_WRONG_TYPE | | SETATTR | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | | | | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, |
| WANT_DELEGATION | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, | | | NFS4ERR_BADOWNER, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, | | | NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DELEG_ALREADY_WANTED, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_NO_GRACE, | | | NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_LOCKED, NFS4ERR_MOVED, |
| | NFS4ERR_RECALLCONFLICT, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_RECLAIM_BAD, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_RECLAIM_CONFLICT, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE | | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, |
| | | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, |
| WRITE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_WRONG_TYPE |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | +----------------------+----------------------------------------+
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | SETCLIENTID | NFS4ERR_NOTSUPP |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | +----------------------+----------------------------------------+
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, | | SETCLIENTID_CONFIRM | NFS4ERR_NOTSUPP |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | +----------------------+----------------------------------------+
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, | | TEST_STATEID | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, | | | NFS4ERR_DELAY, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_PNFS_IO_HOLE, | | | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_PNFS_NO_LAYOUT, | | | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_TOO_MANY_OPS |
| | NFS4ERR_REQ_TOO_BIG, | +----------------------+----------------------------------------+
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | VERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_BADCHAR, NFS4ERR_BADXDR, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_WRONG_TYPE | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | | | | NFS4ERR_INVAL, NFS4ERR_IO, |
+----------------------+--------------------------------------------+ | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOT_SAME, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, |
| | NFS4ERR_WRONG_TYPE |
+----------------------+----------------------------------------+
| WANT_DELEGATION | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, |
| | NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_ALREADY_WANTED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_NO_GRACE, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_RECALLCONFLICT, |
| | NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_RECLAIM_CONFLICT, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE |
+----------------------+----------------------------------------+
| WRITE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE |
+----------------------+----------------------------------------+
Table 6 Table 12: Valid Error Returns for Each Protocol Operation
15.3. Callback Operations and Their Valid Errors 15.3. Callback Operations and Their Valid Errors
This section contains a table that gives the valid error returns for This section contains a table that gives the valid error returns for
each callback operation. The error code NFS4_OK (indicating no each callback operation. The error code NFS4_OK (indicating no
error) is not listed but should be understood to be returnable by all error) is not listed but should be understood to be returnable by all
callback operations with the exception of CB_ILLEGAL. callback operations with the exception of CB_ILLEGAL.
Valid Error Returns for Each Protocol Callback Operation +=========================+=======================================+
| Callback Operation | Errors |
+=========================+=======================================+
| CB_GETATTR | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS, |
+-------------------------+---------------------------------------+
| CB_ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL |
+-------------------------+---------------------------------------+
| CB_LAYOUTRECALL | NFS4ERR_BADHANDLE, NFS4ERR_BADIOMODE, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_NOMATCHING_LAYOUT, |
| | NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, |
| | NFS4ERR_WRONG_TYPE |
+-------------------------+---------------------------------------+
| CB_NOTIFY | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
+-------------------------+---------------------------------------+
| CB_NOTIFY_DEVICEID | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
+-------------------------+---------------------------------------+
| CB_NOTIFY_LOCK | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
+-------------------------+---------------------------------------+
| CB_PUSH_DELEG | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REJECT_DELEG, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE |
+-------------------------+---------------------------------------+
| CB_RECALL | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
+-------------------------+---------------------------------------+
| CB_RECALL_ANY | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS |
+-------------------------+---------------------------------------+
| CB_RECALLABLE_OBJ_AVAIL | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
+-------------------------+---------------------------------------+
| CB_RECALL_SLOT | NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_HIGH_SLOT, NFS4ERR_DELAY, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS |
+-------------------------+---------------------------------------+
| CB_SEQUENCE | NFS4ERR_BADSESSION, NFS4ERR_BADSLOT, |
| | NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_HIGH_SLOT, |
| | NFS4ERR_CONN_NOT_BOUND_TO_SESSION, |
| | NFS4ERR_DELAY, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SEQUENCE_POS, |
| | NFS4ERR_SEQ_FALSE_RETRY, |
| | NFS4ERR_SEQ_MISORDERED, |
| | NFS4ERR_TOO_MANY_OPS |
+-------------------------+---------------------------------------+
| CB_WANTS_CANCELLED | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
+-------------------------+---------------------------------------+
+-------------------------+-----------------------------------------+ Table 13: Valid Error Returns for Each Protocol Callback Operation
| Callback Operation | Errors |
+-------------------------+-----------------------------------------+
| CB_GETATTR | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS, |
| | |
| CB_ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL |
| | |
| CB_LAYOUTRECALL | NFS4ERR_BADHANDLE, NFS4ERR_BADIOMODE, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_NOMATCHING_LAYOUT, |
| | NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, |
| | NFS4ERR_WRONG_TYPE |
| | |
| CB_NOTIFY | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
| | |
| CB_NOTIFY_DEVICEID | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
| | |
| CB_NOTIFY_LOCK | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
| | |
| CB_PUSH_DELEG | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REJECT_DELEG, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE |
| | |
| CB_RECALL | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
| | |
| CB_RECALL_ANY | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS |
| | |
| CB_RECALLABLE_OBJ_AVAIL | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
| | |
| CB_RECALL_SLOT | NFS4ERR_BADXDR, NFS4ERR_BAD_HIGH_SLOT, |
| | NFS4ERR_DELAY, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS |
| | |
| CB_SEQUENCE | NFS4ERR_BADSESSION, NFS4ERR_BADSLOT, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_HIGH_SLOT, |
| | NFS4ERR_CONN_NOT_BOUND_TO_SESSION, |
| | NFS4ERR_DELAY, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SEQUENCE_POS, |
| | NFS4ERR_SEQ_FALSE_RETRY, |
| | NFS4ERR_SEQ_MISORDERED, |
| | NFS4ERR_TOO_MANY_OPS |
| | |
| CB_WANTS_CANCELLED | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_NOTSUPP, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
| | |
+-------------------------+-----------------------------------------+
Table 7
15.4. Errors and the Operations That Use Them 15.4. Errors and the Operations That Use Them
+-----------------------------------+-------------------------------+ +===================================+===============================+
| Error | Operations | | Error | Operations |
+-----------------------------------+-------------------------------+ +===================================+===============================+
| NFS4ERR_ACCESS | ACCESS, COMMIT, CREATE, | | NFS4ERR_ACCESS | ACCESS, COMMIT, CREATE, |
| | GETATTR, GET_DIR_DELEGATION, | | | GETATTR, GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LINK, LOCK, LOCKT, LOCKU, | | | LINK, LOCK, LOCKT, LOCKU, |
| | LOOKUP, LOOKUPP, NVERIFY, | | | LOOKUP, LOOKUPP, NVERIFY, |
| | OPEN, OPENATTR, READ, | | | OPEN, OPENATTR, READ, |
| | READDIR, READLINK, REMOVE, | | | READDIR, READLINK, REMOVE, |
| | RENAME, SECINFO, | | | RENAME, SECINFO, |
| | SECINFO_NO_NAME, SETATTR, | | | SECINFO_NO_NAME, SETATTR, |
| | VERIFY, WRITE | | | VERIFY, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_ADMIN_REVOKED | CLOSE, DELEGRETURN, | | NFS4ERR_ADMIN_REVOKED | CLOSE, DELEGRETURN, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LOCK, LOCKU, | | | LAYOUTRETURN, LOCK, LOCKU, |
| | OPEN, OPEN_DOWNGRADE, READ, | | | OPEN, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_ATTRNOTSUPP | CREATE, LAYOUTCOMMIT, | | NFS4ERR_ATTRNOTSUPP | CREATE, LAYOUTCOMMIT, |
| | NVERIFY, OPEN, SETATTR, | | | NVERIFY, OPEN, SETATTR, |
| | VERIFY | | | VERIFY |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BACK_CHAN_BUSY | DESTROY_SESSION | | NFS4ERR_BACK_CHAN_BUSY | DESTROY_SESSION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADCHAR | CREATE, EXCHANGE_ID, LINK, | | NFS4ERR_BADCHAR | CREATE, EXCHANGE_ID, LINK, |
| | LOOKUP, NVERIFY, OPEN, | | | LOOKUP, NVERIFY, OPEN, |
| | REMOVE, RENAME, SECINFO, | | | REMOVE, RENAME, SECINFO, |
| | SETATTR, VERIFY | | | SETATTR, VERIFY |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADHANDLE | CB_GETATTR, CB_LAYOUTRECALL, | | NFS4ERR_BADHANDLE | CB_GETATTR, CB_LAYOUTRECALL, |
| | CB_NOTIFY, CB_NOTIFY_LOCK, | | | CB_NOTIFY, CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | PUTFH | | | PUTFH |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADIOMODE | CB_LAYOUTRECALL, | | NFS4ERR_BADIOMODE | CB_LAYOUTRECALL, |
| | LAYOUTCOMMIT, LAYOUTGET | | | LAYOUTCOMMIT, LAYOUTGET |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADLAYOUT | LAYOUTCOMMIT, LAYOUTGET | | NFS4ERR_BADLAYOUT | LAYOUTCOMMIT, LAYOUTGET |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADNAME | CREATE, LINK, LOOKUP, OPEN, | | NFS4ERR_BADNAME | CREATE, LINK, LOOKUP, OPEN, |
| | REMOVE, RENAME, SECINFO | | | REMOVE, RENAME, SECINFO |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADOWNER | CREATE, OPEN, SETATTR | | NFS4ERR_BADOWNER | CREATE, OPEN, SETATTR |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADSESSION | BIND_CONN_TO_SESSION, | | NFS4ERR_BADSESSION | BIND_CONN_TO_SESSION, |
| | CB_SEQUENCE, DESTROY_SESSION, | | | CB_SEQUENCE, |
| | SEQUENCE | | | DESTROY_SESSION, SEQUENCE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADSLOT | CB_SEQUENCE, SEQUENCE | | NFS4ERR_BADSLOT | CB_SEQUENCE, SEQUENCE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADTYPE | CREATE | | NFS4ERR_BADTYPE | CREATE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BADXDR | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_BADXDR | ACCESS, BACKCHANNEL_CTL, |
| | BIND_CONN_TO_SESSION, | | | BIND_CONN_TO_SESSION, |
| | CB_GETATTR, CB_ILLEGAL, | | | CB_GETATTR, CB_ILLEGAL, |
| | CB_LAYOUTRECALL, CB_NOTIFY, | | | CB_LAYOUTRECALL, CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_RECALL_ANY, | | | CB_RECALL_ANY, |
| | CB_RECALL_SLOT, CB_SEQUENCE, | | | CB_RECALL_SLOT, CB_SEQUENCE, |
| | CB_WANTS_CANCELLED, CLOSE, | | | CB_WANTS_CANCELLED, CLOSE, |
| | COMMIT, CREATE, | | | COMMIT, CREATE, |
| | CREATE_SESSION, DELEGPURGE, | | | CREATE_SESSION, DELEGPURGE, |
| | DELEGRETURN, | | | DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID, | | | DESTROY_SESSION, |
| | FREE_STATEID, GETATTR, | | | EXCHANGE_ID, FREE_STATEID, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETATTR, GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, ILLEGAL, | | | GET_DIR_DELEGATION, ILLEGAL, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | NVERIFY, OPEN, OPENATTR, | | | NVERIFY, OPEN, OPENATTR, |
| | OPEN_DOWNGRADE, PUTFH, READ, | | | OPEN_DOWNGRADE, PUTFH, READ, |
| | READDIR, RECLAIM_COMPLETE, | | | READDIR, RECLAIM_COMPLETE, |
| | REMOVE, RENAME, SECINFO, | | | REMOVE, RENAME, SECINFO, |
| | SECINFO_NO_NAME, SEQUENCE, | | | SECINFO_NO_NAME, SEQUENCE, |
| | SETATTR, SET_SSV, | | | SETATTR, SET_SSV, |
| | TEST_STATEID, VERIFY, | | | TEST_STATEID, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BAD_COOKIE | GETDEVICELIST, READDIR | | NFS4ERR_BAD_COOKIE | GETDEVICELIST, READDIR |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BAD_HIGH_SLOT | CB_RECALL_SLOT, CB_SEQUENCE, | | NFS4ERR_BAD_HIGH_SLOT | CB_RECALL_SLOT, CB_SEQUENCE, |
| | SEQUENCE | | | SEQUENCE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BAD_RANGE | LOCK, LOCKT, LOCKU | | NFS4ERR_BAD_RANGE | LOCK, LOCKT, LOCKU |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_BAD_SESSION_DIGEST | BIND_CONN_TO_SESSION, SET_SSV | | NFS4ERR_BAD_SESSION_DIGEST | BIND_CONN_TO_SESSION, |
| | | | | SET_SSV |
+-----------------------------------+-------------------------------+
| NFS4ERR_BAD_STATEID | CB_LAYOUTRECALL, CB_NOTIFY, | | NFS4ERR_BAD_STATEID | CB_LAYOUTRECALL, CB_NOTIFY, |
| | CB_NOTIFY_LOCK, CB_RECALL, | | | CB_NOTIFY_LOCK, CB_RECALL, |
| | CLOSE, DELEGRETURN, | | | CLOSE, DELEGRETURN, |
| | FREE_STATEID, LAYOUTGET, | | | FREE_STATEID, LAYOUTGET, |
| | LAYOUTRETURN, LOCK, LOCKU, | | | LAYOUTRETURN, LOCK, LOCKU, |
| | OPEN, OPEN_DOWNGRADE, READ, | | | OPEN, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_CB_PATH_DOWN | DESTROY_SESSION | | NFS4ERR_CB_PATH_DOWN | DESTROY_SESSION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_CLID_INUSE | CREATE_SESSION, EXCHANGE_ID | | NFS4ERR_CLID_INUSE | CREATE_SESSION, EXCHANGE_ID |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_CLIENTID_BUSY | DESTROY_CLIENTID | | NFS4ERR_CLIENTID_BUSY | DESTROY_CLIENTID |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_COMPLETE_ALREADY | RECLAIM_COMPLETE | | NFS4ERR_COMPLETE_ALREADY | RECLAIM_COMPLETE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_CONN_NOT_BOUND_TO_SESSION | CB_SEQUENCE, DESTROY_SESSION, | | NFS4ERR_CONN_NOT_BOUND_TO_SESSION | CB_SEQUENCE, |
| | SEQUENCE | | | DESTROY_SESSION, SEQUENCE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_DEADLOCK | LOCK | | NFS4ERR_DEADLOCK | LOCK |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_DEADSESSION | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_DEADSESSION | ACCESS, BACKCHANNEL_CTL, |
| | BIND_CONN_TO_SESSION, CLOSE, | | | BIND_CONN_TO_SESSION, CLOSE, |
| | COMMIT, CREATE, | | | COMMIT, CREATE, |
| | CREATE_SESSION, DELEGPURGE, | | | CREATE_SESSION, DELEGPURGE, |
| | DELEGRETURN, | | | DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID, | | | DESTROY_SESSION, |
| | FREE_STATEID, GETATTR, | | | EXCHANGE_ID, FREE_STATEID, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETATTR, GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, PUTPUBFH, PUTROOTFH, | | | PUTFH, PUTPUBFH, PUTROOTFH, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SEQUENCE, SETATTR, SET_SSV, | | | SEQUENCE, SETATTR, SET_SSV, |
| | TEST_STATEID, VERIFY, | | | TEST_STATEID, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_DELAY | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_DELAY | ACCESS, BACKCHANNEL_CTL, |
| | BIND_CONN_TO_SESSION, | | | BIND_CONN_TO_SESSION, |
| | CB_GETATTR, CB_LAYOUTRECALL, | | | CB_GETATTR, CB_LAYOUTRECALL, |
| | CB_NOTIFY, | | | CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_RECALL_ANY, | | | CB_RECALL_ANY, |
| | CB_RECALL_SLOT, CB_SEQUENCE, | | | CB_RECALL_SLOT, CB_SEQUENCE, |
| | CB_WANTS_CANCELLED, CLOSE, | | | CB_WANTS_CANCELLED, CLOSE, |
| | COMMIT, CREATE, | | | COMMIT, CREATE, |
| | CREATE_SESSION, DELEGPURGE, | | | CREATE_SESSION, DELEGPURGE, |
| | DELEGRETURN, | | | DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID, | | | DESTROY_SESSION, |
| | FREE_STATEID, GETATTR, | | | EXCHANGE_ID, FREE_STATEID, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETATTR, GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, PUTPUBFH, PUTROOTFH, | | | PUTFH, PUTPUBFH, PUTROOTFH, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, SECINFO, | | | RENAME, SECINFO, |
| | SECINFO_NO_NAME, SEQUENCE, | | | SECINFO_NO_NAME, SEQUENCE, |
| | SETATTR, SET_SSV, | | | SETATTR, SET_SSV, |
| | TEST_STATEID, VERIFY, | | | TEST_STATEID, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_DELEG_ALREADY_WANTED | OPEN, WANT_DELEGATION | | NFS4ERR_DELEG_ALREADY_WANTED | OPEN, WANT_DELEGATION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_DELEG_REVOKED | DELEGRETURN, LAYOUTCOMMIT, | | NFS4ERR_DELEG_REVOKED | DELEGRETURN, LAYOUTCOMMIT, |
| | LAYOUTGET, LAYOUTRETURN, | | | LAYOUTGET, LAYOUTRETURN, |
| | OPEN, READ, SETATTR, WRITE | | | OPEN, READ, SETATTR, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_DENIED | LOCK, LOCKT | | NFS4ERR_DENIED | LOCK, LOCKT |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_DIRDELEG_UNAVAIL | GET_DIR_DELEGATION | | NFS4ERR_DIRDELEG_UNAVAIL | GET_DIR_DELEGATION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_DQUOT | CREATE, LAYOUTGET, LINK, | | NFS4ERR_DQUOT | CREATE, LAYOUTGET, LINK, |
| | OPEN, OPENATTR, RENAME, | | | OPEN, OPENATTR, RENAME, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_ENCR_ALG_UNSUPP | EXCHANGE_ID | | NFS4ERR_ENCR_ALG_UNSUPP | EXCHANGE_ID |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_EXIST | CREATE, LINK, OPEN, RENAME | | NFS4ERR_EXIST | CREATE, LINK, OPEN, RENAME |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_EXPIRED | CLOSE, DELEGRETURN, | | NFS4ERR_EXPIRED | CLOSE, DELEGRETURN, |
| | LAYOUTCOMMIT, LAYOUTRETURN, | | | LAYOUTCOMMIT, LAYOUTRETURN, |
| | LOCK, LOCKU, OPEN, | | | LOCK, LOCKU, OPEN, |
| | OPEN_DOWNGRADE, READ, | | | OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_FBIG | LAYOUTCOMMIT, OPEN, SETATTR, | | NFS4ERR_FBIG | LAYOUTCOMMIT, OPEN, SETATTR, |
| | WRITE | | | WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_FHEXPIRED | ACCESS, CLOSE, COMMIT, | | NFS4ERR_FHEXPIRED | ACCESS, CLOSE, COMMIT, |
| | CREATE, DELEGRETURN, GETATTR, | | | CREATE, DELEGRETURN, |
| | GETDEVICELIST, GETFH, | | | GETATTR, GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GETFH, GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SETATTR, VERIFY, | | | SETATTR, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_FILE_OPEN | LINK, REMOVE, RENAME | | NFS4ERR_FILE_OPEN | LINK, REMOVE, RENAME |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_GRACE | GETATTR, GET_DIR_DELEGATION, | | NFS4ERR_GRACE | GETATTR, GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, NVERIFY, OPEN, READ, | | | LOCKT, NVERIFY, OPEN, READ, |
| | REMOVE, RENAME, SETATTR, | | | REMOVE, RENAME, SETATTR, |
| | VERIFY, WANT_DELEGATION, | | | VERIFY, WANT_DELEGATION, |
| | WRITE | | | WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_HASH_ALG_UNSUPP | EXCHANGE_ID | | NFS4ERR_HASH_ALG_UNSUPP | EXCHANGE_ID |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_INVAL | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_INVAL | ACCESS, BACKCHANNEL_CTL, |
| | BIND_CONN_TO_SESSION, | | | BIND_CONN_TO_SESSION, |
| | CB_GETATTR, CB_LAYOUTRECALL, | | | CB_GETATTR, CB_LAYOUTRECALL, |
| | CB_NOTIFY, | | | CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_PUSH_DELEG, | | | CB_PUSH_DELEG, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_RECALL_ANY, CREATE, | | | CB_RECALL_ANY, CREATE, |
| | CREATE_SESSION, DELEGRETURN, | | | CREATE_SESSION, DELEGRETURN, |
| | EXCHANGE_ID, GETATTR, | | | EXCHANGE_ID, GETATTR, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | NVERIFY, OPEN, | | | NVERIFY, OPEN, |
| | OPEN_DOWNGRADE, READ, | | | OPEN_DOWNGRADE, READ, |
| | READDIR, READLINK, | | | READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, SECINFO, | | | RENAME, SECINFO, |
| | SECINFO_NO_NAME, SETATTR, | | | SECINFO_NO_NAME, SETATTR, |
| | SET_SSV, VERIFY, | | | SET_SSV, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_IO | ACCESS, COMMIT, CREATE, | | NFS4ERR_IO | ACCESS, COMMIT, CREATE, |
| | GETATTR, GETDEVICELIST, | | | GETATTR, GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LINK, LOOKUP, LOOKUPP, | | | LINK, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, | | | NVERIFY, OPEN, OPENATTR, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | REMOVE, RENAME, SETATTR, | | | REMOVE, RENAME, SETATTR, |
| | VERIFY, WANT_DELEGATION, | | | VERIFY, WANT_DELEGATION, |
| | WRITE | | | WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_ISDIR | COMMIT, LAYOUTCOMMIT, | | NFS4ERR_ISDIR | COMMIT, LAYOUTCOMMIT, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, OPEN, READ, WRITE | | | LOCKT, OPEN, READ, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_LAYOUTTRYLATER | LAYOUTGET | | NFS4ERR_LAYOUTTRYLATER | LAYOUTGET |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_LAYOUTUNAVAILABLE | LAYOUTGET | | NFS4ERR_LAYOUTUNAVAILABLE | LAYOUTGET |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_LOCKED | LAYOUTGET, READ, SETATTR, | | NFS4ERR_LOCKED | LAYOUTGET, READ, SETATTR, |
| | WRITE | | | WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_LOCKS_HELD | CLOSE, FREE_STATEID | | NFS4ERR_LOCKS_HELD | CLOSE, FREE_STATEID |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_LOCK_NOTSUPP | LOCK | | NFS4ERR_LOCK_NOTSUPP | LOCK |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_LOCK_RANGE | LOCK, LOCKT, LOCKU | | NFS4ERR_LOCK_RANGE | LOCK, LOCKT, LOCKU |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_MLINK | CREATE, LINK, RENAME | | NFS4ERR_MLINK | CREATE, LINK, RENAME |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_MOVED | ACCESS, CLOSE, COMMIT, | | NFS4ERR_MOVED | ACCESS, CLOSE, COMMIT, |
| | CREATE, DELEGRETURN, GETATTR, | | | CREATE, DELEGRETURN, |
| | GETFH, GET_DIR_DELEGATION, | | | GETATTR, GETFH, |
| | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, READ, READDIR, | | | PUTFH, READ, READDIR, |
| | READLINK, RECLAIM_COMPLETE, | | | READLINK, RECLAIM_COMPLETE, |
| | REMOVE, RENAME, RESTOREFH, | | | REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, | | | SAVEFH, SECINFO, |
| | SECINFO_NO_NAME, SETATTR, | | | SECINFO_NO_NAME, SETATTR, |
| | VERIFY, WANT_DELEGATION, | | | VERIFY, WANT_DELEGATION, |
| | WRITE | | | WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NAMETOOLONG | CREATE, LINK, LOOKUP, OPEN, | | NFS4ERR_NAMETOOLONG | CREATE, LINK, LOOKUP, OPEN, |
| | REMOVE, RENAME, SECINFO | | | REMOVE, RENAME, SECINFO |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NOENT | BACKCHANNEL_CTL, | | NFS4ERR_NOENT | BACKCHANNEL_CTL, |
| | CREATE_SESSION, EXCHANGE_ID, | | | CREATE_SESSION, EXCHANGE_ID, |
| | GETDEVICEINFO, LOOKUP, | | | GETDEVICEINFO, LOOKUP, |
| | LOOKUPP, OPEN, OPENATTR, | | | LOOKUPP, OPEN, OPENATTR, |
| | REMOVE, RENAME, SECINFO, | | | REMOVE, RENAME, SECINFO, |
| | SECINFO_NO_NAME | | | SECINFO_NO_NAME |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NOFILEHANDLE | ACCESS, CLOSE, COMMIT, | | NFS4ERR_NOFILEHANDLE | ACCESS, CLOSE, COMMIT, |
| | CREATE, DELEGRETURN, GETATTR, | | | CREATE, DELEGRETURN, |
| | GETDEVICELIST, GETFH, | | | GETATTR, GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GETFH, GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SETATTR, VERIFY, | | | SETATTR, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NOMATCHING_LAYOUT | CB_LAYOUTRECALL | | NFS4ERR_NOMATCHING_LAYOUT | CB_LAYOUTRECALL |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NOSPC | CREATE, CREATE_SESSION, | | NFS4ERR_NOSPC | CREATE, CREATE_SESSION, |
| | LAYOUTGET, LINK, OPEN, | | | LAYOUTGET, LINK, OPEN, |
| | OPENATTR, RENAME, SETATTR, | | | OPENATTR, RENAME, SETATTR, |
| | WRITE | | | WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NOTDIR | CREATE, GET_DIR_DELEGATION, | | NFS4ERR_NOTDIR | CREATE, GET_DIR_DELEGATION, |
| | LINK, LOOKUP, LOOKUPP, OPEN, | | | LINK, LOOKUP, LOOKUPP, OPEN, |
| | READDIR, REMOVE, RENAME, | | | READDIR, REMOVE, RENAME, |
| | SECINFO, SECINFO_NO_NAME | | | SECINFO, SECINFO_NO_NAME |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NOTEMPTY | REMOVE, RENAME | | NFS4ERR_NOTEMPTY | REMOVE, RENAME |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NOTSUPP | CB_LAYOUTRECALL, CB_NOTIFY, | | NFS4ERR_NOTSUPP | CB_LAYOUTRECALL, CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, | | | CB_PUSH_DELEG, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_WANTS_CANCELLED, | | | CB_WANTS_CANCELLED, |
| | DELEGPURGE, DELEGRETURN, | | | DELEGPURGE, DELEGRETURN, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, OPENATTR, | | | LAYOUTRETURN, LINK, |
| | OPEN_CONFIRM, | | | OPENATTR, OPEN_CONFIRM, |
| | RELEASE_LOCKOWNER, RENEW, | | | RELEASE_LOCKOWNER, RENEW, |
| | SECINFO_NO_NAME, SETCLIENTID, | | | SECINFO_NO_NAME, |
| | SETCLIENTID, |
| | SETCLIENTID_CONFIRM, | | | SETCLIENTID_CONFIRM, |
| | WANT_DELEGATION | | | WANT_DELEGATION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NOT_ONLY_OP | BIND_CONN_TO_SESSION, | | NFS4ERR_NOT_ONLY_OP | BIND_CONN_TO_SESSION, |
| | CREATE_SESSION, | | | CREATE_SESSION, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID | | | DESTROY_SESSION, EXCHANGE_ID |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NOT_SAME | EXCHANGE_ID, GETDEVICELIST, | | NFS4ERR_NOT_SAME | EXCHANGE_ID, GETDEVICELIST, |
| | READDIR, VERIFY | | | READDIR, VERIFY |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_NO_GRACE | LAYOUTCOMMIT, LAYOUTRETURN, | | NFS4ERR_NO_GRACE | LAYOUTCOMMIT, LAYOUTRETURN, |
| | LOCK, OPEN, WANT_DELEGATION | | | LOCK, OPEN, WANT_DELEGATION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_OLD_STATEID | CLOSE, DELEGRETURN, | | NFS4ERR_OLD_STATEID | CLOSE, DELEGRETURN, |
| | FREE_STATEID, LAYOUTGET, | | | FREE_STATEID, LAYOUTGET, |
| | LAYOUTRETURN, LOCK, LOCKU, | | | LAYOUTRETURN, LOCK, LOCKU, |
| | OPEN, OPEN_DOWNGRADE, READ, | | | OPEN, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_OPENMODE | LAYOUTGET, LOCK, READ, | | NFS4ERR_OPENMODE | LAYOUTGET, LOCK, READ, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_OP_ILLEGAL | CB_ILLEGAL, ILLEGAL | | NFS4ERR_OP_ILLEGAL | CB_ILLEGAL, ILLEGAL |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_OP_NOT_IN_SESSION | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_OP_NOT_IN_SESSION | ACCESS, BACKCHANNEL_CTL, |
| | CB_GETATTR, CB_LAYOUTRECALL, | | | CB_GETATTR, CB_LAYOUTRECALL, |
| | CB_NOTIFY, | | | CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_RECALL_ANY, | | | CB_RECALL_ANY, |
| | CB_RECALL_SLOT, | | | CB_RECALL_SLOT, |
| | CB_WANTS_CANCELLED, CLOSE, | | | CB_WANTS_CANCELLED, CLOSE, |
skipping to change at page 417, line 28 skipping to change at line 20096
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, PUTPUBFH, PUTROOTFH, | | | PUTFH, PUTPUBFH, PUTROOTFH, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SETATTR, SET_SSV, | | | SETATTR, SET_SSV, |
| | TEST_STATEID, VERIFY, | | | TEST_STATEID, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_PERM | CREATE, OPEN, SETATTR | | NFS4ERR_PERM | CREATE, OPEN, SETATTR |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_PNFS_IO_HOLE | READ, WRITE | | NFS4ERR_PNFS_IO_HOLE | READ, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_PNFS_NO_LAYOUT | READ, WRITE | | NFS4ERR_PNFS_NO_LAYOUT | READ, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_RECALLCONFLICT | LAYOUTGET, WANT_DELEGATION | | NFS4ERR_RECALLCONFLICT | LAYOUTGET, WANT_DELEGATION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_RECLAIM_BAD | LAYOUTCOMMIT, LOCK, OPEN, | | NFS4ERR_RECLAIM_BAD | LAYOUTCOMMIT, LOCK, OPEN, |
| | WANT_DELEGATION | | | WANT_DELEGATION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_RECLAIM_CONFLICT | LAYOUTCOMMIT, LOCK, OPEN, | | NFS4ERR_RECLAIM_CONFLICT | LAYOUTCOMMIT, LOCK, OPEN, |
| | WANT_DELEGATION | | | WANT_DELEGATION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_REJECT_DELEG | CB_PUSH_DELEG | | NFS4ERR_REJECT_DELEG | CB_PUSH_DELEG |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_REP_TOO_BIG | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_REP_TOO_BIG | ACCESS, BACKCHANNEL_CTL, |
| | BIND_CONN_TO_SESSION, | | | BIND_CONN_TO_SESSION, |
| | CB_GETATTR, CB_LAYOUTRECALL, | | | CB_GETATTR, CB_LAYOUTRECALL, |
| | CB_NOTIFY, | | | CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_RECALL_ANY, | | | CB_RECALL_ANY, |
| | CB_RECALL_SLOT, CB_SEQUENCE, | | | CB_RECALL_SLOT, CB_SEQUENCE, |
| | CB_WANTS_CANCELLED, CLOSE, | | | CB_WANTS_CANCELLED, CLOSE, |
| | COMMIT, CREATE, | | | COMMIT, CREATE, |
| | CREATE_SESSION, DELEGPURGE, | | | CREATE_SESSION, DELEGPURGE, |
| | DELEGRETURN, | | | DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID, | | | DESTROY_SESSION, |
| | FREE_STATEID, GETATTR, | | | EXCHANGE_ID, FREE_STATEID, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETATTR, GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, PUTPUBFH, PUTROOTFH, | | | PUTFH, PUTPUBFH, PUTROOTFH, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SEQUENCE, SETATTR, SET_SSV, | | | SEQUENCE, SETATTR, SET_SSV, |
| | TEST_STATEID, VERIFY, | | | TEST_STATEID, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_REP_TOO_BIG_TO_CACHE | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_REP_TOO_BIG_TO_CACHE | ACCESS, BACKCHANNEL_CTL, |
| | BIND_CONN_TO_SESSION, | | | BIND_CONN_TO_SESSION, |
| | CB_GETATTR, CB_LAYOUTRECALL, | | | CB_GETATTR, CB_LAYOUTRECALL, |
| | CB_NOTIFY, | | | CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_RECALL_ANY, | | | CB_RECALL_ANY, |
| | CB_RECALL_SLOT, CB_SEQUENCE, | | | CB_RECALL_SLOT, CB_SEQUENCE, |
| | CB_WANTS_CANCELLED, CLOSE, | | | CB_WANTS_CANCELLED, CLOSE, |
| | COMMIT, CREATE, | | | COMMIT, CREATE, |
| | CREATE_SESSION, DELEGPURGE, | | | CREATE_SESSION, DELEGPURGE, |
| | DELEGRETURN, | | | DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID, | | | DESTROY_SESSION, |
| | FREE_STATEID, GETATTR, | | | EXCHANGE_ID, FREE_STATEID, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETATTR, GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, PUTPUBFH, PUTROOTFH, | | | PUTFH, PUTPUBFH, PUTROOTFH, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SEQUENCE, SETATTR, SET_SSV, | | | SEQUENCE, SETATTR, SET_SSV, |
| | TEST_STATEID, VERIFY, | | | TEST_STATEID, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_REQ_TOO_BIG | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_REQ_TOO_BIG | ACCESS, BACKCHANNEL_CTL, |
| | BIND_CONN_TO_SESSION, | | | BIND_CONN_TO_SESSION, |
| | CB_GETATTR, CB_LAYOUTRECALL, | | | CB_GETATTR, CB_LAYOUTRECALL, |
| | CB_NOTIFY, | | | CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_RECALL_ANY, | | | CB_RECALL_ANY, |
| | CB_RECALL_SLOT, CB_SEQUENCE, | | | CB_RECALL_SLOT, CB_SEQUENCE, |
| | CB_WANTS_CANCELLED, CLOSE, | | | CB_WANTS_CANCELLED, CLOSE, |
| | COMMIT, CREATE, | | | COMMIT, CREATE, |
| | CREATE_SESSION, DELEGPURGE, | | | CREATE_SESSION, DELEGPURGE, |
| | DELEGRETURN, | | | DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID, | | | DESTROY_SESSION, |
| | FREE_STATEID, GETATTR, | | | EXCHANGE_ID, FREE_STATEID, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETATTR, GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, PUTPUBFH, PUTROOTFH, | | | PUTFH, PUTPUBFH, PUTROOTFH, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SEQUENCE, SETATTR, SET_SSV, | | | SEQUENCE, SETATTR, SET_SSV, |
| | TEST_STATEID, VERIFY, | | | TEST_STATEID, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_RETRY_UNCACHED_REP | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_RETRY_UNCACHED_REP | ACCESS, BACKCHANNEL_CTL, |
| | BIND_CONN_TO_SESSION, | | | BIND_CONN_TO_SESSION, |
| | CB_GETATTR, CB_LAYOUTRECALL, | | | CB_GETATTR, CB_LAYOUTRECALL, |
| | CB_NOTIFY, | | | CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_RECALL_ANY, | | | CB_RECALL_ANY, |
| | CB_RECALL_SLOT, CB_SEQUENCE, | | | CB_RECALL_SLOT, CB_SEQUENCE, |
| | CB_WANTS_CANCELLED, CLOSE, | | | CB_WANTS_CANCELLED, CLOSE, |
| | COMMIT, CREATE, | | | COMMIT, CREATE, |
| | CREATE_SESSION, DELEGPURGE, | | | CREATE_SESSION, DELEGPURGE, |
| | DELEGRETURN, | | | DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID, | | | DESTROY_SESSION, |
| | FREE_STATEID, GETATTR, | | | EXCHANGE_ID, FREE_STATEID, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETATTR, GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, PUTPUBFH, PUTROOTFH, | | | PUTFH, PUTPUBFH, PUTROOTFH, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SEQUENCE, SETATTR, SET_SSV, | | | SEQUENCE, SETATTR, SET_SSV, |
| | TEST_STATEID, VERIFY, | | | TEST_STATEID, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_ROFS | CREATE, LINK, LOCK, LOCKT, | | NFS4ERR_ROFS | CREATE, LINK, LOCK, LOCKT, |
| | OPEN, OPENATTR, | | | OPEN, OPENATTR, |
| | OPEN_DOWNGRADE, REMOVE, | | | OPEN_DOWNGRADE, REMOVE, |
| | RENAME, SETATTR, WRITE | | | RENAME, SETATTR, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_SAME | NVERIFY | | NFS4ERR_SAME | NVERIFY |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_SEQUENCE_POS | CB_SEQUENCE, SEQUENCE | | NFS4ERR_SEQUENCE_POS | CB_SEQUENCE, SEQUENCE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_SEQ_FALSE_RETRY | CB_SEQUENCE, SEQUENCE | | NFS4ERR_SEQ_FALSE_RETRY | CB_SEQUENCE, SEQUENCE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_SEQ_MISORDERED | CB_SEQUENCE, CREATE_SESSION, | | NFS4ERR_SEQ_MISORDERED | CB_SEQUENCE, CREATE_SESSION, |
| | SEQUENCE | | | SEQUENCE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_SERVERFAULT | ACCESS, BIND_CONN_TO_SESSION, | | NFS4ERR_SERVERFAULT | ACCESS, |
| | BIND_CONN_TO_SESSION, |
| | CB_GETATTR, CB_NOTIFY, | | | CB_GETATTR, CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_WANTS_CANCELLED, CLOSE, | | | CB_WANTS_CANCELLED, CLOSE, |
| | COMMIT, CREATE, | | | COMMIT, CREATE, |
| | CREATE_SESSION, DELEGPURGE, | | | CREATE_SESSION, DELEGPURGE, |
| | DELEGRETURN, | | | DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID, | | | DESTROY_SESSION, |
| | FREE_STATEID, GETATTR, | | | EXCHANGE_ID, FREE_STATEID, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETATTR, GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKU, LOOKUP, LOOKUPP, | | | LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, | | | NVERIFY, OPEN, OPENATTR, |
| | OPEN_DOWNGRADE, PUTFH, | | | OPEN_DOWNGRADE, PUTFH, |
| | PUTPUBFH, PUTROOTFH, READ, | | | PUTPUBFH, PUTROOTFH, READ, |
| | READDIR, READLINK, | | | READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SETATTR, TEST_STATEID, | | | SETATTR, TEST_STATEID, |
| | VERIFY, WANT_DELEGATION, | | | VERIFY, WANT_DELEGATION, |
| | WRITE | | | WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_SHARE_DENIED | OPEN | | NFS4ERR_SHARE_DENIED | OPEN |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_STALE | ACCESS, CLOSE, COMMIT, | | NFS4ERR_STALE | ACCESS, CLOSE, COMMIT, |
| | CREATE, DELEGRETURN, GETATTR, | | | CREATE, DELEGRETURN, |
| | GETFH, GET_DIR_DELEGATION, | | | GETATTR, GETFH, |
| | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, READ, READDIR, | | | PUTFH, READ, READDIR, |
| | READLINK, RECLAIM_COMPLETE, | | | READLINK, RECLAIM_COMPLETE, |
| | REMOVE, RENAME, RESTOREFH, | | | REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, | | | SAVEFH, SECINFO, |
| | SECINFO_NO_NAME, SETATTR, | | | SECINFO_NO_NAME, SETATTR, |
| | VERIFY, WANT_DELEGATION, | | | VERIFY, WANT_DELEGATION, |
| | WRITE | | | WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_STALE_CLIENTID | CREATE_SESSION, | | NFS4ERR_STALE_CLIENTID | CREATE_SESSION, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION | | | DESTROY_SESSION |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_SYMLINK | COMMIT, LAYOUTCOMMIT, LINK, | | NFS4ERR_SYMLINK | COMMIT, LAYOUTCOMMIT, LINK, |
| | LOCK, LOCKT, LOOKUP, LOOKUPP, | | | LOCK, LOCKT, LOOKUP, |
| | OPEN, READ, WRITE | | | LOOKUPP, OPEN, READ, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_TOOSMALL | CREATE_SESSION, | | NFS4ERR_TOOSMALL | CREATE_SESSION, |
| | GETDEVICEINFO, LAYOUTGET, | | | GETDEVICEINFO, LAYOUTGET, |
| | READDIR | | | READDIR |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_TOO_MANY_OPS | ACCESS, BACKCHANNEL_CTL, | | NFS4ERR_TOO_MANY_OPS | ACCESS, BACKCHANNEL_CTL, |
| | BIND_CONN_TO_SESSION, | | | BIND_CONN_TO_SESSION, |
| | CB_GETATTR, CB_LAYOUTRECALL, | | | CB_GETATTR, CB_LAYOUTRECALL, |
| | CB_NOTIFY, | | | CB_NOTIFY, |
| | CB_NOTIFY_DEVICEID, | | | CB_NOTIFY_DEVICEID, |
| | CB_NOTIFY_LOCK, | | | CB_NOTIFY_LOCK, |
| | CB_PUSH_DELEG, CB_RECALL, | | | CB_PUSH_DELEG, CB_RECALL, |
| | CB_RECALLABLE_OBJ_AVAIL, | | | CB_RECALLABLE_OBJ_AVAIL, |
| | CB_RECALL_ANY, | | | CB_RECALL_ANY, |
| | CB_RECALL_SLOT, CB_SEQUENCE, | | | CB_RECALL_SLOT, CB_SEQUENCE, |
| | CB_WANTS_CANCELLED, CLOSE, | | | CB_WANTS_CANCELLED, CLOSE, |
| | COMMIT, CREATE, | | | COMMIT, CREATE, |
| | CREATE_SESSION, DELEGPURGE, | | | CREATE_SESSION, DELEGPURGE, |
| | DELEGRETURN, | | | DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, EXCHANGE_ID, | | | DESTROY_SESSION, |
| | FREE_STATEID, GETATTR, | | | EXCHANGE_ID, FREE_STATEID, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETATTR, GETDEVICEINFO, |
| | GETDEVICELIST, |
| | GET_DIR_DELEGATION, | | | GET_DIR_DELEGATION, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTCOMMIT, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, | | | LOCKT, LOCKU, LOOKUP, |
| | LOOKUPP, NVERIFY, OPEN, | | | LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_DOWNGRADE, | | | OPENATTR, OPEN_DOWNGRADE, |
| | PUTFH, PUTPUBFH, PUTROOTFH, | | | PUTFH, PUTPUBFH, PUTROOTFH, |
| | READ, READDIR, READLINK, | | | READ, READDIR, READLINK, |
| | RECLAIM_COMPLETE, REMOVE, | | | RECLAIM_COMPLETE, REMOVE, |
| | RENAME, RESTOREFH, SAVEFH, | | | RENAME, RESTOREFH, SAVEFH, |
| | SECINFO, SECINFO_NO_NAME, | | | SECINFO, SECINFO_NO_NAME, |
| | SEQUENCE, SETATTR, SET_SSV, | | | SEQUENCE, SETATTR, SET_SSV, |
| | TEST_STATEID, VERIFY, | | | TEST_STATEID, VERIFY, |
| | WANT_DELEGATION, WRITE | | | WANT_DELEGATION, WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_UNKNOWN_LAYOUTTYPE | CB_LAYOUTRECALL, | | NFS4ERR_UNKNOWN_LAYOUTTYPE | CB_LAYOUTRECALL, |
| | GETDEVICEINFO, GETDEVICELIST, | | | GETDEVICEINFO, |
| | LAYOUTCOMMIT, LAYOUTGET, | | | GETDEVICELIST, LAYOUTCOMMIT, |
| | LAYOUTRETURN, NVERIFY, | | | LAYOUTGET, LAYOUTRETURN, |
| | SETATTR, VERIFY | | | NVERIFY, SETATTR, VERIFY |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_UNSAFE_COMPOUND | CREATE, OPEN, OPENATTR | | NFS4ERR_UNSAFE_COMPOUND | CREATE, OPEN, OPENATTR |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_WRONGSEC | LINK, LOOKUP, LOOKUPP, OPEN, | | NFS4ERR_WRONGSEC | LINK, LOOKUP, LOOKUPP, OPEN, |
| | PUTFH, PUTPUBFH, PUTROOTFH, | | | PUTFH, PUTPUBFH, PUTROOTFH, |
| | RENAME, RESTOREFH | | | RENAME, RESTOREFH |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_WRONG_CRED | CLOSE, CREATE_SESSION, | | NFS4ERR_WRONG_CRED | CLOSE, CREATE_SESSION, |
| | DELEGPURGE, DELEGRETURN, | | | DELEGPURGE, DELEGRETURN, |
| | DESTROY_CLIENTID, | | | DESTROY_CLIENTID, |
| | DESTROY_SESSION, | | | DESTROY_SESSION, |
| | FREE_STATEID, LAYOUTCOMMIT, | | | FREE_STATEID, LAYOUTCOMMIT, |
| | LAYOUTRETURN, LOCK, LOCKT, | | | LAYOUTRETURN, LOCK, LOCKT, |
| | LOCKU, OPEN_DOWNGRADE, | | | LOCKU, OPEN_DOWNGRADE, |
| | RECLAIM_COMPLETE | | | RECLAIM_COMPLETE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_WRONG_TYPE | CB_LAYOUTRECALL, | | NFS4ERR_WRONG_TYPE | CB_LAYOUTRECALL, |
| | CB_PUSH_DELEG, COMMIT, | | | CB_PUSH_DELEG, COMMIT, |
| | GETATTR, LAYOUTGET, | | | GETATTR, LAYOUTGET, |
| | LAYOUTRETURN, LINK, LOCK, | | | LAYOUTRETURN, LINK, LOCK, |
| | LOCKT, NVERIFY, OPEN, | | | LOCKT, NVERIFY, OPEN, |
| | OPENATTR, READ, READLINK, | | | OPENATTR, READ, READLINK, |
| | RECLAIM_COMPLETE, SETATTR, | | | RECLAIM_COMPLETE, SETATTR, |
| | VERIFY, WANT_DELEGATION, | | | VERIFY, WANT_DELEGATION, |
| | WRITE | | | WRITE |
| | | +-----------------------------------+-------------------------------+
| NFS4ERR_XDEV | LINK, RENAME | | NFS4ERR_XDEV | LINK, RENAME |
| | |
+-----------------------------------+-------------------------------+ +-----------------------------------+-------------------------------+
Table 8 Table 14: Errors and the Operations That Use Them
16. NFSv4.1 Procedures 16. NFSv4.1 Procedures
Both procedures, NULL and COMPOUND, MUST be implemented. Both procedures, NULL and COMPOUND, MUST be implemented.
16.1. Procedure 0: NULL - No Operation 16.1. Procedure 0: NULL - No Operation
16.1.1. ARGUMENTS 16.1.1. ARGUMENTS
void; void;
skipping to change at page 432, line 18 skipping to change at line 20813
PUTFH fh1 {fh1} PUTFH fh1 {fh1}
LOOKUP "compA" {fh2} LOOKUP "compA" {fh2}
GETATTR {fh2} GETATTR {fh2}
LOOKUP "compB" {fh3} LOOKUP "compB" {fh3}
GETATTR {fh3} GETATTR {fh3}
LOOKUP "compC" {fh4} LOOKUP "compC" {fh4}
GETATTR {fh4} GETATTR {fh4}
GETFH GETFH
Figure 2 Figure 2
In this example, the PUTFH (Section 18.19) operation explicitly sets In this example, the PUTFH (Section 18.19) operation explicitly sets
the current filehandle value while the result of each LOOKUP the current filehandle value while the result of each LOOKUP
operation sets the current filehandle value to the resultant file operation sets the current filehandle value to the resultant file
system object. Also, the client is able to insert GETATTR operations system object. Also, the client is able to insert GETATTR operations
using the current filehandle as an argument. using the current filehandle as an argument.
The PUTROOTFH (Section 18.21) and PUTPUBFH (Section 18.20) operations The PUTROOTFH (Section 18.21) and PUTPUBFH (Section 18.20) operations
also set the current filehandle. The above example would replace also set the current filehandle. The above example would replace
"PUTFH fh1" with PUTROOTFH or PUTPUBFH with no filehandle argument in "PUTFH fh1" with PUTROOTFH or PUTPUBFH with no filehandle argument in
skipping to change at page 433, line 30 skipping to change at line 20871
current filehandle and the current stateid as a set. current filehandle and the current stateid as a set.
The following example is the common case of a simple READ operation The following example is the common case of a simple READ operation
with a normal stateid showing that the PUTFH initializes the current with a normal stateid showing that the PUTFH initializes the current
stateid to (0, 0). The subsequent READ with stateid (sid1) leaves stateid to (0, 0). The subsequent READ with stateid (sid1) leaves
the current stateid unchanged. the current stateid unchanged.
PUTFH fh1 - -> {fh1, (0, 0)} PUTFH fh1 - -> {fh1, (0, 0)}
READ (sid1), 0, 1024 {fh1, (0, 0)} -> {fh1, (0, 0)} READ (sid1), 0, 1024 {fh1, (0, 0)} -> {fh1, (0, 0)}
Figure 3 Figure 3
This next example performs an OPEN with the root filehandle and, as a This next example performs an OPEN with the root filehandle and, as a
result, generates stateid (sid1). The next operation specifies the result, generates stateid (sid1). The next operation specifies the
READ with the argument stateid set such that (seqid, other) are equal READ with the argument stateid set such that (seqid, other) are equal
to (1, 0), but the current stateid set by the previous operation is to (1, 0), but the current stateid set by the previous operation is
actually used when the operation is evaluated. This allows correct actually used when the operation is evaluated. This allows correct
interaction with any existing, potentially conflicting, locks. interaction with any existing, potentially conflicting, locks.
PUTROOTFH - -> {fh1, (0, 0)} PUTROOTFH - -> {fh1, (0, 0)}
OPEN "compA" {fh1, (0, 0)} -> {fh2, (sid1)} OPEN "compA" {fh1, (0, 0)} -> {fh2, (sid1)}
READ (1, 0), 0, 1024 {fh2, (sid1)} -> {fh2, (sid1)} READ (1, 0), 0, 1024 {fh2, (sid1)} -> {fh2, (sid1)}
CLOSE (1, 0) {fh2, (sid1)} -> {fh2, (sid2)} CLOSE (1, 0) {fh2, (sid1)} -> {fh2, (sid2)}
Figure 4 Figure 4
This next example is similar to the second in how it passes the This next example is similar to the second in how it passes the
stateid sid2 generated by the LOCK operation to the next READ stateid sid2 generated by the LOCK operation to the next READ
operation. This allows the client to explicitly surround a single I/ operation. This allows the client to explicitly surround a single I/
O operation with a lock and its appropriate stateid to guarantee O operation with a lock and its appropriate stateid to guarantee
correctness with other client locks. The example also shows how correctness with other client locks. The example also shows how
SAVEFH and RESTOREFH can save and later reuse a filehandle and SAVEFH and RESTOREFH can save and later reuse a filehandle and
stateid, passing them as the current filehandle and stateid to a READ stateid, passing them as the current filehandle and stateid to a READ
operation. operation.
skipping to change at page 434, line 19 skipping to change at line 20908
READ (1, 0), 0, 1024 {fh1, (sid2)} -> {fh1, (sid2)} READ (1, 0), 0, 1024 {fh1, (sid2)} -> {fh1, (sid2)}
LOCKU 0, 1024, (1, 0) {fh1, (sid2)} -> {fh1, (sid3)} LOCKU 0, 1024, (1, 0) {fh1, (sid2)} -> {fh1, (sid3)}
SAVEFH {fh1, (sid3)} -> {fh1, (sid3)} SAVEFH {fh1, (sid3)} -> {fh1, (sid3)}
PUTFH fh2 {fh1, (sid3)} -> {fh2, (0, 0)} PUTFH fh2 {fh1, (sid3)} -> {fh2, (0, 0)}
WRITE (1, 0), 0, 1024 {fh2, (0, 0)} -> {fh2, (0, 0)} WRITE (1, 0), 0, 1024 {fh2, (0, 0)} -> {fh2, (0, 0)}
RESTOREFH {fh2, (0, 0)} -> {fh1, (sid3)} RESTOREFH {fh2, (0, 0)} -> {fh1, (sid3)}
READ (1, 0), 1024, 1024 {fh1, (sid3)} -> {fh1, (sid3)} READ (1, 0), 1024, 1024 {fh1, (sid3)} -> {fh1, (sid3)}
Figure 5 Figure 5
The final example shows a disallowed use of the current stateid. The The final example shows a disallowed use of the current stateid. The
client is attempting to implicitly pass an anonymous special stateid, client is attempting to implicitly pass an anonymous special stateid,
(0,0), to the READ operation. The server MUST return (0,0), to the READ operation. The server MUST return
NFS4ERR_BAD_STATEID in the reply to the READ operation. NFS4ERR_BAD_STATEID in the reply to the READ operation.
PUTFH fh1 - -> {fh1, (0, 0)} PUTFH fh1 - -> {fh1, (0, 0)}
READ (1, 0), 0, 1024 {fh1, (0, 0)} -> NFS4ERR_BAD_STATEID READ (1, 0), 0, 1024 {fh1, (0, 0)} -> NFS4ERR_BAD_STATEID
Figure 6 Figure 6
16.2.4. ERRORS 16.2.4. ERRORS
COMPOUND will of course return every error that each operation on the COMPOUND will of course return every error that each operation on the
fore channel can return (see Table 6). However, if COMPOUND returns fore channel can return (see Table 12). However, if COMPOUND returns
zero operations, obviously the error returned by COMPOUND has nothing zero operations, obviously the error returned by COMPOUND has nothing
to do with an error returned by an operation. The list of errors to do with an error returned by an operation. The list of errors
COMPOUND will return if it processes zero operations include: COMPOUND will return if it processes zero operations include:
COMPOUND Error Returns +==============================+==================================+
| Error | Notes |
+------------------------------+------------------------------------+ +==============================+==================================+
| Error | Notes | | NFS4ERR_BADCHAR | The tag argument has a character |
+------------------------------+------------------------------------+ | | the replier does not support. |
| NFS4ERR_BADCHAR | The tag argument has a character | +------------------------------+----------------------------------+
| | the replier does not support. | | NFS4ERR_BADXDR | |
| NFS4ERR_BADXDR | | +------------------------------+----------------------------------+
| NFS4ERR_DELAY | | | NFS4ERR_DELAY | |
| NFS4ERR_INVAL | The tag argument is not in UTF-8 | +------------------------------+----------------------------------+
| | encoding. | | NFS4ERR_INVAL | The tag argument is not in UTF-8 |
| NFS4ERR_MINOR_VERS_MISMATCH | | | | encoding. |
| NFS4ERR_SERVERFAULT | | +------------------------------+----------------------------------+
| NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_MINOR_VERS_MISMATCH | |
| NFS4ERR_REP_TOO_BIG | | +------------------------------+----------------------------------+
| NFS4ERR_REP_TOO_BIG_TO_CACHE | | | NFS4ERR_SERVERFAULT | |
| NFS4ERR_REQ_TOO_BIG | | +------------------------------+----------------------------------+
+------------------------------+------------------------------------+ | NFS4ERR_TOO_MANY_OPS | |
+------------------------------+----------------------------------+
| NFS4ERR_REP_TOO_BIG | |
+------------------------------+----------------------------------+
| NFS4ERR_REP_TOO_BIG_TO_CACHE | |
+------------------------------+----------------------------------+
| NFS4ERR_REQ_TOO_BIG | |
+------------------------------+----------------------------------+
Table 9 Table 15: COMPOUND Error Returns
17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL 17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL
The following tables summarize the operations of the NFSv4.1 protocol The following tables summarize the operations of the NFSv4.1 protocol
and the corresponding designation of REQUIRED, RECOMMENDED, and and the corresponding designation of REQUIRED, RECOMMENDED, and
OPTIONAL to implement or MUST NOT implement. The designation of MUST OPTIONAL to implement or MUST NOT implement. The designation of MUST
NOT implement is reserved for those operations that were defined in NOT implement is reserved for those operations that were defined in
NFSv4.0 and MUST NOT be implemented in NFSv4.1. NFSv4.0 and MUST NOT be implemented in NFSv4.1.
For the most part, the REQUIRED, RECOMMENDED, or OPTIONAL designation For the most part, the REQUIRED, RECOMMENDED, or OPTIONAL designation
skipping to change at page 436, line 36 skipping to change at line 21014
The OPTIONAL features identified and their abbreviations are as The OPTIONAL features identified and their abbreviations are as
follows: follows:
pNFS Parallel NFS pNFS Parallel NFS
FDELG File Delegations FDELG File Delegations
DDELG Directory Delegations DDELG Directory Delegations
Operations +======================+=============+============+===============+
| Operation | REQ, REC, | Feature | Definition |
| | OPT, or MNI | (REQ, REC, | |
| | | or OPT) | |
+======================+=============+============+===============+
| ACCESS | REQ | | Section 18.1 |
+----------------------+-------------+------------+---------------+
| BACKCHANNEL_CTL | REQ | | Section 18.33 |
+----------------------+-------------+------------+---------------+
| BIND_CONN_TO_SESSION | REQ | | Section 18.34 |
+----------------------+-------------+------------+---------------+
| CLOSE | REQ | | Section 18.2 |
+----------------------+-------------+------------+---------------+
| COMMIT | REQ | | Section 18.3 |
+----------------------+-------------+------------+---------------+
| CREATE | REQ | | Section 18.4 |
+----------------------+-------------+------------+---------------+
| CREATE_SESSION | REQ | | Section 18.36 |
+----------------------+-------------+------------+---------------+
| DELEGPURGE | OPT | FDELG | Section 18.5 |
| | | (REQ) | |
+----------------------+-------------+------------+---------------+
| DELEGRETURN | OPT | FDELG, | Section 18.6 |
| | | DDELG, | |
| | | pNFS (REQ) | |
+----------------------+-------------+------------+---------------+
| DESTROY_CLIENTID | REQ | | Section 18.50 |
+----------------------+-------------+------------+---------------+
| DESTROY_SESSION | REQ | | Section 18.37 |
+----------------------+-------------+------------+---------------+
| EXCHANGE_ID | REQ | | Section 18.35 |
+----------------------+-------------+------------+---------------+
| FREE_STATEID | REQ | | Section 18.38 |
+----------------------+-------------+------------+---------------+
| GETATTR | REQ | | Section 18.7 |
+----------------------+-------------+------------+---------------+
| GETDEVICEINFO | OPT | pNFS (REQ) | Section 18.40 |
+----------------------+-------------+------------+---------------+
| GETDEVICELIST | OPT | pNFS (OPT) | Section 18.41 |
+----------------------+-------------+------------+---------------+
| GETFH | REQ | | Section 18.8 |
+----------------------+-------------+------------+---------------+
| GET_DIR_DELEGATION | OPT | DDELG | Section 18.39 |
| | | (REQ) | |
+----------------------+-------------+------------+---------------+
| LAYOUTCOMMIT | OPT | pNFS (REQ) | Section 18.42 |
+----------------------+-------------+------------+---------------+
| LAYOUTGET | OPT | pNFS (REQ) | Section 18.43 |
+----------------------+-------------+------------+---------------+
| LAYOUTRETURN | OPT | pNFS (REQ) | Section 18.44 |
+----------------------+-------------+------------+---------------+
| LINK | OPT | | Section 18.9 |
+----------------------+-------------+------------+---------------+
| LOCK | REQ | | Section 18.10 |
+----------------------+-------------+------------+---------------+
| LOCKT | REQ | | Section 18.11 |
+----------------------+-------------+------------+---------------+
| LOCKU | REQ | | Section 18.12 |
+----------------------+-------------+------------+---------------+
| LOOKUP | REQ | | Section 18.13 |
+----------------------+-------------+------------+---------------+
| LOOKUPP | REQ | | Section 18.14 |
+----------------------+-------------+------------+---------------+
| NVERIFY | REQ | | Section 18.15 |
+----------------------+-------------+------------+---------------+
| OPEN | REQ | | Section 18.16 |
+----------------------+-------------+------------+---------------+
| OPENATTR | OPT | | Section 18.17 |
+----------------------+-------------+------------+---------------+
| OPEN_CONFIRM | MNI | | N/A |
+----------------------+-------------+------------+---------------+
| OPEN_DOWNGRADE | REQ | | Section 18.18 |
+----------------------+-------------+------------+---------------+
| PUTFH | REQ | | Section 18.19 |
+----------------------+-------------+------------+---------------+
| PUTPUBFH | REQ | | Section 18.20 |
+----------------------+-------------+------------+---------------+
| PUTROOTFH | REQ | | Section 18.21 |
+----------------------+-------------+------------+---------------+
| READ | REQ | | Section 18.22 |
+----------------------+-------------+------------+---------------+
| READDIR | REQ | | Section 18.23 |
+----------------------+-------------+------------+---------------+
| READLINK | OPT | | Section 18.24 |
+----------------------+-------------+------------+---------------+
| RECLAIM_COMPLETE | REQ | | Section 18.51 |
+----------------------+-------------+------------+---------------+
| RELEASE_LOCKOWNER | MNI | | N/A |
+----------------------+-------------+------------+---------------+
| REMOVE | REQ | | Section 18.25 |
+----------------------+-------------+------------+---------------+
| RENAME | REQ | | Section 18.26 |
+----------------------+-------------+------------+---------------+
| RENEW | MNI | | N/A |
+----------------------+-------------+------------+---------------+
| RESTOREFH | REQ | | Section 18.27 |
+----------------------+-------------+------------+---------------+
| SAVEFH | REQ | | Section 18.28 |
+----------------------+-------------+------------+---------------+
| SECINFO | REQ | | Section 18.29 |
+----------------------+-------------+------------+---------------+
| SECINFO_NO_NAME | REC | pNFS file | Section |
| | | layout | 18.45, |
| | | (REQ) | Section 13.12 |
+----------------------+-------------+------------+---------------+
| SEQUENCE | REQ | | Section 18.46 |
+----------------------+-------------+------------+---------------+
| SETATTR | REQ | | Section 18.30 |
+----------------------+-------------+------------+---------------+
| SETCLIENTID | MNI | | N/A |
+----------------------+-------------+------------+---------------+
| SETCLIENTID_CONFIRM | MNI | | N/A |
+----------------------+-------------+------------+---------------+
| SET_SSV | REQ | | Section 18.47 |
+----------------------+-------------+------------+---------------+
| TEST_STATEID | REQ | | Section 18.48 |
+----------------------+-------------+------------+---------------+
| VERIFY | REQ | | Section 18.31 |
+----------------------+-------------+------------+---------------+
| WANT_DELEGATION | OPT | FDELG | Section 18.49 |
| | | (OPT) | |
+----------------------+-------------+------------+---------------+
| WRITE | REQ | | Section 18.32 |
+----------------------+-------------+------------+---------------+
+----------------------+------------+--------------+----------------+ Table 16: Operations
| Operation | REQ, REC, | Feature | Definition |
| | OPT, or | (REQ, REC, | |
| | MNI | or OPT) | |
+----------------------+------------+--------------+----------------+
| ACCESS | REQ | | Section 18.1 |
| BACKCHANNEL_CTL | REQ | | Section 18.33 |
| BIND_CONN_TO_SESSION | REQ | | Section 18.34 |
| CLOSE | REQ | | Section 18.2 |
| COMMIT | REQ | | Section 18.3 |
| CREATE | REQ | | Section 18.4 |
| CREATE_SESSION | REQ | | Section 18.36 |
| DELEGPURGE | OPT | FDELG (REQ) | Section 18.5 |
| DELEGRETURN | OPT | FDELG, | Section 18.6 |
| | | DDELG, pNFS | |
| | | (REQ) | |
| DESTROY_CLIENTID | REQ | | Section 18.50 |
| DESTROY_SESSION | REQ | | Section 18.37 |
| EXCHANGE_ID | REQ | | Section 18.35 |
| FREE_STATEID | REQ | | Section 18.38 |
| GETATTR | REQ | | Section 18.7 |
| GETDEVICEINFO | OPT | pNFS (REQ) | Section 18.40 |
| GETDEVICELIST | OPT | pNFS (OPT) | Section 18.41 |
| GETFH | REQ | | Section 18.8 |
| GET_DIR_DELEGATION | OPT | DDELG (REQ) | Section 18.39 |
| LAYOUTCOMMIT | OPT | pNFS (REQ) | Section 18.42 |
| LAYOUTGET | OPT | pNFS (REQ) | Section 18.43 |
| LAYOUTRETURN | OPT | pNFS (REQ) | Section 18.44 |
| LINK | OPT | | Section 18.9 |
| LOCK | REQ | | Section 18.10 |
| LOCKT | REQ | | Section 18.11 |
| LOCKU | REQ | | Section 18.12 |
| LOOKUP | REQ | | Section 18.13 |
| LOOKUPP | REQ | | Section 18.14 |
| NVERIFY | REQ | | Section 18.15 |
| OPEN | REQ | | Section 18.16 |
| OPENATTR | OPT | | Section 18.17 |
| OPEN_CONFIRM | MNI | | N/A |
| OPEN_DOWNGRADE | REQ | | Section 18.18 |
| PUTFH | REQ | | Section 18.19 |
| PUTPUBFH | REQ | | Section 18.20 |
| PUTROOTFH | REQ | | Section 18.21 |
| READ | REQ | | Section 18.22 |
| READDIR | REQ | | Section 18.23 |
| READLINK | OPT | | Section 18.24 |
| RECLAIM_COMPLETE | REQ | | Section 18.51 |
| RELEASE_LOCKOWNER | MNI | | N/A |
| REMOVE | REQ | | Section 18.25 |
| RENAME | REQ | | Section 18.26 |
| RENEW | MNI | | N/A |
| RESTOREFH | REQ | | Section 18.27 |
| SAVEFH | REQ | | Section 18.28 |
| SECINFO | REQ | | Section 18.29 |
| SECINFO_NO_NAME | REC | pNFS file | Section 18.45, |
| | | layout (REQ) | Section 13.12 |
| SEQUENCE | REQ | | Section 18.46 |
| SETATTR | REQ | | Section 18.30 |
| SETCLIENTID | MNI | | N/A |
| SETCLIENTID_CONFIRM | MNI | | N/A |
| SET_SSV | REQ | | Section 18.47 |
| TEST_STATEID | REQ | | Section 18.48 |
| VERIFY | REQ | | Section 18.31 |
| WANT_DELEGATION | OPT | FDELG (OPT) | Section 18.49 |
| WRITE | REQ | | Section 18.32 |
+----------------------+------------+--------------+----------------+
Callback Operations +=========================+=============+============+============+
| Operation | REQ, REC, | Feature | Definition |
| | OPT, or MNI | (REQ, REC, | |
| | | or OPT) | |
+=========================+=============+============+============+
| CB_GETATTR | OPT | FDELG | Section |
| | | (REQ) | 20.1 |
+-------------------------+-------------+------------+------------+
| CB_LAYOUTRECALL | OPT | pNFS (REQ) | Section |
| | | | 20.3 |
+-------------------------+-------------+------------+------------+
| CB_NOTIFY | OPT | DDELG | Section |
| | | (REQ) | 20.4 |
+-------------------------+-------------+------------+------------+
| CB_NOTIFY_DEVICEID | OPT | pNFS (OPT) | Section |
| | | | 20.12 |
+-------------------------+-------------+------------+------------+
| CB_NOTIFY_LOCK | OPT | | Section |
| | | | 20.11 |
+-------------------------+-------------+------------+------------+
| CB_PUSH_DELEG | OPT | FDELG | Section |
| | | (OPT) | 20.5 |
+-------------------------+-------------+------------+------------+
| CB_RECALL | OPT | FDELG, | Section |
| | | DDELG, | 20.2 |
| | | pNFS (REQ) | |
+-------------------------+-------------+------------+------------+
| CB_RECALL_ANY | OPT | FDELG, | Section |
| | | DDELG, | 20.6 |
| | | pNFS (REQ) | |
+-------------------------+-------------+------------+------------+
| CB_RECALL_SLOT | REQ | | Section |
| | | | 20.8 |
+-------------------------+-------------+------------+------------+
| CB_RECALLABLE_OBJ_AVAIL | OPT | DDELG, | Section |
| | | pNFS (REQ) | 20.7 |
+-------------------------+-------------+------------+------------+
| CB_SEQUENCE | OPT | FDELG, | Section |
| | | DDELG, | 20.9 |
| | | pNFS (REQ) | |
+-------------------------+-------------+------------+------------+
| CB_WANTS_CANCELLED | OPT | FDELG, | Section |
| | | DDELG, | 20.10 |
| | | pNFS (REQ) | |
+-------------------------+-------------+------------+------------+
+-------------------------+------------+---------------+------------+ Table 17: Callback Operations
| Operation | REQ, REC, | Feature (REQ, | Definition |
| | OPT, or | REC, or OPT) | |
| | MNI | | |
+-------------------------+------------+---------------+------------+
| CB_GETATTR | OPT | FDELG (REQ) | Section |
| | | | 20.1 |
| CB_LAYOUTRECALL | OPT | pNFS (REQ) | Section |
| | | | 20.3 |
| CB_NOTIFY | OPT | DDELG (REQ) | Section |
| | | | 20.4 |
| CB_NOTIFY_DEVICEID | OPT | pNFS (OPT) | Section |
| | | | 20.12 |
| CB_NOTIFY_LOCK | OPT | | Section |
| | | | 20.11 |
| CB_PUSH_DELEG | OPT | FDELG (OPT) | Section |
| | | | 20.5 |
| CB_RECALL | OPT | FDELG, DDELG, | Section |
| | | pNFS (REQ) | 20.2 |
| CB_RECALL_ANY | OPT | FDELG, DDELG, | Section |
| | | pNFS (REQ) | 20.6 |
| CB_RECALL_SLOT | REQ | | Section |
| | | | 20.8 |
| CB_RECALLABLE_OBJ_AVAIL | OPT | DDELG, pNFS | Section |
| | | (REQ) | 20.7 |
| CB_SEQUENCE | OPT | FDELG, DDELG, | Section |
| | | pNFS (REQ) | 20.9 |
| CB_WANTS_CANCELLED | OPT | FDELG, DDELG, | Section |
| | | pNFS (REQ) | 20.10 |
+-------------------------+------------+---------------+------------+
18. NFSv4.1 Operations 18. NFSv4.1 Operations
18.1. Operation 3: ACCESS - Check Access Rights 18.1. Operation 3: ACCESS - Check Access Rights
18.1.1. ARGUMENTS 18.1.1. ARGUMENTS
const ACCESS4_READ = 0x00000001; const ACCESS4_READ = 0x00000001;
const ACCESS4_LOOKUP = 0x00000002; const ACCESS4_LOOKUP = 0x00000002;
const ACCESS4_MODIFY = 0x00000004; const ACCESS4_MODIFY = 0x00000004;
const ACCESS4_EXTEND = 0x00000008; const ACCESS4_EXTEND = 0x00000008;
const ACCESS4_DELETE = 0x00000010; const ACCESS4_DELETE = 0x00000010;
const ACCESS4_EXECUTE = 0x00000020; const ACCESS4_EXECUTE = 0x00000020;
struct ACCESS4args { struct ACCESS4args {
/* CURRENT_FH: object */ /* CURRENT_FH: object */
uint32_t access; uint32_t access;
skipping to change at page 440, line 36 skipping to change at line 21272
ACCESS4_DELETE Delete an existing directory entry. ACCESS4_DELETE Delete an existing directory entry.
ACCESS4_EXECUTE Execute a regular file (no meaning for a directory). ACCESS4_EXECUTE Execute a regular file (no meaning for a directory).
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
ACCESS4_EXECUTE is a challenging semantic to implement because NFS ACCESS4_EXECUTE is a challenging semantic to implement because NFS
provides remote file access, not remote execution. This leads to the provides remote file access, not remote execution. This leads to the
following: following:
o Whether or not a regular file is executable ought to be the * Whether or not a regular file is executable ought to be the
responsibility of the NFS client and not the server. And yet the responsibility of the NFS client and not the server. And yet the
ACCESS operation is specified to seemingly require a server to own ACCESS operation is specified to seemingly require a server to own
that responsibility. that responsibility.
o When a client executes a regular file, it has to read the file * When a client executes a regular file, it has to read the file
from the server. Strictly speaking, the server should not allow from the server. Strictly speaking, the server should not allow
the client to read a file being executed unless the user has read the client to read a file being executed unless the user has read
permissions on the file. Requiring explicit read permissions on permissions on the file. Requiring explicit read permissions on
executable files in order to access them over NFS is not going to executable files in order to access them over NFS is not going to
be acceptable to some users and storage administrators. be acceptable to some users and storage administrators.
Historically, NFS servers have allowed a user to READ a file if Historically, NFS servers have allowed a user to READ a file if
the user has execute access to the file. the user has execute access to the file.
As a practical example, the UNIX specification [59] states that an As a practical example, the UNIX specification [60] states that an
implementation claiming conformance to UNIX may indicate in the implementation claiming conformance to UNIX may indicate in the
access() programming interface's result that a privileged user has access() programming interface's result that a privileged user has
execute rights, even if no execute permission bits are set on the execute rights, even if no execute permission bits are set on the
regular file's attributes. It is possible to claim conformance to regular file's attributes. It is possible to claim conformance to
the UNIX specification and instead not indicate execute rights in the UNIX specification and instead not indicate execute rights in
that situation, which is true for some operating environments. that situation, which is true for some operating environments.
Suppose the operating environments of the client and server are Suppose the operating environments of the client and server are
implementing the access() semantics for privileged users differently, implementing the access() semantics for privileged users differently,
and the ACCESS operation implementations of the client and server and the ACCESS operation implementations of the client and server
follow their respective access() semantics. This can cause undesired follow their respective access() semantics. This can cause undesired
behavior: behavior:
o Suppose the client's access() interface returns X_OK if the user * Suppose the client's access() interface returns X_OK if the user
is privileged and no execute permission bits are set on the is privileged and no execute permission bits are set on the
regular file's attribute, and the server's access() interface does regular file's attribute, and the server's access() interface does
not return X_OK in that situation. Then the client will be unable not return X_OK in that situation. Then the client will be unable
to execute files stored on the NFS server that could be executed to execute files stored on the NFS server that could be executed
if stored on a non-NFS file system. if stored on a non-NFS file system.
o Suppose the client's access() interface does not return X_OK if * Suppose the client's access() interface does not return X_OK if
the user is privileged, and no execute permission bits are set on the user is privileged, and no execute permission bits are set on
the regular file's attribute, and the server's access() interface the regular file's attribute, and the server's access() interface
does return X_OK in that situation. Then: does return X_OK in that situation. Then:
* The client will be able to execute files stored on the NFS - The client will be able to execute files stored on the NFS
server that could be executed if stored on a non-NFS file server that could be executed if stored on a non-NFS file
system, unless the client's execution subsystem also checks for system, unless the client's execution subsystem also checks for
execute permission bits. execute permission bits.
* Even if the execution subsystem is checking for execute - Even if the execution subsystem is checking for execute
permission bits, there are more potential issues. For example, permission bits, there are more potential issues. For example,
suppose the client is invoking access() to build a "path search suppose the client is invoking access() to build a "path search
table" of all executable files in the user's "search path", table" of all executable files in the user's "search path",
where the path is a list of directories each containing where the path is a list of directories each containing
executable files. Suppose there are two files each in separate executable files. Suppose there are two files each in separate
directories of the search path, such that files have the same directories of the search path, such that files have the same
component name. In the first directory the file has no execute component name. In the first directory the file has no execute
permission bits set, and in the second directory the file has permission bits set, and in the second directory the file has
execute bits set. The path search table will indicate that the execute bits set. The path search table will indicate that the
first directory has the executable file, but the execute first directory has the executable file, but the execute
skipping to change at page 442, line 7 skipping to change at line 21339
if it did, this is a potential performance issue. Clearly, the if it did, this is a potential performance issue. Clearly, the
desired outcome for the client is for the path search table to desired outcome for the client is for the path search table to
not contain the first file. not contain the first file.
To deal with the problems described above, the "smart client, stupid To deal with the problems described above, the "smart client, stupid
server" principle is used. The client owns overall responsibility server" principle is used. The client owns overall responsibility
for determining execute access and relies on the server to parse the for determining execute access and relies on the server to parse the
execution permissions within the file's mode, acl, and dacl execution permissions within the file's mode, acl, and dacl
attributes. The rules for the client and server follow: attributes. The rules for the client and server follow:
o If the client is sending ACCESS in order to determine if the user * If the client is sending ACCESS in order to determine if the user
can read the file, the client SHOULD set ACCESS4_READ in the can read the file, the client SHOULD set ACCESS4_READ in the
request's access field. request's access field.
o If the client's operating environment only grants execution to the * If the client's operating environment only grants execution to the
user if the user has execute access according to the execute user if the user has execute access according to the execute
permissions in the mode, acl, and dacl attributes, then if the permissions in the mode, acl, and dacl attributes, then if the
client wants to determine execute access, the client SHOULD send client wants to determine execute access, the client SHOULD send
an ACCESS request with ACCESS4_EXECUTE bit set in the request's an ACCESS request with ACCESS4_EXECUTE bit set in the request's
access field. access field.
o If the client's operating environment grants execution to the user * If the client's operating environment grants execution to the user
even if the user does not have execute access according to the even if the user does not have execute access according to the
execute permissions in the mode, acl, and dacl attributes, then if execute permissions in the mode, acl, and dacl attributes, then if
the client wants to determine execute access, it SHOULD send an the client wants to determine execute access, it SHOULD send an
ACCESS request with both the ACCESS4_EXECUTE and ACCESS4_READ bits ACCESS request with both the ACCESS4_EXECUTE and ACCESS4_READ bits
set in the request's access field. This way, if any read or set in the request's access field. This way, if any read or
execute permission grants the user read or execute access (or if execute permission grants the user read or execute access (or if
the server interprets the user as privileged), as indicated by the the server interprets the user as privileged), as indicated by the
presence of ACCESS4_EXECUTE and/or ACCESS4_READ in the reply's presence of ACCESS4_EXECUTE and/or ACCESS4_READ in the reply's
access field, the client will be able to grant the user execute access field, the client will be able to grant the user execute
access to the file. access to the file.
o If the server supports execute permission bits, or some other * If the server supports execute permission bits, or some other
method for denoting executability (e.g., the suffix of the name of method for denoting executability (e.g., the suffix of the name of
the file might indicate execute), it MUST check only execute the file might indicate execute), it MUST check only execute
permissions, not read permissions, when determining whether or not permissions, not read permissions, when determining whether or not
the reply will have ACCESS4_EXECUTE set in the access field. The the reply will have ACCESS4_EXECUTE set in the access field. The
server MUST NOT also examine read permission bits when determining server MUST NOT also examine read permission bits when determining
whether or not the reply will have ACCESS4_EXECUTE set in the whether or not the reply will have ACCESS4_EXECUTE set in the
access field. Even if the server's operating environment would access field. Even if the server's operating environment would
grant execute access to the user (e.g., the user is privileged), grant execute access to the user (e.g., the user is privileged),
the server MUST NOT reply with ACCESS4_EXECUTE set in reply's the server MUST NOT reply with ACCESS4_EXECUTE set in reply's
access field unless there is at least one execute permission bit access field unless there is at least one execute permission bit
set in the mode, acl, or dacl attributes. In the case of acl and set in the mode, acl, or dacl attributes. In the case of acl and
dacl, the "one execute permission bit" MUST be an ACE4_EXECUTE bit dacl, the "one execute permission bit" MUST be an ACE4_EXECUTE bit
set in an ALLOW ACE. set in an ALLOW ACE.
o If the server does not support execute permission bits or some * If the server does not support execute permission bits or some
other method for denoting executability, it MUST NOT set other method for denoting executability, it MUST NOT set
ACCESS4_EXECUTE in the reply's supported and access fields. If ACCESS4_EXECUTE in the reply's supported and access fields. If
the client set ACCESS4_EXECUTE in the ACCESS request's access the client set ACCESS4_EXECUTE in the ACCESS request's access
field, and ACCESS4_EXECUTE is not set in the reply's supported field, and ACCESS4_EXECUTE is not set in the reply's supported
field, then the client will have to send an ACCESS request with field, then the client will have to send an ACCESS request with
the ACCESS4_READ bit set in the request's access field. the ACCESS4_READ bit set in the request's access field.
o If the server supports read permission bits, it MUST only check * If the server supports read permission bits, it MUST only check
for read permissions in the mode, acl, and dacl attributes when it for read permissions in the mode, acl, and dacl attributes when it
receives an ACCESS request with ACCESS4_READ set in the access receives an ACCESS request with ACCESS4_READ set in the access
field. The server MUST NOT also examine execute permission bits field. The server MUST NOT also examine execute permission bits
when determining whether the reply will have ACCESS4_READ set in when determining whether the reply will have ACCESS4_READ set in
the access field or not. the access field or not.
Note that if the ACCESS reply has ACCESS4_READ or ACCESS_EXECUTE set, Note that if the ACCESS reply has ACCESS4_READ or ACCESS_EXECUTE set,
then the user also has permissions to OPEN (Section 18.16) or READ then the user also has permissions to OPEN (Section 18.16) or READ
(Section 18.22) the file. In other words, if the client sends an (Section 18.22) the file. In other words, if the client sends an
ACCESS request with the ACCESS4_READ and ACCESS_EXECUTE set in the ACCESS request with the ACCESS4_READ and ACCESS_EXECUTE set in the
skipping to change at page 449, line 26 skipping to change at line 21680
18.4.3. DESCRIPTION 18.4.3. DESCRIPTION
The CREATE operation creates a file object other than an ordinary The CREATE operation creates a file object other than an ordinary
file in a directory with a given name. The OPEN operation MUST be file in a directory with a given name. The OPEN operation MUST be
used to create a regular file or a named attribute. used to create a regular file or a named attribute.
The current filehandle must be a directory: an object of type NF4DIR. The current filehandle must be a directory: an object of type NF4DIR.
If the current filehandle is an attribute directory (type If the current filehandle is an attribute directory (type
NF4ATTRDIR), the error NFS4ERR_WRONG_TYPE is returned. If the NF4ATTRDIR), the error NFS4ERR_WRONG_TYPE is returned. If the
current file handle designates any other type of object, the error current filehandle designates any other type of object, the error
NFS4ERR_NOTDIR results. NFS4ERR_NOTDIR results.
The objname specifies the name for the new object. The objtype The objname specifies the name for the new object. The objtype
determines the type of object to be created: directory, symlink, etc. determines the type of object to be created: directory, symlink, etc.
If the object type specified is that of an ordinary file, a named If the object type specified is that of an ordinary file, a named
attribute, or a named attribute directory, the error NFS4ERR_BADTYPE attribute, or a named attribute directory, the error NFS4ERR_BADTYPE
results. results.
If an object of the same name already exists in the directory, the If an object of the same name already exists in the directory, the
server will return the error NFS4ERR_EXIST. server will return the error NFS4ERR_EXIST.
skipping to change at page 454, line 17 skipping to change at line 21900
Suppose there is an OPEN_DELEGATE_WRITE delegation held by another Suppose there is an OPEN_DELEGATE_WRITE delegation held by another
client for the file in question and size and/or change are among the client for the file in question and size and/or change are among the
set of attributes being interrogated. The server has two choices. set of attributes being interrogated. The server has two choices.
First, the server can obtain the actual current value of these First, the server can obtain the actual current value of these
attributes from the client holding the delegation by using the attributes from the client holding the delegation by using the
CB_GETATTR callback. Second, the server, particularly when the CB_GETATTR callback. Second, the server, particularly when the
delegated client is unresponsive, can recall the delegation in delegated client is unresponsive, can recall the delegation in
question. The GETATTR MUST NOT proceed until one of the following question. The GETATTR MUST NOT proceed until one of the following
occurs: occurs:
o The requested attribute values are returned in the response to * The requested attribute values are returned in the response to
CB_GETATTR. CB_GETATTR.
o The OPEN_DELEGATE_WRITE delegation is returned. * The OPEN_DELEGATE_WRITE delegation is returned.
o The OPEN_DELEGATE_WRITE delegation is revoked. * The OPEN_DELEGATE_WRITE delegation is revoked.
Unless one of the above happens very quickly, one or more Unless one of the above happens very quickly, one or more
NFS4ERR_DELAY errors will be returned while a delegation is NFS4ERR_DELAY errors will be returned while a delegation is
outstanding. outstanding.
18.8. Operation 10: GETFH - Get Current Filehandle 18.8. Operation 10: GETFH - Get Current Filehandle
18.8.1. ARGUMENTS 18.8.1. ARGUMENTS
/* CURRENT_FH: */ /* CURRENT_FH: */
skipping to change at page 460, line 37 skipping to change at line 22152
specified by the offset and length parameters, and lock type specified by the offset and length parameters, and lock type
specified in the locktype parameter. If this is a reclaim request, specified in the locktype parameter. If this is a reclaim request,
the reclaim parameter will be TRUE. the reclaim parameter will be TRUE.
Bytes in a file may be locked even if those bytes are not currently Bytes in a file may be locked even if those bytes are not currently
allocated to the file. To lock the file from a specific offset allocated to the file. To lock the file from a specific offset
through the end-of-file (no matter how long the file actually is) use through the end-of-file (no matter how long the file actually is) use
a length field equal to NFS4_UINT64_MAX. The server MUST return a length field equal to NFS4_UINT64_MAX. The server MUST return
NFS4ERR_INVAL under the following combinations of length and offset: NFS4ERR_INVAL under the following combinations of length and offset:
o Length is equal to zero. * Length is equal to zero.
o Length is not equal to NFS4_UINT64_MAX, and the sum of length and * Length is not equal to NFS4_UINT64_MAX, and the sum of length and
offset exceeds NFS4_UINT64_MAX. offset exceeds NFS4_UINT64_MAX.
32-bit servers are servers that support locking for byte offsets that 32-bit servers are servers that support locking for byte offsets that
fit within 32 bits (i.e., less than or equal to NFS4_UINT32_MAX). If fit within 32 bits (i.e., less than or equal to NFS4_UINT32_MAX). If
the client specifies a range that overlaps one or more bytes beyond the client specifies a range that overlaps one or more bytes beyond
offset NFS4_UINT32_MAX but does not end at offset NFS4_UINT64_MAX, offset NFS4_UINT32_MAX but does not end at offset NFS4_UINT64_MAX,
then such a 32-bit server MUST return the error NFS4ERR_BAD_RANGE. then such a 32-bit server MUST return the error NFS4ERR_BAD_RANGE.
If the server returns NFS4ERR_DENIED, the owner, offset, and length If the server returns NFS4ERR_DENIED, the owner, offset, and length
of a conflicting lock are returned. of a conflicting lock are returned.
skipping to change at page 461, line 24 skipping to change at line 22185
argument contains the stateid of the open file with which this lock argument contains the stateid of the open file with which this lock
is to be associated, together with the lock-owner with which the lock is to be associated, together with the lock-owner with which the lock
is to be associated. The open_to_lock_owner case covers the very is to be associated. The open_to_lock_owner case covers the very
first lock done by a lock-owner for a given open file and offers a first lock done by a lock-owner for a given open file and offers a
method to use the established state of the open_stateid to transition method to use the established state of the open_stateid to transition
to the use of a lock stateid. to the use of a lock stateid.
The following fields of the locker parameter MAY be set to any value The following fields of the locker parameter MAY be set to any value
by the client and MUST be ignored by the server: by the client and MUST be ignored by the server:
o The clientid field of the lock_owner field of the open_owner field * The clientid field of the lock_owner field of the open_owner field
(locker.open_owner.lock_owner.clientid). The reason the server (locker.open_owner.lock_owner.clientid). The reason the server
MUST ignore the clientid field is that the server MUST derive the MUST ignore the clientid field is that the server MUST derive the
client ID from the session ID from the SEQUENCE operation of the client ID from the session ID from the SEQUENCE operation of the
COMPOUND request. COMPOUND request.
o The open_seqid and lock_seqid fields of the open_owner field * The open_seqid and lock_seqid fields of the open_owner field
(locker.open_owner.open_seqid and locker.open_owner.lock_seqid). (locker.open_owner.open_seqid and locker.open_owner.lock_seqid).
o The lock_seqid field of the lock_owner field * The lock_seqid field of the lock_owner field
(locker.lock_owner.lock_seqid). (locker.lock_owner.lock_seqid).
Note that the client ID appearing in a LOCK4denied structure is the Note that the client ID appearing in a LOCK4denied structure is the
actual client associated with the conflicting lock, whether this is actual client associated with the conflicting lock, whether this is
the client ID associated with the current session or a different one. the client ID associated with the current session or a different one.
Thus, if the server returns NFS4ERR_DENIED, it MUST set the clientid Thus, if the server returns NFS4ERR_DENIED, it MUST set the clientid
field of the owner field of the denied field. field of the owner field of the denied field.
If the current filehandle is not an ordinary file, an error will be If the current filehandle is not an ordinary file, an error will be
returned to the client. In the case that the current filehandle returned to the client. In the case that the current filehandle
skipping to change at page 474, line 13 skipping to change at line 22776
* to file. Ordinary OPEN of the * to file. Ordinary OPEN of the
* specified file by current filehandle. * specified file by current filehandle.
*/ */
case CLAIM_FH: /* new to v4.1 */ case CLAIM_FH: /* new to v4.1 */
/* CURRENT_FH: regular file to open */ /* CURRENT_FH: regular file to open */
void; void;
/* /*
* Like CLAIM_DELEGATE_PREV. Right to file based on a * Like CLAIM_DELEGATE_PREV. Right to file based on a
* delegation granted to a previous boot * delegation granted to a previous boot
* instance of the client. File is identified by * instance of the client. File is identified
* by filehandle. * by filehandle.
*/ */
case CLAIM_DELEG_PREV_FH: /* new to v4.1 */ case CLAIM_DELEG_PREV_FH: /* new to v4.1 */
/* CURRENT_FH: file being opened */ /* CURRENT_FH: file being opened */
void; void;
/* /*
* Like CLAIM_DELEGATE_CUR. Right to file based on * Like CLAIM_DELEGATE_CUR. Right to file based on
* a delegation granted by the server. * a delegation granted by the server.
* File is identified by filehandle. * File is identified by filehandle.
skipping to change at page 479, line 5 skipping to change at line 22989
attributes the server used to store the verifier. As described in attributes the server used to store the verifier. As described in
Section 18.16.4, the client can compare cva_attrs.attrmask with Section 18.16.4, the client can compare cva_attrs.attrmask with
attrset to determine which attributes were used to store the attrset to determine which attributes were used to store the
verifier. verifier.
With the addition of persistent sessions and pNFS, under some With the addition of persistent sessions and pNFS, under some
conditions EXCLUSIVE4 MUST NOT be used by the client or supported by conditions EXCLUSIVE4 MUST NOT be used by the client or supported by
the server. The following table summarizes the appropriate and the server. The following table summarizes the appropriate and
mandated exclusive create methods for implementations of NFSv4.1: mandated exclusive create methods for implementations of NFSv4.1:
Required methods for exclusive create +=============+==========+==============+=======================+
| Persistent | Server | Server | Client Allowed |
+----------------+-----------+---------------+----------------------+ | Reply Cache | Supports | REQUIRED | |
| Persistent | Server | Server | Client Allowed | | Enabled | pNFS | | |
| Reply Cache | Supports | REQUIRED | | +=============+==========+==============+=======================+
| Enabled | pNFS | | | | no | no | EXCLUSIVE4_1 | EXCLUSIVE4_1 (SHOULD) |
+----------------+-----------+---------------+----------------------+ | | | and | or EXCLUSIVE4 (SHOULD |
| no | no | EXCLUSIVE4_1 | EXCLUSIVE4_1 | | | | EXCLUSIVE4 | NOT) |
| | | and | (SHOULD) or | +-------------+----------+--------------+-----------------------+
| | | EXCLUSIVE4 | EXCLUSIVE4 (SHOULD | | no | yes | EXCLUSIVE4_1 | EXCLUSIVE4_1 |
| | | | NOT) | +-------------+----------+--------------+-----------------------+
| no | yes | EXCLUSIVE4_1 | EXCLUSIVE4_1 | | yes | no | GUARDED4 | GUARDED4 |
| yes | no | GUARDED4 | GUARDED4 | +-------------+----------+--------------+-----------------------+
| yes | yes | GUARDED4 | GUARDED4 | | yes | yes | GUARDED4 | GUARDED4 |
+----------------+-----------+---------------+----------------------+ +-------------+----------+--------------+-----------------------+
Table 10 Table 18: Required Methods for Exclusive Create
If CREATE_SESSION4_FLAG_PERSIST is set in the results of If CREATE_SESSION4_FLAG_PERSIST is set in the results of
CREATE_SESSION, the reply cache is persistent (see Section 18.36). CREATE_SESSION, the reply cache is persistent (see Section 18.36).
If the EXCHGID4_FLAG_USE_PNFS_MDS flag is set in the results from If the EXCHGID4_FLAG_USE_PNFS_MDS flag is set in the results from
EXCHANGE_ID, the server is a pNFS server (see Section 18.35). If the EXCHANGE_ID, the server is a pNFS server (see Section 18.35). If the
client attempts to use EXCLUSIVE4 on a persistent session, or a client attempts to use EXCLUSIVE4 on a persistent session, or a
session derived from an EXCHGID4_FLAG_USE_PNFS_MDS client ID, the session derived from an EXCHGID4_FLAG_USE_PNFS_MDS client ID, the
server MUST return NFS4ERR_INVAL. server MUST return NFS4ERR_INVAL.
With persistent sessions, exclusive create semantics are fully With persistent sessions, exclusive create semantics are fully
skipping to change at page 481, line 5 skipping to change at line 23055
be any value and the server MUST ignore it. be any value and the server MUST ignore it.
In the case that the client is recovering state from a server In the case that the client is recovering state from a server
failure, the claim field of the OPEN argument is used to signify that failure, the claim field of the OPEN argument is used to signify that
the request is meant to reclaim state previously held. the request is meant to reclaim state previously held.
The "claim" field of the OPEN argument is used to specify the file to The "claim" field of the OPEN argument is used to specify the file to
be opened and the state information that the client claims to be opened and the state information that the client claims to
possess. There are seven claim types as follows: possess. There are seven claim types as follows:
+----------------------+--------------------------------------------+ +======================+============================================+
| open type | description | | open type | description |
+======================+============================================+
| CLAIM_NULL, CLAIM_FH | For the client, this is a new OPEN |
| | request and there is no previous state |
| | associated with the file for the |
| | client. With CLAIM_NULL, the file is |
| | identified by the current filehandle |
| | and the specified component name. |
| | With CLAIM_FH (new to NFSv4.1), the |
| | file is identified by just the current |
| | filehandle. |
+----------------------+--------------------------------------------+
| CLAIM_PREVIOUS | The client is claiming basic OPEN |
| | state for a file that was held |
| | previous to a server restart. |
| | Generally used when a server is |
| | returning persistent filehandles; the |
| | client may not have the file name to |
| | reclaim the OPEN. |
+----------------------+--------------------------------------------+
| CLAIM_DELEGATE_CUR, | The client is claiming a delegation |
| CLAIM_DELEG_CUR_FH | for OPEN as granted by the server. |
| | Generally, this is done as part of |
| | recalling a delegation. With |
| | CLAIM_DELEGATE_CUR, the file is |
| | identified by the current filehandle |
| | and the specified component name. |
| | With CLAIM_DELEG_CUR_FH (new to |
| | NFSv4.1), the file is identified by |
| | just the current filehandle. |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| CLAIM_NULL, CLAIM_FH | For the client, this is a new OPEN request |
| | and there is no previous state associated |
| | with the file for the client. With |
| | CLAIM_NULL, the file is identified by the |
| | current filehandle and the specified |
| | component name. With CLAIM_FH (new to |
| | NFSv4.1), the file is identified by just |
| | the current filehandle. |
| CLAIM_PREVIOUS | The client is claiming basic OPEN state |
| | for a file that was held previous to a |
| | server restart. Generally used when a |
| | server is returning persistent |
| | filehandles; the client may not have the |
| | file name to reclaim the OPEN. |
| CLAIM_DELEGATE_CUR, | The client is claiming a delegation for |
| CLAIM_DELEG_CUR_FH | OPEN as granted by the server. Generally, |
| | this is done as part of recalling a |
| | delegation. With CLAIM_DELEGATE_CUR, the |
| | file is identified by the current |
| | filehandle and the specified component |
| | name. With CLAIM_DELEG_CUR_FH (new to |
| | NFSv4.1), the file is identified by just |
| | the current filehandle. |
| CLAIM_DELEGATE_PREV, | The client is claiming a delegation | | CLAIM_DELEGATE_PREV, | The client is claiming a delegation |
| CLAIM_DELEG_PREV_FH | granted to a previous client instance; | | CLAIM_DELEG_PREV_FH | granted to a previous client instance; |
| | used after the client restarts. The server | | | used after the client restarts. The |
| | MAY support CLAIM_DELEGATE_PREV and/or | | | server MAY support CLAIM_DELEGATE_PREV |
| | CLAIM_DELEG_PREV_FH (new to NFSv4.1). If | | | and/or CLAIM_DELEG_PREV_FH (new to |
| | it does support either claim type, | | | NFSv4.1). If it does support either |
| | CREATE_SESSION MUST NOT remove the | | | claim type, CREATE_SESSION MUST NOT |
| | client's delegation state, and the server | | | remove the client's delegation state, |
| | MUST support the DELEGPURGE operation. | | | and the server MUST support the |
| | DELEGPURGE operation. |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
Table 19
For OPEN requests that reach the server during the grace period, the For OPEN requests that reach the server during the grace period, the
server returns an error of NFS4ERR_GRACE. The following claim types server returns an error of NFS4ERR_GRACE. The following claim types
are exceptions: are exceptions:
o OPEN requests specifying the claim type CLAIM_PREVIOUS are devoted * OPEN requests specifying the claim type CLAIM_PREVIOUS are devoted
to reclaiming opens after a server restart and are typically only to reclaiming opens after a server restart and are typically only
valid during the grace period. valid during the grace period.
o OPEN requests specifying the claim types CLAIM_DELEGATE_CUR and * OPEN requests specifying the claim types CLAIM_DELEGATE_CUR and
CLAIM_DELEG_CUR_FH are valid both during and after the grace CLAIM_DELEG_CUR_FH are valid both during and after the grace
period. Since the granting of the delegation that they are period. Since the granting of the delegation that they are
subordinate to assures that there is no conflict with locks to be subordinate to assures that there is no conflict with locks to be
reclaimed by other clients, the server need not return reclaimed by other clients, the server need not return
NFS4ERR_GRACE when these are received during the grace period. NFS4ERR_GRACE when these are received during the grace period.
For any OPEN request, the server may return an OPEN delegation, which For any OPEN request, the server may return an OPEN delegation, which
allows further opens and closes to be handled locally on the client allows further opens and closes to be handled locally on the client
as described in Section 10.4. Note that delegation is up to the as described in Section 10.4. Note that delegation is up to the
server to decide. The client should never assume that delegation server to decide. The client should never assume that delegation
will or will not be granted in a particular instance. It should will or will not be granted in a particular instance. It should
always be prepared for either case. A partial exception is the always be prepared for either case. A partial exception is the
reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed. reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed.
In this case, delegation will always be granted, although the server In this case, delegation will always be granted, although the server
may specify an immediate recall in the delegation structure. may specify an immediate recall in the delegation structure.
The rflags returned by a successful OPEN allow the server to return The rflags returned by a successful OPEN allow the server to return
information governing how the open file is to be handled. information governing how the open file is to be handled.
o OPEN4_RESULT_CONFIRM is deprecated and MUST NOT be returned by an * OPEN4_RESULT_CONFIRM is deprecated and MUST NOT be returned by an
NFSv4.1 server. NFSv4.1 server.
o OPEN4_RESULT_LOCKTYPE_POSIX indicates that the server's byte-range * OPEN4_RESULT_LOCKTYPE_POSIX indicates that the server's byte-range
locking behavior supports the complete set of POSIX locking locking behavior supports the complete set of POSIX locking
techniques [21]. From this, the client can choose to manage byte- techniques [21]. From this, the client can choose to manage byte-
range locking state in a way to handle a mismatch of byte-range range locking state in a way to handle a mismatch of byte-range
locking management. locking management.
o OPEN4_RESULT_PRESERVE_UNLINKED indicates that the server will * OPEN4_RESULT_PRESERVE_UNLINKED indicates that the server will
preserve the open file if the client (or any other client) removes preserve the open file if the client (or any other client) removes
the file as long as it is open. Furthermore, the server promises the file as long as it is open. Furthermore, the server promises
to preserve the file through the grace period after server to preserve the file through the grace period after server
restart, thereby giving the client the opportunity to reclaim its restart, thereby giving the client the opportunity to reclaim its
open. open.
o OPEN4_RESULT_MAY_NOTIFY_LOCK indicates that the server may attempt * OPEN4_RESULT_MAY_NOTIFY_LOCK indicates that the server may attempt
CB_NOTIFY_LOCK callbacks for locks on this file. This flag is a CB_NOTIFY_LOCK callbacks for locks on this file. This flag is a
hint only, and may be safely ignored by the client. hint only, and may be safely ignored by the client.
If the component is of zero length, NFS4ERR_INVAL will be returned. If the component is of zero length, NFS4ERR_INVAL will be returned.
The component is also subject to the normal UTF-8, character support, The component is also subject to the normal UTF-8, character support,
and name checks. See Section 14.5 for further discussion. and name checks. See Section 14.5 for further discussion.
When an OPEN is done and the specified open-owner already has the When an OPEN is done and the specified open-owner already has the
resulting filehandle open, the result is to "OR" together the new resulting filehandle open, the result is to "OR" together the new
share and deny status together with the existing status. In this share and deny status together with the existing status. In this
skipping to change at page 484, line 20 skipping to change at line 23224
Otherwise, the client is neither indicating a desire nor a non-desire Otherwise, the client is neither indicating a desire nor a non-desire
for a delegation, and the server MAY or MAY not return a delegation for a delegation, and the server MAY or MAY not return a delegation
in the OPEN response. in the OPEN response.
If the server supports the new _WANT_ flags and the client sends one If the server supports the new _WANT_ flags and the client sends one
or more of the new flags, then in the event the server does not or more of the new flags, then in the event the server does not
return a delegation, it MUST return a delegation type of return a delegation, it MUST return a delegation type of
OPEN_DELEGATE_NONE_EXT. The field ond_why in the reply indicates why OPEN_DELEGATE_NONE_EXT. The field ond_why in the reply indicates why
no delegation was returned and will be one of: no delegation was returned and will be one of:
WND4_NOT_WANTED The client specified WND4_NOT_WANTED
OPEN4_SHARE_ACCESS_WANT_NO_DELEG. The client specified OPEN4_SHARE_ACCESS_WANT_NO_DELEG.
WND4_CONTENTION There is a conflicting delegation or open on the WND4_CONTENTION
file. There is a conflicting delegation or open on the file.
WND4_RESOURCE Resource limitations prevent the server from granting WND4_RESOURCE
a delegation. Resource limitations prevent the server from granting a
delegation.
WND4_NOT_SUPP_FTYPE The server does not support delegations on this WND4_NOT_SUPP_FTYPE
file type. The server does not support delegations on this file type.
WND4_WRITE_DELEG_NOT_SUPP_FTYPE The server does not support WND4_WRITE_DELEG_NOT_SUPP_FTYPE
OPEN_DELEGATE_WRITE delegations on this file type. The server does not support OPEN_DELEGATE_WRITE delegations on
this file type.
WND4_NOT_SUPP_UPGRADE The server does not support atomic upgrade of WND4_NOT_SUPP_UPGRADE
an OPEN_DELEGATE_READ delegation to an OPEN_DELEGATE_WRITE The server does not support atomic upgrade of an
OPEN_DELEGATE_READ delegation to an OPEN_DELEGATE_WRITE
delegation. delegation.
WND4_NOT_SUPP_DOWNGRADE The server does not support atomic downgrade WND4_NOT_SUPP_DOWNGRADE
of an OPEN_DELEGATE_WRITE delegation to an OPEN_DELEGATE_READ The server does not support atomic downgrade of an
OPEN_DELEGATE_WRITE delegation to an OPEN_DELEGATE_READ
delegation. delegation.
WND4_CANCELED The client specified OPEN4_SHARE_ACCESS_WANT_CANCEL WND4_CANCELED
and now any "want" for this file object is cancelled. The client specified OPEN4_SHARE_ACCESS_WANT_CANCEL and now any
"want" for this file object is cancelled.
WND4_IS_DIR The specified file object is a directory, and the WND4_IS_DIR
operation is OPEN or WANT_DELEGATION, which do not support The specified file object is a directory, and the operation is
delegations on directories. OPEN or WANT_DELEGATION, which do not support delegations on
directories.
OPEN4_SHARE_ACCESS_WANT_READ_DELEG, OPEN4_SHARE_ACCESS_WANT_READ_DELEG,
OPEN_SHARE_ACCESS_WANT_WRITE_DELEG, or OPEN_SHARE_ACCESS_WANT_WRITE_DELEG, or
OPEN_SHARE_ACCESS_WANT_ANY_DELEG mean, respectively, the client wants OPEN_SHARE_ACCESS_WANT_ANY_DELEG mean, respectively, the client wants
an OPEN_DELEGATE_READ, OPEN_DELEGATE_WRITE, or any delegation an OPEN_DELEGATE_READ, OPEN_DELEGATE_WRITE, or any delegation
regardless which of OPEN4_SHARE_ACCESS_READ, regardless which of OPEN4_SHARE_ACCESS_READ,
OPEN4_SHARE_ACCESS_WRITE, or OPEN4_SHARE_ACCESS_BOTH is set. If the OPEN4_SHARE_ACCESS_WRITE, or OPEN4_SHARE_ACCESS_BOTH is set. If the
client has an OPEN_DELEGATE_READ delegation on a file and requests an client has an OPEN_DELEGATE_READ delegation on a file and requests an
OPEN_DELEGATE_WRITE delegation, then the client is requesting atomic OPEN_DELEGATE_WRITE delegation, then the client is requesting atomic
upgrade of its OPEN_DELEGATE_READ delegation to an upgrade of its OPEN_DELEGATE_READ delegation to an
skipping to change at page 485, line 34 skipping to change at line 23292
OPEN4_SHARE_ACCESS_WANT_CANCEL means that the client wants no OPEN4_SHARE_ACCESS_WANT_CANCEL means that the client wants no
delegation and wants to cancel any previously registered "want" for a delegation and wants to cancel any previously registered "want" for a
delegation. delegation.
The client may set one or both of The client may set one or both of
OPEN4_SHARE_ACCESS_WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL and OPEN4_SHARE_ACCESS_WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL and
OPEN4_SHARE_ACCESS_WANT_PUSH_DELEG_WHEN_UNCONTENDED. However, they OPEN4_SHARE_ACCESS_WANT_PUSH_DELEG_WHEN_UNCONTENDED. However, they
will have no effect unless one of following is set: will have no effect unless one of following is set:
o OPEN4_SHARE_ACCESS_WANT_READ_DELEG * OPEN4_SHARE_ACCESS_WANT_READ_DELEG
o OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG * OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG
o OPEN4_SHARE_ACCESS_WANT_ANY_DELEG * OPEN4_SHARE_ACCESS_WANT_ANY_DELEG
If the client specifies If the client specifies
OPEN4_SHARE_ACCESS_WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL, then it wishes OPEN4_SHARE_ACCESS_WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL, then it wishes
to register a "want" for a delegation, in the event the OPEN results to register a "want" for a delegation, in the event the OPEN results
do not include a delegation. If so and the server denies the do not include a delegation. If so and the server denies the
delegation due to insufficient resources, the server MAY later inform delegation due to insufficient resources, the server MAY later inform
the client, via the CB_RECALLABLE_OBJ_AVAIL operation, that the the client, via the CB_RECALLABLE_OBJ_AVAIL operation, that the
resource limitation condition has eased. The server will tell the resource limitation condition has eased. The server will tell the
client that it intends to send a future CB_RECALLABLE_OBJ_AVAIL client that it intends to send a future CB_RECALLABLE_OBJ_AVAIL
operation by setting delegation_type in the results to operation by setting delegation_type in the results to
skipping to change at page 487, line 43 skipping to change at line 23395
time_creation (a meaningful file creation should be set when the time_creation (a meaningful file creation should be set when the
file is created). file is created).
Another alternative for the server is to use a named attribute to Another alternative for the server is to use a named attribute to
store the verifier. store the verifier.
Because the EXCLUSIVE4 create method does not specify initial Because the EXCLUSIVE4 create method does not specify initial
attributes when processing an EXCLUSIVE4 create, the server attributes when processing an EXCLUSIVE4 create, the server
o SHOULD set the owner of the file to that corresponding to the * SHOULD set the owner of the file to that corresponding to the
credential of request's RPC header. credential of request's RPC header.
o SHOULD NOT leave the file's access control to anyone but the owner * SHOULD NOT leave the file's access control to anyone but the owner
of the file. of the file.
If the server cannot support exclusive create semantics, possibly If the server cannot support exclusive create semantics, possibly
because of the requirement to commit the verifier to stable storage, because of the requirement to commit the verifier to stable storage,
it should fail the OPEN request with the error NFS4ERR_NOTSUPP. it should fail the OPEN request with the error NFS4ERR_NOTSUPP.
During an exclusive CREATE request, if the object already exists, the During an exclusive CREATE request, if the object already exists, the
server reconstructs the object's verifier and compares it with the server reconstructs the object's verifier and compares it with the
verifier in the request. If they match, the server treats the verifier in the request. If they match, the server treats the
request as a success. The request is presumed to be a duplicate of request as a success. The request is presumed to be a duplicate of
skipping to change at page 490, line 5 skipping to change at line 23502
share_access or share_deny value specified), the delegation(s) MUST share_access or share_deny value specified), the delegation(s) MUST
be recalled, and the operation cannot proceed until each such be recalled, and the operation cannot proceed until each such
delegation is returned or revoked. Except where this happens very delegation is returned or revoked. Except where this happens very
quickly, one or more NFS4ERR_DELAY errors will be returned to quickly, one or more NFS4ERR_DELAY errors will be returned to
requests made while delegation remains outstanding. In the case of requests made while delegation remains outstanding. In the case of
an OPEN_DELEGATE_WRITE delegation, any open by a different client an OPEN_DELEGATE_WRITE delegation, any open by a different client
will conflict, while for an OPEN_DELEGATE_READ delegation, only opens will conflict, while for an OPEN_DELEGATE_READ delegation, only opens
with one of the following characteristics will be considered with one of the following characteristics will be considered
conflicting: conflicting:
o The value of share_access includes the bit * The value of share_access includes the bit
OPEN4_SHARE_ACCESS_WRITE. OPEN4_SHARE_ACCESS_WRITE.
o The value of share_deny specifies OPEN4_SHARE_DENY_READ or * The value of share_deny specifies OPEN4_SHARE_DENY_READ or
OPEN4_SHARE_DENY_BOTH. OPEN4_SHARE_DENY_BOTH.
o OPEN4_CREATE is specified together with UNCHECKED4, the size * OPEN4_CREATE is specified together with UNCHECKED4, the size
attribute is specified as zero (for truncation), and an existing attribute is specified as zero (for truncation), and an existing
file is truncated. file is truncated.
If OPEN4_CREATE is specified and the file does not exist and the If OPEN4_CREATE is specified and the file does not exist and the
current filehandle designates a directory for which another client current filehandle designates a directory for which another client
holds a directory delegation, then, unless the delegation is such holds a directory delegation, then, unless the delegation is such
that the situation can be resolved by sending a notification, the that the situation can be resolved by sending a notification, the
delegation MUST be recalled, and the operation cannot proceed until delegation MUST be recalled, and the operation cannot proceed until
the delegation is returned or revoked. Except where this happens the delegation is returned or revoked. Except where this happens
very quickly, one or more NFS4ERR_DELAY errors will be returned to very quickly, one or more NFS4ERR_DELAY errors will be returned to
skipping to change at page 491, line 47 skipping to change at line 23590
the object. If none exist, then NFS4ERR_NOENT will be returned. If the object. If none exist, then NFS4ERR_NOENT will be returned. If
createdir has a value of TRUE and no named attribute directory createdir has a value of TRUE and no named attribute directory
exists, one is created and its filehandle becomes the current exists, one is created and its filehandle becomes the current
filehandle. On the other hand, if createdir has a value of TRUE and filehandle. On the other hand, if createdir has a value of TRUE and
the named attribute directory already exists, no error results and the named attribute directory already exists, no error results and
the filehandle of the existing directory becomes the current the filehandle of the existing directory becomes the current
filehandle. The creation of a named attribute directory assumes that filehandle. The creation of a named attribute directory assumes that
the server has implemented named attribute support in this fashion the server has implemented named attribute support in this fashion
and is not required to do so by this definition. and is not required to do so by this definition.
If the current file handle designates an object of type NF4NAMEDATTR If the current filehandle designates an object of type NF4NAMEDATTR
(a named attribute) or NF4ATTRDIR (a named attribute directory), an (a named attribute) or NF4ATTRDIR (a named attribute directory), an
error of NFS4ERR_WRONG_TYPE is returned to the client. Named error of NFS4ERR_WRONG_TYPE is returned to the client. Named
attributes or a named attribute directory MUST NOT have their own attributes or a named attribute directory MUST NOT have their own
named attributes. named attributes.
18.17.4. IMPLEMENTATION 18.17.4. IMPLEMENTATION
If the server does not support named attributes for the current If the server does not support named attributes for the current
filehandle, an error of NFS4ERR_NOTSUPP will be returned to the filehandle, an error of NFS4ERR_NOTSUPP will be returned to the
client. client.
skipping to change at page 493, line 16 skipping to change at line 23650
Valid values for the share_deny field are OPEN4_SHARE_DENY_NONE, Valid values for the share_deny field are OPEN4_SHARE_DENY_NONE,
OPEN4_SHARE_DENY_READ, OPEN4_SHARE_DENY_WRITE, or OPEN4_SHARE_DENY_READ, OPEN4_SHARE_DENY_WRITE, or
OPEN4_SHARE_DENY_BOTH. If the client specifies other values, the OPEN4_SHARE_DENY_BOTH. If the client specifies other values, the
server MUST reply with NFS4ERR_INVAL. server MUST reply with NFS4ERR_INVAL.
After checking for valid values of share_access and share_deny, the After checking for valid values of share_access and share_deny, the
server replaces the current access and deny modes on the file with server replaces the current access and deny modes on the file with
share_access and share_deny subject to the following constraints: share_access and share_deny subject to the following constraints:
o The bits in share_access SHOULD equal the union of the * The bits in share_access SHOULD equal the union of the
share_access bits (not including OPEN4_SHARE_WANT_* bits) share_access bits (not including OPEN4_SHARE_WANT_* bits)
specified for some subset of the OPENs in effect for the current specified for some subset of the OPENs in effect for the current
open-owner on the current file. open-owner on the current file.
o The bits in share_deny SHOULD equal the union of the share_deny * The bits in share_deny SHOULD equal the union of the share_deny
bits specified for some subset of the OPENs in effect for the bits specified for some subset of the OPENs in effect for the
current open-owner on the current file. current open-owner on the current file.
If the above constraints are not respected, the server SHOULD return If the above constraints are not respected, the server SHOULD return
the error NFS4ERR_INVAL. Since share_access and share_deny bits the error NFS4ERR_INVAL. Since share_access and share_deny bits
should be subsets of those already granted, short of a defect in the should be subsets of those already granted, short of a defect in the
client or server implementation, it is not possible for the client or server implementation, it is not possible for the
OPEN_DOWNGRADE request to be denied because of conflicting share OPEN_DOWNGRADE request to be denied because of conflicting share
reservations. reservations.
skipping to change at page 495, line 15 skipping to change at line 23740
18.20.3. DESCRIPTION 18.20.3. DESCRIPTION
This operation replaces the current filehandle with the filehandle This operation replaces the current filehandle with the filehandle
that represents the public filehandle of the server's namespace. that represents the public filehandle of the server's namespace.
This filehandle may be different from the "root" filehandle that may This filehandle may be different from the "root" filehandle that may
be associated with some other directory on the server. be associated with some other directory on the server.
PUTPUBFH also clears the current stateid. PUTPUBFH also clears the current stateid.
The public filehandle represents the concepts embodied in RFC 2054 The public filehandle represents the concepts embodied in RFC 2054
[48], RFC 2055 [49], and RFC 2224 [60]. The intent for NFSv4.1 is [49], RFC 2055 [50], and RFC 2224 [61]. The intent for NFSv4.1 is
that the public filehandle (represented by the PUTPUBFH operation) be that the public filehandle (represented by the PUTPUBFH operation) be
used as a method of providing WebNFS server compatibility with NFSv3. used as a method of providing WebNFS server compatibility with NFSv3.
The public filehandle and the root filehandle (represented by the The public filehandle and the root filehandle (represented by the
PUTROOTFH operation) SHOULD be equivalent. If the public and root PUTROOTFH operation) SHOULD be equivalent. If the public and root
filehandles are not equivalent, then the directory corresponding to filehandles are not equivalent, then the directory corresponding to
the public filehandle MUST be a descendant of the directory the public filehandle MUST be a descendant of the directory
corresponding to the root filehandle. corresponding to the root filehandle.
See Section 16.2.3.1.1 for more details on the current filehandle. See Section 16.2.3.1.1 for more details on the current filehandle.
skipping to change at page 495, line 37 skipping to change at line 23762
See Section 16.2.3.1.2 for more details on the current stateid. See Section 16.2.3.1.2 for more details on the current stateid.
18.20.4. IMPLEMENTATION 18.20.4. IMPLEMENTATION
This operation is used in an NFS request to set the context for file This operation is used in an NFS request to set the context for file
accessing operations that follow in the same COMPOUND request. accessing operations that follow in the same COMPOUND request.
With the NFSv3 public filehandle, the client is able to specify With the NFSv3 public filehandle, the client is able to specify
whether the pathname provided in the LOOKUP should be evaluated as whether the pathname provided in the LOOKUP should be evaluated as
either an absolute path relative to the server's root or relative to either an absolute path relative to the server's root or relative to
the public filehandle. RFC 2224 [60] contains further discussion of the public filehandle. RFC 2224 [61] contains further discussion of
the functionality. With NFSv4.1, that type of specification is not the functionality. With NFSv4.1, that type of specification is not
directly available in the LOOKUP operation. The reason for this is directly available in the LOOKUP operation. The reason for this is
because the component separators needed to specify absolute vs. because the component separators needed to specify absolute vs.
relative are not allowed in NFSv4. Therefore, the client is relative are not allowed in NFSv4. Therefore, the client is
responsible for constructing its request such that the use of either responsible for constructing its request such that the use of either
PUTROOTFH or PUTPUBFH signifies absolute or relative evaluation of an PUTROOTFH or PUTPUBFH signifies absolute or relative evaluation of an
NFS URL, respectively. NFS URL, respectively.
Note that there are warnings mentioned in RFC 2224 [60] with respect Note that there are warnings mentioned in RFC 2224 [61] with respect
to the use of absolute evaluation and the restrictions the server may to the use of absolute evaluation and the restrictions the server may
place on that evaluation with respect to how much of its namespace place on that evaluation with respect to how much of its namespace
has been made available. These same warnings apply to NFSv4.1. It has been made available. These same warnings apply to NFSv4.1. It
is likely, therefore, that because of server implementation details, is likely, therefore, that because of server implementation details,
an NFSv3 absolute public filehandle look up may behave differently an NFSv3 absolute public filehandle look up may behave differently
than an NFSv4.1 absolute resolution. than an NFSv4.1 absolute resolution.
There is a form of security negotiation as described in RFC 2755 [61] There is a form of security negotiation as described in RFC 2755 [62]
that uses the public filehandle and an overloading of the pathname. that uses the public filehandle and an overloading of the pathname.
This method is not available with NFSv4.1 as filehandles are not This method is not available with NFSv4.1 as filehandles are not
overloaded with special meaning and therefore do not provide the same overloaded with special meaning and therefore do not provide the same
framework as NFSv3. Clients should therefore use the security framework as NFSv3. Clients should therefore use the security
negotiation mechanisms described in Section 2.6. negotiation mechanisms described in Section 2.6.
18.21. Operation 24: PUTROOTFH - Set Root Filehandle 18.21. Operation 24: PUTROOTFH - Set Root Filehandle
18.21.1. ARGUMENTS 18.21.1. ARGUMENTS
skipping to change at page 505, line 38 skipping to change at line 24200
the client should take steps to make sure that the file will still be the client should take steps to make sure that the file will still be
accessible. While the traditional mechanism used is to RENAME the accessible. While the traditional mechanism used is to RENAME the
file from its old name to a new hidden name, the NFSv4.1 OPEN file from its old name to a new hidden name, the NFSv4.1 OPEN
operation MAY return a result flag, OPEN4_RESULT_PRESERVE_UNLINKED, operation MAY return a result flag, OPEN4_RESULT_PRESERVE_UNLINKED,
which indicates to the client that the file will be preserved if the which indicates to the client that the file will be preserved if the
file has an outstanding open (see Section 18.16). file has an outstanding open (see Section 18.16).
If the server finds that the file is still open when the REMOVE If the server finds that the file is still open when the REMOVE
arrives: arrives:
o The server SHOULD NOT delete the file's directory entry if the * The server SHOULD NOT delete the file's directory entry if the
file was opened with OPEN4_SHARE_DENY_WRITE or file was opened with OPEN4_SHARE_DENY_WRITE or
OPEN4_SHARE_DENY_BOTH. OPEN4_SHARE_DENY_BOTH.
o If the file was not opened with OPEN4_SHARE_DENY_WRITE or * If the file was not opened with OPEN4_SHARE_DENY_WRITE or
OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's
directory entry. However, until last CLOSE of the file, the directory entry. However, until last CLOSE of the file, the
server MAY continue to allow access to the file via its server MAY continue to allow access to the file via its
filehandle. filehandle.
o The server MUST NOT delete the directory entry if the reply from * The server MUST NOT delete the directory entry if the reply from
OPEN had the flag OPEN4_RESULT_PRESERVE_UNLINKED set. OPEN had the flag OPEN4_RESULT_PRESERVE_UNLINKED set.
The server MAY implement its own restrictions on removal of a file The server MAY implement its own restrictions on removal of a file
while it is open. The server might disallow such a REMOVE (or a while it is open. The server might disallow such a REMOVE (or a
removal that occurs as part of RENAME). The conditions that removal that occurs as part of RENAME). The conditions that
influence the restrictions on removal of a file while it is still influence the restrictions on removal of a file while it is still
open include: open include:
o Whether certain access protocols (i.e., not just NFS) are holding * Whether certain access protocols (i.e., not just NFS) are holding
the file open. the file open.
o Whether particular options, access modes, or policies on the * Whether particular options, access modes, or policies on the
server are enabled. server are enabled.
If a file has an outstanding OPEN and this prevents the removal of If a file has an outstanding OPEN and this prevents the removal of
the file's directory entry, the error NFS4ERR_FILE_OPEN is returned. the file's directory entry, the error NFS4ERR_FILE_OPEN is returned.
Where the determination above cannot be made definitively because Where the determination above cannot be made definitively because
delegations are being held, they MUST be recalled to allow processing delegations are being held, they MUST be recalled to allow processing
of the REMOVE to continue. When a delegation is held, the server has of the REMOVE to continue. When a delegation is held, the server has
no reliable knowledge of the status of OPENs for that client, so no reliable knowledge of the status of OPENs for that client, so
unless there are files opened with the particular deny modes by unless there are files opened with the particular deny modes by
skipping to change at page 509, line 34 skipping to change at line 24385
result of this operation. When oldname and rename refer to the same result of this operation. When oldname and rename refer to the same
file, no notification is generated (because, as Section 18.26.3 file, no notification is generated (because, as Section 18.26.3
states, the server MUST take no action). When a file is removed states, the server MUST take no action). When a file is removed
because it has the same name as the target, if that removal is done because it has the same name as the target, if that removal is done
atomically with the rename, a NOTIFY4_REMOVE_ENTRY notification will atomically with the rename, a NOTIFY4_REMOVE_ENTRY notification will
not be generated. Instead, the deletion of the file will be reported not be generated. Instead, the deletion of the file will be reported
as part of the NOTIFY4_RENAME_ENTRY notification. as part of the NOTIFY4_RENAME_ENTRY notification.
When the current and saved filehandles are not the same: When the current and saved filehandles are not the same:
o If the current filehandle designates a directory for which one or * If the current filehandle designates a directory for which one or
more directory delegations exist, then, when those delegations more directory delegations exist, then, when those delegations
request such notifications, NOTIFY4_ADD_ENTRY will be generated as request such notifications, NOTIFY4_ADD_ENTRY will be generated as
a result of this operation. When a file is removed because it has a result of this operation. When a file is removed because it has
the same name as the target, if that removal is done atomically the same name as the target, if that removal is done atomically
with the rename, a NOTIFY4_REMOVE_ENTRY notification will not be with the rename, a NOTIFY4_REMOVE_ENTRY notification will not be
generated. Instead, the deletion of the file will be reported as generated. Instead, the deletion of the file will be reported as
part of the NOTIFY4_ADD_ENTRY notification. part of the NOTIFY4_ADD_ENTRY notification.
o If the saved filehandle designates a directory for which one or * If the saved filehandle designates a directory for which one or
more directory delegations exist, then, when those delegations more directory delegations exist, then, when those delegations
request such notifications, NOTIFY4_REMOVE_ENTRY will be generated request such notifications, NOTIFY4_REMOVE_ENTRY will be generated
as a result of this operation. as a result of this operation.
If the object being renamed has file delegations held by clients If the object being renamed has file delegations held by clients
other than the one doing the RENAME, the delegations MUST be other than the one doing the RENAME, the delegations MUST be
recalled, and the operation cannot proceed until each such delegation recalled, and the operation cannot proceed until each such delegation
is returned or revoked. Note that in the case of multiply linked is returned or revoked. Note that in the case of multiply linked
files, the delegation recall requirement applies even if the files, the delegation recall requirement applies even if the
delegation was obtained through a different name than the one being delegation was obtained through a different name than the one being
skipping to change at page 514, line 41 skipping to change at line 24602
18.29.4. IMPLEMENTATION 18.29.4. IMPLEMENTATION
The SECINFO operation is expected to be used by the NFS client when The SECINFO operation is expected to be used by the NFS client when
the error value of NFS4ERR_WRONGSEC is returned from another NFS the error value of NFS4ERR_WRONGSEC is returned from another NFS
operation. This signifies to the client that the server's security operation. This signifies to the client that the server's security
policy is different from what the client is currently using. At this policy is different from what the client is currently using. At this
point, the client is expected to obtain a list of possible security point, the client is expected to obtain a list of possible security
flavors and choose what best suits its policies. flavors and choose what best suits its policies.
As mentioned, the server's security policies will determine when a As mentioned, the server's security policies will determine when a
client request receives NFS4ERR_WRONGSEC. See Table 8 for a list of client request receives NFS4ERR_WRONGSEC. See Table 14 for a list of
operations that can return NFS4ERR_WRONGSEC. In addition, when operations that can return NFS4ERR_WRONGSEC. In addition, when
READDIR returns attributes, the rdattr_error (Section 5.8.1.12) can READDIR returns attributes, the rdattr_error (Section 5.8.1.12) can
contain NFS4ERR_WRONGSEC. Note that CREATE and REMOVE MUST NOT contain NFS4ERR_WRONGSEC. Note that CREATE and REMOVE MUST NOT
return NFS4ERR_WRONGSEC. The rationale for CREATE is that unless the return NFS4ERR_WRONGSEC. The rationale for CREATE is that unless the
target name exists, it cannot have a separate security policy from target name exists, it cannot have a separate security policy from
the parent directory, and the security policy of the parent was the parent directory, and the security policy of the parent was
checked when its filehandle was injected into the COMPOUND request's checked when its filehandle was injected into the COMPOUND request's
operations stream (for similar reasons, an OPEN operation that operations stream (for similar reasons, an OPEN operation that
creates the target MUST NOT return NFS4ERR_WRONGSEC). If the target creates the target MUST NOT return NFS4ERR_WRONGSEC). If the target
name exists, while it might have a separate security policy, that is name exists, while it might have a separate security policy, that is
skipping to change at page 515, line 36 skipping to change at line 24645
The READDIR operation will not directly return the NFS4ERR_WRONGSEC The READDIR operation will not directly return the NFS4ERR_WRONGSEC
error. However, if the READDIR request included a request for error. However, if the READDIR request included a request for
attributes, it is possible that the READDIR request's security triple attributes, it is possible that the READDIR request's security triple
did not match that of a directory entry. If this is the case and the did not match that of a directory entry. If this is the case and the
client has requested the rdattr_error attribute, the server will client has requested the rdattr_error attribute, the server will
return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. return the NFS4ERR_WRONGSEC error in rdattr_error for the entry.
To resolve an error return of NFS4ERR_WRONGSEC, the client does the To resolve an error return of NFS4ERR_WRONGSEC, the client does the
following: following:
o For LOOKUP and OPEN, the client will use SECINFO with the same * For LOOKUP and OPEN, the client will use SECINFO with the same
current filehandle and name as provided in the original LOOKUP or current filehandle and name as provided in the original LOOKUP or
OPEN to enumerate the available security triples. OPEN to enumerate the available security triples.
o For the rdattr_error, the client will use SECINFO with the same * For the rdattr_error, the client will use SECINFO with the same
current filehandle as provided in the original READDIR. The name current filehandle as provided in the original READDIR. The name
passed to SECINFO will be that of the directory entry (as returned passed to SECINFO will be that of the directory entry (as returned
from READDIR) that had the NFS4ERR_WRONGSEC error in the from READDIR) that had the NFS4ERR_WRONGSEC error in the
rdattr_error attribute. rdattr_error attribute.
o For PUTFH, PUTROOTFH, PUTPUBFH, RESTOREFH, LINK, and RENAME, the * For PUTFH, PUTROOTFH, PUTPUBFH, RESTOREFH, LINK, and RENAME, the
client will use SECINFO_NO_NAME { style = client will use SECINFO_NO_NAME { style =
SECINFO_STYLE4_CURRENT_FH }. The client will prefix the SECINFO_STYLE4_CURRENT_FH }. The client will prefix the
SECINFO_NO_NAME operation with the appropriate PUTFH, PUTPUBFH, or SECINFO_NO_NAME operation with the appropriate PUTFH, PUTPUBFH, or
PUTROOTFH operation that provides the filehandle originally PUTROOTFH operation that provides the filehandle originally
provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH
operation. operation.
NOTE: In NFSv4.0, the client was required to use SECINFO, and had NOTE: In NFSv4.0, the client was required to use SECINFO, and had
to reconstruct the parent of the original filehandle and the to reconstruct the parent of the original filehandle and the
component name of the original filehandle. The introduction in component name of the original filehandle. The introduction in
NFSv4.1 of SECINFO_NO_NAME obviates the need for reconstruction. NFSv4.1 of SECINFO_NO_NAME obviates the need for reconstruction.
o For LOOKUPP, the client will use SECINFO_NO_NAME { style = * For LOOKUPP, the client will use SECINFO_NO_NAME { style =
SECINFO_STYLE4_PARENT } and provide the filehandle that equals the SECINFO_STYLE4_PARENT } and provide the filehandle that equals the
filehandle originally provided to LOOKUPP. filehandle originally provided to LOOKUPP.
See Section 21 for a discussion on the recommendations for the See Section 21 for a discussion on the recommendations for the
security flavor used by SECINFO and SECINFO_NO_NAME. security flavor used by SECINFO and SECINFO_NO_NAME.
18.30. Operation 34: SETATTR - Set Attributes 18.30. Operation 34: SETATTR - Set Attributes
18.30.1. ARGUMENTS 18.30.1. ARGUMENTS
skipping to change at page 521, line 49 skipping to change at line 24936
stateid identifies the associated owners if any and is used by the stateid identifies the associated owners if any and is used by the
server to verify that the associated locks are still valid (e.g., server to verify that the associated locks are still valid (e.g.,
have not been revoked). have not been revoked).
Upon successful completion, the following results are returned. The Upon successful completion, the following results are returned. The
count result is the number of bytes of data written to the file. The count result is the number of bytes of data written to the file. The
server may write fewer bytes than requested. If so, the actual server may write fewer bytes than requested. If so, the actual
number of bytes written starting at location, offset, is returned. number of bytes written starting at location, offset, is returned.
The server also returns an indication of the level of commitment of The server also returns an indication of the level of commitment of
the data and metadata via committed. Per Table 11, the data and metadata via committed. Per Table 20,
o The server MAY commit the data at a stronger level than requested. * The server MAY commit the data at a stronger level than requested.
o The server MUST commit the data at a level at least as high as * The server MUST commit the data at a level at least as high as
that committed. that committed.
Valid combinations of the fields stable in the request and committed +============+===================================+
in the reply.
+------------+-----------------------------------+
| stable | committed | | stable | committed |
+------------+-----------------------------------+ +============+===================================+
| UNSTABLE4 | FILE_SYNC4, DATA_SYNC4, UNSTABLE4 | | UNSTABLE4 | FILE_SYNC4, DATA_SYNC4, UNSTABLE4 |
+------------+-----------------------------------+
| DATA_SYNC4 | FILE_SYNC4, DATA_SYNC4 | | DATA_SYNC4 | FILE_SYNC4, DATA_SYNC4 |
+------------+-----------------------------------+
| FILE_SYNC4 | FILE_SYNC4 | | FILE_SYNC4 | FILE_SYNC4 |
+------------+-----------------------------------+ +------------+-----------------------------------+
Table 11 Table 20: Valid Combinations of the Fields
Stable in the Request and Committed in the
Reply
The final portion of the result is the field writeverf. This field The final portion of the result is the field writeverf. This field
is the write verifier and is a cookie that the client can use to is the write verifier and is a cookie that the client can use to
determine whether a server has changed instance state (e.g., server determine whether a server has changed instance state (e.g., server
restart) between a call to WRITE and a subsequent call to either restart) between a call to WRITE and a subsequent call to either
WRITE or COMMIT. This cookie MUST be unchanged during a single WRITE or COMMIT. This cookie MUST be unchanged during a single
instance of the NFSv4.1 server and MUST be unique between instances instance of the NFSv4.1 server and MUST be unique between instances
of the NFSv4.1 server. If the cookie changes, then the client MUST of the NFSv4.1 server. If the cookie changes, then the client MUST
assume that any data written with an UNSTABLE4 value for committed assume that any data written with an UNSTABLE4 value for committed
and an old writeverf in the reply has been lost and will need to be and an old writeverf in the reply has been lost and will need to be
skipping to change at page 525, line 21 skipping to change at line 25098
struct gss_cb_handles4 { struct gss_cb_handles4 {
rpc_gss_svc_t gcbp_service; /* RFC 2203 */ rpc_gss_svc_t gcbp_service; /* RFC 2203 */
gsshandle4_t gcbp_handle_from_server; gsshandle4_t gcbp_handle_from_server;
gsshandle4_t gcbp_handle_from_client; gsshandle4_t gcbp_handle_from_client;
}; };
union callback_sec_parms4 switch (uint32_t cb_secflavor) { union callback_sec_parms4 switch (uint32_t cb_secflavor) {
case AUTH_NONE: case AUTH_NONE:
void; void;
case AUTH_SYS: case AUTH_SYS:
authsys_parms cbsp_sys_cred; /* RFC 1831 */ authsys_parms cbsp_sys_cred; /* RFC 5531 */
case RPCSEC_GSS: case RPCSEC_GSS:
gss_cb_handles4 cbsp_gss_handles; gss_cb_handles4 cbsp_gss_handles;
}; };
struct BACKCHANNEL_CTL4args { struct BACKCHANNEL_CTL4args {
uint32_t bca_cb_program; uint32_t bca_cb_program;
callback_sec_parms4 bca_sec_parms<>; callback_sec_parms4 bca_sec_parms<>;
}; };
18.33.2. RESULT 18.33.2. RESULT
skipping to change at page 529, line 5 skipping to change at line 25254
If so, there is an issue if SET_SSV is sent, no response is returned, If so, there is an issue if SET_SSV is sent, no response is returned,
and the last connection associated with the client ID drops. The and the last connection associated with the client ID drops. The
client, per the sessions model, MUST retry the SET_SSV. But it needs client, per the sessions model, MUST retry the SET_SSV. But it needs
a new connection to do so, and MUST associate that connection with a new connection to do so, and MUST associate that connection with
the session via a BIND_CONN_TO_SESSION authenticated with the SSV GSS the session via a BIND_CONN_TO_SESSION authenticated with the SSV GSS
mechanism. The problem is that the RPCSEC_GSS message integrity mechanism. The problem is that the RPCSEC_GSS message integrity
codes use a subkey derived from the SSV as the key and the SSV may codes use a subkey derived from the SSV as the key and the SSV may
have changed. While there are multiple recovery strategies, a have changed. While there are multiple recovery strategies, a
single, general strategy is described here. single, general strategy is described here.
o The client reconnects. * The client reconnects.
o The client assumes that the SET_SSV was executed, and so sends * The client assumes that the SET_SSV was executed, and so sends
BIND_CONN_TO_SESSION with the subkey (derived from the new SSV, BIND_CONN_TO_SESSION with the subkey (derived from the new SSV,
i.e., what SET_SSV would have set the SSV to) used as the key for i.e., what SET_SSV would have set the SSV to) used as the key for
the RPCSEC_GSS credential message integrity codes. the RPCSEC_GSS credential message integrity codes.
o If the request succeeds, this means that the original attempted * If the request succeeds, this means that the original attempted
SET_SSV did execute successfully. The client re-sends the SET_SSV did execute successfully. The client re-sends the
original SET_SSV, which the server will reply to via the reply original SET_SSV, which the server will reply to via the reply
cache. cache.
o If the server returns an RPC authentication error, this means that * If the server returns an RPC authentication error, this means that
the server's current SSV was not changed (and the SET_SSV was the server's current SSV was not changed (and the SET_SSV was
likely not executed). The client then tries BIND_CONN_TO_SESSION likely not executed). The client then tries BIND_CONN_TO_SESSION
with the subkey derived from the old SSV as the key for the with the subkey derived from the old SSV as the key for the
RPCSEC_GSS message integrity codes. RPCSEC_GSS message integrity codes.
o The attempted BIND_CONN_TO_SESSION with the old SSV should * The attempted BIND_CONN_TO_SESSION with the old SSV should
succeed. If so, the client re-sends the original SET_SSV. If the succeed. If so, the client re-sends the original SET_SSV. If the
original SET_SSV was not executed, then the server executes it. original SET_SSV was not executed, then the server executes it.
If the original SET_SSV was executed but failed, the server will If the original SET_SSV was executed but failed, the server will
return the SET_SSV from the reply cache. return the SET_SSV from the reply cache.
18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID
The EXCHANGE_ID operation exchanges long-hand client and server The EXCHANGE_ID operation exchanges long-hand client and server
identifiers (owners), and provides access to a client ID, creating identifiers (owners) and provides access to a client ID, creating one
one if necessary. This client ID becomes associated with the if necessary. This client ID becomes associated with the connection
connection on which the operation is done, so that it is available on which the operation is done, so that it is available when a
when a CREATE_SESSION is done or when the connection is used to issue CREATE_SESSION is done or when the connection is used to issue a
a request on an existing session associated with the current client. request on an existing session associated with the current client.
18.35.1. ARGUMENT 18.35.1. ARGUMENT
const EXCHGID4_FLAG_SUPP_MOVED_REFER = 0x00000001; const EXCHGID4_FLAG_SUPP_MOVED_REFER = 0x00000001;
const EXCHGID4_FLAG_SUPP_MOVED_MIGR = 0x00000002; const EXCHGID4_FLAG_SUPP_MOVED_MIGR = 0x00000002;
const EXCHGID4_FLAG_BIND_PRINC_STATEID = 0x00000100; const EXCHGID4_FLAG_BIND_PRINC_STATEID = 0x00000100;
const EXCHGID4_FLAG_USE_NON_PNFS = 0x00010000; const EXCHGID4_FLAG_USE_NON_PNFS = 0x00010000;
const EXCHGID4_FLAG_USE_PNFS_MDS = 0x00020000; const EXCHGID4_FLAG_USE_PNFS_MDS = 0x00020000;
skipping to change at page 531, line 43 skipping to change at line 25379
case NFS4_OK: case NFS4_OK:
EXCHANGE_ID4resok eir_resok4; EXCHANGE_ID4resok eir_resok4;
default: default:
void; void;
}; };
18.35.3. DESCRIPTION 18.35.3. DESCRIPTION
The client uses the EXCHANGE_ID operation to register a particular The client uses the EXCHANGE_ID operation to register a particular
client_owner with the server. However, when the client_owner has instance of that client with the server, as represented by a
already been registered by other means (e.g. Transparent State client_owner4. However, when the client_owner4 has already been
Migration), the client may still use EXCHANGE_ID to obtain the client registered by other means (e.g., Transparent State Migration), the
ID assigned previously. client may still use EXCHANGE_ID to obtain the client ID assigned
previously.
The client ID returned from this operation will be associated with The client ID returned from this operation will be associated with
the connection on which the EXCHANGE_ID is received and will serve as the connection on which the EXCHANGE_ID is received and will serve as
a parent object for sessions created by the client on this connection a parent object for sessions created by the client on this connection
or to which the connection is bound. As a result of using those or to which the connection is bound. As a result of using those
sessions to make requests involving the creation of state, that state sessions to make requests involving the creation of state, that state
will become associated with the client ID returned. will become associated with the client ID returned.
In situations in which the registration of the client_owner has not In situations in which the registration of the client_owner has not
occurred previously, the client ID must first be used, along with the occurred previously, the client ID must first be used, along with the
returned eir_sequenceid, in creating an associated session using returned eir_sequenceid, in creating an associated session using
CREATE_SESSION. CREATE_SESSION.
If the flag EXCHGID4_FLAG_CONFIRMED_R is set in the result, If the flag EXCHGID4_FLAG_CONFIRMED_R is set in the result,
eir_flags, then it is an indication that the registration of the eir_flags, then it is an indication that the registration of the
client_owner has already occurred and that a further CREATE_SESSION client_owner has already occurred and that a further CREATE_SESSION
is not needed to confirm it. Of course, subsequent CREATE_SESSION is not needed to confirm it. Of course, subsequent CREATE_SESSION
operations may be needed for other reasons. operations may be needed for other reasons.
The value eir_sequenceid is used to establish an initial sequence The value eir_sequenceid is used to establish an initial sequence
value associate with the client ID returned. In cases in which a value associated with the client ID returned. In cases in which a
CREATE_SESSION has already been done, there is no need for this CREATE_SESSION has already been done, there is no need for this
value, since sequencing of such request has already been established value, since sequencing of such request has already been established,
and the client has no need for this value and will ignore it and the client has no need for this value and will ignore it.
EXCHANGE_ID MAY be sent in a COMPOUND procedure that starts with EXCHANGE_ID MAY be sent in a COMPOUND procedure that starts with
SEQUENCE. However, when a client communicates with a server for the SEQUENCE. However, when a client communicates with a server for the
first time, it will not have a session, so using SEQUENCE will not be first time, it will not have a session, so using SEQUENCE will not be
possible. If EXCHANGE_ID is sent without a preceding SEQUENCE, then possible. If EXCHANGE_ID is sent without a preceding SEQUENCE, then
it MUST be the only operation in the COMPOUND procedure's request. it MUST be the only operation in the COMPOUND procedure's request.
If it is not, the server MUST return NFS4ERR_NOT_ONLY_OP. If it is not, the server MUST return NFS4ERR_NOT_ONLY_OP.
The eia_clientowner field is composed of a co_verifier field and a The eia_clientowner field is composed of a co_verifier field and a
co_ownerid string. As noted in Section 2.4, the co_ownerid co_ownerid string. As noted in Section 2.4, the co_ownerid
identifies the client, and the co_verifier specifies a particular identifies the client, and the co_verifier specifies a particular
incarnation of that client. An EXCHANGE_ID sent with a new incarnation of that client. An EXCHANGE_ID sent with a new
incarnation of the client will lead to the server removing lock state incarnation of the client will lead to the server removing lock state
of the old incarnation. On the other hand, an EXCHANGE_ID sent with of the old incarnation. On the other hand, when an EXCHANGE_ID sent
the current incarnation and co_ownerid will, when it does not result with the current incarnation and co_ownerid does not result in an
in an unrelated error, potentially update an existing client ID's unrelated error, it will potentially update an existing client ID's
properties, or simply return information about the existing properties or simply return information about the existing client_id.
client_id. That latter would happen when this operation is done to The latter would happen when this operation is done to the same
the same server using different network addresses as part of creating server using different network addresses as part of creating trunked
trunked connections. connections.
A server MUST NOT provide the same client ID to two different A server MUST NOT provide the same client ID to two different
incarnations of an eia_clientowner. incarnations of an eia_clientowner.
In addition to the client ID and sequence ID, the server returns a In addition to the client ID and sequence ID, the server returns a
server owner (eir_server_owner) and server scope (eir_server_scope). server owner (eir_server_owner) and server scope (eir_server_scope).
The former field is used in connection with network trunking as The former field is used in connection with network trunking as
described in Section 2.10.5. The latter field is used to allow described in Section 2.10.5. The latter field is used to allow
clients to determine when client IDs sent by one server may be clients to determine when client IDs sent by one server may be
recognized by another in the event of file system migration (see recognized by another in the event of file system migration (see
skipping to change at page 533, line 27 skipping to change at line 25459
the destination network addresses of the connections used with each the destination network addresses of the connections used with each
server and use the network address as the final discriminator. server and use the network address as the final discriminator.
The server, as defined by the unique identity expressed in the The server, as defined by the unique identity expressed in the
so_major_id of the server owner and the server scope, needs to track so_major_id of the server owner and the server scope, needs to track
several properties of each client ID it hands out. The properties several properties of each client ID it hands out. The properties
apply to the client ID and all sessions associated with the client apply to the client ID and all sessions associated with the client
ID. The properties are derived from the arguments and results of ID. The properties are derived from the arguments and results of
EXCHANGE_ID. The client ID properties include: EXCHANGE_ID. The client ID properties include:
o The capabilities expressed by the following bits, which come from * The capabilities expressed by the following bits, which come from
the results of EXCHANGE_ID: the results of EXCHANGE_ID:
* EXCHGID4_FLAG_SUPP_MOVED_REFER - EXCHGID4_FLAG_SUPP_MOVED_REFER
* EXCHGID4_FLAG_SUPP_MOVED_MIGR - EXCHGID4_FLAG_SUPP_MOVED_MIGR
* EXCHGID4_FLAG_BIND_PRINC_STATEID - EXCHGID4_FLAG_BIND_PRINC_STATEID
* EXCHGID4_FLAG_USE_NON_PNFS - EXCHGID4_FLAG_USE_NON_PNFS
* EXCHGID4_FLAG_USE_PNFS_MDS - EXCHGID4_FLAG_USE_PNFS_MDS
* EXCHGID4_FLAG_USE_PNFS_DS - EXCHGID4_FLAG_USE_PNFS_DS
These properties may be updated by subsequent EXCHANGE_ID These properties may be updated by subsequent EXCHANGE_ID
operations on confirmed client IDs though the server MAY refuse to operations on confirmed client IDs though the server MAY refuse to
change them. change them.
o The state protection method used, one of SP4_NONE, SP4_MACH_CRED, * The state protection method used, one of SP4_NONE, SP4_MACH_CRED,
or SP4_SSV, as set by the spa_how field of the arguments to or SP4_SSV, as set by the spa_how field of the arguments to
EXCHANGE_ID. Once the client ID is confirmed, this property EXCHANGE_ID. Once the client ID is confirmed, this property
cannot be updated by subsequent EXCHANGE_ID operations. cannot be updated by subsequent EXCHANGE_ID operations.
o For SP4_MACH_CRED or SP4_SSV state protection: * For SP4_MACH_CRED or SP4_SSV state protection:
* The list of operations (spo_must_enforce) that MUST use the - The list of operations (spo_must_enforce) that MUST use the
specified state protection. This list comes from the results specified state protection. This list comes from the results
of EXCHANGE_ID. of EXCHANGE_ID.
* The list of operations (spo_must_allow) that MAY use the - The list of operations (spo_must_allow) that MAY use the
specified state protection. This list comes from the results specified state protection. This list comes from the results
of EXCHANGE_ID. of EXCHANGE_ID.
Once the client ID is confirmed, these properties cannot be Once the client ID is confirmed, these properties cannot be
updated by subsequent EXCHANGE_ID requests. updated by subsequent EXCHANGE_ID requests.
o For SP4_SSV protection: * For SP4_SSV protection:
* The OID of the hash algorithm. This property is represented by - The OID of the hash algorithm. This property is represented by
one of the algorithms in the ssp_hash_algs field of the one of the algorithms in the ssp_hash_algs field of the
EXCHANGE_ID arguments. Once the client ID is confirmed, this EXCHANGE_ID arguments. Once the client ID is confirmed, this
property cannot be updated by subsequent EXCHANGE_ID requests. property cannot be updated by subsequent EXCHANGE_ID requests.
* 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 operations. EXCHANGE_ID operations.
There are REQUIRED and RECOMMENDED relationships among the There are REQUIRED and RECOMMENDED relationships among the
length of the key of the encryption algorithm ("key length"), 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 output of hash algorithm ("hash length"), and
the length of the SSV ("SSV length"). the length of the SSV ("SSV length").
+ key length MUST be <= hash length. This is because the keys o key length MUST be <= hash length. This is because the keys
used for the encryption algorithm are actually subkeys used for the encryption algorithm are actually subkeys
derived from the SSV, and the derivation is via the hash derived from the SSV, and the derivation is via the hash
algorithm. The selection of an encryption algorithm with a algorithm. The selection of an encryption algorithm with a
key length that exceeded the length of the output of the key length that exceeded the length of the output of the
hash algorithm would require padding, and thus weaken the hash algorithm would require padding, and thus weaken the
use of the encryption algorithm. use of the encryption algorithm.
+ hash length SHOULD be <= SSV length. This is because the o hash length SHOULD be <= SSV length. This is because the
SSV is a key used to derive subkeys via an HMAC, and it is 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 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 least as long as the length of the HMAC's hash algorithm's
output (see Section 3 of [51]). output (see Section 3 of [52]).
+ key length SHOULD be <= SSV length. This is a transitive o key length SHOULD be <= SSV length. This is a transitive
result of the above two invariants. result of the above two invariants.
+ key length SHOULD be >= hash length / 2. This is because o key length SHOULD be >= hash length / 2. This is because
the subkey derivation is via an HMAC and it is recommended the subkey derivation is via an HMAC and it is recommended
that if the HMAC has to be truncated, it should not be that if the HMAC has to be truncated, it should not be
truncated to less than half the hash length (see Section 4 truncated to less than half the hash length (see Section 4
of RFC2104 [51]). of RFC 2104 [52]).
* Number of concurrent versions of the SSV the client and server - Number of concurrent versions of the SSV the client and server
will support (see Section 2.10.9). This property is will support (see Section 2.10.9). This property is
represented by spi_window in the EXCHANGE_ID results. The represented by spi_window in the EXCHANGE_ID results. The
property may be updated by subsequent EXCHANGE_ID operations. property may be updated by subsequent EXCHANGE_ID operations.
o The client's implementation ID as represented by the * 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.
o The server's implementation ID as represented by the * The server's implementation ID as represented by the
eir_server_impl_id field of the reply. The property may be eir_server_impl_id field of the reply. The property may be
updated by replies to subsequent EXCHANGE_ID requests. updated by replies to subsequent EXCHANGE_ID requests.
The eia_flags passed as part of the arguments and the eir_flags The eia_flags passed as part of the arguments and the eir_flags
results allow the client and server to inform each other of their results allow the client and server to inform each other of their
capabilities as well as indicate how the client ID will be used. capabilities as well as indicate how the client ID will be used.
Whether a bit is set or cleared on the arguments' flags does not Whether a bit is set or cleared on the arguments' flags does not
force the server to set or clear the same bit on the results' side. force the server to set or clear the same bit on the results' side.
Bits not defined above cannot be set in the eia_flags field. If they Bits not defined above cannot be set in the eia_flags field. If they
are, the server MUST reject the operation with NFS4ERR_INVAL. are, the server MUST reject the operation with NFS4ERR_INVAL.
skipping to change at page 537, line 14 skipping to change at line 25639
it. If an update to the client ID changes the value of it. If an update to the client ID changes the value of
EXCHGID4_FLAG_BIND_PRINC_STATEID's client ID property, the effect EXCHGID4_FLAG_BIND_PRINC_STATEID's client ID property, the effect
applies only to new stateids. Existing stateids (and all stateids applies only to new stateids. Existing stateids (and all stateids
with the same "other" field) that were created with stateid to with the same "other" field) that were created with stateid to
principal binding in force will continue to have binding in force. principal binding in force will continue to have binding in force.
Existing stateids (and all stateids with the same "other" field) that Existing stateids (and all stateids with the same "other" field) that
were created with stateid to principal not in force will continue to were created with stateid to principal not in force will continue to
have binding not in force. have binding not in force.
The EXCHGID4_FLAG_USE_NON_PNFS, EXCHGID4_FLAG_USE_PNFS_MDS, and The EXCHGID4_FLAG_USE_NON_PNFS, EXCHGID4_FLAG_USE_PNFS_MDS, and
EXCHGID4_FLAG_USE_PNFS_DS bits are described in Section 2.10.2.2 and EXCHGID4_FLAG_USE_PNFS_DS bits are described in Section 13.1 and
convey roles the client ID is to be used for in a pNFS environment. convey roles the client ID is to be used for in a pNFS environment.
The server MUST set one of the acceptable combinations of these bits The server MUST set one of the acceptable combinations of these bits
(roles) in eir_flags, as specified in that section. Note that the (roles) in eir_flags, as specified in that section. Note that the
same client owner/server owner pair can have multiple roles. same client owner/server owner pair can have multiple roles.
Multiple roles can be associated with the same client ID or with Multiple roles can be associated with the same client ID or with
different client IDs. Thus, if a client sends EXCHANGE_ID from the different client IDs. Thus, if a client sends EXCHANGE_ID from the
same client owner to the same server owner multiple times, but same client owner to the same server owner multiple times, but
specifies different pNFS roles each time, the server might return specifies different pNFS roles each time, the server might return
different client IDs. Given that different pNFS roles might have different client IDs. Given that different pNFS roles might have
different client IDs, the client may ask for different properties for different client IDs, the client may ask for different properties for
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 states from client wants to protect its client, locking, and session states 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 * 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. If spa_how is SP4_MACH_CRED, then the client MUST * SP4_MACH_CRED. If spa_how is SP4_MACH_CRED, then the client MUST
send the EXCHANGE_ID operation with RPCSEC_GSS as the security send the EXCHANGE_ID operation with RPCSEC_GSS as the security
flavor, and with a service of RPC_GSS_SVC_INTEGRITY or flavor, and with a service of RPC_GSS_SVC_INTEGRITY or
RPC_GSS_SVC_PRIVACY. If SP4_MACH_CRED is specified, then the RPC_GSS_SVC_PRIVACY. If SP4_MACH_CRED is specified, then the
client wants to use an RPCSEC_GSS-based machine credential to client wants to use an RPCSEC_GSS-based machine credential to
protect its state. The server MUST note the principal the protect its state. The server MUST note the principal the
EXCHANGE_ID operation was sent with, and the GSS mechanism used. EXCHANGE_ID operation was sent with, and the GSS mechanism used.
These notes collectively comprise the machine credential. 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 first EXCHANGE_ID MUST also use the same machine credential as the first
EXCHANGE_ID. The server returns the same client ID for the 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. If spa_how is SP4_SSV, then the client MUST send the * SP4_SSV. If spa_how is SP4_SSV, then the client MUST send the
EXCHANGE_ID operation with RPCSEC_GSS as the security flavor, and EXCHANGE_ID operation with RPCSEC_GSS as the security flavor, and
with a service of RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY. with a service of RPC_GSS_SVC_INTEGRITY or RPC_GSS_SVC_PRIVACY.
If SP4_SSV is specified, then the client wants to use the SSV to If SP4_SSV is specified, then the client wants to use the SSV to
protect its state. The server records the credential used in the protect its state. The server records the credential used in the
request as the machine credential (as defined above) for the request as the machine credential (as defined above) for the
eia_clientowner.co_owner. The CREATE_SESSION operation that eia_clientowner.co_owner. The CREATE_SESSION operation that
confirms the client ID MUST use 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 bitmap). The first list two lists of operations (each expressed as a bitmap). The first list
skipping to change at page 540, line 17 skipping to change at line 25783
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 [26]. The selected algorithms are id-aes192-CBC and id-aes128-CBC [26]. 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. Note that due to is empty, the server MUST return NFS4ERR_INVAL. Note that due to
previously stated requirements and recommendations on the previously stated requirements and recommendations on the
relationships between key length and hash length, some relationships between key length and hash length, some
combinations of RECOMMENDED and REQUIRED encryption algorithm and combinations of RECOMMENDED and REQUIRED encryption algorithm and
hash algorithm either SHOULD NOT or MUST NOT be used. Table 12 hash algorithm either SHOULD NOT or MUST NOT be used. Table 21
summarizes the illegal and discouraged combinations. 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. Any requests MUST NOT exceed ssp_window and MUST be at least one. Any requests
on the backchannel or fore channel that are using a version of the on the backchannel or fore channel that are using a version of the
SSV that is outside the window will fail with an ONC RPC SSV that is outside the window will fail with an ONC RPC
authentication error, and the requester will have to retry them authentication error, and the requester will have to retry them
with the same slot ID and sequence ID. with the same slot ID and sequence ID.
skipping to change at page 541, line 11 skipping to change at line 25823
connections connected to a server that returns the same the connections connected to a server that returns the same the
eir_server_owner.so_major_id and eir_server_owner.so_minor_id on eir_server_owner.so_major_id and eir_server_owner.so_minor_id on
each connection. It is permissible for the client to set each connection. It is permissible for the client to set
ssp_num_gss_handles to zero; the client can create more handles ssp_num_gss_handles to zero; the client can create more handles
with another EXCHANGE_ID call. with another EXCHANGE_ID call.
Because each SSV RPCSEC_GSS handle shares a common SSV GSS Because each SSV RPCSEC_GSS handle shares a common SSV GSS
context, there are security considerations specific to this context, there are security considerations specific to this
situation discussed in Section 2.10.10. situation discussed in Section 2.10.10.
The seq_window (see Section 5.2.3.1 of RFC2203 [4]) of each The seq_window (see Section 5.2.3.1 of RFC 2203 [4]) of each
RPCSEC_GSS handle in spi_handle MUST be the same as the seq_window 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 of the RPCSEC_GSS handle used for the credential of the RPC
request that the EXCHANGE_ID operation was sent as a part of. request of which the EXCHANGE_ID operation was sent as a part.
+-------------------+----------------------+------------------------+ +======================+===========================+===============+
| Encryption | MUST NOT be combined | SHOULD NOT be combined | | Encryption Algorithm | MUST NOT be combined with | SHOULD NOT be |
| Algorithm | with | with | | | | combined with |
+-------------------+----------------------+------------------------+ +======================+===========================+===============+
| id-aes128-CBC | | id-sha384, id-sha512 | | id-aes128-CBC | | id-sha384, |
| id-aes192-CBC | id-sha1 | id-sha512 | | | | id-sha512 |
| id-aes256-CBC | id-sha1, id-sha224 | | +----------------------+---------------------------+---------------+
+-------------------+----------------------+------------------------+ | id-aes192-CBC | id-sha1 | id-sha512 |
+----------------------+---------------------------+---------------+
| id-aes256-CBC | id-sha1, id-sha224 | |
+----------------------+---------------------------+---------------+
Table 12 Table 21
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 eia_client_impl_id. If eia_client_impl_id is present, it contains
the information identifying the implementation of the client. the information identifying the implementation of the client.
Similarly, the results include an array of up to one element in Similarly, the results include an array of up to one element in
length called eir_server_impl_id that identifies the implementation length called eir_server_impl_id that identifies the implementation
of the server. Servers MUST accept a zero-length eia_client_impl_id of the server. Servers MUST accept a zero-length eia_client_impl_id
array, and clients MUST accept a zero-length eir_server_impl_id array, and clients MUST accept a zero-length eir_server_impl_id
array. array.
skipping to change at page 542, line 4 skipping to change at line 25866
server MUST NOT interpret this implementation identity information in server MUST NOT interpret this implementation identity information in
a way that affects how the implementation interacts with its peer. a way that affects how the implementation interacts with its peer.
The client and server are not allowed to depend on the peer's The client and server are not allowed to depend on the peer's
manifesting a particular allowed behavior based on an implementation manifesting a particular allowed behavior based on an implementation
identifier but are required to interoperate as specified elsewhere in identifier but are required to interoperate as specified elsewhere in
the protocol specification. the protocol specification.
Because it is possible that some implementations might violate the Because it is possible that some implementations might violate the
protocol specification and interpret the identity information, protocol specification and interpret the identity information,
implementations MUST provide facilities to allow the NFSv4 client and implementations MUST provide facilities to allow the NFSv4 client and
server be configured to set the contents of the nfs_impl_id server to be configured to set the contents of the nfs_impl_id
structures sent to any specified value. structures sent to any specified value.
18.35.4. IMPLEMENTATION 18.35.4. IMPLEMENTATION
A server's client record is a 5-tuple: A server's client record is a 5-tuple:
1. co_ownerid 1. co_ownerid:
The client identifier string, from the eia_clientowner The client identifier string, from the eia_clientowner structure
structure of the EXCHANGE_ID4args structure. of the EXCHANGE_ID4args structure.
2. co_verifier: 2. co_verifier:
A client-specific value used to indicate incarnations (where a A client-specific value used to indicate incarnations (where a
client restart represents a new incarnation), from the client restart represents a new incarnation), from the
eia_clientowner structure of the EXCHANGE_ID4args structure. eia_clientowner structure of the EXCHANGE_ID4args structure.
3. principal: 3. principal:
The principal that was defined in the RPC header's credential The principal that was defined in the RPC header's credential
and/or verifier at the time the client record was established. and/or verifier at the time the client record was established.
4. client ID: 4. client ID:
The shorthand client identifier, generated by the server and The shorthand client identifier, generated by the server and
returned via the eir_clientid field in the EXCHANGE_ID4resok returned via the eir_clientid field in the EXCHANGE_ID4resok
structure. structure.
5. confirmed: 5. confirmed:
A private field on the server indicating whether or not a A private field on the server indicating whether or not a client
client record has been confirmed. A client record is record has been confirmed. A client record is confirmed if there
confirmed if there has been a successful CREATE_SESSION has been a successful CREATE_SESSION operation to confirm it.
operation to confirm it. Otherwise, it is unconfirmed. An Otherwise, it is unconfirmed. An unconfirmed record is
unconfirmed record is established by an EXCHANGE_ID call. Any established by an EXCHANGE_ID call. Any unconfirmed record that
unconfirmed record that is not confirmed within a lease period is not confirmed within a lease period SHOULD be removed.
SHOULD be removed.
The following identifiers represent special values for the fields in The following identifiers represent special values for the fields in
the records. the records.
ownerid_arg: ownerid_arg:
The value of the eia_clientowner.co_ownerid subfield of the The value of the eia_clientowner.co_ownerid subfield of the
EXCHANGE_ID4args structure of the current request. EXCHANGE_ID4args structure of the current request.
verifier_arg: verifier_arg:
The value of the eia_clientowner.co_verifier subfield of the The value of the eia_clientowner.co_verifier subfield of the
EXCHANGE_ID4args structure of the current request. EXCHANGE_ID4args structure of the current request.
old_verifier_arg: old_verifier_arg:
A value of the eia_clientowner.co_verifier field of a client A value of the eia_clientowner.co_verifier field of a client
record received in a previous request; this is distinct from record received in a previous request; this is distinct from
verifier_arg. verifier_arg.
principal_arg: principal_arg:
The value of the RPCSEC_GSS principal for the current request. The value of the RPCSEC_GSS principal for the current request.
old_principal_arg: old_principal_arg:
A value of the principal of a client record as defined by the RPC A value of the principal of a client record as defined by the RPC
header's credential or verifier of a previous request. This is header's credential or verifier of a previous request. This is
distinct from principal_arg. distinct from principal_arg.
clientid_ret: clientid_ret:
The value of the eir_clientid field the server will return in the The value of the eir_clientid field the server will return in the
EXCHANGE_ID4resok structure for the current request. EXCHANGE_ID4resok structure for the current request.
old_clientid_ret: old_clientid_ret:
The value of the eir_clientid field the server returned in the The value of the eir_clientid field the server returned in the
EXCHANGE_ID4resok structure for a previous request. This is EXCHANGE_ID4resok structure for a previous request. This is
distinct from clientid_ret. distinct from clientid_ret.
confirmed: confirmed:
The client ID has been confirmed. The client ID has been confirmed.
unconfirmed: unconfirmed:
The client ID has not been confirmed. The client ID has not been confirmed.
Since EXCHANGE_ID is a non-idempotent operation, we must consider the Since EXCHANGE_ID is a non-idempotent operation, we must consider the
possibility that retries occur as a result of a client restart, possibility that retries occur as a result of a client restart,
network partition, malfunctioning router, etc. Retries are network partition, malfunctioning router, etc. Retries are
identified by the value of the eia_clientowner field of identified by the value of the eia_clientowner field of
EXCHANGE_ID4args, and the method for dealing with them is outlined in EXCHANGE_ID4args, and the method for dealing with them is outlined in
the scenarios below. the scenarios below.
The scenarios are described in terms of the client record(s) a server The scenarios are described in terms of the client record(s) a server
skipping to change at page 544, line 10 skipping to change at line 25959
The scenarios are described in terms of the client record(s) a server The scenarios are described in terms of the client record(s) a server
has for a given co_ownerid. Note that if the client ID was created has for a given co_ownerid. Note that if the client ID was created
specifying SP4_SSV state protection and EXCHANGE_ID as the one of the specifying SP4_SSV state protection and EXCHANGE_ID as the one of the
operations in spo_must_allow, then the server MUST authorize operations in spo_must_allow, then the server MUST authorize
EXCHANGE_IDs with the SSV principal in addition to the principal that EXCHANGE_IDs with the SSV principal in addition to the principal that
created the client ID. created the client ID.
1. New Owner ID 1. New Owner ID
If the server has no client records with If the server has no client records with
eia_clientowner.co_ownerid matching ownerid_arg, and eia_clientowner.co_ownerid matching ownerid_arg, and
EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set in the EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set in the EXCHANGE_ID,
EXCHANGE_ID, then a new shorthand client ID (let us call it then a new shorthand client ID (let us call it clientid_ret) is
clientid_ret) is generated, and the following unconfirmed generated, and the following unconfirmed record is added to the
record is added to the server's state. server's state.
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret, { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
unconfirmed } unconfirmed }
Subsequently, the server returns clientid_ret. Subsequently, the server returns clientid_ret.
2. Non-Update on Existing Client ID 2. Non-Update on Existing Client ID
If the server has the following confirmed record, and the If the server has the following confirmed record, and the request
request does not have EXCHGID4_FLAG_UPD_CONFIRMED_REC_A set, does not have EXCHGID4_FLAG_UPD_CONFIRMED_REC_A set, then the
then the request is the result of a retried request due to a request is the result of a retried request due to a faulty router
faulty router or lost connection, or the client is trying to or lost connection, or the client is trying to determine if it
determine if it can perform trunking. can perform trunking.
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret, { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
confirmed } confirmed }
Since the record has been confirmed, the client must have Since the record has been confirmed, the client must have
received the server's reply from the initial EXCHANGE_ID received the server's reply from the initial EXCHANGE_ID request.
request. Since the server has a confirmed record, and since Since the server has a confirmed record, and since
EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, with the EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, with the possible
possible exception of eir_server_owner.so_minor_id, the server exception of eir_server_owner.so_minor_id, the server returns the
returns the same result it did when the client ID's properties same result it did when the client ID's properties were last
were last updated (or if never updated, the result when the updated (or if never updated, the result when the client ID was
client ID was created). The confirmed record is unchanged. created). The confirmed record is unchanged.
3. Client Collision 3. Client Collision
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, and if the If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, and if the
server has the following confirmed record, then this request server has the following confirmed record, then this request is
is likely the result of a chance collision between the values likely the result of a chance collision between the values of the
of the eia_clientowner.co_ownerid subfield of EXCHANGE_ID4args eia_clientowner.co_ownerid subfield of EXCHANGE_ID4args for two
for two different clients. different clients.
{ ownerid_arg, *, old_principal_arg, old_clientid_ret, { ownerid_arg, *, old_principal_arg, old_clientid_ret, confirmed
confirmed } }
If there is currently no state associated with If there is currently no state associated with old_clientid_ret,
old_clientid_ret, or if there is state but the lease has or if there is state but the lease has expired, then this case is
expired, then this case is effectively equivalent to the New effectively equivalent to the New Owner ID case of
Owner ID case of Paragraph 1. The confirmed record is Section 18.35.4, Paragraph 7, Item 1. The confirmed record is
deleted, the old_clientid_ret and its lock state are deleted, deleted, the old_clientid_ret and its lock state are deleted, a
a new shorthand client ID is generated, and the following new shorthand client ID is generated, and the following
unconfirmed record is added to the server's state. unconfirmed record is added to the server's state.
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret, { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
unconfirmed } unconfirmed }
Subsequently, the server returns clientid_ret. Subsequently, the server returns clientid_ret.
If old_clientid_ret has an unexpired lease with state, then no If old_clientid_ret has an unexpired lease with state, then no
state of old_clientid_ret is changed or deleted. The server state of old_clientid_ret is changed or deleted. The server
returns NFS4ERR_CLID_INUSE to indicate that the client should returns NFS4ERR_CLID_INUSE to indicate that the client should
retry with a different value for the retry with a different value for the eia_clientowner.co_ownerid
eia_clientowner.co_ownerid subfield of EXCHANGE_ID4args. The subfield of EXCHANGE_ID4args. The client record is not changed.
client record is not changed.
4. Replacement of Unconfirmed Record 4. Replacement of Unconfirmed Record
If the EXCHGID4_FLAG_UPD_CONFIRMED_REC_A flag is not set, and If the EXCHGID4_FLAG_UPD_CONFIRMED_REC_A flag is not set, and the
the server has the following unconfirmed record, then the server has the following unconfirmed record, then the client is
client is attempting EXCHANGE_ID again on an unconfirmed attempting EXCHANGE_ID again on an unconfirmed client ID, perhaps
client ID, perhaps due to a retry, a client restart before due to a retry, a client restart before client ID confirmation
client ID confirmation (i.e., before CREATE_SESSION was (i.e., before CREATE_SESSION was called), or some other reason.
called), or some other reason.
{ ownerid_arg, *, *, old_clientid_ret, unconfirmed } { ownerid_arg, *, *, old_clientid_ret, unconfirmed }
It is possible that the properties of old_clientid_ret are It is possible that the properties of old_clientid_ret are
different than those specified in the current EXCHANGE_ID. different than those specified in the current EXCHANGE_ID.
Whether or not the properties are being updated, to eliminate Whether or not the properties are being updated, to eliminate
ambiguity, the server deletes the unconfirmed record, ambiguity, the server deletes the unconfirmed record, generates a
generates a new client ID (clientid_ret), and establishes the new client ID (clientid_ret), and establishes the following
following unconfirmed record: unconfirmed record:
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret, { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
unconfirmed } unconfirmed }
5. Client Restart 5. Client Restart
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, and if the If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, and if the
server has the following confirmed client record, then this server has the following confirmed client record, then this
request is likely from a previously confirmed client that has request is likely from a previously confirmed client that has
restarted. restarted.
{ ownerid_arg, old_verifier_arg, principal_arg, { ownerid_arg, old_verifier_arg, principal_arg, old_clientid_ret,
old_clientid_ret, confirmed } confirmed }
Since the previous incarnation of the same client will no Since the previous incarnation of the same client will no longer
longer be making requests, once the new client ID is confirmed be making requests, once the new client ID is confirmed by
by CREATE_SESSION, byte-range locks and share reservations CREATE_SESSION, byte-range locks and share reservations should be
should be released immediately rather than forcing the new released immediately rather than forcing the new incarnation to
incarnation to wait for the lease time on the previous wait for the lease time on the previous incarnation to expire.
incarnation to expire. Furthermore, session state should be Furthermore, session state should be removed since if the client
removed since if the client had maintained that information had maintained that information across restart, this request
across restart, this request would not have been sent. If the would not have been sent. If the server supports neither the
server supports neither the CLAIM_DELEGATE_PREV nor CLAIM_DELEGATE_PREV nor CLAIM_DELEG_PREV_FH claim types,
CLAIM_DELEG_PREV_FH claim types, associated delegations should associated delegations should be purged as well; otherwise,
be purged as well; otherwise, delegations are retained and delegations are retained and recovery proceeds according to
recovery proceeds according to Section 10.2.1. Section 10.2.1.
After processing, clientid_ret is returned to the client and After processing, clientid_ret is returned to the client and this
this client record is added: client record is added:
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret, { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
unconfirmed } unconfirmed }
The previously described confirmed record continues to exist, The previously described confirmed record continues to exist, and
and thus the same ownerid_arg exists in both a confirmed and thus the same ownerid_arg exists in both a confirmed and
unconfirmed state at the same time. The number of states can unconfirmed state at the same time. The number of states can
collapse to one once the server receives an applicable collapse to one once the server receives an applicable
CREATE_SESSION or EXCHANGE_ID. CREATE_SESSION or EXCHANGE_ID.
+ If the server subsequently receives a successful * If the server subsequently receives a successful
CREATE_SESSION that confirms clientid_ret, then the server CREATE_SESSION that confirms clientid_ret, then the server
atomically destroys the confirmed record and makes the atomically destroys the confirmed record and makes the
unconfirmed record confirmed as described in unconfirmed record confirmed as described in Section 18.36.3.
Section 18.36.3.
+ If the server instead subsequently receives an EXCHANGE_ID * If the server instead subsequently receives an EXCHANGE_ID
with the client owner equal to ownerid_arg, one strategy is with the client owner equal to ownerid_arg, one strategy is to
to simply delete the unconfirmed record, and process the simply delete the unconfirmed record, and process the
EXCHANGE_ID as described in the entirety of EXCHANGE_ID as described in the entirety of Section 18.35.4.
Section 18.35.4.
6. Update 6. Update
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server has
has the following confirmed record, then this request is an the following confirmed record, then this request is an attempt
attempt at an update. at an update.
{ ownerid_arg, verifier_arg, principal_arg, clientid_ret, { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
confirmed } confirmed }
Since the record has been confirmed, the client must have Since the record has been confirmed, the client must have
received the server's reply from the initial EXCHANGE_ID received the server's reply from the initial EXCHANGE_ID request.
request. The server allows the update, and the client record The server allows the update, and the client record is left
is left intact. intact.
7. Update but No Confirmed Record 7. Update but No Confirmed Record
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server has
has no confirmed record corresponding ownerid_arg, then the no confirmed record corresponding ownerid_arg, then the server
server returns NFS4ERR_NOENT and leaves any unconfirmed record returns NFS4ERR_NOENT and leaves any unconfirmed record intact.
intact.
8. Update but Wrong Verifier 8. Update but Wrong Verifier
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server has
has the following confirmed record, then this request is an the following confirmed record, then this request is an illegal
illegal attempt at an update, perhaps because of a retry from attempt at an update, perhaps because of a retry from a previous
a previous client incarnation. client incarnation.
{ ownerid_arg, old_verifier_arg, *, clientid_ret, confirmed } { ownerid_arg, old_verifier_arg, *, clientid_ret, confirmed }
The server returns NFS4ERR_NOT_SAME and leaves the client The server returns NFS4ERR_NOT_SAME and leaves the client record
record intact. intact.
9. Update but Wrong Principal 9. Update but Wrong Principal
If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is set, and the server has
has the following confirmed record, then this request is an the following confirmed record, then this request is an illegal
illegal attempt at an update by an unauthorized principal. attempt at an update by an unauthorized principal.
{ ownerid_arg, verifier_arg, old_principal_arg, clientid_ret, { ownerid_arg, verifier_arg, old_principal_arg, clientid_ret,
confirmed } confirmed }
The server returns NFS4ERR_PERM and leaves the client record The server returns NFS4ERR_PERM and leaves the client record
intact. intact.
18.36. Operation 43: CREATE_SESSION - Create New Session and Confirm 18.36. Operation 43: CREATE_SESSION - Create New Session and Confirm
Client ID Client ID
18.36.1. ARGUMENT 18.36.1. ARGUMENT
struct channel_attrs4 { struct channel_attrs4 {
count4 ca_headerpadsize; count4 ca_headerpadsize;
count4 ca_maxrequestsize; count4 ca_maxrequestsize;
count4 ca_maxresponsesize; count4 ca_maxresponsesize;
skipping to change at page 549, line 39 skipping to change at line 26199
CREATE_SESSION has no direct relation to the session specified in the CREATE_SESSION has no direct relation to the session specified in the
SEQUENCE operation, although the two sessions might be associated SEQUENCE operation, although the two sessions might be associated
with the same client ID. If CREATE_SESSION is sent without a with the same client ID. If CREATE_SESSION is sent without a
preceding SEQUENCE, then it MUST be the only operation in the preceding SEQUENCE, then it MUST be the only operation in the
COMPOUND procedure's request. If it is not, the server MUST return COMPOUND procedure's request. If it is not, the server MUST return
NFS4ERR_NOT_ONLY_OP. NFS4ERR_NOT_ONLY_OP.
In addition to creating a session, CREATE_SESSION has the following In addition to creating a session, CREATE_SESSION has the following
effects: effects:
o The first session created with a new client ID serves to confirm * The first session created with a new client ID serves to confirm
the creation of that client's state on the server. The server the creation of that client's state on the server. The server
returns the parameter values for the new session. returns the parameter values for the new session.
o The connection CREATE_SESSION that is sent over is associated with * The connection CREATE_SESSION that is sent over is associated with
the session's fore channel. the session's fore channel.
The arguments and results of CREATE_SESSION are described as follows: The arguments and results of CREATE_SESSION are described as follows:
csa_clientid: csa_clientid: This is the client ID with which the new session will
be associated. The corresponding result is csr_sessionid, the
This is the client ID with which the new session will be
associated. The corresponding result is csr_sessionid, the
session ID of the new session. session ID of the new session.
csa_sequence: csa_sequence: Each client ID serializes CREATE_SESSION via a per-
client ID sequence number (see Section 18.36.4). The
Each client ID serializes CREATE_SESSION via a per-client ID corresponding result is csr_sequence, which MUST be equal to
sequence number (see Section 18.36.4). The corresponding result csa_sequence.
is csr_sequence, which MUST be equal to csa_sequence.
In the next three arguments, the client offers a value that is to be In the next three arguments, the client offers a value that is to be
a property of the session. Except where stated otherwise, it is a property of the session. Except where stated otherwise, it is
RECOMMENDED that the server accept the value. If it is not RECOMMENDED that the server accept the value. If it is not
acceptable, the server MAY use a different value. Regardless, the acceptable, the server MAY use a different value. Regardless, the
server MUST return the value the session will use (which will be server MUST return the value the session will use (which will be
either what the client offered, or what the server is insisting on) either what the client offered, or what the server is insisting on)
to the client. to the client.
csa_flags: csa_flags: The csa_flags field contains a list of the following flag
bits:
The csa_flags field contains a list of the following flag bits:
CREATE_SESSION4_FLAG_PERSIST: CREATE_SESSION4_FLAG_PERSIST:
If CREATE_SESSION4_FLAG_PERSIST is set, the client wants the If CREATE_SESSION4_FLAG_PERSIST is set, the client wants the
server to provide a persistent reply cache. For sessions in server to provide a persistent reply cache. For sessions in
which only idempotent operations will be used (e.g., a read- which only idempotent operations will be used (e.g., a read-
only session), clients SHOULD NOT set only session), clients SHOULD NOT set
CREATE_SESSION4_FLAG_PERSIST. If the server does not or cannot CREATE_SESSION4_FLAG_PERSIST. If the server does not or cannot
provide a persistent reply cache, the server MUST NOT set provide a persistent reply cache, the server MUST NOT set
CREATE_SESSION4_FLAG_PERSIST in the field csr_flags. CREATE_SESSION4_FLAG_PERSIST in the field csr_flags.
If the server is a pNFS metadata server, for reasons described If the server is a pNFS metadata server, for reasons described
in Section 12.5.2 it SHOULD support in Section 12.5.2 it SHOULD support
skipping to change at page 551, line 19 skipping to change at line 26266
is currently in non-RDMA mode but has the capability to operate is currently in non-RDMA mode but has the capability to operate
in RDMA mode, then the client is requesting that the server in RDMA mode, then the client is requesting that the server
"step up" to RDMA mode on the connection. If the server "step up" to RDMA mode on the connection. If the server
agrees, it sets CREATE_SESSION4_FLAG_CONN_RDMA in the result agrees, it sets CREATE_SESSION4_FLAG_CONN_RDMA in the result
field csr_flags. If CREATE_SESSION4_FLAG_CONN_RDMA is not set field csr_flags. If CREATE_SESSION4_FLAG_CONN_RDMA is not set
in csa_flags, then CREATE_SESSION4_FLAG_CONN_RDMA MUST NOT be in csa_flags, then CREATE_SESSION4_FLAG_CONN_RDMA MUST NOT be
set in csr_flags. Note that once the server agrees to step up, set in csr_flags. Note that once the server agrees to step up,
it and the client MUST exchange all future traffic on the it and the client MUST exchange all future traffic on the
connection with RPC RDMA framing and not Record Marking ([32]). connection with RPC RDMA framing and not Record Marking ([32]).
csa_fore_chan_attrs, csa_fore_chan_attrs: csa_fore_chan_attrs, csa_back_chan_attrs: The csa_fore_chan_attrs
and csa_back_chan_attrs fields apply to attributes of the fore
The csa_fore_chan_attrs and csa_back_chan_attrs fields apply to channel (which conveys requests originating from the client to the
attributes of the fore channel (which conveys requests originating server), and the backchannel (the channel that conveys callback
from the client to the server), and the backchannel (the channel requests originating from the server to the client), respectively.
that conveys callback requests originating from the server to the The results are in corresponding structures called
client), respectively. The results are in corresponding csr_fore_chan_attrs and csr_back_chan_attrs. The results
structures called csr_fore_chan_attrs and csr_back_chan_attrs. establish attributes for each channel, and on all subsequent use
The results establish attributes for each channel, and on all of each channel of the session. Each structure has the following
subsequent use of each channel of the session. Each structure has fields:
the following fields:
ca_headerpadsize: ca_headerpadsize:
The maximum amount of padding the requester is willing to apply The maximum amount of padding the requester is willing to apply
to ensure that write payloads are aligned on some boundary at to ensure that write payloads are aligned on some boundary at
the replier. For each channel, the server the replier. For each channel, the server
+ will reply in ca_headerpadsize with its preferred value, or * will reply in ca_headerpadsize with its preferred value, or
zero if padding is not in use, and zero if padding is not in use, and
+ MAY decrease this value but MUST NOT increase it. * MAY decrease this value but MUST NOT increase it.
ca_maxrequestsize: ca_maxrequestsize:
The maximum size of a COMPOUND or CB_COMPOUND request that will The maximum size of a COMPOUND or CB_COMPOUND request that will
be sent. This size represents the XDR encoded size of the be sent. This size represents the XDR encoded size of the
request, including the RPC headers (including security flavor request, including the RPC headers (including security flavor
credentials and verifiers) but excludes any RPC transport credentials and verifiers) but excludes any RPC transport
framing headers. Imagine a request coming over a non-RDMA TCP/ framing headers. Imagine a request coming over a non-RDMA TCP/
IP connection, and that it has a single Record Marking header IP connection, and that it has a single Record Marking header
preceding it. The maximum allowable count encoded in the preceding it. The maximum allowable count encoded in the
header will be ca_maxrequestsize. If a requester sends a header will be ca_maxrequestsize. If a requester sends a
request that exceeds ca_maxrequestsize, the error request that exceeds ca_maxrequestsize, the error
NFS4ERR_REQ_TOO_BIG will be returned per the description in NFS4ERR_REQ_TOO_BIG will be returned per the description in
skipping to change at page 552, line 23 skipping to change at line 26315
server MAY decrease this value, but MUST NOT increase it. server MAY decrease this value, but MUST NOT increase it.
However, if the client selects a value for ca_maxresponsesize However, if the client selects a value for ca_maxresponsesize
such that a replier on a channel could never send a response, such that a replier on a channel could never send a response,
the server SHOULD return NFS4ERR_TOOSMALL in the CREATE_SESSION the server SHOULD return NFS4ERR_TOOSMALL in the CREATE_SESSION
reply. After the session is created, if a requester sends a reply. After the session is created, if a requester sends a
request for which the size of the reply would exceed this request for which the size of the reply would exceed this
value, the replier will return NFS4ERR_REP_TOO_BIG, per the value, the replier will return NFS4ERR_REP_TOO_BIG, per the
description in Section 2.10.6.4. description in Section 2.10.6.4.
ca_maxresponsesize_cached: ca_maxresponsesize_cached:
Like ca_maxresponsesize, but the maximum size of a reply that Like ca_maxresponsesize, but the maximum size of a reply that
will be stored in the reply cache (Section 2.10.6.1). For each will be stored in the reply cache (Section 2.10.6.1). For each
channel, the server MAY decrease this value, but MUST NOT channel, the server MAY decrease this value, but MUST NOT
increase it. If, in the reply to CREATE_SESSION, the value of increase it. If, in the reply to CREATE_SESSION, the value of
ca_maxresponsesize_cached of a channel is less than the value ca_maxresponsesize_cached of a channel is less than the value
of ca_maxresponsesize of the same channel, then this is an of ca_maxresponsesize of the same channel, then this is an
indication to the requester that it needs to be selective about indication to the requester that it needs to be selective about
which replies it directs the replier to cache; for example, which replies it directs the replier to cache; for example,
large replies from nonidempotent operations (e.g., COMPOUND large replies from non-idempotent operations (e.g., COMPOUND
requests with a READ operation) should not be cached. The requests with a READ operation) should not be cached. The
requester decides which replies to cache via an argument to the requester decides which replies to cache via an argument to the
SEQUENCE (the sa_cachethis field, see Section 18.46) or SEQUENCE (the sa_cachethis field, see Section 18.46) or
CB_SEQUENCE (the csa_cachethis field, see Section 20.9) CB_SEQUENCE (the csa_cachethis field, see Section 20.9)
operations. After the session is created, if a requester sends operations. After the session is created, if a requester sends
a request for which the size of the reply would exceed a request for which the size of the reply would exceed
ca_maxresponsesize_cached, the replier will return ca_maxresponsesize_cached, the replier will return
NFS4ERR_REP_TOO_BIG_TO_CACHE, per the description in NFS4ERR_REP_TOO_BIG_TO_CACHE, per the description in
Section 2.10.6.4. Section 2.10.6.4.
skipping to change at page 552, line 44 skipping to change at line 26335
requester decides which replies to cache via an argument to the requester decides which replies to cache via an argument to the
SEQUENCE (the sa_cachethis field, see Section 18.46) or SEQUENCE (the sa_cachethis field, see Section 18.46) or
CB_SEQUENCE (the csa_cachethis field, see Section 20.9) CB_SEQUENCE (the csa_cachethis field, see Section 20.9)
operations. After the session is created, if a requester sends operations. After the session is created, if a requester sends
a request for which the size of the reply would exceed a request for which the size of the reply would exceed
ca_maxresponsesize_cached, the replier will return ca_maxresponsesize_cached, the replier will return
NFS4ERR_REP_TOO_BIG_TO_CACHE, per the description in NFS4ERR_REP_TOO_BIG_TO_CACHE, per the description in
Section 2.10.6.4. Section 2.10.6.4.
ca_maxoperations: ca_maxoperations:
The maximum number of operations the replier will accept in a The maximum number of operations the replier will accept in a
COMPOUND or CB_COMPOUND. For the backchannel, the server MUST COMPOUND or CB_COMPOUND. For the backchannel, the server MUST
NOT change the value the client offers. For the fore channel, NOT change the value the client offers. For the fore channel,
the server MAY change the requested value. After the session the server MAY change the requested value. After the session
is created, if a requester sends a COMPOUND or CB_COMPOUND with is created, if a requester sends a COMPOUND or CB_COMPOUND with
more operations than ca_maxoperations, the replier MUST return more operations than ca_maxoperations, the replier MUST return
NFS4ERR_TOO_MANY_OPS. NFS4ERR_TOO_MANY_OPS.
ca_maxrequests: ca_maxrequests:
The maximum number of concurrent COMPOUND or CB_COMPOUND The maximum number of concurrent COMPOUND or CB_COMPOUND
requests the requester will send on the session. Subsequent requests the requester will send on the session. Subsequent
requests will each be assigned a slot identifier by the requests will each be assigned a slot identifier by the
requester within the range zero to ca_maxrequests - 1 requester within the range zero to ca_maxrequests - 1
inclusive. For the backchannel, the server MUST NOT change the inclusive. For the backchannel, the server MUST NOT change the
value the client offers. For the fore channel, the server MAY value the client offers. For the fore channel, the server MAY
change the requested value. change the requested value.
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). For each channel, the server MAY decrease this depth (IRD). For each channel, the server MAY decrease this
value, but MUST NOT increase it. value, but MUST NOT increase it.
csa_cb_program csa_cb_program This is the ONC RPC program number the server MUST
use in any callbacks sent through the backchannel to the client.
This is the ONC RPC program number the server MUST use in any The server MUST specify an ONC RPC program number equal to
callbacks sent through the backchannel to the client. The server csa_cb_program and an ONC RPC version number equal to 4 in
MUST specify an ONC RPC program number equal to csa_cb_program and callbacks sent to the client. If a CB_COMPOUND is sent to the
an ONC RPC version number equal to 4 in callbacks sent to the client, the server MUST use a minor version number of 1. There is
client. If a CB_COMPOUND is sent to the client, the server MUST no corresponding result.
use a minor version number of 1. There is no corresponding
result.
csa_sec_parms
The field csa_sec_parms is an array of acceptable security csa_sec_parms The field csa_sec_parms is an array of acceptable
credentials the server can use on the session's backchannel. security credentials the server can use on the session's
Three security flavors are supported: AUTH_NONE, AUTH_SYS, and backchannel. Three security flavors are supported: AUTH_NONE,
RPCSEC_GSS. If AUTH_NONE is specified for a credential, then this AUTH_SYS, and RPCSEC_GSS. If AUTH_NONE is specified for a
says the client is authorizing the server to use AUTH_NONE on all credential, then this says the client is authorizing the server to
callbacks for the session. If AUTH_SYS is specified, then the use AUTH_NONE on all callbacks for the session. If AUTH_SYS is
client is authorizing the server to use AUTH_SYS on all callbacks, specified, then the client is authorizing the server to use
using the credential specified cbsp_sys_cred. If RPCSEC_GSS is AUTH_SYS on all callbacks, using the credential specified
specified, then the server is allowed to use the RPCSEC_GSS cbsp_sys_cred. If RPCSEC_GSS is specified, then the server is
context specified in cbsp_gss_parms as the RPCSEC_GSS context in allowed to use the RPCSEC_GSS context specified in cbsp_gss_parms
the credential of the RPC header of callbacks to the client. as the RPCSEC_GSS context in the credential of the RPC header of
There is no corresponding result. callbacks to the client. There is no corresponding result.
The RPCSEC_GSS context for the backchannel is specified via a pair The RPCSEC_GSS context for the backchannel is specified via a pair
of values of data type gsshandle4_t. The data type gsshandle4_t of values of data type gsshandle4_t. The data type gsshandle4_t
represents an RPCSEC_GSS handle, and is precisely the same as the represents an RPCSEC_GSS handle, and is precisely the same as the
data type of the "handle" field of the rpc_gss_init_res data type data type of the "handle" field of the rpc_gss_init_res data type
defined in Section 5.2.3.1, "Context Creation Response - defined in "Context Creation Response - Successful Acceptance",
Successful Acceptance", of [4]. Section 5.2.3.1 of [4].
The first RPCSEC_GSS handle, gcbp_handle_from_server, is the fore The first RPCSEC_GSS handle, gcbp_handle_from_server, is the fore
handle the server returned to the client (either in the handle handle the server returned to the client (either in the handle
field of data type rpc_gss_init_res or as one of the elements of field of data type rpc_gss_init_res or as one of the elements of
the spi_handles field returned in the reply to EXCHANGE_ID) when the spi_handles field returned in the reply to EXCHANGE_ID) when
the RPCSEC_GSS context was created on the server. The second the RPCSEC_GSS context was created on the server. The second
handle, gcbp_handle_from_client, is the back handle to which the handle, gcbp_handle_from_client, is the back handle to which the
client will map the RPCSEC_GSS context. The server can client will map the RPCSEC_GSS context. The server can
immediately use the value of gcbp_handle_from_client in the immediately use the value of gcbp_handle_from_client in the
RPCSEC_GSS credential in callback RPCs. That is, the value in RPCSEC_GSS credential in callback RPCs. That is, the value in
gcbp_handle_from_client can be used as the value of the field gcbp_handle_from_client can be used as the value of the field
"handle" in data type rpc_gss_cred_t (see Section 5, "Elements of "handle" in data type rpc_gss_cred_t (see "Elements of the
the RPCSEC_GSS Security Protocol", of [4]) in callback RPCs. The RPCSEC_GSS Security Protocol", Section 5 of [4]) in callback RPCs.
server MUST use the RPCSEC_GSS security service specified in The server MUST use the RPCSEC_GSS security service specified in
gcbp_service, i.e., it MUST set the "service" field of the gcbp_service, i.e., it MUST set the "service" field of the
rpc_gss_cred_t data type in RPCSEC_GSS credential to the value of rpc_gss_cred_t data type in RPCSEC_GSS credential to the value of
gcbp_service (see Section 5.3.1, "RPC Request Header", of [4]). gcbp_service (see "RPC Request Header", Section 5.3.1 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.
Within each element of csa_sec_parms, the fore and back RPCSEC_GSS Within each element of csa_sec_parms, the fore and back RPCSEC_GSS
contexts MUST share the same GSS context and MUST have the same contexts MUST share the same GSS context and MUST have the same
seq_window (see Section 5.2.3.1 of RFC2203 [4]). The fore and seq_window (see Section 5.2.3.1 of RFC 2203 [4]). The fore and
back RPCSEC_GSS context state are independent of each other as far back RPCSEC_GSS context state are independent of each other as far
as the RPCSEC_GSS sequence number (see the seq_num field in the as the RPCSEC_GSS sequence number (see the seq_num field in the
rpc_gss_cred_t data type of Sections 5 and 5.3.1 of [4]). rpc_gss_cred_t data type of Sections 5 and 5.3.1 of [4]).
If an RPCSEC_GSS handle is using the SSV context (see If an RPCSEC_GSS handle is using the SSV context (see
Section 2.10.9), then because each SSV RPCSEC_GSS handle shares a Section 2.10.9), then because each SSV RPCSEC_GSS handle shares a
common SSV GSS context, there are security considerations specific common SSV GSS context, there are security considerations specific
to this situation discussed in Section 2.10.10. to this situation discussed in Section 2.10.10.
Once the session is created, the first SEQUENCE or CB_SEQUENCE Once the session is created, the first SEQUENCE or CB_SEQUENCE
skipping to change at page 555, line 13 skipping to change at line 26440
CREATE_SESSION4args structure of the current request. CREATE_SESSION4args structure of the current request.
Since CREATE_SESSION is a non-idempotent operation, we need to Since CREATE_SESSION is a non-idempotent operation, we need to
consider the possibility that retries may occur as a result of a consider the possibility that retries may occur as a result of a
client restart, network partition, malfunctioning router, etc. For client restart, network partition, malfunctioning router, etc. For
each client ID created by EXCHANGE_ID, the server maintains a each client ID created by EXCHANGE_ID, the server maintains a
separate reply cache (called the CREATE_SESSION reply cache) similar separate reply cache (called the CREATE_SESSION reply cache) similar
to the 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 * 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 * 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.
As previously stated, CREATE_SESSION can be sent with or without a As previously stated, CREATE_SESSION can be sent with or without a
preceding SEQUENCE operation. Even if a SEQUENCE precedes preceding SEQUENCE operation. Even if a SEQUENCE precedes
CREATE_SESSION, the server MUST maintain the CREATE_SESSION reply CREATE_SESSION, the server MUST maintain the CREATE_SESSION reply
cache, which is separate from the reply cache for the session cache, which is separate from the reply cache for the session
associated with a SEQUENCE. If CREATE_SESSION was originally sent by associated with a SEQUENCE. If CREATE_SESSION was originally sent by
itself, the client MAY send a retry of the CREATE_SESSION operation itself, the client MAY send a retry of the CREATE_SESSION operation
skipping to change at page 558, line 16 skipping to change at line 26589
slots, in some cases perhaps more that the fore channel, in order to slots, in some cases perhaps more that the fore channel, in order to
deal with the situations where the network link has high latency and deal with the situations where the network link has high latency and
is the primary bottleneck for response to recalls. If so, and if the is 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 client. limit the number of recallable objects it gives to the client.
Implementing RPCSEC_GSS callback support requires changes to both the Implementing RPCSEC_GSS callback support requires changes to both the
client and server implementations of RPCSEC_GSS. One possible set of client and server implementations of RPCSEC_GSS. One possible set of
changes includes: changes includes:
o Adding a data structure that wraps the GSS-API context with a * Adding a data structure that wraps the GSS-API context with a
reference count. reference count.
o New functions to increment and decrement the reference count. If * New functions to increment and decrement the reference count. If
the reference count is decremented to zero, the wrapper data the reference count is decremented to zero, the wrapper data
structure and the GSS-API context it refers to would be freed. structure and the GSS-API context it refers to would be freed.
o Change RPCSEC_GSS to create the wrapper data structure upon * Change RPCSEC_GSS to create the wrapper data structure upon
receiving GSS-API context from gss_accept_sec_context() and receiving GSS-API context from gss_accept_sec_context() and
gss_init_sec_context(). The reference count would be initialized gss_init_sec_context(). The reference count would be initialized
to 1. to 1.
o Adding a function to map an existing RPCSEC_GSS handle to a * Adding a function to map an existing RPCSEC_GSS handle to a
pointer to the wrapper data structure. The reference count would pointer to the wrapper data structure. The reference count would
be incremented. be incremented.
o Adding a function to create a new RPCSEC_GSS handle from a pointer * Adding a function to create a new RPCSEC_GSS handle from a pointer
to the wrapper data structure. The reference count would be to the wrapper data structure. The reference count would be
incremented. incremented.
o Replacing calls from RPCSEC_GSS that free GSS-API contexts, with * Replacing calls from RPCSEC_GSS that free GSS-API contexts, with
calls to decrement the reference count on the wrapper data calls to decrement the reference count on the wrapper data
structure. structure.
18.37. Operation 44: DESTROY_SESSION - Destroy a Session 18.37. Operation 44: DESTROY_SESSION - Destroy a Session
18.37.1. ARGUMENT 18.37.1. ARGUMENT
struct DESTROY_SESSION4args { struct DESTROY_SESSION4args {
sessionid4 dsa_sessionid; sessionid4 dsa_sessionid;
}; };
skipping to change at page 559, line 32 skipping to change at line 26648
state protection was specified when the client ID was created, the state protection was specified when the client ID was created, the
RPCSEC_GSS principal that created the session MUST be the one that RPCSEC_GSS principal that created the session MUST be the one that
destroys the session, using RPCSEC_GSS privacy or integrity. If destroys the session, using RPCSEC_GSS privacy or integrity. If
SP4_SSV state protection was specified when the client ID was SP4_SSV state protection was specified when the client ID was
created, RPCSEC_GSS using the SSV mechanism (Section 2.10.9) MUST be created, RPCSEC_GSS using the SSV mechanism (Section 2.10.9) MUST be
used, with integrity or privacy. used, with integrity or privacy.
If the COMPOUND request starts with SEQUENCE, and if the sessionids If the COMPOUND request starts with SEQUENCE, and if the sessionids
specified in SEQUENCE and DESTROY_SESSION are the same, then specified in SEQUENCE and DESTROY_SESSION are the same, then
o DESTROY_SESSION MUST be the final operation in the COMPOUND * DESTROY_SESSION MUST be the final operation in the COMPOUND
request. request.
o It is advisable to avoid placing DESTROY_SESSION in a COMPOUND * It is advisable to avoid placing DESTROY_SESSION in a COMPOUND
request with other state-modifying operations, because the request with other state-modifying operations, because the
DESTROY_SESSION will destroy the reply cache. DESTROY_SESSION will destroy the reply cache.
o Because the session and its reply cache are destroyed, a client * Because the session and its reply cache are destroyed, a client
that retries the request may receive an error in reply to the that retries the request may receive an error in reply to the
retry, even though the original request was successful. retry, even though the original request was successful.
If the COMPOUND request starts with SEQUENCE, and if the sessionids If the COMPOUND request starts with SEQUENCE, and if the sessionids
specified in SEQUENCE and DESTROY_SESSION are different, then specified in SEQUENCE and DESTROY_SESSION are different, then
DESTROY_SESSION can appear in any position of the COMPOUND request DESTROY_SESSION can appear in any position of the COMPOUND request
(except for the first position). The two sessionids can belong to (except for the first position). The two sessionids can belong to
different client IDs. different client IDs.
If the COMPOUND request does not start with SEQUENCE, and if If the COMPOUND request does not start with SEQUENCE, and if
skipping to change at page 567, line 27 skipping to change at line 26989
abruptly, or force layouts using the device ID to be recalled or abruptly, or force layouts using the device ID to be recalled or
revoked. revoked.
It is possible that GETDEVICEINFO (and GETDEVICELIST) will race with It is possible that GETDEVICEINFO (and GETDEVICELIST) will race with
CB_NOTIFY_DEVICEID, i.e., CB_NOTIFY_DEVICEID arrives before the CB_NOTIFY_DEVICEID, i.e., CB_NOTIFY_DEVICEID arrives before the
client gets and processes the response to GETDEVICEINFO or client gets and processes the response to GETDEVICEINFO or
GETDEVICELIST. The analysis of the race leverages the fact that the GETDEVICELIST. The analysis of the race leverages the fact that the
server MUST NOT delete a device ID that is referred to by a layout server MUST NOT delete a device ID that is referred to by a layout
the client has. the client has.
o CB_NOTIFY_DEVICEID deletes a device ID. If the client believes it * CB_NOTIFY_DEVICEID deletes a device ID. If the client believes it
has layouts that refer to the device ID, then it is possible that has layouts that refer to the device ID, then it is possible that
layouts referring to the deleted device ID have been revoked. The layouts referring to the deleted device ID have been revoked. The
client should send a TEST_STATEID request using the stateid for client should send a TEST_STATEID request using the stateid for
each layout that might have been revoked. If TEST_STATEID each layout that might have been revoked. If TEST_STATEID
indicates that any layouts have been revoked, the client must indicates that any layouts have been revoked, the client must
recover from layout revocation as described in Section 12.5.6. If recover from layout revocation as described in Section 12.5.6. If
TEST_STATEID indicates that at least one layout has not been TEST_STATEID indicates that at least one layout has not been
revoked, the client should send a GETDEVICEINFO operation on the revoked, the client should send a GETDEVICEINFO operation on the
supposedly deleted device ID to verify that the device ID has been supposedly deleted device ID to verify that the device ID has been
deleted. deleted.
skipping to change at page 568, line 5 skipping to change at line 27014
ID does exist, then while the server is faulty for sending an ID does exist, then while the server is faulty for sending an
erroneous device ID deletion notification, the degree to which it erroneous device ID deletion notification, the degree to which it
is faulty does not require the client to create a new client ID. is faulty does not require the client to create a new client ID.
If the client does not have layouts that refer to the device ID, If the client does not have layouts that refer to the device ID,
no harm is done. The client should mark the device ID as deleted, no harm is done. The client should mark the device ID as deleted,
and when GETDEVICEINFO or GETDEVICELIST results are received that and when GETDEVICEINFO or GETDEVICELIST results are received that
indicate that the device ID has been in fact deleted, the device indicate that the device ID has been in fact deleted, the device
ID should be removed from the client's cache. ID should be removed from the client's cache.
o CB_NOTIFY_DEVICEID indicates that a device ID's device addressing * CB_NOTIFY_DEVICEID indicates that a device ID's device addressing
mappings have changed. The client should assume that the results mappings have changed. The client should assume that the results
from the in-progress GETDEVICEINFO will be stale for the device ID from the in-progress GETDEVICEINFO will be stale for the device ID
once received, and so it should send another GETDEVICEINFO on the once received, and so it should send another GETDEVICEINFO on the
device ID. device ID.
18.41. Operation 48: GETDEVICELIST - Get All Device Mappings for a File 18.41. Operation 48: GETDEVICELIST - Get All Device Mappings for a File
System System
18.41.1. ARGUMENT 18.41.1. ARGUMENT
skipping to change at page 573, line 33 skipping to change at line 27256
expansive recovery of file system objects if the metadata server does expansive recovery of file system objects if the metadata server does
not get a positive indication from all clients holding a not get a positive indication from all clients holding a
LAYOUTIOMODE4_RW layout that they have successfully completed all LAYOUTIOMODE4_RW layout that they have successfully completed all
their writes. Sending a LAYOUTCOMMIT (if required) and then their writes. Sending a LAYOUTCOMMIT (if required) and then
following with LAYOUTRETURN can provide such an indication and allow following with LAYOUTRETURN can provide such an indication and allow
for graceful and efficient recovery. for graceful and efficient recovery.
If loca_reclaim is TRUE, the metadata server is free to either If loca_reclaim is TRUE, the metadata server is free to either
examine or ignore the value in the field loca_stateid. The metadata examine or ignore the value in the field loca_stateid. The metadata
server implementation might or might not encode in its layout stateid server implementation might or might not encode in its layout stateid
information that allows the metadate server to perform a consistency information that allows the metadata server to perform a consistency
check on the LAYOUTCOMMIT request. check on the LAYOUTCOMMIT request.
18.43. Operation 50: LAYOUTGET - Get Layout Information 18.43. Operation 50: LAYOUTGET - Get Layout Information
18.43.1. ARGUMENT 18.43.1. ARGUMENT
struct LAYOUTGET4args { struct LAYOUTGET4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
bool loga_signal_layout_avail; bool loga_signal_layout_avail;
layouttype4 loga_layout_type; layouttype4 loga_layout_type;
skipping to change at page 575, line 8 skipping to change at line 27325
MUST be less than or equal to loga_length. MUST be less than or equal to loga_length.
When a length field is set to NFS4_UINT64_MAX, this indicates a When a length field is set to NFS4_UINT64_MAX, this indicates a
desire (when loga_length is NFS4_UINT64_MAX) or requirement (when desire (when loga_length is NFS4_UINT64_MAX) or requirement (when
loga_minlength is NFS4_UINT64_MAX) to get a layout from loga_offset loga_minlength is NFS4_UINT64_MAX) to get a layout from loga_offset
through the end-of-file, regardless of the file's length. through the end-of-file, regardless of the file's length.
The following rules govern the relationships among, and the minima The following rules govern the relationships among, and the minima
of, loga_length, loga_minlength, and loga_offset. of, loga_length, loga_minlength, and loga_offset.
o If loga_length is less than loga_minlength, the metadata server * If loga_length is less than loga_minlength, the metadata server
MUST return NFS4ERR_INVAL. MUST return NFS4ERR_INVAL.
o If loga_minlength is zero, this is an indication to the metadata * If loga_minlength is zero, this is an indication to the metadata
server that the client desires any layout at offset loga_offset or server that the client desires any layout at offset loga_offset or
less that the metadata server has "readily available". Readily is less that the metadata server has "readily available". Readily is
subjective, and depends on the layout type and the pNFS server subjective, and depends on the layout type and the pNFS server
implementation. For example, some metadata servers might have to implementation. For example, some metadata servers might have to
pre-allocate stable storage when they receive a request for a pre-allocate stable storage when they receive a request for a
range of a file that goes beyond the file's current length. If range of a file that goes beyond the file's current length. If
loga_minlength is zero and loga_length is greater than zero, this loga_minlength is zero and loga_length is greater than zero, this
tells the metadata server what range of the layout the client tells the metadata server what range of the layout the client
would prefer to have. If loga_length and loga_minlength are both would prefer to have. If loga_length and loga_minlength are both
zero, then the client is indicating that it desires a layout of zero, then the client is indicating that it desires a layout of
any length with the ending offset of the range no less than the any length with the ending offset of the range no less than the
value specified loga_offset, and the starting offset at or below value specified loga_offset, and the starting offset at or below
loga_offset. If the metadata server does not have a layout that loga_offset. If the metadata server does not have a layout that
is readily available, then it MUST return NFS4ERR_LAYOUTTRYLATER. is readily available, then it MUST return NFS4ERR_LAYOUTTRYLATER.
o If the sum of loga_offset and loga_minlength exceeds * 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, * 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 13. MUST return a layout according to the rules in Table 22.
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 request | of reply | of reply | |
| | request | | | | +===========+============+==========+==========+===================+
+-----------+-----------+----------+----------+---------------------+ | _READ | u64m | MAY be | MUST be | MUST be >= file |
| _READ | u64m | MAY be | MUST be | MUST be >= file | | | | _READ | <= a_off | length - layout |
| | | _READ | <= a_off | length - layout | | | | | | offset |
| | | | | offset | +-----------+------------+----------+----------+-------------------+
| _READ | u64m | MAY be | MUST be | MUST be u64m | | _READ | u64m | MAY be | MUST be | MUST be u64m |
| | | _RW | <= a_off | | | | | _RW | <= a_off | |
| _READ | > 0 and < | MAY be | MUST be | MUST be >= MIN(file | +-----------+------------+----------+----------+-------------------+
| | u64m | _READ | <= a_off | length, a_minlen + | | _READ | > 0 and < | MAY be | MUST be | MUST be >= |
| | | | | a_off) - layout | | | u64m | _READ | <= a_off | MIN(file length, |
| | | | | offset | | | | | | a_minlen + a_off) |
| _READ | > 0 and < | MAY be | MUST be | MUST be >= a_off - | | | | | | - layout offset |
| | u64m | _RW | <= a_off | layout offset + | +-----------+------------+----------+----------+-------------------+
| | | | | a_minlen | | _READ | > 0 and < | MAY be | MUST be | MUST be >= a_off |
| _READ | 0 | MAY be | MUST be | MUST be > 0 | | | u64m | _RW | <= a_off | - layout offset + |
| | | _READ | <= a_off | | | | | | | a_minlen |
| _READ | 0 | MAY be | MUST be | MUST be > 0 | +-----------+------------+----------+----------+-------------------+
| | | _RW | <= a_off | | | _READ | 0 | MAY be | MUST be | MUST be > 0 |
| _RW | u64m | MUST be | MUST be | MUST be u64m | | | | _READ | <= a_off | |
| | | _RW | <= a_off | | +-----------+------------+----------+----------+-------------------+
| _RW | > 0 and < | MUST be | MUST be | MUST be >= a_off - | | _READ | 0 | MAY be | MUST be | MUST be > 0 |
| | u64m | _RW | <= a_off | layout offset + | | | | _RW | <= a_off | |
| | | | | a_minlen | +-----------+------------+----------+----------+-------------------+
| _RW | 0 | MUST be | MUST be | MUST be > 0 | | _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 |
| | u64m | _RW | <= a_off | - layout offset + |
| | | | | a_minlen |
+-----------+------------+----------+----------+-------------------+
| _RW | 0 | MUST be | MUST be | MUST be > 0 |
| | | _RW | <= a_off | |
+-----------+------------+----------+----------+-------------------+
Table 13 Table 22
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 13, then the metadata server layout according to the rules in Table 22, 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 13, then the metadata server MUST return the to the rules in Table 22, then the metadata server MUST return the
error NFS4ERR_LAYOUTTRYLATER. Assuming that loga_length is greater error NFS4ERR_LAYOUTTRYLATER. Assuming that loga_length is greater
than loga_minlength or equal to zero, the metadata server SHOULD than loga_minlength or equal to zero, the metadata server SHOULD
return a layout according to the rules in Table 14. return a layout according to the rules in Table 23.
Desired layouts based on loga_length. The rules of Table 13 MUST be Desired layouts based on loga_length. The rules of Table 22 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 iomode | Layout | Layout | Layout | Layout length |
| iomode of | a_len of | iomode of | offset of | of reply | | of request | a_len of | iomode | offset | of reply |
| request | request | reply | reply | | | | request | of reply | of 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 | |
| _READ | u64m | MAY be | MUST be | SHOULD be u64m | +---------------+----------+----------+----------+----------------+
| | | _RW | <= a_off | | | _READ | u64m | MAY be | MUST be | SHOULD be u64m |
| _READ | > 0 and < | MAY be | MUST be | SHOULD be >= | | | | _RW | <= a_off | |
| | u64m | _READ | <= a_off | a_off - layout | +---------------+----------+----------+----------+----------------+
| | | | | offset + a_len | | _READ | > 0 and | MAY be | MUST be | SHOULD be >= |
| _READ | > 0 and < | MAY be | MUST be | SHOULD be >= | | | < u64m | _READ | <= a_off | a_off - layout |
| | u64m | _RW | <= a_off | a_off - layout | | | | | | offset + a_len |
| | | | | offset + a_len | +---------------+----------+----------+----------+----------------+
| _READ | 0 | MAY be | MUST be | SHOULD be > | | _READ | > 0 and | MAY be | MUST be | SHOULD be >= |
| | | _READ | <= a_off | a_off - layout | | | < u64m | _RW | <= a_off | a_off - layout |
| | | | | offset | | | | | | offset + a_len |
| _READ | 0 | MAY be | MUST be | SHOULD be > | +---------------+----------+----------+----------+----------------+
| | | _READ | <= a_off | a_off - layout | | _READ | 0 | MAY be | MUST be | SHOULD be > |
| | | | | offset | | | | _READ | <= a_off | a_off - layout |
| _RW | u64m | MUST be | MUST be | SHOULD be u64m | | | | | | offset |
| | | _RW | <= a_off | | +---------------+----------+----------+----------+----------------+
| _RW | > 0 and < | MUST be | MUST be | SHOULD be >= | | _READ | 0 | MAY be | MUST be | SHOULD be > |
| | u64m | _RW | <= a_off | a_off - layout | | | | _READ | <= a_off | a_off - layout |
| | | | | offset + a_len | | | | | | offset |
| _RW | 0 | MUST be | MUST be | SHOULD be > | +---------------+----------+----------+----------+----------------+
| | | _RW | <= a_off | a_off - layout | | _RW | u64m | MUST be | MUST be | SHOULD be u64m |
| | | | | offset | | | | _RW | <= a_off | |
+------------+------------+-----------+-----------+-----------------+ +---------------+----------+----------+----------+----------------+
| _RW | > 0 and | MUST be | MUST be | SHOULD be >= |
| | < u64m | _RW | <= a_off | a_off - layout |
| | | | | offset + a_len |
+---------------+----------+----------+----------+----------------+
| _RW | 0 | MUST be | MUST be | SHOULD be > |
| | | _RW | <= a_off | a_off - layout |
| | | | | offset |
+---------------+----------+----------+----------+----------------+
Table 14 Table 23
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 578, line 17 skipping to change at line 27476
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 13 and Table 14 both refer to a returned layout iomode, offset, Table 22 and Table 23 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 22
and Table 23 is equal to the value of the lo_iomode field in each
The value of the returned layout iomode listed in Table 13 and element of logr_layout. As shown in Table 22 and Table 23, the
Table 14 is equal to the value of the lo_iomode field in each
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 LAYOUTIOMODE4_READ requests to an implementation to upgrade LAYOUTIOMODE4_READ requests to
LAYOUTIOMODE4_RW requests at its discretion, within the limits of LAYOUTIOMODE4_RW requests at its discretion, within the limits of
the layout type specific protocol. A lo_iomode of either the layout type specific protocol. A lo_iomode of either
LAYOUTIOMODE4_READ or LAYOUTIOMODE4_RW MUST be returned. LAYOUTIOMODE4_READ or LAYOUTIOMODE4_RW MUST be returned.
offset offset The value of the returned layout offset listed in Table 22
and Table 23 is always equal to the lo_offset field of the first
The value of the returned layout offset listed in Table 13 and
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 13 states that the metadata * If an applicable rule of Table 22 states that the metadata
server MUST return a layout of length NFS4_UINT64_MAX, then the server MUST return a layout of length NFS4_UINT64_MAX, then the
lo_length field of the last element of logr_layout MUST be lo_length field of the last element of logr_layout MUST be
NFS4_UINT64_MAX. NFS4_UINT64_MAX.
* If an applicable rule of Table 13 states that the metadata * If an applicable rule of Table 22 states that the metadata
server MUST NOT return a layout of length NFS4_UINT64_MAX, then server MUST NOT return a layout of length NFS4_UINT64_MAX, then
the lo_length field of the last element of logr_layout MUST NOT the lo_length field of the last element of logr_layout MUST NOT
be NFS4_UINT64_MAX. be NFS4_UINT64_MAX.
* If an applicable rule of Table 14 states that the metadata * If an applicable rule of Table 23 states that the metadata
server SHOULD return a layout of length NFS4_UINT64_MAX, then server SHOULD return a layout of length NFS4_UINT64_MAX, then
the lo_length field of the last element of logr_layout SHOULD the lo_length field of the last element of logr_layout SHOULD
be NFS4_UINT64_MAX. be NFS4_UINT64_MAX.
* When the value of the returned layout length of Table 13 and * When the value of the returned layout length of Table 22 and
Table 14 is not NFS4_UINT64_MAX, then the returned layout Table 23 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 in which the client fails to return the layout before close. case in which the client fails to return the layout before close.
For the metadata server that knows a layout must be returned before a For the metadata server that knows a layout must be returned before a
close of the file, this return value can be used to communicate the close of the file, this return value can be used to communicate the
desired behavior to the client and thus remove one extra step from desired behavior to the client and thus remove one extra step from
skipping to change at page 580, line 43 skipping to change at line 27591
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 may 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 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 13 and Table 14, the specification of LAYOUTGET As indicated by Table 22 and Table 23, 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 * If LAYOUTGET is preceded by OPEN in the same COMPOUND request and
the OPEN requests OPEN4_SHARE_ACCESS_READ access, the client might the OPEN requests OPEN4_SHARE_ACCESS_READ access, the client might
opt to request a _READ layout with loga_offset set to zero, opt to request a _READ layout with loga_offset set to zero,
loga_minlength set to zero, and loga_length set to loga_minlength set to zero, and loga_length set to
NFS4_UINT64_MAX. If the file has space allocated to it, that NFS4_UINT64_MAX. If the file has space allocated to it, that
space is striped over one or more storage devices, and there is space is striped over one or more storage devices, and there is
either no conflicting layout or the concept of a conflicting either no conflicting layout or the concept of a conflicting
layout does not apply to the pNFS server's layout type or layout does not apply to the pNFS server's layout type or
implementation, then the metadata server might return a layout implementation, then the metadata server might return a layout
with a starting offset of zero, and a length equal to the length with a starting offset of zero, and a length equal to the length
of the file, if not NFS4_UINT64_MAX. If the length of the file is of the file, if not NFS4_UINT64_MAX. If the length of the file is
not a multiple of the pNFS server's stripe width (see Section 13.2 not a multiple of the pNFS server's stripe width (see Section 13.2
for a formal definition), the metadata server might round up the for a formal definition), the metadata server might round up the
returned layout's length. returned layout's length.
o If LAYOUTGET is preceded by OPEN in the same COMPOUND request, and * If LAYOUTGET is preceded by OPEN in the same COMPOUND request, and
the OPEN requests OPEN4_SHARE_ACCESS_WRITE access and does not the OPEN requests OPEN4_SHARE_ACCESS_WRITE access and does not
truncate the file, the client might opt to request a _RW layout truncate the file, the client might opt to request a _RW layout
with loga_offset set to zero, loga_minlength set to zero, and with loga_offset set to zero, loga_minlength set to zero, and
loga_length set to the file's current length (if known), or loga_length set to the file's current length (if known), or
NFS4_UINT64_MAX. As with the previous case, under some conditions NFS4_UINT64_MAX. As with the previous case, under some conditions
the metadata server might return a layout that covers the entire the metadata server might return a layout that covers the entire
length of the file or beyond. length of the file or beyond.
o This strategy is as above, but the OPEN truncates the file. In * This strategy is as above, but the OPEN truncates the file. In
this case, the client might anticipate it will be writing to the this case, the client might anticipate it will be writing to the
file from offset zero, and so loga_offset and loga_minlength are file from offset zero, and so loga_offset and loga_minlength are
set to zero, and loga_length is set to the value of set to zero, and loga_length is set to the value of
threshold4_write_iosize. The metadata server might return a threshold4_write_iosize. The metadata server might return a
layout from offset zero with a length at least as long as layout from offset zero with a length at least as long as
threshold4_write_iosize. threshold4_write_iosize.
o A process on the client invokes a request to read from offset * A process on the client invokes a request to read from offset
10000 for length 50000. The client is using buffered I/O, and has 10000 for length 50000. The client is using buffered I/O, and has
buffer sizes of 4096 bytes. The client intends to map the request buffer sizes of 4096 bytes. The client intends to map the request
of the process into a series of READ requests starting at offset of the process into a series of READ requests starting at offset
8192. The end offset needs to be higher than 10000 + 50000 = 8192. The end offset needs to be higher than 10000 + 50000 =
60000, and the next offset that is a multiple of 4096 is 61440. 60000, and the next offset that is a multiple of 4096 is 61440.
The difference between 61440 and that starting offset of the The difference between 61440 and that starting offset of the
layout is 53248 (which is the product of 4096 and 15). The value layout is 53248 (which is the product of 4096 and 15). The value
of threshold4_read_iosize is less than 53248, so the client sends of threshold4_read_iosize is less than 53248, so the client sends
a LAYOUTGET request with loga_offset set to 8192, loga_minlength a LAYOUTGET request with loga_offset set to 8192, loga_minlength
set to 53248, and loga_length set to the file's length (if known) set to 53248, and loga_length set to the file's length (if known)
minus 8192 or NFS4_UINT64_MAX (if the file's length is not known). minus 8192 or NFS4_UINT64_MAX (if the file's length is not known).
Since this LAYOUTGET request exceeds the metadata server's Since this LAYOUTGET request exceeds the metadata server's
threshold, it grants the layout, possibly with an initial offset threshold, it grants the layout, possibly with an initial offset
of zero, with an end offset of at least 8192 + 53248 - 1 = 61439, of zero, with an end offset of at least 8192 + 53248 - 1 = 61439,
but preferably a layout with an offset aligned on the stripe width but preferably a layout with an offset aligned on the stripe width
and a length that is a multiple of the stripe width. and a length that is a multiple of the stripe width.
o This strategy is as above, but the client is not using buffered I/ * This strategy is as above, but the client is not using buffered I/
O, and instead all internal I/O requests are sent directly to the O, and instead all internal I/O requests are sent directly to the
server. The LAYOUTGET request has loga_offset equal to 10000 and server. The LAYOUTGET request has loga_offset equal to 10000 and
loga_minlength set to 50000. The value of loga_length is set to loga_minlength set to 50000. The value of loga_length is set to
the length of the file. The metadata server is free to return a the length of the file. The metadata server is free to return a
layout that fully overlaps the requested range, with a starting layout that fully overlaps the requested range, with a starting
offset and length aligned on the stripe width. offset and length aligned on the stripe width.
o Again, a process on the client invokes a request to read from * Again, a process on the client invokes a request to read from
offset 10000 for length 50000 (i.e. a range with a starting offset offset 10000 for length 50000 (i.e. a range with a starting offset
of 10000 and an ending offset of 69999), and buffered I/O is in of 10000 and an ending offset of 69999), and buffered I/O is in
use. The client is expecting that the server might not be able to use. The client is expecting that the server might not be able to
return the layout for the full I/O range. The client intends to return the layout for the full I/O range. The client intends to
map the request of the process into a series of thirteen READ map the request of the process into a series of thirteen READ
requests starting at offset 8192, each with length 4096, with a requests starting at offset 8192, each with length 4096, with a
total length of 53248 (which equals 13 * 4096), which fully total length of 53248 (which equals 13 * 4096), which fully
contains the range that client's process wants to read. Because contains the range that client's process wants to read. Because
the value of threshold4_read_iosize is equal to 4096, it is the value of threshold4_read_iosize is equal to 4096, it is
practical and reasonable for the client to use several LAYOUTGET practical and reasonable for the client to use several LAYOUTGET
operations to complete the series of READs. The client sends a operations to complete the series of READs. The client sends a
LAYOUTGET request with loga_offset set to 8192, loga_minlength set LAYOUTGET request with loga_offset set to 8192, loga_minlength set
to 4096, and loga_length set to 53248 or higher. The server will to 4096, and loga_length set to 53248 or higher. The server will
grant a layout possibly with an initial offset of zero, with an grant a layout possibly with an initial offset of zero, with an
end offset of at least 8192 + 4096 - 1 = 12287, but preferably a end offset of at least 8192 + 4096 - 1 = 12287, but preferably a
layout with an offset aligned on the stripe width and a length layout with an offset aligned on the stripe width and a length
that is a multiple of the stripe width. This will allow the that is a multiple of the stripe width. This will allow the
client to make forward progress, possibly sending more LAYOUTGET client to make forward progress, possibly sending more LAYOUTGET
operations for the remainder of the range. operations for the remainder of the range.
o An NFS client detects a sequential read pattern, and so sends a * An NFS client detects a sequential read pattern, and so sends a
LAYOUTGET operation that goes well beyond any current or pending LAYOUTGET operation that goes well beyond any current or pending
read requests to the server. The server might likewise detect read requests to the server. The server might likewise detect
this pattern, and grant the LAYOUTGET request. Once the client this pattern, and grant the LAYOUTGET request. Once the client
reads from an offset of the file that represents 50% of the way reads from an offset of the file that represents 50% of the way
through the range of the last layout it received, in order to through the range of the last layout it received, in order to
avoid stalling I/O that would wait for a layout, the client sends avoid stalling I/O that would wait for a layout, the client sends
more operations from an offset of the file that represents 50% of more operations from an offset of the file that represents 50% of
the way through the last layout it received. The client continues the way through the last layout it received. The client continues
to request layouts with byte-ranges that are well in advance of to request layouts with byte-ranges that are well in advance of
the byte-ranges of recent and/or read requests of processes the byte-ranges of recent and/or read requests of processes
running on the client. running on the client.
o This strategy is as above, but the client fails to detect the * This strategy is as above, but the client fails to detect the
pattern, but the server does. The next time the metadata server pattern, but the server does. The next time the metadata server
gets a LAYOUTGET, it returns a layout with a length that is well gets a LAYOUTGET, it returns a layout with a length that is well
beyond loga_minlength. beyond loga_minlength.
o A client is using buffered I/O, and has a long queue of write- * A client is using buffered I/O, and has a long queue of write-
behinds to process and also detects a sequential write pattern. behinds to process and also detects a sequential write pattern.
It sends a LAYOUTGET for a layout that spans the range of the It sends a LAYOUTGET for a layout that spans the range of the
queued write-behinds and well beyond, including ranges beyond the queued write-behinds and well beyond, including ranges beyond the
filer's current length. The client continues to send LAYOUTGET filer's current length. The client continues to send LAYOUTGET
operations once the write-behind queue reaches 50% of the maximum operations once the write-behind queue reaches 50% of the maximum
queue length. queue length.
Once the client has obtained a layout referring to a particular Once the client has obtained a layout referring to a particular
device ID, the metadata server MUST NOT delete the device ID until device ID, the metadata server MUST NOT delete the device ID until
the layout is returned or revoked. the layout is returned or revoked.
skipping to change at page 594, line 26 skipping to change at line 28207
SEQ4_STATUS_DEVID_DELETED SEQ4_STATUS_DEVID_DELETED
The client is using device ID notifications and the server has The client is using device ID notifications and the server has
deleted a device ID mapping held by the client. This flag will deleted a device ID mapping held by the client. This flag will
stay in effect until the client sends a GETDEVICEINFO on the stay in effect until the client sends a GETDEVICEINFO on the
device ID with a null value in the argument gdia_notify_types. device ID with a null value in the argument gdia_notify_types.
The value of the sa_sequenceid argument relative to the cached The value of the sa_sequenceid argument relative to the cached
sequence ID on the slot falls into one of three cases. sequence ID on the slot falls into one of three cases.
o If the difference between sa_sequenceid and the server's cached * If the difference between sa_sequenceid and the server's cached
sequence ID at the slot ID is two (2) or more, or if sa_sequenceid sequence ID at the slot ID is two (2) or more, or if sa_sequenceid
is less than the cached sequence ID (accounting for wraparound of is less than the cached sequence ID (accounting for wraparound of
the unsigned sequence ID value), then the server MUST return the unsigned sequence ID value), then the server MUST return
NFS4ERR_SEQ_MISORDERED. NFS4ERR_SEQ_MISORDERED.
o If sa_sequenceid and the cached sequence ID are the same, this is * If sa_sequenceid and the cached sequence ID are the same, this is
a retry, and the server replies with what is recorded in the reply a retry, and the server replies with what is recorded in the reply
cache. The lease is possibly renewed as described below. cache. The lease is possibly renewed as described below.
o If sa_sequenceid is one greater (accounting for wraparound) than * If sa_sequenceid is one greater (accounting for wraparound) than
the cached sequence ID, then this is a new request, and the slot's the cached sequence ID, then this is a new request, and the slot's
sequence ID is incremented. The operations subsequent to sequence ID is incremented. The operations subsequent to
SEQUENCE, if any, are processed. If there are no other SEQUENCE, if any, are processed. If there are no other
operations, the only other effects are to cache the SEQUENCE reply operations, the only other effects are to cache the SEQUENCE reply
in the slot, maintain the session's activity, and possibly renew in the slot, maintain the session's activity, and possibly renew
the lease. the lease.
If the client reuses a slot ID and sequence ID for a completely If the client reuses a slot ID and sequence ID for a completely
different request, the server MAY treat the request as if it is a different request, the server MAY treat the request as if it is a
retry of what it has already executed. The server MAY however detect retry of what it has already executed. The server MAY however detect
skipping to change at page 596, line 31 skipping to change at line 28305
This operation is used to update the SSV for a client ID. Before This operation is used to update the SSV for a client ID. Before
SET_SSV is called the first time on a client ID, the SSV is zero. SET_SSV is called the first time on a client ID, the SSV is zero.
The SSV is the key used for the SSV GSS mechanism (Section 2.10.9) The SSV is the key used for the SSV GSS mechanism (Section 2.10.9)
SET_SSV MUST be preceded by a SEQUENCE operation in the same SET_SSV MUST be preceded by a SEQUENCE operation in the same
COMPOUND. It MUST NOT be used if the client did not opt for SP4_SSV COMPOUND. It MUST NOT be used if the client did not opt for SP4_SSV
state protection when the client ID was created (see Section 18.35); state protection when the client ID was created (see Section 18.35);
the server returns NFS4ERR_INVAL in that case. the server returns NFS4ERR_INVAL in that case.
The field ssa_digest is computed as the output of the HMAC (RFC 2104 The field ssa_digest is computed as the output of the HMAC (RFC 2104
[51]) using the subkey derived from the SSV4_SUBKEY_MIC_I2T and [52]) using the subkey derived from the SSV4_SUBKEY_MIC_I2T and
current SSV as the key (see Section 2.10.9 for a description of current SSV as the key (see Section 2.10.9 for a description of
subkeys), and an XDR encoded value of data type ssa_digest_input4. subkeys), and an XDR encoded value of data type ssa_digest_input4.
The field sdi_seqargs is equal to the arguments of the SEQUENCE The field sdi_seqargs is equal to the arguments of the SEQUENCE
operation for the COMPOUND procedure that SET_SSV is within. operation for the COMPOUND procedure that SET_SSV is within.
The argument ssa_ssv is XORed with the current SSV to produce the new The argument ssa_ssv is XORed with the current SSV to produce the new
SSV. The argument ssa_ssv SHOULD be generated randomly. SSV. The argument ssa_ssv SHOULD be generated randomly.
In the response, ssr_digest is the output of the HMAC using the In the response, ssr_digest is the output of the HMAC using the
subkey derived from SSV4_SUBKEY_MIC_T2I and new SSV as the key, and subkey derived from SSV4_SUBKEY_MIC_T2I and new SSV as the key, and
skipping to change at page 598, line 27 skipping to change at line 28394
18.48.3. DESCRIPTION 18.48.3. DESCRIPTION
The TEST_STATEID operation is used to check the validity of a set of The TEST_STATEID operation is used to check the validity of a set of
stateids. It can be used at any time, but the client should stateids. It can be used at any time, but the client should
definitely use it when it receives an indication that one or more of definitely use it when it receives an indication that one or more of
its stateids have been invalidated due to lock revocation. This its stateids have been invalidated due to lock revocation. This
occurs when the SEQUENCE operation returns with one of the following occurs when the SEQUENCE operation returns with one of the following
sr_status_flags set: sr_status_flags set:
o SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED * SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED
o SEQ4_STATUS_EXPIRED_ADMIN_STATE_REVOKED * SEQ4_STATUS_EXPIRED_ADMIN_STATE_REVOKED
o SEQ4_STATUS_EXPIRED_RECALLABLE_STATE_REVOKED * SEQ4_STATUS_EXPIRED_RECALLABLE_STATE_REVOKED
The client can use TEST_STATEID one or more times to test the The client can use TEST_STATEID one or more times to test the
validity of its stateids. Each use of TEST_STATEID allows a large validity of its stateids. Each use of TEST_STATEID allows a large
set of such stateids to be tested and avoids problems with earlier set of such stateids to be tested and avoids problems with earlier
stateids in a COMPOUND request from interfering with the checking of stateids in a COMPOUND request from interfering with the checking of
subsequent stateids, as would happen if individual stateids were subsequent stateids, as would happen if individual stateids were
tested by a series of corresponding by operations in a COMPOUND tested by a series of corresponding by operations in a COMPOUND
request. request.
For each stateid, the server returns the status code that would be For each stateid, the server returns the status code that would be
returned if that stateid were to be used in normal operation. returned if that stateid were to be used in normal operation.
Returning such a status indication is not an error and does not cause Returning such a status indication is not an error and does not cause
COMPOUND processing to terminate. Checks for the validity of the COMPOUND processing to terminate. Checks for the validity of the
stateid proceed as they would for normal operations with a number of stateid proceed as they would for normal operations with a number of
exceptions: exceptions:
o There is no check for the type of stateid object, as would be the * There is no check for the type of stateid object, as would be the
case for normal use of a stateid. case for normal use of a stateid.
o There is no reference to the current filehandle. * There is no reference to the current filehandle.
o Special stateids are always considered invalid (they result in the * Special stateids are always considered invalid (they result in the
error code NFS4ERR_BAD_STATEID). error code NFS4ERR_BAD_STATEID).
All stateids are interpreted as being associated with the client for All stateids are interpreted as being associated with the client for
the current session. Any possible association with a previous the current session. Any possible association with a previous
instance of the client (as stale stateids) is not considered. instance of the client (as stale stateids) is not considered.
The valid status values in the returned status_code array are The valid status values in the returned status_code array are
NFS4ERR_OK, NFS4ERR_BAD_STATEID, NFS4ERR_OLD_STATEID, NFS4ERR_OK, NFS4ERR_BAD_STATEID, NFS4ERR_OLD_STATEID,
NFS4ERR_EXPIRED, NFS4ERR_ADMIN_REVOKED, and NFS4ERR_DELEG_REVOKED. NFS4ERR_EXPIRED, NFS4ERR_ADMIN_REVOKED, and NFS4ERR_DELEG_REVOKED.
skipping to change at page 601, line 13 skipping to change at line 28491
}; };
18.49.3. DESCRIPTION 18.49.3. DESCRIPTION
Where this description mandates the return of a specific error code Where this description mandates the return of a specific error code
for a specific condition, and where multiple conditions apply, the for a specific condition, and where multiple conditions apply, the
server MAY return any of the mandated error codes. server MAY return any of the mandated error codes.
This operation allows a client to: This operation allows a client to:
o Get a delegation on all types of files except directories. * Get a delegation on all types of files except directories.
o Register a "want" for a delegation for the specified file object, * Register a "want" for a delegation for the specified file object,
and be notified via a callback when the delegation is available. and be notified via a callback when the delegation is available.
The server MAY support notifications of availability via The server MAY support notifications of availability via
callbacks. If the server does not support registration of wants, callbacks. If the server does not support registration of wants,
it MUST NOT return an error to indicate that, and instead MUST it MUST NOT return an error to indicate that, and instead MUST
return with ond_why set to WND4_CONTENTION or WND4_RESOURCE and return with ond_why set to WND4_CONTENTION or WND4_RESOURCE and
ond_server_will_push_deleg or ond_server_will_signal_avail set to ond_server_will_push_deleg or ond_server_will_signal_avail set to
FALSE. When the server indicates that it will notify the client FALSE. When the server indicates that it will notify the client
by means of a callback, it will either provide the delegation by means of a callback, it will either provide the delegation
using a CB_PUSH_DELEG operation or cancel its promise by sending a using a CB_PUSH_DELEG operation or cancel its promise by sending a
CB_WANTS_CANCELLED operation. CB_WANTS_CANCELLED operation.
o Cancel a want for a delegation. * Cancel a want for a delegation.
The client SHOULD NOT set OPEN4_SHARE_ACCESS_READ and SHOULD NOT set The client SHOULD NOT set OPEN4_SHARE_ACCESS_READ and SHOULD NOT set
OPEN4_SHARE_ACCESS_WRITE in wda_want. If it does, the server MUST OPEN4_SHARE_ACCESS_WRITE in wda_want. If it does, the server MUST
ignore them. ignore them.
The meanings of the following flags in wda_want are the same as they The meanings of the following flags in wda_want are the same as they
are in OPEN, except as noted below. are in OPEN, except as noted below.
o OPEN4_SHARE_ACCESS_WANT_READ_DELEG * OPEN4_SHARE_ACCESS_WANT_READ_DELEG
o OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG * OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG
o OPEN4_SHARE_ACCESS_WANT_ANY_DELEG * OPEN4_SHARE_ACCESS_WANT_ANY_DELEG
o OPEN4_SHARE_ACCESS_WANT_NO_DELEG. Unlike the OPEN operation, this * OPEN4_SHARE_ACCESS_WANT_NO_DELEG. Unlike the OPEN operation, this
flag SHOULD NOT be set by the client in the arguments to flag SHOULD NOT be set by the client in the arguments to
WANT_DELEGATION, and MUST be ignored by the server. WANT_DELEGATION, and MUST be ignored by the server.
o OPEN4_SHARE_ACCESS_WANT_CANCEL * OPEN4_SHARE_ACCESS_WANT_CANCEL
o OPEN4_SHARE_ACCESS_WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL * OPEN4_SHARE_ACCESS_WANT_SIGNAL_DELEG_WHEN_RESRC_AVAIL
* OPEN4_SHARE_ACCESS_WANT_PUSH_DELEG_WHEN_UNCONTENDED
o OPEN4_SHARE_ACCESS_WANT_PUSH_DELEG_WHEN_UNCONTENDED
The handling of the above flags in WANT_DELEGATION is the same as in The handling of the above flags in WANT_DELEGATION is the same as in
OPEN. Information about the delegation and/or the promises the OPEN. Information about the delegation and/or the promises the
server is making regarding future callbacks are the same as those server is making regarding future callbacks are the same as those
described in the open_delegation4 structure. described in the open_delegation4 structure.
The successful results of WANT_DELEGATION are of data type The successful results of WANT_DELEGATION are of data type
open_delegation4, which is the same data type as the "delegation" open_delegation4, which is the same data type as the "delegation"
field in the results of the OPEN operation (see Section 18.16.3). field in the results of the OPEN operation (see Section 18.16.3).
The server constructs wdr_resok4 the same way it constructs OPEN's The server constructs wdr_resok4 the same way it constructs OPEN's
"delegation" with one difference: WANT_DELEGATION MUST NOT return a "delegation" with one difference: WANT_DELEGATION MUST NOT return a
skipping to change at page 604, line 9 skipping to change at line 28625
DESTROY_CLIENTID allows a server to immediately reclaim the resources DESTROY_CLIENTID allows a server to immediately reclaim the resources
consumed by an unused client ID, and also to forget that it ever consumed by an unused client ID, and also to forget that it ever
generated the client ID. By forgetting that it ever generated the generated the client ID. By forgetting that it ever generated the
client ID, the server can safely reuse the client ID on a future client ID, the server can safely reuse the client ID on a future
EXCHANGE_ID operation. EXCHANGE_ID operation.
18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims Finished 18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims Finished
18.51.1. ARGUMENT 18.51.1. ARGUMENT
<CODE BEGINS>
struct RECLAIM_COMPLETE4args { struct RECLAIM_COMPLETE4args {
/* /*
* If rca_one_fs TRUE, * If rca_one_fs TRUE,
* *
* CURRENT_FH: object in * CURRENT_FH: object in
* file system reclaim is * file system reclaim is
* complete for. * complete for.
*/ */
bool rca_one_fs; bool rca_one_fs;
}; };
<CODE ENDS>
18.51.2. RESULTS 18.51.2. RESULTS
<CODE BEGINS>
struct RECLAIM_COMPLETE4res { struct RECLAIM_COMPLETE4res {
nfsstat4 rcr_status; nfsstat4 rcr_status;
}; };
<CODE ENDS>
18.51.3. DESCRIPTION 18.51.3. DESCRIPTION
A RECLAIM_COMPLETE operation is used to indicate that the client has A RECLAIM_COMPLETE operation is used to indicate that the client has
reclaimed all of the locking state that it will recover using reclaimed all of the locking state that it will recover using
reclaim, when it is recovering state due to either a server restart reclaim, when it is recovering state due to either a server restart
or the migration of a file system to another server. There are two or the migration of a file system to another server. There are two
types of RECLAIM_COMPLETE operations: types of RECLAIM_COMPLETE operations:
o When rca_one_fs is FALSE, a global RECLAIM_COMPLETE is being done. * When rca_one_fs is FALSE, a global RECLAIM_COMPLETE is being done.
This indicates that recovery of all locks that the client held on This indicates that recovery of all locks that the client held on
the previous server instance has been completed. The current the previous server instance has been completed. The current
filehandle need not be set in this case. filehandle need not be set in this case.
o When rca_one_fs is TRUE, a file system-specific RECLAIM_COMPLETE * When rca_one_fs is TRUE, a file system-specific RECLAIM_COMPLETE
is being done. This indicates that recovery of locks for a single is being done. This indicates that recovery of locks for a single
fs (the one designated by the current filehandle) due to the fs (the one designated by the current filehandle) due to the
migration of the file system has been completed. Presence of a migration of the file system has been completed. Presence of a
current filehandle is required when rca_one_fs is set to TRUE. current filehandle is required when rca_one_fs is set to TRUE.
When the current filehandle designates a filehandle in a file When the current filehandle designates a filehandle in a file
system not in the process of migration, the operation returns system not in the process of migration, the operation returns
NFS4_OK and is otherwise ignored. NFS4_OK and is otherwise ignored.
Once a RECLAIM_COMPLETE is done, there can be no further reclaim Once a RECLAIM_COMPLETE is done, there can be no further reclaim
operations for locks whose scope is defined as having completed operations for locks whose scope is defined as having completed
recovery. Once the client sends RECLAIM_COMPLETE, the server will recovery. Once the client sends RECLAIM_COMPLETE, the server will
not allow the client to do subsequent reclaims of locking state for not allow the client to do subsequent reclaims of locking state for
that scope and, if these are attempted, will return NFS4ERR_NO_GRACE. that scope and, if these are attempted, will return NFS4ERR_NO_GRACE.
skipping to change at page 605, line 47 skipping to change at line 28702
These two may be done in any order as long as all necessary lock These two may be done in any order as long as all necessary lock
reclaims have been done before issuing either of them. reclaims have been done before issuing either of them.
Any locks not reclaimed at the point at which RECLAIM_COMPLETE is Any locks not reclaimed at the point at which RECLAIM_COMPLETE is
done become non-reclaimable. The client MUST NOT attempt to reclaim done become non-reclaimable. The client MUST NOT attempt to reclaim
them, either during the current server instance or in any subsequent them, either during the current server instance or in any subsequent
server instance, or on another server to which responsibility for server instance, or on another server to which responsibility for
that file system is transferred. If the client were to do so, it that file system is transferred. If the client were to do so, it
would be violating the protocol by representing itself as owning would be violating the protocol by representing itself as owning
locks that it does not own, and so has no right to reclaim. See locks that it does not own, and so has no right to reclaim. See
Section 8.4.3 of [65] for a discussion of edge conditions related to Section 8.4.3 of [66] for a discussion of edge conditions related to
lock reclaim. lock reclaim.
By sending a RECLAIM_COMPLETE, the client indicates readiness to By sending a RECLAIM_COMPLETE, the client indicates readiness to
proceed to do normal non-reclaim locking operations. The client proceed to do normal non-reclaim locking operations. The client
should be aware that such operations may temporarily result in should be aware that such operations may temporarily result in
NFS4ERR_GRACE errors until the server is ready to terminate its grace NFS4ERR_GRACE errors until the server is ready to terminate its grace
period. period.
18.51.4. IMPLEMENTATION 18.51.4. IMPLEMENTATION
skipping to change at page 606, line 39 skipping to change at line 28743
When a RECLAIM_COMPLETE is sent, the client effectively acknowledges When a RECLAIM_COMPLETE is sent, the client effectively acknowledges
any locks not yet reclaimed as lost. This allows the server to re- any locks not yet reclaimed as lost. This allows the server to re-
enable the client to recover locks if the occurrence of edge enable the client to recover locks if the occurrence of edge
conditions, as described in Section 8.4.3, had caused the server to conditions, as described in Section 8.4.3, had caused the server to
disable the client's ability to recover locks. disable the client's ability to recover locks.
Because previous descriptions of RECLAIM_COMPLETE were not Because previous descriptions of RECLAIM_COMPLETE were not
sufficiently explicit about the circumstances in which use of sufficiently explicit about the circumstances in which use of
RECLAIM_COMPLETE with rca_one_fs set to TRUE was appropriate, there RECLAIM_COMPLETE with rca_one_fs set to TRUE was appropriate, there
have been cases which it has been misused by clients who have issued have been cases in which it has been misused by clients who have
RECLAIM_COMPLETE with rca_one_fs set to TRUE when it should have not issued RECLAIM_COMPLETE with rca_one_fs set to TRUE when it should
been. There have also been cases in which servers have, in various have not been. There have also been cases in which servers have, in
ways, not responded to such misuse as described above, either various ways, not responded to such misuse as described above, either
ignoring the rca_one_fs setting (treating the operation as a global ignoring the rca_one_fs setting (treating the operation as a global
RECLAIM_COMPLETE) or ignoring the entire operation. RECLAIM_COMPLETE) or ignoring the entire operation.
While clients SHOULD NOT misuse this feature and servers SHOULD While clients SHOULD NOT misuse this feature, and servers SHOULD
respond to such misuse as described above, implementers need to be respond to such misuse as described above, implementors need to be
aware of the following considerations as they make necessary aware of the following considerations as they make necessary trade-
tradeoffs between interoperability with existing implementations and offs between interoperability with existing implementations and
proper support for facilities to allow lock recovery in the event of proper support for facilities to allow lock recovery in the event of
file system migration. file system migration.
o When servers have no support for becoming the destination server * When servers have no support for becoming the destination server
of a file system subject to migration, there is no possibility of of a file system subject to migration, there is no possibility of
a per-fs RECLAIM_COMPLETE being done legitimately and occurrences a per-fs RECLAIM_COMPLETE being done legitimately, and occurrences
of it SHOULD be ignored. However, the negative consequences of of it SHOULD be ignored. However, the negative consequences of
accepting such mistaken use are quite limited as long as the accepting such mistaken use are quite limited as long as the
client does not issue it before all necessary reclaims are done. client does not issue it before all necessary reclaims are done.
o When a server might become the destination for a file system being * When a server might become the destination for a file system being
migrated, inappropriate use of per-fs RECLAIM_COMPLETE is more migrated, inappropriate use of per-fs RECLAIM_COMPLETE is more
concerning. In the case in which the file system designated is concerning. In the case in which the file system designated is
not within a per-fs grace period, the per-fs RECLAIM_COMPLETE not within a per-fs grace period, the per-fs RECLAIM_COMPLETE
SHOULD be ignored, with the negative consequences of accepting it SHOULD be ignored, with the negative consequences of accepting it
being limited, as in the case in which migration is not supported. being limited, as in the case in which migration is not supported.
However, if the server encounters a file system undergoing However, if the server encounters a file system undergoing
migration, the operation cannot be accepted as if it were a global migration, the operation cannot be accepted as if it were a global
RECLAIM_COMPLETE without invalidating its intended use. RECLAIM_COMPLETE without invalidating its intended use.
18.52. Operation 10044: ILLEGAL - Illegal Operation 18.52. Operation 10044: ILLEGAL - Illegal Operation
skipping to change at page 612, line 46 skipping to change at line 28985
into a single RPC request. The client interprets each of the into a single RPC request. The client interprets each of the
operations in turn. If an operation is executed by the client and operations in turn. If an operation is executed by the client and
the status of that operation is NFS4_OK, then the next operation in the status of that operation is NFS4_OK, then the next operation in
the CB_COMPOUND procedure is executed. The client continues this the CB_COMPOUND procedure is executed. The client continues this
process until there are no more operations to be executed or one of process until there are no more operations to be executed or one of
the operations has a status value other than NFS4_OK. the operations has a status value other than NFS4_OK.
19.2.5. ERRORS 19.2.5. ERRORS
CB_COMPOUND will of course return every error that each operation on CB_COMPOUND will of course return every error that each operation on
the backchannel can return (see Table 7). However, if CB_COMPOUND the backchannel can return (see Table 13). However, if CB_COMPOUND
returns zero operations, obviously the error returned by COMPOUND has returns zero operations, obviously the error returned by COMPOUND has
nothing to do with an error returned by an operation. The list of nothing to do with an error returned by an operation. The list of
errors CB_COMPOUND will return if it processes zero operations errors CB_COMPOUND will return if it processes zero operations
includes: includes:
CB_COMPOUND error returns +==============================+==================================+
| Error | Notes |
+------------------------------+------------------------------------+ +==============================+==================================+
| Error | Notes | | NFS4ERR_BADCHAR | The tag argument has a character |
+------------------------------+------------------------------------+ | | the replier does not support. |
| NFS4ERR_BADCHAR | The tag argument has a character | +------------------------------+----------------------------------+
| | the replier does not support. | | NFS4ERR_BADXDR | |
| NFS4ERR_BADXDR | | +------------------------------+----------------------------------+
| NFS4ERR_DELAY | | | NFS4ERR_DELAY | |
| NFS4ERR_INVAL | The tag argument is not in UTF-8 | +------------------------------+----------------------------------+
| | encoding. | | NFS4ERR_INVAL | The tag argument is not in UTF-8 |
| NFS4ERR_MINOR_VERS_MISMATCH | | | | encoding. |
| NFS4ERR_SERVERFAULT | | +------------------------------+----------------------------------+
| NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_MINOR_VERS_MISMATCH | |
| NFS4ERR_REP_TOO_BIG | | +------------------------------+----------------------------------+
| NFS4ERR_REP_TOO_BIG_TO_CACHE | | | NFS4ERR_SERVERFAULT | |
| NFS4ERR_REQ_TOO_BIG | | +------------------------------+----------------------------------+
+------------------------------+------------------------------------+ | NFS4ERR_TOO_MANY_OPS | |
+------------------------------+----------------------------------+
| NFS4ERR_REP_TOO_BIG | |
+------------------------------+----------------------------------+
| NFS4ERR_REP_TOO_BIG_TO_CACHE | |
+------------------------------+----------------------------------+
| NFS4ERR_REQ_TOO_BIG | |
+------------------------------+----------------------------------+
Table 15 Table 24: CB_COMPOUND Error Returns
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 624, line 47 skipping to change at line 29558
these are to be used. There are ranges reserved for object-based these are to be used. There are ranges reserved for object-based
storage protocols and for other experimental storage protocols. An storage protocols and for other experimental storage protocols. An
RFC defining such a storage protocol needs to specify how particular RFC defining such a storage protocol needs to specify how particular
bits within its range are to be used. For example, it may specify a bits within its range are to be used. For example, it may specify a
mapping between attributes of the layout (read vs. write, size of mapping between attributes of the layout (read vs. write, size of
area) and the bit to be used, or it may define a field in the layout area) and the bit to be used, or it may define a field in the layout
where the associated bit position is made available by the server to where the associated bit position is made available by the server to
the client. the client.
RCA4_TYPE_MASK_RDATA_DLG RCA4_TYPE_MASK_RDATA_DLG
The client is to return OPEN_DELEGATE_READ delegations on non- The client is to return OPEN_DELEGATE_READ delegations on non-
directory file objects. directory file objects.
RCA4_TYPE_MASK_WDATA_DLG RCA4_TYPE_MASK_WDATA_DLG
The client is to return OPEN_DELEGATE_WRITE delegations on regular The client is to return OPEN_DELEGATE_WRITE delegations on regular
file objects. file objects.
RCA4_TYPE_MASK_DIR_DLG RCA4_TYPE_MASK_DIR_DLG
The client is to return directory delegations. The client is to return directory delegations.
RCA4_TYPE_MASK_FILE_LAYOUT RCA4_TYPE_MASK_FILE_LAYOUT
The client is to return layouts of type LAYOUT4_NFSV4_1_FILES. The client is to return layouts of type LAYOUT4_NFSV4_1_FILES.
RCA4_TYPE_MASK_BLK_LAYOUT RCA4_TYPE_MASK_BLK_LAYOUT
See [48] for a description.
See [47] for a description.
RCA4_TYPE_MASK_OBJ_LAYOUT_MIN to RCA4_TYPE_MASK_OBJ_LAYOUT_MAX RCA4_TYPE_MASK_OBJ_LAYOUT_MIN to RCA4_TYPE_MASK_OBJ_LAYOUT_MAX
See [47] for a description.
See [46] for a description.
RCA4_TYPE_MASK_OTHER_LAYOUT_MIN to RCA4_TYPE_MASK_OTHER_LAYOUT_MAX RCA4_TYPE_MASK_OTHER_LAYOUT_MIN to RCA4_TYPE_MASK_OTHER_LAYOUT_MAX
This range is reserved for telling the client to recall layouts of This range is reserved for telling the client to recall layouts of
experimental or site-specific layout types (see Section 3.3.13). experimental or site-specific layout types (see Section 3.3.13).
When a bit is set in the type mask that corresponds to an undefined When a bit is set in the type mask that corresponds to an undefined
type of recallable object, NFS4ERR_INVAL MUST be returned. When a type of recallable object, NFS4ERR_INVAL MUST be returned. When a
bit is set that corresponds to a defined type of object but the bit is set that corresponds to a defined type of object but the
client does not support an object of the type, NFS4ERR_INVAL MUST NOT client does not support an object of the type, NFS4ERR_INVAL MUST NOT
be returned. Future minor versions of NFSv4 may expand the set of be returned. Future minor versions of NFSv4 may expand the set of
valid type mask bits. valid type mask bits.
skipping to change at page 630, line 25 skipping to change at line 29794
identified by session ID, slot ID, and sequence ID. These are identified by session ID, slot ID, and sequence ID. These are
requests that the client previously sent to the server. These requests that the client previously sent to the server. These
previous requests created state that some operation(s) in the same previous requests created state that some operation(s) in the same
CB_COMPOUND as the csa_referring_call_lists are identifying. A CB_COMPOUND as the csa_referring_call_lists are identifying. A
session ID is included because leased state is tied to a client ID, session ID is included because leased state is tied to a client ID,
and a client ID can have multiple sessions. See Section 2.10.6.3. and a client ID can have multiple sessions. See Section 2.10.6.3.
The value of the csa_sequenceid argument relative to the cached The value of the csa_sequenceid argument relative to the cached
sequence ID on the slot falls into one of three cases. sequence ID on the slot falls into one of three cases.
o If the difference between csa_sequenceid and the client's cached * If the difference between csa_sequenceid and the client's cached
sequence ID at the slot ID is two (2) or more, or if sequence ID at the slot ID is two (2) or more, or if
csa_sequenceid is less than the cached sequence ID (accounting for csa_sequenceid is less than the cached sequence ID (accounting for
wraparound of the unsigned sequence ID value), then the client wraparound of the unsigned sequence ID value), then the client
MUST return NFS4ERR_SEQ_MISORDERED. MUST return NFS4ERR_SEQ_MISORDERED.
o If csa_sequenceid and the cached sequence ID are the same, this is * If csa_sequenceid and the cached sequence ID are the same, this is
a retry, and the client returns the CB_COMPOUND request's cached a retry, and the client returns the CB_COMPOUND request's cached
reply. reply.
o If csa_sequenceid is one greater (accounting for wraparound) than * If csa_sequenceid is one greater (accounting for wraparound) than
the cached sequence ID, then this is a new request, and the slot's the cached sequence ID, then this is a new request, and the slot's
sequence ID is incremented. The operations subsequent to sequence ID is incremented. The operations subsequent to
CB_SEQUENCE, if any, are processed. If there are no other CB_SEQUENCE, if any, are processed. If there are no other
operations, the only other effects are to cache the CB_SEQUENCE operations, the only other effects are to cache the CB_SEQUENCE
reply in the slot, maintain the session's activity, and when the reply in the slot, maintain the session's activity, and when the
server receives the CB_SEQUENCE reply, renew the lease of state server receives the CB_SEQUENCE reply, renew the lease of state
related to the client ID. related to the client ID.
If the server reuses a slot ID and sequence ID for a completely If the server reuses a slot ID and sequence ID for a completely
different request, the client MAY treat the request as if it is a different request, the client MAY treat the request as if it is a
skipping to change at page 637, line 27 skipping to change at line 30098
and/or reduction of CPU utilization, users of NFSv4.1 implementations and/or reduction of CPU utilization, users of NFSv4.1 implementations
might decline to use security mechanisms that enable integrity might decline to use security mechanisms that enable integrity
protection on each remote procedure call and response. The use of protection on each remote procedure call and response. The use of
mechanisms without integrity leaves the user vulnerable to a man-in- mechanisms without integrity leaves the user vulnerable to a man-in-
the-middle of the NFS client and server that modifies the RPC request the-middle of the NFS client and server that modifies the RPC request
and/or the response. While implementations are free to provide the and/or the response. While implementations are free to provide the
option to use weaker security mechanisms, there are three operations option to use weaker security mechanisms, there are three operations
in particular that warrant the implementation overriding user in particular that warrant the implementation overriding user
choices. choices.
o The first two such operations are SECINFO and SECINFO_NO_NAME. It * The first two such operations are SECINFO and SECINFO_NO_NAME. It
is RECOMMENDED that the client send both operations such that they is RECOMMENDED that the client send both operations such that they
are protected with a security flavor that has integrity are protected with a security flavor that has integrity
protection, such as RPCSEC_GSS with either the protection, such as RPCSEC_GSS with either the
rpc_gss_svc_integrity or rpc_gss_svc_privacy service. Without rpc_gss_svc_integrity or rpc_gss_svc_privacy service. Without
integrity protection encapsulating SECINFO and SECINFO_NO_NAME and integrity protection encapsulating SECINFO and SECINFO_NO_NAME and
their results, a man-in-the-middle could modify results such that their results, a man-in-the-middle could modify results such that
the client might select a weaker algorithm in the set allowed by the client might select a weaker algorithm in the set allowed by
the server, making the client and/or server vulnerable to further the server, making the client and/or server vulnerable to further
attacks. attacks.
o The third operation that SHOULD use integrity protection is any * The third operation that SHOULD use integrity protection is any
GETATTR for the fs_locations and fs_locations_info attributes, in GETATTR for the fs_locations and fs_locations_info attributes, in
order to mitigate the severity of a man-in-the-middle attack. The order to mitigate the severity of a man-in-the-middle attack. The
attack has two steps. First the attacker modifies the unprotected attack has two steps. First the attacker modifies the unprotected
results of some operation to return NFS4ERR_MOVED. Second, when results of some operation to return NFS4ERR_MOVED. Second, when
the client follows up with a GETATTR for the fs_locations or the client follows up with a GETATTR for the fs_locations or
fs_locations_info attributes, the attacker modifies the results to fs_locations_info attributes, the attacker modifies the results to
cause the client to migrate its traffic to a server controlled by cause the client to migrate its traffic to a server controlled by
the attacker. With integrity protection, this attack is the attacker. With integrity protection, this attack is
mitigated. mitigated.
Relative to previous NFS versions, NFSv4.1 has additional security Relative to previous NFS versions, NFSv4.1 has additional security
considerations for pNFS (see Sections 12.9 and 13.12), locking and considerations for pNFS (see Sections 12.9 and 13.12), locking and
session state (see Section 2.10.8.3), and state recovery during grace session state (see Section 2.10.8.3), and state recovery during grace
period (see Section 8.4.2.1.1). With respect to locking and session period (see Section 8.4.2.1.1). With respect to locking and session
state, if SP4_SSV state protection is being used, Section 2.10.10 has state, if SP4_SSV state protection is being used, Section 2.10.10 has
specific security considerations for the NFSv4.1 client and server. specific security considerations for the NFSv4.1 client and server.
Security considerations for lock reclaim differ between the two Security considerations for lock reclaim differ between the two
different situations in which state reclaim is to be done. The different situations in which state reclaim is to be done. The
server failure situation is discussed in Section 8.4.2.1.1 while the server failure situation is discussed in Section 8.4.2.1.1, while the
per-fs state reclaim done in support of migration/replication is per-fs state reclaim done in support of migration/replication is
discussed in Section 11.11.9.1. discussed in Section 11.11.9.1.
The use of the multi-server namespace features described in The use of the multi-server namespace features described in
Section 11 raises the possibility that requests to determine the set Section 11 raises the possibility that requests to determine the set
of network addresses corresponding to a given server might be of network addresses corresponding to a given server might be
interfered with or have their responses modified in flight. In light interfered with or have their responses modified in flight. In light
of this possibility, the following considerations should be taken of this possibility, the following considerations should be noted:
note of:
o When DNS is used to convert server names to addresses and DNSSEC * When DNS is used to convert server names to addresses and DNSSEC
[29] is not available, the validity of the network addresses [29] is not available, the validity of the network addresses
returned generally cannot be relied upon. However, when combined returned generally cannot be relied upon. However, when combined
with a trusted resolver, DNS over TLS [30], and DNS over HTTPS with a trusted resolver, DNS over TLS [30] and DNS over HTTPS [34]
[34] can also be relied upon to provide valid address resolutions. can be relied upon to provide valid address resolutions.
In situations in which the validity of the provided addresses In situations in which the validity of the provided addresses
cannot be relied upon and the client uses RPCSEC_GSS to access the cannot be relied upon and the client uses RPCSEC_GSS to access the
designated server, it is possible for mutual authentication to designated server, it is possible for mutual authentication to
discover invalid server addresses as long as the RPCSEC_GSS discover invalid server addresses as long as the RPCSEC_GSS
implementation used does not use insecure DNS queries to implementation used does not use insecure DNS queries to
canonicalize the hostname components of the service principal canonicalize the hostname components of the service principal
names, as explained in [28]. names, as explained in [28].
o The fetching of attributes containing file system location * The fetching of attributes containing file system location
information SHOULD be performed using integrity protection. It is information SHOULD be performed using integrity protection. It is
important to note here that a client making a request of this sort important to note here that a client making a request of this sort
without using integrity protection needs be aware of the negative without using integrity protection needs be aware of the negative
consequences of doing so, which can lead to invalid host names or consequences of doing so, which can lead to invalid hostnames or
network addresses being returned. These include cases in which network addresses being returned. These include cases in which
the client is directed to a server under the control of an the client is directed to a server under the control of an
attacker, who might get access to data written or provide attacker, who might get access to data written or provide
incorrect values for data read. In light of this, the client incorrect values for data read. In light of this, the client
needs to recognize that using such returned location information needs to recognize that using such returned location information
to access an NFSv4 server without use of RPCSEC_GSS (i.e. by to access an NFSv4 server without use of RPCSEC_GSS (i.e., by
using AUTH_SYS) poses dangers as it can result in the client using AUTH_SYS) poses dangers as it can result in the client
interacting with such an attacker-controlled server, without any interacting with such an attacker-controlled server without any
authentication facilities to verify the server's identity. authentication facilities to verify the server's identity.
o Despite the fact that it is a requirement that implementations * Despite the fact that it is a requirement that implementations
provide "support" for use of RPCSEC_GSS, it cannot be assumed that provide "support" for use of RPCSEC_GSS, it cannot be assumed that
use of RPCSEC_GSS is always available between any particular use of RPCSEC_GSS is always available between any particular
client-server pair. client-server pair.
o When a client has the network addresses of a server but not the * When a client has the network addresses of a server but not the
associated host names, that would interfere with its ability to associated hostnames, that would interfere with its ability to use
use RPCSEC_GSS. RPCSEC_GSS.
In light of the above, a server SHOULD present file system location In light of the above, a server SHOULD present file system location
entries that correspond to file systems on other servers using a host entries that correspond to file systems on other servers using a
name. This would allow the client to interrogate the fs_locations on hostname. This would allow the client to interrogate the
the destination server to obtain trunking information (as well as fs_locations on the destination server to obtain trunking information
replica information) using integrity protection, validating the name (as well as replica information) using integrity protection,
provided while assuring that the response has not been modified in validating the name provided while assuring that the response has not
flight. been modified in flight.
When RPCSEC_GSS is not available on a server, the client needs to be When RPCSEC_GSS is not available on a server, the client needs to be
aware of the fact that the location entries are subject to aware of the fact that the location entries are subject to
modification in flight and so cannot be relied upon. In the case of modification in flight and so cannot be relied upon. In the case of
a client being directed to another server after NFS4ERR_MOVED, this a client being directed to another server after NFS4ERR_MOVED, this
could vitiate the authentication provided by the use of RPCSEC_GSS on could vitiate the authentication provided by the use of RPCSEC_GSS on
the designated destination server. Even when RPCSEC_GSS the designated destination server. Even when RPCSEC_GSS
authentication is available on the destination, the server might authentication is available on the destination, the server might
still properly authenticate as the server to which the client was still properly authenticate as the server to which the client was
erroneously directed. Without a way to decide whether the server is erroneously directed. Without a way to decide whether the server is
skipping to change at page 639, line 44 skipping to change at line 30210
When a file system location attribute is fetched upon connecting with When a file system location attribute is fetched upon connecting with
an NFS server, it SHOULD, as stated above, be done with integrity an NFS server, it SHOULD, as stated above, be done with integrity
protection. When this not possible, it is generally best for the protection. When this not possible, it is generally best for the
client to ignore trunking and replica information or simply not fetch client to ignore trunking and replica information or simply not fetch
the location information for these purposes. the location information for these purposes.
When location information cannot be verified, it can be subjected to When location information cannot be verified, it can be subjected to
additional filtering to prevent the client from being inappropriately additional filtering to prevent the client from being inappropriately
directed. For example, if a range of network addresses can be directed. For example, if a range of network addresses can be
determined that assure that the servers and clients using AUTH_SYS determined that assure that the servers and clients using AUTH_SYS
are subject to the appropriate set of constraints (e.g. physical are subject to the appropriate set of constraints (e.g., physical
network isolation, administrative controls on the operating systems network isolation, administrative controls on the operating systems
used), then network addresses in the appropriate range can be used used), then network addresses in the appropriate range can be used
with others discarded or restricted in their use of AUTH_SYS. with others discarded or restricted in their use of AUTH_SYS.
To summarize considerations regarding the use of RPCSEC_GSS in To summarize considerations regarding the use of RPCSEC_GSS in
fetching location information, we need to consider the following fetching location information, we need to consider the following
possibilities for requests to interrogate location information, with possibilities for requests to interrogate location information, with
interrogation approaches on the referring and destination servers interrogation approaches on the referring and destination servers
arrived at separately: arrived at separately:
o The use of integrity protection is RECOMMENDED in all cases, since * The use of integrity protection is RECOMMENDED in all cases, since
the absence of integrity protection exposes the client to the the absence of integrity protection exposes the client to the
possibility of the results being modified in transit. possibility of the results being modified in transit.
o The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS * The use of requests issued without RPCSEC_GSS (i.e., using
which has no provision to avoid modification of data in flight), AUTH_SYS, which has no provision to avoid modification of data in
while undesirable and a potential security exposure, may not be flight), while undesirable and a potential security exposure, may
avoidable in all cases. Where the use of the returned information not be avoidable in all cases. Where the use of the returned
cannot be avoided, it is made subject to filtering as described information cannot be avoided, it is made subject to filtering as
above to eliminate the possibility that the client would treat an described above to eliminate the possibility that the client would
invalid address as if it were a NFSv4 server. The specifics will treat an invalid address as if it were a NFSv4 server. The
vary depending on the degree of network isolation and whether the specifics will vary depending on the degree of network isolation
request is to the referring or destination servers. and whether the request is to the referring or destination
servers.
Even if such requests are not interfered with in flight, it is Even if such requests are not interfered with in flight, it is
possible for a compromised server to direct the client to use possible for a compromised server to direct the client to use
inappropriate servers, such as those under the control of the inappropriate servers, such as those under the control of the
attacker. It is not clear that being directed to such servers attacker. It is not clear that being directed to such servers
represents a greater threat to the client than the damage that could represents a greater threat to the client than the damage that could
be done by the compromised server itself. However, it is possible be done by the compromised server itself. However, it is possible
that some sorts of transient server compromises might be taken that some sorts of transient server compromises might be exploited to
advantage of to direct a client to a server capable of doing greater direct a client to a server capable of doing greater damage over a
damage over a longer time. One useful step to guard against this longer time. One useful step to guard against this possibility is to
possibility is to issue requests to fetch location data using issue requests to fetch location data using RPCSEC_GSS, even if no
RPCSEC_GSS, even if no mapping to an RPCSEC_GSS principal is mapping to an RPCSEC_GSS principal is available. In this case,
available. In this case, RPCSEC_GSS would not be used, as it RPCSEC_GSS would not be used, as it typically is, to identify the
typically is, to identify the client principal to the server, but client principal to the server, but rather to make sure (via
rather to make sure (via RPCSEC_GSS mutual authentication) that the RPCSEC_GSS mutual authentication) that the server being contacted is
server being contacted is the one intended. the one intended.
Similar considerations apply if the threat to be avoided is the Similar considerations apply if the threat to be avoided is the
redirection of client traffic to inappropriate (i.e. poorly redirection of client traffic to inappropriate (i.e., poorly
performing) servers. In both cases, there is no reason for the performing) servers. In both cases, there is no reason for the
information returned to depend on the identity of the client information returned to depend on the identity of the client
principal requesting it, while the validity of the server principal requesting it, while the validity of the server
information, which has the capability to affect all client information, which has the capability to affect all client
principals, is of considerable importance. principals, is of considerable importance.
22. IANA Considerations 22. IANA Considerations
This section uses terms that are defined in [62]. This section uses terms that are defined in [63].
22.1. IANA Actions Needed 22.1. IANA Actions
This update does not require any modification of or additions to This update does not require any modification of, or additions to,
registry entries or registry rules associated with NFSv4.1. However, registry entries or registry rules associated with NFSv4.1. However,
since this document is intended to obsolete RFC5661, it will be since this document obsoletes RFC 5661, IANA has updated all registry
necessary for IANA to update all registry entries and registry rules entries and registry rules references that point to RFC 5661 to point
references that points to RFC5661 to point to this document instead. to this document instead.
Previous actions by IANA related to NFSv4.1 are listed in the Previous actions by IANA related to NFSv4.1 are listed in the
remaining subsections of Section 22. remaining subsections of Section 22.
22.2. Named Attribute Definitions 22.2. Named Attribute Definitions
IANA created a registry called the "NFSv4 Named Attribute Definitions IANA created a registry called the "NFSv4 Named Attribute Definitions
Registry". Registry".
The NFSv4.1 protocol supports the association of a file with zero or The NFSv4.1 protocol supports the association of a file with zero or
skipping to change at page 641, line 37 skipping to change at line 30296
attributes as needed, they are encouraged to register the attributes attributes as needed, they are encouraged to register the attributes
with IANA. with IANA.
Such registered named attributes are presumed to apply to all minor Such registered named attributes are presumed to apply to all minor
versions of NFSv4, including those defined subsequently to the versions of NFSv4, including those defined subsequently to the
registration. If the named attribute is intended to be limited to registration. If the named attribute is intended to be limited to
specific minor versions, this will be clearly stated in the specific minor versions, this will be clearly stated in the
registry's assignment. registry's assignment.
All assignments to the registry are made on a First Come First Served All assignments to the registry are made on a First Come First Served
basis, per Section 4.1 of [62]. The policy for each assignment is basis, per Section 4.4 of [63]. The policy for each assignment is
Specification Required, per Section 4.1 of [62]. Specification Required, per Section 4.6 of [63].
Under the NFSv4.1 specification, the name of a named attribute can in Under the NFSv4.1 specification, the name of a named attribute can in
theory be up to 2^32 - 1 bytes in length, but in practice NFSv4.1 theory be up to 2^(32) - 1 bytes in length, but in practice NFSv4.1
clients and servers will be unable to handle a string that long. clients and servers will be unable to handle a string that long.
IANA should reject any assignment request with a named attribute that IANA should reject any assignment request with a named attribute that
exceeds 128 UTF-8 characters. To give the IESG the flexibility to exceeds 128 UTF-8 characters. To give the IESG the flexibility to
set up bases of assignment of Experimental Use and Standards Action, set up bases of assignment of Experimental Use and Standards Action,
the prefixes of "EXPE" and "STDS" are Reserved. The named attribute the prefixes of "EXPE" and "STDS" are Reserved. The named attribute
with a zero-length name is Reserved. with a zero-length name is Reserved.
The prefix "PRIV" is designated for Private Use. A site that wants The prefix "PRIV" is designated for Private Use. A site that wants
to make use of unregistered named attributes without risk of to make use of unregistered named attributes without risk of
conflicting with an assignment in IANA's registry should use the conflicting with an assignment in IANA's registry should use the
skipping to change at page 642, line 48 skipping to change at line 30356
The potential exists for new notification types to be added to the The potential exists for new notification types to be added to the
CB_NOTIFY_DEVICEID operation (see Section 20.12). This can be done CB_NOTIFY_DEVICEID operation (see Section 20.12). This can be done
via changes to the operations that register notifications, or by via changes to the operations that register notifications, or by
adding new operations to NFSv4. This requires a new minor version of adding new operations to NFSv4. This requires a new minor version of
NFSv4, and requires a Standards Track document from the IETF. NFSv4, and requires a Standards Track document from the IETF.
Another way to add a notification is to specify a new layout type Another way to add a notification is to specify a new layout type
(see Section 22.5). (see Section 22.5).
Hence, all assignments to the registry are made on a Standards Action Hence, all assignments to the registry are made on a Standards Action
basis per Section 4.1 of [62], with Expert Review required. basis per Section 4.6 of [63], with Expert Review required.
The registry is a list of assignments, each containing five fields The registry is a list of assignments, each containing five fields
per assignment. per assignment.
1. The name of the notification type. This name must have the 1. The name of the notification type. This name must have the
prefix "NOTIFY_DEVICEID4_". This name must be unique. prefix "NOTIFY_DEVICEID4_". This name must be unique.
2. The value of the notification. IANA will assign this number, and 2. The value of the notification. IANA will assign this number, and
the request from the registrant will use TBD1 instead of an the request from the registrant will use TBD1 instead of an
actual value. IANA MUST use a whole number that can be no higher actual value. IANA MUST use a whole number that can be no higher
than 2^32-1, and should be the next available value. The value than 2^(32)-1, and should be the next available value. The value
assigned must be unique. A Designated Expert must be used to assigned must be unique. A Designated Expert must be used to
ensure that when the name of the notification type and its value ensure that when the name of the notification type and its value
are added to the NFSv4.1 notify_deviceid_type4 enumerated data are added to the NFSv4.1 notify_deviceid_type4 enumerated data
type in the NFSv4.1 XDR description ([10]), the result continues type in the NFSv4.1 XDR description [10], the result continues to
to be a valid XDR description. be a valid XDR description.
3. The Standards Track RFC(s) that describe the notification. If 3. The Standards Track RFC(s) that describe the notification. If
the RFC(s) have not yet been published, the registrant will use the RFC(s) have not yet been published, the registrant will use
RFCTBD2, RFCTBD3, etc. instead of an actual RFC number. RFCTBD2, RFCTBD3, etc. instead of an actual RFC number.
4. How the RFC introduces the notification. This is indicated by a 4. How the RFC introduces the notification. This is indicated by a
single US-ASCII value. If the value is N, it means a minor single US-ASCII value. If the value is N, it means a minor
revision to the NFSv4 protocol. If the value is L, it means a revision to the NFSv4 protocol. If the value is L, it means a
new pNFS layout type. Other values can be used with IESG new pNFS layout type. Other values can be used with IESG
Approval. Approval.
5. The minor versions of NFSv4 that are allowed to use the 5. The minor versions of NFSv4 that are allowed to 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 a new IESG Approval assigns these numbers. Each time there is a 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.3.1. Initial Registry 22.3.1. Initial Registry
The initial registry is in Table 16. Note that the next available The initial registry is in Table 25. Note that the next available
value is zero. value is zero.
+-------------------------+-------+---------+-----+----------------+ +=========================+=======+==========+=====+================+
| Notification Name | Value | RFC | How | Minor Versions | | Notification Name | Value | RFC | How | Minor Versions |
+-------------------------+-------+---------+-----+----------------+ +=========================+=======+==========+=====+================+
| NOTIFY_DEVICEID4_CHANGE | 1 | RFC5661 | N | 1 | | NOTIFY_DEVICEID4_CHANGE | 1 | RFC | N | 1 |
| NOTIFY_DEVICEID4_DELETE | 2 | RFC5661 | N | 1 | | | | 8881 | | |
+-------------------------+-------+---------+-----+----------------+ +-------------------------+-------+----------+-----+----------------+
| NOTIFY_DEVICEID4_DELETE | 2 | RFC | N | 1 |
| | | 8881 | | |
+-------------------------+-------+----------+-----+----------------+
Table 16: Initial Device ID Notification Assignments Table 25: Initial Device ID Notification 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. Object Recall Types 22.4. Object Recall Types
IANA created a registry called the "NFSv4 Recallable Object Types IANA created a registry called the "NFSv4 Recallable Object Types
Registry". Registry".
The potential exists for new object types to be added to the The potential exists for new object types to be added to the
CB_RECALL_ANY operation (see Section 20.6). This can be done via CB_RECALL_ANY operation (see Section 20.6). This can be done via
changes to the operations that add recallable types, or by adding new changes to the operations that add recallable types, or by adding new
operations to NFSv4. This requires a new minor version of NFSv4, and operations to NFSv4. This requires a new minor version of NFSv4, and
requires a Standards Track document from IETF. Another way to add a requires a Standards Track document from IETF. Another way to add a
new recallable object is to specify a new layout type (see new recallable object is to specify a new layout type (see
Section 22.5). Section 22.5).
All assignments to the registry are made on a Standards Action basis All assignments to the registry are made on a Standards Action basis
per Section 4.1 of [62], with Expert Review required. per Section 4.9 of [63], with Expert Review required.
Recallable object types are 32-bit unsigned numbers. There are no Recallable object types are 32-bit unsigned numbers. There are no
Reserved values. Values in the range 12 through 15, inclusive, are Reserved values. Values in the range 12 through 15, inclusive, are
designated for Private Use. designated for Private Use.
The registry is a list of assignments, each containing five fields The registry is a list of assignments, each containing five fields
per assignment. per assignment.
1. The name of the recallable object type. This name must have the 1. The name of the recallable object type. This name must have the
prefix "RCA4_TYPE_MASK_". The name must be unique. prefix "RCA4_TYPE_MASK_". The name must be unique.
2. The value of the recallable object type. IANA will assign this 2. The value of the recallable object type. IANA will assign this
number, and the request from the registrant will use TBD1 instead number, and the request from the registrant will use TBD1 instead
of an actual value. IANA MUST use a whole number that can be no of an actual value. IANA MUST use a whole number that can be no
higher than 2^32-1, and should be the next available value. The higher than 2^(32)-1, and should be the next available value.
value must be unique. A Designated Expert must be used to ensure The value must be unique. A Designated Expert must be used to
that when the name of the recallable type and its value are added ensure that when the name of the recallable type and its value
to the NFSv4 XDR description [10], the result continues to be a are added to the NFSv4 XDR description [10], the result continues
valid XDR description. to be a valid XDR description.
3. The Standards Track RFC(s) that describe the recallable object 3. The Standards Track RFC(s) that describe the recallable object
type. If the RFC(s) have not yet been published, the registrant type. If the RFC(s) have not yet been published, the registrant
will use RFCTBD2, RFCTBD3, etc. instead of an actual RFC number. will use RFCTBD2, RFCTBD3, etc. instead of an actual RFC number.
4. How the RFC introduces the recallable object type. This is 4. How the RFC introduces the recallable object type. This is
indicated by a single US-ASCII value. If the value is N, it indicated by a single US-ASCII value. If the value is N, it
means a minor revision to the NFSv4 protocol. If the value is L, means a minor revision to the NFSv4 protocol. If the value is L,
it means a new pNFS layout type. Other values can be used with it means a new pNFS layout type. Other values can be used with
IESG Approval. IESG Approval.
5. The minor versions of NFSv4 that are allowed to use the 5. The minor versions of NFSv4 that are allowed to 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 a new minor version of NFSv4 approved, a Designated Expert is a 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.4.1. Initial Registry 22.4.1. Initial Registry
The initial registry is in Table 17. Note that the next available The initial registry is in Table 26. Note that the next available
value is five. value 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 | RFC | N | 1 | | RCA4_TYPE_MASK_RDATA_DLG | 0 | RFC | N | 1 |
| | | 5661 | | | | | | 8881 | | |
| RCA4_TYPE_MASK_WDATA_DLG | 1 | RFC | N | 1 | +-------------------------------+-------+------+-----+----------+
| | | 5661 | | | | RCA4_TYPE_MASK_WDATA_DLG | 1 | RFC | N | 1 |
| RCA4_TYPE_MASK_DIR_DLG | 2 | RFC | N | 1 | | | | 8881 | | |
| | | 5661 | | | +-------------------------------+-------+------+-----+----------+
| RCA4_TYPE_MASK_FILE_LAYOUT | 3 | RFC | N | 1 | | RCA4_TYPE_MASK_DIR_DLG | 2 | RFC | N | 1 |
| | | 5661 | | | | | | 8881 | | |
| RCA4_TYPE_MASK_BLK_LAYOUT | 4 | RFC | L | 1 | +-------------------------------+-------+------+-----+----------+
| | | 5661 | | | | RCA4_TYPE_MASK_FILE_LAYOUT | 3 | RFC | N | 1 |
| RCA4_TYPE_MASK_OBJ_LAYOUT_MIN | 8 | RFC | L | 1 | | | | 8881 | | |
| | | 5661 | | | +-------------------------------+-------+------+-----+----------+
| RCA4_TYPE_MASK_OBJ_LAYOUT_MAX | 9 | RFC | L | 1 | | RCA4_TYPE_MASK_BLK_LAYOUT | 4 | RFC | L | 1 |
| | | 5661 | | | | | | 8881 | | |
+-------------------------------+-------+--------+-----+------------+ +-------------------------------+-------+------+-----+----------+
| RCA4_TYPE_MASK_OBJ_LAYOUT_MIN | 8 | RFC | L | 1 |
| | | 8881 | | |
+-------------------------------+-------+------+-----+----------+
| RCA4_TYPE_MASK_OBJ_LAYOUT_MAX | 9 | RFC | L | 1 |
| | | 8881 | | |
+-------------------------------+-------+------+-----+----------+
Table 17: Initial Recallable Object Type Assignments Table 26: Initial Recallable Object 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.5. Layout Types 22.5. Layout Types
IANA created a registry called the "pNFS Layout Types Registry". IANA created a registry called the "pNFS Layout Types Registry".
skipping to change at page 646, line 20 skipping to change at line 30525
The registry is a list of assignments, each containing five fields. The registry is a list of assignments, each containing five fields.
1. The name of the layout type. This name must have the prefix 1. The name of the layout type. This name must have the prefix
"LAYOUT4_". The name must be unique. "LAYOUT4_". The name must be unique.
2. The value of the layout type. IANA will assign this number, and 2. The value of the layout type. IANA will assign this number, and
the request from the registrant will use TBD1 instead of an the request from the registrant will use TBD1 instead of an
actual value. The value assigned must be unique. A Designated actual value. The value assigned must be unique. A Designated
Expert must be used to ensure that when the name of the layout Expert must be used to ensure that when the name of the layout
type and its value are added to the NFSv4.1 layouttype4 type and its value are added to the NFSv4.1 layouttype4
enumerated data type in the NFSv4.1 XDR description ([10]), the enumerated data type in the NFSv4.1 XDR description [10], the
result continues to be a valid XDR description. result continues to be a valid XDR description.
3. The Standards Track RFC(s) that describe the notification. If 3. The Standards Track RFC(s) that describe the notification. If
the RFC(s) have not yet been published, the registrant will use the RFC(s) have not yet been published, the registrant will use
RFCTBD2, RFCTBD3, etc. instead of an actual RFC number. RFCTBD2, RFCTBD3, etc. instead of an actual RFC number.
Collectively, the RFC(s) must adhere to the guidelines listed in Collectively, the RFC(s) must adhere to the guidelines listed in
Section 22.5.3. Section 22.5.3.
4. How the RFC introduces the layout type. This is indicated by a 4. How the RFC introduces the layout type. This is indicated by a
single US-ASCII value. If the value is N, it means a minor single US-ASCII value. If the value is N, it means a minor
skipping to change at page 646, line 44 skipping to change at line 30549
5. The minor versions of NFSv4 that are allowed to use the 5. The minor versions of NFSv4 that are allowed to 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 a new IESG Approval assigns these numbers. Each time there is a 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.5.1. Initial Registry 22.5.1. Initial Registry
The initial registry is in Table 18. The initial registry is in Table 27.
+-----------------------+-------+----------+-----+----------------+ +=======================+=======+==========+=====+================+
| Layout Type Name | Value | RFC | How | Minor Versions | | Layout Type Name | Value | RFC | How | Minor Versions |
+=======================+=======+==========+=====+================+
| LAYOUT4_NFSV4_1_FILES | 0x1 | RFC 8881 | N | 1 |
+-----------------------+-------+----------+-----+----------------+ +-----------------------+-------+----------+-----+----------------+
| LAYOUT4_NFSV4_1_FILES | 0x1 | RFC 5661 | N | 1 |
| LAYOUT4_OSD2_OBJECTS | 0x2 | RFC 5664 | L | 1 | | LAYOUT4_OSD2_OBJECTS | 0x2 | RFC 5664 | L | 1 |
+-----------------------+-------+----------+-----+----------------+
| LAYOUT4_BLOCK_VOLUME | 0x3 | RFC 5663 | L | 1 | | LAYOUT4_BLOCK_VOLUME | 0x3 | RFC 5663 | L | 1 |
+-----------------------+-------+----------+-----+----------------+ +-----------------------+-------+----------+-----+----------------+
Table 18: Initial Layout Type Assignments Table 27: Initial Layout Type Assignments
22.5.2. Updating Registrations 22.5.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.5.3. Guidelines for Writing Layout Type Specifications 22.5.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:
1. The author devises the new layout specification. 1. The author devises the new layout specification.
2. The new layout type specification MUST, at a minimum: 2. The new layout type specification MUST, at a minimum:
* Define the contents of the layout-type-specific fields of the * Define the contents of the layout-type-specific fields of the
following data types: following data types:
+ the da_addr_body field of the device_addr4 data type; - the da_addr_body field of the device_addr4 data type;
+ the loh_body field of the layouthint4 data type; - the loh_body field of the layouthint4 data type;
+ the loc_body field of layout_content4 data type (which in - the loc_body field of layout_content4 data type (which in
turn is the lo_content field of the layout4 data type); turn is the lo_content field of the layout4 data type);
+ the lou_body field of the layoutupdate4 data type; - the lou_body field of the layoutupdate4 data type;
* Describe or define the storage access protocol used to access * Describe or define the storage access protocol used to access
the storage devices. the storage devices.
* Describe whether revocation of layouts is supported. * Describe whether revocation of layouts is supported.
* At a minimum, describe the methods of recovery from: * At a minimum, describe the methods of recovery from:
1. Failure and restart for client, server, storage device. 1. Failure and restart for client, server, storage device.
2. Lease expiration from perspective of the active client, 2. Lease expiration from perspective of the active client,
server, storage device. server, storage device.
3. Loss of layout state resulting in fencing of client access 3. Loss of layout state resulting in fencing of client access
to storage devices (for an example, see Section 12.7.3). to storage devices (for an example, see Section 12.7.3).
* Include an IANA considerations section, which will in turn * Include an IANA considerations section, which will in turn
include: include:
+ A request to IANA for a new layout type per Section 22.5. - A request to IANA for a new layout type per Section 22.5.
+ A list of requests to IANA for any new recallable object - A list of requests to IANA for any new recallable object
types for CB_RECALL_ANY; each entry is to be presented in types for CB_RECALL_ANY; each entry is to be presented in
the form described in Section 22.4. the form described in Section 22.4.
+ A list of requests to IANA for any new notification values - A list of requests to IANA for any new notification values
for CB_NOTIFY_DEVICEID; each entry is to be presented in for CB_NOTIFY_DEVICEID; each entry is to be presented in
the form described in Section 22.3. the form described in Section 22.3.
* Include a security considerations section. This section MUST * Include a security considerations section. This section MUST
explain how the NFSv4.1 authentication, authorization, and explain how the NFSv4.1 authentication, authorization, and
access-control models are preserved. That is, if a metadata access-control models are preserved. That is, if a metadata
server would restrict a READ or WRITE operation, how would server would restrict a READ or WRITE operation, how would
pNFS via the layout similarly restrict a corresponding input pNFS via the layout similarly restrict a corresponding input
or output operation? or output operation?
3. The author documents the new layout specification as an Internet- 3. The author documents the new layout specification as an Internet-
Draft. Draft.
4. The author submits the Internet-Draft for review through the IETF 4. The author submits the Internet-Draft for review through the IETF
standards process as defined in "The Internet Standards Process-- standards process as defined in "The Internet Standards Process--
Revision 3" (BCP 9). The new layout specification will be Revision 3" (BCP 9 [35]). The new layout specification will be
submitted for eventual publication as a Standards Track RFC. submitted for eventual publication as a Standards Track RFC.
5. The layout specification progresses through the IETF standards 5. The layout specification progresses through the IETF standards
process. process.
22.6. Path Variable Definitions 22.6. Path Variable Definitions
This section deals with the IANA considerations associated with the This section deals with the IANA considerations associated with the
variable substitution feature for location names as described in variable substitution feature for location names as described in
Section 11.17.3. As described there, variables subject to Section 11.17.3. As described there, variables subject to
skipping to change at page 650, line 7 skipping to change at line 30697
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.6.1.1.1. Initial Registry 22.6.1.1.1. Initial Registry
The initial registry is in Table 19. The initial registry is in Table 28.
+------------------------+----------+------------------+ +========================+==========+==================+
| Variable Name | RFC | Point of Contact | | Variable Name | RFC | Point of Contact |
+========================+==========+==================+
| ${ietf.org:CPU_ARCH} | RFC 8881 | IESG |
+------------------------+----------+------------------+ +------------------------+----------+------------------+
| ${ietf.org:CPU_ARCH} | RFC 5661 | IESG | | ${ietf.org:OS_TYPE} | RFC 8881 | IESG |
| ${ietf.org:OS_TYPE} | RFC 5661 | IESG | +------------------------+----------+------------------+
| ${ietf.org:OS_VERSION} | RFC 5661 | IESG | | ${ietf.org:OS_VERSION} | RFC 8881 | IESG |
+------------------------+----------+------------------+ +------------------------+----------+------------------+
Table 19: Initial List of Path Variables Table 28: Initial List of Path Variables
IANA has created registries for the values of the variable names IANA has created registries for the values of the variable names
${ietf.org:CPU_ARCH} and ${ietf.org:OS_TYPE}. See Sections 22.6.2 and ${ietf.org:CPU_ARCH} and ${ietf.org:OS_TYPE}. See Sections 22.6.2 and
22.6.3. 22.6.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 the value of ${ietf.org:OS_TYPE}. Thus, values for
${ietf.org:OS_VERSION} are on a Hierarchical Allocation basis and are ${ietf.org:OS_VERSION} are on a Hierarchical Allocation basis and are
of no concern to IANA. of no concern to IANA.
skipping to change at page 652, line 10 skipping to change at line 30795
22.6.3.2. Updating Registrations 22.6.3.2. Updating Registrations
The registrant is free to update the assignment, i.e., change the The registrant is free to update the assignment, i.e., change the
explanation and/or point of contact fields. explanation and/or point of contact fields.
23. References 23. References
23.1. Normative References 23.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[2] Eisler, M., Ed., "XDR: External Data Representation [2] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, May 2006. Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <https://www.rfc-editor.org/info/rfc4506>.
[3] Thurlow, R., "RPC: Remote Procedure Call Protocol [3] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, May 2009. Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <https://www.rfc-editor.org/info/rfc5531>.
[4] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [4] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, DOI 10.17487/RFC2203, September
1997, <https://www.rfc-editor.org/info/rfc2203>.
[5] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [5] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism Version 2", RFC 4121, July Interface (GSS-API) Mechanism: Version 2", RFC 4121,
2005. DOI 10.17487/RFC4121, July 2005,
<https://www.rfc-editor.org/info/rfc4121>.
[6] The Open Group, "Section 3.191 of Chapter 3 of Base [6] The Open Group, "Section 3.191 of Chapter 3 of Base
Definitions of The Open Group Base Specifications Issue 6 Definitions of The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition, HTML Version IEEE Std 1003.1, 2004 Edition, HTML Version",
(www.opengroup.org), ISBN 1931624232", 2004. ISBN 1931624232, 2004, <https://www.opengroup.org>.
[7] Linn, J., "Generic Security Service Application Program [7] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743,
DOI 10.17487/RFC2743, January 2000,
<https://www.rfc-editor.org/info/rfc2743>.
[8] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. [8] Recio, R., Metzler, B., Culley, P., Hilland, J., and D.
Garcia, "A Remote Direct Memory Access Protocol Garcia, "A Remote Direct Memory Access Protocol
Specification", RFC 5040, October 2007. Specification", RFC 5040, DOI 10.17487/RFC5040, October
2007, <https://www.rfc-editor.org/info/rfc5040>.
[9] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February [9] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403,
2009. DOI 10.17487/RFC5403, February 2009,
<https://www.rfc-editor.org/info/rfc5403>.
[10] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [10] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
External Data Representation Standard (XDR) Description", External Data Representation Standard (XDR) Description",
RFC 5662, January 2010. RFC 5662, DOI 10.17487/RFC5662, January 2010,
<https://www.rfc-editor.org/info/rfc5662>.
[11] The Open Group, "Section 3.372 of Chapter 3 of Base [11] The Open Group, "Section 3.372 of Chapter 3 of Base
Definitions of The Open Group Base Specifications Issue 6 Definitions of The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition, HTML Version IEEE Std 1003.1, 2004 Edition, HTML Version",
(www.opengroup.org), ISBN 1931624232", 2004. ISBN 1931624232, 2004, <https://www.opengroup.org>.
[12] Eisler, M., "IANA Considerations for Remote Procedure Call [12] Eisler, M., "IANA Considerations for Remote Procedure Call
(RPC) Network Identifiers and Universal Address Formats", (RPC) Network Identifiers and Universal Address Formats",
RFC 5665, January 2010. RFC 5665, DOI 10.17487/RFC5665, January 2010,
<https://www.rfc-editor.org/info/rfc5665>.
[13] The Open Group, "Section 'read()' of System Interfaces of [13] The Open Group, "Section 'read()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version", ISBN 1931624232,
ISBN 1931624232", 2004. 2004, <https://www.opengroup.org>.
[14] The Open Group, "Section 'readdir()' of System Interfaces [14] The Open Group, "Section 'readdir()' of System Interfaces
of The Open Group Base Specifications Issue 6 IEEE Std of The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version", ISBN 1931624232,
ISBN 1931624232", 2004. 2004, <https://www.opengroup.org>.
[15] The Open Group, "Section 'write()' of System Interfaces of [15] The Open Group, "Section 'write()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version", ISBN 1931624232,
ISBN 1931624232", 2004. 2004, <https://www.opengroup.org>.
[16] Hoffman, P. and M. Blanchet, "Preparation of [16] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, Internationalized Strings ("stringprep")", RFC 3454,
December 2002. DOI 10.17487/RFC3454, December 2002,
<https://www.rfc-editor.org/info/rfc3454>.
[17] The Open Group, "Section 'chmod()' of System Interfaces of [17] The Open Group, "Section 'chmod()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version", ISBN 1931624232,
ISBN 1931624232", 2004. 2004, <https://www.opengroup.org>.
[18] International Organization for Standardization, [18] International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded "Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993. Multilingual Plane", ISO Standard 10646-1, May 1993.
[19] Alvestrand, H., "IETF Policy on Character Sets and [19] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
January 1998, <https://www.rfc-editor.org/info/rfc2277>.
[20] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep [20] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", Profile for Internationalized Domain Names (IDN)",
RFC 3491, March 2003. RFC 3491, DOI 10.17487/RFC3491, March 2003,
<https://www.rfc-editor.org/info/rfc3491>.
[21] The Open Group, "Section 'fcntl()' of System Interfaces of [21] The Open Group, "Section 'fcntl()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version", ISBN 1931624232,
ISBN 1931624232", 2004. 2004, <https://www.opengroup.org>.
[22] The Open Group, "Section 'fsync()' of System Interfaces of [22] The Open Group, "Section 'fsync()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version", ISBN 1931624232,
ISBN 1931624232", 2004. 2004, <https://www.opengroup.org>.
[23] The Open Group, "Section 'getpwnam()' of System Interfaces [23] The Open Group, "Section 'getpwnam()' of System Interfaces
of The Open Group Base Specifications Issue 6 IEEE Std of The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version", ISBN 1931624232,
ISBN 1931624232", 2004. 2004, <https://www.opengroup.org>.
[24] The Open Group, "Section 'unlink()' of System Interfaces [24] The Open Group, "Section 'unlink()' of System Interfaces
of The Open Group Base Specifications Issue 6 IEEE Std of The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version", ISBN 1931624232,
ISBN 1931624232", 2004. 2004, <https://www.opengroup.org>.
[25] Schaad, J., Kaliski, B., and R. Housley, "Additional [25] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005. DOI 10.17487/RFC4055, June 2005,
<https://www.rfc-editor.org/info/rfc4055>.
[26] National Institute of Standards and Technology, [26] National Institute of Standards and Technology, "Computer
"Cryptographic Algorithm Object Registration", URL Security Objects Register", May 2016,
http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/ <https://csrc.nist.gov/projects/computer-security-objects-
algorithms.html, November 2007. register/algorithm-registration>.
[27] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) [27] Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", RFC 7861, DOI 10.17487/RFC7861, Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
November 2016, <https://www.rfc-editor.org/info/rfc7861>. November 2016, <https://www.rfc-editor.org/info/rfc7861>.
[28] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [28] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005, DOI 10.17487/RFC4120, July 2005,
<https://www.rfc-editor.org/info/rfc4120>. <https://www.rfc-editor.org/info/rfc4120>.
skipping to change at page 655, line 24 skipping to change at line 30961
[33] Lever, C., "Network File System (NFS) Upper-Layer Binding [33] Lever, C., "Network File System (NFS) Upper-Layer Binding
to RPC-over-RDMA Version 1", RFC 8267, to RPC-over-RDMA Version 1", RFC 8267,
DOI 10.17487/RFC8267, October 2017, DOI 10.17487/RFC8267, October 2017,
<https://www.rfc-editor.org/info/rfc8267>. <https://www.rfc-editor.org/info/rfc8267>.
[34] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [34] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[35] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
Kolkman, O., Bradner, S., and S. Turner, "Characterization
of Proposed Standards", BCP 9, RFC 7127, January 2014.
Dusseault, L. and R. Sparks, "Guidance on Interoperation
and Implementation Reports for Advancement to Draft
Standard", BCP 9, RFC 5657, September 2009.
Housley, R., Crocker, D., and E. Burger, "Reducing the
Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
October 2011.
Resnick, P., "Retirement of the "Internet Official
Protocol Standards" Summary Document", BCP 9, RFC 7100,
December 2013.
Dawkins, S., "Increasing the Number of Area Directors in
an IETF Area", BCP 9, RFC 7475, March 2015.
<https://www.rfc-editor.org/info/bcp9>
23.2. Informative References 23.2. Informative References
[35] Roach, A., "Process for Handling Non-Major Revisions to [36] Roach, A., "Process for Handling Non-Major Revisions to
Existing RFCs", draft-roach-bis-documents-00 (work in Existing RFCs", Work in Progress, Internet-Draft, draft-
progress), May 2019. roach-bis-documents-00, 7 May 2019,
<https://tools.ietf.org/html/draft-roach-bis-documents-
00>.
[36] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [37] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, DOI 10.17487/RFC3530,
April 2003, <https://www.rfc-editor.org/info/rfc3530>.
[37] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [38] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995. Version 3 Protocol Specification", RFC 1813,
DOI 10.17487/RFC1813, June 1995,
<https://www.rfc-editor.org/info/rfc1813>.
[38] Eisler, M., "LIPKEY - A Low Infrastructure Public Key [39] Eisler, M., "LIPKEY - A Low Infrastructure Public Key
Mechanism Using SPKM", RFC 2847, June 2000. Mechanism Using SPKM", RFC 2847, DOI 10.17487/RFC2847,
June 2000, <https://www.rfc-editor.org/info/rfc2847>.
[39] Eisler, M., "NFS Version 2 and Version 3 Security Issues [40] Eisler, M., "NFS Version 2 and Version 3 Security Issues
and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999. RFC 2623, DOI 10.17487/RFC2623, June 1999,
<https://www.rfc-editor.org/info/rfc2623>.
[40] Juszczak, C., "Improving the Performance and Correctness [41] Juszczak, C., "Improving the Performance and Correctness
of an NFS Server", USENIX Conference Proceedings , June of an NFS Server", USENIX Conference Proceedings, June
1990. 1990.
[41] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced [42] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
by an On-line Database", RFC 3232, January 2002. by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
January 2002, <https://www.rfc-editor.org/info/rfc3232>.
[42] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", [43] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995. RFC 1833, DOI 10.17487/RFC1833, August 1995,
<https://www.rfc-editor.org/info/rfc1833>.
[43] Werme, R., "RPC XID Issues", USENIX Conference [44] Werme, R., "RPC XID Issues", USENIX Conference
Proceedings , February 1996. Proceedings, February 1996.
[44] Nowicki, B., "NFS: Network File System Protocol [45] Nowicki, B., "NFS: Network File System Protocol
specification", RFC 1094, March 1989. specification", RFC 1094, DOI 10.17487/RFC1094, March
1989, <https://www.rfc-editor.org/info/rfc1094>.
[45] Bhide, A., Elnozahy, E., and S. Morgan, "A Highly [46] Bhide, A., Elnozahy, E. N., and S. P. Morgan, "A Highly
Available Network Server", USENIX Conference Proceedings , Available Network Server", USENIX Conference Proceedings,
January 1991. January 1991.
[46] Halevy, B., Welch, B., and J. Zelenka, "Object-Based [47] Halevy, B., Welch, B., and J. Zelenka, "Object-Based
Parallel NFS (pNFS) Operations", RFC 5664, January 2010. Parallel NFS (pNFS) Operations", RFC 5664,
DOI 10.17487/RFC5664, January 2010,
<https://www.rfc-editor.org/info/rfc5664>.
[47] Black, D., Glasgow, J., and S. Fridella, "Parallel NFS [48] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS
(pNFS) Block/Volume Layout", RFC 5663, January 2010. (pNFS) Block/Volume Layout", RFC 5663,
DOI 10.17487/RFC5663, January 2010,
<https://www.rfc-editor.org/info/rfc5663>.
[48] Callaghan, B., "WebNFS Client Specification", RFC 2054, [49] Callaghan, B., "WebNFS Client Specification", RFC 2054,
October 1996. DOI 10.17487/RFC2054, October 1996,
<https://www.rfc-editor.org/info/rfc2054>.
[49] Callaghan, B., "WebNFS Server Specification", RFC 2055, [50] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996. DOI 10.17487/RFC2055, October 1996,
<https://www.rfc-editor.org/info/rfc2055>.
[50] IESG, "IESG Processing of RFC Errata for the IETF Stream", [51] IESG, "IESG Processing of RFC Errata for the IETF Stream",
July 2008. July 2008,
<https://www.ietf.org/about/groups/iesg/statements/
processing-rfc-errata/>.
[51] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [52] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104,
1997. DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[52] Shepler, S., "NFS Version 4 Design Considerations", [53] Shepler, S., "NFS Version 4 Design Considerations",
RFC 2624, June 1999. RFC 2624, DOI 10.17487/RFC2624, June 1999,
<https://www.rfc-editor.org/info/rfc2624>.
[53] The Open Group, "Protocols for Interworking: XNFS, Version [54] The Open Group, "Protocols for Interworking: XNFS, Version
3W, ISBN 1-85912-184-5", February 1998. 3W", ISBN 1-85912-184-5, February 1998.
[54] Floyd, S. and V. Jacobson, "The Synchronization of [55] Floyd, S. and V. Jacobson, "The Synchronization of
Periodic Routing Messages", IEEE/ACM Transactions on Periodic Routing Messages", IEEE/ACM Transactions on
Networking 2(2), pp. 122-136, April 1994. Networking, 2(2), pp. 122-136, April 1994.
[55] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., [56] Chadalapaka, M., Satran, J., Meth, K., and D. Black,
and E. Zeidner, "Internet Small Computer Systems Interface "Internet Small Computer System Interface (iSCSI) Protocol
(iSCSI)", RFC 3720, April 2004. (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April
2014, <https://www.rfc-editor.org/info/rfc7143>.
[56] Snively, R., "Fibre Channel Protocol for SCSI, 2nd Version [57] Snively, R., "Fibre Channel Protocol for SCSI, 2nd Version
(FCP-2)", ANSI/INCITS 350-2003, Oct 2003. (FCP-2)", ANSI/INCITS, 350-2003, October 2003.
[57] Weber, R., "Object-Based Storage Device Commands (OSD)", [58] Weber, R.O., "Object-Based Storage Device Commands (OSD)",
ANSI/INCITS 400-2004, July 2004, ANSI/INCITS, 400-2004, July 2004,
<http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf>. <https://www.t10.org/drafts.htm>.
[58] Carns, P., Ligon III, W., Ross, R., and R. Thakur, "PVFS: [59] Carns, P. H., Ligon III, W. B., Ross, R. B., and R.
A Parallel File System for Linux Clusters.", Proceedings Thakur, "PVFS: A Parallel File System for Linux
of the 4th Annual Linux Showcase and Conference , 2000. Clusters.", Proceedings of the 4th Annual Linux Showcase
and Conference, 2000.
[59] The Open Group, "The Open Group Base Specifications Issue [60] The Open Group, "The Open Group Base Specifications Issue
6, IEEE Std 1003.1, 2004 Edition", 2004. 6, IEEE Std 1003.1, 2004 Edition", 2004,
<https://www.opengroup.org>.
[60] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [61] Callaghan, B., "NFS URL Scheme", RFC 2224,
DOI 10.17487/RFC2224, October 1997,
<https://www.rfc-editor.org/info/rfc2224>.
[61] Chiu, A., Eisler, M., and B. Callaghan, "Security [62] Chiu, A., Eisler, M., and B. Callaghan, "Security
Negotiation for WebNFS", RFC 2755, January 2000. Negotiation for WebNFS", RFC 2755, DOI 10.17487/RFC2755,
January 2000, <https://www.rfc-editor.org/info/rfc2755>.
[62] Narten, T. and H. Alvestrand, "Guidelines for Writing an [63] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
IANA Considerations Section in RFCs", BCP 26, RFC 5226, Writing an IANA Considerations Section in RFCs", BCP 26,
May 2008. RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[63] Eisler, M., "Errata 2006 for RFC 5661", January 2010, [64] RFC Errata, Erratum ID 2006, RFC 5661,
<https://www.rfc-editor.org/errata_search.php?eid=2006>. <https://www.rfc-editor.org/errata/eid2006>.
[64] Spasojevic, M. and M. Satayanarayanan, "An Empirical Study [65] Spasojevic, M. and M. Satayanarayanan, "An Empirical Study
of a Wide-Area Distributed File System", May 1996, of a Wide-Area Distributed File System", ACM Transactions
<https://www.cs.cmu.edu/~satya/docdir/spasojevic-tocs-afs- on Computer Systems, Vol. 14, No. 2, pp. 200-222,
measurement-1996.pdf>. DOI 10.1145/227695.227698, May 1996,
<https://doi.org/10.1145/227695.227698>.
[65] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [66] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>. <https://www.rfc-editor.org/info/rfc5661>.
[66] Noveck, D., "Rules for NFSv4 Extensions and Minor [67] Noveck, D., "Rules for NFSv4 Extensions and Minor
Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
<https://www.rfc-editor.org/info/rfc8178>. <https://www.rfc-editor.org/info/rfc8178>.
[67] Haynes, T., Ed. and D. Noveck, Ed., "Network File System [68] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/info/rfc7530>. March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[68] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, [69] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4.0 Migration: Specification Update", RFC 7931, "NFSv4.0 Migration: Specification Update", RFC 7931,
DOI 10.17487/RFC7931, July 2016, DOI 10.17487/RFC7931, July 2016,
<https://www.rfc-editor.org/info/rfc7931>. <https://www.rfc-editor.org/info/rfc7931>.
[69] Haynes, T., "Requirements for Parallel NFS (pNFS) Layout [70] Haynes, T., "Requirements for Parallel NFS (pNFS) Layout
Types", RFC 8434, DOI 10.17487/RFC8434, August 2018, Types", RFC 8434, DOI 10.17487/RFC8434, August 2018,
<https://www.rfc-editor.org/info/rfc8434>. <https://www.rfc-editor.org/info/rfc8434>.
[70] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [71] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[71] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
Appendix A. Need for this Update Appendix A. The Need for This Update
This document includes an explanation of how clients and servers are This document includes an explanation of how clients and servers are
to determine the particular network access paths to be used to access to determine the particular network access paths to be used to access
a file system. This includes describing how changes to the specific a file system. This includes descriptions of how to handle changes
replica to be used or to the set of addresses to be used to access it to the specific replica to be used or to the set of addresses to be
are to be dealt with, and how transfers of responsibility that need used to access it, and how to deal transparently with transfers of
to be made can be dealt with transparently. This includes cases in responsibility that need to be made. This includes cases in which
which there is a shift between one replica and another and those in there is a shift between one replica and another and those in which
which different network access paths are used to access the same different network access paths are used to access the same replica.
replica.
As a result of the following problems in RFC5661 [65], it is As a result of the following problems in RFC 5661 [66], it was
necessary to provide the specific updates which are made by this necessary to provide the specific updates that are made by this
document. These updates are described in Appendix B document. These updates are described in Appendix B.
o RFC5661 [65], while it dealt with situations in which various * RFC 5661 [66], while it dealt with situations in which various
forms of clustering allowed co-ordination of the state assigned by forms of clustering allowed coordination of the state assigned by
co-operating servers to be used, made no provisions for cooperating servers to be used, made no provisions for Transparent
Transparent State Migration. Within NFSv4.0, Transparent State Migration. Within NFSv4.0, Transparent State Migration was
Migration was first explained clearly in RFC7530 [67] and first explained clearly in RFC 7530 [68] and corrected and
corrected and clarified by RFC7931 [68]. No corresponding clarified by RFC 7931 [69]. No corresponding explanation for
explanation for NFSv4.1 had been provided. NFSv4.1 had been provided.
o Although NFSv4.1 was defined with a clear definition of how * Although NFSv4.1 provided a clear definition of how trunking
trunking detection was to be done, there was no clear detection was to be done, there was no clear specification of how
specification of how trunking discovery was to be done, despite trunking discovery was to be done, despite the fact that the
the fact that the specification clearly indicated that this specification clearly indicated that this information could be
information could be made available via the file system location made available via the file system location attributes.
attributes.
o Because the existence of multiple network access paths to the same * Because the existence of multiple network access paths to the same
file system was dealt with as if there were multiple replicas, file system was dealt with as if there were multiple replicas,
issues relating to transitions between replicas could never be issues relating to transitions between replicas could never be
clearly distinguished from trunking-related transitions between clearly distinguished from trunking-related transitions between
the addresses used to access a particular file system instance. the addresses used to access a particular file system instance.
As a result, in situations in which both migration and trunking As a result, in situations in which both migration and trunking
configuration changes were involved, neither of these could be configuration changes were involved, neither of these could be
clearly dealt with and the relationship between these two features clearly dealt with, and the relationship between these two
was not seriously addressed. features was not seriously addressed.
o Because use of two network access paths to the same file system * Because use of two network access paths to the same file system
instance (i.e. trunking) was often treated as if two replicas were instance (i.e., trunking) was often treated as if two replicas
involved, it was considered that two replicas were being used were involved, it was considered that two replicas were being used
simultaneously. As a result, the treatment of replicas being used simultaneously. As a result, the treatment of replicas being used
simultaneously in RFC5661 [65] was not clear as it covered the two simultaneously in RFC 5661 [66] was not clear, as it covered the
distinct cases of a single file system instance being accessed by two distinct cases of a single file system instance being accessed
two different network access paths and two replicas being accessed by two different network access paths and two replicas being
simultaneously, with the limitations of the latter case not being accessed simultaneously, with the limitations of the latter case
clearly laid out. not being clearly laid out.
The majority of the consequences of these issues are dealt with by The majority of the consequences of these issues are dealt with by
presenting in Section 11 a replacement for Section 11 within RFC5661 presenting in Section 11 a replacement for Section 11 of RFC 5661
[65]. This replacement modifies existing sub-sections within that [66]. This replacement modifies existing subsections within that
section and adds new ones, as described in Appendix B.1. Also, some section and adds new ones as described in Appendix B.1. Also, some
existing sections are deleted. These changes were made in order to: existing sections were deleted. These changes were made in order to
do the following:
o Reorganize the description so that the case of two network access * Reorganize the description so that the case of two network access
paths to the same file system instance needs to be distinguished paths to the same file system instance is distinguished clearly
clearly from the case of two different replicas since, in the from the case of two different replicas since, in the former case,
former case, locking state is shared and there also can be sharing locking state is shared and there also can be sharing of session
of session state. state.
o Provide a clear statement regarding the desirability of * Provide a clear statement regarding the desirability of
transparent transfer of state between replicas together with a transparent transfer of state between replicas together with a
recommendation that either that or a single-fs grace period be recommendation that either transparent transfer or a single-fs
provided. grace period be provided.
o Specifically delineate how such transfers are to be dealt with by * Specifically delineate how a client is to handle such transfers,
the client, taking into account the differences from the treatment taking into account the differences from the treatment in [69]
in [68] made necessary by the major protocol changes made in made necessary by the major protocol changes to NFSv4.1.
NFSv4.1.
o Provide discussion of the relationship between transparent state * Discuss the relationship between transparent state transfer and
transfer and Parallel NFS (pNFS). Parallel NFS (pNFS).
o Provide clarification of the fs_locations_info attribute in order * Clarify the fs_locations_info attribute in order to specify which
to specify which portions of the information provided apply to a portions of the provided information apply to a specific network
specific network access path and which to the replica which that access path and which apply to the replica that the path is used
path is used to access. to access.
In addition, there are also updates to other sections of RFC5661 In addition, other sections of RFC 5661 [66] were updated to correct
[65], where the consequences of the incorrect assumptions underlying the consequences of the incorrect assumptions underlying the
the current treatment of multi-server namespace issues also needed to treatment of multi-server namespace issues. These are described in
be corrected. These are to be dealt with as described in Sections Appendices B.2 through B.4.
B.2 through B.4.
o A revised introductory section regarding multi-server namespace * A revised introductory section regarding multi-server namespace
facilities is provided. facilities is provided.
o A more realistic treatment of server scope is provided, which * A more realistic treatment of server scope is provided. This
reflects the more limited co-ordination of locking state adopted treatment reflects the more limited coordination of locking state
by servers actually sharing a common server scope. adopted by servers actually sharing a common server scope.
o Some confusing text regarding changes in server_owner has been * Some confusing text regarding changes in server_owner has been
clarified. clarified.
o The description of some existing errors has been modified to more * The description of some existing errors has been modified to more
clearly explain certain errors situations to reflect the existence clearly explain certain error situations to reflect the existence
of trunking and the possible use of fs-specific grace periods. of trunking and the possible use of fs-specific grace periods.
For details, see Appendix B.3. For details, see Appendix B.3.
o New descriptions of certain existing operations are provided, * New descriptions of certain existing operations are provided,
either because the existing treatment did not account for either because the existing treatment did not account for
situations that would arise in dealing with transparent state situations that would arise in dealing with Transparent State
migration, or because some types of reclaim issues were not Migration, or because some types of reclaim issues were not
adequately dealt with in the context of fs-specific grace periods. adequately dealt with in the context of fs-specific grace periods.
For details, see Appendix B.2. For details, see Appendix B.2.
Appendix B. Changes in this Update Appendix B. Changes in This Update
B.1. Revisions Made to Section 11 of RFC5661 B.1. Revisions Made to Section 11 of RFC 5661
A number of areas needed to be revised or extended, in many case A number of areas have been revised or extended, in many cases
replacing existing sub-sections within section 11 of RFC5661 [65]: replacing subsections within Section 11 of RFC 5661 [66]:
o New introductory material, including a terminology section, * New introductory material, including a terminology section,
replaces the existing material in RFC5661 [65] ranging from the replaces the material in RFC 5661 [66], ranging from the start of
start of the existing Section 11 up to and including the existing the original Section 11 up to and including Section 11.1. The new
Section 11.1. The new material starts at the beginning of material starts at the beginning of Section 11 and continues
Section 11 and continues through 11.2 below. through 11.2.
o A significant reorganization of the material in the existing * A significant reorganization of the material in Sections 11.4 and
Sections 11.4 and 11.5 (of RFC5661 [65]) is necessary. The 11.5 of RFC 5661 [66] was necessary. The reasons for the
reasons for the reorganization of these sections into a single reorganization of these sections into a single section with
section with multiple subsections are discussed in Appendix B.1.1 multiple subsections are discussed in Appendix B.1.1 below. This
below. This replacement appears as Section 11.5 below. replacement appears as Section 11.5.
New material relating to the handling of the file system location New material relating to the handling of the file system location
attributes is contained in Sections 11.5.1 and 11.5.7 below. attributes is contained in Sections 11.5.1 and 11.5.7.
o A new section describing requirements for user and group handling * A new section describing requirements for user and group handling
within a multi-server namespace has been added as Section 11.7 within a multi-server namespace has been added as Section 11.7.
o A major replacement for the existing Section 11.7 of RFC5661 [65] * A major replacement for Section 11.7 of RFC 5661 [66], entitled
entitled "Effecting File System Transitions", will appear as "Effecting File System Transitions", appears as Sections 11.9
Sections 11.9 through 11.14. The reasons for the reorganization through 11.14. The reasons for the reorganization of this section
of this section into multiple sections are discussed in into multiple sections are discussed in Appendix B.1.2.
Appendix B.1.2.
o A replacement for the existing Section 11.10 of RFC5661 [65] * A replacement for Section 11.10 of RFC 5661 [66], entitled "The
entitled "The Attribute fs_locations_info", will appear as Attribute fs_locations_info", appears as Section 11.17, with
Section 11.17, with Appendix B.1.3 describing the differences Appendix B.1.3 describing the differences between the new section
between the new section and the treatment within [65]. A revised and the treatment within [66]. A revised treatment was necessary
treatment is necessary because the existing treatment did not make because the original treatment did not make clear how the added
clear how the added attribute information relates to the case of attribute information relates to the case of trunked paths to the
trunked paths to the same replica. These issues were not same replica. These issues were not addressed in RFC 5661 [66]
addressed in RFC5661 [65] where the concepts of a replica and a where the concepts of a replica and a network path used to access
network path used to access a replica were not clearly a replica were not clearly distinguished.
distinguished.
B.1.1. Re-organization of Sections 11.4 and 11.5 of RFC5661 B.1.1. Reorganization of Sections 11.4 and 11.5 of RFC 5661
Previously, issues related to the fact that multiple location entries Previously, issues related to the fact that multiple location entries
directed the client to the same file system instance were dealt with directed the client to the same file system instance were dealt with
in a separate Section 11.5 of RFC5661 [65]. Because of the new in Section 11.5 of RFC 5661 [66]. Because of the new treatment of
treatment of trunking, these issues now belong within Section 11.5 trunking, these issues now belong within Section 11.5.
below.
In this new section, trunking is dealt with in Section 11.5.2 In this new section, trunking is covered in Section 11.5.2 together
together with the other uses of file system location information with the other uses of file system location information described in
described in Sections Section 11.5.3 through 11.5.6. Sections 11.5.3 through 11.5.6.
As a result, Section 11.5 which will replace Section 11.4 of RFC5661 As a result, Section 11.5, which replaces Section 11.4 of RFC 5661
[65] is substantially different than the section it replaces in that [66], is substantially different than the section it replaces in that
some existing sections will be replaced by corresponding sections some original sections have been replaced by corresponding sections
below while, at the same time, new sections will be added, resulting as described below, while new sections have been added:
in a replacement containing some renumbered sections, as follows:
o The material in Section 11.5, exclusive of subsections, replaces * The material in Section 11.5, exclusive of subsections, replaces
the material in Section 11.4 of RFC5661 [65] exclusive of the material in Section 11.4 of RFC 5661 [66] exclusive of
subsections. subsections.
o Section 11.5.1 is a new first subsection of the overall section. * Section 11.5.1 is the new first subsection of the overall section.
o Section 11.5.2 is a new second subsection of the overall section. * Section 11.5.2 is the new second subsection of the overall
section.
o Each of the Sections 11.5.4, 11.5.5, and 11.5.6 replaces (in * Each of the Sections 11.5.4, 11.5.5, and 11.5.6 replaces (in
order) one of the corresponding Sections 11.4.1, 11.4.2, and order) one of the corresponding Sections 11.4.1, 11.4.2, and
11.4.3 of RFC5661 [65]. 11.4.4, and 11.4.5. 11.4.3 of RFC 5661 [66].
o Section 11.5.7 is a new final subsection of the overall section. * Section 11.5.7 is the new final subsection of the overall section.
B.1.2. Re-organization of Material Dealing with File System Transitions B.1.2. Reorganization of Material Dealing with File System Transitions
The material relating to file system transition, previously contained The material relating to file system transition, previously contained
in Section 11.7 of RFC5661 [65] has been reorganized and augmented as in Section 11.7 of RFC 5661 [66] has been reorganized and augmented
described below: as described below:
o Because there can be a shift of the network access paths used to * Because there can be a shift of the network access paths used to
access a file system instance without any shift between replicas, access a file system instance without any shift between replicas,
a new Section 11.9 distinguishes between those cases in which a new Section 11.9 distinguishes between those cases in which
there is a shift between distinct replicas and those involving a there is a shift between distinct replicas and those involving a
shift in network access paths with no shift between replicas. shift in network access paths with no shift between replicas.
As a result, a new Section 11.10 deals with network address As a result, the new Section 11.10 deals with network address
transitions while the bulk of the former Section 11.7 (in RFC5661 transitions, while the bulk of the original Section 11.7 of RFC
[65]) is extensively modified as reflected in Section 11.11 which 5661 [66] has been extensively modified as reflected in
is now limited to cases in which there is a shift between two Section 11.11, which is now limited to cases in which there is a
different sets of replicas. shift between two different sets of replicas.
o The additional Section 11.12 discusses the case in which a shift * The additional Section 11.12 discusses the case in which a shift
to a different replica is made and state is transferred to allow to a different replica is made and state is transferred to allow
the client the ability to have continued access to its accumulated the client the ability to have continued access to its accumulated
locking state on the new server. locking state on the new server.
o The additional Section 11.13 discusses the client's response to * The additional Section 11.13 discusses the client's response to
access transitions and how it determines whether migration has access transitions, how it determines whether migration has
occurred, and how it gets access to any transferred locking and occurred, and how it gets access to any transferred locking and
session state. session state.
o The additional Section 11.14 discusses the responsibilities of the * The additional Section 11.14 discusses the responsibilities of the
source and destination servers when transferring locking and source and destination servers when transferring locking and
session state. session state.
This re-organization has caused a renumbering of the sections within This reorganization has caused a renumbering of the sections within
Section 11 of [65] as described below: Section 11 of [66] as described below:
o The new Sections 11.9 and 11.10 have resulted in existing sections * The new Sections 11.9 and 11.10 have resulted in the renumbering
with these numbers to be renumbered. of existing sections with these numbers.
o Section 11.7 of [65] will be substantially modified and appear as * Section 11.7 of [66] has been substantially modified and appears
Section 11.11. The necessary modifications reflect the fact that as Section 11.11. The necessary modifications reflect the fact
this section will only deal with transitions between replicas that this section only deals with transitions between replicas,
while transitions between network addresses are dealt with in while transitions between network addresses are dealt with in
other sections. Details of the reorganization are described later other sections. Details of the reorganization are described later
in this section. in this section.
o The additional Sections 11.12, 11.13, and 11.14 have been added. * Sections 11.12, 11.13, and 11.14 have been added.
o Consequently, Sections 11.8, 11.9, 11.10, and 11.11 in [65] now * Consequently, Sections 11.8, 11.9, 11.10, and 11.11 in [66] now
appear as Sections 11.13, 11.14, 11.15, and 11.16, respectively. appear as Sections 11.15, 11.16, 11.17, and 11.18, respectively.
As part of this general re-organization, Section 11.7 of RFC5661 [65] As part of this general reorganization, Section 11.7 of RFC 5661 [66]
will be modified as described below: has been modified as described below:
o Sections 11.7 and 11.7.1 of RFC5661 [65] are to be replaced by * Sections 11.7 and 11.7.1 of RFC 5661 [66] have been replaced by
Sections 11.11 and 11.11.1, respectively. Sections 11.11 and 11.11.1, respectively.
o Section 11.7.2 (and included subsections) of RFC5661 [65] are to * Section 11.7.2 of RFC 5661 (and included subsections) has been
be deleted. deleted.
o Sections 11.7.3, 11.7.4. 11.7.5, 11.7.5.1, and 11.7.6 of RFC5661 * Sections 11.7.3, 11.7.4, 11.7.5, 11.7.5.1, and 11.7.6 of RFC 5661
[65] are to be replaced by Sections 11.11.2, 11.11.3, 11.11.4, [66] have been replaced by Sections 11.11.2, 11.11.3, 11.11.4,
11.11.4.1, and 11.11.5 respectively in this document. 11.11.4.1, and 11.11.5 respectively in this document.
o Section 11.7.7 of RFC5661 [65] is to be replaced by * Section 11.7.7 of RFC 5661 [66] has been replaced by
Section 11.11.9 This sub-section has been moved to the end of the Section 11.11.9. This subsection has been moved to the end of the
section dealing with file system transitions. section dealing with file system transitions.
o Sections 11.7.8, 11.7.9. and 11.7.10 of RFC5661 [65] are to be * Sections 11.7.8, 11.7.9, and 11.7.10 of RFC 5661 [66] have been
replaced by Sections 11.11.6, 11.11.7, and 11.11.8 respectively in replaced by Sections 11.11.6, 11.11.7, and 11.11.8 respectively in
this document. this document.
B.1.3. Updates to treatment of fs_locations_info B.1.3. Updates to the Treatment of fs_locations_info
Various elements of the fs_locations_info attribute contain Various elements of the fs_locations_info attribute contain
information that applies to either a specific file system replica or information that applies to either a specific file system replica or
to a network path or set of network paths used to access such a to a network path or set of network paths used to access such a
replica. The existing treatment of fs_locations info (in replica. The original treatment of fs_locations_info (Section 11.10
Section 11.10 of RFC5661 [65]) does not clearly distinguish these of RFC 5661 [66]) did not clearly distinguish these cases, in part
cases, in part because the document did not clearly distinguish because the document did not clearly distinguish replicas from the
replicas from the paths used to access them. paths used to access them.
In addition, special clarification needed to be provided with regard In addition, special clarification has been provided with regard to
to the following fields: the following fields:
o With regard to the handling of FSLI4GF_GOING, it needs to be made * With regard to the handling of FSLI4GF_GOING, it was clarified
clear that this only applies to the unavailability of a replica that this only applies to the unavailability of a replica rather
rather than to a path to access a replica. than to a path to access a replica.
o In describing the appropriate value for a server to use for * In describing the appropriate value for a server to use for
fli_valid_for, it needs to be made clear that there is no need for fli_valid_for, it was clarified that there is no need for the
the client to frequently fetch the fs_locations_info value to be client to frequently fetch the fs_locations_info value to be
prepared for shifts in trunking patterns. prepared for shifts in trunking patterns.
o Clarification of the rules for extensions to the fls_info needs to * Clarification of the rules for extensions to the fls_info has been
be provided. The existing treatment reflects the extension model provided. The original treatment reflected the extension model
in effect at the time RFC5661 [65] was written, and needed to be that was in effect at the time RFC 5661 [66] was written, but has
updated in accordance with the extension model described in been updated in accordance with the extension model described in
RFC8178 [66]. RFC 8178 [67].
B.2. Revisions Made to Operations in RFC5661 B.2. Revisions Made to Operations in RFC 5661
Revised descriptions were needed to address issues that arose in Descriptions have been revised to address issues that arose in
effecting necessary changes to multi-server namespace features. effecting necessary changes to multi-server namespace features.
o The existing treatment of EXCHANGE_ID (in Section 18.35 of RFC5661 * The treatment of EXCHANGE_ID (Section 18.35 of RFC 5661 [66])
[65]) assumes that client IDs cannot be created/ confirmed other assumed that client IDs cannot be created/confirmed other than by
than by the EXCHANGE_ID and CREATE_SESSION operations. Also, the the EXCHANGE_ID and CREATE_SESSION operations. Also, the
necessary use of EXCHANGE_ID in recovery from migration and necessary use of EXCHANGE_ID in recovery from migration and
related situations is not addressed clearly. A revised treatment related situations was not clearly addressed. A revised treatment
of EXCHANGE_ID is necessary and it appears in Section 18.35 while of EXCHANGE_ID was necessary, and it appears in Section 18.35,
the specific differences between it and the treatment within [65] while the specific differences between it and the treatment within
are explained in Appendix B.2.1 below. [66] are explained in Appendix B.2.1 below.
o The existing treatment of RECLAIM_COMPLETE in section 18.51 of * The treatment of RECLAIM_COMPLETE in Section 18.51 of RFC 5661
RFC5661 [65]) is not sufficiently clear about the purpose and use [66] was not sufficiently clear about the purpose and use of the
of the rca_one_fs and how the server is to deal with inappropriate rca_one_fs and how the server was to deal with inappropriate
values of this argument. Because the resulting confusion raises values of this argument. Because the resulting confusion raised
interoperability issues, a new treatment of RECLAIM_COMPLETE is interoperability issues, a new treatment of RECLAIM_COMPLETE was
necessary and it appears in Section 18.51 below while the specific necessary, and it appears in Section 18.51, while the specific
differences between it and the treatment within RFC5661 [65] are differences between it and the treatment within RFC 5661 [66] are
discussed in Appendix B.2.2 below. In addition, the definitions discussed in Appendix B.2.2 below. In addition, the definitions
of the reclaim-related errors receive an updated treatment in of the reclaim-related errors have received an updated treatment
Section 15.1.9 to reflect the fact that there are multiple in Section 15.1.9 to reflect the fact that there are multiple
contexts for lock reclaim operations. contexts for lock reclaim operations.
B.2.1. Revision to Treatment of EXCHANGE_ID B.2.1. Revision of Treatment of EXCHANGE_ID
There are a number of issues in the original treatment of EXCHANGE_ID There was a number of issues in the original treatment of EXCHANGE_ID
(in RFC5661 [65]) that cause problems for Transparent State Migration in RFC 5661 [66] that caused problems for Transparent State Migration
and for the transfer of access between different network access paths and for the transfer of access between different network access paths
to the same file system instance. to the same file system instance.
These issues arise from the fact that this treatment was written, These issues arose from the fact that this treatment was written:
o Assuming that a client ID can only become known to a server by * Assuming that a client ID can only become known to a server by
having been created by executing an EXCHANGE_ID, with confirmation having been created by executing an EXCHANGE_ID, with confirmation
of the ID only possible by execution of a CREATE_SESSION. of the ID only possible by execution of a CREATE_SESSION.
o Considering the interactions between a client and a server only * Considering the interactions between a client and a server only
occurring on a single network address occurring on a single network address.
As these assumptions have become invalid in the context of As these assumptions have become invalid in the context of
Transparent State Migration and active use of trunking, the treatment Transparent State Migration and active use of trunking, the treatment
has been modified in several respects. has been modified in several respects:
o It had been assumed that an EXCHANGED_ID executed when the server
is already aware of a given client instance must be either
updating associated parameters (e.g. with respect to callbacks) or
a lingering retransmission to deal with a previously lost reply.
As result, any slot sequence returned by that operation would be
of no use. The existing treatment goes so far as to say that it
"MUST NOT" be used, although this usage is not in accord with [1].
This created a difficulty when an EXCHANGE_ID is done after * It had been assumed that an EXCHANGE_ID executed when the server
Transparent State Migration since that slot sequence would need to was already aware that a given client instance was either updating
be used in a subsequent CREATE_SESSION. associated parameters (e.g., with respect to callbacks) or dealing
with a previously lost reply by retransmitting. As a result, any
slot sequence returned by that operation would be of no use. The
original treatment went so far as to say that it "MUST NOT" be
used, although this usage was not in accord with [1]. This
created a difficulty when an EXCHANGE_ID is done after Transparent
State Migration since that slot sequence would need to be used in
a subsequent CREATE_SESSION.
In the updated treatment, CREATE_SESSION is a way that client IDs In the updated treatment, CREATE_SESSION is a way that client IDs
are confirmed but it is understood that other ways are possible. are confirmed, but it is understood that other ways are possible.
The slot sequence can be used as needed and cases in which it The slot sequence can be used as needed, and cases in which it
would be of no use are appropriately noted. would be of no use are appropriately noted.
o It was assumed that the only functions of EXCHANGE_ID were to * It had been assumed that the only functions of EXCHANGE_ID were to
inform the server of the client, create the client ID, and inform the server of the client, to create the client ID, and to
communicate it to the client. When multiple simultaneous communicate it to the client. When multiple simultaneous
connections are involved, as often happens when trunking, that connections are involved, as often happens when trunking, that
treatment was inadequate in that it ignored the role of treatment was inadequate in that it ignored the role of
EXCHANGE_ID in associating the client ID with the connection on EXCHANGE_ID in associating the client ID with the connection on
which it was done, so that it could be used by a subsequent which it was done, so that it could be used by a subsequent
CREATE_SESSSION, whose parameters do not include an explicit CREATE_SESSION whose parameters do not include an explicit client
client ID. ID.
The new treatment explicitly discusses the role of EXCHANGE_ID in The new treatment explicitly discusses the role of EXCHANGE_ID in
associating the client ID with the connection so it can be used by associating the client ID with the connection so it can be used by
CREATE_SESSION and in associating a connection with an existing CREATE_SESSION and in associating a connection with an existing
session. session.
The new treatment can be found in Section 18.35 above. It supersedes The new treatment can be found in Section 18.35 above. It supersedes
the treatment in Section 18.35 of RFC5661 [65]. the treatment in Section 18.35 of RFC 5661 [66].
B.2.2. Revision to Treatment of RECLAIM_COMPLETE B.2.2. Revision of Treatment of RECLAIM_COMPLETE
The following changes were made to the treatment of RECLAIM_COMPLETE The following changes were made to the treatment of RECLAIM_COMPLETE
in RFC5661 [65] to arrive at the treatment in Section 18.51. in RFC 5661 [66] to arrive at the treatment in Section 18.51:
o In a number of places the text is made more explicit about the * In a number of places, the text was made more explicit about the
purpose of rca_one_fs and its connection to file system migration. purpose of rca_one_fs and its connection to file system migration.
o There is a discussion of situations in which particular forms of * There is a discussion of situations in which particular forms of
RECLAIM_COMPLETE would need to be done. RECLAIM_COMPLETE would need to be done.
o There is a discussion of interoperability issues that result from * There is a discussion of interoperability issues between
implementations that may have arisen due to the lack of clarity of implementations that may have arisen due to the lack of clarity of
the previous treatment of RECLAIM_COMPLETE. the previous treatment of RECLAIM_COMPLETE.
B.3. Revisions Made to Error Definitions in RFC5661 B.3. Revisions Made to Error Definitions in RFC 5661
The new handling of various situations required revisions of some The new handling of various situations required revisions to some
existing error definition: existing error definitions:
o Because of the need to appropriately address trunking-related * Because of the need to appropriately address trunking-related
issues, some uses of the term "replica" in RFC5661 [65] have issues, some uses of the term "replica" in RFC 5661 [66] became
become problematic since a shift in network access paths was problematic because a shift in network access paths was considered
considered to be a shift to a different replica. As a result, the to be a shift to a different replica. As a result, the original
existing definition of NFS4ERR_MOVED (in Section 15.1.2.4 of definition of NFS4ERR_MOVED (in Section 15.1.2.4 of RFC 5661 [66])
RFC5661 [65]) needs to be updated to reflect the different was updated to reflect the different handling of unavailability of
handling of unavailability of a particular fs via a specific a particular fs via a specific network address.
network address.
Since such a situation is no longer considered to constitute Since such a situation is no longer considered to constitute
unavailability of a file system instance, the description needs to unavailability of a file system instance, the description has been
change even though the set of circumstances in which it is to be changed, even though the set of circumstances in which it is to be
returned remain the same. The new paragraph explicitly recognizes returned remains the same. The new paragraph explicitly
that a different network address might be used, while the previous recognizes that a different network address might be used, while
description, misleadingly, treated this as a shift between two the previous description, misleadingly, treated this as a shift
replicas while only a single file system instance might be between two replicas while only a single file system instance
involved. The updated description appears in Section 15.1.2.4 might be involved. The updated description appears in
below. Section 15.1.2.4.
o Because of the need to accommodate use of fs-specific grace * Because of the need to accommodate the use of fs-specific grace
periods, it is necessary to clarify some of the error definitions periods, it was necessary to clarify some of the definitions of
of reclaim-related errors in Section 15 of RFC5661 [65], so the reclaim-related errors in Section 15 of RFC 5661 [66] so that the
text applies properly to reclaims for all types of grace periods. text applies properly to reclaims for all types of grace periods.
The updated descriptions appear within Section 15.1.9 below. The updated descriptions appear within Section 15.1.9.
o Because of the need to provide the clarifications in errata report * Because of the need to provide the clarifications in errata report
2006 [63] and to adapt these to properly explain the interaction 2006 [64] and to adapt these to properly explain the interaction
of NFS4ERR_DELAY with the replay cache, a revised description of of NFS4ERR_DELAY with the reply cache, a revised description of
NFS4ERR_DELAY appears in Section 15.1.1.3. This errata report, NFS4ERR_DELAY appears in Section 15.1.1.3. This errata report,
unlike many other RFC5661 errata reports, is addressed in this unlike many other RFC 5661 errata reports, is addressed in this
document because of the extensive use of NFS4ERR_DELAY in document because of the extensive use of NFS4ERR_DELAY in
connection with state migration and session migration. connection with state migration and session migration.
B.4. Other Revisions Made to RFC5661 B.4. Other Revisions Made to RFC 5661
Beside the major reworking of Section 11 and the associated revisions Besides the major reworking of Section 11 of RFC 5661 [66] and the
to existing operations and errors, there are a number of related associated revisions to existing operations and errors, there were a
changes that are necessary: number of related changes that were necessary:
o The summary that appeared in Section 1.7.3.3 of RFC5661 [65] was * The summary in Section 1.7.3.3 of RFC 5661 [66] was revised to
revised to reflect the changes made in the revised Section 11 reflect the changes made to Section 11 above. The updated summary
above. The updated summary appears as Section 1.8.3.3 above. appears as Section 1.8.3.3 above.
o The discussion of server scope which appeared in Section 2.10.4 of * The discussion of server scope in Section 2.10.4 of RFC 5661 [66]
RFC5661 [65] needed to be replaced, since the previous text was replaced since it appeared to require a level of inter-server
appears to require a level of inter-server co-ordination coordination incompatible with its basic function of avoiding the
incompatible with its basic function of avoiding the need for a need for a globally uniform means of assigning server_owner
globally uniform means of assigning server_owner values. A values. A revised treatment appears in Section 2.10.4.
revised treatment appears in Section 2.10.4.
o The discussion of trunking which appeared in Section 2.10.5 of * The discussion of trunking in Section 2.10.5 of RFC 5661 [66] was
RFC5661 [65] needed to be revised, to more clearly explain the revised to more clearly explain the multiple types of trunking
multiple types of trunking support and how the client can be made support and how the client can be made aware of the existing
aware of the existing trunking configuration. In addition, while trunking configuration. In addition, while the last paragraph
the last paragraph (exclusive of sub-sections) of that section, (exclusive of subsections) of that section dealing with
dealing with server_owner changes, is literally true, it has been server_owner changes was literally true, it had been a source of
a source of confusion. Since the existing paragraph can be read confusion. Since the original paragraph could be read as
as suggesting that such changes be dealt with non-disruptively, suggesting that such changes be handled nondisruptively, the issue
the issue needs to be clarified in the revised section, which was clarified in the revised Section 2.10.5.
appears in Section 2.10.5.
Appendix C. Security Issues that Need to be Addressed Appendix C. Security Issues That Need to Be Addressed
The following issues in the treatment of security within the NFSv4.1 The following issues in the treatment of security within the NFSv4.1
specification need to be addressed: specification need to be addressed:
o The Security Considerations Section of RFC5661 [65] is not written * The Security Considerations Section of RFC 5661 [66] was not
in accord with RFC3552 [71] (also BCP72). Of particular concern written in accordance with RFC 3552 (BCP 72) [72]. Of particular
is the fact that the section does not contain a threat analysis. concern was the fact that the section did not contain a threat
analysis.
o Initial analysis of the existing security issues with NFSv4.1 has * Initial analysis of the existing security issues with NFSv4.1 has
made it likely that a revised Security Considerations Section for made it likely that a revised Security Considerations section for
the existing protocol (one containing a threat analysis) would be the existing protocol (one containing a threat analysis) would be
likely to conclude that NFSv4.1 does not meet the goal of secure likely to conclude that NFSv4.1 does not meet the goal of secure
use on the internet. use on the Internet.
The Security Considerations Section of this document (in Section 21) The Security Considerations section of this document (Section 21) has
has not been thoroughly revised to correct the difficulties mentioned not been thoroughly revised to correct the difficulties mentioned
above. Instead, it has been modified to take proper account of above. Instead, it has been modified to take proper account of
issues related to the multi-server namespace features discussed in issues related to the multi-server namespace features discussed in
Section 11, leaving the incomplete discussion and security weaknesses Section 11, leaving the incomplete discussion and security weaknesses
pretty much as they were. pretty much as they were.
The following major security issues need to be addressed in a The following major security issues need to be addressed in a
satisfactory fashion before an updated Security Considerations satisfactory fashion before an updated Security Considerations
section can be published as part of a bis document for NFSv4.1: section can be published as part of a bis document for NFSv4.1:
o The continued use of AUTH_SYS and the security exposures it * The continued use of AUTH_SYS and the security exposures it
creates needs to be addressed. Addressing this issue must not be creates need to be addressed. Addressing this issue must not be
limited to the questions of whether the designation of this as limited to the questions of whether the designation of this as
OPTIONAL was justified and whether it should be changed. OPTIONAL was justified and whether it should be changed.
In any event, it may not be possible, at this point, to correct In any event, it may not be possible at this point to correct the
the security problems created by continued use of AUTH_SYS simply security problems created by continued use of AUTH_SYS simply by
by revising this designation. revising this designation.
o The lack of attention within the protocol to the possibility of * The lack of attention within the protocol to the possibility of
pervasive monitoring attacks such as those described in RFC7258 pervasive monitoring attacks such as those described in RFC 7258
[70] (also BCP188). [71] (also BCP 188).
In that connection, the use of CREATE_SESSION without privacy In that connection, the use of CREATE_SESSION without privacy
protection needs to be addressed as it exposes the session ID to protection needs to be addressed as it exposes the session ID to
view by an attacker. This is worrisome as this is precisely the view by an attacker. This is worrisome as this is precisely the
type of protocol artifact alluded to in RFC7258, which can enable type of protocol artifact alluded to in RFC 7258, which can enable
further mischief on the part of the attacker as it enables denial- further mischief on the part of the attacker as it enables denial-
of-service attacks which can be executed effectively with only a of-service attacks that can be executed effectively with only a
single, normally low-value, credential, even when RPCSEC_GSS single, normally low-value, credential, even when RPCSEC_GSS
authentication is in use. authentication is in use.
o The lack of effective use of privacy and integrity, even where the * The lack of effective use of privacy and integrity, even where the
infrastructure to support use of RPCSEC_GSS in present, needs to infrastructure to support use of RPCSEC_GSS is present, needs to
be addressed. be addressed.
In light of the security exposures that this situation creates, it In light of the security exposures that this situation creates, it
is not enough to define a protocol that could, with the provision is not enough to define a protocol that could address this problem
of sufficient resources, address the problem. Instead, what is with the provision of sufficient resources. Instead, what is
needed is a way to provide the necessary security, with very needed is a way to provide the necessary security with very
limited performance costs and without requiring security limited performance costs and without requiring security
infrastructure that experience has shown is difficult for many infrastructure, which experience has shown is difficult for many
clients and servers to provide. clients and servers to provide.
In trying to provide a major security upgrade for a deployed protocol In trying to provide a major security upgrade for a deployed protocol
such as NFSv4.1, the working group, and the internet community is such as NFSv4.1, the working group and the Internet community are
likely to find itself dealing with a number of considerations such as likely to find themselves dealing with a number of considerations
the following: such as the following:
o The need to accommodate existing deployments of existing protocols * The need to accommodate existing deployments of protocols
as specified previously in existing Proposed Standards. specified previously in existing Proposed Standards.
o The difficulty of effecting changes to existing interoperating * The difficulty of effecting changes to existing, interoperating
implementations. implementations.
o The difficulty of making changes to NFSv4 protocols other than * The difficulty of making changes to NFSv4 protocols other than
those in the form of OPTIONAL extensions. those in the form of OPTIONAL extensions.
o The tendency of those responsible for existing NFSv4 deployments * The tendency of those responsible for existing NFSv4 deployments
to ignore security flaws in the context of local area networks to ignore security flaws in the context of local area networks
under the mistaken impression that network isolation provides, in under the mistaken impression that network isolation provides, in
and of itself, isolation from all potential attackers. and of itself, isolation from all potential attackers.
Given that the difficulties mentioned above apply to minor version Given that the above-mentioned difficulties apply to minor version
zero as well, it may make sense to deal with these security issues in zero as well, it may make sense to deal with these security issues in
a common document applying to all NFSv4 minor versions. If that a common document that applies to all NFSv4 minor versions. If that
approach is taken the, Security Considerations section of an eventual approach is taken, the Security Considerations section of an eventual
NFv4.1 bis document would reference that common document and the NFv4.1 bis document would reference that common document, and the
defining RFCs for other minor versions might do so as well. defining RFCs for other minor versions might do so as well.
Appendix D. Acknowledgments Acknowledgments
D.1. Acknowledgments for this Update Acknowledgments for This Update
The authors wish to acknowledge the important role of Andy Adamson of The authors wish to acknowledge the important role of Andy Adamson of
Netapp in clarifying the need for trunking discovery functionality, Netapp in clarifying the need for trunking discovery functionality,
and exploring the role of the file system location attributes in and exploring the role of the file system location attributes in
providing the necessary support. providing the necessary support.
The authors wish to thank Tom Haynes of Hammerspace for drawing our The authors wish to thank Tom Haynes of Hammerspace for drawing our
attention to the fact that internationalization and security might attention to the fact that internationalization and security might
best be handled in documents dealing with such protocol issues as best be handled in documents dealing with such protocol issues as
they apply to all NFSv4 minor versions. they apply to all NFSv4 minor versions.
The authors also wish to acknowledge the work of Xuan Qi of Oracle The authors also wish to acknowledge the work of Xuan Qi of Oracle
with NFSv4.1 client and server prototypes of transparent state with NFSv4.1 client and server prototypes of Transparent State
migration functionality. Migration functionality.
The authors wish to thank others that brought attention to important The authors wish to thank others that brought attention to important
issues. The comments of Trond Myklebust of Primary Data related to issues. The comments of Trond Myklebust of Primary Data related to
trunking helped to clarify the role of DNS in trunking discovery. trunking helped to clarify the role of DNS in trunking discovery.
Rick Macklem's comments brought attention to problems in the handling Rick Macklem's comments brought attention to problems in the handling
of the per-fs version of RECLAIM_COMPLETE. of the per-fs version of RECLAIM_COMPLETE.
The authors wish to thank Olga Kornievskaia of Netapp for her helpful The authors wish to thank Olga Kornievskaia of Netapp for her helpful
review comments. review comments.
D.2. Acknowledgments for RFC5661 Acknowledgments for RFC 5661
The initial text for the SECINFO extensions were edited by Mike The initial text for the SECINFO extensions were edited by Mike
Eisler with contributions from Peng Dai, Sergey Klyushin, and Carl Eisler with contributions from Peng Dai, Sergey Klyushin, and Carl
Burnett. Burnett.
The initial text for the SESSIONS extensions were edited by Tom The initial text for the SESSIONS extensions were edited by Tom
Talpey, Spencer Shepler, Jon Bauman with contributions from Charles Talpey, Spencer Shepler, Jon Bauman with contributions from Charles
Antonelli, Brent Callaghan, Mike Eisler, John Howard, Chet Juszczak, Antonelli, Brent Callaghan, Mike Eisler, John Howard, Chet Juszczak,
Trond Myklebust, Dave Noveck, John Scott, Mike Stolarchuk, and Mark Trond Myklebust, Dave Noveck, John Scott, Mike Stolarchuk, and Mark
Wittle. Wittle.
skipping to change at page 671, line 28 skipping to change at line 31735
The initial text for the parallel NFS support was edited by Brent The initial text for the parallel NFS support was edited by Brent
Welch and Garth Goodson. Additional authors for those documents were Welch and Garth Goodson. Additional authors for those documents were
Benny Halevy, David Black, and Andy Adamson. Additional input came Benny Halevy, David Black, and Andy Adamson. Additional input came
from the informal group that contributed to the construction of the from the informal group that contributed to the construction of the
initial pNFS drafts; specific acknowledgment goes to Gary Grider, initial pNFS drafts; specific acknowledgment goes to Gary Grider,
Peter Corbett, Dave Noveck, Peter Honeyman, and Stephen Fridella. Peter Corbett, Dave Noveck, Peter Honeyman, and Stephen Fridella.
Fredric Isaman found several errors in draft versions of the ONC RPC Fredric Isaman found several errors in draft versions of the ONC RPC
XDR description of the NFSv4.1 protocol. XDR description of the NFSv4.1 protocol.
Audrey Van Belleghem provided, in numerous ways, essential co- Audrey Van Belleghem provided, in numerous ways, essential
ordination and management of the process of editing the specification coordination and management of the process of editing the
documents. specification documents.
Richard Jernigan gave feedback on the file layout's striping pattern Richard Jernigan gave feedback on the file layout's striping pattern
design. design.
Several formal inspection teams were formed to review various areas Several formal inspection teams were formed to review various areas
of the protocol. All the inspections found significant errors and of the protocol. All the inspections found significant errors and
room for improvement. NFSv4.1's inspection teams were: room for improvement. NFSv4.1's inspection teams were:
o ACLs, with the following inspectors: Sam Falkner, Bruce Fields, * ACLs, with the following inspectors: Sam Falkner, Bruce Fields,
Rahul Iyer, Saadia Khan, Dave Noveck, Lisa Week, Mario Wurzl, and Rahul Iyer, Saadia Khan, Dave Noveck, Lisa Week, Mario Wurzl, and
Alan Yoder. Alan Yoder.
o Sessions, with the following inspectors: William Brown, Tom * Sessions, with the following inspectors: William Brown, Tom
Doeppner, Robert Gordon, Benny Halevy, Fredric Isaman, Rick Doeppner, Robert Gordon, Benny Halevy, Fredric Isaman, Rick
Macklem, Trond Myklebust, Dave Noveck, Karen Rochford, John Scott, Macklem, Trond Myklebust, Dave Noveck, Karen Rochford, John Scott,
and Peter Shah. and Peter Shah.
o Initial pNFS inspection, with the following inspectors: Andy * Initial pNFS inspection, with the following inspectors: Andy
Adamson, David Black, Mike Eisler, Marc Eshel, Sam Falkner, Garth Adamson, David Black, Mike Eisler, Marc Eshel, Sam Falkner, Garth
Goodson, Benny Halevy, Rahul Iyer, Trond Myklebust, Spencer Goodson, Benny Halevy, Rahul Iyer, Trond Myklebust, Spencer
Shepler, and Lisa Week. Shepler, and Lisa Week.
o Global namespace, with the following inspectors: Mike Eisler, Dan * Global namespace, with the following inspectors: Mike Eisler, Dan
Ellard, Craig Everhart, Fredric Isaman, Trond Myklebust, Dave Ellard, Craig Everhart, Fredric Isaman, Trond Myklebust, Dave
Noveck, Theresa Raj, Spencer Shepler, Renu Tewari, and Robert Noveck, Theresa Raj, Spencer Shepler, Renu Tewari, and Robert
Thurlow. Thurlow.
o NFSv4.1 file layout type, with the following inspectors: Andy * 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 * 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: * EXCHANGE_ID and DESTROY_CLIENTID, with the following inspectors:
Mike Eisler, Pranoop Erasani, Robert Gordon, Benny Halevy, Fredric Mike Eisler, Pranoop Erasani, Robert Gordon, Benny Halevy, Fredric
Isaman, Saadia Khan, Ricardo Labiaga, Rick Macklem, Trond Isaman, Saadia Khan, Ricardo Labiaga, Rick Macklem, Trond
Myklebust, Spencer Shepler, and Brent Welch. Myklebust, Spencer Shepler, and Brent Welch.
o Final pNFS inspection, with the following inspectors: Andy * 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,
skipping to change at page 672, line 46 skipping to change at line 31801
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.
Olga Kornievskaia found several errors in the SSV specification. Olga Kornievskaia found several errors in the SSV specification.
Ricardo Labiaga found several places where the use of RPCSEC_GSS was Ricardo Labiaga found several places where the use of RPCSEC_GSS was
underspecified. underspecified.
Those who provided miscellaneous comments include: Andy Adamson, Those who provided miscellaneous comments include: Andy Adamson,
Sunil Bhargo, Alex Burlyga, Pranoop Erasani, Bruce Fields, Vadim Sunil Bhargo, Alex Burlyga, Pranoop Erasani, Bruce Fields, Vadim
Finkelstein, Jason Goldschmidt, Vijay K. Gurbani, Sergey Klyushin, Finkelstein, Jason Goldschmidt, Vijay K. Gurbani, Sergey Klyushin,
Ricardo Labiaga, James Lentini, Anshul Madan, Daniel Muntz, Daniel Ricardo Labiaga, James Lentini, Anshul Madan, Daniel Muntz, Daniel
Picken, Archana Ramani, Jim Rees, Mahesh Siddheshwar, Tom Talpey, and Picken, Archana Ramani, Jim Rees, Mahesh Siddheshwar, Tom Talpey, and
Peter Varga. Peter Varga.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
NetApp NetApp
1601 Trapelo Road, Suite 16 1601 Trapelo Road, Suite 16
Waltham, MA 02451 Waltham, MA 02451
USA United States of America
Phone: +1-781-768-5347 Phone: +1-781-768-5347
EMail: dnoveck@netapp.com Email: dnoveck@netapp.com
Charles Lever Charles Lever
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
United States of America United States of America
Phone: +1 248 614 5091 Phone: +1-248-614-5091
EMail: chuck.lever@oracle.com Email: chuck.lever@oracle.com
 End of changes. 1813 change blocks. 
4197 lines changed or deleted 4764 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/