draft-ietf-nfsv4-rfc5661sesqui-msns-04.original   draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt 
NFSv4 D. Noveck, Ed. Internet Engineering Task Force (IETF) D. Noveck, Ed.
Internet-Draft NetApp Request for Comments: 0000 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 April 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 RFC5661. 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 RFC5661.
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/rfc0000.
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 Needed
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. 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 RFC5661
B.2. Revisions Made to Operations in RFC5661 . . . . . . . . . 664 B.2. Revisions Made to Operations in RFC5661
B.3. Revisions Made to Error Definitions in RFC5661 . . . . . 666 B.3. Revisions Made to Error Definitions in RFC5661
B.4. Other Revisions Made to RFC5661 . . . . . . . . . . . . . 667 B.4. Other Revisions Made to RFC5661
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, 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 [65]. RFC5661 is
obsoleted by this document. However, the update has a limited scope obsoleted by this document. However, the update has a limited scope
and is focused on enabling full use of trunking and transparent state and is focused on enabling full use of trunking and transparent state
migration. The need for these changes is discussed in Appendix A. migration. The need for these changes is discussed in Appendix A.
Appendix B describes the specific changes made to arrive at the Appendix B describes the specific changes made to arrive at the
current text. 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 [35], 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 expected by
a full update of the protocol. Below are some areas which are known a full update of the protocol. Below are some areas which are known
to need addressing in a future update of the protocol. 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 [66] which
establishes NFSv4-wide versioning rules. As RFC5661 is currently establishes NFSv4-wide versioning rules. As RFC5661 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 RFC8178
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 [69], which
establishes the requirements for pNFS layout types, which are not establishes the requirements for pNFS layout types, which are not
clearly defined in RFC5661. When that work is done and the clearly defined in RFC5661. When that work is done and the
resulting documents approved, the new NFSv4.1 specification resulting documents approved, the new NFSv4.1 specification
document will provide a clear set of requirements for layout types document will provide a clear set of requirements for layout types
and a description of the file layout type that conforms to those and a description of the file layout type that conforms to those
requirements. Other layout types will have their own requirements. Other layout types will have their own
specification documents that conforms to those requirements as specification documents that conforms to those requirements as
well. 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 [63], 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
skipping to change at page 9, line 19 skipping to change at line 393
decided that the treatment in RFC 5661 is incorrect, and needs to decided that the treatment in RFC 5661 is incorrect, and needs to
be revised to reflect the working group's new consensus and ensure be revised to reflect the working group's new consensus and ensure
compatibility with existing implementations that do not follow the compatibility with existing implementations that do not follow the
handling described in in RFC 5661. handling described in 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 implementers and the authors of an eventual
rfc5661bis, despite the fact that this document, when approved, rfc5661bis, despite the fact that this document, when approved,
will obsolete RFC 5661 [65]. will obsolete RFC 5661 [65].
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 [67] 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 providing a description of the NFSv4.1 protocol and any
full description would involve documents updating other documents 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 RFC8434 [69] and
RFC8178 [66] to RFC5661 also apply to this specification, and will RFC8178 [66] to RFC5661 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 [67]. 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 [36]. 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 [37]. 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 17, line 11 skipping to change at line 764
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 non-disruptive 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 non-disruptive 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]. [38].
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.
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.2 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 24, line 51 skipping to change at line 1139
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 [36].)
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 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
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]. [40].
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.
skipping to change at page 40, line 45 skipping to change at line 1900
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 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 48, line 45 skipping to change at line 2284
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 id's it obtained previously (e.g. file handles) can be validly
used on the new server, and, even if the new server accepts them, used on the new server, and, even if the new server accepts them,
there is no assurance that this is not due to accident. Thus, it there is no assurance that this is not due to accident. Thus, it
is best to treat all such state as lost/stale although a client is best to treat all such state as lost/stale although a client
may assume that the probability of inadvertent acceptance is low may assume that the probability of inadvertent acceptance is low
and treat this situation as within the next case. 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 file handle 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 claiming
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 2350
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 2393
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 2459
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 2552
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
skipping to change at page 55, line 22 skipping to change at line 2594
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 2646
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 58, line 7 skipping to change at line 2718
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_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
skipping to change at page 63, line 31 skipping to change at line 2981
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 69, line 46 skipping to change at line 3273
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 3341
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 3400
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 78, line 23 skipping to change at line 3658
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 3684
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 3735
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 3876
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 87, line 20 skipping to change at line 4077
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 4099
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 35 skipping to change at line 4388
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 98, line 8 skipping to change at line 4625
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
types for a single file. types for a single file.
skipping to change at page 103, line 6 skipping to change at line 4865
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 47 skipping to change at line 4955
Named attributes are accessed by the new OPENATTR operation, which Named attributes are accessed by the new OPENATTR operation, which
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 5071
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 5108
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 5149
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 between the assigned number and [10], the latter is conflicts between the assigned number and [10], the latter is
likely authoritative, but should be resolved with Errata to this likely authoritative, but should be resolved with Errata to this
document and/or [10]. See [50] for the Errata process. document and/or [10]. See [50] 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 6.2.1 |
+--------------------+----+----------------+-----+------------------+
| aclsupport | 13 | uint32_t | R | Section 6.2.1.2 | | aclsupport | 13 | uint32_t | R | Section 6.2.1.2 |
+--------------------+----+----------------+-----+------------------+
| archive | 14 | bool | R W | Section 5.8.2.1 | | archive | 14 | bool | R W | Section 5.8.2.1 |
+--------------------+----+----------------+-----+------------------+
| cansettime | 15 | bool | R | Section 5.8.2.2 | | cansettime | 15 | bool | R | Section 5.8.2.2 |
+--------------------+----+----------------+-----+------------------+
| case_insensitive | 16 | bool | R | Section 5.8.2.3 | | case_insensitive | 16 | bool | R | Section 5.8.2.3 |
+--------------------+----+----------------+-----+------------------+
| case_preserving | 17 | bool | R | Section 5.8.2.4 | | case_preserving | 17 | bool | R | Section 5.8.2.4 |
+--------------------+----+----------------+-----+------------------+
| change_policy | 60 | chg_policy4 | R | Section 5.8.2.5 | | change_policy | 60 | chg_policy4 | R | Section 5.8.2.5 |
+--------------------+----+----------------+-----+------------------+
| chown_restricted | 18 | bool | R | Section 5.8.2.6 | | chown_restricted | 18 | bool | R | Section 5.8.2.6 |
+--------------------+----+----------------+-----+------------------+
| dacl | 58 | nfsacl41 | R W | Section 6.2.2 | | dacl | 58 | nfsacl41 | R W | Section 6.2.2 |
+--------------------+----+----------------+-----+------------------+
| dir_notif_delay | 56 | nfstime4 | R | Section 5.11.1 | | dir_notif_delay | 56 | nfstime4 | R | Section 5.11.1 |
+--------------------+----+----------------+-----+------------------+
| dirent_notif_delay | 57 | nfstime4 | R | Section 5.11.2 | | dirent_notif_delay | 57 | nfstime4 | R | Section 5.11.2 |
+--------------------+----+----------------+-----+------------------+
| fileid | 20 | uint64_t | R | Section 5.8.2.7 | | fileid | 20 | uint64_t | R | Section 5.8.2.7 |
+--------------------+----+----------------+-----+------------------+
| files_avail | 21 | uint64_t | R | Section 5.8.2.8 | | files_avail | 21 | uint64_t | R | Section 5.8.2.8 |
+--------------------+----+----------------+-----+------------------+
| files_free | 22 | uint64_t | R | Section 5.8.2.9 | | files_free | 22 | uint64_t | R | Section 5.8.2.9 |
| files_total | 23 | uint64_t | R | Section 5.8.2.10 | +--------------------+----+----------------+-----+------------------+
| fs_charset_cap | 76 | uint32_t | R | Section 5.8.2.11 | | files_total | 23 | uint64_t | R | Section |
| | | | | 5.8.2.10 |
+--------------------+----+----------------+-----+------------------+
| fs_charset_cap | 76 | uint32_t | R | Section |
| | | | | 5.8.2.11 |
+--------------------+----+----------------+-----+------------------+
| fs_layout_type | 62 | layouttype4<> | R | Section 5.12.1 | | fs_layout_type | 62 | layouttype4<> | R | Section 5.12.1 |
| fs_locations | 24 | fs_locations | R | Section 5.8.2.12 | +--------------------+----+----------------+-----+------------------+
| fs_locations_info | 67 | * | R | Section 5.8.2.13 | | fs_locations | 24 | fs_locations | R | Section |
| fs_status | 61 | fs4_status | R | Section 5.8.2.14 | | | | | | 5.8.2.12 |
| hidden | 25 | bool | R W | Section 5.8.2.15 | +--------------------+----+----------------+-----+------------------+
| homogeneous | 26 | bool | R | Section 5.8.2.16 | | fs_locations_info | 67 | * | R | Section |
| | | | | 5.8.2.13 |
+--------------------+----+----------------+-----+------------------+
| fs_status | 61 | fs4_status | R | Section |
| | | | | 5.8.2.14 |
+--------------------+----+----------------+-----+------------------+
| hidden | 25 | bool | R W | Section |
| | | | | 5.8.2.15 |
+--------------------+----+----------------+-----+------------------+
| homogeneous | 26 | bool | R | Section |
| | | | | 5.8.2.16 |
+--------------------+----+----------------+-----+------------------+
| layout_alignment | 66 | uint32_t | R | Section 5.12.2 | | layout_alignment | 66 | uint32_t | R | Section 5.12.2 |
+--------------------+----+----------------+-----+------------------+
| layout_blksize | 65 | uint32_t | R | Section 5.12.3 | | layout_blksize | 65 | uint32_t | R | Section 5.12.3 |
+--------------------+----+----------------+-----+------------------+
| layout_hint | 63 | layouthint4 | W | Section 5.12.4 | | layout_hint | 63 | layouthint4 | W | Section 5.12.4 |
+--------------------+----+----------------+-----+------------------+
| layout_type | 64 | layouttype4<> | R | Section 5.12.5 | | 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 | | maxfilesize | 27 | uint64_t | R | Section |
| maxname | 29 | uint32_t | R | Section 5.8.2.19 | | | | | | 5.8.2.17 |
| maxread | 30 | uint64_t | R | Section 5.8.2.20 | +--------------------+----+----------------+-----+------------------+
| maxwrite | 31 | uint64_t | R | Section 5.8.2.21 | | 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 | | mdsthreshold | 68 | mdsthreshold4 | R | Section 5.12.6 |
| mimetype | 32 | utf8str_cs | R W | Section 5.8.2.22 | +--------------------+----+----------------+-----+------------------+
| mimetype | 32 | utf8str_cs | R W | Section |
| | | | | 5.8.2.22 |
+--------------------+----+----------------+-----+------------------+
| mode | 33 | mode4 | R W | Section 6.2.4 | | mode | 33 | mode4 | R W | Section 6.2.4 |
+--------------------+----+----------------+-----+------------------+
| mode_set_masked | 74 | mode_masked4 | W | Section 6.2.5 | | 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 | | mounted_on_fileid | 55 | uint64_t | R | Section |
| numlinks | 35 | uint32_t | R | Section 5.8.2.25 | | | | | | 5.8.2.23 |
| owner | 36 | utf8str_mixed | R W | Section 5.8.2.26 | +--------------------+----+----------------+-----+------------------+
| owner_group | 37 | utf8str_mixed | R W | Section 5.8.2.27 | | no_trunc | 34 | bool | R | Section |
| quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.28 | | | | | | 5.8.2.24 |
| quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.29 | +--------------------+----+----------------+-----+------------------+
| quota_used | 40 | uint64_t | R | Section 5.8.2.30 | | numlinks | 35 | uint32_t | R | Section |
| rawdev | 41 | specdata4 | R | Section 5.8.2.31 | | | | | | 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_get | 71 | retention_get4 | R | Section 5.13.3 |
+--------------------+----+----------------+-----+------------------+
| retentevt_set | 72 | retention_set4 | W | Section 5.13.4 | | retentevt_set | 72 | retention_set4 | W | Section 5.13.4 |
+--------------------+----+----------------+-----+------------------+
| retention_get | 69 | retention_get4 | R | Section 5.13.1 | | retention_get | 69 | retention_get4 | R | Section 5.13.1 |
+--------------------+----+----------------+-----+------------------+
| retention_hold | 73 | uint64_t | R W | Section 5.13.5 | | retention_hold | 73 | uint64_t | R W | Section 5.13.5 |
+--------------------+----+----------------+-----+------------------+
| retention_set | 70 | retention_set4 | W | Section 5.13.2 | | retention_set | 70 | retention_set4 | W | Section 5.13.2 |
+--------------------+----+----------------+-----+------------------+
| sacl | 59 | nfsacl41 | R W | Section 6.2.3 | | 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_avail | 42 | uint64_t | R | Section |
| space_total | 44 | uint64_t | R | Section 5.8.2.34 | | | | | | 5.8.2.32 |
| space_used | 45 | uint64_t | R | Section 5.8.2.35 | +--------------------+----+----------------+-----+------------------+
| system | 46 | bool | R W | Section 5.8.2.36 | | space_free | 43 | uint64_t | R | Section |
| time_access | 47 | nfstime4 | R | Section 5.8.2.37 | | | | | | 5.8.2.33 |
| time_access_set | 48 | settime4 | W | Section 5.8.2.38 | +--------------------+----+----------------+-----+------------------+
| time_backup | 49 | nfstime4 | R W | Section 5.8.2.39 | | space_total | 44 | uint64_t | R | Section |
| time_create | 50 | nfstime4 | R W | Section 5.8.2.40 | | | | | | 5.8.2.34 |
| time_delta | 51 | nfstime4 | R | Section 5.8.2.41 | +--------------------+----+----------------+-----+------------------+
| time_metadata | 52 | nfstime4 | R | Section 5.8.2.42 | | space_used | 45 | uint64_t | R | Section |
| time_modify | 53 | nfstime4 | R | Section 5.8.2.43 | | | | | | 5.8.2.35 |
| time_modify_set | 54 | settime4 | W | Section 5.8.2.44 | +--------------------+----+----------------+-----+------------------+
| 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 |
+--------------------+----+----------------+-----+------------------+ +--------------------+----+----------------+-----+------------------+
Table 3 Table 5
* fs_locations_info4 * fs_locations_info4
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 126, line 17 skipping to change at line 6080
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 6157
"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 7 skipping to change at line 6295
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 6473
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 6541
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 143, line 20 skipping to change at line 6853
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 6982
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 26 skipping to change at line 7578
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) [53]. 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 7659
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 7784
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 7862
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 7912
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 7991
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 8070
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 8121
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 35 skipping to change at line 8394
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 8599
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 183, line 47 skipping to change at line 8788
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 8939
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 8985
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 9304
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 9374
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 9427
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 9502
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 9555
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 9632
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 9661
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 9694
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 9800
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 OPEN_DELEGATE_WRITE
skipping to change at page 206, line 51 skipping to change at line 9887
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 10057
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 10092
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 10173
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 10458
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 10536
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 10609
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 10714
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 10873
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
skipping to change at page 228, line 35 skipping to change at line 10926
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 RFC5661 [65], making
it necessary to provide those means in this document. it necessary to provide those means in this document.
skipping to change at page 229, line 43 skipping to change at line 10982
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 terminology relating to the construction of multi-server
namespaces out of a set of local per-server namespaces: 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 which 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 (described in Section 11.5.6), migration (described in
Section 11.5.5), and replication (described in Section 11.5.4). Section 11.5.5), and replication (described in 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 co-ordination 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 terminology relating 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 host name or an
address, and an fs name, which designates the location of the file address, and an fs name, which designates the location of the file
system within the server's local namespace. A file system system within the server's local namespace. A file system
location entry designates a set of server endpoints to which the location entry designates a set of server endpoints to which the
client may establish connections. There may be multiple endpoints client may establish connections. There may be multiple endpoints
because a host name may map to multiple network addresses and because a host name may map to multiple network addresses and
because multiple connection types may be used to communicate with because multiple connection types may be used to communicate with
a single network address. However, except where an explicit port a single network address. However, except where an explicit port
numbers are used to designate a set of server within a single numbers are used to designate a set of server within a single
skipping to change at page 231, line 13 skipping to change at line 11047
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, 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 host name 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 which includes the IP address of an interface to
a server and an fs name which is the location of the file system a 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 RFC5661 [65], with a meaning different from that in
this document. In short, in [65] each replica is identified by a this document. In short, in [65] each replica is identified by a
single network access path while, in the current document a set of single network access path while, in the current document a set of
network access paths which have server-trunkable network addresses network access paths which have server-trunkable network addresses
skipping to change at page 232, line 30 skipping to change at line 11112
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. This attribute
provides to the client, in addition to specification of file system provides to the client, in addition to specification of file system
instance locations, other helpful information such as: instance locations, other helpful information such as:
o Information guiding choices among the various file system * Information guiding choices among the various file system
instances provided (e.g., priority for use, writability, currency, instances provided (e.g., priority for use, writability, currency,
etc.). etc.).
o Information to help the client efficiently effect as seamless a * Information to help the client efficiently effect as seamless a
transition as possible among multiple file system instances, when transition as possible among multiple file system instances, when
and if that should be necessary. and if that should be necessary.
o Information helping to guide the selection of the appropriate * Information helping to guide the selection of the appropriate
connection type to be used when establishing a connection. connection type to be used 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 with the fls_server
field designating the server, with the location pathname within the field designating the server, with the location pathname within the
server's pseudo-fs given by the fl_rootpath field of the encompassing server's pseudo-fs given by the fl_rootpath field of the encompassing
fs_locations_item4. fs_locations_item4.
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
skipping to change at page 235, line 44 skipping to change at line 11269
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 in providing
reliable, manageable, and scalable data access. reliable, 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
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. Provision
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 and 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
skipping to change at page 237, line 25 skipping to change at line 11346
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 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 which 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 a set of server-trunkable location entries. Using the latter or 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 field returned by the
servers in question determines whether a trunking relationship servers in question determines whether a trunking relationship
skipping to change at page 240, line 35 skipping to change at line 11494
migration 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, when the attribute fs_locations_info is
used, trunking may be disallowed: used, trunking may be disallowed:
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 transition
activity required on the part of the client. In this case, any activity required on the part of the client. In this case, any
transition between access paths is transparent, and the client, in transition between access paths is transparent, and the client, in
transferring access from one to the other, is acting as it would transferring access from one to the other, is acting as it would
in the event that communication is interrupted, with a new in the event that communication is interrupted, with a new
connection and possibly a new session being established to connection and possibly a new session being established 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 [65], 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 use of a different access path to the
existing replica or by providing a path to a different replica. The existing replica or by providing a path to a different replica. The
new access path or the location of the new replica is specified by a new access path or the location of the new replica is specified by a
file system location attribute. The ensuing migration of access file system location attribute. The ensuing migration of access
includes the ability to retain locks across the transition. includes the ability to retain locks across the transition.
Depending on circumstances, this can involve: Depending on 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 individual client can be helpful in
providing load balancing, as long as the replicas in question are 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 co-
ordinated as to allow coherent simultaneous access to both by a ordinated as to allow coherent simultaneous access to both by a
single client, there is, in general, no obstacle to use of single client, there is, in general, no obstacle to use of
migration of particular clients to effect load balancing. migration of particular clients to effect load balancing.
Generally, such simultaneous use involves co-operation between Generally, such simultaneous use involves co-operation between
servers to ensure that locks granted on two co-ordinated replicas servers to ensure that locks granted on two co-ordinated replicas
cannot conflict and can remain effective when transferred to a cannot conflict and 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 are accessing a file
system in a read-only fashion, in can be helpful to migrate all system in a read-only fashion, in 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
appearing in Section 11.11.8, designed to prevent data reversion appearing in Section 11.11.8, designed to prevent data reversion
are adhered to. are adhered to.
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/coherence to function properly (e.g. the data in the
two replicas is similar but not identical), and the possibility that two replicas is similar but not identical), and the possibility that
different clients are updating different replicas can exacerbate the different clients are updating different replicas can exacerbate the
skipping to change at page 245, line 31 skipping to change at line 11732
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 the case in which a migration event occurs
subsequently, the client can choose to take note of the new subsequently, the client can choose to take note of the new
address and then use it whenever it needs to switch access to a address and then use it whenever it needs to 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 need to be acted on immediately by ceasing
use of existing access paths although new connections are not to use of existing access paths although new connections are not to
be established on addresses that have been deleted. However, be established on addresses that have been deleted. However,
clients can choose to act on such deletions by making preparations clients can choose to act on such deletions by making preparations
for an eventual shift in access which would become unavoidable as for an eventual shift in access which would become unavoidable as
soon as the server indicates that a particular network access path soon as the server indicates that a particular network access path
is not usable to access the current file system, by returning is not usable to access the current file system, by returning
NFS4ERR_MOVED. 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 a new replica to be selected.
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
skipping to change at page 247, line 10 skipping to change at line 11808
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 RFC8000 [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 which 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 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 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.
skipping to change at page 248, line 45 skipping to change at line 11888
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, filehandles, stateids, client IDs and 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 (i.e. server endpoints which are server-trunkable with one previously
being used) which are available for use. being used) which are available for use.
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 one currently in use which 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 using the new
connection and proceed to access the file system using 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 there
are valid addresses session-trunkable with the one whose use is to are valid addresses session-trunkable with the one whose use is to
be discontinued, the client can use BIND_CONN_TO_SESSION to access be discontinued, the client can use BIND_CONN_TO_SESSION to access
the existing session using the new address. Although the target the existing session using the new address. Although the target
session will generally be accessible, there may be rare situations session will generally be accessible, there may be rare situations
in which that session is no longer accessible, when an attempt is in which that session is no longer accessible, when an attempt is
made to bind the new connection to it. In this case, the client made to bind the new connection to it. In this case, the client
can create a new session to enable continued access to the can create a new session to enable continued access to the
existing instance using the new connection, providing for use of existing instance using the new connection, providing for use of
existing filehandles, stateids, and client ids while providing existing filehandles, stateids, and client ids while providing
continuity of locking state. 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 use of CREATE_SESSION is
available to provide continued access to the existing instance, 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.
skipping to change at page 250, line 36 skipping to change at line 11976
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 non-disruptive 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 servers' (source and destination) responsibilities in
effecting Transparent Migration of locking and session state are effecting Transparent 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
skipping to change at page 255, line 34 skipping to change at line 12211
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 return NFS4ERR_MOVED (i.e., the
case of migration), the client may depend on the fact that all 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
skipping to change at page 256, line 50 skipping to change at line 12274
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 which 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 file handles
will, upon reclaim, will be the same as those at open. In the will, upon reclaim, will be the same as those at open. In the
case of migration, this requires that source and destination case of migration, this requires that source and destination
servers use the same filehandles, as evidenced by using the same servers use the same filehandles, as evidenced by using the same
server scope (see Section 2.10.4) or by showing this agreement server scope (see Section 2.10.4) or by showing this agreement
using fs_locations_info (see Section 11.11.2 above). using 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 co-ordination. 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
skipping to change at page 258, line 11 skipping to change at line 12332
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:
o Since failure is not involved, there is no need store to locking * Since failure is not involved, there is no need store to 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 the ability to obtain new locks during the grace period. them 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
skipping to change at page 260, line 24 skipping to change at line 12441
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 co-operation, it is possible to:
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 [68]. 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. (DS's) 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 DS's.
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 revoking existing layouts and granting new ones on a different data
server. server.
Migration of the MDS function is directly supported by Transparent Migration of the MDS function is directly supported by Transparent
skipping to change at page 262, line 10 skipping to change at line 12524
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" to that subset of transition recovery which
applies when the file system has migrated to a different replica. 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 which a client is
to use to access a file system, there are a number of related status to 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 file handles 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 SEQUENCE operation is sent by a client to a server
which generated state held on that client which is associated with which generated state held on that client which is associated with
a file system that is no longer accessible on the server at which a file system that is no longer accessible on the server at which
it was previously available, the response will contain a lease- it was previously available, the response will contain a lease-
migrated indication, with the SEQ4_STATUS_LEASE_MOVED status bit migrated indication, with the SEQ4_STATUS_LEASE_MOVED status bit
being set. 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
skipping to change at page 263, line 30 skipping to change at line 12590
ordinate the necessary recovery actions when both indications arrive ordinate the necessary recovery actions when both indications arrive
in the response to the same request. It should be noted that when in the 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 that 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 when
accessing a file system for which transition recovery already going accessing a file system for which transition recovery already going
on, the client merely waits for that recovery to be completed while on, the client merely waits for that recovery to be completed while
the receipt of SEQ4_STATUS_LEASE_MOVED indication only needs to the receipt of SEQ4_STATUS_LEASE_MOVED indication only needs to
skipping to change at page 264, line 39 skipping to change at line 12648
exclusive, there are number of issues that are important in exclusive, 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 go on while,
o The migration discovery process is going on for that server. * The migration discovery process is going on for that server.
o The transition recovery process is going on for other file systems * The transition recovery process is going on for other file systems
connected to that server. 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 LEASE_MOVED indication if the
migration discovery process is not able to respond to the discovery migration discovery process is not able to respond to the discovery
of additional migrating file systems without additional aid. A of additional migrating file systems without additional aid. A
further complexity relevant in addressing such situations is that a further complexity relevant in addressing such situations is that a
skipping to change at page 265, line 45 skipping to change at line 12702
migration events may occur at any time, and because a LEASE_MOVED migration events may occur at any time, and because a LEASE_MOVED
indication may reflect the situation in effect a considerable time indication may reflect the situation in effect a considerable time
before the indication is received, special care needs to be taken to before the indication is received, special care needs to be taken to
ensure that LEASE_MOVED indications are not inappropriately ignored. ensure that 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 the file systems contributing
to the lease-migrated indication. 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 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 note
that it was received. Later, the existence of such indications is that it was received. Later, the existence of such indications is
used when the request completes, as described below. 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 traversed, since new migrations could have occurred while the
process was going on. 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 going on, that record is
cleared and the verification request retried. The discovery cleared and the verification request retried. The discovery
process remains in completion/verification state. process remains in 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 non-
operating state. Once it enters this state, subsequent lease- operating state. Once it enters this state, subsequent lease-
migrated indication will trigger a new migration discovery migrated indication 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 LEASE_MOVED indication. To
prevent unnecessary lease expiration, it is appropriate for clients prevent unnecessary lease expiration, it is appropriate for clients
to use the discovery of migrations to effect lease renewal to use the discovery of migrations to effect lease renewal
skipping to change at page 267, line 23 skipping to change at line 12778
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
skipping to change at page 269, line 18 skipping to change at line 12868
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 whether
it has occurred is deferred until sessions are established and the it has occurred is deferred until sessions are established and the
client is ready to begin state recovery. 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
skipping to change at page 270, line 22 skipping to change at line 12920
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 and
any failure to transport all of the stateids will be reflected in any failure to transport all of the stateids will be reflected in
the SEQ4_STATUS bits. Otherwise, Transparent State Migration has the SEQ4_STATUS bits. Otherwise, Transparent State Migration has
not occurred. 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
skipping to change at page 271, line 35 skipping to change at line 12981
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 to access 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 destination. the destination.
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,
skipping to change at page 272, line 36 skipping to change at line 13031
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 co-
operate to transfer information about locks, implementations are operate 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 type-specific information, such
as share and deny modes for opens and type and byte ranges for as share and deny modes for opens and type and byte ranges for
byte-range locks and layouts. byte-range locks and layouts.
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_COMPLTE 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 [68] 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 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 [68] 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:
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.
skipping to change at page 276, line 7 skipping to change at line 13189
processed, for many slots. 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
skipping to change at page 276, line 45 skipping to change at line 13227
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 returning
NFS4ERR_DELAY or NFS4ERR_MOVED, where the reply consists solely of NFS4ERR_DELAY or NFS4ERR_MOVED, where the reply consists solely of
a series of operations where the response is NFS4_OK until the a series of operations where the response is NFS4_OK until the
final error. final error.
Because of the considerations mentioned above including the rules for Because of the considerations mentioned above including the rules for
the handling of NFS4ERR_DELAY included in Section 15.1.1.3, the 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, since 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
skipping to change at page 278, line 19 skipping to change at line 13298
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 13361
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 13475
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 13691
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.
skipping to change at page 287, line 31 skipping to change at line 13747
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
skipping to change at page 291, line 19 skipping to change at line 13927
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 that 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 described in RFC5661 [65]), this would necessitate a new
minor version to effect any Standards Track extension to the data minor version to effect any Standards Track extension to the data
in in fls_info. in 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 RFC8178 [66] 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
RFC5661 [65] or this document. RFC5661 [65] 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.
skipping to change at page 294, line 37 skipping to change at line 14089
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 appears, a transition to a new replica rather than to a it appears, a transition to a new replica rather than to a
different path to the same replica, is indicated. different 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 35 skipping to change at line 14135
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 14166
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 14211
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 14417
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 14591
||| | ||| |
||| | ||| |
||| 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 14679
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) [55] and FCP
[56]. The block/volume protocol support can be independent of the [56]. 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 [47] 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 [57].
See [46] for a layout specification that allows pNFS to use object See [46] 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.
skipping to change at page 314, line 25 skipping to change at line 15019
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 15304
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 15567
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 15685
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 15809
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 15837
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 15912
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 16041
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]. [47], and objects layout [46].
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 16377
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 9 skipping to change at line 16527
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 7 skipping to change at line 16661
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 16736
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 16946
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 17050
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 17230
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 17299
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 17344
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 17552
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 17826
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, so that the
need to wait for this delegation to be recalled and returned makes need 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 replay cache, integration with the session-provided replay
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 on the basis of its presence in the replay cache.
If the replier did this, the retries would not be effective as If the replier did this, the retries would not be effective as
there would be no opportunity for the replier to see whether the 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, which validly appears as the first operation of a request,
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 replay cache. If the replier did this, the
retries would not be effective as there would be no opportunity retries would not be effective as there would be no opportunity
for the replier to see whether the condition that generated the for 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 which is different than the original one, with either
the bin id or the sequence value different from that in the the bin id or the sequence value different from that in the
original request. Because requesters do this, there is no need original request. Because requesters do this, there is no need
for the replier to take special care to avoid returning an for the replier to take special care to avoid returning an
NFS4ERR_DELAY error, obtained from the replay cache. When no non- NFS4ERR_DELAY error, obtained from the replay cache. When no non-
idempotent operations have been processed before the NFS4ERR_DELAY idempotent operations have been processed before the NFS4ERR_DELAY
was returned, the requester should retry the request in full, with was returned, the requester should retry the request in full, with
the only difference from the original request being the the only difference from the original request being the
modification to the slot id or sequence value in the reissued modification to the slot id or sequence value in the reissued
SEQUENCE operation. SEQUENCE 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-
skipping to change at page 378, line 40 skipping to change at line 18170
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 18309
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 383, line 4 skipping to change at line 18364
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
skipping to change at page 389, line 10 skipping to change at line 18652
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 18700
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 20070
| | 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 20787
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 20845
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 20882
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 20988
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 21246
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 [59] states that an
implementation claiming conformance to UNIX may indicate in the implementation claiming conformance to UNIX may indicate in the
skipping to change at page 441, line 14 skipping to change at line 21273
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 21313
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 454, line 17 skipping to change at line 21874
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 22126
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 22159
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 479, line 5 skipping to change at line 22963
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 7 skipping to change at line 23031
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 23198
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 23266
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 23369
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 23476
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 493, line 16 skipping to change at line 23624
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 505, line 38 skipping to change at line 24174
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 24359
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 24576
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 24619
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 24910
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 529, line 5 skipping to change at line 25228
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 if necessary. This client ID becomes associated with the one if necessary. This client ID becomes associated with the
skipping to change at page 533, line 27 skipping to change at line 25432
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 [51]).
+ 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 [51]).
* 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 31 skipping to change at line 25629
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 25756
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 25796
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 that the EXCHANGE_ID operation was sent as a part of.
+-------------------+----------------------+------------------------+ +----------------------+---------------------------+---------------+
| 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 11 skipping to change at line 25846
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 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 25932
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 26172
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 26239
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_fore_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 44 skipping to change at line 26308
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 RFC2203 [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
skipping to change at page 555, line 13 skipping to change at line 26413
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 26562
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 26621
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 26962
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 26987
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 575, line 8 skipping to change at line 27298
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 27449
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 27564
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 28180
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 598, line 27 skipping to change at line 28367
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 28464
}; };
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 28598
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 607, line 5 skipping to change at line 28730
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, implementers need to be
aware of the following considerations as they make necessary aware of the following considerations as they make necessary
tradeoffs between interoperability with existing implementations and tradeoffs 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 28958
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 630, line 25 skipping to change at line 29767
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 30071
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.
skipping to change at page 638, line 20 skipping to change at line 30113
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 taken
note of: 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] can also be relied upon to provide valid address resolutions. [34] can also 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 host names 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 host names, that would interfere with its ability to
use RPCSEC_GSS. use 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 host
name. This would allow the client to interrogate the fs_locations on name. This would allow the client to interrogate the fs_locations on
the destination server to obtain trunking information (as well as the destination server to obtain trunking information (as well as
replica information) using integrity protection, validating the name replica information) using integrity protection, validating the name
provided while assuring that the response has not been modified in provided while assuring that the response has not been modified in
flight. flight.
skipping to change at page 640, line 7 skipping to change at line 30195
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 AUTH_SYS
which has no provision to avoid modification of data in flight), which has no provision to avoid modification of data in flight),
while undesirable and a potential security exposure, may not be while undesirable and a potential security exposure, may not be
avoidable in all cases. Where the use of the returned information avoidable in all cases. Where the use of the returned information
cannot be avoided, it is made subject to filtering as described cannot be avoided, it is made subject to filtering as described
above to eliminate the possibility that the client would treat an above to eliminate the possibility that the client would treat an
invalid address as if it were a NFSv4 server. The specifics will invalid address as if it were a NFSv4 server. The specifics will
vary depending on the degree of network isolation and whether the vary depending on the degree of network isolation and whether the
request is to the referring or destination servers. 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
skipping to change at page 641, line 41 skipping to change at line 30273
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.1 of [62]. The policy for each assignment is
Specification Required, per Section 4.1 of [62]. Specification Required, per Section 4.1 of [62].
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 643, line 11 skipping to change at line 30340
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 | | | | 5661 | | |
+-------------------------+-------+---------+-----+----------------+ +-------------------------+-------+----------+-----+----------------+
| NOTIFY_DEVICEID4_DELETE | 2 | RFC | N | 1 |
| | | 5661 | | |
+-------------------------+-------+----------+-----+----------------+
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".
skipping to change at page 644, line 39 skipping to change at line 30415
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 | | | | | | 5661 | | |
| 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 | | | | 5661 | | |
| | | 5661 | | | +-------------------------------+-------+------+-----+----------+
| RCA4_TYPE_MASK_FILE_LAYOUT | 3 | RFC | N | 1 | | RCA4_TYPE_MASK_DIR_DLG | 2 | RFC | N | 1 |
| | | 5661 | | | | | | 5661 | | |
| 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 | | | | 5661 | | |
| | | 5661 | | | +-------------------------------+-------+------+-----+----------+
| RCA4_TYPE_MASK_OBJ_LAYOUT_MAX | 9 | RFC | L | 1 | | RCA4_TYPE_MASK_BLK_LAYOUT | 4 | RFC | L | 1 |
| | | 5661 | | | | | | 5661 | | |
+-------------------------------+-------+--------+-----+------------+ +-------------------------------+-------+------+-----+----------+
| RCA4_TYPE_MASK_OBJ_LAYOUT_MIN | 8 | RFC | L | 1 |
| | | 5661 | | |
+-------------------------------+-------+------+-----+----------+
| RCA4_TYPE_MASK_OBJ_LAYOUT_MAX | 9 | RFC | L | 1 |
| | | 5661 | | |
+-------------------------------+-------+------+-----+----------+
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 30498
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 30522
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 5661 | 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?
skipping to change at page 650, line 7 skipping to change at line 30670
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 5661 | IESG | | ${ietf.org:CPU_ARCH} | RFC 5661 | IESG |
+------------------------+----------+------------------+
| ${ietf.org:OS_TYPE} | RFC 5661 | IESG | | ${ietf.org:OS_TYPE} | RFC 5661 | IESG |
+------------------------+----------+------------------+
| ${ietf.org:OS_VERSION} | RFC 5661 | IESG | | ${ietf.org:OS_VERSION} | RFC 5661 | 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 30768
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. (www.opengroup.org), ISBN 1931624232", 2004.
[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. (www.opengroup.org), ISBN 1931624232", 2004.
[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 (www.opengroup.org),
ISBN 1931624232", 2004. ISBN 1931624232", 2004.
[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 (www.opengroup.org),
ISBN 1931624232", 2004. ISBN 1931624232", 2004.
[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 (www.opengroup.org),
ISBN 1931624232", 2004. ISBN 1931624232", 2004.
[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 (www.opengroup.org),
ISBN 1931624232", 2004. ISBN 1931624232", 2004.
[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 (www.opengroup.org),
ISBN 1931624232", 2004. ISBN 1931624232", 2004.
[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 (www.opengroup.org),
ISBN 1931624232", 2004. ISBN 1931624232", 2004.
skipping to change at page 654, line 24 skipping to change at line 30888
[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 (www.opengroup.org),
ISBN 1931624232", 2004. ISBN 1931624232", 2004.
[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,
"Cryptographic Algorithm Object Registration", URL "Cryptographic Algorithm Object Registration", URL
http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/ http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/
algorithms.html, November 2007. algorithms.html, November 2007.
[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>.
skipping to change at page 655, line 27 skipping to change at line 30937
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>.
23.2. Informative References 23.2. Informative References
[35] Roach, A., "Process for Handling Non-Major Revisions to [35] 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., [36] 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 [37] 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 [38] 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 [39] 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 [40] 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 [41] 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", [42] 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 [43] Werme, R., "RPC XID Issues", USENIX Conference
Proceedings , February 1996. Proceedings , February 1996.
[44] Nowicki, B., "NFS: Network File System Protocol [44] 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 [45] 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 [46] 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 [47] 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, [48] 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, [49] 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", [50] IESG, "IESG Processing of RFC Errata for the IETF Stream",
July 2008. July 2008, <http://www.ietf.org/IESG/STATEMENTS/iesg-
statement-07-30-2008.txt>.
[51] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [51] 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", [52] 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 [53] 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 [54] 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., [55] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
and E. Zeidner, "Internet Small Computer Systems Interface and E. Zeidner, "Internet Small Computer Systems Interface
(iSCSI)", RFC 3720, April 2004. (iSCSI)", RFC 3720, DOI 10.17487/RFC3720, April 2004,
<https://www.rfc-editor.org/info/rfc3720>.
[56] Snively, R., "Fibre Channel Protocol for SCSI, 2nd Version [56] 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)", [57] 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>. <http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf>.
[58] Carns, P., Ligon III, W., Ross, R., and R. Thakur, "PVFS: [58] 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 [59] 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.
[60] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [60] 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 [61] 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 [62] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[63] Eisler, M., "Errata 2006 for RFC 5661", January 2010, [63] Eisler, M., "Errata 2006 for RFC 5661", January 2010,
<https://www.rfc-editor.org/errata_search.php?eid=2006>. <https://www.rfc-editor.org/errata_search.php?eid=2006>.
[64] Spasojevic, M. and M. Satayanarayanan, "An Empirical Study [64] Spasojevic, M. and M. Satayanarayanan, "An Empirical Study
of a Wide-Area Distributed File System", May 1996, of a Wide-Area Distributed File System", May 1996,
<https://www.cs.cmu.edu/~satya/docdir/spasojevic-tocs-afs- <https://www.cs.cmu.edu/~satya/docdir/spasojevic-tocs-afs-
measurement-1996.pdf>. measurement-1996.pdf>.
[65] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [65] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
skipping to change at page 659, line 21 skipping to change at line 31110
are to be dealt with, and how transfers of responsibility that need are to be dealt with, and how transfers of responsibility that need
to be made can be dealt with transparently. This includes cases in to be made can be dealt with transparently. This includes cases in
which there is a shift between one replica and another and those in which there is a shift between one replica and another and those in
which different network access paths are used to access the same which 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 RFC5661 [65], it is
necessary to provide the specific updates which are made by this necessary to provide the specific updates which 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 * RFC5661 [65], while it dealt with situations in which various
forms of clustering allowed co-ordination of the state assigned by forms of clustering allowed co-ordination of the state assigned by
co-operating servers to be used, made no provisions for co-operating servers to be used, made no provisions for
Transparent State Migration. Within NFSv4.0, Transparent Transparent State Migration. Within NFSv4.0, Transparent
Migration was first explained clearly in RFC7530 [67] and Migration was first explained clearly in RFC7530 [67] and
corrected and clarified by RFC7931 [68]. No corresponding corrected and clarified by RFC7931 [68]. No corresponding
explanation for NFSv4.1 had been provided. explanation for NFSv4.1 had been provided.
o Although NFSv4.1 was defined with a clear definition of how * Although NFSv4.1 was defined with a clear definition of how
trunking detection was to be done, there was no clear trunking detection was to be done, there was no clear
specification of how trunking discovery was to be done, despite specification of how trunking discovery was to be done, despite
the fact that the specification clearly indicated that this the fact that the specification clearly indicated that this
information could be made available via the file system location information could be 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 features
was not seriously addressed. 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 were
involved, it was considered that two replicas were being used 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 RFC5661 [65] was not clear as it covered the two
distinct cases of a single file system instance being accessed by distinct cases of a single file system instance being accessed by
two different network access paths and two replicas being accessed two different network access paths and two replicas being accessed
simultaneously, with the limitations of the latter case not being simultaneously, with the limitations of the latter case not being
clearly laid out. 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 [65]. This replacement modifies existing sub-sections 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 are deleted. These changes were made in order to:
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 needs to be distinguished
clearly from the case of two different replicas since, in the clearly from the case of two different replicas since, in the
former case, locking state is shared and there also can be sharing former case, locking state is shared and there also can be sharing
of session state. of session 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 that or a single-fs grace period be
provided. provided.
o Specifically delineate how such transfers are to be dealt with by * Specifically delineate how such transfers are to be dealt with by
the client, taking into account the differences from the treatment the client, taking into account the differences from the treatment
in [68] made necessary by the major protocol changes made in in [68] made necessary by the major protocol changes made in
NFSv4.1. NFSv4.1.
o Provide discussion of the relationship between transparent state * Provide discussion of the relationship between transparent state
transfer and Parallel NFS (pNFS). transfer and Parallel NFS (pNFS).
o Provide clarification of the fs_locations_info attribute in order * Provide clarification of the fs_locations_info attribute in order
to specify which portions of the information provided apply to a to specify which portions of the information provided apply to a
specific network access path and which to the replica which that specific network access path and which to the replica which that
path is used to access. path is used to access.
In addition, there are also updates to other sections of RFC5661 In addition, there are also updates to other sections of RFC5661
[65], where the consequences of the incorrect assumptions underlying [65], where the consequences of the incorrect assumptions underlying
the current treatment of multi-server namespace issues also needed to the current treatment of multi-server namespace issues also needed to
be corrected. These are to be dealt with as described in Sections be corrected. These are to be dealt with as described in 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, which
reflects the more limited co-ordination of locking state adopted reflects the more limited co-ordination of locking state adopted
by servers actually sharing a common server scope. 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 errors 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 RFC5661
A number of areas needed to be revised or extended, in many case A number of areas needed to be revised or extended, in many case
replacing existing sub-sections within section 11 of RFC5661 [65]: replacing existing sub-sections within Section 11 of RFC 5661 [65]:
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 existing material in RFC5661 [65] ranging from the
start of the existing Section 11 up to and including the existing start of the existing Section 11 up to and including the existing
Section 11.1. The new material starts at the beginning of Section 11.1. The new material starts at the beginning of
Section 11 and continues through 11.2 below. Section 11 and continues through 11.2 below.
o A significant reorganization of the material in the existing * A significant reorganization of the material in the existing
Sections 11.4 and 11.5 (of RFC5661 [65]) is necessary. The Sections 11.4 and 11.5 of RFC 5661 [65]) is necessary. The
reasons for the reorganization of these sections into a single reasons for the reorganization of these sections into a single
section with multiple subsections are discussed in Appendix B.1.1 section with multiple subsections are discussed in Appendix B.1.1
below. This replacement appears as Section 11.5 below. below. This replacement appears as Section 11.5 below.
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 below.
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 the existing Section 11.7 of RFC 5661 [65]
entitled "Effecting File System Transitions", will appear as entitled "Effecting File System Transitions", will appear as
Sections 11.9 through 11.14. The reasons for the reorganization Sections 11.9 through 11.14. The reasons for the reorganization
of this section into multiple sections are discussed in of this section 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 the existing Section 11.10 of RFC 5661 [65]
entitled "The Attribute fs_locations_info", will appear as entitled "The Attribute fs_locations_info", will appear as
Section 11.17, with Appendix B.1.3 describing the differences Section 11.17, with Appendix B.1.3 describing the differences
between the new section and the treatment within [65]. A revised between the new section and the treatment within [65]. A revised
treatment is necessary because the existing treatment did not make treatment is necessary because the existing treatment did not make
clear how the added attribute information relates to the case of clear how the added attribute information relates to the case of
trunked paths to the same replica. These issues were not trunked paths to the same replica. These issues were not
addressed in RFC5661 [65] where the concepts of a replica and a addressed in RFC5661 [65] where the concepts of a replica and a
network path used to access a replica were not clearly network path used to access a replica were not clearly
distinguished. distinguished.
B.1.1. Re-organization of Sections 11.4 and 11.5 of RFC5661 B.1.1. Re-organization of Sections 11.4 and 11.5 of RFC5661
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 a separate Section 11.5 of RFC 5661 [65]. Because of the new
treatment of trunking, these issues now belong within Section 11.5 treatment of trunking, these issues now belong within Section 11.5
below. below.
In this new section, trunking is dealt with in Section 11.5.2 In this new section, trunking is dealt with in Section 11.5.2
together with the other uses of file system location information together with the other uses of file system location information
described in Sections Section 11.5.3 through 11.5.6. described in 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 will replace Section 11.4 of RFC 5661
[65] is substantially different than the section it replaces in that [65] is substantially different than the section it replaces in that
some existing sections will be replaced by corresponding sections some existing sections will be replaced by corresponding sections
below while, at the same time, new sections will be added, resulting below while, at the same time, new sections will be added, resulting
in a replacement containing some renumbered sections, as follows: 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 [65] exclusive of
subsections. subsections.
o Section 11.5.1 is a new first subsection of the overall section. * Section 11.5.1 is a 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 a 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 [65]. 11.4.4, and 11.4.5.
o Section 11.5.7 is a new final subsection of the overall section. * Section 11.5.7 is a new final subsection of the overall section.
B.1.2. Re-organization of Material Dealing with File System Transitions B.1.2. Re-organization 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 [65] 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, a 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 former Section 11.7 of RFC 5661
[65]) is extensively modified as reflected in Section 11.11 which [65] is extensively modified as reflected in Section 11.11 which
is now limited to cases in which there is a shift between two is now limited to cases in which there is a shift between two
different sets of replicas. 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 and 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 re-organization has caused a renumbering of the sections within
Section 11 of [65] as described below: Section 11 of [65] 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 existing sections
with these numbers to be renumbered. with these numbers to be renumbered.
o Section 11.7 of [65] will be substantially modified and appear as * Section 11.7 of [65] will be substantially modified and appear as
Section 11.11. The necessary modifications reflect the fact that Section 11.11. The necessary modifications reflect the fact that
this section will only deal with transitions between replicas this section will only deal 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. * The additional 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 [65] now
appear as Sections 11.13, 11.14, 11.15, and 11.16, respectively. appear as Sections 11.13, 11.14, 11.15, and 11.16, respectively.
As part of this general re-organization, Section 11.7 of RFC5661 [65] As part of this general re-organization, Section 11.7 of RFC 5661
will be modified as described below: [65] will be 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 [65] are to be 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) are to be
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, [65] are to be 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 [65] is to be replaced by
Section 11.11.9 This sub-section has been moved to the end of the Section 11.11.9 This sub-section 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 [65] are to be
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 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 existing treatment of fs_locations info (Section 11.10
Section 11.10 of RFC5661 [65]) does not clearly distinguish these of RFC 5661 [65]) does 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 needed to be provided with regard
to the following fields: to 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 needs to be made
clear that this only applies to the unavailability of a replica clear that this only applies to the unavailability of a replica
rather than to a path to access a replica. rather 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 needs to be made clear that there is no need for
the client to frequently fetch the fs_locations_info value to be the 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 needs to
be provided. The existing treatment reflects the extension model be provided. The existing treatment reflects the extension model
in effect at the time RFC5661 [65] was written, and needed to be in effect at the time RFC5661 [65] was written, and needed to be
updated in accordance with the extension model described in updated in accordance with the extension model described in
RFC8178 [66]. RFC8178 [66].
B.2. Revisions Made to Operations in RFC5661 B.2. Revisions Made to Operations in RFC5661
Revised descriptions were needed to address issues that arose in Revised descriptions were needed 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 existing treatment of EXCHANGE_ID (Section 13.35 of RFC 5661
[65]) assumes that client IDs cannot be created/ confirmed other [65]) assumes that client IDs cannot be created/ confirmed other
than by the EXCHANGE_ID and CREATE_SESSION operations. Also, the than by 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 is not addressed clearly. A revised treatment
of EXCHANGE_ID is necessary and it appears in Section 18.35 while of EXCHANGE_ID is necessary and it appears in Section 18.35 while
the specific differences between it and the treatment within [65] the specific differences between it and the treatment within [65]
are explained in Appendix B.2.1 below. are explained in Appendix B.2.1 below.
o The existing treatment of RECLAIM_COMPLETE in section 18.51 of * The existing treatment of RECLAIM_COMPLETE in Section 18.51 of RFC
RFC5661 [65]) is not sufficiently clear about the purpose and use 5661 [65]) is not sufficiently clear about the purpose and use of
of the rca_one_fs and how the server is to deal with inappropriate the rca_one_fs and how the server is to deal with inappropriate
values of this argument. Because the resulting confusion raises values of this argument. Because the resulting confusion raises
interoperability issues, a new treatment of RECLAIM_COMPLETE is interoperability issues, a new treatment of RECLAIM_COMPLETE is
necessary and it appears in Section 18.51 below while the specific necessary and it appears in Section 18.51 below while the specific
differences between it and the treatment within RFC5661 [65] are differences between it and the treatment within RFC5661 [65] 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 receive an updated treatment in
Section 15.1.9 to reflect the fact that there are multiple 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 to Treatment of EXCHANGE_ID
There are a number of issues in the original treatment of EXCHANGE_ID There are a number of issues in the original treatment of EXCHANGE_ID
(in RFC5661 [65]) that cause problems for Transparent State Migration (in RFC5661 [65]) that cause 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 arise 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 * It had been assumed that an EXCHANGED_ID executed when the server
is already aware of a given client instance must be either is already aware of a given client instance must be either
updating associated parameters (e.g. with respect to callbacks) or updating associated parameters (e.g. with respect to callbacks) or
a lingering retransmission to deal with a previously lost reply. a lingering retransmission to deal with a previously lost reply.
As result, any slot sequence returned by that operation would be 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 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]. "MUST NOT" be used, although this usage is not in accord with [1].
This created a difficulty when an EXCHANGE_ID is done after This created a difficulty when an EXCHANGE_ID is done after
Transparent State Migration since that slot sequence would need to Transparent State Migration since that slot sequence would need to
be used in a subsequent CREATE_SESSION. 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 was 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, create the client ID, and
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_SESSSION, whose parameters do not include an explicit
client ID. client 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 [65].
B.2.2. Revision to Treatment of RECLAIM_COMPLETE B.2.2. Revision to 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 RFC5661 [65] 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 is 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 that result from
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 RFC5661
The new handling of various situations required revisions of some The new handling of various situations required revisions of some
existing error definition: existing error definition:
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 RFC5661 [65] have
become problematic since a shift in network access paths was become problematic since a shift in network access paths was
considered to be a shift to a different replica. As a result, the considered to be a shift to a different replica. As a result, the
existing definition of NFS4ERR_MOVED (in Section 15.1.2.4 of existing definition of NFS4ERR_MOVED (in Section 15.1.2.4 of RFC
RFC5661 [65]) needs to be updated to reflect the different 5661 [65]) needs to be updated to reflect the different handling
handling of unavailability of a particular fs via a specific of unavailability of a particular fs via a specific network
network address. 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 needs to
change even though the set of circumstances in which it is to be change even though the set of circumstances in which it is to be
returned remain the same. The new paragraph explicitly recognizes returned remain the same. The new paragraph explicitly recognizes
that a different network address might be used, while the previous that a different network address might be used, while the previous
description, misleadingly, treated this as a shift between two description, misleadingly, treated this as a shift between two
replicas while only a single file system instance might be replicas while only a single file system instance might be
involved. The updated description appears in Section 15.1.2.4 involved. The updated description appears in Section 15.1.2.4
below. below.
o Because of the need to accommodate use of fs-specific grace * Because of the need to accommodate use of fs-specific grace
periods, it is necessary to clarify some of the error definitions periods, it is necessary to clarify some of the error definitions
of reclaim-related errors in Section 15 of RFC5661 [65], so the of reclaim-related errors in Section 15 of RFC 5661 [65], so 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 below.
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 [63] 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 replay 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 RFC5661 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 RFC5661
Beside the major reworking of Section 11 and the associated revisions Beside the major reworking of Section 11 of RFC 5661 [65] and the
to existing operations and errors, there are a number of related associated revisions to existing operations and errors, there are a
changes that are necessary: number of related changes that are necessary:
o The summary that appeared in Section 1.7.3.3 of RFC5661 [65] was * The summary that appeared in Section 1.7.3.3 of RFC 5661 [65] was
revised to reflect the changes made in the revised Section 11 revised to reflect the changes made in the revised Section 11
above. The updated summary appears as Section 1.8.3.3 above. above. The updated summary 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 which appeared in Section 2.10.4 of
RFC5661 [65] needed to be replaced, since the previous text RFC 5661 [65] needed to be replaced, since the previous text
appears to require a level of inter-server co-ordination appears to require a level of inter-server co-ordination
incompatible with its basic function of avoiding the need for a incompatible with its basic function of avoiding the need for a
globally uniform means of assigning server_owner values. A globally uniform means of assigning server_owner 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 which appeared in Section 2.10.5 of RFC
RFC5661 [65] needed to be revised, to more clearly explain the 5661 [65] needed to be revised, to more clearly explain the
multiple types of trunking support and how the client can be made multiple types of trunking support and how the client can be made
aware of the existing trunking configuration. In addition, while aware of the existing trunking configuration. In addition, while
the last paragraph (exclusive of sub-sections) of that section, the last paragraph (exclusive of sub-sections) of that section,
dealing with server_owner changes, is literally true, it has been dealing with server_owner changes, is literally true, it has been
a source of confusion. Since the existing paragraph can be read a source of confusion. Since the existing paragraph can be read
as suggesting that such changes be dealt with non-disruptively, as suggesting that such changes be dealt with non-disruptively,
the issue needs to be clarified in the revised section, which the issue needs to be clarified in the revised section, which
appears in 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 RFC5661 [65] is not written
in accord with RFC3552 [71] (also BCP72). Of particular concern in accord with RFC3552 [71] (also BCP72). Of particular concern
is the fact that the section does not contain a threat analysis. is the fact that the section does 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 (in Section 21)
has not been thoroughly revised to correct the difficulties mentioned has 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 needs 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 security problems created by continued use of AUTH_SYS simply the security problems created by continued use of AUTH_SYS simply
by revising this designation. by 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 RFC7258
[70] (also BCP188). [70] (also BCP188).
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 RFC7258, 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 which 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 in 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, with the provision
of sufficient resources, address the problem. Instead, what is of sufficient resources, address the problem. 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 that 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 is
likely to find itself dealing with a number of considerations such as likely to find itself dealing with a number of considerations such as
the following: the following:
o The need to accommodate existing deployments of existing protocols * The need to accommodate existing deployments of existing protocols
as specified previously in existing Proposed Standards. as 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 difficulties mentioned above 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 applying 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.
skipping to change at page 670, line 34 skipping to change at line 31650
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 RFC5661
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 39 skipping to change at line 31701
ordination and management of the process of editing the specification ordination and management of the process of editing the specification
documents. 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 31756
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. 1448 change blocks. 
3132 lines changed or deleted 3662 lines changed or added

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