draft-ietf-nfsv4-rfc3530bis-08.txt | draft-ietf-nfsv4-rfc3530bis-09.txt | |||
---|---|---|---|---|
NFSv4 T. Haynes | NFSv4 T. Haynes, Ed. | |||
Internet-Draft D. Noveck | Internet-Draft NetApp | |||
Intended status: Standards Track Editors | Intended status: Standards Track D. Noveck, Ed. | |||
Expires: September 5, 2011 March 04, 2011 | Expires: September 14, 2011 EMC | |||
March 13, 2011 | ||||
NFS Version 4 Protocol | Network File System (NFS) Version 4 Protocol | |||
draft-ietf-nfsv4-rfc3530bis-08.txt | draft-ietf-nfsv4-rfc3530bis-09.txt | |||
Abstract | Abstract | |||
The Network File System (NFS) version 4 is a distributed filesystem | The Network File System (NFS) version 4 is a distributed filesystem | |||
protocol which owes heritage to NFS protocol version 2, RFC 1094, and | protocol which owes heritage to NFS protocol version 2, RFC 1094, and | |||
version 3, RFC 1813. Unlike earlier versions, the NFS version 4 | version 3, RFC 1813. Unlike earlier versions, the NFS version 4 | |||
protocol supports traditional file access while integrating support | protocol supports traditional file access while integrating support | |||
for file locking and the mount protocol. In addition, support for | for file locking and the mount protocol. In addition, support for | |||
strong security (and its negotiation), compound operations, client | strong security (and its negotiation), compound operations, client | |||
caching, and internationalization have been added. Of course, | caching, and internationalization have been added. Of course, | |||
skipping to change at page 2, line 8 | skipping to change at page 2, line 8 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on September 5, 2011. | This Internet-Draft will expire on September 14, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 27 | skipping to change at page 3, line 27 | |||
1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 14 | 1.5.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 14 | |||
1.5.5. File Locking . . . . . . . . . . . . . . . . . . . . 14 | 1.5.5. File Locking . . . . . . . . . . . . . . . . . . . . 14 | |||
1.5.6. Client Caching and Delegation . . . . . . . . . . . 14 | 1.5.6. Client Caching and Delegation . . . . . . . . . . . 14 | |||
1.6. General Definitions . . . . . . . . . . . . . . . . . . 15 | 1.6. General Definitions . . . . . . . . . . . . . . . . . . 15 | |||
2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 17 | 2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 17 | |||
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 17 | 2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 17 | |||
2.2. Structured Data Types . . . . . . . . . . . . . . . . . 19 | 2.2. Structured Data Types . . . . . . . . . . . . . . . . . 19 | |||
3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 24 | 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 24 | |||
3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 24 | 3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 24 | |||
3.1.1. Client Retransmission Behavior . . . . . . . . . . . 25 | 3.1.1. Client Retransmission Behavior . . . . . . . . . . . 25 | |||
3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 25 | 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 26 | |||
3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 26 | 3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 26 | |||
3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 28 | 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 28 | |||
3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 28 | 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 29 | |||
3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 28 | 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 29 | |||
3.3.3. Callback RPC Authentication . . . . . . . . . . . . 29 | 3.3.3. Callback RPC Authentication . . . . . . . . . . . . 29 | |||
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 31 | 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 31 | |||
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 31 | 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 32 | |||
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 31 | 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 32 | |||
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 32 | 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 32 | |||
4.2.1. General Properties of a Filehandle . . . . . . . . . 32 | 4.2.1. General Properties of a Filehandle . . . . . . . . . 33 | |||
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 33 | 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 33 | |||
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 33 | 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 34 | |||
4.2.4. One Method of Constructing a Volatile Filehandle . . 35 | 4.2.4. One Method of Constructing a Volatile Filehandle . . 35 | |||
4.3. Client Recovery from Filehandle Expiration . . . . . . . 35 | 4.3. Client Recovery from Filehandle Expiration . . . . . . . 35 | |||
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 36 | 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 37 | 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 37 | |||
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 37 | 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 38 | |||
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 38 | 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 38 | |||
5.4. Classification of Attributes . . . . . . . . . . . . . . 39 | 5.4. Classification of Attributes . . . . . . . . . . . . . . 40 | |||
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 40 | 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 40 | |||
5.6. REQUIRED Attributes - List and Definition References . . 40 | 5.6. REQUIRED Attributes - List and Definition References . . 41 | |||
5.7. RECOMMENDED Attributes - List and Definition | 5.7. RECOMMENDED Attributes - List and Definition | |||
References . . . . . . . . . . . . . . . . . . . . . . . 41 | References . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 42 | 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 43 | |||
5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 42 | 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 43 | |||
5.8.2. Definitions of Uncategorized RECOMMENDED | 5.8.2. Definitions of Uncategorized RECOMMENDED | |||
Attributes . . . . . . . . . . . . . . . . . . . . . 44 | Attributes . . . . . . . . . . . . . . . . . . . . . 45 | |||
5.9. Interpreting owner and owner_group . . . . . . . . . . . 50 | 5.9. Interpreting owner and owner_group . . . . . . . . . . . 51 | |||
5.10. Character Case Attributes . . . . . . . . . . . . . . . 53 | 5.10. Character Case Attributes . . . . . . . . . . . . . . . 54 | |||
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 53 | 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 54 | |||
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 54 | 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 54 | 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 55 | |||
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 54 | 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 55 | |||
6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 68 | 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 69 | |||
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 69 | 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 70 | |||
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 69 | 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 70 | |||
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 70 | 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 71 | |||
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 71 | 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 72 | |||
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 72 | 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 72 | |||
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 73 | 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 74 | |||
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 73 | 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 74 | |||
7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 75 | 7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 76 | |||
7.1. Location Attributes . . . . . . . . . . . . . . . . . . 75 | 7.1. Location Attributes . . . . . . . . . . . . . . . . . . 76 | |||
7.2. File System Presence or Absence . . . . . . . . . . . . 76 | 7.2. File System Presence or Absence . . . . . . . . . . . . 76 | |||
7.3. Getting Attributes for an Absent File System . . . . . . 77 | 7.3. Getting Attributes for an Absent File System . . . . . . 77 | |||
7.3.1. GETATTR Within an Absent File System . . . . . . . . 77 | 7.3.1. GETATTR Within an Absent File System . . . . . . . . 78 | |||
7.3.2. READDIR and Absent File Systems . . . . . . . . . . 78 | 7.3.2. READDIR and Absent File Systems . . . . . . . . . . 79 | |||
7.4. Uses of Location Information . . . . . . . . . . . . . . 78 | 7.4. Uses of Location Information . . . . . . . . . . . . . . 79 | |||
7.4.1. File System Replication . . . . . . . . . . . . . . 79 | 7.4.1. File System Replication . . . . . . . . . . . . . . 80 | |||
7.4.2. File System Migration . . . . . . . . . . . . . . . 80 | 7.4.2. File System Migration . . . . . . . . . . . . . . . 81 | |||
7.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 81 | 7.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 81 | |||
7.5. Location Entries and Server Identity . . . . . . . . . . 81 | 7.5. Location Entries and Server Identity . . . . . . . . . . 82 | |||
7.6. Additional Client-Side Considerations . . . . . . . . . 82 | 7.6. Additional Client-Side Considerations . . . . . . . . . 83 | |||
7.7. Effecting File System Transitions . . . . . . . . . . . 83 | 7.7. Effecting File System Transitions . . . . . . . . . . . 84 | |||
7.7.1. File System Transitions and Simultaneous Access . . 84 | 7.7.1. File System Transitions and Simultaneous Access . . 85 | |||
7.7.2. Filehandles and File System Transitions . . . . . . 84 | 7.7.2. Filehandles and File System Transitions . . . . . . 85 | |||
7.7.3. Fileids and File System Transitions . . . . . . . . 85 | 7.7.3. Fileids and File System Transitions . . . . . . . . 86 | |||
7.7.4. Fsids and File System Transitions . . . . . . . . . 86 | 7.7.4. Fsids and File System Transitions . . . . . . . . . 87 | |||
7.7.5. The Change Attribute and File System Transitions . . 86 | 7.7.5. The Change Attribute and File System Transitions . . 87 | |||
7.7.6. Lock State and File System Transitions . . . . . . . 87 | 7.7.6. Lock State and File System Transitions . . . . . . . 88 | |||
7.7.7. Write Verifiers and File System Transitions . . . . 89 | 7.7.7. Write Verifiers and File System Transitions . . . . 90 | |||
7.7.8. Readdir Cookies and Verifiers and File System | 7.7.8. Readdir Cookies and Verifiers and File System | |||
Transitions . . . . . . . . . . . . . . . . . . . . 89 | Transitions . . . . . . . . . . . . . . . . . . . . 90 | |||
7.7.9. File System Data and File System Transitions . . . . 90 | 7.7.9. File System Data and File System Transitions . . . . 90 | |||
7.8. Effecting File System Referrals . . . . . . . . . . . . 91 | 7.8. Effecting File System Referrals . . . . . . . . . . . . 92 | |||
7.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 91 | 7.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 92 | |||
7.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 95 | 7.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 96 | |||
7.9. The Attribute fs_locations . . . . . . . . . . . . . . . 98 | 7.9. The Attribute fs_locations . . . . . . . . . . . . . . . 98 | |||
7.9.1. Inferring Transition Modes . . . . . . . . . . . . . 99 | 7.9.1. Inferring Transition Modes . . . . . . . . . . . . . 100 | |||
8. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 101 | 8. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 101 | |||
8.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 101 | 8.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 102 | |||
8.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 101 | 8.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 102 | |||
8.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 101 | 8.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 102 | |||
8.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 102 | 8.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 103 | |||
8.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 102 | 8.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 103 | |||
8.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 102 | 8.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 103 | |||
8.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 103 | 8.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 104 | |||
8.8. Security Policy and Name Space Presentation . . . . . . 103 | 8.8. Security Policy and Name Space Presentation . . . . . . 104 | |||
9. File Locking and Share Reservations . . . . . . . . . . . . . 104 | 9. File Locking and Share Reservations . . . . . . . . . . . . . 105 | |||
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 105 | 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 106 | |||
9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 105 | 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 106 | |||
9.1.2. Server Release of Client ID . . . . . . . . . . . . 108 | 9.1.2. Server Release of Client ID . . . . . . . . . . . . 109 | |||
9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 109 | 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 110 | |||
9.1.4. lock_owner . . . . . . . . . . . . . . . . . . . . . 117 | 9.1.4. lock_owner . . . . . . . . . . . . . . . . . . . . . 117 | |||
9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 117 | 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 118 | |||
9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 119 | 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 120 | |||
9.1.7. Recovery from Replayed Requests . . . . . . . . . . 120 | 9.1.7. Recovery from Replayed Requests . . . . . . . . . . 121 | |||
9.1.8. Releasing lock_owner State . . . . . . . . . . . . . 121 | 9.1.8. Releasing lock_owner State . . . . . . . . . . . . . 121 | |||
9.1.9. Use of Open Confirmation . . . . . . . . . . . . . . 121 | 9.1.9. Use of Open Confirmation . . . . . . . . . . . . . . 122 | |||
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 122 | 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 123 | |||
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 123 | 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 123 | |||
9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 123 | 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 124 | |||
9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 124 | 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 125 | |||
9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 125 | 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 126 | |||
9.6.1. Client Failure and Recovery . . . . . . . . . . . . 125 | 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 126 | |||
9.6.2. Server Failure and Recovery . . . . . . . . . . . . 126 | 9.6.2. Server Failure and Recovery . . . . . . . . . . . . 127 | |||
9.6.3. Network Partitions and Recovery . . . . . . . . . . 127 | 9.6.3. Network Partitions and Recovery . . . . . . . . . . 128 | |||
9.7. Recovery from a Lock Request Timeout or Abort . . . . . 133 | 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 134 | |||
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 133 | 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 135 | |||
9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 135 | 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 136 | |||
9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 135 | 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 136 | |||
9.10.1. Close and Retention of State Information . . . . . . 136 | 9.10.1. Close and Retention of State Information . . . . . . 137 | |||
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 137 | 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 138 | |||
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 137 | 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 139 | |||
9.13. Clocks, Propagation Delay, and Calculating Lease | 9.13. Clocks, Propagation Delay, and Calculating Lease | |||
Expiration . . . . . . . . . . . . . . . . . . . . . . . 138 | Expiration . . . . . . . . . . . . . . . . . . . . . . . 139 | |||
9.14. Migration, Replication and State . . . . . . . . . . . . 138 | 9.14. Migration, Replication and State . . . . . . . . . . . . 140 | |||
9.14.1. Migration and State . . . . . . . . . . . . . . . . 139 | 9.14.1. Migration and State . . . . . . . . . . . . . . . . 140 | |||
9.14.2. Replication and State . . . . . . . . . . . . . . . 140 | 9.14.2. Replication and State . . . . . . . . . . . . . . . 141 | |||
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 140 | 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 141 | |||
9.14.4. Migration and the Lease_time Attribute . . . . . . . 141 | 9.14.4. Migration and the Lease_time Attribute . . . . . . . 142 | |||
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 141 | 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 143 | |||
10.1. Performance Challenges for Client-Side Caching . . . . . 142 | 10.1. Performance Challenges for Client-Side Caching . . . . . 143 | |||
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 143 | 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 144 | |||
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 145 | 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 146 | |||
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 147 | 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 148 | |||
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 147 | 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 148 | |||
10.3.2. Data Caching and File Locking . . . . . . . . . . . 148 | 10.3.2. Data Caching and File Locking . . . . . . . . . . . 149 | |||
10.3.3. Data Caching and Mandatory File Locking . . . . . . 149 | 10.3.3. Data Caching and Mandatory File Locking . . . . . . 151 | |||
10.3.4. Data Caching and File Identity . . . . . . . . . . . 150 | 10.3.4. Data Caching and File Identity . . . . . . . . . . . 151 | |||
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 151 | 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 152 | |||
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 153 | 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 155 | |||
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 155 | 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 156 | |||
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 155 | 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 156 | |||
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 158 | 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 159 | |||
10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 160 | 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 161 | |||
10.4.6. Clients that Fail to Honor Delegation Recalls . . . 161 | 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 162 | |||
10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 162 | 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 163 | |||
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 162 | 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 163 | |||
10.5.1. Revocation Recovery for Write Open Delegation . . . 163 | 10.5.1. Revocation Recovery for Write Open Delegation . . . 164 | |||
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 163 | 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 164 | |||
10.7. Data and Metadata Caching and Memory Mapped Files . . . 165 | 10.7. Data and Metadata Caching and Memory Mapped Files . . . 166 | |||
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 167 | 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 169 | |||
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 168 | 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 170 | |||
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 169 | 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 171 | |||
12. Internationalization . . . . . . . . . . . . . . . . . . . . 172 | 12. Internationalization . . . . . . . . . . . . . . . . . . . . 173 | |||
12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 173 | 12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 174 | |||
12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 173 | 12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 174 | |||
12.1.2. Normalization, Equivalence, and Confusability . . . 174 | 12.1.2. Normalization, Equivalence, and Confusability . . . 175 | |||
12.2. String Type Overview . . . . . . . . . . . . . . . . . . 177 | 12.2. String Type Overview . . . . . . . . . . . . . . . . . . 178 | |||
12.2.1. Overall String Class Divisions . . . . . . . . . . . 177 | 12.2.1. Overall String Class Divisions . . . . . . . . . . . 178 | |||
12.2.2. Divisions by Typedef Parent types . . . . . . . . . 178 | 12.2.2. Divisions by Typedef Parent types . . . . . . . . . 179 | |||
12.2.3. Individual Types and Their Handling . . . . . . . . 179 | 12.2.3. Individual Types and Their Handling . . . . . . . . 180 | |||
12.3. Errors Related to Strings . . . . . . . . . . . . . . . 180 | 12.3. Errors Related to Strings . . . . . . . . . . . . . . . 181 | |||
12.4. Types with Pre-processing to Resolve Mixture Issues . . 181 | 12.4. Types with Pre-processing to Resolve Mixture Issues . . 182 | |||
12.4.1. Processing of Principal Strings . . . . . . . . . . 181 | 12.4.1. Processing of Principal Strings . . . . . . . . . . 182 | |||
12.4.2. Processing of Server Id Strings . . . . . . . . . . 181 | 12.4.2. Processing of Server Id Strings . . . . . . . . . . 183 | |||
12.5. String Types without Internationalization Processing . . 182 | 12.5. String Types without Internationalization Processing . . 183 | |||
12.6. Types with Processing Defined by Other Internet Areas . 182 | 12.6. Types with Processing Defined by Other Internet Areas . 184 | |||
12.7. String Types with NFS-specific Processing . . . . . . . 183 | 12.7. String Types with NFS-specific Processing . . . . . . . 185 | |||
12.7.1. Handling of File Name Components . . . . . . . . . . 184 | 12.7.1. Handling of File Name Components . . . . . . . . . . 185 | |||
12.7.2. Processing of Link Text . . . . . . . . . . . . . . 193 | 12.7.2. Processing of Link Text . . . . . . . . . . . . . . 194 | |||
12.7.3. Processing of Principal Prefixes . . . . . . . . . . 194 | 12.7.3. Processing of Principal Prefixes . . . . . . . . . . 195 | |||
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 195 | 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 196 | |||
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 195 | 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 196 | |||
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 197 | 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 198 | |||
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 198 | 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 199 | |||
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 199 | 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 201 | |||
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 200 | 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 201 | |||
13.1.5. State Management Errors . . . . . . . . . . . . . . 202 | 13.1.5. State Management Errors . . . . . . . . . . . . . . 203 | |||
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 203 | 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 204 | |||
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 203 | 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 205 | |||
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 204 | 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 205 | |||
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 205 | 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 207 | |||
13.1.10. Client Management Errors . . . . . . . . . . . . . . 206 | 13.1.10. Client Management Errors . . . . . . . . . . . . . . 207 | |||
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 206 | 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 208 | |||
13.2. Operations and their valid errors . . . . . . . . . . . 207 | 13.2. Operations and their valid errors . . . . . . . . . . . 208 | |||
13.3. Callback operations and their valid errors . . . . . . . 214 | 13.3. Callback operations and their valid errors . . . . . . . 216 | |||
13.4. Errors and the operations that use them . . . . . . . . 214 | 13.4. Errors and the operations that use them . . . . . . . . 216 | |||
14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 219 | 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 220 | |||
14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 219 | 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 221 | |||
14.2. Evaluation of a Compound Request . . . . . . . . . . . . 220 | 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 221 | |||
14.3. Synchronous Modifying Operations . . . . . . . . . . . . 221 | 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 222 | |||
14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 221 | 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 223 | |||
15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 221 | 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 223 | |||
15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 221 | 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 223 | |||
15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 222 | 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 223 | |||
15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 227 | 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 229 | |||
15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 230 | 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 231 | |||
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 231 | 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 232 | |||
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 233 | 15.6. Operation 6: CREATE - Create a Non-Regular File Object . 235 | |||
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting | 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting | |||
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 236 | Recovery . . . . . . . . . . . . . . . . . . . . . . . . 238 | |||
15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 237 | 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 239 | |||
15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 237 | 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 239 | |||
15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 239 | 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 241 | |||
15.11. Operation 11: LINK - Create Link to a File . . . . . . . 240 | 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 242 | |||
15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 241 | 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 243 | |||
15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 245 | 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 247 | |||
15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 247 | 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 249 | |||
15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 248 | 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 250 | |||
15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 250 | 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 252 | |||
15.17. Operation 17: NVERIFY - Verify Difference in | 15.17. Operation 17: NVERIFY - Verify Difference in | |||
Attributes . . . . . . . . . . . . . . . . . . . . . . . 250 | Attributes . . . . . . . . . . . . . . . . . . . . . . . 252 | |||
15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 252 | 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 254 | |||
15.19. Operation 19: OPENATTR - Open Named Attribute | 15.19. Operation 19: OPENATTR - Open Named Attribute | |||
Directory . . . . . . . . . . . . . . . . . . . . . . . 262 | Directory . . . . . . . . . . . . . . . . . . . . . . . 264 | |||
15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 263 | 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 265 | |||
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 265 | 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 267 | |||
15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 266 | 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 268 | |||
15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 267 | 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 269 | |||
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 268 | 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 270 | |||
15.25. Operation 25: READ - Read from File . . . . . . . . . . 269 | 15.25. Operation 25: READ - Read from File . . . . . . . . . . 271 | |||
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 271 | 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 273 | |||
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 275 | 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 277 | |||
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 276 | 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 278 | |||
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 278 | 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 280 | |||
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 280 | 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 282 | |||
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 281 | 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 283 | |||
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 282 | 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 284 | |||
15.33. Operation 33: SECINFO - Obtain Available Security . . . 282 | 15.33. Operation 33: SECINFO - Obtain Available Security . . . 284 | |||
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 285 | 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 287 | |||
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 288 | 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 290 | |||
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 292 | 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 294 | |||
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 295 | 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 297 | |||
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 297 | 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 299 | |||
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner | 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner | |||
State . . . . . . . . . . . . . . . . . . . . . . . . . 301 | State . . . . . . . . . . . . . . . . . . . . . . . . . 303 | |||
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 302 | 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 304 | |||
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 302 | 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 304 | |||
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 303 | 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 305 | |||
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 303 | 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 305 | |||
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 305 | 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 307 | |||
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 306 | 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 308 | |||
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback | 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback | |||
Operation . . . . . . . . . . . . . . . . . . . . . 307 | Operation . . . . . . . . . . . . . . . . . . . . . 309 | |||
17. Security Considerations . . . . . . . . . . . . . . . . . . . 308 | 17. Security Considerations . . . . . . . . . . . . . . . . . . . 310 | |||
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 309 | 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 311 | |||
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 309 | 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 311 | |||
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 310 | 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 312 | |||
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 310 | 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 312 | |||
18.2. ONC RPC Network Identifiers (netids) . . . . . . . . . . 310 | 18.2. ONC RPC Network Identifiers (netids) . . . . . . . . . . 312 | |||
18.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 312 | 18.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 314 | |||
18.2.2. Updating Registrations . . . . . . . . . . . . . . . 312 | 18.2.2. Updating Registrations . . . . . . . . . . . . . . . 314 | |||
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 312 | 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 314 | |||
19.1. Normative References . . . . . . . . . . . . . . . . . . 312 | 19.1. Normative References . . . . . . . . . . . . . . . . . . 314 | |||
19.2. Informative References . . . . . . . . . . . . . . . . . 313 | 19.2. Informative References . . . . . . . . . . . . . . . . . 315 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 315 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 317 | |||
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 316 | Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 318 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 316 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 318 | |||
1. Introduction | 1. Introduction | |||
1.1. Changes since RFC 3530 | 1.1. Changes since RFC 3530 | |||
This document, together with the companion XDR description document | This document, together with the companion XDR description document | |||
[2], obsoletes RFC 3530 [11] as the authoritative document describing | [2], obsoletes RFC 3530 [11] as the authoritative document describing | |||
NFSv4. It does not introduce any over-the-wire protocol changes, in | NFSv4. It does not introduce any over-the-wire protocol changes, in | |||
the sense that previously valid requests requests remain valid. | the sense that previously valid requests requests remain valid. | |||
However, some requests previously defined as invalid, although not | However, some requests previously defined as invalid, although not | |||
skipping to change at page 9, line 45 | skipping to change at page 9, line 45 | |||
reality of required string processing. | reality of required string processing. | |||
o LIPKEY SPKM/3 has been moved from being REQUIRED to OPTIONAL. | o LIPKEY SPKM/3 has been moved from being REQUIRED to OPTIONAL. | |||
o Some clarification on a client re-establishing callback | o Some clarification on a client re-establishing callback | |||
information to the new server if state has been migrated. | information to the new server if state has been migrated. | |||
o A third edge case was added for Courtesy locks and network | o A third edge case was added for Courtesy locks and network | |||
partitions. | partitions. | |||
o The definintion of stateid was strengthened, which had the side | o The definition of stateid was strengthened, which had the side | |||
effect of introducing a semantic change in a COMPOUND structure | effect of introducing a semantic change in a COMPOUND structure | |||
having a current stateid and a saved stateid. | having a current stateid and a saved stateid. | |||
1.2. Changes since RFC 3010 | 1.2. Changes since RFC 3010 | |||
This definition of the NFSv4 protocol replaces or obsoletes the | This definition of the NFSv4 protocol replaces or obsoletes the | |||
definition present in [12]. While portions of the two documents have | definition present in [12]. While portions of the two documents have | |||
remained the same, there have been substantive changes in others. | remained the same, there have been substantive changes in others. | |||
The changes made between [12] and this document represent | The changes made between [12] and this document represent | |||
implementation experience and further review of the protocol. While | implementation experience and further review of the protocol. While | |||
skipping to change at page 16, line 41 | skipping to change at page 16, line 41 | |||
exist, then delegations cannot be granted. The essence of a | exist, then delegations cannot be granted. The essence of a | |||
delegation is that it allows the client to locally service operations | delegation is that it allows the client to locally service operations | |||
such as OPEN, CLOSE, LOCK, LOCKU, READ, or WRITE without immediate | such as OPEN, CLOSE, LOCK, LOCKU, READ, or WRITE without immediate | |||
interaction with the server. | interaction with the server. | |||
1.6. General Definitions | 1.6. General Definitions | |||
The following definitions are provided for the purpose of providing | The following definitions are provided for the purpose of providing | |||
an appropriate context for the reader. | an appropriate context for the 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. | |||
Client The client is the entity that accesses the NFS server's | Client: The client is the entity that accesses the NFS server's | |||
resources. The client may be an application that contains the | resources. The client may be an application that contains the | |||
logic to access the NFS server directly. The client may also be | logic to access the NFS server directly. The client may also be | |||
the traditional operating system client that provides remote | the traditional operating system client that provides remote | |||
filesystem services for a set of applications. | filesystem services for a set of applications. | |||
With reference to byte-range locking, the client is also the | With reference to byte-range locking, the client is also the | |||
entity that maintains a set of locks on behalf of one or more | entity that maintains a set of locks on behalf of one or more | |||
applications. This client is responsible for crash or failure | applications. This client is responsible for crash or failure | |||
recovery for those locks it manages. | recovery for those locks it manages. | |||
Note that multiple clients may share the same transport and | Note that multiple clients may share the same transport and | |||
connection and multiple clients may exist on the same network | connection and multiple clients may exist on the same network | |||
node. | node. | |||
Client ID A 64-bit quantity used as a unique, short-hand reference | Client ID: A 64-bit quantity used as a unique, short-hand reference | |||
to a client supplied Verifier and ID. The server is responsible | to a client supplied Verifier and ID. The server is responsible | |||
for supplying the Client ID. | for supplying the Client ID. | |||
File System The file system is the collection of objects on a server | File System: The file system is the collection of objects on a | |||
that share the same fsid attribute (see Section 5.8.1.9). | server that share the same fsid attribute (see Section 5.8.1.9). | |||
Lease An interval of time defined by the server for which the client | Lease: An interval of time defined by the server for which the | |||
is irrevocably granted a lock. At the end of a lease period the | client is irrevocably granted a lock. At the end of a lease | |||
lock may be revoked if the lease has not been extended. The lock | period the lock may be revoked if the lease has not been extended. | |||
must be revoked if a conflicting lock has been granted after the | The lock must be revoked if a conflicting lock has been granted | |||
lease interval. | after the lease interval. | |||
All leases granted by a server have the same fixed interval. Note | All leases granted by a server have the same fixed interval. Note | |||
that the fixed interval was chosen to alleviate the expense a | that the fixed interval was chosen to alleviate the expense a | |||
server would have in maintaining state about variable length | server would have in maintaining state about variable length | |||
leases across server failures. | leases across server failures. | |||
Lock The term "lock" is used to refer to both record (byte-range) | Lock: The term "lock" is used to refer to both record (byte-range) | |||
locks as well as share reservations unless specifically stated | locks as well as share reservations unless specifically stated | |||
otherwise. | otherwise. | |||
Server The "Server" is the entity responsible for coordinating | Server: The "Server" is the entity responsible for coordinating | |||
client access to a set of filesystems. | client access to a set of filesystems. | |||
Stable Storage NFSv4 servers must be able to recover without data | Stable Storage: NFSv4 servers must be able to recover without data | |||
loss from multiple power failures (including cascading power | loss from multiple power failures (including cascading power | |||
failures, that is, several power failures in quick succession), | failures, that is, several power failures in quick succession), | |||
operating system failures, and hardware failure of components | operating system failures, and hardware failure of components | |||
other than the storage medium itself (for example, disk, | other than the storage medium itself (for example, disk, | |||
nonvolatile RAM). | nonvolatile RAM). | |||
Some examples of stable storage that are allowable for an NFS | Some examples of stable storage that are allowable for an NFS | |||
server include: | server include: | |||
1. Media commit of data, that is, the modified data has been | (1) Media commit of data, that is, the modified data has been | |||
successfully written to the disk media, for example, the disk | successfully written to the disk media, for example, the disk | |||
platter. | platter. | |||
2. An immediate reply disk drive with battery-backed on-drive | (2) An immediate reply disk drive with battery-backed on-drive | |||
intermediate storage or uninterruptible power system (UPS). | intermediate storage or uninterruptible power system (UPS). | |||
3. Server commit of data with battery-backed intermediate storage | (3) Server commit of data with battery-backed intermediate | |||
and recovery software. | storage and recovery software. | |||
4. Cache commit with uninterruptible power system (UPS) and | (4) Cache commit with uninterruptible power system (UPS) and | |||
recovery software. | recovery software. | |||
Stateid A stateid is a 128-bit quantity returned by a server that | Stateid: A stateid is a 128-bit quantity returned by a server that | |||
uniquely defines the open and locking states provided by the | uniquely defines the open and locking states provided by the | |||
server for a specific open-owner or lock-owner/open-owner pair for | server for a specific open-owner or lock-owner/open-owner pair for | |||
a specific file and type of lock. | a specific file and type of lock. | |||
Verifier A 64-bit quantity generated by the client that the server | Verifier: A 64-bit quantity generated by the client that the server | |||
can use to determine if the client has restarted and lost all | can use to determine if the client has restarted and lost all | |||
previous lock state. | previous lock state. | |||
2. Protocol Data Types | 2. Protocol Data Types | |||
The syntax and semantics to describe the data types of the NFS | The syntax and semantics to describe the data types of the NFS | |||
version 4 protocol are defined in the XDR [15] and RPC [3] documents. | version 4 protocol are defined in the XDR [15] and RPC [3] documents. | |||
The next sections build upon the XDR data types to define types and | The next sections build upon the XDR data types to define types and | |||
structures specific to this protocol. | structures specific to this protocol. | |||
skipping to change at page 35, line 8 | skipping to change at page 35, line 24 | |||
server should return NFS4ERR_STALE to the client (as is the case for | server should return NFS4ERR_STALE to the client (as is the case for | |||
persistent filehandles). In all other cases where the server | persistent filehandles). In all other cases where the server | |||
determines that a volatile filehandle can no longer be used, it | determines that a volatile filehandle can no longer be used, it | |||
should return an error of NFS4ERR_FHEXPIRED. | should return an error of NFS4ERR_FHEXPIRED. | |||
The mandatory attribute "fh_expire_type" is used by the client to | The mandatory attribute "fh_expire_type" is used by the client to | |||
determine what type of filehandle the server is providing for a | determine what type of filehandle the server is providing for a | |||
particular filesystem. This attribute is a bitmask with the | particular filesystem. This attribute is a bitmask with the | |||
following values: | following values: | |||
FH4_PERSISTENT The value of FH4_PERSISTENT is used to indicate a | FH4_PERSISTENT: The value of FH4_PERSISTENT is used to indicate a | |||
persistent filehandle, which is valid until the object is removed | persistent filehandle, which is valid until the object is removed | |||
from the filesystem. The server will not return NFS4ERR_FHEXPIRED | from the filesystem. The server will not return NFS4ERR_FHEXPIRED | |||
for this filehandle. FH4_PERSISTENT is defined as a value in | for this filehandle. FH4_PERSISTENT is defined as a value in | |||
which none of the bits specified below are set. | which none of the bits specified below are set. | |||
FH4_VOLATILE_ANY The filehandle may expire at any time, except as | FH4_VOLATILE_ANY: The filehandle may expire at any time, except as | |||
specifically excluded (i.e., FH4_NOEXPIRE_WITH_OPEN). | specifically excluded (i.e., FH4_NOEXPIRE_WITH_OPEN). | |||
FH4_NOEXPIRE_WITH_OPEN May only be set when FH4_VOLATILE_ANY is set. | FH4_NOEXPIRE_WITH_OPEN: May only be set when FH4_VOLATILE_ANY is | |||
If this bit is set, then the meaning of FH4_VOLATILE_ANY is | set. If this bit is set, then the meaning of FH4_VOLATILE_ANY is | |||
qualified to exclude any expiration of the filehandle when it is | qualified to exclude any expiration of the filehandle when it is | |||
open. | open. | |||
FH4_VOL_MIGRATION The filehandle will expire as a result of | FH4_VOL_MIGRATION: The filehandle will expire as a result of | |||
migration. If FH4_VOLATILE_ANY is set, FH4_VOL_MIGRATION is | migration. If FH4_VOLATILE_ANY is set, FH4_VOL_MIGRATION is | |||
redundant. | redundant. | |||
FH4_VOL_RENAME The filehandle will expire during rename. This | FH4_VOL_RENAME: The filehandle will expire during rename. This | |||
includes a rename by the requesting client or a rename by any | includes a rename by the requesting client or a rename by any | |||
other client. If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME is | other client. If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME is | |||
redundant. | redundant. | |||
Servers which provide volatile filehandles that may expire while open | Servers which provide volatile filehandles that may expire while open | |||
(i.e., if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if | (i.e., if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if | |||
FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should | FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should | |||
deny a RENAME or REMOVE that would affect an OPEN file of any of the | deny a RENAME or REMOVE that would affect an OPEN file of any of the | |||
components leading to the OPEN file. In addition, the server should | components leading to the OPEN file. In addition, the server should | |||
deny all RENAME or REMOVE requests during the grace period upon | deny all RENAME or REMOVE requests during the grace period upon | |||
skipping to change at page 84, line 12 | skipping to change at page 84, line 49 | |||
Another issue concerns refresh of referral locations. When referrals | Another issue concerns refresh of referral locations. When referrals | |||
are used extensively, they may change as server configurations | are used extensively, they may change as server configurations | |||
change. It is expected that clients will cache information related | change. It is expected that clients will cache information related | |||
to traversing referrals so that future client-side requests are | to traversing referrals so that future client-side requests are | |||
resolved locally without server communication. This is usually | resolved locally without server communication. This is usually | |||
rooted in client-side name look up caching. Clients should | rooted in client-side name look up caching. Clients should | |||
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. | changes in location information. | |||
A problem exists if a client allows an open owner to have state on | ||||
multiple filesystems on a server. If one of those filesystems is | ||||
migrated, what happens to the sequence numbers? A client can avoid | ||||
such a situation with the stipulation that any client which supports | ||||
migration MUST ensure that any open owner is confined to a single | ||||
filesystem. If the server finds itself migrating open owners that | ||||
span multiple filesystems, then it MUST not migrate the state for the | ||||
conflicting open owners on the non-migrated filesystems; instead it | ||||
MUST return NFS4ERR_STALE_STATEID if the client tries to use those | ||||
stateids. | ||||
7.7. Effecting File System Transitions | 7.7. Effecting File System Transitions | |||
Transitions between file system instances, whether due to switching | Transitions between file system instances, whether due to switching | |||
between replicas upon server unavailability or to server-initiated | between replicas upon server unavailability or to server-initiated | |||
migration events, are best dealt with together. This is so even | migration events, are best dealt with together. This is so even | |||
though, for the server, pragmatic considerations will normally force | though, for the server, pragmatic considerations will normally force | |||
different implementation strategies for planned and unplanned | different implementation strategies for planned and unplanned | |||
transitions. Even though the prototypical use cases of replication | transitions. Even though the prototypical use cases of replication | |||
and migration contain distinctive sets of features, when all | and migration contain distinctive sets of features, when all | |||
possibilities for these operations are considered, there is an | possibilities for these operations are considered, there is an | |||
skipping to change at page 112, line 37 | skipping to change at page 113, line 34 | |||
in the case of a stateid sent with a READ or WRITE operation. It | in the case of a stateid sent with a READ or WRITE operation. It | |||
also may set a non-zero value, in which case the server checks if | also may set a non-zero value, in which case the server checks if | |||
that seqid is the correct one. In that case, the server is required | that seqid is the correct one. In that case, the server is required | |||
to return NFS4ERR_OLD_STATEID if the seqid is lower than the most | to return NFS4ERR_OLD_STATEID if the seqid is lower than the most | |||
current value and NFS4ERR_BAD_STATEID if the seqid is greater than | current value and NFS4ERR_BAD_STATEID if the seqid is greater than | |||
the most current value. This would be the common choice in the case | the most current value. This would be the common choice in the case | |||
of stateids sent with a CLOSE or OPEN_DOWNGRADE. Because OPENs may | of stateids sent with a CLOSE or OPEN_DOWNGRADE. Because OPENs may | |||
be sent in parallel for the same owner, a client might close a file | be sent in parallel for the same owner, a client might close a file | |||
without knowing that an OPEN upgrade had been done by the server, | without knowing that an OPEN upgrade had been done by the server, | |||
changing the lock in question. If CLOSE were sent with a zero seqid, | changing the lock in question. If CLOSE were sent with a zero seqid, | |||
the OPEN upgrade would be cancelled before the client even received | the OPEN upgrade would be canceled before the client even received an | |||
an indication that an upgrade had happened. | indication that an upgrade had happened. | |||
When a stateid is sent by the server to the client as part of a | When a stateid is sent by the server to the client as part of a | |||
callback operation, it is not subject to checking for a current seqid | callback operation, it is not subject to checking for a current seqid | |||
and returning NFS4ERR_OLD_STATEID. This is because the client is not | and returning NFS4ERR_OLD_STATEID. This is because the client is not | |||
in a position to know the most up-to-date seqid and thus cannot | in a position to know the most up-to-date seqid and thus cannot | |||
verify it. Unless specially noted, the seqid value for a stateid | verify it. Unless specially noted, the seqid value for a stateid | |||
sent by the server to the client as part of a callback is required to | sent by the server to the client as part of a callback is required to | |||
be zero with NFS4ERR_BAD_STATEID returned if it is not. | be zero with NFS4ERR_BAD_STATEID returned if it is not. | |||
In making comparisons between seqids, both by the client in | In making comparisons between seqids, both by the client in | |||
skipping to change at page 129, line 12 | skipping to change at page 130, line 12 | |||
the client with the now invalid stateids will fail with the server | the client with the now invalid stateids will fail with the server | |||
returning the error NFS4ERR_EXPIRED. Once this error is received, | returning the error NFS4ERR_EXPIRED. Once this error is received, | |||
the client will suitably notify the application that held the lock. | the client will suitably notify the application that held the lock. | |||
9.6.3.1. Courtesy Locks | 9.6.3.1. Courtesy Locks | |||
As a courtesy to the client or as an optimization, the server may | As a courtesy to the client or as an optimization, the server may | |||
continue to hold locks on behalf of a client for which recent | continue to hold locks on behalf of a client for which recent | |||
communication has extended beyond the lease period. If the server | communication has extended beyond the lease period. If the server | |||
receives a lock or I/O request that conflicts with one of these | receives a lock or I/O request that conflicts with one of these | |||
courtesy locks, the server must free the courtesy lock and grant the | courtesy locks, the server MUST free the courtesy lock and grant the | |||
new request. | new request. If the server runs out of resources, it MAY free all | |||
courtesy locks. I.e., the client MUST not make an assumption that | ||||
the server has issued courtesy locks. | ||||
If the server does not reboot before the network partition is healed, | If the server does not reboot before the network partition is healed, | |||
when the original client tries to access a courtesy lock which was | when the original client tries to access a courtesy lock which was | |||
freed, the server SHOULD send back a NFS4ERR_BAD_STATEID to the | freed, the server SHOULD send back a NFS4ERR_BAD_STATEID to the | |||
client. If the client tries to access a courtesy lock which was not | client. If the client tries to access a courtesy lock which was not | |||
freed, then the server should mark all of the courtesy locks as | freed, then the server SHOULD mark all of the courtesy locks as | |||
implicitly being renewed. | implicitly being renewed. | |||
When a network partition is combined with a server reboot, there are | When a network partition is combined with a server reboot, then both | |||
edge conditions that place requirements on the server in order to | the server and client have responsibilities to ensure that the client | |||
avoid silent data corruption following the server reboot. Two of | does not reclaim a lock which it should no longer be able to access. | |||
these edge conditions are known, and are discussed below. | The next sections illustrate examples of these edge conditions and | |||
the steps necessary to be undertaken to ensure proper lock semantics. | ||||
9.6.3.1.1. First Server Edge Condition | 9.6.3.1.1. First Server Edge Condition | |||
The first edge condition has the following scenario: | The first edge condition has the following scenario: | |||
1. Client A acquires a lock. | 1. Client A acquires a lock. | |||
2. Client A and server experience mutual network partition, such | 2. Client A and server experience mutual network partition, such | |||
that client A is unable to renew its lease. | that client A is unable to renew its lease. | |||
skipping to change at page 132, line 34 | skipping to change at page 133, line 37 | |||
4. Client A issues a RENEW operation, and gets back a | 4. Client A issues a RENEW operation, and gets back a | |||
NFS4ERR_STALE_CLIENTID. | NFS4ERR_STALE_CLIENTID. | |||
5. Client A reclaims its lock 1 within the server's grace period. | 5. Client A reclaims its lock 1 within the server's grace period. | |||
6. Client A and server experience mutual network partition, such | 6. Client A and server experience mutual network partition, such | |||
that client A is unable to reclaim its remaining locks within | that client A is unable to reclaim its remaining locks within | |||
the grace period. | the grace period. | |||
7. Server's reclaim grace period ends. Client A has no locks | 7. Server's reclaim grace period ends. | |||
recorded on server. | ||||
8. Server reboots a second time. | 8. Client B acquires a lock that would have conflicted with Client | |||
A's lock 2. | ||||
9. Network partition between client A and server heals. | 9. Client B releases the lock. | |||
10. Client A issues a RENEW operation, and gets back a | 10. Server reboots a second time. | |||
11. Network partition between client A and server heals. | ||||
12. Client A issues a RENEW operation, and gets back a | ||||
NFS4ERR_STALE_CLIENTID. | NFS4ERR_STALE_CLIENTID. | |||
11. Client A reclaims its lock 1 within the server's grace period. | 13. Client A reclaims both lock 1 and lock 2 within the server's | |||
grace period. | ||||
During the partition, client A decided that the server had revoked | At the last step, the client reclaims lock 2 as if it had held that | |||
lock 2. After the partition, it was able to reclaim lock 1, but made | lock continuously, when in fact a conflicting lock was granted to | |||
no attempt to reclaim lock 2. After the grace period, it is free to | client B. | |||
try to reestablish lock 2 via LOCK operations. | ||||
Note that the other two edge conditions are able to interact with | A server could avoid this situation by rejecting the reclaim of lock | |||
this third edge condition. Another client B may have established a | 2. However, to do so accurately it would have to ensure that | |||
conflicting lock during the partition, made some changes, and the | additional information about individual locks held survives reboot. | |||
released the lock before the second server reboot. | Server implementations are not required to do that, so the client | |||
must not assume that the server will. | ||||
Instead, a client MUST reclaim only those locks which it succesfully | ||||
acquired from the previous server instance, omitting any that it | ||||
failed to reclaim before a new reboot. Thus, in the last step above, | ||||
client A should reclaim only lock 1. | ||||
9.6.3.1.5. Client's Handling of NFS4ERR_NO_GRACE | 9.6.3.1.5. Client's Handling of NFS4ERR_NO_GRACE | |||
A mandate for the client's handling of the NFS4ERR_NO_GRACE error is | A mandate for the client's handling of the NFS4ERR_NO_GRACE error is | |||
outside the scope of this specification, since the strategies for | outside the scope of this specification, since the strategies for | |||
such handling are very dependent on the client's operating | such handling are very dependent on the client's operating | |||
environment. However, one potential approach is described below. | environment. However, one potential approach is described below. | |||
When the client receives NFS4ERR_NO_GRACE, it could examine the | When the client receives NFS4ERR_NO_GRACE, it could examine the | |||
change attribute of the objects the client is trying to reclaim state | change attribute of the objects the client is trying to reclaim state | |||
skipping to change at page 171, line 4 | skipping to change at page 172, line 14 | |||
11. Minor Versioning | 11. 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 protocol contains the rules and framework to | need arises, the NFSv4 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 must follow the IETF process and be | future accepted minor version must follow the IETF process and be | |||
documented in a standards track RFC. Therefore, each minor version | documented in a standards track RFC. Therefore, each minor version | |||
number will correspond to an RFC. Minor version zero of the NFS | number will correspond to an RFC. Minor version 0 of the NFS version | |||
version 4 protocol is represented by this RFC. The COMPOUND and | 4 protocol is represented by this RFC. The COMPOUND and CB_COMPOUND | |||
CB_COMPOUND procedures support the encoding of the minor version | procedures support the encoding of the minor version being requested | |||
being requested by the client. | by the client. | |||
The following items represent the basic rules for the development of | The following items represent the basic rules for the development of | |||
minor versions. Note that a future minor version may decide to | minor versions. Note that a future minor version may decide to | |||
modify or add to the following rules as part of the minor version | modify or add to the following rules as part of the minor version | |||
definition. | definition. | |||
1. Procedures are not added or deleted | 1. Procedures are not added or deleted | |||
To maintain the general RPC model, NFSv4 minor versions will not | To maintain the general RPC model, NFSv4 minor versions will not | |||
add to or delete procedures from the NFS program. | add to or delete procedures from the NFS program. | |||
skipping to change at page 172, line 51 | skipping to change at page 174, line 12 | |||
2. Minor versions may declare that a flag bit or enumeration | 2. Minor versions may declare that a flag bit or enumeration | |||
value MUST NOT be implemented. | value MUST NOT be implemented. | |||
9. Minor versions may downgrade features from REQUIRED to | 9. Minor versions may downgrade features from REQUIRED to | |||
RECOMMENDED, or RECOMMENDED to OPTIONAL. | RECOMMENDED, or RECOMMENDED to OPTIONAL. | |||
10. Minor versions may upgrade features from OPTIONAL to RECOMMENDED | 10. Minor versions may upgrade features from OPTIONAL to RECOMMENDED | |||
or RECOMMENDED to REQUIRED. | or RECOMMENDED to REQUIRED. | |||
11. A client and server that support minor version X SHOULD support | 11. A client and server that support minor version X SHOULD support | |||
minor versions 0 (zero) through X-1 as well. | minor versions 0 through X-1 as well. | |||
12. Except for infrastructural changes, no new features may be | 12. Except for infrastructural changes, no new features may be | |||
introduced as REQUIRED in a minor version. | introduced as REQUIRED in a minor version. | |||
This rule allows for the introduction of new functionality and | This rule allows for the introduction of new functionality and | |||
forces the use of implementation experience before designating a | forces the use of implementation experience before designating a | |||
feature as REQUIRED. On the other hand, some classes of | feature as REQUIRED. On the other hand, some classes of | |||
features are infrastructural and have broad effects. Allowing | features are infrastructural and have broad effects. Allowing | |||
infrastructural features to be RECOMMENDED or OPTIONAL | infrastructural features to be RECOMMENDED or OPTIONAL | |||
complicates implementation of the minor version. | complicates implementation of the minor version. | |||
skipping to change at page 178, line 37 | skipping to change at page 179, line 47 | |||
the responsibility of other IETF groups and our job is simply to | the responsibility of other IETF groups and our job is simply to | |||
reference those and perhaps make a few choices as to how they are | reference those and perhaps make a few choices as to how they are | |||
to be used (e.g., U-labels vs. A-labels). | to be used (e.g., U-labels vs. A-labels). | |||
o There are also cases in which a string has a small amount of NFSv4 | o There are also cases in which a string has a small amount of NFSv4 | |||
processing which results in one or more strings being referred to | processing which results in one or more strings being referred to | |||
one of the other categories. | one of the other categories. | |||
We will divide strings to be dealt with into the following classes: | We will divide strings to be dealt with into the following classes: | |||
MIX indicating that there is small amount of preparatory processing | MIX: indicating that there is small amount of preparatory processing | |||
that either picks an internationalization handling mode or divides | that either picks an internationalization handling mode or divides | |||
the string into a set of (two) strings with a different mode | the string into a set of (two) strings with a different mode | |||
internationalization handling for each. The details are discussed | internationalization handling for each. The details are discussed | |||
in the section "Types with Pre-processing to Resolve Mixture | in the section "Types with Pre-processing to Resolve Mixture | |||
Issues". | Issues". | |||
NIP indicating that, for various reasons, there is no need for | NIP: indicating that, for various reasons, there is no need for | |||
internationalization-specific processing to be performed. The | internationalization-specific processing to be performed. The | |||
specifics of the various string types handled in this way are | specifics of the various string types handled in this way are | |||
described in the section "String Types without | described in the section "String Types without | |||
Internationalization Processing". | Internationalization Processing". | |||
INET indicating that the string needs to be processed in a fashion | INET: indicating that the string needs to be processed in a fashion | |||
governed by non-NFS-specific internet specifications. The details | governed by non-NFS-specific internet specifications. The details | |||
are discussed in the section "Types with Processing Defined by | are discussed in the section "Types with Processing Defined by | |||
Other Internet Areas". | Other Internet Areas". | |||
NFS indicating that the string needs to be processed in a fashion | NFS: indicating that the string needs to be processed in a fashion | |||
governed by NFSv4-specific considerations. The primary focus is | governed by NFSv4-specific considerations. The primary focus is | |||
on enabling flexibility for the various file systems to be | on enabling flexibility for the various file systems to be | |||
accessed and is described in the section "String Types with NFS- | accessed and is described in the section "String Types with NFS- | |||
specific Processing". | specific Processing". | |||
12.2.2. Divisions by Typedef Parent types | 12.2.2. Divisions by Typedef Parent types | |||
There are a number of different string types within NFSv4 and | There are a number of different string types within NFSv4 and | |||
internationalization handling will be different for different types | internationalization handling will be different for different types | |||
of strings. Each the types will be in one of four groups based on | of strings. Each the types will be in one of four groups based on | |||
skipping to change at page 183, line 22 | skipping to change at page 184, line 32 | |||
There are a number of types of strings which, for a number of | There are a number of types of strings which, for a number of | |||
different reasons, do not require any internationalization-specific | different reasons, do not require any internationalization-specific | |||
handling, such as validation of UTF-8, normalization, or character | handling, such as validation of UTF-8, normalization, or character | |||
mapping or checking. This does not necessarily mean that the strings | mapping or checking. This does not necessarily mean that the strings | |||
need not be UTF-8. In some case, other checking on the string | need not be UTF-8. In some case, other checking on the string | |||
ensures that they are valid UTF-8, without doing any checking | ensures that they are valid UTF-8, without doing any checking | |||
specific to internationalization. | specific to internationalization. | |||
The following are the specific types: | The following are the specific types: | |||
comptag4 strings are an aid to debugging and the sender should avoid | comptag4: strings are an aid to debugging and the sender should | |||
confusion by not using anything but valid UTF-8. But any work | avoid confusion by not using anything but valid UTF-8. But any | |||
validating the string or modifying it would only add complication | work validating the string or modifying it would only add | |||
to a mechanism whose basic function is best supported by making it | complication to a mechanism whose basic function is best supported | |||
not subject to any checking and having data maximally available to | by making it not subject to any checking and having data maximally | |||
be looked at in a network trace. | available to be looked at in a network trace. | |||
fattr4_mimetype strings need to be validated by matching against a | fattr4_mimetype: strings need to be validated by matching against a | |||
list of valid mime types. Since these are all ASCII, no | list of valid mime types. Since these are all ASCII, no | |||
processing specific to internationalization is required since | processing specific to internationalization is required since | |||
anything that does not match is invalid and anything which does | anything that does not match is invalid and anything which does | |||
not obey the rules of UTF-8 will not be ASCII and consequently | not obey the rules of UTF-8 will not be ASCII and consequently | |||
will not match, and will be invalid. | will not match, and will be invalid. | |||
svraddr4 strings, in order to be valid, need to be ASCII, but if you | svraddr4: strings, in order to be valid, need to be ASCII, but if | |||
check them for validity, you have inherently checked that that | you check them for validity, you have inherently checked that that | |||
they are ASCII and thus UTF-8. | they are ASCII and thus UTF-8. | |||
12.6. Types with Processing Defined by Other Internet Areas | 12.6. Types with Processing Defined by Other Internet Areas | |||
There are two types of strings which NFSv4 deals with whose | There are two types of strings which NFSv4 deals with whose | |||
processing is defined by other Internet standards, and where issues | processing is defined by other Internet standards, and where issues | |||
related to different handling choices by server operating systems or | related to different handling choices by server operating systems or | |||
server file systems do not apply. | server file systems do not apply. | |||
These are as follows: | These are as follows: | |||
skipping to change at page 229, line 46 | skipping to change at page 231, line 20 | |||
ACCESS4_READ even if it could have reliably checked other values. | ACCESS4_READ even if it could have reliably checked other values. | |||
The results of this operation are necessarily advisory in nature. A | The results of this operation are necessarily advisory in nature. A | |||
return status of NFS4_OK and the appropriate bit set in the bit mask | return status of NFS4_OK and the appropriate bit set in the bit mask | |||
does not imply that such access will be allowed to the file system | does not imply that such access will be allowed to the file system | |||
object in the future. This is because access rights can be revoked | object in the future. This is because access rights can be revoked | |||
by the server at any time. | by the server at any time. | |||
The following access permissions may be requested: | The following access permissions may be requested: | |||
ACCESS4_READ Read data from file or read a directory. | ACCESS4_READ: Read data from file or read a directory. | |||
ACCESS4_LOOKUP Look up a name in a directory (no meaning for non- | ACCESS4_LOOKUP: Look up a name in a directory (no meaning for non- | |||
directory objects). | directory objects). | |||
ACCESS4_MODIFY Rewrite existing file data or modify existing | ACCESS4_MODIFY: Rewrite existing file data or modify existing | |||
directory entries. | directory entries. | |||
ACCESS4_EXTEND Write new data or add directory entries. | ACCESS4_EXTEND: Write new data or add directory entries. | |||
ACCESS4_DELETE Delete an existing directory entry. | ACCESS4_DELETE: Delete an existing directory entry. | |||
ACCESS4_EXECUTE Execute file (no meaning for a directory). | ACCESS4_EXECUTE: Execute file (no meaning for a directory). | |||
On success, the current filehandle retains its value. | On success, the current filehandle retains its value. | |||
15.3.5. IMPLEMENTATION | 15.3.5. IMPLEMENTATION | |||
In general, it is not sufficient for the client to attempt to deduce | In general, it is not sufficient for the client to attempt to deduce | |||
access permissions by inspecting the uid, gid, and mode fields in the | access permissions by inspecting the uid, gid, and mode fields in the | |||
file attributes or by attempting to interpret the contents of the ACL | file attributes or by attempting to interpret the contents of the ACL | |||
attribute. This is because the server may perform uid or gid mapping | attribute. This is because the server may perform uid or gid mapping | |||
or enforce additional access control restrictions. It is also | or enforce additional access control restrictions. It is also | |||
skipping to change at page 259, line 5 | skipping to change at page 261, line 5 | |||
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 which the client claims to | be opened and the state information which the client claims to | |||
possess. There are four basic claim types which cover the various | possess. There are four basic claim types which cover the various | |||
situations for an OPEN. They are as follows: | situations for an OPEN. They are as follows: | |||
CLAIM_NULL For the client, this is a new OPEN request and there is | CLAIM_NULL: For the client, this is a new OPEN request and there is | |||
no previous state associate with the file for the client. | no previous state associate with the file for the client. | |||
CLAIM_PREVIOUS The client is claiming basic OPEN state for a file | CLAIM_PREVIOUS: The client is claiming basic OPEN state for a file | |||
that was held previous to a server reboot. Generally used when a | that was held previous to a server reboot. Generally used when a | |||
server is returning persistent filehandles; the client may not | server is returning persistent filehandles; the client may not | |||
have the file name to reclaim the OPEN. | have the file name to reclaim the OPEN. | |||
CLAIM_DELEGATE_CUR The client is claiming a delegation for OPEN as | CLAIM_DELEGATE_CUR: The client is claiming a delegation for OPEN as | |||
granted by the server. Generally this is done as part of | granted by the server. Generally this is done as part of | |||
recalling a delegation. | recalling a delegation. | |||
CLAIM_DELEGATE_PREV The client is claiming a delegation granted to a | CLAIM_DELEGATE_PREV: The client is claiming a delegation granted to | |||
previous client instance; used after the client reboots. The | a previous client instance; used after the client reboots. The | |||
server MAY support CLAIM_DELEGATE_PREV. If it does support | server MAY support CLAIM_DELEGATE_PREV. If it does support | |||
CLAIM_DELEGATE_PREV, SETCLIENTID_CONFIRM MUST NOT remove the | CLAIM_DELEGATE_PREV, SETCLIENTID_CONFIRM MUST NOT remove the | |||
client's delegation state, and the server MUST support the | client's delegation state, and the server MUST support the | |||
DELEGPURGE operation. | DELEGPURGE operation. | |||
For OPEN requests whose claim type is other than CLAIM_PREVIOUS | For OPEN requests whose claim type is other than CLAIM_PREVIOUS | |||
(i.e., requests other than those devoted to reclaiming opens after a | (i.e., requests other than those devoted to reclaiming opens after a | |||
server reboot) that reach the server during its grace or lease | server reboot) that reach the server during its grace or lease | |||
expiration period, the server returns an error of NFS4ERR_GRACE. | expiration period, the server returns an error of NFS4ERR_GRACE. | |||
skipping to change at page 312, line 17 | skipping to change at page 314, line 17 | |||
must be done with the publication of an RFC. | must be done with the publication of an RFC. | |||
The initial values for this registry are as follows (some of this | The initial values for this registry are as follows (some of this | |||
text is replicated from section 2.2 for clarity): | text is replicated from section 2.2 for clarity): | |||
The Network Identifier (or r_netid for short) is used to specify a | The Network Identifier (or r_netid for short) is used to specify a | |||
transport protocol and associated universal address (or r_addr for | transport protocol and associated universal address (or r_addr for | |||
short). The syntax of the Network Identifier is a US-ASCII string. | short). The syntax of the Network Identifier is a US-ASCII string. | |||
The initial definitions for r_netid are: | The initial definitions for r_netid are: | |||
"tcp" TCP over IP version 4 | "tcp": TCP over IP version 4 | |||
"udp" UDP over IP version 4 | "udp": UDP over IP version 4 | |||
"tcp6" TCP over IP version 6 | "tcp6": TCP over IP version 6 | |||
"udp6" UDP over IP version 6 | "udp6": UDP over IP version 6 | |||
Note: the '"' marks are used for delimiting the strings for this | Note: the '"' marks are used for delimiting the strings for this | |||
document and are not part of the Network Identifier string. | document and are not part of the Network Identifier string. | |||
For the "tcp" and "udp" Network Identifiers the Universal Address or | For the "tcp" and "udp" Network Identifiers the Universal Address or | |||
r_addr (for IPv4) is a US-ASCII string and is of the form: | r_addr (for IPv4) is a US-ASCII string and is of the form: | |||
h1.h2.h3.h4.p1.p2 | h1.h2.h3.h4.p1.p2 | |||
The prefix, "h1.h2.h3.h4", is the standard textual form for | The prefix, "h1.h2.h3.h4", is the standard textual form for | |||
skipping to change at page 313, line 28 | skipping to change at page 315, line 28 | |||
19.1. Normative References | 19.1. Normative References | |||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Levels", March 1997. | Levels", March 1997. | |||
[2] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Description", | [2] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Description", | |||
draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work in progress), | draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work in progress), | |||
Feb 2011. | Feb 2011. | |||
[3] Srinivasan, R., "RPC: Remote Procedure Call Protocol | [3] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification | |||
Specification Version 2", RFC 1831, August 1995. | Version 2", RFC 5531, May 2009. | |||
[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, September 1997. | |||
[5] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism | [5] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism | |||
Using SPKM", RFC 2847, June 2000. | Using SPKM", RFC 2847, June 2000. | |||
[6] Linn, J., "Generic Security Service Application Program | [6] Linn, J., "Generic Security Service Application Program | |||
Interface Version 2, Update 1", RFC 2743, January 2000. | Interface Version 2, Update 1", RFC 2743, January 2000. | |||
skipping to change at page 317, line 5 | skipping to change at page 318, line 48 | |||
contributed substantially to improving the quality of the final | contributed substantially to improving the quality of the final | |||
result. | result. | |||
James Lentini graciously read the rewrite of Section 7 and his | James Lentini graciously read the rewrite of Section 7 and his | |||
comments were vital in improving the quality of that effort. | comments were vital in improving the quality of that effort. | |||
Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond | Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond | |||
Myklebust were faithful attendants of the biweekly triage meeting and | Myklebust were faithful attendants of the biweekly triage meeting and | |||
accepted many an action item. | accepted many an action item. | |||
Bruce Fields was a good sounding board for both the Third Edge | ||||
Condition and Courtsey Locks in general. | ||||
Appendix B. RFC Editor Notes | Appendix B. RFC Editor Notes | |||
[RFC Editor: please remove this section prior to publishing this | [RFC Editor: please remove this section prior to publishing this | |||
document as an RFC] | document as an RFC] | |||
[RFC Editor: prior to publishing this document as an RFC, please | [RFC Editor: prior to publishing this document as an RFC, please | |||
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the | replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the | |||
RFC number of this document] | RFC number of this document] | |||
Authors' Addresses | Authors' Addresses | |||
Thomas Haynes | Thomas Haynes (editor) | |||
NetApp | NetApp | |||
9110 E 66th St | 9110 E 66th St | |||
Tulsa, OK 74133 | Tulsa, OK 74133 | |||
USA | USA | |||
Phone: +1 918 307 1415 | Phone: +1 918 307 1415 | |||
Email: thomas@netapp.com | Email: thomas@netapp.com | |||
URI: http://www.tulsalabs.com | ||||
David Noveck | David Noveck (editor) | |||
EMC | EMC Corporation | |||
32 Coslin Drive | 32 Coslin Drive | |||
Southborough, MA 01772 | Southborough, MA 01772 | |||
US | US | |||
Phone: +1 508 305 8404 | Phone: +1 508 305 8404 | |||
Email: novecd@emc.com | Email: novecd@emc.com | |||
End of changes. 91 change blocks. | ||||
308 lines changed or deleted | 337 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |