Internet Engineering Task Force (IETF) T. Haynes, Ed.
Request for Comments: 7530 Primary Data
Obsoletes: 3530 D. Noveck, Ed.
Category: Standards Track Dell
ISSN: 2070-1721 March 2015
Internet Engineering Task Force (IETF) T. Haynes, Ed.
Request for Comments: 7530 Primary Data
Obsoletes: 3530 D. Noveck, Ed.
Category: Standards Track Dell
ISSN: 2070-1721 March 2015
Network File System (NFS) Version 4 Protocol
网络文件系统（NFS）版本4协议
Abstract
摘要
The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.
网络文件系统（NFS）版本4协议是一种分布式文件系统协议，它建立在NFS协议版本2（RFC 1094）和版本3（RFC 1813）的基础上。与早期版本不同，NFS版本4协议支持传统的文件访问，同时集成了对文件锁定和装载协议的支持。此外，还增加了对强安全性（及其协商）、复合操作、客户端缓存和国际化的支持。当然，人们已经注意到使NFS版本4在Internet环境中运行良好。
This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol.
本文档以及附带的外部数据表示（XDR）描述文档RFC 7531将RFC 3530废弃为NFS版本4协议的定义。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7530.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7530.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................8
1.1. Requirements Language ......................................8
1.2. NFS Version 4 Goals ........................................8
1.3. Definitions in the Companion Document RFC 7531 Are
Authoritative ..............................................9
1.4. Overview of NFSv4 Features .................................9
1.4.1. RPC and Security ....................................9
1.4.2. Procedure and Operation Structure ..................10
1.4.3. File System Model ..................................10
1.4.4. OPEN and CLOSE .....................................12
1.4.5. File Locking .......................................12
1.4.6. Client Caching and Delegation ......................13
1.5. General Definitions .......................................14
1.6. Changes since RFC 3530 ....................................16
1.7. Changes between RFC 3010 and RFC 3530 .....................16
2. Protocol Data Types ............................................18
2.1. Basic Data Types ..........................................18
2.2. Structured Data Types .....................................21
1. Introduction ....................................................8
1.1. Requirements Language ......................................8
1.2. NFS Version 4 Goals ........................................8
1.3. Definitions in the Companion Document RFC 7531 Are
Authoritative ..............................................9
1.4. Overview of NFSv4 Features .................................9
1.4.1. RPC and Security ....................................9
1.4.2. Procedure and Operation Structure ..................10
1.4.3. File System Model ..................................10
1.4.4. OPEN and CLOSE .....................................12
1.4.5. File Locking .......................................12
1.4.6. Client Caching and Delegation ......................13
1.5. General Definitions .......................................14
1.6. Changes since RFC 3530 ....................................16
1.7. Changes between RFC 3010 and RFC 3530 .....................16
2. Protocol Data Types ............................................18
2.1. Basic Data Types ..........................................18
2.2. Structured Data Types .....................................21
3. RPC and Security Flavor ........................................25
3.1. Ports and Transports ......................................25
3.1.1. Client Retransmission Behavior .....................26
3.2. Security Flavors ..........................................27
3.2.1. Security Mechanisms for NFSv4 ......................27
3.3. Security Negotiation ......................................28
3.3.1. SECINFO ............................................29
3.3.2. Security Error .....................................29
3.3.3. Callback RPC Authentication ........................29
4. Filehandles ....................................................30
4.1. Obtaining the First Filehandle ............................30
4.1.1. Root Filehandle ....................................31
4.1.2. Public Filehandle ..................................31
4.2. Filehandle Types ..........................................31
4.2.1. General Properties of a Filehandle .................32
4.2.2. Persistent Filehandle ..............................32
4.2.3. Volatile Filehandle ................................33
4.2.4. One Method of Constructing a Volatile Filehandle ...34
4.3. Client Recovery from Filehandle Expiration ................35
5. Attributes .....................................................35
5.1. REQUIRED Attributes .......................................37
5.2. RECOMMENDED Attributes ....................................37
5.3. Named Attributes ..........................................37
5.4. Classification of Attributes ..............................39
5.5. Set-Only and Get-Only Attributes ..........................40
5.6. REQUIRED Attributes - List and Definition References ......40
5.7. RECOMMENDED Attributes - List and Definition References ...41
5.8. Attribute Definitions .....................................42
5.8.1. Definitions of REQUIRED Attributes .................42
5.8.2. Definitions of Uncategorized RECOMMENDED
Attributes .........................................45
5.9. Interpreting owner and owner_group ........................51
5.10. Character Case Attributes ................................53
6. Access Control Attributes ......................................54
6.1. Goals .....................................................54
6.2. File Attributes Discussion ................................55
6.2.1. Attribute 12: acl ..................................55
6.2.2. Attribute 33: mode .................................70
6.3. Common Methods ............................................71
6.3.1. Interpreting an ACL ................................71
6.3.2. Computing a mode Attribute from an ACL .............72
6.4. Requirements ..............................................73
6.4.1. Setting the mode and/or ACL Attributes .............74
6.4.2. Retrieving the mode and/or ACL Attributes ..........75
6.4.3. Creating New Objects ...............................75
3. RPC and Security Flavor ........................................25
3.1. Ports and Transports ......................................25
3.1.1. Client Retransmission Behavior .....................26
3.2. Security Flavors ..........................................27
3.2.1. Security Mechanisms for NFSv4 ......................27
3.3. Security Negotiation ......................................28
3.3.1. SECINFO ............................................29
3.3.2. Security Error .....................................29
3.3.3. Callback RPC Authentication ........................29
4. Filehandles ....................................................30
4.1. Obtaining the First Filehandle ............................30
4.1.1. Root Filehandle ....................................31
4.1.2. Public Filehandle ..................................31
4.2. Filehandle Types ..........................................31
4.2.1. General Properties of a Filehandle .................32
4.2.2. Persistent Filehandle ..............................32
4.2.3. Volatile Filehandle ................................33
4.2.4. One Method of Constructing a Volatile Filehandle ...34
4.3. Client Recovery from Filehandle Expiration ................35
5. Attributes .....................................................35
5.1. REQUIRED Attributes .......................................37
5.2. RECOMMENDED Attributes ....................................37
5.3. Named Attributes ..........................................37
5.4. Classification of Attributes ..............................39
5.5. Set-Only and Get-Only Attributes ..........................40
5.6. REQUIRED Attributes - List and Definition References ......40
5.7. RECOMMENDED Attributes - List and Definition References ...41
5.8. Attribute Definitions .....................................42
5.8.1. Definitions of REQUIRED Attributes .................42
5.8.2. Definitions of Uncategorized RECOMMENDED
Attributes .........................................45
5.9. Interpreting owner and owner_group ........................51
5.10. Character Case Attributes ................................53
6. Access Control Attributes ......................................54
6.1. Goals .....................................................54
6.2. File Attributes Discussion ................................55
6.2.1. Attribute 12: acl ..................................55
6.2.2. Attribute 33: mode .................................70
6.3. Common Methods ............................................71
6.3.1. Interpreting an ACL ................................71
6.3.2. Computing a mode Attribute from an ACL .............72
6.4. Requirements ..............................................73
6.4.1. Setting the mode and/or ACL Attributes .............74
6.4.2. Retrieving the mode and/or ACL Attributes ..........75
6.4.3. Creating New Objects ...............................75
7. NFS Server Namespace ...........................................77
7.1. Server Exports ............................................77
7.2. Browsing Exports ..........................................77
7.3. Server Pseudo-File System .................................78
7.4. Multiple Roots ............................................79
7.5. Filehandle Volatility .....................................79
7.6. Exported Root .............................................79
7.7. Mount Point Crossing ......................................79
7.8. Security Policy and Namespace Presentation ................80
8. Multi-Server Namespace .........................................81
8.1. Location Attributes .......................................81
8.2. File System Presence or Absence ...........................81
8.3. Getting Attributes for an Absent File System ..............83
8.3.1. GETATTR within an Absent File System ...............83
8.3.2. READDIR and Absent File Systems ....................84
8.4. Uses of Location Information ..............................84
8.4.1. File System Replication ............................85
8.4.2. File System Migration ..............................86
8.4.3. Referrals ..........................................86
8.5. Location Entries and Server Identity ......................87
8.6. Additional Client-Side Considerations .....................88
8.7. Effecting File System Referrals ...........................89
8.7.1. Referral Example (LOOKUP) ..........................89
8.7.2. Referral Example (READDIR) .........................93
8.8. The Attribute fs_locations ................................96
9. File Locking and Share Reservations ............................98
9.1. Opens and Byte-Range Locks ................................99
9.1.1. Client ID ..........................................99
9.1.2. Server Release of Client ID .......................102
9.1.3. Use of Seqids .....................................103
9.1.4. Stateid Definition ................................104
9.1.5. Lock-Owner ........................................110
9.1.6. Use of the Stateid and Locking ....................110
9.1.7. Sequencing of Lock Requests .......................113
9.1.8. Recovery from Replayed Requests ...................114
9.1.9. Interactions of Multiple Sequence Values ..........114
9.1.10. Releasing State-Owner State ......................115
9.1.11. Use of Open Confirmation .........................116
9.2. Lock Ranges ..............................................117
9.3. Upgrading and Downgrading Locks ..........................117
9.4. Blocking Locks ...........................................118
9.5. Lease Renewal ............................................119
9.6. Crash Recovery ...........................................120
9.6.1. Client Failure and Recovery .......................120
9.6.2. Server Failure and Recovery .......................120
9.6.3. Network Partitions and Recovery ...................122
9.7. Recovery from a Lock Request Timeout or Abort ............130
9.8. Server Revocation of Locks ...............................130
7. NFS Server Namespace ...........................................77
7.1. Server Exports ............................................77
7.2. Browsing Exports ..........................................77
7.3. Server Pseudo-File System .................................78
7.4. Multiple Roots ............................................79
7.5. Filehandle Volatility .....................................79
7.6. Exported Root .............................................79
7.7. Mount Point Crossing ......................................79
7.8. Security Policy and Namespace Presentation ................80
8. Multi-Server Namespace .........................................81
8.1. Location Attributes .......................................81
8.2. File System Presence or Absence ...........................81
8.3. Getting Attributes for an Absent File System ..............83
8.3.1. GETATTR within an Absent File System ...............83
8.3.2. READDIR and Absent File Systems ....................84
8.4. Uses of Location Information ..............................84
8.4.1. File System Replication ............................85
8.4.2. File System Migration ..............................86
8.4.3. Referrals ..........................................86
8.5. Location Entries and Server Identity ......................87
8.6. Additional Client-Side Considerations .....................88
8.7. Effecting File System Referrals ...........................89
8.7.1. Referral Example (LOOKUP) ..........................89
8.7.2. Referral Example (READDIR) .........................93
8.8. The Attribute fs_locations ................................96
9. File Locking and Share Reservations ............................98
9.1. Opens and Byte-Range Locks ................................99
9.1.1. Client ID ..........................................99
9.1.2. Server Release of Client ID .......................102
9.1.3. Use of Seqids .....................................103
9.1.4. Stateid Definition ................................104
9.1.5. Lock-Owner ........................................110
9.1.6. Use of the Stateid and Locking ....................110
9.1.7. Sequencing of Lock Requests .......................113
9.1.8. Recovery from Replayed Requests ...................114
9.1.9. Interactions of Multiple Sequence Values ..........114
9.1.10. Releasing State-Owner State ......................115
9.1.11. Use of Open Confirmation .........................116
9.2. Lock Ranges ..............................................117
9.3. Upgrading and Downgrading Locks ..........................117
9.4. Blocking Locks ...........................................118
9.5. Lease Renewal ............................................119
9.6. Crash Recovery ...........................................120
9.6.1. Client Failure and Recovery .......................120
9.6.2. Server Failure and Recovery .......................120
9.6.3. Network Partitions and Recovery ...................122
9.7. Recovery from a Lock Request Timeout or Abort ............130
9.8. Server Revocation of Locks ...............................130
9.9. Share Reservations .......................................132
9.10. OPEN/CLOSE Operations ...................................132
9.10.1. Close and Retention of State Information .........133
9.11. Open Upgrade and Downgrade ..............................134
9.12. Short and Long Leases ...................................135
9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration ..............................................135
9.14. Migration, Replication, and State .......................136
9.14.1. Migration and State ..............................136
9.14.2. Replication and State ............................137
9.14.3. Notification of Migrated Lease ...................137
9.14.4. Migration and the lease_time Attribute ...........138
10. Client-Side Caching ..........................................139
10.1. Performance Challenges for Client-Side Caching ..........139
10.2. Delegation and Callbacks ................................140
10.2.1. Delegation Recovery ..............................142
10.3. Data Caching ............................................147
10.3.1. Data Caching and OPENs ...........................147
10.3.2. Data Caching and File Locking ....................148
10.3.3. Data Caching and Mandatory File Locking ..........150
10.3.4. Data Caching and File Identity ...................150
10.4. Open Delegation .........................................151
10.4.1. Open Delegation and Data Caching .................154
10.4.2. Open Delegation and File Locks ...................155
10.4.3. Handling of CB_GETATTR ...........................155
10.4.4. Recall of Open Delegation ........................158
10.4.5. OPEN Delegation Race with CB_RECALL ..............160
10.4.6. Clients That Fail to Honor Delegation Recalls ....161
10.4.7. Delegation Revocation ............................162
10.5. Data Caching and Revocation .............................162
10.5.1. Revocation Recovery for Write Open Delegation ....163
10.6. Attribute Caching .......................................164
10.7. Data and Metadata Caching and Memory-Mapped Files .......166
10.8. Name Caching ............................................168
10.9. Directory Caching .......................................169
11. Minor Versioning .............................................170
12. Internationalization .........................................170
12.1. Introduction ............................................170
12.2. Limitations on Internationalization-Related
Processing in the NFSv4 Context .........................172
12.3. Summary of Server Behavior Types ........................173
12.4. String Encoding .........................................173
12.5. Normalization ...........................................174
12.6. Types with Processing Defined by Other Internet Areas ...175
12.7. Errors Related to UTF-8 .................................177
12.8. Servers That Accept File Component Names That
Are Not Valid UTF-8 Strings .............................177
9.9. Share Reservations .......................................132
9.10. OPEN/CLOSE Operations ...................................132
9.10.1. Close and Retention of State Information .........133
9.11. Open Upgrade and Downgrade ..............................134
9.12. Short and Long Leases ...................................135
9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration ..............................................135
9.14. Migration, Replication, and State .......................136
9.14.1. Migration and State ..............................136
9.14.2. Replication and State ............................137
9.14.3. Notification of Migrated Lease ...................137
9.14.4. Migration and the lease_time Attribute ...........138
10. Client-Side Caching ..........................................139
10.1. Performance Challenges for Client-Side Caching ..........139
10.2. Delegation and Callbacks ................................140
10.2.1. Delegation Recovery ..............................142
10.3. Data Caching ............................................147
10.3.1. Data Caching and OPENs ...........................147
10.3.2. Data Caching and File Locking ....................148
10.3.3. Data Caching and Mandatory File Locking ..........150
10.3.4. Data Caching and File Identity ...................150
10.4. Open Delegation .........................................151
10.4.1. Open Delegation and Data Caching .................154
10.4.2. Open Delegation and File Locks ...................155
10.4.3. Handling of CB_GETATTR ...........................155
10.4.4. Recall of Open Delegation ........................158
10.4.5. OPEN Delegation Race with CB_RECALL ..............160
10.4.6. Clients That Fail to Honor Delegation Recalls ....161
10.4.7. Delegation Revocation ............................162
10.5. Data Caching and Revocation .............................162
10.5.1. Revocation Recovery for Write Open Delegation ....163
10.6. Attribute Caching .......................................164
10.7. Data and Metadata Caching and Memory-Mapped Files .......166
10.8. Name Caching ............................................168
10.9. Directory Caching .......................................169
11. Minor Versioning .............................................170
12. Internationalization .........................................170
12.1. Introduction ............................................170
12.2. Limitations on Internationalization-Related
Processing in the NFSv4 Context .........................172
12.3. Summary of Server Behavior Types ........................173
12.4. String Encoding .........................................173
12.5. Normalization ...........................................174
12.6. Types with Processing Defined by Other Internet Areas ...175
12.7. Errors Related to UTF-8 .................................177
12.8. Servers That Accept File Component Names That
Are Not Valid UTF-8 Strings .............................177
13. Error Values .................................................178
13.1. Error Definitions .......................................179
13.1.1. General Errors ...................................180
13.1.2. Filehandle Errors ................................181
13.1.3. Compound Structure Errors ........................183
13.1.4. File System Errors ...............................184
13.1.5. State Management Errors ..........................186
13.1.6. Security Errors ..................................187
13.1.7. Name Errors ......................................187
13.1.8. Locking Errors ...................................188
13.1.9. Reclaim Errors ...................................190
13.1.10. Client Management Errors ........................191
13.1.11. Attribute Handling Errors .......................191
13.1.12. Miscellaneous Errors ............................191
13.2. Operations and Their Valid Errors .......................192
13.3. Callback Operations and Their Valid Errors ..............200
13.4. Errors and the Operations That Use Them .................201
14. NFSv4 Requests ...............................................206
14.1. COMPOUND Procedure ......................................207
14.2. Evaluation of a COMPOUND Request ........................207
14.3. Synchronous Modifying Operations ........................208
14.4. Operation Values ........................................208
15. NFSv4 Procedures .............................................209
15.1. Procedure 0: NULL - No Operation ........................209
15.2. Procedure 1: COMPOUND - COMPOUND Operations .............210
16. NFSv4 Operations .............................................214
16.1. Operation 3: ACCESS - Check Access Rights ...............214
16.2. Operation 4: CLOSE - Close File .........................217
16.3. Operation 5: COMMIT - Commit Cached Data ................218
16.4. Operation 6: CREATE - Create a Non-regular File Object ..221
16.5. Operation 7: DELEGPURGE - Purge Delegations
Awaiting Recovery .......................................224
16.6. Operation 8: DELEGRETURN - Return Delegation ............226
16.7. Operation 9: GETATTR - Get Attributes ...................227
16.8. Operation 10: GETFH - Get Current Filehandle ............229
16.9. Operation 11: LINK - Create Link to a File ..............230
16.10. Operation 12: LOCK - Create Lock .......................232
16.11. Operation 13: LOCKT - Test for Lock ....................236
16.12. Operation 14: LOCKU - Unlock File ......................238
16.13. Operation 15: LOOKUP - Look Up Filename ................240
16.14. Operation 16: LOOKUPP - Look Up Parent Directory .......242
16.15. Operation 17: NVERIFY - Verify Difference in
Attributes .............................................243
16.16. Operation 18: OPEN - Open a Regular File ...............245
13. Error Values .................................................178
13.1. Error Definitions .......................................179
13.1.1. General Errors ...................................180
13.1.2. Filehandle Errors ................................181
13.1.3. Compound Structure Errors ........................183
13.1.4. File System Errors ...............................184
13.1.5. State Management Errors ..........................186
13.1.6. Security Errors ..................................187
13.1.7. Name Errors ......................................187
13.1.8. Locking Errors ...................................188
13.1.9. Reclaim Errors ...................................190
13.1.10. Client Management Errors ........................191
13.1.11. Attribute Handling Errors .......................191
13.1.12. Miscellaneous Errors ............................191
13.2. Operations and Their Valid Errors .......................192
13.3. Callback Operations and Their Valid Errors ..............200
13.4. Errors and the Operations That Use Them .................201
14. NFSv4 Requests ...............................................206
14.1. COMPOUND Procedure ......................................207
14.2. Evaluation of a COMPOUND Request ........................207
14.3. Synchronous Modifying Operations ........................208
14.4. Operation Values ........................................208
15. NFSv4 Procedures .............................................209
15.1. Procedure 0: NULL - No Operation ........................209
15.2. Procedure 1: COMPOUND - COMPOUND Operations .............210
16. NFSv4 Operations .............................................214
16.1. Operation 3: ACCESS - Check Access Rights ...............214
16.2. Operation 4: CLOSE - Close File .........................217
16.3. Operation 5: COMMIT - Commit Cached Data ................218
16.4. Operation 6: CREATE - Create a Non-regular File Object ..221
16.5. Operation 7: DELEGPURGE - Purge Delegations
Awaiting Recovery .......................................224
16.6. Operation 8: DELEGRETURN - Return Delegation ............226
16.7. Operation 9: GETATTR - Get Attributes ...................227
16.8. Operation 10: GETFH - Get Current Filehandle ............229
16.9. Operation 11: LINK - Create Link to a File ..............230
16.10. Operation 12: LOCK - Create Lock .......................232
16.11. Operation 13: LOCKT - Test for Lock ....................236
16.12. Operation 14: LOCKU - Unlock File ......................238
16.13. Operation 15: LOOKUP - Look Up Filename ................240
16.14. Operation 16: LOOKUPP - Look Up Parent Directory .......242
16.15. Operation 17: NVERIFY - Verify Difference in
Attributes .............................................243
16.16. Operation 18: OPEN - Open a Regular File ...............245
16.17. Operation 19: OPENATTR - Open Named Attribute
Directory ..............................................256
16.18. Operation 20: OPEN_CONFIRM - Confirm Open ..............257
16.19. Operation 21: OPEN_DOWNGRADE - Reduce Open File
Access .................................................260
16.20. Operation 22: PUTFH - Set Current Filehandle ...........262
16.21. Operation 23: PUTPUBFH - Set Public Filehandle .........263
16.22. Operation 24: PUTROOTFH - Set Root Filehandle ..........265
16.23. Operation 25: READ - Read from File ....................266
16.24. Operation 26: READDIR - Read Directory .................269
16.25. Operation 27: READLINK - Read Symbolic Link ............273
16.26. Operation 28: REMOVE - Remove File System Object .......274
16.27. Operation 29: RENAME - Rename Directory Entry ..........276
16.28. Operation 30: RENEW - Renew a Lease ....................278
16.29. Operation 31: RESTOREFH - Restore Saved Filehandle .....280
16.30. Operation 32: SAVEFH - Save Current Filehandle .........281
16.31. Operation 33: SECINFO - Obtain Available Security ......282
16.32. Operation 34: SETATTR - Set Attributes .................286
16.33. Operation 35: SETCLIENTID - Negotiate Client ID ........289
16.34. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID ..293
16.35. Operation 37: VERIFY - Verify Same Attributes ..........297
16.36. Operation 38: WRITE - Write to File ....................299
16.37. Operation 39: RELEASE_LOCKOWNER - Release
Lock-Owner State .......................................304
16.38. Operation 10044: ILLEGAL - Illegal Operation ...........305
17. NFSv4 Callback Procedures ....................................306
17.1. Procedure 0: CB_NULL - No Operation .....................306
17.2. Procedure 1: CB_COMPOUND - COMPOUND Operations ..........307
18. NFSv4 Callback Operations ....................................309
18.1. Operation 3: CB_GETATTR - Get Attributes ................309
18.2. Operation 4: CB_RECALL - Recall an Open Delegation ......310
18.3. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation ...............................................311
19. Security Considerations ......................................312
20. IANA Considerations ..........................................314
20.1. Named Attribute Definitions .............................314
20.1.1. Initial Registry .................................315
20.1.2. Updating Registrations ...........................315
20.2. Updates to Existing IANA Registries .....................315
21. References ...................................................316
21.1. Normative References ....................................316
21.2. Informative References ..................................318
Acknowledgments ..................................................322
Authors' Addresses ...............................................323
16.17. Operation 19: OPENATTR - Open Named Attribute
Directory ..............................................256
16.18. Operation 20: OPEN_CONFIRM - Confirm Open ..............257
16.19. Operation 21: OPEN_DOWNGRADE - Reduce Open File
Access .................................................260
16.20. Operation 22: PUTFH - Set Current Filehandle ...........262
16.21. Operation 23: PUTPUBFH - Set Public Filehandle .........263
16.22. Operation 24: PUTROOTFH - Set Root Filehandle ..........265
16.23. Operation 25: READ - Read from File ....................266
16.24. Operation 26: READDIR - Read Directory .................269
16.25. Operation 27: READLINK - Read Symbolic Link ............273
16.26. Operation 28: REMOVE - Remove File System Object .......274
16.27. Operation 29: RENAME - Rename Directory Entry ..........276
16.28. Operation 30: RENEW - Renew a Lease ....................278
16.29. Operation 31: RESTOREFH - Restore Saved Filehandle .....280
16.30. Operation 32: SAVEFH - Save Current Filehandle .........281
16.31. Operation 33: SECINFO - Obtain Available Security ......282
16.32. Operation 34: SETATTR - Set Attributes .................286
16.33. Operation 35: SETCLIENTID - Negotiate Client ID ........289
16.34. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID ..293
16.35. Operation 37: VERIFY - Verify Same Attributes ..........297
16.36. Operation 38: WRITE - Write to File ....................299
16.37. Operation 39: RELEASE_LOCKOWNER - Release
Lock-Owner State .......................................304
16.38. Operation 10044: ILLEGAL - Illegal Operation ...........305
17. NFSv4 Callback Procedures ....................................306
17.1. Procedure 0: CB_NULL - No Operation .....................306
17.2. Procedure 1: CB_COMPOUND - COMPOUND Operations ..........307
18. NFSv4 Callback Operations ....................................309
18.1. Operation 3: CB_GETATTR - Get Attributes ................309
18.2. Operation 4: CB_RECALL - Recall an Open Delegation ......310
18.3. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation ...............................................311
19. Security Considerations ......................................312
20. IANA Considerations ..........................................314
20.1. Named Attribute Definitions .............................314
20.1.1. Initial Registry .................................315
20.1.2. Updating Registrations ...........................315
20.2. Updates to Existing IANA Registries .....................315
21. References ...................................................316
21.1. Normative References ....................................316
21.2. Informative References ..................................318
Acknowledgments ..................................................322
Authors' Addresses ...............................................323
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119], except where "REQUIRED" and "RECOMMENDED" are used as qualifiers to distinguish classes of attributes as described in Sections 1.4.3.2 and 5 of this document.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释，但“要求”和“建议”除外用作限定符，以区分本文件第1.4.3.2和5节所述的属性类别。
The Network File System version 4 (NFSv4) protocol is a further revision of the NFS protocol defined already by versions 2 [RFC1094] and 3 [RFC1813]. It retains the essential characteristics of previous versions: design for easy recovery; independent of transport protocols, operating systems, and file systems; simplicity; and good performance. The NFSv4 revision has the following goals:
网络文件系统版本4（NFSv4）协议是版本2[RFC1094]和版本3[RFC1813]已经定义的NFS协议的进一步修订版。它保留了以前版本的基本特征：易于恢复的设计；独立于传输协议、操作系统和文件系统；简单性能良好。NFSv4修订版具有以下目标：
o Improved access and good performance on the Internet.
o 改进了Internet上的访问和良好性能。
The protocol is designed to transit firewalls easily, perform well where latency is high and bandwidth is low, and scale to very large numbers of clients per server.
该协议设计用于轻松传输防火墙，在延迟高、带宽低的情况下性能良好，并可扩展到每台服务器上的大量客户端。
o Strong security with negotiation built into the protocol.
o 协议内置协商功能，安全性强。
The protocol builds on the work of the Open Network Computing (ONC) Remote Procedure Call (RPC) working group in supporting the RPCSEC_GSS protocol (see both [RFC2203] and [RFC5403]). Additionally, the NFSv4 protocol provides a mechanism to allow clients and servers the ability to negotiate security and require clients and servers to support a minimal set of security schemes.
该协议建立在开放网络计算（ONC）远程过程调用（RPC）工作组支持RPCSEC_GSS协议的工作基础上（参见[RFC2203]和[RFC5403]）。此外，NFSv4协议提供了一种机制，允许客户端和服务器协商安全性，并要求客户端和服务器支持一组最小的安全方案。
o Good cross-platform interoperability.
o 良好的跨平台互操作性。
The protocol features a file system model that provides a useful, common set of features that does not unduly favor one file system or operating system over another.
该协议以一个文件系统模型为特色，该模型提供了一组有用的、通用的特性，这些特性不会过分偏向于一个文件系统或操作系统而不是另一个文件系统或操作系统。
o Designed for protocol extensions.
o 专为协议扩展而设计。
The protocol is designed to accept standard extensions that do not compromise backward compatibility.
该协议旨在接受不损害向后兼容性的标准扩展。
This document, together with the companion External Data Representation (XDR) description document [RFC7531], obsoletes [RFC3530] as the authoritative document describing NFSv4. It does not introduce any over-the-wire protocol changes, in the sense that previously valid requests remain valid.
本文件连同配套的外部数据表示（XDR）描述文件[RFC7531]一起，将[RFC3530]废弃为描述NFSv4的权威文件。它不会引入任何跨线协议更改，因为以前有效的请求仍然有效。
The "Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description" [RFC7531] contains the definitions in XDR description language of the constructs used by the protocol. Inside this document, several of the constructs are reproduced for purposes of explanation. The reader is warned of the possibility of errors in the reproduced constructs outside of [RFC7531]. For any part of the document that is inconsistent with [RFC7531], [RFC7531] is to be considered authoritative.
“网络文件系统（NFS）第4版外部数据表示标准（XDR）描述”[RFC7531]包含协议使用的结构的XDR描述语言定义。在本文件中，为了便于解释，复制了一些结构。读者被警告在[RFC7531]之外的复制结构中可能存在错误。对于文件中与[RFC7531]不一致的任何部分，[RFC7531]将被视为权威。
To provide a reasonable context for the reader, the major features of the NFSv4 protocol will be reviewed in brief. This is done to provide an appropriate context for both the reader who is familiar with the previous versions of the NFS protocol and the reader who is new to the NFS protocols. For the reader new to the NFS protocols, some fundamental knowledge is still expected. The reader should be familiar with the XDR and RPC protocols as described in [RFC4506] and [RFC5531]. A basic knowledge of file systems and distributed file systems is expected as well.
为了给读者提供一个合理的上下文，将简要回顾NFSv4协议的主要特征。这样做是为了为熟悉以前版本的NFS协议的读者和不熟悉NFS协议的读者提供适当的上下文。对于初次接触NFS协议的读者，仍然需要一些基础知识。读者应熟悉[RFC4506]和[RFC5531]中所述的XDR和RPC协议。具备文件系统和分布式文件系统的基本知识。
As with previous versions of NFS, the XDR and RPC mechanisms used for the NFSv4 protocol are those defined in [RFC4506] and [RFC5531]. To meet end-to-end security requirements, the RPCSEC_GSS framework (both version 1 in [RFC2203] and version 2 in [RFC5403]) will be used to extend the basic RPC security. With the use of RPCSEC_GSS, various mechanisms can be provided to offer authentication, integrity, and privacy to the NFSv4 protocol. Kerberos V5 will be used as described in [RFC4121] to provide one security framework. With the use of RPCSEC_GSS, other mechanisms may also be specified and used for NFSv4 security.
与以前版本的NFS一样，NFSv4协议使用的XDR和RPC机制是[RFC4506]和[RFC5531]中定义的机制。为了满足端到端安全性要求，将使用RPCSEC_GSS框架（RFC2203中的版本1和RFC5403中的版本2）扩展基本RPC安全性。通过使用RPCSEC_GSS，可以提供各种机制来为NFSv4协议提供身份验证、完整性和隐私。Kerberos V5将按[RFC4121]中所述使用，以提供一个安全框架。通过使用RPCSEC_GSS，还可以指定其他机制并用于NFSv4安全性。
To enable in-band security negotiation, the NFSv4 protocol has added a new operation that provides the client with a method of querying the server about its policies regarding which security mechanisms must be used for access to the server's file system resources. With this, the client can securely match the security mechanism that meets the policies specified at both the client and server.
为了启用带内安全协商，NFSv4协议添加了一个新的操作，该操作为客户端提供了一种查询服务器策略的方法，该策略涉及访问服务器文件系统资源必须使用哪些安全机制。这样，客户机就可以安全地匹配满足客户机和服务器上指定的策略的安全机制。
A significant departure from the previous versions of the NFS protocol is the introduction of the COMPOUND procedure. For the NFSv4 protocol, there are two RPC procedures: NULL and COMPOUND. The COMPOUND procedure is defined in terms of operations, and these operations correspond more closely to the traditional NFS procedures.
与以前版本的NFS协议不同的一个重要区别是引入了复合过程。对于NFSv4协议，有两个RPC过程：NULL和component。复合过程是根据操作定义的，这些操作与传统的NFS过程更接近。
With the use of the COMPOUND procedure, the client is able to build simple or complex requests. These COMPOUND requests allow for a reduction in the number of RPCs needed for logical file system operations. For example, without previous contact with a server a client will be able to read data from a file in one request by combining LOOKUP, OPEN, and READ operations in a single COMPOUND RPC. With previous versions of the NFS protocol, this type of single request was not possible.
通过使用复合过程，客户机能够构建简单或复杂的请求。这些复合请求允许减少逻辑文件系统操作所需的RPC数量。例如，如果以前没有与服务器联系，客户端将能够通过在单个复合RPC中组合查找、打开和读取操作，在一个请求中从文件读取数据。对于以前版本的NFS协议，这种类型的单一请求是不可能的。
The model used for COMPOUND is very simple. There is no logical OR or ANDing of operations. The operations combined within a COMPOUND request are evaluated in order by the server. Once an operation returns a failing result, the evaluation ends and the results of all evaluated operations are returned to the client.
用于化合物的模型非常简单。操作之间没有逻辑或AND。复合请求中组合的操作由服务器按顺序进行评估。一旦操作返回失败的结果，评估将结束，所有评估操作的结果将返回给客户端。
The NFSv4 protocol continues to have the client refer to a file or directory at the server by a "filehandle". The COMPOUND procedure has a method of passing a filehandle from one operation to another within the sequence of operations. There is a concept of a current filehandle and a saved filehandle. Most operations use the current filehandle as the file system object to operate upon. The saved filehandle is used as temporary filehandle storage within a COMPOUND procedure as well as an additional operand for certain operations.
NFSv4协议继续让客户端通过“文件句柄”引用服务器上的文件或目录。复合过程有一种在操作序列中将文件句柄从一个操作传递到另一个操作的方法。有当前文件句柄和已保存文件句柄的概念。大多数操作使用当前文件句柄作为要操作的文件系统对象。保存的文件句柄用作复合过程中的临时文件句柄存储，以及某些操作的附加操作数。
The general file system model used for the NFSv4 protocol is the same as previous versions. The server file system is hierarchical, with the regular files contained within being treated as opaque byte streams. In a slight departure, file and directory names are encoded with UTF-8 to deal with the basics of internationalization.
NFSv4协议使用的通用文件系统模型与以前的版本相同。服务器文件系统是分层的，其中包含的常规文件被视为不透明的字节流。稍微不同的是，文件名和目录名用UTF-8编码，以处理国际化的基础知识。
The NFSv4 protocol does not require a separate protocol to provide for the initial mapping between pathname and filehandle. Instead of using the older MOUNT protocol for this mapping, the server provides a root filehandle that represents the logical root or top of the file system tree provided by the server. The server provides multiple file systems by gluing them together with pseudo-file systems. These pseudo-file systems provide for potential gaps in the pathnames between real file systems.
NFSv4协议不需要单独的协议来提供路径名和文件句柄之间的初始映射。服务器提供了一个根文件句柄，表示服务器提供的文件系统树的逻辑根或顶部，而不是使用较旧的装载协议进行此映射。服务器通过将多个文件系统与伪文件系统粘合在一起来提供多个文件系统。这些伪文件系统为实际文件系统之间的路径名提供了潜在的间隙。
In previous versions of the NFS protocol, the filehandle provided by the server was guaranteed to be valid or persistent for the lifetime of the file system object to which it referred. For some server implementations, this persistence requirement has been difficult to meet. For the NFSv4 protocol, this requirement has been relaxed by introducing another type of filehandle -- volatile. With persistent and volatile filehandle types, the server implementation can match the abilities of the file system at the server along with the operating environment. The client will have knowledge of the type of filehandle being provided by the server and can be prepared to deal with the semantics of each.
在NFS协议的早期版本中，服务器提供的filehandle保证在其引用的文件系统对象的生命周期内有效或持久。对于某些服务器实现，这种持久性需求一直难以满足。对于NFSv4协议，通过引入另一种类型的文件句柄（volatile）放宽了这一要求。对于持久性和易失性文件句柄类型，服务器实现可以与服务器上的文件系统的能力以及操作环境相匹配。客户机将了解服务器提供的文件句柄类型，并准备好处理每个文件句柄的语义。
The NFSv4 protocol has a rich and extensible file object attribute structure, which is divided into REQUIRED, RECOMMENDED, and named attributes (see Section 5).
NFSv4协议具有丰富且可扩展的文件对象属性结构，该结构分为必需属性、推荐属性和命名属性（参见第5节）。
Several (but not all) of the REQUIRED attributes are derived from the attributes of NFSv3 (see the definition of the fattr3 data type in [RFC1813]). An example of a REQUIRED attribute is the file object's type (Section 5.8.1.2) so that regular files can be distinguished from directories (also known as folders in some operating environments) and other types of objects. REQUIRED attributes are discussed in Section 5.1.
几个（但不是全部）必需的属性是从NFSv3的属性派生的（参见[RFC1813]中fattr3数据类型的定义）。所需属性的一个示例是文件对象的类型（第5.8.1.2节），以便将常规文件与目录（在某些操作环境中也称为文件夹）和其他类型的对象区分开来。第5.1节讨论了所需属性。
An example of the RECOMMENDED attributes is an acl (Section 6.2.1). This attribute defines an Access Control List (ACL) on a file object. An ACL provides file access control beyond the model used in NFSv3. The ACL definition allows for specification of specific sets of permissions for individual users and groups. In addition, ACL inheritance allows propagation of access permissions and restriction down a directory tree as file system objects are created. RECOMMENDED attributes are discussed in Section 5.2.
推荐属性的一个示例是acl（第6.2.1节）。此属性定义文件对象上的访问控制列表（ACL）。ACL提供了NFSv3中使用的模型之外的文件访问控制。ACL定义允许为单个用户和组指定特定的权限集。此外，ACL继承允许在创建文件系统对象时沿目录树传播访问权限和限制。第5.2节讨论了推荐属性。
A named attribute is an opaque byte stream that is associated with a directory or file and referred to by a string name. Named attributes are meant to be used by client applications as a method to associate application-specific data with a regular file or directory. NFSv4.1 modifies named attributes relative to NFSv4.0 by tightening the allowed operations in order to prevent the development of non-interoperable implementations. Named attributes are discussed in Section 5.3.
命名属性是与目录或文件关联并由字符串名称引用的不透明字节流。命名属性被客户机应用程序用作将特定于应用程序的数据与常规文件或目录关联的方法。NFSv4.1通过收紧允许的操作来修改相对于NFSv4.0的命名属性，以防止开发不可互操作的实现。命名属性在第5.3节中讨论。
A single-server namespace is the file system hierarchy that the server presents for remote access. It is a proper subset of all the file systems available locally. NFSv4 contains a number of features to allow implementation of namespaces that cross server boundaries and that allow and facilitate a non-disruptive transfer of support for individual file systems between servers. They are all based upon attributes that allow one file system to specify alternative or new locations for that file system. That is, just as a client might traverse across local file systems on a single server, it can now traverse to a remote file system on a different server.
单个服务器名称空间是服务器为远程访问提供的文件系统层次结构。它是本地可用的所有文件系统的适当子集。NFSv4包含许多功能，允许实现跨越服务器边界的名称空间，并允许和促进在服务器之间无中断地传输对单个文件系统的支持。它们都基于允许一个文件系统为该文件系统指定替代位置或新位置的属性。也就是说，正如客户机可以跨单个服务器上的本地文件系统进行遍历一样，它现在可以遍历到不同服务器上的远程文件系统。
These attributes may be used together with the concept of absent file systems, which provide specifications for additional locations but no actual file system content. This allows a number of important facilities:
这些属性可以与缺席文件系统的概念一起使用，缺席文件系统为其他位置提供规范，但不提供实际的文件系统内容。这允许使用一些重要的设施：
o Location attributes may be used with absent file systems to implement referrals whereby one server may direct the client to a file system provided by another server. This allows extensive multi-server namespaces to be constructed.
o 位置属性可用于缺少的文件系统，以实现引用，其中一台服务器可将客户端指向另一台服务器提供的文件系统。这允许构造广泛的多服务器名称空间。
o Location attributes may be provided for present file systems to provide the locations of alternative file system instances or replicas to be used in the event that the current file system instance becomes unavailable.
o 可以为当前文件系统提供位置属性，以提供在当前文件系统实例变得不可用时使用的替代文件系统实例或副本的位置。
o Location attributes may be provided when a previously present file system becomes absent. This allows non-disruptive migration of file systems to alternative servers.
o 当以前存在的文件系统不存在时，可以提供位置属性。这允许无中断地将文件系统迁移到其他服务器。
The NFSv4 protocol introduces OPEN and CLOSE operations. The OPEN operation provides a single point where file lookup, creation, and share semantics (see Section 9.9) can be combined. The CLOSE operation also provides for the release of state accumulated by OPEN.
NFSv4协议引入了打开和关闭操作。“打开”操作提供了一个单一点，在这里可以组合文件查找、创建和共享语义（请参见第9.9节）。关闭操作还可释放打开累积的状态。
With the NFSv4 protocol, the support for byte-range file locking is part of the NFS protocol. The file locking support is structured so that an RPC callback mechanism is not required. This is a departure from the previous versions of the NFS file locking protocol, Network Lock Manager (NLM) [RFC1813]. The state associated with file locks is maintained at the server under a lease-based model. The server defines a single lease period for all state held by an NFS client.
对于NFSv4协议，对字节范围文件锁定的支持是NFS协议的一部分。文件锁定支持的结构不需要RPC回调机制。这与以前版本的NFS文件锁定协议Network Lock Manager（NLM）[RFC1813]不同。与文件锁关联的状态在基于租约的模型下在服务器上维护。服务器为NFS客户端持有的所有状态定义一个租用期。
If the client does not renew its lease within the defined period, all state associated with the client's lease may be released by the server. The client may renew its lease by use of the RENEW operation or implicitly by use of other operations (primarily READ).
如果客户端未在定义的期限内续订其租约，则服务器可能会释放与客户端租约关联的所有状态。客户可以通过使用“续订”操作或通过使用其他操作（主要是READ）来间接续订其租约。
The file, attribute, and directory caching for the NFSv4 protocol is similar to previous versions. Attributes and directory information are cached for a duration determined by the client. At the end of a predefined timeout, the client will query the server to see if the related file system object has been updated.
NFSv4协议的文件、属性和目录缓存与以前的版本类似。属性和目录信息的缓存时间由客户端确定。在预定义超时结束时，客户端将查询服务器，查看相关文件系统对象是否已更新。
For file data, the client checks its cache validity when the file is opened. A query is sent to the server to determine if the file has been changed. Based on this information, the client determines if the data cache for the file should be kept or released. Also, when the file is closed, any modified data is written to the server.
对于文件数据，客户端在打开文件时检查其缓存有效性。将向服务器发送查询，以确定文件是否已更改。根据此信息，客户机确定是保留还是释放文件的数据缓存。此外，当文件关闭时，任何修改的数据都会写入服务器。
If an application wants to serialize access to file data, file locking of the file data ranges in question should be used.
若应用程序想要序列化对文件数据的访问，那个么应该使用有问题的文件数据范围的文件锁定。
The major addition to NFSv4 in the area of caching is the ability of the server to delegate certain responsibilities to the client. When the server grants a delegation for a file to a client, the client is guaranteed certain semantics with respect to the sharing of that file with other clients. At OPEN, the server may provide the client either a read (OPEN_DELEGATE_READ) or a write (OPEN_DELEGATE_WRITE) delegation for the file (see Section 10.4). If the client is granted an OPEN_DELEGATE_READ delegation, it is assured that no other client has the ability to write to the file for the duration of the delegation. If the client is granted an OPEN_DELEGATE_WRITE delegation, the client is assured that no other client has read or write access to the file.
NFSv4在缓存领域的主要新增功能是服务器将某些职责委托给客户端的能力。当服务器向客户机授予文件的委托时，客户机可以保证与其他客户机共享该文件时具有一定的语义。打开时，服务器可以为客户端提供文件的读取（打开\u委托\u读取）或写入（打开\u委托\u写入）委托（参见第10.4节）。如果客户机被授予OPEN_DELEGATE_READ委派，则可以确保在委派期间没有其他客户机能够写入文件。如果客户机被授予OPEN_DELEGATE_WRITE委托，则可以确保没有其他客户机对该文件具有读写访问权限。
Delegations can be recalled by the server. If another client requests access to the file in such a way that the access conflicts with the granted delegation, the server is able to notify the initial client and recall the delegation. This requires that a callback path exist between the server and client. If this callback path does not exist, then delegations cannot be granted. The essence of a delegation is that it allows the client to locally service operations such as OPEN, CLOSE, LOCK, LOCKU, READ, or WRITE without immediate interaction with the server.
服务器可以调用委托。如果另一个客户端请求访问该文件，并且访问与授予的委托冲突，则服务器能够通知初始客户端并重新调用该委托。这要求在服务器和客户端之间存在回调路径。如果此回调路径不存在，则无法授予委派。委托的本质是，它允许客户端在本地为操作（如打开、关闭、锁定、锁定、读取或写入）提供服务，而无需立即与服务器交互。
The following definitions are provided for the purpose of providing an appropriate context for the reader.
以下定义旨在为读者提供适当的上下文。
Absent File System: A file system is "absent" when a namespace component does not have a backing file system.
缺少文件系统：当命名空间组件没有支持文件系统时，文件系统是“缺少”的。
Anonymous Stateid: The Anonymous Stateid is a special locking object and is defined in Section 9.1.4.3.
匿名Stateid：匿名Stateid是一个特殊的锁定对象，在第9.1.4.3节中定义。
Byte: In this document, a byte is an octet, i.e., a datum exactly 8 bits in length.
字节：在本文档中，字节是八位字节，即长度正好为8位的数据。
Client: The client is the entity that accesses the NFS server's resources. The client may be an application that contains the logic to access the NFS server directly. The client may also be the traditional operating system client that provides remote file system services for a set of applications.
客户端：客户端是访问NFS服务器资源的实体。客户端可能是包含直接访问NFS服务器的逻辑的应用程序。客户端也可以是为一组应用程序提供远程文件系统服务的传统操作系统客户端。
With reference to byte-range locking, the client is also the entity that maintains a set of locks on behalf of one or more applications. This client is responsible for crash or failure recovery for those locks it manages.
关于字节范围锁定，客户机也是代表一个或多个应用程序维护一组锁的实体。此客户端负责其管理的锁的崩溃或故障恢复。
Note that multiple clients may share the same transport and connection, and multiple clients may exist on the same network node.
请注意，多个客户端可能共享相同的传输和连接，并且多个客户端可能存在于同一网络节点上。
Client ID: The client ID is a 64-bit quantity used as a unique, shorthand reference to a client-supplied verifier and ID. The server is responsible for supplying the client ID.
客户机ID：客户机ID是一个64位的数量，用作对客户机提供的验证器和ID的唯一、简写引用。服务器负责提供客户机ID。
File System: The file system is the collection of objects on a server that share the same fsid attribute (see Section 5.8.1.9).
文件系统：文件系统是服务器上共享相同fsid属性的对象的集合（参见第5.8.1.9节）。
Lease: A lease is an interval of time defined by the server for which the client is irrevocably granted a lock. At the end of a lease period the lock may be revoked if the lease has not been extended. The lock must be revoked if a conflicting lock has been granted after the lease interval.
租约：租约是由服务器定义的一段时间间隔，对于该时间间隔，客户端被不可撤销地授予锁。在租赁期结束时，如果租赁期未延长，则可撤销锁定。如果在租约间隔后授予了冲突的锁，则必须撤销该锁。
All leases granted by a server have the same fixed duration. Note that the fixed interval duration was chosen to alleviate the expense a server would have in maintaining state about variable-length leases across server failures.
服务器授予的所有租约具有相同的固定期限。请注意，选择固定间隔持续时间是为了减轻服务器在维护跨服务器故障的可变长度租约状态时的开销。
Lock: The term "lock" is used to refer to record (byte-range) locks as well as share reservations unless specifically stated otherwise.
锁定：除非另有特别说明，否则术语“锁定”用于指记录（字节范围）锁定以及共享保留。
Lock-Owner: Each byte-range lock is associated with a specific lock-owner and an open-owner. The lock-owner consists of a client ID and an opaque owner string. The client presents this to the server to establish the ownership of the byte-range lock as needed.
锁所有者：每个字节范围锁都与特定的锁所有者和打开的所有者相关联。锁所有者由客户端ID和不透明所有者字符串组成。客户机根据需要将其呈现给服务器，以建立字节范围锁的所有权。
Open-Owner: Each open file is associated with a specific open-owner, which consists of a client ID and an opaque owner string. The client presents this to the server to establish the ownership of the open as needed.
打开所有者：每个打开的文件都与特定的打开所有者关联，该所有者由客户端ID和不透明的所有者字符串组成。客户机将此信息呈现给服务器，以根据需要确定开放式数据库的所有权。
READ Bypass Stateid: The READ Bypass Stateid is a special locking object and is defined in Section 9.1.4.3.
读取旁路Stateid：读取旁路Stateid是一个特殊的锁定对象，在第9.1.4.3节中定义。
Server: The "server" is the entity responsible for coordinating client access to a set of file systems.
服务器：“服务器”是负责协调客户端对一组文件系统的访问的实体。
Stable Storage: NFSv4 servers must be able to recover without data loss from multiple power failures (including cascading power failures, that is, several power failures in quick succession), operating system failures, and hardware failure of components other than the storage medium itself (for example, disk, non-volatile RAM).
稳定存储：NFSv4服务器必须能够从多个电源故障（包括级联电源故障，即连续几次电源故障）、操作系统故障和存储介质本身以外的组件（例如，磁盘、非易失性RAM）的硬件故障中恢复而不丢失数据。
Some examples of stable storage that are allowable for an NFS server include:
NFS服务器允许的一些稳定存储示例包括：
(1) Media commit of data. That is, the modified data has been successfully written to the disk media -- for example, the disk platter.
(1) 媒体提交数据。也就是说，修改后的数据已成功写入磁盘介质——例如，磁盘盘片。
(2) An immediate reply disk drive with battery-backed on-drive intermediate storage or uninterruptible power system (UPS).
(2) 立即回复磁盘驱动器，在驱动器中间存储器或不间断电源系统（UPS）上备有电池。
(3) Server commit of data with battery-backed intermediate storage and recovery software.
(3) 使用电池备份的中间存储和恢复软件进行服务器数据提交。
(4) Cache commit with UPS and recovery software.
(4) 使用UPS和恢复软件进行缓存提交。
Stateid: A stateid is a 128-bit quantity returned by a server that uniquely identifies the open and locking states provided by the server for a specific open-owner or lock-owner/open-owner pair for a specific file and type of lock.
Stateid：Stateid是服务器返回的128位数量，它唯一标识服务器为特定打开所有者或特定文件和锁类型的锁所有者/打开所有者对提供的打开和锁定状态。
Verifier: A verifier is a 64-bit quantity generated by the client that the server can use to determine if the client has restarted and lost all previous lock state.
验证器：验证器是由客户端生成的64位数量，服务器可以使用它来确定客户端是否已重新启动并丢失所有以前的锁定状态。
The main changes from RFC 3530 [RFC3530] are:
RFC 3530[RFC3530]的主要变化如下：
o The XDR definition has been moved to a companion document [RFC7531].
o XDR定义已移至附带文档[RFC7531]。
o The IETF intellectual property statements were updated to the latest version.
o IETF知识产权声明已更新至最新版本。
o There is a restructured and more complete explanation of multi-server namespace features.
o 对多服务器名称空间特性有一个重新构造的更完整的解释。
o The handling of domain names was updated to reflect Internationalized Domain Names in Applications (IDNA) [RFC5891].
o 对域名的处理进行了更新，以反映应用程序中的国际化域名（IDNA）[RFC5891]。
o The previously required LIPKEY and SPKM-3 security mechanisms have been removed.
o 先前需要的LIPKEY和SPKM-3安全机制已被删除。
o Some clarification was provided regarding a client re-establishing callback information to the new server if state has been migrated.
o 对于在状态已迁移的情况下客户端重新建立新服务器的回调信息，提供了一些说明。
o A third edge case was added for courtesy locks and network partitions.
o 为门控锁和网络分区添加了第三个edge案例。
o The definition of stateid was strengthened.
o 国家ID的定义得到加强。
The definition of the NFSv4 protocol in [RFC3530] replaced and obsoleted the definition present in [RFC3010]. While portions of the two documents remained the same, there were substantive changes in others. The changes made between [RFC3010] and [RFC3530] reflect implementation experience and further review of the protocol.
[RFC3530]中NFSv4协议的定义取代并废除了[RFC3010]中的定义。虽然这两份文件的某些部分保持不变，但其他部分有实质性变化。[RFC3010]和[RFC3530]之间的变更反映了实施经验和协议的进一步审查。
The following list is not inclusive of all changes but presents some of the most notable changes or additions made:
以下列表不包括所有更改，但列出了一些最显著的更改或添加：
o The state model has added an open_owner4 identifier. This was done to accommodate POSIX-based clients and the model they use for file locking. For POSIX clients, an open_owner4 would correspond to a file descriptor potentially shared amongst a set of processes and the lock_owner4 identifier would correspond to a process that is locking a file.
o 状态模型添加了一个open_owner4标识符。这样做是为了适应基于POSIX的客户端及其用于文件锁定的模型。对于POSIX客户端，open_owner4将对应于一组进程之间可能共享的文件描述符，lock_owner4标识符将对应于锁定文件的进程。
o Added clarifications and error conditions for the handling of the owner and group attributes. Since these attributes are string based (as opposed to the numeric uid/gid of previous versions of NFS), translations may not be available and hence the changes made.
o 为处理所有者和组属性添加了澄清和错误条件。由于这些属性是基于字符串的（与以前版本的NFS的数字uid/gid相反），翻译可能不可用，因此会进行更改。
o Added clarifications for the ACL and mode attributes to address evaluation and partial support.
o 增加了ACL和模式属性的澄清，以解决评估和部分支持问题。
o For identifiers that are defined as XDR opaque, set limits on their size.
o 对于定义为XDR不透明的标识符，设置其大小限制。
o Added the mounted_on_fileid attribute to allow POSIX clients to correctly construct local mounts.
o 添加了mounted_on_fileid属性，以允许POSIX客户端正确构造本地装载。
o Modified the SETCLIENTID/SETCLIENTID_CONFIRM operations to deal correctly with confirmation details along with adding the ability to specify new client callback information. Also added clarification of the callback information itself.
o 修改了SETCLIENTID/SETCLIENTID_确认操作，以正确处理确认详细信息，并添加了指定新客户端回调信息的功能。还添加了回调信息本身的澄清。
o Added a new operation RELEASE_LOCKOWNER to enable notifying the server that a lock_owner4 will no longer be used by the client.
o 添加了一个新的操作RELEASE_LOCKOWNER，以允许通知服务器客户端将不再使用锁所有者4。
o Added RENEW operation changes to identify the client correctly and allow for additional error returns.
o 添加了续订操作更改，以正确识别客户端并允许其他错误返回。
o Verified error return possibilities for all operations.
o 已验证所有操作的错误返回可能性。
o Removed use of the pathname4 data type from LOOKUP and OPEN in favor of having the client construct a sequence of LOOKUP operations to achieve the same effect.
o 从LOOKUP和OPEN中删除了pathname4数据类型的使用，以便让客户端构造一系列查找操作来实现相同的效果。
The syntax and semantics to describe the data types of the NFSv4 protocol are defined in the XDR [RFC4506] and RPC [RFC5531] documents. The next sections build upon the XDR data types to define types and structures specific to this protocol. As a reminder, the size constants and authoritative definitions can be found in [RFC7531].
XDR[RFC4506]和RPC[RFC5531]文档中定义了描述NFSv4协议数据类型的语法和语义。下一节将基于XDR数据类型来定义特定于此协议的类型和结构。作为提醒，尺寸常数和权威定义可在[RFC7531]中找到。
Table 1 lists the base NFSv4 data types.
表1列出了基本NFSv4数据类型。
+-----------------+-------------------------------------------------+
| Data Type | Definition |
+-----------------+-------------------------------------------------+
| int32_t | typedef int int32_t; |
| | |
| uint32_t | typedef unsigned int uint32_t; |
| | |
| int64_t | typedef hyper int64_t; |
| | |
| uint64_t | typedef unsigned hyper uint64_t; |
| | |
| attrlist4 | typedef opaque attrlist4<>; |
| | |
| | Used for file/directory attributes. |
| | |
| bitmap4 | typedef uint32_t bitmap4<>; |
| | |
| | Used in attribute array encoding. |
| | |
| changeid4 | typedef uint64_t changeid4; |
| | |
| | Used in the definition of change_info4. |
| | |
| clientid4 | typedef uint64_t clientid4; |
| | |
| | Shorthand reference to client identification. |
| | |
| count4 | typedef uint32_t count4; |
| | |
| | Various count parameters (READ, WRITE, COMMIT). |
| | |
| length4 | typedef uint64_t length4; |
| | |
| | Describes LOCK lengths. |
| | |
+-----------------+-------------------------------------------------+
| Data Type | Definition |
+-----------------+-------------------------------------------------+
| int32_t | typedef int int32_t; |
| | |
| uint32_t | typedef unsigned int uint32_t; |
| | |
| int64_t | typedef hyper int64_t; |
| | |
| uint64_t | typedef unsigned hyper uint64_t; |
| | |
| attrlist4 | typedef opaque attrlist4<>; |
| | |
| | Used for file/directory attributes. |
| | |
| bitmap4 | typedef uint32_t bitmap4<>; |
| | |
| | Used in attribute array encoding. |
| | |
| changeid4 | typedef uint64_t changeid4; |
| | |
| | Used in the definition of change_info4. |
| | |
| clientid4 | typedef uint64_t clientid4; |
| | |
| | Shorthand reference to client identification. |
| | |
| count4 | typedef uint32_t count4; |
| | |
| | Various count parameters (READ, WRITE, COMMIT). |
| | |
| length4 | typedef uint64_t length4; |
| | |
| | Describes LOCK lengths. |
| | |
| mode4 | typedef uint32_t mode4; |
| | |
| | Mode attribute data type. |
| | |
| nfs_cookie4 | typedef uint64_t nfs_cookie4; |
| | |
| | Opaque cookie value for READDIR. |
| | |
| nfs_fh4 | typedef opaque nfs_fh4<NFS4_FHSIZE>; |
| | |
| | Filehandle definition. |
| | |
| nfs_ftype4 | enum nfs_ftype4; |
| | |
| | Various defined file types. |
| | |
| nfsstat4 | enum nfsstat4; |
| | |
| | Return value for operations. |
| | |
| nfs_lease4 | typedef uint32_t nfs_lease4; |
| | |
| | Duration of a lease in seconds. |
| | |
| offset4 | typedef uint64_t offset4; |
| | |
| | Various offset designations (READ, WRITE, LOCK, |
| | COMMIT). |
| | |
| qop4 | typedef uint32_t qop4; |
| | |
| | Quality of protection designation in SECINFO. |
| | |
| sec_oid4 | typedef opaque sec_oid4<>; |
| | |
| | Security Object Identifier. The sec_oid4 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 [RFC2743] for |
| | details. |
| | |
| seqid4 | typedef uint32_t seqid4; |
| | |
| | Sequence identifier used for file locking. |
| | |
| mode4 | typedef uint32_t mode4; |
| | |
| | Mode attribute data type. |
| | |
| nfs_cookie4 | typedef uint64_t nfs_cookie4; |
| | |
| | Opaque cookie value for READDIR. |
| | |
| nfs_fh4 | typedef opaque nfs_fh4<NFS4_FHSIZE>; |
| | |
| | Filehandle definition. |
| | |
| nfs_ftype4 | enum nfs_ftype4; |
| | |
| | Various defined file types. |
| | |
| nfsstat4 | enum nfsstat4; |
| | |
| | Return value for operations. |
| | |
| nfs_lease4 | typedef uint32_t nfs_lease4; |
| | |
| | Duration of a lease in seconds. |
| | |
| offset4 | typedef uint64_t offset4; |
| | |
| | Various offset designations (READ, WRITE, LOCK, |
| | COMMIT). |
| | |
| qop4 | typedef uint32_t qop4; |
| | |
| | Quality of protection designation in SECINFO. |
| | |
| sec_oid4 | typedef opaque sec_oid4<>; |
| | |
| | Security Object Identifier. The sec_oid4 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 [RFC2743] for |
| | details. |
| | |
| seqid4 | typedef uint32_t seqid4; |
| | |
| | Sequence identifier used for file locking. |
| | |
| 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 opaque linktext4<>; |
| | |
| | Symbolic link contents ("symbolic link" is |
| | defined in an Open Group [openg_symlink] |
| | standard). |
| | |
| ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; |
| | |
| | String is sent as ASCII and thus is |
| | automatically UTF-8. |
| | |
| pathname4 | typedef component4 pathname4<>; |
| | |
| | Represents pathname for fs_locations. |
| | |
| nfs_lockid4 | typedef uint64_t nfs_lockid4; |
| | |
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; |
| | |
| | Verifier used for various operations (COMMIT, |
| | CREATE, OPEN, READDIR, WRITE) |
| | NFS4_VERIFIER_SIZE is defined as 8. |
+-----------------+-------------------------------------------------+
| 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 opaque linktext4<>; |
| | |
| | Symbolic link contents ("symbolic link" is |
| | defined in an Open Group [openg_symlink] |
| | standard). |
| | |
| ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; |
| | |
| | String is sent as ASCII and thus is |
| | automatically UTF-8. |
| | |
| pathname4 | typedef component4 pathname4<>; |
| | |
| | Represents pathname for fs_locations. |
| | |
| nfs_lockid4 | typedef uint64_t nfs_lockid4; |
| | |
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; |
| | |
| | Verifier used for various operations (COMMIT, |
| | CREATE, OPEN, READDIR, WRITE) |
| | NFS4_VERIFIER_SIZE is defined as 8. |
+-----------------+-------------------------------------------------+
Table 1: Base NFSv4 Data Types
表1：基本NFSv4数据类型
struct nfstime4 {
int64_t seconds;
uint32_t nseconds;
};
struct nfstime4 {
int64_t seconds;
uint32_t nseconds;
};
The nfstime4 structure gives the number of seconds and nanoseconds since midnight or 0 hour January 1, 1970 Coordinated Universal Time (UTC). Values greater than zero for the seconds field denote dates after the 0 hour January 1, 1970. Values less than zero for the seconds field denote dates before the 0 hour January 1, 1970. In both cases, the nseconds field is to be added to the seconds field for the final time representation. For example, if the time to be represented is one-half second before 0 hour January 1, 1970, the seconds field would have a value of negative one (-1) and the nseconds fields would have a value of one-half second (500000000). Values greater than 999,999,999 for nseconds are considered invalid.
nfstime4结构给出了自1970年1月1日协调世界时（UTC）午夜或0小时后的秒数和纳秒数。秒字段大于零的值表示1970年1月1日0小时后的日期。秒字段小于零的值表示1970年1月1日0小时之前的日期。在这两种情况下，N秒字段将添加到秒字段中，作为最终时间表示。例如，如果要表示的时间是1970年1月1日0小时之前的半秒，则秒字段的值为负1（-1），而秒字段的值为半秒（500000000）。对于N秒，大于9999999的值被视为无效。
This data type is used to pass time and date information. A server converts to and from its local representation of time when processing time values, preserving as much accuracy as possible. If the precision of timestamps stored for a file system object is less than defined, loss of precision can occur. An adjunct time maintenance protocol is recommended to reduce client and server time skew.
此数据类型用于传递时间和日期信息。在处理时间值时，服务器会在本地表示的时间之间进行转换，以尽可能保持准确性。如果为文件系统对象存储的时间戳的精度小于定义的精度，则可能会发生精度损失。建议使用附加的时间维护协议来减少客户端和服务器的时间偏差。
enum time_how4 {
SET_TO_SERVER_TIME4 = 0,
SET_TO_CLIENT_TIME4 = 1
};
enum time_how4 {
SET_TO_SERVER_TIME4 = 0,
SET_TO_CLIENT_TIME4 = 1
};
union settime4 switch (time_how4 set_it) {
case SET_TO_CLIENT_TIME4:
nfstime4 time;
default:
void;
};
union settime4 switch (time_how4 set_it) {
case SET_TO_CLIENT_TIME4:
nfstime4 time;
default:
void;
};
The above definitions are used as the attribute definitions to set time values. If set_it is SET_TO_SERVER_TIME4, then the server uses its local representation of time for the time value.
以上定义用作设置时间值的属性定义。如果将其设置为服务器时间4，则服务器使用其本地时间表示形式作为时间值。
struct specdata4 {
uint32_t specdata1; /* major device number */
uint32_t specdata2; /* minor device number */
};
struct specdata4 {
uint32_t specdata1; /* major device number */
uint32_t specdata2; /* minor device number */
};
This data type represents additional information for the device file types NF4CHR and NF4BLK.
此数据类型表示设备文件类型NF4CHR和NF4BLK的附加信息。
struct fsid4 {
uint64_t major;
uint64_t minor;
};
struct fsid4 {
uint64_t major;
uint64_t minor;
};
This type is the file system identifier that is used as a REQUIRED attribute.
此类型是用作必需属性的文件系统标识符。
struct fs_location4 {
utf8str_cis server<>;
pathname4 rootpath;
};
struct fs_location4 {
utf8str_cis server<>;
pathname4 rootpath;
};
struct fs_locations4 {
pathname4 fs_root;
fs_location4 locations<>;
};
struct fs_locations4 {
pathname4 fs_root;
fs_location4 locations<>;
};
The fs_location4 and fs_locations4 data types are used for the fs_locations RECOMMENDED attribute, which is used for migration and replication support.
fs_location4和fs_locations4数据类型用于fs_locations RECOMMENDED属性，该属性用于迁移和复制支持。
struct fattr4 {
bitmap4 attrmask;
attrlist4 attr_vals;
};
struct fattr4 {
bitmap4 attrmask;
attrlist4 attr_vals;
};
The fattr4 structure is used to represent file and directory attributes.
fattr4结构用于表示文件和目录属性。
The bitmap is a counted array of 32-bit integers used to contain bit values. The position of the integer in the array that contains bit n can be computed from the expression (n / 32), and its bit within that integer is (n mod 32).
位图是一个32位整数的计数数组，用于包含位值。整数在包含位n的数组中的位置可以从表达式（n/32）计算出来，其在该整数中的位是（n mod 32）。
0 1
+-----------+-----------+-----------+--
| count | 31 .. 0 | 63 .. 32 |
+-----------+-----------+-----------+--
0 1
+-----------+-----------+-----------+--
| count | 31 .. 0 | 63 .. 32 |
+-----------+-----------+-----------+--
struct change_info4 {
bool atomic;
changeid4 before;
changeid4 after;
};
struct change_info4 {
bool atomic;
changeid4 before;
changeid4 after;
};
This structure is used with the CREATE, LINK, REMOVE, and RENAME operations to let the client know the value of the change attribute for the directory in which the target file system object resides.
此结构与创建、链接、删除和重命名操作一起使用，以让客户端知道目标文件系统对象所在目录的change属性的值。
struct clientaddr4 {
/* see struct rpcb in RFC 1833 */
string r_netid<>; /* network id */
string r_addr<>; /* universal address */
};
struct clientaddr4 {
/* see struct rpcb in RFC 1833 */
string r_netid<>; /* network id */
string r_addr<>; /* universal address */
};
The clientaddr4 structure is used as part of the SETCLIENTID operation, either (1) to specify the address of the client that is using a client ID or (2) as part of the callback registration. The r_netid and r_addr fields respectively contain a network id and universal address. The network id and universal address concepts, together with formats for TCP over IPv4 and TCP over IPv6, are defined in [RFC5665], specifically Tables 2 and 3 and Sections 5.2.3.3 and 5.2.3.4.
ClientAddress4结构用作SETCLIENTID操作的一部分，可以（1）指定使用客户端ID的客户端的地址，也可以（2）作为回调注册的一部分。r_netid和r_addr字段分别包含网络id和通用地址。[RFC5665]中定义了网络id和通用地址概念以及IPv4上的TCP和IPv6上的TCP格式，特别是表2和表3以及第5.2.3.3和5.2.3.4节。
struct cb_client4 {
unsigned int cb_program;
clientaddr4 cb_location;
};
struct cb_client4 {
unsigned int cb_program;
clientaddr4 cb_location;
};
This structure is used by the client to inform the server of its callback address; it includes the program number and client address.
客户端使用此结构通知服务器其回调地址；它包括程序编号和客户端地址。
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
This structure is part of the arguments to the SETCLIENTID operation.
此结构是SETCLIENTID操作参数的一部分。
struct open_owner4 {
clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>;
};
struct open_owner4 {
clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>;
};
This structure is used to identify the owner of open state.
此结构用于标识打开状态的所有者。
struct lock_owner4 {
clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>;
};
struct lock_owner4 {
clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>;
};
This structure is used to identify the owner of file locking state.
此结构用于标识文件锁定状态的所有者。
struct open_to_lock_owner4 {
seqid4 open_seqid;
stateid4 open_stateid;
seqid4 lock_seqid;
lock_owner4 lock_owner;
};
struct open_to_lock_owner4 {
seqid4 open_seqid;
stateid4 open_stateid;
seqid4 lock_seqid;
lock_owner4 lock_owner;
};
This structure is used for the first LOCK operation done for an open_owner4. It provides both the open_stateid and lock_owner such that the transition is made from a valid open_stateid sequence to that of the new lock_stateid sequence. Using this mechanism avoids the confirmation of the lock_owner/lock_seqid pair since it is tied to established state in the form of the open_stateid/open_seqid.
此结构用于为开放式所有者完成的第一次锁定操作4。它同时提供open_stateid和lock_owner，以便从有效的open_stateid序列转换为新的lock_stateid序列。使用此机制可以避免确认lock_owner/lock_seqid对，因为它以open_stateid/open_seqid的形式绑定到已建立的状态。
struct stateid4 {
uint32_t seqid;
opaque other[NFS4_OTHER_SIZE];
};
struct stateid4 {
uint32_t seqid;
opaque other[NFS4_OTHER_SIZE];
};
This structure is used for the various state-sharing mechanisms between the client and server. For the client, this data structure is read-only. The server is required to increment the seqid field monotonically at each transition of the stateid. This is important since the client will inspect the seqid in OPEN stateids to determine the order of OPEN processing done by the server.
此结构用于客户端和服务器之间的各种状态共享机制。对于客户端，此数据结构是只读的。服务器需要在stateid的每次转换时单调递增seqid字段。这一点很重要，因为客户端将检查OPEN StateID中的seqid，以确定服务器完成的打开处理顺序。
The NFSv4 protocol is an RPC application that uses RPC version 2 and the XDR as defined in [RFC5531] and [RFC4506]. The RPCSEC_GSS security flavors as defined in version 1 ([RFC2203]) and version 2 ([RFC5403]) MUST be implemented as the mechanism to deliver stronger security for the NFSv4 protocol. However, deployment of RPCSEC_GSS is optional.
NFSv4协议是一个RPC应用程序，它使用RPC版本2和[RFC5531]和[RFC4506]中定义的XDR。版本1（[RFC2203]）和版本2（[RFC5403]）中定义的RPCSEC_GSS安全风格必须作为为NFSv4协议提供更强安全性的机制来实现。但是，RPCSEC_GSS的部署是可选的。
Historically, NFSv2 and NFSv3 servers have resided on port 2049. The registered port 2049 [RFC3232] for the NFS protocol SHOULD be the default configuration. Using the registered port for NFS services means the NFS client will not need to use the RPC binding protocols as described in [RFC1833]; this will allow NFS to transit firewalls.
过去，NFSv2和NFSv3服务器位于端口2049上。NFS协议的注册端口2049[RFC3232]应为默认配置。使用NFS服务的注册端口意味着NFS客户端不需要使用[RFC1833]中所述的RPC绑定协议；这将允许NFS传输防火墙。
Where an NFSv4 implementation supports operation over the IP network protocol, the supported transport layer between NFS and IP MUST be an IETF standardized transport protocol that is specified to avoid network congestion; such transports include TCP and the Stream Control Transmission Protocol (SCTP). To enhance the possibilities for interoperability, an NFSv4 implementation MUST support operation over the TCP transport protocol.
如果NFSv4实现支持通过IP网络协议进行操作，则NFS和IP之间受支持的传输层必须是IETF标准化传输协议，该协议指定用于避免网络拥塞；此类传输包括TCP和流控制传输协议（SCTP）。为了增强互操作性的可能性，NFSv4实现必须支持TCP传输协议上的操作。
If TCP is used as the transport, the client and server SHOULD use persistent connections. This will prevent the weakening of TCP's congestion control via short-lived connections and will improve performance for the Wide Area Network (WAN) environment by eliminating the need for SYN handshakes.
如果使用TCP作为传输，则客户端和服务器应使用持久连接。这将防止通过短命连接削弱TCP的拥塞控制，并通过消除SYN握手的需要来提高广域网（WAN）环境的性能。
As noted in Section 19, the authentication model for NFSv4 has moved from machine-based to principal-based. However, this modification of the authentication model does not imply a technical requirement to
如第19节所述，NFSv4的身份验证模型已从基于机器转向基于主体。然而，对认证模型的这种修改并不意味着对
move the TCP connection management model from whole machine-based to one based on a per-user model. In particular, NFS over TCP client implementations have traditionally multiplexed traffic for multiple users over a common TCP connection between an NFS client and server. This has been true, regardless of whether the NFS client is using AUTH_SYS, AUTH_DH, RPCSEC_GSS, or any other flavor. Similarly, NFS over TCP server implementations have assumed such a model and thus scale the implementation of TCP connection management in proportion to the number of expected client machines. It is intended that NFSv4 will not modify this connection management model. NFSv4 clients that violate this assumption can expect scaling issues on the server and hence reduced service.
将TCP连接管理模型从基于整台计算机移动到基于每用户模型。特别是，NFS over TCP客户端实现传统上通过NFS客户端和服务器之间的公共TCP连接为多个用户多路传输流量。无论NFS客户端使用的是AUTH_SYS、AUTH_DH、RPCSEC_GSS还是任何其他风格，这都是正确的。类似地，NFS over TCP服务器实现也采用了这样的模型，因此TCP连接管理的实现与预期客户端计算机的数量成比例。NFSv4不会修改此连接管理模型。违反此假设的NFSv4客户端可能会在服务器上出现扩展问题，从而降低服务。
When processing an NFSv4 request received over a reliable transport such as TCP, the NFSv4 server MUST NOT silently drop the request, except if the established transport connection has been broken. Given such a contract between NFSv4 clients and servers, clients MUST NOT retry a request unless one or both of the following are true:
当处理通过可靠传输（如TCP）接收的NFSv4请求时，NFSv4服务器不得静默丢弃该请求，除非已建立的传输连接已断开。鉴于NFSv4客户端和服务器之间存在此类约定，客户端不得重试请求，除非以下一项或两项均为真：
o The transport connection has been broken
o 传输连接已断开
o The procedure being retried is the NULL procedure
o 正在重试的过程为空过程
Since reliable transports, such as TCP, do not always synchronously inform a peer when the other peer has broken the connection (for example, when an NFS server reboots), the NFSv4 client may want to actively "probe" the connection to see if has been broken. Use of the NULL procedure is one recommended way to do so. So, when a client experiences a remote procedure call timeout (of some arbitrary implementation-specific amount), rather than retrying the remote procedure call, it could instead issue a NULL procedure call to the server. If the server has died, the transport connection break will eventually be indicated to the NFSv4 client. The client can then reconnect, and then retry the original request. If the NULL procedure call gets a response, the connection has not broken. The client can decide to wait longer for the original request's response, or it can break the transport connection and reconnect before re-sending the original request.
由于可靠的传输（如TCP）并不总是在另一个对等方断开连接时（例如，NFS服务器重新启动时）同步通知另一个对等方，因此NFSv4客户端可能希望主动“探测”该连接以查看是否断开。使用NULL过程是一种推荐的方法。因此，当客户机遇到远程过程调用超时（某种特定于实现的任意数量）时，它不会重试远程过程调用，而是可以向服务器发出NULL过程调用。如果服务器死机，传输连接中断最终将指示给NFSv4客户端。然后，客户端可以重新连接，然后重试原始请求。如果NULL过程调用得到响应，则表示连接没有中断。客户端可以决定等待原始请求的响应更长时间，也可以在重新发送原始请求之前中断传输连接并重新连接。
For callbacks from the server to the client, the same rules apply, but the server doing the callback becomes the client, and the client receiving the callback becomes the server.
对于从服务器到客户机的回调，同样的规则也适用，但执行回调的服务器成为客户机，接收回调的客户机成为服务器。
Traditional RPC implementations have included AUTH_NONE, AUTH_SYS, AUTH_DH, and AUTH_KRB4 as security flavors. With [RFC2203], an additional security flavor of RPCSEC_GSS has been introduced, which uses the functionality of GSS-API [RFC2743]. This allows for the use of various security mechanisms by the RPC layer without the additional implementation overhead of adding RPC security flavors. For NFSv4, the RPCSEC_GSS security flavor MUST be used to enable the mandatory-to-implement security mechanism. Other flavors, such as AUTH_NONE, AUTH_SYS, and AUTH_DH, MAY be implemented as well.
传统的RPC实现包括AUTH_NONE、AUTH_SYS、AUTH_DH和AUTH_KRB4作为安全特性。[RFC2203]引入了RPCSEC_GSS的另一种安全特性，它使用GSS-API[RFC2743]的功能。这允许RPC层使用各种安全机制，而无需添加RPC安全特性的额外实现开销。对于NFSv4，必须使用RPCSEC_GSS安全特性来启用强制实现安全机制。还可以实现其他风格，例如AUTH_NONE、AUTH_SYS和AUTH_DH。
RPCSEC_GSS, via GSS-API, supports multiple mechanisms that provide security services. For interoperability, NFSv4 clients and servers MUST support the Kerberos V5 security mechanism.
RPCSEC_GSS通过GSS-API支持提供安全服务的多种机制。为了实现互操作性，NFSv4客户端和服务器必须支持Kerberos V5安全机制。
The use of RPCSEC_GSS requires selection of mechanism, quality of protection (QOP), and service (authentication, integrity, privacy). For the mandated security mechanisms, NFSv4 specifies that a QOP of zero is used, leaving it up to the mechanism or the mechanism's configuration to map QOP zero to an appropriate level of protection. Each mandated mechanism specifies a minimum set of cryptographic algorithms for implementing integrity and privacy. NFSv4 clients and servers MUST be implemented on operating environments that comply with the required cryptographic algorithms of each required mechanism.
RPCSEC_GSS的使用需要选择机制、保护质量（QOP）和服务（身份验证、完整性、隐私）。对于强制安全机制，NFSv4指定使用QOP为零，由机制或机制的配置将QOP零映射到适当的保护级别。每个强制机制都指定了用于实现完整性和隐私性的最小加密算法集。NFSv4客户端和服务器必须在符合每个所需机制的所需加密算法的操作环境中实现。
The Kerberos V5 GSS-API mechanism as described in [RFC4121] MUST be implemented with the RPCSEC_GSS services as specified in Table 2. Both client and server MUST support each of the pseudo-flavors.
[RFC4121]中描述的Kerberos V5 GSS-API机制必须使用表2中指定的RPCSEC_GSS服务实现。客户端和服务器都必须支持每种伪风格。
+--------+-------+----------------------+-----------------------+
| Number | Name | Mechanism's OID | RPCSEC_GSS service |
+--------+-------+----------------------+-----------------------+
| 390003 | krb5 | 1.2.840.113554.1.2.2 | rpc_gss_svc_none |
| 390004 | krb5i | 1.2.840.113554.1.2.2 | rpc_gss_svc_integrity |
| 390005 | krb5p | 1.2.840.113554.1.2.2 | rpc_gss_svc_privacy |
+--------+-------+----------------------+-----------------------+
+--------+-------+----------------------+-----------------------+
| Number | Name | Mechanism's OID | RPCSEC_GSS service |
+--------+-------+----------------------+-----------------------+
| 390003 | krb5 | 1.2.840.113554.1.2.2 | rpc_gss_svc_none |
| 390004 | krb5i | 1.2.840.113554.1.2.2 | rpc_gss_svc_integrity |
| 390005 | krb5p | 1.2.840.113554.1.2.2 | rpc_gss_svc_privacy |
+--------+-------+----------------------+-----------------------+
Table 2: Mapping Pseudo-Flavor to Service
表2：将伪风格映射到服务
Note that the pseudo-flavor is presented here as a mapping aid to the implementer. Because this NFS protocol includes a method to negotiate security and it understands the GSS-API mechanism, the
请注意，伪风格在这里作为映射辅助工具提供给实现者。由于此NFS协议包含协商安全性的方法，并且它了解GSS-API机制，因此
pseudo-flavor is not needed. The pseudo-flavor is needed for NFSv3 since the security negotiation is done via the MOUNT protocol as described in [RFC2623].
伪味是不需要的。NFSv3需要伪风格，因为安全协商是通过[RFC2623]中描述的装载协议完成的。
At the time this document was specified, the Advanced Encryption Standard (AES) with HMAC-SHA1 was a required algorithm set for Kerberos V5. In contrast, when NFSv4.0 was first specified in [RFC3530], weaker algorithm sets were REQUIRED for Kerberos V5, and were REQUIRED in the NFSv4.0 specification, because the Kerberos V5 specification at the time did not specify stronger algorithms. The NFSv4 specification does not specify required algorithms for Kerberos V5, and instead, the implementer is expected to track the evolution of the Kerberos V5 standard if and when stronger algorithms are specified.
在指定本文档时，带有HMAC-SHA1的高级加密标准（AES）是Kerberos V5所需的算法集。相反，当[RFC3530]中首次指定NFSv4.0时，Kerberos V5需要较弱的算法集，NFSv4.0规范也需要较弱的算法集，因为当时的Kerberos V5规范没有指定更强的算法。NFSv4规范没有为Kerberos V5指定所需的算法，相反，如果指定了更强大的算法，则实现者应该跟踪Kerberos V5标准的发展。
3.2.1.1.1. Security Considerations for Cryptographic Algorithms in Kerberos V5
3.2.1.1.1. Kerberos V5中加密算法的安全注意事项
When deploying NFSv4, the strength of the security achieved depends on the existing Kerberos V5 infrastructure. The algorithms of Kerberos V5 are not directly exposed to or selectable by the client or server, so there is some due diligence required by the user of NFSv4 to ensure that security is acceptable where needed. Guidance is provided in [RFC6649] as to why weak algorithms should be disabled by default.
在部署NFSv4时，实现的安全性的强度取决于现有的Kerberos V5基础架构。Kerberos V5的算法不直接暴露于客户机或服务器，也不可由客户机或服务器选择，因此NFSv4的用户需要进行一些尽职调查，以确保在需要时可以接受安全性。[RFC6649]中提供了关于为什么默认情况下应禁用弱算法的指导。
With the NFSv4 server potentially offering multiple security mechanisms, the client needs a method to determine or negotiate which mechanism is to be used for its communication with the server. The NFS server can have multiple points within its file system namespace that are available for use by NFS clients. In turn, the NFS server can be configured such that each of these entry points can have different or multiple security mechanisms in use.
由于NFSv4服务器可能提供多种安全机制，客户端需要一种方法来确定或协商用于与服务器通信的机制。NFS服务器在其文件系统命名空间中可以有多个点，供NFS客户端使用。反过来，可以对NFS服务器进行配置，使每个入口点都可以使用不同或多个安全机制。
The security negotiation between client and server SHOULD be done with a secure channel to eliminate the possibility of a third party intercepting the negotiation sequence and forcing the client and server to choose a lower level of security than required or desired. See Section 19 for further discussion.
客户端和服务器之间的安全协商应使用安全通道进行，以消除第三方截获协商序列并迫使客户端和服务器选择低于要求或期望的安全级别的可能性。进一步讨论见第19节。
The SECINFO operation will allow the client to determine, on a per-filehandle basis, what security triple (see [RFC2743] and Section 16.31.4) is to be used for server access. In general, the client will not have to use the SECINFO operation, except during initial communication with the server or when the client encounters a new security policy as the client navigates the namespace. Either condition will force the client to negotiate a new security triple.
SECINFO操作将允许客户端根据每个文件句柄确定用于服务器访问的三重安全性（请参见[RFC2743]和第16.31.4节）。通常，客户机不必使用SECINFO操作，除非在与服务器的初始通信期间，或者当客户机在导航命名空间时遇到新的安全策略时。任何一种情况都会迫使客户协商新的安全协议。
Based on the assumption that each NFSv4 client and server MUST support a minimum set of security (i.e., Kerberos V5 under RPCSEC_GSS), the NFS client will start its communication with the server with one of the minimal security triples. During communication with the server, the client can receive an NFS error of NFS4ERR_WRONGSEC. This error allows the server to notify the client that the security triple currently being used is not appropriate for access to the server's file system resources. The client is then responsible for determining what security triples are available at the server and choosing one that is appropriate for the client. See Section 16.31 for further discussion of how the client will respond to the NFS4ERR_WRONGSEC error and use SECINFO.
基于每个NFSv4客户端和服务器必须支持一组最低安全性（即RPCSEC_GSS下的Kerberos V5）的假设，NFS客户端将使用其中一个最低安全性三元组开始与服务器的通信。在与服务器通信期间，客户端可能会收到NFS4ERR_错误秒的NFS错误。此错误允许服务器通知客户端当前使用的安全性三元组不适合访问服务器的文件系统资源。然后，客户机负责确定服务器上有哪些安全三元组可用，并选择一个适合客户机的安全三元组。有关客户如何响应NFS4ERR_ErrorSec错误和使用SECINFO的进一步讨论，请参见第16.31节。
Except as noted elsewhere in this section, the callback RPC (described later) MUST mutually authenticate the NFS server to the principal that acquired the client ID (also described later), using the security flavor of the original SETCLIENTID operation used.
除本节其他地方所述外，回调RPC（稍后描述）必须使用所使用的原始SETCLIENTID操作的安全特性，向获取客户机ID（稍后描述）的主体相互验证NFS服务器。
For AUTH_NONE, there are no principals, so this is a non-issue.
对于AUTH_NONE，没有主体，因此这不是问题。
AUTH_SYS has no notions of mutual authentication or a server principal, so the callback from the server simply uses the AUTH_SYS credential that the user used when he set up the delegation.
AUTH_SYS没有相互身份验证或服务器主体的概念，因此来自服务器的回调仅使用用户在设置委派时使用的AUTH_SYS凭据。
For AUTH_DH, one commonly used convention is that the server uses the credential corresponding to this AUTH_DH principal:
对于AUTH_DH，一个常用的约定是服务器使用与此AUTH_DH主体对应的凭据：
unix.host@domain
unix。host@domain
where host and domain are variables corresponding to the name of the server host and directory services domain in which it lives, such as a Network Information System domain or a DNS domain.
其中，主机和域是与其所在的服务器主机和目录服务域（如网络信息系统域或DNS域）的名称相对应的变量。
Regardless of what security mechanism under RPCSEC_GSS is being used, the NFS server MUST identify itself in GSS-API via a GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE names are of the form:
无论使用的是RPCSEC_GSS下的哪种安全机制，NFS服务器都必须通过GSS_C_NT_HOSTBASED_服务名称类型在GSS-API中标识自己。GSS_C_NT_基于主机的_服务名称的形式如下：
service@hostname
service@hostname
For NFS, the "service" element is:
对于NFS，“服务”元素是：
nfs
nfs
Implementations of security mechanisms will convert nfs@hostname to various different forms. For Kerberos V5, the following form is RECOMMENDED:
安全机制的实现将转换为nfs@hostname以各种不同的形式。对于Kerberos V5，建议使用以下格式：
nfs/hostname
nfs/主机名
For Kerberos V5, nfs/hostname would be a server principal in the Kerberos Key Distribution Center database. This is the same principal the client acquired a GSS-API context for when it issued the SETCLIENTID operation; therefore, the realm name for the server principal must be the same for the callback as it was for the SETCLIENTID.
对于Kerberos V5，nfs/主机名将是Kerberos密钥分发中心数据库中的服务器主体。这与客户端在发出SETCLIENTID操作时获取GSS-API上下文的主体相同；因此，回调的服务器主体的域名称必须与SETCLIENTID的域名称相同。
The filehandle in the NFS protocol is a per-server unique identifier for a file system object. The contents of the filehandle are opaque to the client. Therefore, the server is responsible for translating the filehandle to an internal representation of the file system object.
NFS协议中的filehandle是文件系统对象的每服务器唯一标识符。文件句柄的内容对客户端是不透明的。因此，服务器负责将文件句柄转换为文件系统对象的内部表示形式。
The operations of the NFS protocol are defined in terms of one or more filehandles. Therefore, the client needs a filehandle to initiate communication with the server. With the NFSv2 protocol [RFC1094] and the NFSv3 protocol [RFC1813], there exists an ancillary protocol to obtain this first filehandle. The MOUNT protocol, RPC program number 100005, provides the mechanism of translating a string-based file system pathname to a filehandle that can then be used by the NFS protocols.
NFS协议的操作是根据一个或多个文件句柄定义的。因此，客户端需要一个文件句柄来启动与服务器的通信。对于NFSv2协议[RFC1094]和NFSv3协议[RFC1813]，存在一个辅助协议来获取第一个文件句柄。装载协议（RPC程序编号100005）提供了将基于字符串的文件系统路径名转换为NFS协议可以使用的文件句柄的机制。
The MOUNT protocol has deficiencies in the area of security and use via firewalls. This is one reason that the use of the public filehandle was introduced in [RFC2054] and [RFC2055]. With the use of the public filehandle in combination with the LOOKUP operation in
MOUNT协议在安全性和通过防火墙使用方面存在缺陷。这就是[RFC2054]和[RFC2055]中引入公共文件句柄的原因之一。将公共文件句柄与中的查找操作结合使用
the NFSv2 and NFSv3 protocols, it has been demonstrated that the MOUNT protocol is unnecessary for viable interaction between the NFS client and server.
在NFSv2和NFSv3协议中，已经证明了挂载协议对于NFS客户端和服务器之间的有效交互是不必要的。
Therefore, the NFSv4 protocol will not use an ancillary protocol for translation from string-based pathnames to a filehandle. Two special filehandles will be used as starting points for the NFS client.
因此，NFSv4协议不会使用辅助协议将基于字符串的路径名转换为文件句柄。两个特殊的文件句柄将用作NFS客户端的起点。
The first of the special filehandles is the root filehandle. The root filehandle is the "conceptual" root of the file system namespace at the NFS server. The client uses or starts with the root filehandle by employing the PUTROOTFH operation. The PUTROOTFH operation instructs the server to set the current filehandle to the root of the server's file tree. Once this PUTROOTFH operation is used, the client can then traverse the entirety of the server's file tree with the LOOKUP operation. A complete discussion of the server namespace is in Section 7.
第一个特殊文件句柄是根文件句柄。根文件句柄是NFS服务器上文件系统名称空间的“概念”根。客户端通过使用PUTROOTFH操作来使用或启动根文件句柄。PUTROOTFH操作指示服务器将当前文件句柄设置为服务器文件树的根。使用此PUTROOTFH操作后，客户机可以使用查找操作遍历服务器的整个文件树。关于服务器名称空间的完整讨论见第7节。
The second special filehandle is the public filehandle. Unlike the root filehandle, the public filehandle may be bound or represent an arbitrary file system object at the server. The server is responsible for this binding. It may be that the public filehandle and the root filehandle refer to the same file system object. However, it is up to the administrative software at the server and the policies of the server administrator to define the binding of the public filehandle and server file system object. The client may not make any assumptions about this binding. The client uses the public filehandle via the PUTPUBFH operation.
第二个特殊文件句柄是公共文件句柄。与根文件句柄不同，公共文件句柄可以绑定或表示服务器上的任意文件系统对象。服务器负责此绑定。公共文件句柄和根文件句柄可能引用同一个文件系统对象。但是，定义公共文件句柄和服务器文件系统对象的绑定取决于服务器上的管理软件和服务器管理员的策略。客户不得对此绑定做出任何假设。客户端通过PUTPUBFH操作使用公共文件句柄。
In the NFSv2 and NFSv3 protocols, there was one type of filehandle with a single set of semantics, of which the primary one was that it was persistent across a server reboot. As such, this type of filehandle is termed "persistent" in NFSv4. The semantics of a persistent filehandle remain the same as before. A new type of filehandle introduced in NFSv4 is the volatile filehandle, which attempts to accommodate certain server environments.
在NFSv2和NFSv3协议中，有一种文件句柄类型具有一组语义，其中主要的一种是它在服务器重新启动时是持久的。因此，这种类型的文件句柄在NFSv4中被称为“持久的”。持久化文件句柄的语义与以前相同。NFSv4中引入的一种新型文件句柄是volatile文件句柄，它试图适应某些服务器环境。
The volatile filehandle type was introduced to address server functionality or implementation issues that make correct implementation of a persistent filehandle infeasible. Some server environments do not provide a file system level invariant that can be used to construct a persistent filehandle. The underlying server
引入volatile filehandle类型是为了解决使持久化filehandle的正确实现不可行的服务器功能或实现问题。某些服务器环境不提供可用于构造持久化文件句柄的文件系统级不变量。底层服务器
file system may not provide the invariant, or the server's file system programming interfaces may not provide access to the needed invariant. Volatile filehandles may ease the implementation of server functionality, such as hierarchical storage management or file system reorganization or migration. However, the volatile filehandle increases the implementation burden for the client.
文件系统可能不提供不变量，或者服务器的文件系统编程接口可能不提供对所需不变量的访问。易失性文件句柄可以简化服务器功能的实现，如分层存储管理或文件系统重组或迁移。但是，易失性文件句柄增加了客户端的实现负担。
Since the client will need to handle persistent and volatile filehandles differently, a file attribute is defined that may be used by the client to determine the filehandle types being returned by the server.
由于客户端需要以不同的方式处理持久性和易失性文件句柄，因此定义了一个文件属性，客户端可以使用该属性来确定服务器返回的文件句柄类型。
The filehandle contains all the information the server needs to distinguish an individual file. To the client, the filehandle is opaque. The client stores filehandles for use in a later request and can compare two filehandles from the same server for equality by doing a byte-by-byte comparison. However, the client MUST NOT otherwise interpret the contents of filehandles. If two filehandles from the same server are equal, they MUST refer to the same file. However, it is not required that two different filehandles refer to different file system objects. Servers SHOULD try to maintain a one-to-one correspondence between filehandles and file system objects but there may be situations in which the mapping is not one-to-one. Clients MUST use filehandle comparisons only to improve performance, not for correct behavior. All clients need to be prepared for situations in which it cannot be determined whether two different filehandles denote the same object and in such cases need to avoid assuming that objects denoted are different, as this might cause incorrect behavior. Further discussion of filehandle and attribute comparison in the context of data caching is presented in Section 10.3.4.
filehandle包含服务器区分单个文件所需的所有信息。对于客户端来说，文件句柄是不透明的。客户端存储文件句柄，以便在以后的请求中使用，并且可以通过逐字节比较来比较来自同一服务器的两个文件句柄是否相等。但是，客户端不得以其他方式解释文件句柄的内容。如果来自同一服务器的两个文件句柄相等，则它们必须引用同一文件。但是，不要求两个不同的文件句柄引用不同的文件系统对象。服务器应尝试在文件句柄和文件系统对象之间保持一对一的对应关系，但可能存在映射不是一对一的情况。客户端必须使用filehandle比较来提高性能，而不是正确的行为。所有客户端都需要为无法确定两个不同的文件句柄是否表示同一个对象的情况做好准备，在这种情况下，需要避免假设表示的对象不同，因为这可能会导致错误的行为。第10.3.4节进一步讨论了数据缓存环境中的文件句柄和属性比较。
As an example, in the case that two different pathnames when traversed at the server terminate at the same file system object, the server SHOULD return the same filehandle for each path. This can occur if a hard link is used to create two filenames that refer to the same underlying file object and associated data. For example, if paths /a/b/c and /a/d/c refer to the same file, the server SHOULD return the same filehandle for both pathname traversals.
例如，如果在服务器上遍历两个不同的路径名时终止于同一文件系统对象，则服务器应为每个路径返回相同的filehandle。如果使用硬链接创建引用同一基础文件对象和关联数据的两个文件名，则可能发生这种情况。例如，如果路径/a/b/c和/a/d/c引用同一个文件，则服务器应为两个路径名遍历返回相同的文件句柄。
A persistent filehandle is defined as having a fixed value for the lifetime of the file system object to which it refers. Once the server creates the filehandle for a file system object, the server MUST accept the same filehandle for the object for the lifetime of
持久化文件句柄定义为在其引用的文件系统对象的生存期内具有固定值。一旦服务器为文件系统对象创建filehandle，服务器必须在对象的生存期内接受相同的filehandle
the object. If the server restarts or reboots, the NFS server must honor the same filehandle value as it did in the server's previous instantiation. Similarly, if the file system is migrated, the new NFS server must honor the same filehandle as the old NFS server.
物体。如果服务器重新启动或重新启动，NFS服务器必须使用与服务器上一次实例化中相同的filehandle值。类似地，如果文件系统被迁移，新的NFS服务器必须与旧的NFS服务器使用相同的文件句柄。
The persistent filehandle will become stale or invalid when the file system object is removed. When the server is presented with a persistent filehandle that refers to a deleted object, it MUST return an error of NFS4ERR_STALE. A filehandle may become stale when the file system containing the object is no longer available. The file system may become unavailable if it exists on removable media and the media is no longer available at the server, or if the file system in whole has been destroyed, or if the file system has simply been removed from the server's namespace (i.e., unmounted in a UNIX environment).
删除文件系统对象后，持久化文件句柄将变得陈旧或无效。当服务器显示引用已删除对象的持久化文件句柄时，它必须返回NFS4ERR_STALE错误。当包含对象的文件系统不再可用时，文件句柄可能会过时。如果文件系统存在于可移动介质上，而该介质在服务器上不再可用，或者整个文件系统已被破坏，或者文件系统已从服务器的命名空间中删除（即在UNIX环境中卸载），则文件系统可能不可用。
A volatile filehandle does not share the same longevity characteristics of a persistent filehandle. The server may determine that a volatile filehandle is no longer valid at many different points in time. If the server can definitively determine that a volatile filehandle refers to an object that has been removed, the server should return NFS4ERR_STALE to the client (as is the case for persistent filehandles). In all other cases where the server determines that a volatile filehandle can no longer be used, it should return an error of NFS4ERR_FHEXPIRED.
易失性文件句柄与持久性文件句柄的寿命特征不同。服务器可能会确定易失性文件句柄在许多不同的时间点不再有效。如果服务器可以确定易失性文件句柄引用已删除的对象，则服务器应将NFS4ERR_STALE返回给客户端（与持久性文件句柄的情况相同）。在所有其他情况下，如果服务器确定无法再使用易失性文件句柄，则应返回一个错误NFS4ERR\fhu expired。
The REQUIRED attribute "fh_expire_type" is used by the client to determine what type of filehandle the server is providing for a particular file system. This attribute is a bitmask with the following values:
客户端使用必需的属性“fh_expire_type”来确定服务器为特定文件系统提供的文件句柄类型。此属性是具有以下值的位掩码：
FH4_PERSISTENT: The value of FH4_PERSISTENT is used to indicate a persistent filehandle, which is valid until the object is removed from the file system. The server will not return NFS4ERR_FHEXPIRED for this filehandle. FH4_PERSISTENT is defined as a value in which none of the bits specified below are set.
FH4_PERSISTENT：FH4_PERSISTENT的值用于指示持久化文件句柄，该句柄在对象从文件系统中删除之前有效。服务器不会为此文件句柄返回NFS4ERR_fhu expired。FH4_PERSISTENT定义为未设置以下指定位的值。
FH4_VOLATILE_ANY: The filehandle may expire at any time, except as specifically excluded (i.e., FH4_NOEXPIRE_WITH_OPEN).
FH4\u VOLATILE\u ANY：文件句柄可能随时过期，除非明确排除（即FH4\u NOEXPIRE\u打开）。
FH4_NOEXPIRE_WITH_OPEN: May only be set when 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 open.
FH4_NOEXPIRE_WITH_OPEN:只能在设置FH4_VOLATILE_ANY时设置。如果设置了该位，则FH4_VOLATILE_ANY的含义有资格排除文件句柄打开时的任何过期。
FH4_VOL_MIGRATION: The filehandle will expire as a result of migration. If FH4_VOLATILE_ANY is set, FH4_VOL_MIGRATION is redundant.
FH4_VOL_迁移：文件句柄将因迁移而过期。如果设置了FH4_VOLATILE_ANY，则FH4_VOL_迁移是冗余的。
FH4_VOL_RENAME: The filehandle will expire during rename. This includes a rename by the requesting client or a rename by any other client. If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME is redundant.
FH4_VOL_RENAME：文件句柄将在重命名期间过期。这包括请求客户端的重命名或任何其他客户端的重命名。如果设置了FH4_VOLATILE_ANY，则FH4_VOL_RENAME是冗余的。
Servers that provide volatile filehandles that may expire while open (i.e., if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN is not set) should 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 deny all RENAME or REMOVE requests during the grace period upon server restart.
提供易失性文件句柄的服务器在打开时可能会过期（即，如果设置了FH4_VOL_MIGRATION或FH4_VOL_RENAME，或者如果设置了FH4_volatile_ANY且未设置FH4_NOEXPIRE_WITH_open），则应拒绝重命名或删除会影响导致打开文件的任何组件的打开文件。此外，在服务器重新启动的宽限期内，服务器应拒绝所有重命名或删除请求。
Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the client to determine that expiration has occurred whenever a specific event occurs, without an explicit filehandle expiration error from the server. FH4_VOLATILE_ANY does not provide this form of information. In situations where the server will expire many, but not all, filehandles upon migration (e.g., all but those that are open), FH4_VOLATILE_ANY (in this case, with FH4_NOEXPIRE_WITH_OPEN) is a better choice since the client may not assume that all filehandles will expire when migration occurs, and it is likely that additional expirations will occur (as a result of file CLOSE) that are separated in time from the migration event itself.
请注意，位FH4_VOL_MIGRATION和FH4_VOL_RENAME允许客户机在发生特定事件时确定是否已发生过期，而不会出现来自服务器的显式filehandle过期错误。FH4\u VOLATILE\u ANY不提供这种形式的信息。在服务器在迁移时会使许多但不是所有文件句柄过期的情况下（例如，除了那些打开的文件句柄以外的所有文件句柄），FH4_VOLATILE_ANY（在这种情况下，使用FH4_NOEXPIRE_和_open）是一个更好的选择，因为客户端可能不会假设在迁移发生时所有文件句柄都会过期，而且，很可能会发生与迁移事件本身在时间上分离的其他过期（由于文件关闭）。
A volatile filehandle, while opaque to the client, could contain:
易失性文件句柄虽然对客户端不透明，但可能包含：
[volatile bit = 1 | server boot time | slot | generation number]
[volatile bit=1 |服务器启动时间|插槽|代数]
o slot is an index in the server volatile filehandle table
o slot是服务器volatile filehandle表中的索引
o generation number is the generation number for the table entry/slot
o generation number是表项/插槽的生成编号
When the client presents a volatile filehandle, the server makes the following checks, which assume that the check for the volatile bit 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 NFS4ERR_BADHANDLE. If the generation number does not match, return NFS4ERR_FHEXPIRED.
当客户机呈现易失性文件句柄时，服务器进行以下检查，假设已通过对易失性位的检查。如果服务器引导时间小于当前服务器引导时间，则返回NFS4ERR\fhu expired。如果插槽超出范围，则返回NFS4ERR_BADHANDLE。如果生成编号不匹配，则返回NFS4ERR\fhu expired。
When the server reboots, the table is gone (it is volatile).
当服务器重新启动时，表就不存在了（它是不稳定的）。
If the volatile bit is 0, then it is a persistent filehandle with a different structure following it.
如果volatile位为0，则它是一个具有不同结构的持久文件句柄。
If possible, the client should recover from the receipt of an NFS4ERR_FHEXPIRED error. The client must take on additional responsibility so that it may prepare itself to recover from the expiration of a volatile filehandle. If the server returns persistent filehandles, the client does not need these additional steps.
如果可能，客户端应在收到NFS4ERR\fhu过期错误后恢复。客户机必须承担额外的责任，以便做好准备，从易失性文件句柄过期时恢复。如果服务器返回持久化文件句柄，则客户端不需要这些附加步骤。
For volatile filehandles, most commonly the client will need to store the component names leading up to and including the file system object in question. With these names, the client should be able to recover by finding a filehandle in the namespace that is still available or by starting at the root of the server's file system namespace.
对于易失性文件句柄，最常见的情况是，客户机需要存储指向并包括所讨论的文件系统对象的组件名称。有了这些名称，客户端应该能够通过在名称空间中找到仍然可用的文件句柄或从服务器文件系统名称空间的根开始进行恢复。
If the expired filehandle refers to an object that has been removed from the file system, obviously the client will not be able to recover from the expired filehandle.
如果过期的filehandle引用了已从文件系统中删除的对象，则客户端显然无法从过期的filehandle中恢复。
It is also possible that the expired filehandle refers to a file that has been renamed. If the file was renamed by another client, again it is possible that the original client will not be able to recover. However, in the case that the client itself is renaming the file and the file is open, it is possible that the client may be able to recover. The client can determine the new pathname based on the processing of the rename request. The client can then regenerate the new filehandle based on the new pathname. The client could also use the COMPOUND operation mechanism to construct a set of operations like:
过期的文件句柄也可能引用已重命名的文件。如果文件被另一个客户端重命名，则原始客户端也可能无法恢复。但是，如果客户机本身正在重命名文件并且文件已打开，则客户机可能能够恢复。客户端可以根据重命名请求的处理来确定新的路径名。然后，客户端可以基于新路径名重新生成新的文件句柄。客户端还可以使用复合操作机制构建一组操作，如：
RENAME A B LOOKUP B GETFH
重命名A B查找B GETFH
Note that the COMPOUND procedure does not provide atomicity. This example only reduces the overhead of recovering from an expired filehandle.
注意，复合过程不提供原子性。此示例仅减少了从过期文件句柄恢复的开销。
To meet the requirements of extensibility and increased interoperability with non-UNIX platforms, attributes need to be handled in a flexible manner. The NFSv3 fattr3 structure contains a fixed list of attributes that not all clients and servers are able to
为了满足可扩展性和与非UNIX平台增强的互操作性的要求，需要以灵活的方式处理属性。NFSv3 fattr3结构包含一个固定的属性列表，并非所有客户机和服务器都能够这样做
support or care about. The fattr3 structure cannot be extended as new needs arise, and it provides no way to indicate non-support. With the NFSv4.0 protocol, the client is able to query what attributes the server supports and construct requests with only those supported attributes (or a subset thereof).
支持或关心。fattr3结构不能随着新需求的出现而扩展，也无法表示不支持。使用NFSv4.0协议，客户机能够查询服务器支持哪些属性，并仅使用这些支持的属性（或其子集）构造请求。
To this end, attributes are divided into three groups: REQUIRED, RECOMMENDED, and named. Both REQUIRED and RECOMMENDED attributes are supported in the NFSv4.0 protocol by a specific and well-defined encoding and are identified by number. They are requested by setting a bit in the bit vector sent in the GETATTR request; the server response includes a bit vector to list what attributes were returned in the response. New REQUIRED or RECOMMENDED attributes may be added to the NFSv4 protocol as part of a new minor version by publishing a Standards Track RFC that allocates a new attribute number value and defines the encoding for the attribute. See Section 11 for further discussion.
为此，属性分为三组：必需、推荐和命名。NFSv4.0协议中通过特定和定义良好的编码支持必需属性和推荐属性，并通过数字标识。通过在GETATTR请求中发送的位向量中设置位来请求它们；服务器响应包含一个位向量，用于列出响应中返回的属性。通过发布分配新属性编号值并定义属性编码的标准跟踪RFC，可以将新的必需或推荐属性作为新次要版本的一部分添加到NFSv4协议中。进一步讨论见第11节。
Named attributes are accessed by the OPENATTR operation, which accesses a hidden directory of attributes associated with a file system object. OPENATTR takes a filehandle for the object and returns the filehandle for the attribute hierarchy. The filehandle for the named attributes is a directory object accessible by LOOKUP or READDIR and contains files whose names represent the named attributes and whose data bytes are the value of the attribute. For example:
命名属性由OPENATTR操作访问，该操作访问与文件系统对象关联的属性的隐藏目录。OPENATTR获取对象的文件句柄，并返回属性层次结构的文件句柄。命名属性的filehandle是可由LOOKUP或READDIR访问的目录对象，包含名称表示命名属性且数据字节为属性值的文件。例如：
+----------+-----------+---------------------------------+
| LOOKUP | "foo" | ; look up file |
| GETATTR | attrbits | |
| OPENATTR | | ; access foo's named attributes |
| LOOKUP | "x11icon" | ; look up specific attribute |
| READ | 0,4096 | ; read stream of bytes |
+----------+-----------+---------------------------------+
+----------+-----------+---------------------------------+
| LOOKUP | "foo" | ; look up file |
| GETATTR | attrbits | |
| OPENATTR | | ; access foo's named attributes |
| LOOKUP | "x11icon" | ; look up specific attribute |
| READ | 0,4096 | ; read stream of bytes |
+----------+-----------+---------------------------------+
Named attributes are intended for data needed by applications rather than by an NFS client implementation. NFS implementers are strongly encouraged to define their new attributes as RECOMMENDED attributes by bringing them to the IETF Standards Track process.
命名属性用于应用程序而不是NFS客户端实现所需的数据。强烈鼓励NFS实现者通过将其引入IETF标准跟踪过程，将其新属性定义为推荐属性。
The set of attributes that are classified as REQUIRED is deliberately small since servers need to do whatever it takes to support them. A server should support as many of the RECOMMENDED attributes as possible; however, by their definition, the server is not required to support all of them. Attributes are deemed REQUIRED if the data is both needed by a large number of clients and is not otherwise reasonably computable by the client when support is not provided on the server.
由于服务器需要尽一切努力来支持这些属性，因此被分类为必需的属性集故意很小。服务器应该支持尽可能多的推荐属性；但是，根据它们的定义，并不要求服务器支持所有这些功能。如果大量客户机都需要这些数据，并且当服务器上没有提供支持时，客户机无法合理地计算这些数据，则认为这些属性是必需的。
Note that the hidden directory returned by OPENATTR is a convenience for protocol processing. The client should not make any assumptions about the server's implementation of named attributes and whether or not the underlying file system at the server has a named attribute directory. Therefore, operations such as SETATTR and GETATTR on the named attribute directory are undefined.
请注意，OPENATTR返回的隐藏目录便于协议处理。客户机不应该对服务器的命名属性实现以及服务器上的底层文件系统是否具有命名属性目录做出任何假设。因此，命名属性目录上的SETATTR和GETATTR等操作是未定义的。
These attributes MUST be supported by every NFSv4.0 client and server in order to ensure a minimum level of interoperability. The server MUST store and return these attributes, and the client MUST be able to function with an attribute set limited to these attributes. With just the REQUIRED attributes, some client functionality can be impaired or limited in some ways. A client can ask for any of these attributes to be returned by setting a bit in the GETATTR request. For each such bit set, the server MUST return the corresponding attribute value.
每个NFSv4.0客户端和服务器都必须支持这些属性，以确保最低级别的互操作性。服务器必须存储并返回这些属性，客户机必须能够使用限制于这些属性的属性集运行。仅使用所需的属性，某些客户端功能可能会在某些方面受到损害或限制。客户机可以通过在GETATTR请求中设置一个位来请求返回这些属性中的任何一个。对于每个这样的位集，服务器必须返回相应的属性值。
These attributes are understood well enough to warrant support in the NFSv4.0 protocol. However, they may not be supported on all clients and servers. A client MAY ask for any of these attributes to be returned by setting a bit in the GETATTR request but MUST handle the case where the server does not return them. A client MAY ask for the set of attributes the server supports and SHOULD NOT request attributes the server does not support. A server should be tolerant of requests for unsupported attributes and simply not return them, rather than considering the request an error. It is expected that servers will support all attributes they comfortably can and only fail to support attributes that are difficult to support in their operating environments. A server should provide attributes whenever they don't have to "tell lies" to the client. For example, a file modification time either should be an accurate time or should not be supported by the server. At times this will be difficult for clients, but a client is better positioned to decide whether and how to fabricate or construct an attribute or whether to do without the attribute.
对这些属性的理解足以保证NFSv4.0协议中的支持。但是，并非所有客户端和服务器都支持它们。客户机可以通过在GETATTR请求中设置一个位来请求返回这些属性中的任何一个，但必须处理服务器不返回这些属性的情况。客户端可能要求服务器支持的属性集，但不应要求服务器不支持的属性集。服务器应该容忍对不受支持的属性的请求，并且不返回它们，而不是将请求视为错误。预计服务器将支持其能够轻松支持的所有属性，并且只支持在其操作环境中难以支持的属性。只要服务器不必向客户端“撒谎”，就应该提供属性。例如，文件修改时间应该是准确的时间，或者服务器不支持。有时，这对客户机来说很困难，但客户机可以更好地决定是否以及如何制作或构造属性，或者是否不使用属性。
These attributes are not supported by direct encoding in the NFSv4 protocol but are accessed by string names rather than numbers and correspond to an uninterpreted stream of bytes that are stored with the file system object. The namespace for these attributes may be accessed by using the OPENATTR operation. The OPENATTR operation returns a filehandle for a virtual "named attribute directory", and
NFSv4协议中的直接编码不支持这些属性，但可以通过字符串名称而不是数字来访问这些属性，并对应于与文件系统对象一起存储的未解释的字节流。可以使用OPENATTR操作访问这些属性的名称空间。OPENATTR操作返回虚拟“命名属性目录”的文件句柄，然后
further perusal and modification of the namespace may be done using operations that work on more typical directories. In particular, READDIR may be used to get a list of such named attributes, and LOOKUP and OPEN may select a particular attribute. Creation of a new named attribute may be the result of an OPEN specifying file creation.
可以使用在更典型的目录上工作的操作来进一步阅读和修改名称空间。具体而言，READDIR可用于获取此类命名属性的列表，而LOOKUP和OPEN可选择特定属性。新命名属性的创建可能是打开指定文件创建的结果。
Once an OPEN is done, named attributes may be examined and changed by normal READ and WRITE operations using the filehandles and stateids returned by OPEN.
一旦打开完成，命名属性就可以通过使用OPEN返回的filehandles和stateID的正常读写操作进行检查和更改。
Named attributes and the named attribute directory may have their own (non-named) attributes. Each of these objects must have all of the REQUIRED attributes and may have additional RECOMMENDED attributes. However, the set of attributes for named attributes and the named attribute directory need not be, and typically will not be, as large as that for other objects in that file system.
命名属性和命名属性目录可能有自己的（非命名）属性。这些对象中的每一个都必须具有所有必需的属性，并且可能具有其他建议的属性。但是，命名属性和命名属性目录的属性集不需要也通常不会像该文件系统中其他对象的属性集那样大。
Named attributes might be the target of delegations. However, since granting of delegations is at the server's discretion, a server need not support delegations on named attributes.
命名属性可能是委派的目标。但是，由于委派的授予由服务器自行决定，因此服务器不需要支持命名属性上的委派。
It is RECOMMENDED that servers support arbitrary named attributes. A client should not depend on the ability to store any named attributes in the server's file system. If a server does support named attributes, a client that is also able to handle them should be able to copy a file's data and metadata with complete transparency from one location to another; this would imply that names allowed for regular directory entries are valid for named attribute names as well.
建议服务器支持任意命名属性。客户端不应依赖于在服务器的文件系统中存储任何命名属性的能力。如果服务器确实支持命名属性，那么能够处理这些属性的客户端应该能够完全透明地将文件的数据和元数据从一个位置复制到另一个位置；这意味着常规目录项允许的名称对于命名属性名称也是有效的。
In NFSv4.0, the structure of named attribute directories is restricted in a number of ways, in order to prevent the development of non-interoperable implementations in which some servers support a fully general hierarchical directory structure for named attributes while others support a limited but adequate structure for named attributes. In such an environment, clients or applications might come to depend on non-portable extensions. The restrictions are:
在NFSv4.0中，命名属性目录的结构以多种方式受到限制，以防止开发不可互操作的实现，其中一些服务器支持命名属性的完全通用层次目录结构，而另一些服务器支持有限但适当的命名属性结构。在这样的环境中，客户端或应用程序可能会依赖于不可移植的扩展。这些限制包括：
o CREATE is not allowed in a named attribute directory. Thus, such objects as symbolic links and special files are not allowed to be named attributes. Further, directories may not be created in a named attribute directory, so no hierarchical structure of named attributes for a single object is allowed.
o 不允许在命名属性目录中创建。因此，诸如符号链接和特殊文件之类的对象不允许被命名为属性。此外，可能无法在命名属性目录中创建目录，因此不允许单个对象的命名属性的层次结构。
o If OPENATTR is done on a named attribute directory or on a named attribute, the server MUST return an error.
o 如果在命名属性目录或命名属性上执行OPENATTR，则服务器必须返回错误。
o Doing a RENAME of a named attribute to a different named attribute directory or to an ordinary (i.e., non-named-attribute) directory is not allowed.
o 不允许将命名属性重命名为其他命名属性目录或普通（即非命名属性）目录。
o Creating hard links between named attribute directories or between named attribute directories and ordinary directories is not allowed.
o 不允许在命名属性目录之间或命名属性目录与普通目录之间创建硬链接。
Names of attributes will not be controlled by this document or other IETF Standards Track documents. See Section 20 for further discussion.
属性名称不受本文件或其他IETF标准跟踪文件的控制。进一步讨论见第20节。
Each of the attributes accessed using SETATTR and GETATTR (i.e., REQUIRED and RECOMMENDED attributes) can be classified in one of three categories:
使用SETATTR和GETATTR访问的每个属性（即必需和推荐属性）可分为三类：
1. per-server attributes for which the value of the attribute will be the same for all file objects that share the same server.
1. 对于共享同一服务器的所有文件对象，其属性值将相同的每服务器属性。
2. per-file system attributes for which the value of the attribute will be the same for some or all file objects that share the same server and fsid attribute (Section 5.8.1.9). See below for details regarding when such sharing is in effect.
2. 对于共享相同服务器和fsid属性的某些或所有文件对象，每个文件系统属性的属性值将相同（第5.8.1.9节）。有关此类共享何时生效的详细信息，请参见下文。
3. per-file system object attributes.
3. 每个文件系统对象属性。
The handling of per-file system attributes depends on the particular attribute and the setting of the homogeneous (Section 5.8.2.12) attribute. The following rules apply:
每个文件系统属性的处理取决于特定属性和同质（第5.8.2.12节）属性的设置。以下规则适用：
1. The values of the attributes supported_attrs, fsid, homogeneous, link_support, and symlink_support are always common to all objects within the given file system.
1. 支持的属性值\u attrs、fsid、齐次、链接\u支持和符号链接\u支持对于给定文件系统中的所有对象始终是通用的。
2. For other attributes, different values may be returned for different file system objects if the attribute homogeneous is supported within the file system in question and has the value false.
2. 对于其他属性，如果所讨论的文件系统中支持同构属性且其值为false，则可能会为不同的文件系统对象返回不同的值。
The classification of attributes is as follows. Note that the attributes time_access_set and time_modify_set are not listed in this section, because they are write-only attributes corresponding to time_access and time_modify and are used in a special instance of SETATTR.
属性的分类如下。请注意，属性time_access_set和time_modify_set未在本节中列出，因为它们是与time_access和time_modify相对应的仅写属性，并在SETATTR的特殊实例中使用。
o The per-server attribute is:
o 每服务器属性为：
lease_time
租赁时间
o The per-file system attributes are:
o 每个文件系统的属性包括：
supported_attrs, fh_expire_type, link_support, symlink_support, unique_handles, aclsupport, cansettime, case_insensitive, case_preserving, chown_restricted, files_avail, files_free, files_total, fs_locations, homogeneous, maxfilesize, maxname, maxread, maxwrite, no_trunc, space_avail, space_free, space_total, and time_delta
受支持的属性、fh过期类型、链接支持、符号链接支持、唯一句柄、aclsupport、cansettime、不区分大小写、保留大小写、chown限制、文件可用、文件可用、文件总数、fs位置、同构、maxfilesize、maxname、maxread、maxwrite、no-trunc、空格可用、空格可用、空格总数和时间增量
o The per-file system object attributes are:
o 每个文件系统对象属性包括：
type, change, size, named_attr, fsid, rdattr_error, filehandle, acl, archive, fileid, hidden, maxlink, mimetype, mode, numlinks, owner, owner_group, rawdev, space_used, system, time_access, time_backup, time_create, time_metadata, time_modify, and mounted_on_fileid
类型、更改、大小、命名属性、fsid、rdattr错误、文件句柄、acl、存档、文件ID、隐藏、maxlink、mimetype、模式、numlinks、所有者、所有者组、rawdev、使用的空间、系统、时间访问、时间备份、时间创建、时间元数据、时间修改和在文件ID上装载
For quota_avail_hard, quota_avail_soft, and quota_used, see their definitions below for the appropriate classification.
有关配额\可用\硬、配额\可用\软和使用的配额\的定义，请参见下面的相应分类。
Some REQUIRED and RECOMMENDED attributes are set-only; i.e., they can be set via SETATTR but not retrieved via GETATTR. Similarly, some REQUIRED and RECOMMENDED attributes are get-only; i.e., they can be retrieved via GETATTR but not set via SETATTR. If a client attempts to set a get-only attribute or get a set-only attribute, the server MUST return NFS4ERR_INVAL.
仅设置了一些必需和推荐的属性；i、 例如，它们可以通过SETATTR设置，但不能通过GETATTR检索。类似地，一些必需的和推荐的属性是get only；i、 例如，它们可以通过GETATTR检索，但不能通过SETATTR设置。如果客户端试图设置get only属性或get only属性，则服务器必须返回NFS4ERR_INVAL。
The list of REQUIRED attributes appears in Table 3. The meanings of the columns of the table are:
所需属性列表如表3所示。表中各列的含义如下：
o Name: The name of the attribute.
o 名称：属性的名称。
o ID: The number assigned to the attribute. In the event of conflicts between the assigned number and [RFC7531], the latter is authoritative, but in such an event, it should be resolved with errata to this document and/or [RFC7531]. See [IESG_ERRATA] for the errata process.
o ID：分配给属性的编号。如果分配的编号与[RFC7531]之间存在冲突，后者具有权威性，但在这种情况下，应使用本文件和/或[RFC7531]的勘误表予以解决。有关勘误表流程，请参见[IESG_勘误表]。
o Data Type: The XDR data type of the attribute.
o 数据类型：属性的XDR数据类型。
o Acc: Access allowed to the attribute. R means read-only (GETATTR may retrieve, SETATTR may not set). W means write-only (SETATTR may set, GETATTR may not retrieve). R W means read/write (GETATTR may retrieve, SETATTR may set).
o Acc：允许访问该属性。R表示只读（GETATTR可以检索，SETATTR可以不设置）。W表示仅写（SETATTR可以设置，GETATTR不能检索）。RW表示读/写（GETATTR可以检索，SETATTR可以设置）。
o Defined in: The section of this specification that describes the attribute.
o 定义于：本规范中描述属性的部分。
+-----------------+----+------------+-----+-------------------+
| Name | ID | Data Type | Acc | Defined in |
+-----------------+----+------------+-----+-------------------+
| 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 |
| change | 3 | changeid4 | R | Section 5.8.1.4 |
| size | 4 | uint64_t | R W | Section 5.8.1.5 |
| link_support | 5 | bool | R | Section 5.8.1.6 |
| symlink_support | 6 | bool | R | Section 5.8.1.7 |
| 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 | nfsstat4 | R | Section 5.8.1.12 |
| filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 |
+-----------------+----+------------+-----+-------------------+
+-----------------+----+------------+-----+-------------------+
| Name | ID | Data Type | Acc | Defined in |
+-----------------+----+------------+-----+-------------------+
| 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 |
| change | 3 | changeid4 | R | Section 5.8.1.4 |
| size | 4 | uint64_t | R W | Section 5.8.1.5 |
| link_support | 5 | bool | R | Section 5.8.1.6 |
| symlink_support | 6 | bool | R | Section 5.8.1.7 |
| 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 | nfsstat4 | R | Section 5.8.1.12 |
| filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 |
+-----------------+----+------------+-----+-------------------+
Table 3: REQUIRED Attributes
表3：所需属性
The RECOMMENDED attributes are defined in Table 4. The meanings of the column headers are the same as Table 3; see Section 5.6 for the meanings.
表4中定义了推荐的属性。列标题的含义与表3相同；含义见第5.6节。
+-------------------+----+-----------------+-----+------------------+
| Name | ID | Data Type | Acc | Defined in |
+-------------------+----+-----------------+-----+------------------+
| acl | 12 | nfsace4<> | R W | Section 6.2.1 |
| aclsupport | 13 | uint32_t | R | Section 6.2.1.2 |
| archive | 14 | bool | R W | Section 5.8.2.1 |
| cansettime | 15 | bool | R | Section 5.8.2.2 |
| case_insensitive | 16 | bool | R | Section 5.8.2.3 |
| case_preserving | 17 | bool | R | Section 5.8.2.4 |
| chown_restricted | 18 | bool | R | Section 5.8.2.5 |
| fileid | 20 | uint64_t | R | Section 5.8.2.6 |
| files_avail | 21 | uint64_t | R | Section 5.8.2.7 |
| files_free | 22 | uint64_t | R | Section 5.8.2.8 |
| files_total | 23 | uint64_t | R | Section 5.8.2.9 |
+-------------------+----+-----------------+-----+------------------+
| Name | ID | Data Type | Acc | Defined in |
+-------------------+----+-----------------+-----+------------------+
| acl | 12 | nfsace4<> | R W | Section 6.2.1 |
| aclsupport | 13 | uint32_t | R | Section 6.2.1.2 |
| archive | 14 | bool | R W | Section 5.8.2.1 |
| cansettime | 15 | bool | R | Section 5.8.2.2 |
| case_insensitive | 16 | bool | R | Section 5.8.2.3 |
| case_preserving | 17 | bool | R | Section 5.8.2.4 |
| chown_restricted | 18 | bool | R | Section 5.8.2.5 |
| fileid | 20 | uint64_t | R | Section 5.8.2.6 |
| files_avail | 21 | uint64_t | R | Section 5.8.2.7 |
| files_free | 22 | uint64_t | R | Section 5.8.2.8 |
| files_total | 23 | uint64_t | R | Section 5.8.2.9 |
| fs_locations | 24 | fs_locations4 | R | Section 5.8.2.10 |
| hidden | 25 | bool | R W | Section 5.8.2.11 |
| homogeneous | 26 | bool | R | Section 5.8.2.12 |
| maxfilesize | 27 | uint64_t | R | Section 5.8.2.13 |
| maxlink | 28 | uint32_t | R | Section 5.8.2.14 |
| maxname | 29 | uint32_t | R | Section 5.8.2.15 |
| maxread | 30 | uint64_t | R | Section 5.8.2.16 |
| maxwrite | 31 | uint64_t | R | Section 5.8.2.17 |
| mimetype | 32 | ascii_ | R W | Section 5.8.2.18 |
| | | REQUIRED4<> | | |
| mode | 33 | mode4 | R W | Section 6.2.2 |
| mounted_on_fileid | 55 | uint64_t | R | Section 5.8.2.19 |
| no_trunc | 34 | bool | R | Section 5.8.2.20 |
| numlinks | 35 | uint32_t | R | Section 5.8.2.21 |
| owner | 36 | utf8str_mixed | R W | Section 5.8.2.22 |
| owner_group | 37 | utf8str_mixed | R W | Section 5.8.2.23 |
| quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.24 |
| quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.25 |
| quota_used | 40 | uint64_t | R | Section 5.8.2.26 |
| rawdev | 41 | specdata4 | R | Section 5.8.2.27 |
| space_avail | 42 | uint64_t | R | Section 5.8.2.28 |
| space_free | 43 | uint64_t | R | Section 5.8.2.29 |
| space_total | 44 | uint64_t | R | Section 5.8.2.30 |
| space_used | 45 | uint64_t | R | Section 5.8.2.31 |
| system | 46 | bool | R W | Section 5.8.2.32 |
| time_access | 47 | nfstime4 | R | Section 5.8.2.33 |
| time_access_set | 48 | settime4 | W | Section 5.8.2.34 |
| time_backup | 49 | nfstime4 | R W | Section 5.8.2.35 |
| time_create | 50 | nfstime4 | R W | Section 5.8.2.36 |
| time_delta | 51 | nfstime4 | R | Section 5.8.2.37 |
| time_metadata | 52 | nfstime4 | R | Section 5.8.2.38 |
| time_modify | 53 | nfstime4 | R | Section 5.8.2.39 |
| time_modify_set | 54 | settime4 | W | Section 5.8.2.40 |
+-------------------+----+-----------------+-----+------------------+
| fs_locations | 24 | fs_locations4 | R | Section 5.8.2.10 |
| hidden | 25 | bool | R W | Section 5.8.2.11 |
| homogeneous | 26 | bool | R | Section 5.8.2.12 |
| maxfilesize | 27 | uint64_t | R | Section 5.8.2.13 |
| maxlink | 28 | uint32_t | R | Section 5.8.2.14 |
| maxname | 29 | uint32_t | R | Section 5.8.2.15 |
| maxread | 30 | uint64_t | R | Section 5.8.2.16 |
| maxwrite | 31 | uint64_t | R | Section 5.8.2.17 |
| mimetype | 32 | ascii_ | R W | Section 5.8.2.18 |
| | | REQUIRED4<> | | |
| mode | 33 | mode4 | R W | Section 6.2.2 |
| mounted_on_fileid | 55 | uint64_t | R | Section 5.8.2.19 |
| no_trunc | 34 | bool | R | Section 5.8.2.20 |
| numlinks | 35 | uint32_t | R | Section 5.8.2.21 |
| owner | 36 | utf8str_mixed | R W | Section 5.8.2.22 |
| owner_group | 37 | utf8str_mixed | R W | Section 5.8.2.23 |
| quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.24 |
| quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.25 |
| quota_used | 40 | uint64_t | R | Section 5.8.2.26 |
| rawdev | 41 | specdata4 | R | Section 5.8.2.27 |
| space_avail | 42 | uint64_t | R | Section 5.8.2.28 |
| space_free | 43 | uint64_t | R | Section 5.8.2.29 |
| space_total | 44 | uint64_t | R | Section 5.8.2.30 |
| space_used | 45 | uint64_t | R | Section 5.8.2.31 |
| system | 46 | bool | R W | Section 5.8.2.32 |
| time_access | 47 | nfstime4 | R | Section 5.8.2.33 |
| time_access_set | 48 | settime4 | W | Section 5.8.2.34 |
| time_backup | 49 | nfstime4 | R W | Section 5.8.2.35 |
| time_create | 50 | nfstime4 | R W | Section 5.8.2.36 |
| time_delta | 51 | nfstime4 | R | Section 5.8.2.37 |
| time_metadata | 52 | nfstime4 | R | Section 5.8.2.38 |
| time_modify | 53 | nfstime4 | R | Section 5.8.2.39 |
| time_modify_set | 54 | settime4 | W | Section 5.8.2.40 |
+-------------------+----+-----------------+-----+------------------+
Table 4: RECOMMENDED Attributes
表4：建议属性
The bit vector that would retrieve all REQUIRED and RECOMMENDED attributes that are supported for this object. The scope of this attribute applies to all objects with a matching fsid.
将检索此对象支持的所有必需和推荐属性的位向量。此属性的范围适用于具有匹配fsid的所有对象。
Designates the type of an object in terms of one of a number of special constants:
根据许多特殊常数中的一个指定对象的类型：
o NF4REG designates a regular file.
o NF4REG指定一个常规文件。
o NF4DIR designates a directory.
o NF4DIR指定一个目录。
o NF4BLK designates a block device special file.
o NF4BLK指定块设备专用文件。
o NF4CHR designates a character device special file.
o NF4CHR指定字符设备专用文件。
o NF4LNK designates a symbolic link.
o NF4LNK指定符号链接。
o NF4SOCK designates a named socket special file.
o NF4SOCK指定一个命名套接字特殊文件。
o NF4FIFO designates a fifo special file.
o NF4FIFO指定一个fifo特殊文件。
o NF4ATTRDIR designates a named attribute directory.
o NF4ATTRDIR指定一个命名的属性目录。
o NF4NAMEDATTR designates a named attribute.
o NF4NAMEDATTR指定一个命名属性。
Within the explanatory text and operation descriptions, the following phrases will be used with the meanings given below:
在解释性文本和操作说明中，将使用以下短语，其含义如下：
o The phrase "is a directory" means that the object's type attribute is NF4DIR or NF4ATTRDIR.
o 短语“is a directory”表示对象的type属性是NF4DIR或NF4ATTRDIR。
o The phrase "is a special file" means that the object's type attribute is NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO.
o 短语“是一个特殊文件”表示对象的type属性是NF4BLK、NF4CHR、NF4SOCK或NF4FIFO。
o The phrase "is a regular file" means that the object's type attribute is NF4REG or NF4NAMEDATTR.
o 短语“是常规文件”表示对象的type属性是NF4REG或NF4NAMEDATTR。
o The phrase "is a symbolic link" means that the object's type attribute is NF4LNK.
o 短语“是符号链接”表示对象的type属性是NF4LNK。
The server uses this to specify filehandle expiration behavior to the client. See Section 4 for additional description.
服务器使用此选项为客户端指定文件句柄过期行为。更多说明见第4节。
A value created by the server that the client can use to determine if file data, directory contents, or attributes of the object have been modified. The server MAY return the object's time_metadata attribute for this attribute's value but only if the file system object cannot be updated more frequently than the resolution of time_metadata.
由服务器创建的值，客户端可使用该值确定对象的文件数据、目录内容或属性是否已修改。服务器可以为该属性的值返回对象的time_元数据属性，但仅当文件系统对象的更新频率不能超过time_元数据的解析频率时。
The size of the object in bytes.
对象的大小（以字节为单位）。
TRUE, if the object's file system supports hard links.
如果对象的文件系统支持硬链接，则为TRUE。
TRUE, if the object's file system supports symbolic links.
如果对象的文件系统支持符号链接，则为TRUE。
TRUE, if this object has named attributes. In other words, this object has a non-empty named attribute directory.
如果此对象具有命名属性，则为TRUE。换句话说，这个对象有一个非空的命名属性目录。
Unique file system identifier for the file system holding this object. The fsid attribute has major and minor components, each of which are of data type uint64_t.
保存此对象的文件系统的唯一文件系统标识符。fsid属性有主要和次要组件，每个组件都是数据类型uint64\u t。
TRUE, if two distinct filehandles are guaranteed to refer to two different file system objects.
如果保证两个不同的文件句柄引用两个不同的文件系统对象，则为TRUE。
Duration of the lease at the server in seconds.
服务器上租约的持续时间（秒）。
Error returned from an attempt to retrieve attributes during a READDIR operation.
在READDIR操作期间尝试检索属性时返回错误。
The filehandle of this object (primarily for READDIR requests).
此对象的文件句柄（主要用于READDIR请求）。
The definitions of most of the RECOMMENDED attributes follow. Collections that share a common category are defined in other sections.
大多数推荐属性的定义如下。共享公共类别的集合在其他部分中定义。
TRUE, if this file has been archived since the time of the last modification (deprecated in favor of time_backup).
如果此文件自上次修改后已存档（不推荐使用time\u备份），则为TRUE。
TRUE, if the server is able to change the times for a file system object as specified in a SETATTR operation.
如果服务器能够更改SETATTR操作中指定的文件系统对象的时间，则为TRUE。
TRUE, if filename comparisons on this file system are case insensitive. This refers only to comparisons, and not to the case in which filenames are stored.
如果此文件系统上的文件名比较不区分大小写，则为TRUE。这只是指比较，而不是指存储文件名的情况。
TRUE, if the filename case on this file system is preserved. This refers only to how filenames are stored, and not to how they are compared. Filenames stored in mixed case might be compared using either case-insensitive or case-sensitive comparisons.
如果保留此文件系统上的文件名大小写，则为TRUE。这只是指文件名的存储方式，而不是它们的比较方式。存储在混合大小写中的文件名可以使用不区分大小写或区分大小写的比较进行比较。
If TRUE, the server will reject any request to change either the owner or the group associated with a file if the caller is not a privileged user (for example, "root" in UNIX operating environments or the "Take Ownership" privilege in Windows 2000).
如果为TRUE，则如果调用方不是特权用户（例如，UNIX操作环境中的“root”或Windows 2000中的“Take owner”特权），服务器将拒绝任何更改与文件关联的所有者或组的请求。
A number uniquely identifying the file within the file system.
在文件系统中唯一标识文件的编号。
File slots available to this user on the file system containing this object -- this should be the smallest relevant limit.
此用户在包含此对象的文件系统上可用的文件槽——这应该是最小的相关限制。
Free file slots on the file system containing this object -- this should be the smallest relevant limit.
包含此对象的文件系统上的可用文件插槽——这应该是最小的相关限制。
Total file slots on the file system containing this object.
包含此对象的文件系统上的文件插槽总数。
Locations where this file system may be found. If the server returns NFS4ERR_MOVED as an error, this attribute MUST be supported.
可以找到此文件系统的位置。如果服务器返回NFS4ERR_MOVED作为错误，则必须支持此属性。
The server specifies the rootpath for a given server by returning a path consisting of zero path components.
服务器通过返回由零路径组件组成的路径来指定给定服务器的根路径。
TRUE, if the file is considered hidden with respect to the Windows API.
如果文件相对于Windows API被认为是隐藏的，则为TRUE。
TRUE, if this object's file system is homogeneous, i.e., all objects in the file system (all objects on the server with the same fsid) have common values for all per-file system attributes.
如果此对象的文件系统是同构的，即文件系统中的所有对象（服务器上具有相同fsid的所有对象）都具有每个文件系统属性的公共值，则为TRUE。
Maximum supported file size for the file system of this object.
此对象的文件系统支持的最大文件大小。
Maximum number of hard links for this object.
此对象的最大硬链接数。
Maximum filename size supported for this object.
此对象支持的最大文件名大小。
Maximum amount of data the READ operation will return for this object.
读取操作将为此对象返回的最大数据量。
Maximum amount of data the WRITE operation will accept for this object. This attribute SHOULD be supported if the file is writable. Lack of this attribute can lead to the client either wasting bandwidth or not receiving the best performance.
写入操作将为此对象接受的最大数据量。如果文件可写，则应支持此属性。缺少此属性可能会导致客户端浪费带宽或无法获得最佳性能。
MIME media type/subtype of this object.
此对象的MIME媒体类型/子类型。
Like fileid, but if the target filehandle is the root of a file system, this attribute represents the fileid of the underlying directory.
类似于fileid，但如果目标filehandle是文件系统的根，则此属性表示基础目录的fileid。
UNIX-based operating environments connect a file system into the namespace by connecting (mounting) the file system onto the existing file object (the mount point, usually a directory) of an existing file system. When the mount point's parent directory is read via an API such as readdir() [readdir_api], the return results are directory entries, each with a component name and a fileid. The fileid of the mount point's directory entry will be different from the fileid that the stat() [stat] system call returns. The stat() system call is returning the fileid of the root of the mounted file system, whereas readdir() is returning the fileid that stat() would have returned before any file systems were mounted on the mount point.
基于UNIX的操作环境通过将文件系统连接（装载）到现有文件系统的现有文件对象（装载点，通常是目录）上，将文件系统连接到命名空间中。当通过诸如readdir（）[readdir_API]之类的API读取装载点的父目录时，返回的结果是目录项，每个目录项都有一个组件名和一个文件ID。装载点目录项的fileid将不同于stat（）[stat]系统调用返回的fileid。stat（）系统调用返回装载的文件系统的根的fileid，而readdir（）返回在装载点上装载任何文件系统之前stat（）将返回的fileid。
Unlike NFSv3, NFSv4.0 allows a client's LOOKUP request to cross other file systems. The client detects the file system crossing whenever the filehandle argument of LOOKUP has an fsid attribute different from that of the filehandle returned by LOOKUP. A UNIX-based client will consider this a "mount point crossing". UNIX has a legacy scheme for allowing a process to determine its current working directory. This relies on readdir() of a mount point's parent and stat() of the mount point returning fileids as previously described. The mounted_on_fileid attribute corresponds to the fileid that readdir() would have returned, as described previously.
与NFSv3不同，NFSv4.0允许客户端的查找请求跨其他文件系统。只要LOOKUP的filehandle参数具有与LOOKUP返回的filehandle不同的fsid属性，客户端就会检测文件系统交叉。一个基于UNIX的客户端将考虑这是一个“挂载点交叉”。UNIX有一个遗留方案，允许进程确定其当前工作目录。这依赖于装载点的父级的readdir（）和装载点的stat（），如前所述返回fileid。如前所述，mounted_on_fileid属性对应于readdir（）将返回的fileid。
While the NFSv4.0 client could simply fabricate a fileid corresponding to what mounted_on_fileid provides (and if the server does not support mounted_on_fileid, the client has no choice), there is a risk that the client will generate a fileid that conflicts with one that is already assigned to another object in the file system. Instead, if the server can provide the mounted_on_fileid, the potential for client operational problems in this area is eliminated.
虽然NFSv4.0客户端可以简单地创建一个与mounted_on_fileid提供的内容相对应的fileid（如果服务器不支持mounted_on_fileid，则客户端别无选择），但客户端生成的fileid可能与已分配给文件系统中另一个对象的fileid冲突。相反，如果服务器可以提供挂载的\u on_文件ID，则可以消除此区域中客户端操作问题的可能性。
If the server detects that there is nothing mounted on top of the target file object, then the value for mounted_on_fileid that it returns is the same as that of the fileid attribute.
如果服务器检测到目标文件对象顶部没有装载任何内容，那么它返回的mounted_on_fileid的值与fileid属性的值相同。
The mounted_on_fileid attribute is RECOMMENDED, so the server SHOULD provide it if possible, and for a UNIX-based server, this is straightforward. Usually, mounted_on_fileid will be requested during a READDIR operation, in which case it is trivial (at least for UNIX-based servers) to return mounted_on_fileid since it is equal to the fileid of a directory entry returned by readdir(). If mounted_on_fileid is requested in a GETATTR operation, the server should obey an invariant that has it returning a value that is equal to the file object's entry in the object's parent directory, i.e., what readdir() would have returned. Some operating environments allow a series of two or more file systems to be mounted onto a single mount point. In this case, for the server to obey the aforementioned invariant, it will need to find the base mount point, and not the intermediate mount points.
建议使用mounted_on_fileid属性，因此如果可能，服务器应该提供它，对于基于UNIX的服务器，这是很简单的。通常，在READDIR操作期间会请求在\u fileid上挂载的\u，在这种情况下，返回在\u fileid上挂载的\u很简单（至少对于基于UNIX的服务器而言），因为它等于READDIR（）返回的目录项的fileid。如果在GETATTR操作中请求挂载在文件ID上的文件，则服务器应遵循一个不变量，该不变量使其返回一个值，该值等于对象父目录中文件对象的条目，即readdir（）将返回的值。某些操作环境允许将一系列两个或多个文件系统装载到单个装载点上。在这种情况下，为了使服务器遵守上述不变量，它需要找到基本装载点，而不是中间装载点。
If this attribute is TRUE, then if the client uses a filename longer than name_max, an error will be returned instead of the name being truncated.
如果此属性为TRUE，则如果客户端使用的文件名长于name_max，则将返回错误，而不是截断名称。
Number of hard links to this object.
指向此对象的硬链接数。
The string name of the owner of this object.
此对象所有者的字符串名称。
The string name of the group ownership of this object.
此对象的组所有权的字符串名称。
The value in bytes that represents the amount of additional disk space beyond the current allocation that can be allocated to this file or directory before further allocations will be refused. It is understood that this space may be consumed by allocations to other files or directories.
以字节为单位的值，表示在拒绝进一步分配之前，可以分配给此文件或目录的超出当前分配的额外磁盘空间量。可以理解的是，分配给其他文件或目录可能会占用此空间。
The value in bytes that represents the amount of additional disk space that can be allocated to this file or directory before the user may reasonably be warned. It is understood that this space may be consumed by allocations to other files or directories, though there may exist server-side rules as to which other files or directories.
以字节为单位的值，表示在合理警告用户之前可以分配给此文件或目录的额外磁盘空间量。可以理解的是，分配给其他文件或目录可能会占用此空间，尽管可能存在关于哪些文件或目录的服务器端规则。
The value in bytes that represents the amount of disk space used by this file or directory and possibly a number of other similar files or directories, where the set of "similar" meets at least the criterion that allocating space to any file or directory in the set will reduce the "quota_avail_hard" of every other file or directory in the set.
以字节为单位的值，表示此文件或目录以及可能的许多其他类似文件或目录所使用的磁盘空间量，其中“相似”集合至少满足将空间分配给集合中的任何文件或目录将减少集合中每个其他文件或目录的“配额利用率”。
Note that there may be a number of distinct but overlapping sets of files or directories for which a quota_used value is maintained, e.g., "all files with a given owner", "all files with a given group owner", etc. The server is at liberty to choose any of those sets when providing the content of the quota_used attribute but should do so in a repeatable way. The rule may be configured per file system or may be "choose the set with the smallest quota".
请注意，可能存在许多不同但重叠的文件或目录集，这些文件或目录保留了配额使用值，例如，“具有给定所有者的所有文件”、“具有给定组所有者的所有文件”，等等。当提供quota_used属性的内容时，服务器可以自由选择这些集合中的任何一个，但应以可重复的方式进行选择。规则可以按文件系统配置，也可以是“选择配额最小的集合”。
Raw device number of file of type NF4BLK or NF4CHR. The device number is split into major and minor numbers. If the file's type attribute is not NF4BLK or NF4CHR, this attribute SHOULD NOT be returned, and any value returned SHOULD NOT be considered useful.
NF4BLK或NF4CHR类型文件的原始设备号。设备编号分为主要编号和次要编号。如果文件的type属性不是NF4BLK或NF4CHR，则不应返回此属性，并且不应认为返回的任何值有用。
Disk space in bytes available to this user on the file system containing this object -- this should be the smallest relevant limit.
在包含此对象的文件系统上，此用户可用的磁盘空间（字节）——这应该是最小的相关限制。
Free disk space in bytes on the file system containing this object -- this should be the smallest relevant limit.
包含此对象的文件系统上的可用磁盘空间（以字节为单位）——这应该是最小的相关限制。
Total disk space in bytes on the file system containing this object.
包含此对象的文件系统上的总磁盘空间（字节）。
Number of file system bytes allocated to this object.
分配给此对象的文件系统字节数。
TRUE, if this file is a "system" file with respect to the Windows operating environment.
如果此文件是相对于Windows操作环境的“系统”文件，则为TRUE。
Represents the time of last access to the object by a READ operation sent to the server. The notion of what is an "access" depends on the server's operating environment and/or the server's file system semantics. For example, for servers obeying Portable Operating System Interface (POSIX) semantics, time_access would be updated only by the READ and READDIR operations and not any of the operations that modify the content of the object [read_api], [readdir_api], [write_api]. Of course, setting the corresponding time_access_set attribute is another way to modify the time_access attribute.
表示通过发送到服务器的读取操作上次访问对象的时间。什么是“访问”的概念取决于服务器的操作环境和/或服务器的文件系统语义。例如，对于遵循可移植操作系统接口（POSIX）语义的服务器，时间访问将仅由读取和读取操作更新，而不是任何修改对象内容的操作[READ_api]、[READDIR_api]、[write_api]。当然，设置相应的time\u access\u set属性是修改time\u access属性的另一种方法。
Whenever the file object resides on a writable file system, the server should make its best efforts to record time_access into stable storage. However, to mitigate the performance effects of doing so, and most especially whenever the server is satisfying the read of the object's content from its cache, the server MAY cache access time updates and lazily write them to stable storage. It is also acceptable to give administrators of the server the option to disable time_access updates.
每当文件对象驻留在可写文件系统上时，服务器应尽最大努力记录访问稳定存储的时间。但是，为了减轻这样做对性能的影响，尤其是当服务器满足从其缓存读取对象内容的要求时，服务器可能会缓存访问时间更新，并将其惰性地写入稳定存储器。允许服务器管理员选择禁用时间访问更新也是可以接受的。
Sets the time of last access to the object. SETATTR use only.
设置上次访问对象的时间。SETATTR仅用于。
The time of last backup of the object.
上次备份对象的时间。
The time of creation of the object. This attribute does not have any relation to the traditional UNIX file attribute "ctime" ("change time").
对象的创建时间。此属性与传统的UNIX文件属性“ctime”（“更改时间”）没有任何关系。
Smallest useful server time granularity.
最小有用的服务器时间粒度。
The time of last metadata modification of the object.
上次修改对象元数据的时间。
The time of last modification to the object.
上次修改对象的时间。
Sets the time of last modification to the object. SETATTR use only.
设置上次修改对象的时间。SETATTR仅用于。
The RECOMMENDED attributes "owner" and "owner_group" (and also users and groups used as values of the who field within nfs4ace structures used in the acl attribute) are represented in the form of UTF-8 strings. This format avoids the use of a representation that is tied to a particular underlying implementation at the client or server. Note that Section 6.1 of [RFC2624] provides additional rationale. It is expected that the client and server will have their own local representation of owners and groups that is used for local storage or presentation to the application via APIs that expect such a representation. Therefore, the protocol requires that when these attributes are transferred between the client and server, the local representation is translated to a string of the form "identifier@dns_domain". This allows clients and servers that do not use the same local representation to effectively interoperate since they both use a common syntax that can be interpreted by both.
推荐的属性“owner”和“owner_group”（以及用作acl属性中使用的nfs4ace结构中who字段值的用户和组）以UTF-8字符串的形式表示。这种格式避免使用与客户机或服务器上的特定底层实现绑定的表示。请注意，[RFC2624]第6.1节提供了额外的基本原理。预期客户机和服务器将拥有自己的所有者和组的本地表示，这些所有者和组用于本地存储或通过期望这种表示的API向应用程序进行表示。因此，协议要求在客户端和服务器之间传输这些属性时，将本地表示转换为以下形式的字符串“identifier@dns_domain". 这使得不使用相同本地表示的客户机和服务器能够有效地进行互操作，因为它们都使用可以由双方解释的通用语法。
Similarly, security principals may be represented in different ways by different security mechanisms. Servers normally translate these representations into a common format, generally that used by local storage, to serve as a means of identifying the users corresponding to these security principals. When these local identifiers are translated to the form of the owner attribute, associated with files created by such principals, they identify, in a common format, the users associated with each corresponding set of security principals.
类似地，安全主体可以通过不同的安全机制以不同的方式表示。服务器通常将这些表示转换为通用格式（通常由本地存储使用），作为识别与这些安全主体相对应的用户的手段。当这些本地标识符被转换为与这些主体创建的文件相关联的所有者属性的形式时，它们以公共格式标识与每个对应的安全主体集相关联的用户。
The translation used to interpret owner and group strings is not specified as part of the protocol. This allows various solutions to be employed. For example, a local translation table may be consulted that maps a numeric identifier to the user@dns_domain syntax. A name service may also be used to accomplish the translation. A server may provide a more general service, not limited by any particular translation (which would only translate a limited set of possible strings) by storing the owner and owner_group attributes in local storage without any translation, or it may augment a translation
用于解释所有者和组字符串的转换未指定为协议的一部分。这允许采用各种解决方案。例如，可以参考将数字标识符映射到本地的本地翻译表user@dns_domain语法。名称服务也可用于完成翻译。服务器可以通过将所有者和所有者组属性存储在本地存储器中而不进行任何转换来提供更一般的服务，而不受任何特定转换（仅转换有限的一组可能字符串）的限制，也可以增加转换
method by storing the entire string for attributes for which no translation is available while using the local representation for those cases in which a translation is available.
方法，方法是存储没有翻译可用的属性的整个字符串，同时对有翻译可用的情况使用局部表示。
Servers that do not provide support for all possible values of user and group strings SHOULD return an error (NFS4ERR_BADOWNER) when a string is presented that has no translation, as the value to be set for a SETATTR of the owner or owner_group attributes or as part of the value of the acl attribute. When a server does accept a user or group string as valid on a SETATTR, it is promising to return that same string (see below) when a corresponding GETATTR is done, as long as there has been no further change in the corresponding attribute before the GETATTR. For some internationalization-related exceptions where this is not possible, see below. Configuration changes (including changes from the mapping of the string to the local representation) and ill-constructed name translations (those that contain aliasing) may make that promise impossible to honor. Servers should make appropriate efforts to avoid a situation in which these attributes have their values changed when no real change to either ownership or acls has occurred.
当显示没有翻译的字符串时，不支持用户和组字符串的所有可能值的服务器应返回一个错误（NFS4ERR_BADOWNER），作为要为所有者或所有者组属性的SETATTR设置的值，或作为acl属性值的一部分。当服务器确实接受用户或组字符串作为SETATTR上的有效字符串时，只要在GETATTR之前对应的属性没有进一步更改，则在相应的GETATTR完成时，它承诺返回相同的字符串（见下文）。对于一些无法实现国际化的例外情况，请参见下文。配置更改（包括从字符串映射到本地表示的更改）和构造错误的名称转换（那些包含别名的转换）可能会使这一承诺无法兑现。服务器应做出适当的努力，避免在所有权或ACL未发生实际更改的情况下，这些属性的值发生更改。
The "dns_domain" portion of the owner string is meant to be a DNS domain name -- for example, "user@example.org". Servers should accept as valid a set of users for at least one domain. A server may treat other domains as having no valid translations. A more general service is provided when a server is capable of accepting users for multiple domains, or for all domains, subject to security constraints.
所有者字符串的“dns_域”部分是指dns域名，例如user@example.org". 服务器应接受至少一个域的一组用户作为有效用户。服务器可能会将其他域视为没有有效的翻译。当服务器能够接受多个域或所有域的用户时，会提供更一般的服务，但会受到安全约束。
As an implementation guide, both clients and servers may provide a means to configure the "dns_domain" portion of the owner string. For example, the DNS domain name of the host running the NFS server might be "lab.example.org", but the user names are defined in "example.org". In the absence of such a configuration, or as a default, the current DNS domain name of the server should be the value used for the "dns_domain".
作为实现指南，客户端和服务器都可以提供一种方法来配置所有者字符串的“dns_域”部分。例如，运行NFS服务器的主机的DNS域名可能是“lab.example.org”，但用户名是在“example.org”中定义的。在没有此类配置的情况下，或者默认情况下，服务器的当前DNS域名应为用于“DNS_域”的值。
As mentioned above, it is desirable that a server, when accepting a string of the form "user@domain" or "group@domain" in an attribute, return this same string when that corresponding attribute is fetched. Internationalization issues make this impossible under certain circumstances, and the client needs to take note of these. See Section 12 for a detailed discussion of these issues.
如上所述，服务器在接受表单字符串时最好user@domain“或”group@domain在属性中，获取相应属性时返回相同的字符串。国际化问题使这在某些情况下不可能实现，客户需要注意这些问题。有关这些问题的详细讨论，请参见第12节。
In the case where there is no translation available to the client or server, the attribute value will be constructed without the "@". Therefore, the absence of the "@" from the owner or owner_group attribute signifies that no translation was available at the sender
如果客户机或服务器没有可用的转换，则将构造属性值，而不使用“@”。因此，owner或owner_group属性中没有“@”表示发送方没有可用的翻译
and that the receiver of the attribute should not use that string as a basis for translation into its own internal format. Even though the attribute value cannot be translated, it may still be useful. In the case of a client, the attribute string may be used for local display of ownership.
属性的接收者不应使用该字符串作为将其转换为自身内部格式的基础。即使无法转换属性值，它仍然可能有用。对于客户端，属性字符串可用于本地显示所有权。
To provide a greater degree of compatibility with NFSv3, which identified users and groups by 32-bit unsigned user identifiers and group identifiers, owner and group strings that consist of ASCII-encoded decimal numeric values with no leading zeros can be given a special interpretation by clients and servers that choose to provide such support. The receiver may treat such a user or group string as representing the same user as would be represented by an NFSv3 uid or gid having the corresponding numeric value.
NFSv3通过32位无符号用户标识符和组标识符标识用户和组，为了与NFSv3提供更大程度的兼容性，选择提供此类支持的客户端和服务器可以对由ASCII编码的十进制数值组成的所有者和组字符串进行特殊解释，这些十进制数值不带前导零。接收方可以将这样的用户或组字符串视为表示将由具有相应数值的NFSv3 uid或gid表示的相同用户。
A server SHOULD reject such a numeric value if the security mechanism is using Kerberos. That is, in such a scenario, the client will already need to form "user@domain" strings. For any other security mechanism, the server SHOULD accept such numeric values. As an implementation note, the server could make such an acceptance be configurable. If the server does not support numeric values or if it is configured off, then it MUST return an NFS4ERR_BADOWNER error. If the security mechanism is using Kerberos and the client attempts to use the special form, then the server SHOULD return an NFS4ERR_BADOWNER error when there is a valid translation for the user or owner designated in this way. In that case, the client must use the appropriate user@domain string and not the special form for compatibility.
如果安全机制使用Kerberos，则服务器应拒绝此类数值。也就是说，在这种情况下，客户机已经需要user@domain“弦。对于任何其他安全机制，服务器应接受此类数值。作为一个实现说明，服务器可以使这样的接受成为可配置的。如果服务器不支持数值或配置为关闭，则必须返回NFS4ERR_BADOWNER错误。如果安全机制使用Kerberos，并且客户端尝试使用特殊表单，则当存在以这种方式指定的用户或所有者的有效翻译时，服务器应返回NFS4ERR_BADOWNER错误。在这种情况下，客户必须使用适当的user@domain字符串，而不是兼容的特殊形式。
The client MUST always accept numeric values if the security mechanism is not RPCSEC_GSS. A client can determine if a server supports numeric identifiers by first attempting to provide a numeric identifier. If this attempt is rejected with an NFS4ERR_BADOWNER error, then the client should only use named identifiers of the form "user@dns_domain".
如果安全机制不是RPCSEC_GSS，则客户端必须始终接受数值。客户端可以通过首先尝试提供数字标识符来确定服务器是否支持数字标识符。如果此尝试因NFS4ERR_BADOWNER错误而被拒绝，则客户端应仅使用表单“”的命名标识符user@dns_domain".
The owner string "nobody" may be used to designate an anonymous user, which will be associated with a file created by a security principal that cannot be mapped through normal means to the owner attribute.
所有者字符串“nobody”可用于指定匿名用户，该用户将与安全主体创建的文件关联，该文件无法通过正常方式映射到所有者属性。
With respect to the case_insensitive and case_preserving attributes, case-insensitive comparisons of Unicode characters SHOULD use Unicode Default Case Folding as defined in Chapter 3 of the Unicode Standard [UNICODE] and MAY override that behavior for specific selected characters with the case folding defined in the SpecialCasing.txt [SPECIALCASING] file; see Section 3.13 of the Unicode Standard.
关于不区分大小写和保留大小写的属性，Unicode字符的不区分大小写比较应使用Unicode标准[Unicode]第3章中定义的Unicode默认大小写折叠，并可能使用SpecialCasing.txt中定义的大小写折叠覆盖特定选定字符的该行为[SPECIALCASING]文件；参见Unicode标准第3.13节。
The SpecialCasing.txt file replaces the Default Case Folding with locale- and context-dependent case folding for specific situations. An example of locale- and context-dependent case folding is that LATIN CAPITAL LETTER I ("I", U+0049) is default case folded to LATIN SMALL LETTER I ("i", U+0069). However, several languages (e.g., Turkish) treat an "I" character with a dot as a different letter than an "I" character without a dot; therefore, in such languages, unless an I is before a dot_above, the "I" (U+0049) character should be case folded to a different character, LATIN SMALL LETTER DOTLESS I (U+0131).
对于特定情况，SpecialCasing.txt文件将默认的大小写折叠替换为区域设置和上下文相关的大小写折叠。区域设置和上下文相关大小写折叠的一个示例是，拉丁大写字母I（“I”，U+0049）默认大小写折叠为拉丁小写字母I（“I”，U+0069）。但是，有几种语言（如土耳其语）将带点的“I”字符视为与不带点的“I”字符不同的字母；因此，在这些语言中，除非I在上面的点_之前，否则“I”（U+0049）字符应大小写折叠为另一个字符，即拉丁文小写字母无点I（U+0131）。
The [UNICODE] and [SPECIALCASING] references in this RFC are for version 7.0.0 of the Unicode standard, as that was the latest version of Unicode when this RFC was published. Implementations SHOULD always use the latest version of Unicode (<http://www.unicode.org/versions/latest/>).
本RFC中的[UNICODE]和[SPECIALCASING]引用适用于UNICODE标准的7.0.0版，因为这是本RFC发布时UNICODE的最新版本。实现应始终使用最新版本的Unicode(<http://www.unicode.org/versions/latest/>).
Access Control Lists (ACLs) are file attributes that specify fine-grained access control. This section covers the "acl", "aclsupport", and "mode" file attributes, and their interactions. Note that file attributes may apply to any file system object.
访问控制列表（ACL）是指定细粒度访问控制的文件属性。本节介绍“acl”、“aclsupport”和“mode”文件属性及其交互。请注意，文件属性可以应用于任何文件系统对象。
ACLs and modes represent two well-established models for specifying permissions. This section specifies requirements that attempt to meet the following goals:
ACL和模式代表两种用于指定权限的成熟模型。本节规定了试图达到以下目标的要求：
o If a server supports the mode attribute, it should provide reasonable semantics to clients that only set and retrieve the mode attribute.
o 如果服务器支持mode属性，那么它应该为只设置和检索mode属性的客户端提供合理的语义。
o If a server supports ACL attributes, it should provide reasonable semantics to clients that only set and retrieve those attributes.
o 如果服务器支持ACL属性，它应该为只设置和检索这些属性的客户端提供合理的语义。
o On servers that support the mode attribute, if ACL attributes have never been set on an object, via inheritance or explicitly, the behavior should be traditional UNIX-like behavior.
o 在支持mode属性的服务器上，如果从未通过继承或显式在对象上设置过ACL属性，则该行为应为传统的类UNIX行为。
o On servers that support the mode attribute, if the ACL attributes have been previously set on an object, either explicitly or via inheritance:
o 在支持mode属性的服务器上，如果先前已显式或通过继承在对象上设置了ACL属性，请执行以下操作：
* Setting only the mode attribute should effectively control the traditional UNIX-like permissions of read, write, and execute on owner, owner_group, and other.
* 仅设置mode属性应该可以有效地控制对owner、owner\u组和其他对象的读、写和执行的传统类UNIX权限。
* Setting only the mode attribute should provide reasonable security. For example, setting a mode of 000 should be enough to ensure that future opens for read or write by any principal fail, regardless of a previously existing or inherited ACL.
* 仅设置mode属性应提供合理的安全性。例如，将模式设置为000应该足以确保将来打开供任何主体读取或写入失败，而不管以前存在或继承的ACL如何。
o When a mode attribute is set on an object, the ACL attributes may need to be modified so as to not conflict with the new mode. In such cases, it is desirable that the ACL keep as much information as possible. This includes information about inheritance, AUDIT and ALARM access control entries (ACEs), and permissions granted and denied that do not conflict with the new mode.
o 在对象上设置模式属性时，可能需要修改ACL属性以避免与新模式冲突。在这种情况下，希望ACL保留尽可能多的信息。这包括有关继承、审核和报警访问控制项（ACE）以及授予和拒绝的与新模式不冲突的权限的信息。
Support for each of the ACL attributes is RECOMMENDED and not required, since file systems accessed using NFSv4 might not support ACLs.
由于使用NFSv4访问的文件系统可能不支持ACL，因此建议且不要求支持每个ACL属性。
The NFSv4.0 ACL attribute contains an array of ACEs that are associated with the file system object. Although the client can read and write the acl attribute, the server is responsible for using the ACL to perform access control. The client can use the OPEN or ACCESS operations to check access without modifying or reading data or metadata.
NFSv4.0 ACL属性包含与文件系统对象关联的ACE数组。尽管客户端可以读取和写入acl属性，但服务器负责使用acl执行访问控制。客户端可以使用OPEN或ACCESS操作来检查访问，而无需修改或读取数据或元数据。
The NFS ACE structure is defined as follows:
NFS ACE结构定义如下：
typedef uint32_t acetype4;
typedef uint32_t acetype4；
typedef uint32_t aceflag4;
typedef uint32_t aceflag4；
typedef uint32_t acemask4;
typedef uint32_t acemask4；
struct nfsace4 {
acetype4 type;
aceflag4 flag;
acemask4 access_mask;
utf8str_mixed who;
};
struct nfsace4 {
acetype4 type;
aceflag4 flag;
acemask4 access_mask;
utf8str_mixed who;
};
To determine if a request succeeds, the server processes each nfsace4 entry in order. Only ACEs that have a "who" that matches the requester are considered. Each ACE is processed until all of the bits of the requester's access have been ALLOWED. Once a bit (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer considered in the processing of later ACEs. If an ACCESS_DENIED_ACE
为了确定请求是否成功，服务器按顺序处理每个nfsace4条目。仅考虑具有与请求者匹配的“谁”的ACE。处理每个ACE，直到请求者访问的所有位都被允许。一旦一个位（见下文）被一个允许访问的ACE允许，它就不再被考虑在以后的ACE处理中。如果访问被拒绝
is encountered where the requester's access still has unALLOWED bits in common with the "access_mask" of the ACE, the request is denied. When the ACL is fully processed, if there are bits in the requester's mask that have not been ALLOWED or DENIED, access is denied.
如果请求者的访问仍有与ACE的“访问掩码”相同的未允许位，则请求被拒绝。完全处理ACL时，如果请求者掩码中有未被允许或拒绝的位，则拒绝访问。
Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE types do not affect a requester's access and instead are for triggering events as a result of a requester's access attempt. Therefore, AUDIT and ALARM ACEs are processed only after processing ALLOW and DENY ACEs.
与允许和拒绝ACE类型不同，报警和审核ACE类型不会影响请求者的访问，而是用于触发请求者尝试访问时发生的事件。因此，只有在处理“允许”和“拒绝”ACE之后，才会处理审核和报警ACE。
The NFSv4.0 ACL model is quite rich. Some server platforms may provide access control functionality that goes beyond the UNIX-style mode attribute but that is not as rich as the NFS ACL model. So that users can take advantage of this more limited functionality, the server may support the acl attributes by mapping between its ACL model and the NFSv4.0 ACL model. Servers must ensure that the ACL they actually store or enforce is at least as strict as the NFSv4 ACL that was set. It is tempting to accomplish this by rejecting any ACL that falls outside the small set that can be represented accurately. However, such an approach can render ACLs unusable without special client-side knowledge of the server's mapping, which defeats the purpose of having a common NFSv4 ACL protocol. Therefore, servers should accept every ACL that they can without compromising security. To help accomplish this, servers may make a special exception, in the case of unsupported permission bits, to the rule that bits not ALLOWED or DENIED by an ACL must be denied. For example, a UNIX-style server might choose to silently allow read attribute permissions even though an ACL does not explicitly allow those permissions. (An ACL that explicitly denies permission to read attributes should still result in a denial.)
NFSv4.0ACL模型非常丰富。某些服务器平台可能提供超越UNIX样式模式属性的访问控制功能，但没有NFS ACL模型丰富。为了使用户能够利用这一更有限的功能，服务器可以通过其acl模型和NFSv4.0 acl模型之间的映射来支持acl属性。服务器必须确保其实际存储或实施的ACL至少与设置的NFSv4 ACL一样严格。通过拒绝任何不属于可以准确表示的小集合的ACL来实现这一点是很有诱惑力的。然而，这种方法可能会使ACL在没有服务器映射的特殊客户端知识的情况下无法使用，这与使用通用NFSv4 ACL协议的目的背道而驰。因此，服务器应该在不影响安全性的情况下尽可能地接受每个ACL。为了帮助实现这一点，服务器可能会在权限位不受支持的情况下对ACL不允许或拒绝的位必须被拒绝的规则做出特殊的例外。例如，UNIX样式的服务器可能会选择以静默方式允许读取属性权限，即使ACL不显式允许这些权限。（明确拒绝读取属性权限的ACL仍应导致拒绝。）
The situation is complicated by the fact that a server may have multiple modules that enforce ACLs. For example, the enforcement for NFSv4.0 access may be different from, but not weaker than, the enforcement for local access, and both may be different from the enforcement for access through other protocols such as Server Message Block (SMB) [MS-SMB]. So it may be useful for a server to accept an ACL even if not all of its modules are able to support it.
服务器可能有多个强制ACL的模块，这一事实使情况变得复杂。例如，NFSv4.0访问的实施可能不同于但不弱于本地访问的实施，并且两者都可能不同于通过服务器消息块（SMB）[MS-SMB]等其他协议进行访问的实施。因此，即使不是所有的模块都能支持ACL，服务器接受ACL也是很有用的。
The guiding principle with regard to NFSv4 access is that the server must not accept ACLs that give an appearance of more restricted access to a file than what is actually enforced.
关于NFSv4访问的指导原则是，服务器不能接受ACL，因为这些ACL看起来对文件的访问比实际执行的访问更受限制。
The constants used for the type field (acetype4) are as follows:
类型字段（acetype4）使用的常量如下所示：
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000;
const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001;
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002;
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003;
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000;
const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001;
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002;
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003;
All four bit types are permitted in the acl attribute.
acl属性中允许所有四种位类型。
+------------------------------+--------------+---------------------+
| Value | Abbreviation | Description |
+------------------------------+--------------+---------------------+
| ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants |
| | | the access defined |
| | | in acemask4 to the |
| | | file or directory. |
| | | |
| ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies |
| | | the access defined |
| | | in acemask4 to the |
| | | file or directory. |
| | | |
| ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | LOG (in a system- |
| | | dependent way) any |
| | | access attempt to a |
| | | file or directory |
| | | that uses any of |
| | | the access methods |
| | | specified in |
| | | acemask4. |
| | | |
| ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generate a system |
| | | ALARM (system |
| | | dependent) when any |
| | | access attempt is |
| | | made to a file or |
| | | directory for the |
| | | access methods |
| | | specified in |
| | | acemask4. |
+------------------------------+--------------+---------------------+
+------------------------------+--------------+---------------------+
| Value | Abbreviation | Description |
+------------------------------+--------------+---------------------+
| ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants |
| | | the access defined |
| | | in acemask4 to the |
| | | file or directory. |
| | | |
| ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies |
| | | the access defined |
| | | in acemask4 to the |
| | | file or directory. |
| | | |
| ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | LOG (in a system- |
| | | dependent way) any |
| | | access attempt to a |
| | | file or directory |
| | | that uses any of |
| | | the access methods |
| | | specified in |
| | | acemask4. |
| | | |
| ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generate a system |
| | | ALARM (system |
| | | dependent) when any |
| | | access attempt is |
| | | made to a file or |
| | | directory for the |
| | | access methods |
| | | specified in |
| | | acemask4. |
+------------------------------+--------------+---------------------+
The "Abbreviation" column denotes how the types will be referred to throughout the rest of this section.
“缩写”列表示在本节其余部分中如何引用这些类型。
A server need not support all of the above ACE types. This attribute indicates which ACE types are supported for the current file system. The bitmask constants used to represent the above definitions within the aclsupport attribute are as follows:
服务器不需要支持上述所有ACE类型。此属性指示当前文件系统支持哪些ACE类型。用于在aclsupport属性中表示上述定义的位掩码常量如下所示：
const ACL4_SUPPORT_ALLOW_ACL = 0x00000001;
const ACL4_SUPPORT_DENY_ACL = 0x00000002;
const ACL4_SUPPORT_AUDIT_ACL = 0x00000004;
const ACL4_SUPPORT_ALARM_ACL = 0x00000008;
const ACL4_SUPPORT_ALLOW_ACL = 0x00000001;
const ACL4_SUPPORT_DENY_ACL = 0x00000002;
const ACL4_SUPPORT_AUDIT_ACL = 0x00000004;
const ACL4_SUPPORT_ALARM_ACL = 0x00000008;
Servers that support either the ALLOW or DENY ACE type SHOULD support both ALLOW and DENY ACE types.
支持ALLOW或DENY ACE类型的服务器应同时支持ALLOW和DENY ACE类型。
Clients should not attempt to set an ACE unless the server claims support for that ACE type. If the server receives a request to set an ACE that it cannot store, it MUST reject the request with NFS4ERR_ATTRNOTSUPP. If the server receives a request to set an ACE that it can store but cannot enforce, the server SHOULD reject the request with NFS4ERR_ATTRNOTSUPP.
客户端不应尝试设置ACE，除非服务器声明支持该ACE类型。如果服务器收到设置其无法存储的ACE的请求，则必须使用NFS4ERR_ATTRNOTSUPP拒绝该请求。如果服务器收到一个请求，要求设置一个它可以存储但无法执行的ACE，则服务器应使用NFS4ERR_ATTRNOTSUPP拒绝该请求。
The bitmask constants used for the access mask field are as follows:
用于访问掩码字段的位掩码常数如下所示：
const ACE4_READ_DATA = 0x00000001;
const ACE4_LIST_DIRECTORY = 0x00000001;
const ACE4_WRITE_DATA = 0x00000002;
const ACE4_ADD_FILE = 0x00000002;
const ACE4_APPEND_DATA = 0x00000004;
const ACE4_ADD_SUBDIRECTORY = 0x00000004;
const ACE4_READ_NAMED_ATTRS = 0x00000008;
const ACE4_WRITE_NAMED_ATTRS = 0x00000010;
const ACE4_EXECUTE = 0x00000020;
const ACE4_DELETE_CHILD = 0x00000040;
const ACE4_READ_ATTRIBUTES = 0x00000080;
const ACE4_WRITE_ATTRIBUTES = 0x00000100;
const ACE4_READ_DATA = 0x00000001;
const ACE4_LIST_DIRECTORY = 0x00000001;
const ACE4_WRITE_DATA = 0x00000002;
const ACE4_ADD_FILE = 0x00000002;
const ACE4_APPEND_DATA = 0x00000004;
const ACE4_ADD_SUBDIRECTORY = 0x00000004;
const ACE4_READ_NAMED_ATTRS = 0x00000008;
const ACE4_WRITE_NAMED_ATTRS = 0x00000010;
const ACE4_EXECUTE = 0x00000020;
const ACE4_DELETE_CHILD = 0x00000040;
const ACE4_READ_ATTRIBUTES = 0x00000080;
const ACE4_WRITE_ATTRIBUTES = 0x00000100;
const ACE4_DELETE = 0x00010000;
const ACE4_READ_ACL = 0x00020000;
const ACE4_WRITE_ACL = 0x00040000;
const ACE4_WRITE_OWNER = 0x00080000;
const ACE4_SYNCHRONIZE = 0x00100000;
const ACE4_DELETE = 0x00010000;
const ACE4_READ_ACL = 0x00020000;
const ACE4_WRITE_ACL = 0x00040000;
const ACE4_WRITE_OWNER = 0x00080000;
const ACE4_SYNCHRONIZE = 0x00100000;
Note that some masks have coincident values -- for example, ACE4_READ_DATA and ACE4_LIST_DIRECTORY. The mask entries ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY are intended to be used with directory objects, while ACE4_READ_DATA, ACE4_WRITE_DATA, and ACE4_APPEND_DATA are intended to be used with non-directory objects.
请注意，某些掩码具有重合的值——例如，ACE4_读取_数据和ACE4_列表_目录。掩码条目ACE4_LIST_DIRECTORY、ACE4_ADD_FILE和ACE4_ADD_子目录用于目录对象，而ACE4_READ_DATA、ACE4_WRITE_DATA和ACE4_APPEND_DATA用于非目录对象。
ACE4_READ_DATA
ACE4_读取_数据
Operation(s) affected:
受影响的行动：
READ
阅读
OPEN
打开
Discussion:
讨论：
Permission to read the data of the file.
读取文件数据的权限。
Servers SHOULD allow a user the ability to read the data of the file when only the ACE4_EXECUTE access mask bit is set.
服务器应允许用户在仅设置ACE4_EXECUTE访问掩码位时读取文件数据。
ACE4_LIST_DIRECTORY
ACE4\u列表\u目录
Operation(s) affected:
受影响的行动：
READDIR
READDIR
Discussion:
讨论：
Permission to list the contents of a directory.
列出目录内容的权限。
ACE4_WRITE_DATA
ACE4_写入_数据
Operation(s) affected:
受影响的行动：
WRITE
写
OPEN
打开
SETATTR of size
大小设置属性
Discussion:
讨论：
Permission to modify a file's data.
修改文件数据的权限。
ACE4_ADD_FILE
ACE4_添加_文件
Operation(s) affected:
受影响的行动：
CREATE
创造
LINK
链接
OPEN
打开
RENAME
改名
Discussion:
讨论：
Permission to add a new file in a directory. The CREATE operation is affected when nfs_ftype4 is NF4LNK, NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not listed because it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected when used to create a regular file. LINK and RENAME are always affected.
在目录中添加新文件的权限。当nfs_ftype4为NF4LNK、NF4BLK、NF4CHR、NF4SOCK或NF4FIFO时，创建操作会受到影响。（NF4DIR未列出，因为它包含在ACE4_ADD_子目录中。）OPEN在用于创建常规文件时会受到影响。链接和重命名总是受到影响。
ACE4_APPEND_DATA
ACE4_追加_数据
Operation(s) affected:
受影响的行动：
WRITE
写
OPEN
打开
SETATTR of size
大小设置属性
Discussion:
讨论：
The ability to modify a file's data, but only starting at EOF. This allows for the notion of append-only files, by allowing 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 and a WRITE request is made for somewhere other than EOF, the server SHOULD return NFS4ERR_ACCESS.
修改文件数据的能力，但仅从EOF开始。通过允许ACE4_追加_数据并拒绝ACE4_向同一用户或组写入_数据，这允许仅追加文件的概念。如果文件具有如上所述的ACL，并且对EOF以外的其他位置发出写入请求，则服务器应返回NFS4ERR_访问。
ACE4_ADD_SUBDIRECTORY
ACE4_添加_子目录
Operation(s) affected:
受影响的行动：
CREATE
创造
RENAME
改名
Discussion:
讨论：
Permission to create a subdirectory in a directory. The CREATE operation is affected when nfs_ftype4 is NF4DIR. The RENAME operation is always affected.
在目录中创建子目录的权限。当nfs_ftype4为NF4DIR时，创建操作会受到影响。重命名操作始终受到影响。
ACE4_READ_NAMED_ATTRS
ACE4\u读取\u命名\u属性
Operation(s) affected:
受影响的行动：
OPENATTR
OPENATTR
Discussion:
讨论：
Permission to read the named attributes of a file or to look up the named attributes directory. OPENATTR is affected when it is not used to create a named attribute directory. This is when 1) createdir is TRUE but a named attribute directory already exists or 2) createdir is FALSE.
读取文件的命名属性或查找命名属性目录的权限。OPENATTR不用于创建命名属性目录时会受到影响。这是指1）createdir为TRUE，但命名属性目录已存在，或2）createdir为FALSE。
ACE4_WRITE_NAMED_ATTRS
ACE4\u写入\u命名\u属性
Operation(s) affected:
受影响的行动：
OPENATTR
OPENATTR
Discussion:
讨论：
Permission to write the named attributes of a file or to create a named attribute directory. OPENATTR is affected when it is used to create a named attribute directory. This is when createdir is TRUE and no named attribute directory exists. The ability to check whether or not a named attribute directory exists depends on the ability to look it up; therefore, users also need the ACE4_READ_NAMED_ATTRS permission in order to create a named attribute directory.
写入文件的命名属性或创建命名属性目录的权限。OPENATTR用于创建命名属性目录时会受到影响。此时createdir为TRUE且不存在命名属性目录。检查命名属性目录是否存在的能力取决于查找它的能力；因此，用户还需要ACE4_READ_NAMED_ATTRS权限才能创建命名属性目录。
ACE4_EXECUTE
ACE4_执行
Operation(s) affected:
受影响的行动：
READ
阅读
Discussion:
讨论：
Permission to execute a file.
执行文件的权限。
Servers SHOULD allow a user the ability to read the data of the file when only the ACE4_EXECUTE access mask bit is set. This is because there is no way to execute a file without reading the contents. Though a server may treat ACE4_EXECUTE and ACE4_READ_DATA bits identically when deciding to permit a READ operation, it SHOULD still allow the two bits to be set independently in ACLs and MUST distinguish between them when replying to ACCESS operations. In particular, servers SHOULD 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 enforce the distinction between read and execute permissions.
服务器应允许用户在仅设置ACE4_EXECUTE访问掩码位时读取文件数据。这是因为在不读取内容的情况下无法执行文件。尽管在决定允许读取操作时，服务器可能会对ACE4_EXECUTE和ACE4_READ_数据位进行相同的处理，但仍应允许在ACL中独立设置这两个位，并且在答复访问操作时必须区分它们。特别是，当另一位被设置时，服务器不应该静默地打开这两位中的一位，因为这将使客户端无法正确执行读取和执行权限之间的区别。
As an example, following a SETATTR of the following ACL:
例如，在以下ACL的SETATTR之后：
nfsuser:ACE4_EXECUTE:ALLOW
nfsuser:ACE4_执行：允许
A subsequent GETATTR of ACL for that file SHOULD return:
该文件的ACL的后续GETATTR应返回：
nfsuser:ACE4_EXECUTE:ALLOW
nfsuser:ACE4_执行：允许
Rather than:
而不是：
nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW
nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW
ACE4_EXECUTE
ACE4_执行
Operation(s) affected:
受影响的行动：
LOOKUP
查找
OPEN
打开
REMOVE
去除
RENAME
改名
LINK
链接
CREATE
创造
Discussion:
讨论：
Permission to traverse/search a directory.
遍历/搜索目录的权限。
ACE4_DELETE_CHILD
ACE4_删除_子项
Operation(s) affected:
受影响的行动：
REMOVE
去除
RENAME
改名
Discussion:
讨论：
Permission to delete a file or directory within a directory. See Section 6.2.1.3.2 for information on how ACE4_DELETE and ACE4_DELETE_CHILD interact.
删除目录中的文件或目录的权限。有关ACE4_DELETE和ACE4_DELETE_CHILD如何交互的信息，请参见第6.2.1.3.2节。
ACE4_READ_ATTRIBUTES
ACE4_读取_属性
Operation(s) affected:
受影响的行动：
GETATTR of file system object attributes
文件系统对象属性的GETATTR
VERIFY
验证
NVERIFY
恩弗里
READDIR
READDIR
Discussion:
讨论：
The ability to read basic attributes (non-ACLs) of a file. On a UNIX system, basic attributes can be thought of as the stat-level attributes. Allowing this access mask bit would mean the entity can execute "ls -l" and stat. If a READDIR operation requests attributes, this mask must be allowed for the READDIR to succeed.
能够读取文件的基本属性（非ACL）。在UNIX系统上，基本属性可以看作是stat级别的属性。允许此访问掩码位意味着实体可以执行“ls-l”和stat。如果READDIR操作请求属性，则必须允许此掩码，READDIR才能成功。
ACE4_WRITE_ATTRIBUTES
ACE4_写入_属性
Operation(s) affected:
受影响的行动：
SETATTR of time_access_set, time_backup, time_create, time_modify_set, mimetype, hidden, and system
设置时间访问集、时间备份、时间创建、时间修改集、mimetype、隐藏和系统的属性
Discussion:
讨论：
Permission to change the times associated with a file or directory to an arbitrary value. Also, permission to change the mimetype, hidden and system attributes. A user having ACE4_WRITE_DATA or ACE4_WRITE_ATTRIBUTES will be allowed to set the times associated with a file to the current server time.
将与文件或目录关联的时间更改为任意值的权限。此外，还有更改mimetype、hidden和system属性的权限。允许具有ACE4_WRITE_数据或ACE4_WRITE_属性的用户将与文件关联的时间设置为当前服务器时间。
ACE4_DELETE
ACE4_删除
Operation(s) affected:
受影响的行动：
REMOVE
去除
Discussion:
讨论：
Permission to delete the file or directory. See Section 6.2.1.3.2 for information on ACE4_DELETE and ACE4_DELETE_CHILD interact.
删除文件或目录的权限。有关ACE4_DELETE和ACE4_DELETE_子交互的信息，请参见第6.2.1.3.2节。
ACE4_READ_ACL
ACE4\u读取\u ACL
Operation(s) affected:
受影响的行动：
GETATTR of acl
acl的GETATTR
NVERIFY
恩弗里
VERIFY
验证
Discussion:
讨论：
Permission to read the ACL.
读取ACL的权限。
ACE4_WRITE_ACL
ACE4_WRITE_ACL
Operation(s) affected:
受影响的行动：
SETATTR of acl and mode
acl和模式的SETATTR
Discussion:
讨论：
Permission to write the acl and mode attributes.
写入acl和模式属性的权限。
ACE4_WRITE_OWNER
ACE4_写入_所有者
Operation(s) affected:
受影响的行动：
SETATTR of owner and owner_group
所有者和所有者组的设置属性
Discussion:
讨论：
Permission to write the owner and owner_group attributes. On UNIX systems, this is the ability to execute chown() and chgrp().
写入所有者和所有者组属性的权限。在UNIX系统上，这是执行chown（）和chgrp（）的能力。
ACE4_SYNCHRONIZE
ACE4_同步
Operation(s) affected:
受影响的行动：
NONE
没有一个
Discussion:
讨论：
Permission to use the file object as a synchronization primitive for interprocess communication. This permission is not enforced or interpreted by the NFSv4.0 server on behalf of the client.
将文件对象用作进程间通信的同步原语的权限。NFSv4.0服务器不会代表客户端强制或解释此权限。
Typically, the ACE4_SYNCHRONIZE permission is only meaningful on local file systems, i.e., file systems not accessed via NFSv4.0. The reason that the permission bit exists is that some operating environments, such as Windows, use ACE4_SYNCHRONIZE.
通常，ACE4_SYNCHRONIZE权限仅在本地文件系统上有意义，即未通过NFSv4.0访问的文件系统。权限位存在的原因是某些操作环境（如Windows）使用ACE4\u同步。
For example, if a client copies a file that has ACE4_SYNCHRONIZE set from a local file system to an NFSv4.0 server, and then later copies the file from the NFSv4.0 server to a local file system, it is likely that if ACE4_SYNCHRONIZE was set in the original file, the client will want it set in the second copy. The first copy will not have the permission set unless the NFSv4.0 server has the means to set the ACE4_SYNCHRONIZE bit. The second copy will not have the permission set unless the NFSv4.0 server has the means to retrieve the ACE4_SYNCHRONIZE bit.
例如，如果客户端将设置了ACE4_SYNCHRONIZE的文件从本地文件系统复制到NFSv4.0服务器，然后将该文件从NFSv4.0服务器复制到本地文件系统，则如果在原始文件中设置了ACE4_SYNCHRONIZE，则客户端可能希望在第二个副本中设置该文件。除非NFSv4.0服务器具有设置ACE4_同步位的方法，否则第一个副本将不会设置权限。除非NFSv4.0服务器具有检索ACE4_同步位的方法，否则第二个副本将不具有权限集。
Server implementations need not provide the granularity of control that is implied by this list of masks. For example, POSIX-based systems might not distinguish ACE4_APPEND_DATA (the ability to append to a file) from ACE4_WRITE_DATA (the ability to modify existing contents); both masks would be tied to a single "write" permission. When such a server returns attributes to the client, it would show both ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the write permission is enabled.
服务器实现不需要提供此掩码列表所暗示的控制粒度。例如，基于POSIX的系统可能无法区分ACE4_追加_数据（追加到文件的能力）和ACE4_写入_数据（修改现有内容的能力）；两个掩码都将绑定到一个“写入”权限。当这样的服务器将属性返回给客户机时，它将显示ACE4_APPEND_数据和ACE4_WRITE_数据，前提是且仅当启用了写入权限。
If a server receives a SETATTR request that it cannot accurately implement, it should err in the direction of more restricted access, except in the previously discussed cases of execute and read. For example, suppose a server cannot distinguish overwriting data from appending new data, as described in the previous paragraph. If a client submits an ALLOW ACE where ACE4_APPEND_DATA is set but ACE4_WRITE_DATA is not (or vice versa), the server should either turn off ACE4_APPEND_DATA or reject the request with NFS4ERR_ATTRNOTSUPP.
如果服务器接收到无法准确实现的SETATTR请求，那么它应该在更受限的访问方向上出错，前面讨论的execute和read情况除外。例如，假设服务器无法区分覆盖数据和追加新数据，如前一段所述。如果客户端提交了一个允许ACE，其中设置了ACE4_APPEND_数据，但未设置ACE4_WRITE_数据（反之亦然），则服务器应关闭ACE4_APPEND_数据或使用NFS4ERR_ATTRNOTSUPP拒绝请求。
Two access mask bits govern the ability to delete a directory entry: ACE4_DELETE on the object itself (the "target") and ACE4_DELETE_CHILD on the containing directory (the "parent").
两个访问掩码位控制删除目录项的能力：对象本身（“目标”）上的ACE4_delete和包含目录（“父目录”）上的ACE4_delete_CHILD。
Many systems also take the "sticky bit" (MODE4_SVTX) on a directory to allow unlink only to a user that owns either the target or the parent; on some such systems, the decision also depends on whether the target is writable.
许多系统还采用目录上的“粘性位”（MODE4_SVTX），只允许与拥有目标或父目录的用户解除链接；在某些这样的系统上，决策还取决于目标是否可写。
Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the target or ACE4_DELETE_CHILD is permitted on the parent. (Note that this is true even if the parent or target explicitly denies the other of these permissions.)
如果目标服务器上允许ACE4_删除，或者父服务器上允许ACE4_删除子服务器，则服务器应允许取消链接。（请注意，即使父级或目标明确拒绝这些权限中的另一个，这也是正确的。）
If the ACLs in question neither explicitly ALLOW nor DENY either of the above, and if MODE4_SVTX is not set on the parent, then the server SHOULD allow the removal if and only if ACE4_ADD_FILE is permitted. In the case where MODE4_SVTX is set, the server may also require the remover to own either the parent or the target, or may require the target to be writable.
如果所讨论的ACL既不明确允许也不拒绝上述任何一项，并且如果父级上未设置MODE4_SVTX，则只有在允许ACE4_ADD_文件的情况下，服务器才应允许删除。在设置MODE4_SVTX的情况下，服务器还可能要求删除程序拥有父级或目标，或者可能要求目标可写。
This allows servers to support something close to traditional UNIX-like semantics, with ACE4_ADD_FILE taking the place of the write bit.
这允许服务器支持类似于传统UNIX的语义，用ACE4_ADD_文件代替写位。
The bitmask constants used for the flag field are as follows:
用于标志字段的位掩码常数如下所示：
const ACE4_FILE_INHERIT_ACE = 0x00000001;
const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002;
const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004;
const ACE4_INHERIT_ONLY_ACE = 0x00000008;
const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010;
const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020;
const ACE4_IDENTIFIER_GROUP = 0x00000040;
const ACE4_FILE_INHERIT_ACE = 0x00000001;
const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002;
const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004;
const ACE4_INHERIT_ONLY_ACE = 0x00000008;
const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010;
const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020;
const ACE4_IDENTIFIER_GROUP = 0x00000040;
A server need not support any of these flags. If the server supports flags that are similar to, but not exactly the same as, these flags, the implementation may define a mapping between the protocol-defined flags and the implementation-defined flags.
服务器不需要支持这些标志中的任何一个。如果服务器支持与这些标志相似但不完全相同的标志，则实现可以定义协议定义标志和实现定义标志之间的映射。
For example, suppose a client tries to set an ACE with ACE4_FILE_INHERIT_ACE set but not ACE4_DIRECTORY_INHERIT_ACE. If the server does not support any form of ACL inheritance, the server should reject the request with NFS4ERR_ATTRNOTSUPP. If the server
例如，假设客户机尝试使用ACE4\u文件\u继承\u ACE集设置ACE，但不使用ACE4\u目录\u继承\u ACE。如果服务器不支持任何形式的ACL继承，则服务器应使用NFS4ERR_ATTRNOTSUPP拒绝请求。如果服务器
supports a single "inherit ACE" flag that applies to both files and directories, the server may reject the request (i.e., requiring the client to set both the file and directory inheritance flags). The server may also accept the request and silently turn on the ACE4_DIRECTORY_INHERIT_ACE flag.
支持应用于文件和目录的单个“继承ACE”标志，服务器可能会拒绝请求（即，要求客户端同时设置文件和目录继承标志）。服务器也可以接受请求并静默地打开ACE4\u目录\u继承\u ACE标志。
ACE4_FILE_INHERIT_ACE Any non-directory file in any subdirectory will get this ACE inherited.
ACE4\u文件\u继承\u ACE任何子目录中的任何非目录文件都将继承此ACE。
ACE4_DIRECTORY_INHERIT_ACE Can be placed on a directory and indicates that this ACE should be added to each new directory created. If this flag is set in an ACE in an ACL attribute to be set on a non-directory file system object, the operation attempting to set the ACL SHOULD fail with NFS4ERR_ATTRNOTSUPP.
ACE4_DIRECTORY_INHERIT_ACE可放置在目录上，并指示应将此ACE添加到创建的每个新目录中。如果在要在非目录文件系统对象上设置的ACL属性的ACE中设置了此标志，则尝试设置ACL的操作将失败，并出现NFS4ERR_ATTRNOTSUPP。
ACE4_INHERIT_ONLY_ACE Can be placed on a directory but does not apply to the directory; ALLOW and DENY ACEs with this bit set do not affect access to the directory, and AUDIT and ALARM ACEs with this bit set do not trigger log or alarm events. Such ACEs only take effect once they are applied (with this bit cleared) to newly created files and directories as specified by the above two flags. If this flag is present on an ACE, but neither ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present, then an operation attempting to set such an attribute SHOULD fail with NFS4ERR_ATTRNOTSUPP.
ACE4_INHERIT_ONLY_ACE可放置在目录上，但不适用于该目录；具有此位集的允许和拒绝ACE不会影响对目录的访问，并且具有此位集的审核和报警ACE不会触发日志或报警事件。此类ACE仅在应用于（清除此位）上述两个标志指定的新创建的文件和目录后生效。如果ACE上存在此标志，但既不存在ACE4_目录_继承_ACE，也不存在ACE4_文件_继承_ACE，则尝试设置此类属性的操作应失败，并出现NFS4ERR_ATTRNOTSUPP。
ACE4_NO_PROPAGATE_INHERIT_ACE Can be placed on a directory. This flag tells the server that inheritance of this ACE should stop at newly created child directories.
ACE4\u NO\u PROPAGATE\u INHERIT\u ACE可以放置在目录中。此标志告诉服务器，此ACE的继承应在新创建的子目录处停止。
ACE4_SUCCESSFUL_ACCESS_ACE_FLAG
ACE4\u成功访问\u ACE\u标志
ACE4_FAILED_ACCESS_ACE_FLAG The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE (ALARM) ACE types. If, during the processing of the file's ACL, the server encounters an AUDIT or ALARM ACE that matches the principal attempting the OPEN, the server notes that fact and notes the presence, if any, of the SUCCESS and FAILED flags encountered in the AUDIT or ALARM ACE. Once the server completes the ACL processing, it then notes if the operation succeeded or
ACE4_失败访问_ACE_标志ACE4_成功访问_ACE_标志（成功）和ACE4_失败访问_ACE_标志（失败）位只能在ACE4_系统审计_ACE_类型（审计）和ACE4_系统报警_ACE类型（报警）ACE类型上设置。如果在处理文件的ACL期间，服务器遇到与尝试打开的主体匹配的审核或报警ACE，则服务器会记录该事实，并记录审核或报警ACE中遇到的成功和失败标志（如果有）。一旦服务器完成ACL处理，它就会记录操作是否成功
failed. If the operation succeeded, and if the SUCCESS flag was set for a matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM event occurs. If the operation failed, and if the FAILED flag was set for the matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM event occurs. Either or both of the SUCCESS or FAILED can be set, but if neither is set, the AUDIT or ALARM ACE is not useful.
失败。如果操作成功，并且为匹配的审核或报警ACE设置了成功标志，则会发生相应的审核或报警事件。如果操作失败，并且如果为匹配的审核或报警ACE设置了失败标志，则会发生相应的审核或报警事件。可以设置成功或失败中的一个或两个，但如果两个都未设置，则审核或报警ACE将无效。
The previously described processing applies to ACCESS operations even when they return NFS4_OK. For the purposes of AUDIT and ALARM, we consider an ACCESS operation to be a "failure" if it fails to return a bit that was requested and supported.
前面描述的处理适用于访问操作，即使它们返回NFS4_OK。出于审计和警报的目的，我们认为如果不能返回请求和支持的位，则访问操作将是“失败”。
ACE4_IDENTIFIER_GROUP Indicates that the "who" refers to a GROUP as defined under UNIX or a GROUP ACCOUNT as defined under Windows. Clients and servers MUST ignore the ACE4_IDENTIFIER_GROUP flag on ACEs with a who value equal to one of the special identifiers outlined in Section 6.2.1.5.
ACE4_IDENTIFIER_GROUP表示“谁”是指UNIX下定义的组或Windows下定义的组帐户。客户机和服务器必须忽略ACEs上的ACE4_标识符_组标志，其who值等于第6.2.1.5节中概述的特殊标识符之一。
The who field of an ACE is an identifier that specifies the principal or principals to whom the ACE applies. It may refer to a user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying which.
ACE的who字段是一个标识符，用于指定ACE应用到的一个或多个主体。它可能指的是用户或组，标志位ACE4_IDENTIFIER_group指定用户或组。
There are several special identifiers that need to be understood universally, rather than in the context of a particular DNS domain. Some of these identifiers cannot be understood when an NFS client accesses the server but have meaning when a local process accesses the file. The ability to display and modify these permissions is permitted over NFS, even if none of the access methods on the server understand the identifiers.
有几个特殊标识符需要普遍理解，而不是在特定DNS域的上下文中。其中一些标识符在NFS客户端访问服务器时无法理解，但在本地进程访问文件时具有意义。允许通过NFS显示和修改这些权限，即使服务器上的任何访问方法都不理解标识符。
+---------------+---------------------------------------------------+
| Who | Description |
+---------------+---------------------------------------------------+
| OWNER | The owner of the file. |
| GROUP | The group associated with the file. |
| EVERYONE | The world, including the owner and owning group. |
| INTERACTIVE | Accessed from an interactive terminal. |
| NETWORK | Accessed via the network. |
| 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. |
+---------------+---------------------------------------------------+
+---------------+---------------------------------------------------+
| Who | Description |
+---------------+---------------------------------------------------+
| OWNER | The owner of the file. |
| GROUP | The group associated with the file. |
| EVERYONE | The world, including the owner and owning group. |
| INTERACTIVE | Accessed from an interactive terminal. |
| NETWORK | Accessed via the network. |
| 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 5: Special Identifiers
表5：特殊标识符
To avoid conflict, these special identifiers are distinguished by an appended "@" and should appear in the form "xxxx@" (with no domain name after the "@") -- for example, ANONYMOUS@.
为了避免冲突，这些特殊标识符通过附加的“@”加以区分，并应以“xxxx@”的形式出现（在“@”之后没有域名），例如，ANONYMOUS@.
The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these special identifiers. When encoding entries with these special identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero.
对于具有这些特殊标识符的条目，必须忽略ACE4_标识符_组标志。使用这些特殊标识符对条目进行编码时，ACE4_IDENTIFIER_GROUP标志应设置为零。
It is important to note that "EVERYONE@" is not equivalent to the UNIX "other" entity. This is because, by definition, UNIX "other" does not include the owner or owning group of a file. "EVERYONE@" means literally everyone, including the owner or owning group.
需要注意的是，“EVERYONE@”并不等同于UNIX“other”实体。这是因为，根据定义，UNIX“其他”不包括文件的所有者或所有者组。“EVERYONE@”字面上是指所有人，包括所有者或所有者团体。
The NFSv4.0 mode attribute is based on the UNIX mode bits. The following bits are defined:
NFSv4.0模式属性基于UNIX模式位。定义了以下位：
const MODE4_SUID = 0x800; /* set user id on execution */
const MODE4_SGID = 0x400; /* set group id on execution */
const MODE4_SVTX = 0x200; /* save text even after use */
const MODE4_RUSR = 0x100; /* read permission: owner */
const MODE4_WUSR = 0x080; /* write permission: owner */
const MODE4_XUSR = 0x040; /* execute permission: owner */
const MODE4_RGRP = 0x020; /* read permission: group */
const MODE4_WGRP = 0x010; /* write permission: group */
const MODE4_XGRP = 0x008; /* execute permission: group */
const MODE4_SUID = 0x800; /* set user id on execution */
const MODE4_SGID = 0x400; /* set group id on execution */
const MODE4_SVTX = 0x200; /* save text even after use */
const MODE4_RUSR = 0x100; /* read permission: owner */
const MODE4_WUSR = 0x080; /* write permission: owner */
const MODE4_XUSR = 0x040; /* execute permission: owner */
const MODE4_RGRP = 0x020; /* read permission: group */
const MODE4_WGRP = 0x010; /* write permission: group */
const MODE4_XGRP = 0x008; /* execute permission: group */
const MODE4_ROTH = 0x004; /* read permission: other */
const MODE4_WOTH = 0x002; /* write permission: other */
const MODE4_XOTH = 0x001; /* execute permission: other */
const MODE4_ROTH = 0x004; /* read permission: other */
const MODE4_WOTH = 0x002; /* write permission: other */
const MODE4_XOTH = 0x001; /* execute permission: other */
Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal identified in the owner attribute. Bits MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP apply to principals identified in the owner_group attribute but who are not identified in the owner attribute. Bits MODE4_ROTH, MODE4_WOTH, and MODE4_XOTH apply to any principal that does not match that in the owner attribute and does not have a group matching that of the owner_group attribute.
位MODE4_RUSR、MODE4_WUSR和MODE4_XUSR应用于所有者属性中标识的主体。位MODE4_RGRP、MODE4_WGRP和MODE4_XGRP适用于在owner_group属性中标识但在owner属性中未标识的主体。位MODE4_ROTH、MODE4_WOTH和MODE4_XOTH适用于与owner属性中的主体不匹配且组与owner_group属性中的主体不匹配的任何主体。
Bits within the mode other than those specified above are not defined by this protocol. A server MUST NOT return bits other than those defined above in a GETATTR or READDIR operation, and it MUST return NFS4ERR_INVAL if bits other than those defined above are set in a SETATTR, CREATE, OPEN, VERIFY, or NVERIFY operation.
本协议未定义除上述规定之外的模式内的位。服务器不能返回除上面在GETATTR或READDIR操作中定义的位以外的位，如果在SETATTR、CREATE、OPEN、VERIFY或NVERIFY操作中设置了除上面定义的位以外的位，则必须返回NFS4ERR_INVAL。
The requirements in this section will be referred to in future sections, especially Section 6.4.
本节中的要求将在以后的章节中提及，特别是第6.4节。
The server uses the algorithm described in Section 6.2.1 to determine whether an ACL allows access to an object. However, the ACL may not be the sole determiner of access. For example:
服务器使用第6.2.1节中描述的算法来确定ACL是否允许访问对象。但是，ACL可能不是访问的唯一决定因素。例如：
o In the case of a file system exported as read-only, the server may deny write permissions even though an object's ACL grants it.
o 对于以只读方式导出的文件系统，即使对象的ACL授予写入权限，服务器也可能会拒绝该权限。
o Server implementations MAY grant ACE4_WRITE_ACL and ACE4_READ_ACL permissions to prevent a situation from arising in which there is no valid way to ever modify the ACL.
o 服务器实现可能会授予ACE4_WRITE_ACL和ACE4_READ_ACL权限，以防止出现无法有效修改ACL的情况。
o 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 denies the user ACE4_READ_DATA access and allows the user ACE4_EXECUTE, the server will allow the user to read the data of the file).
o 当仅授予执行权限时，所有服务器将允许用户读取文件数据（即，如果ACL拒绝用户ACE4_读取_数据访问并允许用户ACE4_执行，则服务器将允许用户读取文件数据）。
o Many servers have the notion of owner-override, in which the owner of the object is allowed to override accesses that are denied by the ACL. This may be helpful, for example, to allow users continued access to open files on which the permissions have changed.
o 许多服务器都有所有者覆盖的概念，其中允许对象的所有者覆盖ACL拒绝的访问。例如，这可能有助于允许用户继续访问权限已更改的打开文件。
o Many servers have the notion of a "superuser" that has privileges 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 ACL.
o 许多服务器都有“超级用户”的概念，拥有普通用户以外的特权。超级用户可能能够以ACL不允许的方式读取或写入数据或元数据。
Clients SHOULD NOT do their own access checks based on their interpretation of the ACL but rather use the OPEN and ACCESS operations to do access checks. This allows the client to act on the results of having the server determine whether or not access should be granted based on its interpretation of the ACL.
客户端不应该基于对ACL的解释来执行自己的访问检查，而应该使用OPEN和access操作来执行访问检查。这允许客户端根据服务器根据其对ACL的解释确定是否应授予访问权限的结果进行操作。
Clients must be aware of situations in which an object's ACL will define a certain access even though the server will not have adequate information to enforce it. For example, the server has no way of determining whether a particular OPEN reflects a user's open for read access or is done as part of executing the file in question. In such situations, the client needs to do its part in the enforcement of access as defined by the ACL. To do this, the client will send the appropriate ACCESS operation (or use a cached previous determination) prior to servicing the request of the user or application in order to determine whether the user or application should be granted the access requested. For examples in which the ACL may define accesses that the server does not enforce, see Section 6.3.1.1.
客户端必须知道对象的ACL将定义特定访问权限的情况，即使服务器没有足够的信息来强制执行该访问权限。例如，服务器无法确定特定的打开是否反映了用户对读取访问的打开，或者是否作为执行相关文件的一部分完成。在这种情况下，客户机需要按照ACL的定义执行访问。为此，客户端将在为用户或应用程序的请求提供服务之前发送适当的访问操作（或使用缓存的先前确定），以确定是否应向用户或应用程序授予请求的访问权限。有关ACL可能定义服务器不强制执行的访问的示例，请参见第6.3.1.1节。
The following method can be used to calculate the MODE4_R*, MODE4_W*, and MODE4_X* bits of a mode attribute, based upon an ACL.
以下方法可用于基于ACL计算模式属性的MODE4_R*、MODE4_W*和MODE4_X*位。
First, for each of the special identifiers OWNER@, GROUP@, and EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY ACEs for the identifier EVERYONE@ and for the identifier under consideration. The result of the evaluation will be an NFSv4 ACL mask showing exactly which bits are permitted to that identifier.
首先，对于每个特殊标识符OWNER@、GROUP@和EVERYONE@，依次评估ACL，考虑仅允许和拒绝标识符EVERYONE@和正在考虑的标识符的ACE。评估的结果将是一个NFSv4 ACL掩码，精确显示允许该标识符使用的位。
Then translate the calculated mask for OWNER@, GROUP@, and EVERYONE@ into mode bits for the user, group, and other, respectively, as follows:
然后将计算出的OWNER@、GROUP@和everybody@掩码分别转换为user、GROUP和other的模式位，如下所示：
1. Set the read bit (MODE4_RUSR, MODE4_RGRP, or MODE4_ROTH) if and only if ACE4_READ_DATA is set in the corresponding mask.
1. 当且仅当在相应掩码中设置了ACE4_读取数据时，设置读取位（MODE4_RUSR、MODE4_RGRP或MODE4_ROTH）。
2. Set the write bit (MODE4_WUSR, MODE4_WGRP, or MODE4_WOTH) if and only if ACE4_WRITE_DATA and ACE4_APPEND_DATA are both set in the corresponding mask.
2. 设置写入位（MODE4_WUSR、MODE4_WGRP或MODE4_WOTH），前提是且仅当ACE4_写入_数据和ACE4_附加_数据均在相应掩码中设置。
3. Set the execute bit (MODE4_XUSR, MODE4_XGRP, or MODE4_XOTH), if and only if ACE4_EXECUTE is set in the corresponding mask.
3. 设置执行位（MODE4_XUSR、MODE4_XGRP或MODE4_XOTH），前提是且仅当相应掩码中设置了ACE4_execute。
Some server implementations also add bits permitted to named users and groups to the group bits (MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP).
一些服务器实现还将允许命名用户和组的位添加到组位（MODE4_RGRP、MODE4_WGRP和MODE4_XGRP）。
Implementations are discouraged from doing this, because it has been found to cause confusion for users who see members of a file's group denied access that the mode bits appear to allow. (The presence of DENY ACEs may also lead to such behavior, but DENY ACEs are expected to be more rarely used.)
不鼓励实现这样做，因为已经发现，如果用户看到模式位似乎允许的文件组成员被拒绝访问，则会导致混淆。（拒绝ACE的存在也可能导致此类行为，但拒绝ACE预计将很少使用。）
The same user confusion seen when fetching the mode also results if setting the mode does not effectively control permissions for the owner, group, and other users; this motivates some of the requirements that follow.
如果设置模式不能有效控制所有者、组和其他用户的权限，则在获取模式时也会出现相同的用户混淆；这激发了接下来的一些需求。
The server that supports both mode and ACL must take care to synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the ACEs that have respective who fields of "OWNER@", "GROUP@", and "EVERYONE@" so that the client can see that semantically equivalent access permissions exist whether the client asks for just the ACL or any of the owner, owner_group, and mode attributes.
同时支持mode和ACL的服务器必须注意将MODE4_*USR、MODE4_*GRP和MODE4_*OTH位与ACE同步，ACE具有各自的who字段“OWNER@”、“GROUP@”和“EVERYONE@”，以便客户端可以看到，无论客户端只请求ACL还是请求任何所有者，都存在语义等效的访问权限，所有者组和模式属性。
Many requirements refer to Section 6.3.2, but note that the methods have behaviors specified with "SHOULD". This is intentional, to avoid invalidating existing implementations that compute the mode according to the withdrawn POSIX ACL draft ([P1003.1e]), rather than by actual permissions on owner, group, and other.
许多要求参考第6.3.2节，但请注意，这些方法具有“应”指定的行为。这是有意的，以避免使根据撤销的POSIX ACL草案（[P1003.1e]）而不是所有者、组和其他用户的实际权限计算模式的现有实现无效。
When any of the nine low-order mode bits are changed because the mode attribute was set, and no ACL attribute is explicitly set, the acl attribute must be modified in accordance with the updated value of those bits. This must happen even if the value of the low-order bits is the same after the mode is set as before.
如果由于设置了模式属性而更改了九个低阶模式位中的任何一个，并且没有显式设置ACL属性，则必须根据这些位的更新值修改ACL属性。即使低阶位的值在模式设置后与之前相同，也必须发生这种情况。
Note that any AUDIT or ALARM ACEs are unaffected by changes to the mode.
请注意，任何审核或报警ACE均不受模式更改的影响。
In cases in which the permissions bits are subject to change, the acl attribute MUST be modified such that the mode computed via the method described in Section 6.3.2 yields the low-order nine bits (MODE4_R*, MODE4_W*, MODE4_X*) of the mode attribute as modified by the change attribute. The ACL attributes SHOULD also be modified such that:
在权限位可能发生更改的情况下，必须修改acl属性，以便通过第6.3.2节中描述的方法计算的模式产生由更改属性修改的模式属性的低阶九位（MODE4_R*、MODE4_W*、MODE4_X*）。还应修改ACL属性，以便：
1. If MODE4_RGRP is not set, entities explicitly listed in the ACL other than OWNER@ and EVERYONE@ SHOULD NOT be granted ACE4_READ_DATA.
1. 如果未设置MODE4_RGRP，则ACL中明确列出的除OWNER@和EVERYONE@之外的实体不应被授予ACE4_读取_数据。
2. If MODE4_WGRP is not set, entities explicitly listed in the ACL other than OWNER@ and EVERYONE@ SHOULD NOT be granted ACE4_WRITE_DATA or ACE4_APPEND_DATA.
2. 如果未设置MODE4_WGRP，则在ACL中明确列出的除OWNER@和EVERYONE@以外的实体不应被授予ACE4_WRITE_数据或ACE4_APPEND_数据。
3. If MODE4_XGRP is not set, entities explicitly listed in the ACL other than OWNER@ and EVERYONE@ SHOULD NOT be granted ACE4_EXECUTE.
3. 如果未设置MODE4_XGRP，则不应授予ACL中明确列出的除OWNER@和EVERYONE@以外的实体ACE4_EXECUTE。
Access mask bits other than those listed above, appearing in ALLOW ACEs, MAY also be disabled.
除了上面列出的访问掩码位之外，出现在允许ACEs中的访问掩码位也可能被禁用。
Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect the permissions of the ACL itself, nor do ACEs of the types AUDIT and ALARM. As such, it is desirable to leave these ACEs unmodified when modifying the ACL attributes.
请注意，带有标志ACE4_INHERIT_ONLY_ACE set的ACE不会影响ACL本身的权限，也不会影响AUDIT和ALARM类型的ACE。因此，在修改ACL属性时，最好不要修改这些ACE。
Also note that the requirement may be met by discarding the acl in favor of an ACL that represents the mode and only the mode. This is permitted, but it is preferable for a server to preserve as much of the ACL as possible without violating the above requirements. Discarding the ACL makes it effectively impossible for a file created with a mode attribute to inherit an ACL (see Section 6.4.3).
还请注意，可以通过放弃acl而使用表示模式且仅表示模式的acl来满足该要求。这是允许的，但服务器最好在不违反上述要求的情况下保留尽可能多的ACL。丢弃ACL实际上使使用mode属性创建的文件无法继承ACL（请参阅第6.4.3节）。
When setting the acl and not setting the mode attribute, the permission bits of the mode need to be derived from the ACL. In this case, the ACL attribute SHOULD be set as given. The nine low-order bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) MUST be modified to match the result of the method described in Section 6.3.2. The three high-order bits of the mode (MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged.
设置acl而不设置mode属性时，需要从acl派生模式的权限位。在这种情况下，ACL属性应按给定值设置。必须修改模式属性的九个低阶位（MODE4_R*、MODE4_W*、MODE4_X*），以匹配第6.3.2节所述方法的结果。模式的三个高阶位（MODE4_SUID、MODE4_SGID、MODE4_SVTX）应保持不变。
When setting both the mode and the acl attribute in the same operation, the attributes MUST be applied in this order: mode, then ACL. The mode-related attribute is set as given, then the ACL attribute is set as given, possibly changing the final mode, as described above in Section 6.4.1.2.
在同一操作中设置模式和acl属性时，必须按以下顺序应用属性：模式，然后是acl。模式相关属性设置为给定，然后ACL属性设置为给定，可能会更改最终模式，如上文第6.4.1.2节所述。
This section applies only to servers that support both the mode and ACL attributes.
本节仅适用于同时支持模式和ACL属性的服务器。
Some server implementations may have a concept of "objects without ACLs", meaning that all permissions are granted and denied according to the mode attribute, and that no ACL attribute is stored for that object. If an ACL attribute is requested of such a server, the server SHOULD return an ACL that does not conflict with the mode; that is to say, the ACL returned SHOULD represent the nine low-order bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) as described in Section 6.3.2.
一些服务器实现可能有“没有ACL的对象”的概念，这意味着根据mode属性授予和拒绝所有权限，并且没有为该对象存储ACL属性。如果请求此类服务器的ACL属性，则服务器应返回与模式不冲突的ACL；也就是说，返回的ACL应表示第6.3.2节中描述的模式属性（MODE4_R*、MODE4_W*、MODE4_X*）的九个低阶位。
For other server implementations, the ACL attribute is always present for every object. Such servers SHOULD store at least the three high-order bits of the mode attribute (MODE4_SUID, MODE4_SGID, MODE4_SVTX). The server SHOULD return a mode attribute if one is requested, and the low-order nine bits of the mode (MODE4_R*, MODE4_W*, MODE4_X*) MUST match the result of applying the method in Section 6.3.2 to the ACL attribute.
对于其他服务器实现，ACL属性始终存在于每个对象中。此类服务器应至少存储模式属性的三个高阶位（MODE4_SUID、MODE4_SGID、MODE4_SVTX）。如果请求模式属性，服务器应返回一个模式属性，模式的低阶九位（MODE4_R*、MODE4_W*、MODE4_X*）必须与将第6.3.2节中的方法应用于ACL属性的结果相匹配。
If a server supports any ACL attributes, it may use the ACL attributes on the parent directory to compute an initial ACL attribute for a newly created object. This will be referred to as the inherited ACL within this section. The act of adding one or more
如果服务器支持任何ACL属性，它可以使用父目录上的ACL属性来计算新创建对象的初始ACL属性。这将在本节中称为继承的ACL。添加一个或多个的行为
ACEs to the inherited ACL that are based upon ACEs in the parent directory's ACL will be referred to as inheriting an ACE within this section.
基于父目录ACL中ACE的继承ACL的ACE在本节中称为继承ACE。
In the presence or absence of the mode and ACL attributes, the behavior of CREATE and OPEN SHOULD be:
在存在或不存在模式和ACL属性的情况下，CREATE和OPEN的行为应为：
1. If just the mode is given in the call:
1. 如果通话中仅给出了模式：
In this case, inheritance SHOULD take place, but the mode MUST be applied to the inherited ACL as described in Section 6.4.1.1, thereby modifying the ACL.
在这种情况下，应该进行继承，但必须按照第6.4.1.1节所述将该模式应用于继承的ACL，从而修改ACL。
2. If just the ACL is given in the call:
2. 如果调用中仅给出了ACL：
In this case, inheritance SHOULD NOT take place, and the ACL as defined in the CREATE or OPEN will be set without modification, and the mode modified as in Section 6.4.1.2.
在这种情况下，不应发生继承，并且在创建或打开中定义的ACL将在不进行修改的情况下进行设置，并且模式将按照第6.4.1.2节的规定进行修改。
3. If both mode and ACL are given in the call:
3. 如果调用中同时给出了mode和ACL：
In this case, inheritance SHOULD NOT take place, and both attributes will be set as described in Section 6.4.1.3.
在这种情况下，不应发生继承，两个属性都将按照第6.4.1.3节所述进行设置。
4. If neither mode nor ACL is given in the call:
4. 如果调用中未给出模式或ACL：
In the case where an object is being created without any initial attributes at all, e.g., an OPEN operation with an opentype4 of OPEN4_CREATE and a createmode4 of EXCLUSIVE4, inheritance SHOULD NOT take place. Instead, the server SHOULD set permissions to deny all access to the newly created object. It is expected that the appropriate client will set the desired attributes in a subsequent SETATTR operation, and the server SHOULD allow that operation to succeed, regardless of what permissions the object is created with. For example, an empty ACL denies all permissions, but the server should allow the owner's SETATTR to succeed even though WRITE_ACL is implicitly denied.
如果创建对象时根本没有任何初始属性，例如，opentype4为OPEN4_CREATE，createmode4为EXCLUSIVE4的开放操作，则不应发生继承。相反，服务器应该设置权限以拒绝对新创建的对象的所有访问。预期适当的客户端将在后续的SETATTR操作中设置所需的属性，并且服务器应允许该操作成功，而不管使用什么权限创建对象。例如，空ACL拒绝所有权限，但服务器应允许所有者的SETATTR成功，即使WRITE_ACL被隐式拒绝。
In other cases, inheritance SHOULD take place, and no modifications to the ACL will happen. The mode attribute, if supported, MUST be as computed via the method described in Section 6.3.2, with the MODE4_SUID, MODE4_SGID, and MODE4_SVTX bits clear. If no inheritable ACEs exist on the parent directory, the rules for creating acl attributes are implementation defined.
在其他情况下，应该进行继承，并且不会对ACL进行任何修改。如果支持模式属性，则必须通过第6.3.2节中描述的方法计算模式属性，并清除MODE4_SUID、MODE4_SGID和MODE4_SVTX位。如果父目录上不存在可继承的ACE，则创建acl属性的规则由实现定义。
If the object being created is not a directory, the inherited ACL SHOULD NOT inherit ACEs from the parent directory ACL unless the ACE4_FILE_INHERIT_FLAG is set.
如果要创建的对象不是目录，则继承的ACL不应从父目录ACL继承ACE，除非设置了ACE4_FILE_inherit_标志。
If the object being created is a directory, the inherited ACL should inherit all inheritable ACEs from the parent directory, i.e., those that have the ACE4_FILE_INHERIT_ACE or ACE4_DIRECTORY_INHERIT_ACE flag set. If the inheritable ACE has ACE4_FILE_INHERIT_ACE set, but ACE4_DIRECTORY_INHERIT_ACE is clear, the inherited ACE on the newly created directory MUST have the ACE4_INHERIT_ONLY_ACE flag set to prevent the directory from being affected by ACEs meant for non-directories.
如果要创建的对象是目录，则继承的ACL应继承父目录中的所有可继承ACE，即设置了ACE4\u文件\u继承\u ACE或ACE4\u目录\u继承\u ACE标志的ACE。如果可继承ACE设置了ACE4\u文件\u继承\u ACE，但ACE4\u目录\u继承\u ACE是清除的，则新创建目录上的继承ACE必须设置ACE4\u仅继承\u ACE标志，以防止目录受到非目录的ACE的影响。
When a new directory is created, the server MAY split any inherited ACE that is both inheritable and effective (in other words, that has neither ACE4_INHERIT_ONLY_ACE nor ACE4_NO_PROPAGATE_INHERIT_ACE set) into two ACEs -- one with no inheritance flags, and one with ACE4_INHERIT_ONLY_ACE set. This makes it simpler to modify the effective permissions on the directory without modifying the ACE that is to be inherited to the new directory's children.
创建新目录时，服务器可能会将任何既可继承又有效的继承ACE（换句话说，既没有ACE4_INHERIT_ONLY_ACE也没有ACE4_NO_PROPAGATE_INHERIT_ACE集）拆分为两个ACE—一个没有继承标志，另一个只有ACE4_INHERIT_ACE集。这使得修改目录上的有效权限变得更简单，而无需修改要继承到新目录子目录的ACE。
On a UNIX server, the namespace describes all the files reachable by pathnames under the root directory or "/". On a Windows server, the namespace constitutes all the files on disks named by mapped disk letters. NFS server administrators rarely make the entire server's file system namespace available to NFS clients. More often, portions of the namespace are made available via an "export" feature. In previous versions of the NFS protocol, the root filehandle for each export is obtained through the MOUNT protocol; the client sends a string that identifies an object in the exported namespace, and the server returns the root filehandle for it. The MOUNT protocol supports an EXPORTS procedure that will enumerate the server's exports.
在UNIX服务器上，命名空间描述根目录或“/”下的路径名可访问的所有文件。在Windows服务器上，名称空间由磁盘上以映射的磁盘字母命名的所有文件组成。NFS服务器管理员很少使整个服务器的文件系统命名空间可供NFS客户端使用。更常见的情况是，命名空间的某些部分通过“导出”功能提供。在以前版本的NFS协议中，每次导出的根文件句柄都是通过MOUNT协议获得的；客户端发送一个字符串，标识导出命名空间中的对象，服务器返回该对象的根文件句柄。装载协议支持导出过程，该过程将枚举服务器的导出。
The NFSv4 protocol provides a root filehandle that clients can use to obtain filehandles for these exports via a multi-component LOOKUP. A common user experience is to use a graphical user interface (perhaps a file "Open" dialog window) to find a file via progressive browsing
NFSv4协议提供了一个根文件句柄，客户端可以使用该根文件句柄通过多组件查找来获取这些导出的文件句柄。常见的用户体验是使用图形用户界面（可能是文件“打开”对话框窗口）通过渐进式浏览查找文件
through a directory tree. The client must be able to move from one export to another export via single-component, progressive LOOKUP operations.
通过目录树。客户端必须能够通过单个组件、渐进式查找操作从一个导出移动到另一个导出。
This style of browsing is not well supported by the NFSv2 and NFSv3 protocols. The client expects all LOOKUP operations to remain within a single-server file system. For example, the device attribute will not change. This prevents a client from taking namespace paths that span exports.
NFSv2和NFSv3协议不支持这种浏览方式。客户端希望所有查找操作都保留在单个服务器文件系统中。例如，设备属性不会更改。这将防止客户端采用跨越导出的命名空间路径。
An automounter on the client can obtain a snapshot of the server's namespace using the EXPORTS procedure of the MOUNT protocol. If it understands the server's pathname syntax, it can create an image of the server's namespace on the client. The parts of the namespace that are not exported by the server are filled in with a "pseudo-file system" that allows the user to browse from one mounted file system to another. There is a drawback to this representation of the server's namespace on the client: it is static. If the server administrator adds a new export, the client will be unaware of it.
客户机上的自动装载程序可以使用装载协议的导出过程获取服务器名称空间的快照。如果它理解服务器的路径名语法，就可以在客户端上创建服务器名称空间的映像。服务器未导出的命名空间部分由“伪文件系统”填充，该系统允许用户从一个装入的文件系统浏览到另一个装入的文件系统。这种在客户端上表示服务器名称空间的方法有一个缺点：它是静态的。如果服务器管理员添加了一个新的导出，客户端将不知道它。
NFSv4 servers avoid this namespace inconsistency by presenting all the exports within the framework of a single-server namespace. An NFSv4 client uses LOOKUP and READDIR operations to browse seamlessly from one export to another. Portions of the server namespace that are not exported are bridged via a "pseudo-file system" that provides a view of exported directories only. A pseudo-file system has a unique fsid and behaves like a normal, read-only file system.
NFSv4服务器通过在单个服务器名称空间的框架内呈现所有导出来避免这种名称空间不一致。NFSv4客户端使用查找和READDIR操作从一个导出无缝浏览到另一个导出。未导出的服务器命名空间部分通过“伪文件系统”桥接，该系统仅提供导出目录的视图。伪文件系统具有唯一的fsid，其行为类似于普通的只读文件系统。
Based on the construction of the server's namespace, it is possible that multiple pseudo-file systems may exist. For example:
根据服务器名称空间的构造，可能存在多个伪文件系统。例如：
/a pseudo-file system
/a/b real file system
/a/b/c pseudo-file system
/a/b/c/d real file system
/a pseudo-file system
/a/b real file system
/a/b/c pseudo-file system
/a/b/c/d real file system
Each of the pseudo-file systems are considered separate entities and therefore will have a unique fsid.
每个伪文件系统都被视为独立的实体，因此具有唯一的fsid。
The DOS and Windows operating environments are sometimes described as having "multiple roots". File systems are commonly represented as disk letters. MacOS represents file systems as top-level names. NFSv4 servers for these platforms can construct a pseudo-file system above these root names so that disk letters or volume names are simply directory names in the pseudo-root.
DOS和Windows操作环境有时被描述为具有“多个根”。文件系统通常表示为磁盘字母。MacOS将文件系统表示为顶级名称。这些平台的NFSv4服务器可以在这些根名称之上构造一个伪文件系统，以便磁盘字母或卷名称只是伪根中的目录名。
The nature of the server's pseudo-file system is that it is a logical representation of file system(s) available from the server. Therefore, the pseudo-file system is most likely constructed dynamically when the server is first instantiated. It is expected that the pseudo-file system may not have an on-disk counterpart from which persistent filehandles could be constructed. Even though it is preferable that the server provide persistent filehandles for the pseudo-file system, the NFS client should expect that pseudo-file system filehandles are volatile. This can be confirmed by checking the associated "fh_expire_type" attribute for those filehandles in question. If the filehandles are volatile, the NFS client must be prepared to recover a filehandle value (e.g., with a multi-component LOOKUP) when receiving an error of NFS4ERR_FHEXPIRED.
服务器伪文件系统的本质是，它是服务器上可用的文件系统的逻辑表示。因此，伪文件系统最有可能在服务器第一次实例化时动态构建。预计伪文件系统可能没有可用于构造持久化文件句柄的磁盘上副本。尽管服务器最好为伪文件系统提供持久的文件句柄，但NFS客户机应该认为伪文件系统文件句柄是易变的。这可以通过检查相关文件句柄的“fh\u expire\u type”属性来确认。如果文件句柄是易失性的，则NFS客户端必须准备在接收到NFS4ERR_错误时恢复文件句柄值（例如，使用多组件查找）。
If the server's root file system is exported, one might conclude that a pseudo-file system is not needed. This would be wrong. Assume the following file systems on a server:
如果导出了服务器的根文件系统，可能会得出不需要伪文件系统的结论。这是错误的。假设服务器上有以下文件系统：
/ disk1 (exported)
/a disk2 (not exported)
/a/b disk3 (exported)
/ disk1 (exported)
/a disk2 (not exported)
/a/b disk3 (exported)
Because disk2 is not exported, disk3 cannot be reached with simple LOOKUPs. The server must bridge the gap with a pseudo-file system.
由于未导出disk2，因此无法通过简单的查找访问disk3。服务器必须使用伪文件系统来弥补这一差距。
The server file system environment may be constructed in such a way that one file system contains a directory that is 'covered' or mounted upon by a second file system. For example:
服务器文件系统环境可以这样构造：一个文件系统包含一个被第二个文件系统“覆盖”或挂载的目录。例如：
/a/b (file system 1)
/a/b/c/d (file system 2)
/a/b (file system 1)
/a/b/c/d (file system 2)
The pseudo-file system for this server may be constructed to look like:
此服务器的伪文件系统的构造如下所示：
/ (placeholder/not exported)
/a/b (file system 1)
/a/b/c/d (file system 2)
/ (placeholder/not exported)
/a/b (file system 1)
/a/b/c/d (file system 2)
It is the server's responsibility to present the pseudo-file system that is complete to the client. If the client sends a LOOKUP request for the path "/a/b/c/d", the server's response is the filehandle of the file system "/a/b/c/d". In previous versions of the NFS protocol, the server would respond with the filehandle of directory "/a/b/c/d" within the file system "/a/b".
服务器负责向客户端呈现完整的伪文件系统。如果客户端发送路径“/a/b/c/d”的查找请求，则服务器的响应是文件系统“/a/b/c/d”的文件句柄。在以前版本的NFS协议中，服务器将在文件系统“/a/b”中使用目录“/a/b/c/d”的文件句柄进行响应。
The NFS client will be able to determine if it crosses a server mount point by a change in the value of the "fsid" attribute.
NFS客户端将能够通过更改“fsid”属性的值来确定它是否跨越服务器装载点。
Because NFSv4 clients possess the ability to change the security mechanisms used, after determining what is allowed, by using SECINFO the server SHOULD NOT present a different view of the namespace based on the security mechanism being used by a client. Instead, it should present a consistent view and return NFS4ERR_WRONGSEC if an attempt is made to access data with an inappropriate security mechanism.
由于NFSv4客户端具有更改所用安全机制的能力，因此在确定允许的安全机制后，通过使用SECINFO，服务器不应基于客户端使用的安全机制呈现命名空间的不同视图。相反，如果试图使用不适当的安全机制访问数据，它应该提供一致的视图并返回NFS4ERR_-errosec。
If security considerations make it necessary to hide the existence of a particular file system, as opposed to all of the data within it, the server can apply the security policy of a shared resource in the server's namespace to components of the resource's ancestors. For example:
如果出于安全考虑，需要隐藏特定文件系统的存在，而不是其中的所有数据，则服务器可以将服务器命名空间中共享资源的安全策略应用于资源祖先的组件。例如：
/ (placeholder/not exported)
/a/b (file system 1)
/a/b/MySecretProject (file system 2)
/ (placeholder/not exported)
/a/b (file system 1)
/a/b/MySecretProject (file system 2)
The /a/b/MySecretProject directory is a real file system and is the shared resource. Suppose the security policy for /a/b/ MySecretProject is Kerberos with integrity and it is desired to limit knowledge of the existence of this file system. In this case, the server should apply the same security policy to /a/b. This allows for knowledge of the existence of a file system to be secured when desirable.
/a/b/MySecretProject目录是一个真正的文件系统，是共享资源。假设/a/b/MySecretProject的安全策略是具有完整性的Kerberos，需要限制对该文件系统存在的了解。在这种情况下，服务器应该对/a/b应用相同的安全策略。这允许在需要时了解要保护的文件系统的存在。
For the case of the use of multiple, disjoint security mechanisms in the server's resources, applying that sort of policy would result in the higher-level file system not being accessible using any security
对于在服务器资源中使用多个不相交的安全机制的情况，应用这种策略将导致无法使用任何安全机制访问更高级别的文件系统
flavor. Therefore, that sort of configuration is not compatible with hiding the existence (as opposed to the contents) from clients using multiple disjoint sets of security flavors.
风味因此，这种配置与使用多个不相交的安全风格集向客户端隐藏存在（与内容相反）是不兼容的。
In other circumstances, a desirable policy is for the security of a particular object in the server's namespace to include the union of all security mechanisms of all direct descendants. A common and convenient practice, unless strong security requirements dictate otherwise, is to make the entire pseudo-file system accessible by all of the valid security mechanisms.
在其他情况下，理想的策略是服务器命名空间中特定对象的安全性，以包括所有直接子体的所有安全机制的联合。除非强烈的安全性要求另有规定，否则一种常见且方便的做法是让所有有效的安全机制都可以访问整个伪文件系统。
Where there is concern about the security of data on the network, clients should use strong security mechanisms to access the pseudo-file system in order to prevent man-in-the-middle attacks.
如果担心网络上数据的安全性，客户端应使用强大的安全机制访问伪文件系统，以防止中间人攻击。
NFSv4 supports attributes that allow a namespace to extend beyond the boundaries of a single server. It is RECOMMENDED that clients and servers support construction of such multi-server namespaces. Use of such multi-server namespaces is optional, however, and for many purposes, single-server namespaces are perfectly acceptable. Use of multi-server namespaces can provide many advantages, however, by separating a file system's logical position in a namespace from the (possibly changing) logistical and administrative considerations that result in particular file systems being located on particular servers.
NFSv4支持允许命名空间扩展到单个服务器边界之外的属性。建议客户端和服务器支持这种多服务器名称空间的构造。但是，使用这样的多服务器名称空间是可选的，对于许多目的，单服务器名称空间是完全可以接受的。但是，通过将文件系统在名称空间中的逻辑位置与导致特定文件系统位于特定服务器上的（可能不断变化的）后勤和管理考虑因素分开，使用多服务器名称空间可以提供许多优势。
NFSv4 contains RECOMMENDED attributes that allow file systems on one server to be associated with one or more instances of that file system on other servers. These attributes specify such file system instances by specifying a server address target (as either a DNS name representing one or more IP addresses, or a literal IP address), together with the path of that file system within the associated single-server namespace.
NFSv4包含建议的属性，允许一台服务器上的文件系统与其他服务器上该文件系统的一个或多个实例相关联。这些属性通过指定服务器地址目标（作为表示一个或多个IP地址的DNS名称或文字IP地址）以及相关单个服务器名称空间中该文件系统的路径来指定此类文件系统实例。
The fs_locations RECOMMENDED attribute allows specification of the file system locations where the data corresponding to a given file system may be found.
fs_locations RECOMMENDED属性允许指定文件系统位置，其中可以找到与给定文件系统对应的数据。
A given location in an NFSv4 namespace (typically but not necessarily a multi-server namespace) can have a number of file system instance locations associated with it via the fs_locations attribute. There may also be an actual current file system at that location,
NFSv4名称空间（通常但不一定是多服务器名称空间）中的给定位置可以通过fs_locations属性与多个文件系统实例位置关联。在该位置还可能存在实际的当前文件系统，
accessible via normal namespace operations (e.g., LOOKUP). In this case, the file system is said to be "present" at that position in the namespace, and clients will typically use it, reserving use of additional locations specified via the location-related attributes to situations in which the principal location is no longer available.
可通过正常名称空间操作（例如，查找）访问。在这种情况下，文件系统被称为在名称空间中的该位置“存在”，客户端通常会使用它，在主位置不再可用的情况下保留使用通过位置相关属性指定的其他位置。
When there is no actual file system at the namespace location in question, the file system is said to be "absent". An absent file system contains no files or directories other than the root. Any reference to it, except to access a small set of attributes useful in determining alternative locations, will result in an error, NFS4ERR_MOVED. Note that if the server ever returns the error NFS4ERR_MOVED, it MUST support the fs_locations attribute.
当所讨论的名称空间位置没有实际的文件系统时，文件系统被称为“缺席”。缺少的文件系统不包含根目录以外的文件或目录。对它的任何引用，除了访问在确定替代位置时有用的一小组属性外，都将导致错误NFS4ERR_MOVED。请注意，如果服务器返回错误NFS4ERR_MOVED，它必须支持fs_locations属性。
While the error name suggests that we have a case of a file system that once was present, and has only become absent later, this is only one possibility. A position in the namespace may be permanently absent with the set of file system(s) designated by the location attributes being the only realization. The name NFS4ERR_MOVED reflects an earlier, more limited conception of its function, but this error will be returned whenever the referenced file system is absent, whether it has moved or simply never existed.
虽然错误名称表明我们有一个文件系统的案例，它曾经存在，但后来才消失，但这只是一种可能性。名称空间中的位置可能永久不存在，位置属性指定的文件系统集是唯一的实现。名称NFS4ERR_MOVED反映了对其功能的更早、更有限的概念，但只要引用的文件系统不存在，无论它是否已移动，都会返回此错误。
Except in the case of GETATTR-type operations (to be discussed later), when the current filehandle at the start of an operation is within an absent file system, that operation is not performed and the error NFS4ERR_MOVED is returned, to indicate that the file system is absent on the current server.
除GETATTR类型的操作（稍后讨论）外，当操作开始时的当前文件句柄位于不存在的文件系统内时，不会执行该操作，并返回错误NFS4ERR_MOVED，以指示当前服务器上不存在该文件系统。
Because a GETFH cannot succeed if the current filehandle is within an absent file system, filehandles within an absent file system cannot be transferred to the client. When a client does have filehandles within an absent file system, it is the result of obtaining them when the file system was present, and having the file system become absent subsequently.
由于如果当前文件句柄位于缺少的文件系统中，则GETFH无法成功，因此无法将缺少的文件系统中的文件句柄传输到客户端。如果客户机在不存在的文件系统中确实具有文件句柄，则这是在文件系统存在时获取这些句柄，并使文件系统随后变得不存在的结果。
It should be noted that because the check for the current filehandle being within an absent file system happens at the start of every operation, operations that change the current filehandle so that it is within an absent file system will not result in an error. This allows such combinations as PUTFH-GETATTR and LOOKUP-GETATTR to be used to get attribute information, particularly location attribute information, as discussed below.
应该注意的是，由于检查当前文件句柄是否在缺少的文件系统中是在每次操作开始时进行的，因此更改当前文件句柄以使其位于缺少的文件系统中的操作不会导致错误。这允许使用PUTFH-GETATTR和LOOKUP-GETATTR等组合来获取属性信息，特别是位置属性信息，如下所述。
When a file system is absent, most attributes are not available, but it is necessary to allow the client access to the small set of attributes that are available, and most particularly that which gives information about the correct current locations for this file system, fs_locations.
当文件系统不存在时，大多数属性都不可用，但必须允许客户端访问可用的一小部分属性，尤其是提供有关此文件系统的正确当前位置信息的属性，即fs_位置。
As mentioned above, an exception is made for GETATTR in that attributes may be obtained for a filehandle within an absent file system. This exception only applies if the attribute mask contains at least the fs_locations attribute bit, which indicates that the client is interested in a result regarding an absent file system. If it is not requested, GETATTR will result in an NFS4ERR_MOVED error.
如上所述，GETATTR有一个例外，即可以为缺少的文件系统中的文件句柄获取属性。此异常仅适用于属性掩码至少包含fs_locations属性位的情况，该属性位表示客户端对缺少文件系统的结果感兴趣。如果未请求，GETATTR将导致NFS4ERR_移动错误。
When a GETATTR is done on an absent file system, the set of supported attributes is very limited. Many attributes, including those that are normally REQUIRED, will not be available on an absent file system. In addition to the fs_locations attribute, the following attributes SHOULD be available on absent file systems. In the case of RECOMMENDED attributes, they should be available at least to the same degree that they are available on present file systems.
在缺少文件系统的情况下执行GETATTR时，支持的属性集非常有限。许多属性（包括通常需要的属性）在缺少的文件系统上不可用。除了fs_locations属性外，以下属性在缺少的文件系统上也应该可用。对于推荐的属性，它们的可用程度应至少与当前文件系统上的可用程度相同。
fsid: This attribute should be provided so that the client can determine file system boundaries, including, in particular, the boundary between present and absent file systems. This value must be different from any other fsid on the current server and need have no particular relationship to fsids on any particular destination to which the client might be directed.
fsid：应提供此属性，以便客户端可以确定文件系统边界，特别是现有和不存在的文件系统之间的边界。此值必须不同于当前服务器上的任何其他fsid，并且不需要与客户端可能指向的任何特定目标上的fsid具有特定关系。
mounted_on_fileid: For objects at the top of an absent file system, this attribute needs to be available. Since the fileid is within the present parent file system, there should be no need to reference the absent file system to provide this information.
mounted_on_fileid：对于不存在的文件系统顶部的对象，此属性需要可用。由于fileid位于当前父文件系统中，因此不需要引用缺少的文件系统来提供此信息。
Other attributes SHOULD NOT be made available for absent file systems, even when it is possible to provide them. The server should not assume that more information is always better and should avoid gratuitously providing additional information.
对于缺少的文件系统，即使可以提供其他属性，也不应提供这些属性。服务器不应该认为信息越多越好，应该避免无偿提供额外信息。
When a GETATTR operation includes a bitmask for the attribute fs_locations, but where the bitmask includes attributes that are not supported, GETATTR will not return an error but will return the mask of the actual attributes supported with the results.
当GETATTR操作包含属性fs_位置的位掩码，但位掩码包含不受支持的属性时，GETATTR不会返回错误，而是返回结果支持的实际属性的掩码。
Handling of VERIFY/NVERIFY is similar to GETATTR in that if the attribute mask does not include fs_locations the error NFS4ERR_MOVED will result. It differs in that any appearance in the attribute mask of an attribute not supported for an absent file system (and note that this will include some normally REQUIRED attributes) will also cause an NFS4ERR_MOVED result.
VERIFY/NVERIFY的处理类似于GETATTR，因为如果属性掩码不包括fs_位置，则会导致错误NFS4ERR_MOVED。它的不同之处在于，属性掩码中不受缺少的文件系统支持的属性的任何外观（请注意，这将包括一些通常需要的属性）也将导致NFS4ERR_移动结果。
A READDIR performed when the current filehandle is within an absent file system will result in an NFS4ERR_MOVED error, since, unlike the case of GETATTR, no such exception is made for READDIR.
当当前文件句柄位于不存在的文件系统内时执行的READDIR将导致NFS4ERR_MOVED错误，因为与GETATTR的情况不同，READDIR没有此类异常。
Attributes for an absent file system may be fetched via a READDIR for a directory in a present file system, when that directory contains the root directories of one or more absent file systems. In this case, the handling is as follows:
当当前文件系统中的目录包含一个或多个缺席文件系统的根目录时，缺席文件系统的属性可以通过READDIR获取。在这种情况下，处理如下：
o If the attribute set requested includes fs_locations, then the fetching of attributes proceeds normally, and no NFS4ERR_MOVED indication is returned even when the rdattr_error attribute is requested.
o 如果请求的属性集包括fs_位置，则属性的获取正常进行，即使请求rdattr_错误属性，也不会返回NFS4ERR_移动指示。
o If the attribute set requested does not include fs_locations, then if the rdattr_error attribute is requested, each directory entry for the root of an absent file system will report NFS4ERR_MOVED as the value of the rdattr_error attribute.
o 如果请求的属性集不包括fs_位置，则如果请求rdattr_错误属性，则缺少文件系统的根目录的每个目录项都将报告NFS4ERR_MOVED作为rdattr_错误属性的值。
o If the attribute set requested does not include either of the attributes fs_locations or rdattr_error, then the occurrence of the root of an absent file system within the directory will result in the READDIR failing with an NFS4ERR_MOVED error.
o 如果请求的属性集不包括属性fs_locations或rdattr_error，则目录中不存在文件系统的根目录将导致READDIR失败，并出现NFS4ERR_MOVED错误。
o The unavailability of an attribute because of a file system's absence, even one that is ordinarily REQUIRED, does not result in any error indication. The set of attributes returned for the root directory of the absent file system in that case is simply restricted to those actually available.
o 由于文件系统不存在而导致属性不可用，即使是通常需要的属性，也不会导致任何错误指示。在这种情况下，为不存在的文件系统的根目录返回的属性集仅限于那些实际可用的属性。
The location-bearing attribute of fs_locations provides, together with the possibility of absent file systems, a number of important facilities in providing reliable, manageable, and scalable data access.
fs_locations的位置承载属性与缺少文件系统的可能性一起，提供了许多重要的功能，以提供可靠、可管理和可扩展的数据访问。
When a file system is present, these attributes can provide alternative locations, to be used to access the same data, in the event of server failures, communications problems, or other difficulties that make continued access to the current file system impossible or otherwise impractical. Under some circumstances, multiple alternative locations may be used simultaneously to provide higher-performance access to the file system in question. Provision of such alternative locations is referred to as "replication", although there are cases in which replicated sets of data are not in fact present and the replicas are instead different paths to the same data.
当存在文件系统时，这些属性可以提供备用位置，以便在出现服务器故障、通信问题或其他导致无法继续访问当前文件系统或无法继续访问当前文件系统的困难时，用于访问相同的数据。在某些情况下，可以同时使用多个备选位置，以提供对相关文件系统的更高性能访问。提供此类替代位置称为“复制”，尽管在某些情况下，复制的数据集实际上不存在，而副本是指向相同数据的不同路径。
When a file system is present and subsequently becomes absent, clients can be given the opportunity to have continued access to their data, at an alternative location. Transfer of the file system contents to the new location is referred to as "migration". See Section 8.4.2 for details.
当文件系统存在并且随后不存在时，客户机可以有机会在其他位置继续访问其数据。将文件系统内容传输到新位置称为“迁移”。详见第8.4.2节。
Alternative locations may be physical replicas of the file system data or alternative communication paths to the same server or, in the case of various forms of server clustering, another server providing access to the same physical file system. The client's responsibilities in dealing with this transition depend on the specific nature of the new access path as well as how and whether data was in fact migrated. These issues will be discussed in detail below.
替代位置可以是文件系统数据的物理副本或到同一服务器的替代通信路径，或者在各种形式的服务器集群的情况下，提供对同一物理文件系统的访问的另一服务器。客户在处理此转换时的责任取决于新访问路径的特定性质以及数据的实际迁移方式和是否迁移。下面将详细讨论这些问题。
Where a file system was not previously present, specification of file system location provides a means by which file systems located on one server can be associated with a namespace defined by another server, thus allowing a general multi-server namespace facility. A designation of such a location, in place of an absent file system, is called a "referral".
当文件系统以前不存在时，文件系统位置规范提供了一种方法，通过这种方法，位于一台服务器上的文件系统可以与另一台服务器定义的名称空间相关联，从而允许使用通用的多服务器名称空间功能。指定这样一个位置来代替缺少的文件系统，称为“参考”。
Because client support for location-related attributes is OPTIONAL, a server may (but is not required to) take action to hide migration and referral events from such clients, by acting as a proxy, for example.
由于客户机对位置相关属性的支持是可选的，因此服务器可以（但不需要）通过代理等方式对这些客户机隐藏迁移和引用事件。
The fs_locations attribute provides alternative locations, to be used to access data in place of, or in addition to, the current file system instance. On first access to a file system, the client should obtain the value of the set of alternative locations by interrogating the fs_locations attribute.
fs_locations属性提供了替代位置，用于代替或补充当前文件系统实例访问数据。在第一次访问文件系统时，客户机应通过询问fs_locations属性来获取备选位置集的值。
In the event that server failures, communications problems, or other difficulties make continued access to the current file system impossible or otherwise impractical, the client can use the alternative locations as a way to get continued access to its data. Multiple locations may be used simultaneously, to provide higher performance through the exploitation of multiple paths between client and target file system.
如果服务器故障、通信问题或其他困难导致无法继续访问当前文件系统或无法继续访问当前文件系统，客户机可以使用其他位置作为继续访问其数据的方式。可以同时使用多个位置，通过利用客户端和目标文件系统之间的多个路径来提供更高的性能。
Multiple server addresses, whether they are derived from a single entry with a DNS name representing a set of IP addresses or from multiple entries each with its own server address, may correspond to the same actual server.
多个服务器地址，无论是从一个具有代表一组IP地址的DNS名称的单个条目中派生出来的，还是从多个具有各自服务器地址的条目中派生出来的，都可能对应于同一个实际服务器。
When a file system is present and becomes absent, clients can be given the opportunity to have continued access to their data, at an alternative location, as specified by the fs_locations attribute. Typically, a client will be accessing the file system in question, get an NFS4ERR_MOVED error, and then use the fs_locations attribute to determine the new location of the data.
当文件系统存在且不存在时，客户机可以在fs_locations属性指定的其他位置继续访问其数据。通常，客户机将访问有问题的文件系统，获取NFS4ERR_MOVED错误，然后使用fs_locations属性确定数据的新位置。
Such migration can be helpful in providing load balancing or general resource reallocation. The protocol does not specify how the file system will be moved between servers. It is anticipated that a number of different server-to-server transfer mechanisms might be used, with the choice left to the server implementer. The NFSv4 protocol specifies the method used to communicate the migration event between client and server.
这种迁移有助于提供负载平衡或一般资源重新分配。该协议未指定文件系统在服务器之间移动的方式。预计可能会使用许多不同的服务器到服务器传输机制，选择权留给服务器实现者。NFSv4协议指定用于在客户端和服务器之间传递迁移事件的方法。
When an alternative location is designated as the target for migration, it must designate the same data. Where file systems are writable, a change made on the original file system must be visible on all migration targets. Where a file system is not writable but represents a read-only copy (possibly periodically updated) of a writable file system, similar requirements apply to the propagation of updates. Any change visible in the original file system must already be effected on all migration targets, to avoid any possibility that a client, in effecting a transition to the migration target, will see any reversion in file system state.
当替代位置被指定为迁移目标时，它必须指定相同的数据。如果文件系统是可写的，则对原始文件系统所做的更改必须在所有迁移目标上可见。如果文件系统不可写，但表示可写文件系统的只读副本（可能定期更新），则类似的要求适用于更新的传播。在原始文件系统中可见的任何更改必须已经在所有迁移目标上生效，以避免客户端在执行到迁移目标的转换时看到文件系统状态的任何恢复。
Referrals provide a way of placing a file system in a location within the namespace essentially without respect to its physical location on a given server. This allows a single server or a set of servers to present a multi-server namespace that encompasses file systems
引用提供了一种将文件系统放置在命名空间中某个位置的方法，基本上不考虑其在给定服务器上的物理位置。这允许单个服务器或一组服务器呈现包含文件系统的多服务器命名空间
located on multiple servers. Some likely uses of this include establishment of site-wide or organization-wide namespaces, or even knitting such together into a truly global namespace.
位于多个服务器上。它的一些可能用途包括建立站点范围或组织范围的名称空间，甚至将这些名称空间组合成一个真正的全局名称空间。
Referrals occur when a client determines, upon first referencing a position in the current namespace, that it is part of a new file system and that the file system is absent. When this occurs, typically by receiving the error NFS4ERR_MOVED, the actual location or locations of the file system can be determined by fetching the fs_locations attribute.
当客户机在第一次引用当前名称空间中的位置时，确定该位置是新文件系统的一部分并且该文件系统不存在时，就会发生引用。发生这种情况时，通常通过接收错误NFS4ERR_MOVED，可以通过获取fs_locations属性来确定文件系统的实际位置。
The location-related attribute may designate a single file system location or multiple file system locations, to be selected based on the needs of the client.
位置相关属性可以指定单个文件系统位置或多个文件系统位置，以根据客户机的需要进行选择。
Use of multi-server namespaces is enabled by NFSv4 but is not required. The use of multi-server namespaces and their scope will depend on the applications used and system administration preferences.
NFSv4支持使用多服务器名称空间，但不是必需的。多服务器名称空间的使用及其范围将取决于所使用的应用程序和系统管理首选项。
Multi-server namespaces can be established by a single server providing a large set of referrals to all of the included file systems. Alternatively, a single multi-server namespace may be administratively segmented with separate referral file systems (on separate servers) for each separately administered portion of the namespace. The top-level referral file system or any segment may use replicated referral file systems for higher availability.
多服务器名称空间可以由一台服务器建立，该服务器提供对所有包含的文件系统的大量引用。或者，单个多服务器名称空间可以使用单独的引用文件系统（在单独的服务器上）对名称空间的每个单独管理部分进行管理分段。顶级转诊文件系统或任何细分市场都可以使用复制的转诊文件系统以获得更高的可用性。
Generally, multi-server namespaces are for the most part uniform, in that the same data made available to one client at a given location in the namespace is made available to all clients at that location.
通常，多服务器名称空间在很大程度上是统一的，因为名称空间中给定位置的一个客户端可以使用的相同数据，在该位置的所有客户端都可以使用。
As mentioned above, a single location entry may have a server address target in the form of a DNS name that may represent multiple IP addresses, while multiple location entries may have their own server address targets that reference the same server.
如上所述，单个位置项可以具有DNS名称形式的服务器地址目标，该DNS名称可以表示多个IP地址，而多个位置项可以具有引用同一服务器的自己的服务器地址目标。
When multiple addresses for the same server exist, the client may assume that for each file system in the namespace of a given server network address, there exist file systems at corresponding namespace locations for each of the other server network addresses. It may do this even in the absence of explicit listing in fs_locations. Such corresponding file system locations can be used as alternative locations, just as those explicitly specified via the fs_locations attribute.
当同一服务器存在多个地址时，客户机可能会假定，对于给定服务器网络地址的命名空间中的每个文件系统，在其他每个服务器网络地址的相应命名空间位置都存在文件系统。即使在fs_位置中没有明确的列表，它也可以这样做。这些相应的文件系统位置可以用作替代位置，就像通过fs_locations属性显式指定的位置一样。
If a single location entry designates multiple server IP addresses, the client should choose a single one to use. When two server addresses are designated by a single location entry and they correspond to different servers, this normally indicates some sort of misconfiguration, and so the client should avoid using such location entries when alternatives are available. When they are not, clients should pick one of the IP addresses and use it, without using others that are not directed to the same server.
如果单个位置条目指定多个服务器IP地址，则客户端应选择一个要使用的IP地址。当两个服务器地址由一个位置条目指定，并且它们对应于不同的服务器时，这通常表示存在某种配置错误，因此当有其他选择时，客户端应避免使用此类位置条目。如果不是，客户端应该选择一个IP地址并使用它，而不使用其他不指向同一服务器的IP地址。
When clients make use of servers that implement referrals, replication, and migration, care should be taken that a user who mounts a given file system that includes a referral or a relocated file system continues to see a coherent picture of that user-side file system despite the fact that it contains a number of server-side file systems that may be on different servers.
当客户端使用实现转介、复制和迁移的服务器时，应注意，装载包含引用或重新定位文件系统的给定文件系统的用户继续看到该用户端文件系统的一致图片，尽管它包含许多可能位于不同服务器上的服务器端文件系统。
One important issue is upward navigation from the root of a server-side file system to its parent (specified as ".." in UNIX), in the case in which it transitions to that file system as a result of referral, migration, or a transition as a result of replication. When the client is at such a point, and it needs to ascend to the parent, it must go back to the parent as seen within the multi-server namespace rather than sending a LOOKUPP operation to the server, which would result in the parent within that server's single-server namespace. In order to do this, the client needs to remember the filehandles that represent such file system roots and use these instead of issuing a LOOKUPP operation to the current server. This will allow the client to present to applications a consistent namespace, where upward navigation and downward navigation are consistent.
一个重要问题是从服务器端文件系统的根目录向上导航到其父目录（在UNIX中指定为“.”），在这种情况下，由于引用、迁移或复制而转换到该文件系统。当客户端处于这样的位置，并且需要提升到父级时，它必须返回到多服务器名称空间中看到的父级，而不是向服务器发送LOOKUPP操作，这将导致该服务器的单服务器名称空间中的父级。为了做到这一点，客户机需要记住表示这些文件系统根的文件句柄，并使用它们，而不是向当前服务器发出LOOKUPP操作。这将允许客户端向应用程序提供一致的命名空间，其中向上导航和向下导航是一致的。
Another issue concerns refresh of referral locations. When referrals are used extensively, they may change as server configurations change. It is expected that clients will cache information related to traversing referrals so that future client-side requests are resolved locally without server communication. This is usually rooted in client-side name lookup caching. Clients should periodically purge this data for referral points in order to detect changes in location information.
另一个问题涉及转诊地点的更新。广泛使用转介时，它们可能会随着服务器配置的更改而更改。预期客户端将缓存与遍历引用相关的信息，以便将来的客户端请求在本地解析，而无需服务器通信。这通常源于客户端名称查找缓存。客户应定期清除转诊点的这些数据，以便检测位置信息的变化。
A potential problem exists if a client were to allow an open-owner to have state on multiple file systems on a server, in that it is unclear how the sequence numbers associated with open-owners are to be dealt with, in the event of transparent state migration. A client can avoid such a situation if it ensures that any use of an open-owner is confined to a single file system.
如果客户端允许开放所有者在服务器上的多个文件系统上拥有状态，则存在一个潜在问题，因为在透明状态迁移的情况下，不清楚如何处理与开放所有者关联的序列号。如果客户机确保开放所有者的任何使用仅限于单个文件系统，则可以避免这种情况。
A server MAY decline to migrate state associated with open-owners that span multiple file systems. In cases in which the server chooses not to migrate such state, the server MUST return NFS4ERR_BAD_STATEID when the client uses those stateids on the new server.
服务器可能会拒绝迁移与跨多个文件系统的开放所有者关联的状态。在服务器选择不迁移这种状态的情况下，当客户端在新服务器上使用这些STATEID时，服务器必须返回NFS4ERR_BAD_STATEID。
The server MUST return NFS4ERR_STALE_STATEID when the client uses those stateids on the old server, regardless of whether migration has occurred or not.
当客户端在旧服务器上使用NFS4ERR_STALE_STATEID时，服务器必须返回NFS4ERR_STALE_STATEID，无论是否发生迁移。
Referrals are effected when an absent file system is encountered and one or more alternative locations are made available by the fs_locations attribute. The client will typically get an NFS4ERR_MOVED error, fetch the appropriate location information, and proceed to access the file system on a different server, even though it retains its logical position within the original namespace. Referrals differ from migration events in that they happen only when the client has not previously referenced the file system in question (so there is nothing to transition). Referrals can only come into effect when an absent file system is encountered at its root.
当遇到不存在的文件系统并且fs_locations属性提供了一个或多个替代位置时，将影响引用。客户机通常会收到NFS4ERR_MOVED错误，获取适当的位置信息，并继续访问不同服务器上的文件系统，即使它在原始命名空间中保留其逻辑位置。引用与迁移事件的不同之处在于，它们仅在客户端以前没有引用过相关的文件系统时发生（因此不需要转换）。只有在根目录中遇到缺少的文件系统时，引用才能生效。
The examples given in the sections below are somewhat artificial in that an actual client will not typically do a multi-component lookup but will have cached information regarding the upper levels of the name hierarchy. However, these example are chosen to make the required behavior clear and easy to put within the scope of a small number of requests, without getting unduly into details of how specific clients might choose to cache things.
下面几节中给出的示例有些人为，因为实际的客户机通常不会执行多组件查找，但会缓存有关名称层次结构上层的信息。然而，选择这些示例是为了使所需的行为清晰，并且易于放在少量请求的范围内，而不必过分详细地说明特定客户机可能如何选择缓存内容。
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 may be for a number of reasons. It may be the case that the file system has moved, or it may be the case that the target server is functioning mainly, or solely, to refer clients to the servers on which various file systems are located.
假设在目标服务器中不存在/this/is/the/path的环境中发送以下化合物。这可能有很多原因。可能是文件系统已移动，也可能是目标服务器主要或仅在将客户端引用到各种文件系统所在的服务器。
o PUTROOTFH
o PUTROOTFH
o LOOKUP "this"
o 查找“此”
o LOOKUP "is"
o 查找“是”
o LOOKUP "the"
o 查找“the”
o LOOKUP "path"
o 查找“路径”
o GETFH
o GETFH
o GETATTR(fsid, fileid, size, time_modify)
o GETATTR（fsid、fileid、大小、时间\u修改）
Under the given circumstances, the following will be the result:
在特定情况下，结果如下：
o PUTROOTFH --> NFS_OK. The current fh is now the root of the pseudo-fs.
o PUTROOTFH-->NFS\u正常。当前fh现在是伪fs的根。
o LOOKUP "this" --> NFS_OK. The current fh is for /this and is within the pseudo-fs.
o 查找“this”->NFS\u确定。当前fh适用于/且在伪fs范围内。
o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is within the pseudo-fs.
o 查找“是”-->NFS\u正常。当前fh为/this/is，且在伪fs范围内。
o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and is within the pseudo-fs.
o 查找“the”-->NFS\u确定。当前fh用于/this/is/The，并且在伪fs内。
o 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 never see the value of that fh.
o 查找“路径”-->NFS\u确定。当前fh用于/this/is/The/path，并且位于一个新的、缺少的文件系统中，但是。。。客户永远看不到fh的价值。
o GETFH --> NFS4ERR_MOVED. Fails, because the current fh is in an absent file system at the start of the operation and the specification makes no exception for GETFH.
o GETFH-->NFS4ERR\u已移动。失败，因为当前fh在操作开始时位于缺少的文件系统中，并且规范对GETFH也不例外。
o GETATTR(fsid, fileid, size, time_modify). Not executed, because the failure of the GETFH stops the processing of the COMPOUND.
o GETATTR（fsid、fileid、大小、时间和修改）。未执行，因为GETFH的故障停止了化合物的处理。
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 system, i.e., the server and path relative to that server's root fh. Note here that in this example, the client did not obtain filehandles and attribute information (e.g., fsid) for the intermediate directories, 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 moved file system and that the reason that the lookup of "path" succeeded is that the file system was not absent on
考虑到GETFH的失败，客户端的任务是确定缺少的文件系统的根，以及在哪里找到该文件系统，即服务器和相对于该服务器的根fh的路径。请注意，在此示例中，客户机没有获取中间目录的文件句柄和属性信息（例如，fsid），因此无法确定缺少的文件系统从何处启动。例如，/this/is/the可能是已移动文件系统的根目录，查找“path”成功的原因可能是上没有缺少文件系统
that operation but was moved between the last LOOKUP and the GETFH (since COMPOUND is not atomic). Even if we had the fsids for all of the intermediate directories, we could have no way of knowing that /this/is/the/path was the root of a new file system, since we don't yet have its fsid.
但在最后一次查找和GETFH之间移动了该操作（因为化合物不是原子的）。即使我们拥有所有中间目录的fsid，我们也无法知道/this/is/the/path是新文件系统的根，因为我们还没有它的fsid。
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 can be sure where the appropriate file system boundaries are. The client could choose to get fs_locations at the same time, but in most cases the client will have a good guess as to where the file system boundaries are (because of where NFS4ERR_MOVED was, and was not, received), making the fetching of fs_locations unnecessary.
为了获得必要的信息，让我们使用GETFHs和GETATTRs重新发送查找链，以至少获取fsid，这样我们就可以确定适当的文件系统边界在哪里。客户机可以选择同时获取fs_位置，但在大多数情况下，客户机都可以很好地猜测文件系统边界的位置（因为NFS4ERR_移动的位置和未接收的位置），因此不需要获取fs_位置。
OP01: PUTROOTFH --> NFS_OK
OP01: PUTROOTFH --> NFS_OK
- The current fh is at the root of the pseudo-fs.
- 当前fh位于伪fs的根。
OP02: GETATTR(fsid) --> NFS_OK
OP02: GETATTR(fsid) --> NFS_OK
- Just for completeness. Normally, clients will know the fsid of the pseudo-fs as soon as they establish communication with a server.
- 只是为了完整。通常，客户机在与服务器建立通信后就会知道伪fs的fsid。
OP03: LOOKUP "this" --> NFS_OK
OP03: LOOKUP "this" --> NFS_OK
OP04: GETATTR(fsid) --> NFS_OK
OP04: GETATTR(fsid) --> NFS_OK
- Get the current fsid to see where the file system boundaries are. The fsid will be that for the pseudo-fs in this example, so no boundary.
- 获取当前fsid以查看文件系统边界的位置。fsid将是本例中伪fs的fsid，因此没有边界。
OP05: GETFH --> NFS_OK
OP05: GETFH --> NFS_OK
- The current fh is for /this and is within the pseudo-fs.
- 当前fh适用于/且在伪fs范围内。
OP06: LOOKUP "is" --> NFS_OK
OP06: LOOKUP "is" --> NFS_OK
- The current fh is for /this/is and is within the pseudo-fs.
- 当前fh为/this/is，且在伪fs范围内。
OP07: GETATTR(fsid) --> NFS_OK
OP07: GETATTR(fsid) --> NFS_OK
- Get the current fsid to see where the file system boundaries are. The fsid will be that for the pseudo-fs in this example, so no boundary.
- 获取当前fsid以查看文件系统边界的位置。fsid将是本例中伪fs的fsid，因此没有边界。
OP08: GETFH --> NFS_OK
OP08: GETFH --> NFS_OK
- The current fh is for /this/is and is within the pseudo-fs.
- 当前fh为/this/is，且在伪fs范围内。
OP09: LOOKUP "the" --> NFS_OK
OP09: LOOKUP "the" --> NFS_OK
- The current fh is for /this/is/the and is within the pseudo-fs.
- 当前fh用于/this/is/The，并且在伪fs内。
OP10: GETATTR(fsid) --> NFS_OK
OP10: GETATTR(fsid) --> NFS_OK
- Get the current fsid to see where the file system boundaries are. The fsid will be that for the pseudo-fs in this example, so no boundary.
- 获取当前fsid以查看文件系统边界的位置。fsid将是本例中伪fs的fsid，因此没有边界。
OP11: GETFH --> NFS_OK
OP11: GETFH --> NFS_OK
- The current fh is for /this/is/the and is within the pseudo-fs.
- 当前fh用于/this/is/The，并且在伪fs内。
OP12: LOOKUP "path" --> NFS_OK
OP12: LOOKUP "path" --> NFS_OK
- The current fh is for /this/is/the/path and is within a new, absent file system, but ...
- 当前fh用于/this/is/The/path，并且位于一个新的、缺少的文件系统中，但是。。。
- The client will never see the value of that fh.
- 客户永远看不到fh的价值。
OP13: GETATTR(fsid, fs_locations) --> NFS_OK
OP13: GETATTR(fsid, fs_locations) --> NFS_OK
- We are getting the fsid to know where the file system boundaries are. In this operation, the fsid will be different than that of the parent directory (which in turn was retrieved in OP10). Note that the fsid we are given will not necessarily be preserved at the new location. That fsid might be different, and in fact the fsid we have for this file system might be a valid fsid of a different file system on that new server.
- 我们正在让fsid知道文件系统边界在哪里。在这个操作中，fsid将不同于父目录的fsid（父目录又在OP10中检索到）。请注意，我们获得的fsid不一定会保留在新位置。该fsid可能不同，事实上，我们为该文件系统提供的fsid可能是新服务器上不同文件系统的有效fsid。
- In this particular case, we are pretty sure anyway that what has moved is /this/is/the/path rather than /this/is/the since we have the fsid of the latter and it is that of the pseudo-fs, which presumably cannot move. However, in other examples, we might not have this kind of information to rely on (e.g., /this/is/the might be a non-pseudo-file system separate from /this/is/the/path), so we need to have other reliable source information on the boundary of the file system that is moved. If, for example, the file system /this/is had moved, we would have a case of migration rather than referral, and once the boundaries of the migrated file system were clear we could fetch fs_locations.
- 在这个特殊的例子中，我们非常确定已经移动的是/this/is/the/path而不是/this/is/the，因为我们有后者的fsid，它是伪fs的fsid，它可能无法移动。但是，在其他示例中，我们可能没有此类信息可依赖（例如，/this/is/the可能是与/this/is/the/path分离的非伪文件系统），因此我们需要在移动的文件系统边界上有其他可靠的源信息。例如，如果文件系统/this/is已移动，我们将遇到迁移而不是引用的情况，并且一旦迁移的文件系统的边界被清除，我们就可以获取fs_位置。
- We are fetching fs_locations because the fact that we got an NFS4ERR_MOVED at this point means that this is most likely a referral and we need the destination. Even if it is the case that /this/is/the is a file system that has migrated, we will still need the location information for that file system.
- 我们正在获取fs_位置，因为我们在此时移动了一个NFS4ERR_，这意味着这很可能是一个转介，我们需要目的地。即使/this/is/the是已迁移的文件系统，我们仍然需要该文件系统的位置信息。
OP14: GETFH --> NFS4ERR_MOVED
OP14: GETFH --> NFS4ERR_MOVED
- Fails because current fh is in an absent file system at the start of the operation, and the specification makes no exception for GETFH. Note that this means the server will never send the client a filehandle from within an absent file system.
- 失败，因为在操作开始时，当前fh位于缺少的文件系统中，并且规范对GETFH也不例外。请注意，这意味着服务器永远不会从缺少的文件系统中向客户端发送文件句柄。
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 occurred (between "the" and "path"). The fs_locations attribute also gives the client the actual location of the absent file system so that the referral can proceed. The server gives the client the bare minimum of information about the absent file system so that there will be very little scope for problems of conflict between information sent by the referring server and information of the file system's home. No filehandles and very few attributes are present on the referring server, and the client can treat those it receives as transient information with the function of enabling the referral.
鉴于上述情况，客户机通过注意fsid的更改发生在何处（在“the”和“path”之间），知道缺少的文件系统的根在何处（/this/is/the/path）。fs_locations属性还为客户端提供缺少的文件系统的实际位置，以便可以继续引用。服务器向客户机提供关于缺少的文件系统的最低限度的信息，这样，在引用服务器发送的信息与文件系统的主信息之间发生冲突的问题的范围将非常小。引用服务器上没有文件句柄，属性也很少，客户端可以使用启用引用的功能将接收到的文件句柄和属性视为临时信息。
Another context in which a client may encounter referrals is when it does a READDIR on a directory in which some of the subdirectories are the roots of absent file systems.
客户机可能遇到引用的另一个上下文是，当它在一个目录上执行READDIR时，其中一些子目录是不存在的文件系统的根。
Suppose such a directory is read as follows:
假设这样一个目录如下所示：
o PUTROOTFH
o PUTROOTFH
o LOOKUP "this"
o 查找“此”
o LOOKUP "is"
o 查找“是”
o LOOKUP "the"
o 查找“the”
o READDIR(fsid, size, time_modify, mounted_on_fileid)
o READDIR（fsid、大小、时间、修改、在文件ID上挂载）
In this case, because rdattr_error is not requested, fs_locations is not requested, and some of the attributes cannot be provided, the result will be an NFS4ERR_MOVED error on the READDIR, with the detailed results as follows:
在这种情况下，由于未请求rdattr_错误，未请求fs_位置，并且无法提供某些属性，因此结果将是READDIR上的NFS4ERR_移动错误，详细结果如下：
o PUTROOTFH --> NFS_OK. The current fh is at the root of the pseudo-fs.
o PUTROOTFH-->NFS\u正常。当前fh位于伪fs的根。
o LOOKUP "this" --> NFS_OK. The current fh is for /this and is within the pseudo-fs.
o 查找“this”->NFS\u确定。当前fh适用于/且在伪fs范围内。
o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is within the pseudo-fs.
o 查找“是”-->NFS\u正常。当前fh为/this/is，且在伪fs范围内。
o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and is within the pseudo-fs.
o 查找“the”-->NFS\u确定。当前fh用于/this/is/The，并且在伪fs内。
o READDIR(fsid, size, time_modify, mounted_on_fileid) --> NFS4ERR_MOVED. Note that the same error would have been returned if /this/is/the had migrated, but it is returned because the directory contains the root of an absent file system.
o READDIR（fsid、大小、时间、修改、在文件ID上挂载）-->NFS4ERR\u已移动。请注意，如果/this/is/the已迁移，则会返回相同的错误，但返回该错误是因为该目录包含缺少的文件系统的根。
So now suppose that we re-send with rdattr_error:
现在假设我们用rdattr_错误重新发送：
o PUTROOTFH
o PUTROOTFH
o LOOKUP "this"
o 查找“此”
o LOOKUP "is"
o 查找“是”
o LOOKUP "the"
o 查找“the”
o READDIR(rdattr_error, fsid, size, time_modify, mounted_on_fileid)
o READDIR（rdattr错误、fsid、大小、时间、修改、在文件ID上挂载）
The results will be:
结果将是：
o PUTROOTFH --> NFS_OK. The current fh is at the root of the pseudo-fs.
o PUTROOTFH-->NFS\u正常。当前fh位于伪fs的根。
o LOOKUP "this" --> NFS_OK. The current fh is for /this and is within the pseudo-fs.
o 查找“this”->NFS\u确定。当前fh适用于/且在伪fs范围内。
o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is within the pseudo-fs.
o 查找“是”-->NFS\u正常。当前fh为/this/is，且在伪fs范围内。
o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and is within the pseudo-fs.
o 查找“the”-->NFS\u确定。当前fh用于/this/is/The，并且在伪fs内。
o READDIR(rdattr_error, fsid, size, time_modify, mounted_on_fileid) --> NFS_OK. The attributes for the directory entry with the component named "path" will only contain rdattr_error with the value NFS4ERR_MOVED, together with an fsid value and a value for mounted_on_fileid.
o READDIR（rdattr\u错误、fsid、大小、时间\u修改、在\u文件ID上装载）->NFS\u正常。名为“path”的组件的目录项的属性将仅包含值为NFS4ERR_MOVED的rdattr_error，以及fsid值和fileid上mounted_的值。
So suppose we do another READDIR to get fs_locations (although we could have used a GETATTR directly, as in Section 8.7.1):
因此，假设我们执行另一个READDIR来获取fs_位置（尽管我们可以直接使用GETATTR，如第8.7.1节所述）：
o PUTROOTFH
o PUTROOTFH
o LOOKUP "this"
o 查找“此”
o LOOKUP "is"
o 查找“是”
o LOOKUP "the"
o 查找“the”
o READDIR(rdattr_error, fs_locations, mounted_on_fileid, fsid, size, time_modify)
o READDIR（rdattr\u错误、fs\u位置、文件ID上的挂载\u、fsid、大小、时间\u修改）
The results would be:
结果将是：
o PUTROOTFH --> NFS_OK. The current fh is at the root of the pseudo-fs.
o PUTROOTFH-->NFS\u正常。当前fh位于伪fs的根。
o LOOKUP "this" --> NFS_OK. The current fh is for /this and is within the pseudo-fs.
o 查找“this”->NFS\u确定。当前fh适用于/且在伪fs范围内。
o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is within the pseudo-fs.
o 查找“是”-->NFS\u正常。当前fh为/this/is，且在伪fs范围内。
o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and is within the pseudo-fs.
o 查找“the”-->NFS\u确定。当前fh用于/this/is/The，并且在伪fs内。
o READDIR(rdattr_error, fs_locations, mounted_on_fileid, fsid, size, time_modify) --> NFS_OK. The attributes will be as shown below.
o READDIR（rdattr\u错误、fs\u位置、文件ID上的挂载、fsid、大小、时间\u修改）->NFS\u正常。属性如下所示。
The attributes for the directory entry with the component named "path" will only contain:
组件名为“path”的目录项的属性将仅包含：
o rdattr_error (value: NFS_OK)
o rdattr_错误（值：NFS_OK）
o fs_locations
o 财政司司长办公室地点
o mounted_on_fileid (value: unique fileid within referring file system)
o 在文件ID上装入文件（值：引用文件系统中的唯一文件ID）
o fsid (value: unique value within referring server)
o fsid（值：引用服务器中的唯一值）
The attributes for entry "path" will not contain size or time_modify, because these attributes are not available within an absent file system.
条目“path”的属性将不包含size或time\u modify，因为这些属性在缺少的文件系统中不可用。
The fs_locations attribute is defined by both fs_location4 (Section 2.2.6) and fs_locations4 (Section 2.2.7). It is used to represent the location of a file system by providing a server name and the path to the root of the file system within that server's namespace. When a set of servers have corresponding file systems at the same path within their namespaces, an array of server names may be provided. An entry in the server array is a UTF-8 string and represents one of a traditional DNS host name, IPv4 address, IPv6 address, or a zero-length string. A zero-length string SHOULD be used to indicate the current address being used for the RPC. It is not a requirement that all servers that share the same rootpath be listed in one fs_location4 instance. The array of server names is provided for convenience. Servers that share the same rootpath may also be listed in separate fs_location4 entries in the fs_locations attribute.
fs_位置属性由fs_位置4（第2.2.6节）和fs_位置4（第2.2.7节）定义。它通过提供服务器名称和文件系统根目录在服务器名称空间中的路径来表示文件系统的位置。当一组服务器在其名称空间内的同一路径上具有相应的文件系统时，可以提供服务器名称数组。服务器阵列中的条目是UTF-8字符串，表示传统DNS主机名、IPv4地址、IPv6地址或零长度字符串之一。长度为零的字符串应用于指示RPC使用的当前地址。不要求共享同一根路径的所有服务器都列在一个fs_location4实例中。为方便起见，提供了服务器名称数组。共享同一根路径的服务器也可能列在fs_locations属性的单独fs_location4条目中。
The fs_locations4 data type and fs_locations attribute contain an array of such locations. Since the namespace of each server may be constructed differently, the fs_root field is provided. The path represented by the fs_root represents the location of the file system in the current server's namespace, i.e., that of the server from which the fs_locations attribute was obtained. The fs_root path is meant to aid the client by clearly referencing the root of the file system whose locations are being reported, no matter what object within the current file system the current filehandle designates. The fs_root is simply the pathname the client used to reach the object on the current server (i.e., the object to which the fs_locations attribute applies).
fs_locations4数据类型和fs_locations属性包含此类位置的数组。由于每个服务器的名称空间的构造可能不同，因此提供了fs_root字段。由fs_根表示的路径表示文件系统在当前服务器名称空间中的位置，即获取fs_locations属性的服务器的位置。fs_根路径旨在通过明确引用正在报告其位置的文件系统的根来帮助客户端，无论当前文件句柄指定当前文件系统中的哪个对象。fs_根只是客户端用来访问当前服务器上的对象（即fs_locations属性所应用的对象）的路径名。
When the fs_locations attribute is interrogated and there are no alternative file system locations, the server SHOULD return a zero-length array of fs_location4 structures, together with a valid fs_root.
当查询fs_locations属性且没有其他文件系统位置时，服务器应返回fs_location4结构的零长度数组以及有效的fs_根。
As an example, suppose there is a replicated file system located at
two servers (servA and servB). At servA, the file system is located
at path /a/b/c. At servB, the file system is located at path /x/y/z.
If the client were to obtain the fs_locations value for the directory
at /a/b/c/d, it might not necessarily know that the file system's
root is located in servA's namespace at /a/b/c. When the client
switches to servB, it will need to determine that the directory it
first referenced at servA is now represented by the path /x/y/z/d
As an example, suppose there is a replicated file system located at
two servers (servA and servB). At servA, the file system is located
at path /a/b/c. At servB, the file system is located at path /x/y/z.
If the client were to obtain the fs_locations value for the directory
at /a/b/c/d, it might not necessarily know that the file system's
root is located in servA's namespace at /a/b/c. When the client
switches to servB, it will need to determine that the directory it
first referenced at servA is now represented by the path /x/y/z/d
on servB. To facilitate this, the fs_locations attribute provided by servA would have an fs_root value of /a/b/c and two entries in fs_locations. One entry in fs_locations will be for itself (servA), and the other will be for servB with a path of /x/y/z. With this information, the client is able to substitute /x/y/z for /a/b/c at the beginning of its access path and construct /x/y/z/d to use for the new server.
在servB上。为了便于实现这一点，servA提供的fs_locations属性的fs_根值为/a/b/c，在fs_位置中有两个条目。fs_位置中的一个条目将用于自身（servA），另一个条目将用于路径为/x/y/z的servB。有了这些信息，客户端可以在其访问路径的开始处用/x/y/z替换/a/b/c，并构造/x/y/z/d以用于新服务器。
Note that there is no requirement that the number of components in each rootpath be the same; there is no relation between the number of components in the rootpath or fs_root, and none of the components in each rootpath and fs_root have to be the same. In the above example, we could have had a third element in the locations array, with server equal to "servC" and rootpath equal to "/I/II", and a fourth element in the locations array, with server equal to "servD" and rootpath equal to "/aleph/beth/gimel/daleth/he".
注意，没有要求每个根路径中的组件数量相同；根路径或fs_根中的组件数量之间没有关系，每个根路径和fs_根中的组件都不必相同。在上面的示例中，我们可以在locations数组中有第三个元素，其中server等于“servC”，rootpath等于“/I/II”；在locations数组中有第四个元素，server等于“servD”，rootpath等于“/aleph/beth/gimel/daleth/he”。
The relationship between an fs_root and a rootpath is that the client replaces the pathname indicated in the fs_root for the current server for the substitute indicated in the rootpath for the new server.
fs_根目录和根路径之间的关系是，客户端将当前服务器的fs_根目录中指示的路径名替换为新服务器的根路径中指示的替换项。
For an example of a referred or migrated file system, suppose there is a file system located at serv1. At serv1, the file system is located at /az/buky/vedi/glagoli. The client finds that the object at glagoli has migrated (or is a referral). The client gets the fs_locations attribute, which contains an fs_root of /az/buky/vedi/ glagoli, and one element in the locations array, with server equal to serv2, and rootpath equal to /izhitsa/fita. The client replaces /az/buky/vedi/glagoli with /izhitsa/fita and uses the latter pathname on serv2.
对于引用或迁移的文件系统示例，假设有一个文件系统位于serv1。在serv1中，文件系统位于/az/buky/vedi/glagoli。客户端发现glagoli的对象已迁移（或是引用）。客户端获取fs_locations属性，该属性包含/az/buky/vedi/glagoli的fs_根，以及locations数组中的一个元素，其中server等于serv2，rootpath等于/izhitsa/fita。客户端将/az/buky/vedi/glagoli替换为/izhitsa/fita，并在serv2上使用后者的路径名。
Thus, the server MUST return an fs_root that is equal to the path the client used to reach the object to which the fs_locations attribute applies. Otherwise, the client cannot determine the new path to use on the new server.
因此，服务器必须返回一个fs_根，该根等于客户端用来到达应用fs_locations属性的对象的路径。否则，客户端无法确定要在新服务器上使用的新路径。
Integrating locking into the NFS protocol necessarily causes it to be stateful. With the inclusion of share reservations, the protocol becomes substantially more dependent on state than the traditional combination of NFS and NLM (Network Lock Manager) [xnfs]. There are three components to making this state manageable:
将锁定集成到NFS协议中必然会导致它是有状态的。由于包含了共享保留，协议比NFS和NLM（网络锁管理器）[xnfs]的传统组合更依赖于状态。要使此状态易于管理，有三个组件：
o clear division between client and server
o 清除客户端和服务器之间的划分
o ability to reliably detect inconsistency in state between client and server
o 能够可靠地检测客户端和服务器之间状态的不一致性
o simple and robust recovery mechanisms
o 简单而稳健的恢复机制
In this model, the server owns the state information. The client requests changes in locks, and the server responds with the changes made. Non-client-initiated changes in locking state are infrequent. The client receives prompt notification of such changes and can 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 client at its request are represented by 128-bit stateids. These stateids may represent a particular open file, a set of byte-range locks held by a particular owner, or a recallable delegation of privileges to access a file in particular ways or at a particular location.
由服务器创建并在客户机请求时传递给客户机的各个状态段由128位StateID表示。这些stateID可以表示特定打开的文件、特定所有者持有的一组字节范围锁，或者以特定方式或在特定位置访问文件的可重新分配的权限。
In all cases, there is a transition from the most general information that represents a client as a whole to the eventual lightweight stateid used for most client and server locking interactions. The details of this transition will vary with the type of object, but it always starts with a client ID.
在所有情况下，都会从代表整个客户机的最一般信息过渡到用于大多数客户机和服务器锁定交互的最终轻量级stateid。此转换的详细信息将随对象的类型而变化，但它总是以客户机ID开始。
To support Win32 share reservations, it is necessary to atomically OPEN or CREATE files and apply the appropriate locks in the same operation. Having a separate share/unshare operation would not allow correct implementation of the Win32 OpenFile API. In order to correctly implement share semantics, the previous NFS protocol mechanisms used when a file is opened or created (LOOKUP, CREATE, ACCESS) need to be replaced. The NFSv4 protocol has an OPEN operation that subsumes the NFSv3 methodology of LOOKUP, CREATE, and ACCESS. However, because many operations require a filehandle, the traditional LOOKUP is preserved to map a filename to a filehandle without establishing state on the server. The policy of granting access or modifying files is managed by the server based on the client's state. These mechanisms can implement policy ranging from advisory only locking to full mandatory locking.
要支持Win32共享保留，必须在同一操作中以原子方式打开或创建文件并应用适当的锁。使用单独的共享/取消共享操作将不允许Win32 OpenFile API的正确实现。为了正确实现共享语义，需要替换以前在打开或创建文件（查找、创建、访问）时使用的NFS协议机制。NFSv4协议有一个开放操作，包含了查找、创建和访问的NFSv3方法。但是，由于许多操作需要文件句柄，因此保留了传统的查找方法，以便将文件名映射到文件句柄，而无需在服务器上建立状态。授予访问权限或修改文件的策略由服务器根据客户端的状态进行管理。这些机制可以实现从仅建议锁定到完全强制锁定的策略。
It is assumed that manipulating a byte-range lock is rare when compared to READ and WRITE operations. It is also assumed that server restarts and network partitions are relatively rare. Therefore, it is important that the READ and WRITE operations have a lightweight mechanism to indicate if they possess a held lock. A byte-range lock request contains the heavyweight information required to establish a lock and uniquely define the owner of the lock.
与读写操作相比，假设操纵字节范围锁的情况很少。还假定服务器重启和网络分区相对较少。因此，读写操作必须有一个轻量级的机制来指示它们是否拥有持有的锁。字节范围锁请求包含建立锁和唯一定义锁所有者所需的重量级信息。
The following sections describe the transition from the heavyweight information to the eventual stateid used for most client and server locking and lease interactions.
以下各节描述了从重量级信息到用于大多数客户端和服务器锁定和租赁交互的最终stateid的转换。
For each LOCK request, the client must identify itself to the server. This is done in such a way as to allow for correct lock identification and crash recovery. A sequence of a SETCLIENTID operation followed by a SETCLIENTID_CONFIRM operation is required to establish the identification onto the server. Establishment of identification by a new incarnation of the client also has the effect of immediately breaking any leased state that a previous incarnation of the client might have had on the server, as opposed to forcing the new client incarnation to wait for the leases to expire. Breaking the lease state amounts to the server removing all lock, share reservation, and, where the server is not supporting the CLAIM_DELEGATE_PREV claim type, all delegation state associated with the same client with the same identity. For a discussion of delegation state recovery, see Section 10.2.1.
对于每个锁请求，客户端必须向服务器标识自己。这是以允许正确识别锁和碰撞恢复的方式进行的。要在服务器上建立标识，需要先执行SETCLIENTID操作，然后执行SETCLIENTID_确认操作。通过客户机的新版本建立标识还具有立即中断客户机的前一版本可能在服务器上具有的任何租用状态的效果，而不是强制新客户机版本等待租用到期。破坏租约状态相当于服务器删除所有锁、共享保留，如果服务器不支持CLAIM_DELEGATE_PREV CLAIM类型，则删除与具有相同标识的同一客户端关联的所有委派状态。有关授权状态恢复的讨论，请参见第10.2.1节。
Owners of opens and owners of byte-range locks are separate entities and remain separate even if the same opaque arrays are used to designate owners of each. The protocol distinguishes between open-owners (represented by open_owner4 structures) and lock-owners (represented by lock_owner4 structures).
opens的所有者和byte range锁的所有者是独立的实体，即使使用相同的不透明数组指定每个锁的所有者，它们仍然保持独立。该协议区分开放所有者（由open_owner4结构表示）和锁所有者（由lock_owner4结构表示）。
Both sorts of owners consist of a clientid and an opaque owner string. For each client, the set of distinct owner values used with that client constitutes the set of owners of that type, for the given client.
这两种所有者都由clientid和不透明的所有者字符串组成。对于每个客户机，与该客户机一起使用的一组不同的所有者值构成了给定客户机的该类型的所有者集。
Each open is associated with a specific open-owner, while each byte-range lock is associated with a lock-owner and an open-owner, the latter being the open-owner associated with the open file under which the LOCK operation was done.
每个打开与特定的打开所有者关联，而每个字节范围锁与一个锁所有者和一个打开所有者关联，后者是与执行锁定操作的打开文件关联的打开所有者。
Client identification is encapsulated in the following structure:
客户标识封装在以下结构中：
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
The first field, verifier, is a client incarnation verifier that is used to detect client reboots. Only if the verifier is different from that which the server has previously recorded for the client (as identified by the second field of the structure, id) does the server start the process of canceling the client's leased state.
第一个字段verifier是用于检测客户端重新启动的客户端化身验证器。只有当验证器不同于服务器先前为客户机记录的验证器（由结构的第二个字段标识，id）时，服务器才会启动取消客户机租用状态的过程。
The second field, id, is a variable-length string that uniquely defines the client.
第二个字段id是唯一定义客户机的可变长度字符串。
There are several considerations for how the client generates the id string:
对于客户端如何生成id字符串，有几个注意事项：
o The string should be unique so that multiple clients do not present the same string. The consequences of two clients presenting the same string range from one client getting an error to one client having its leased state abruptly and unexpectedly canceled.
o 该字符串应该是唯一的，以便多个客户端不显示相同的字符串。两个客户端呈现相同字符串的后果从一个客户端出错到一个客户端的租用状态突然意外取消。
o The string should be selected so the subsequent incarnations (e.g., reboots) of the same client cause the client to present the same string. The implementer is cautioned against an approach that requires the string to be recorded in a local file because this precludes the use of the implementation in an environment where there is no local disk and all file access is from an NFSv4 server.
o 应选择该字符串，以便同一客户端的后续化身（例如，重新启动）使客户端呈现相同的字符串。提醒实现者不要使用要求将字符串记录在本地文件中的方法，因为这会妨碍在没有本地磁盘且所有文件访问都来自NFSv4服务器的环境中使用实现。
o The string should be different for each server network address that the client accesses, rather than common to all server network addresses. The reason is that it may not be possible for the client to tell if the same server is listening on multiple network addresses. If the client issues SETCLIENTID with the same id string to each network address of such a server, the server will think it is the same client, and each successive SETCLIENTID will cause the server to begin the process of removing the client's previous leased state.
o 对于客户端访问的每个服务器网络地址，字符串应该是不同的，而不是所有服务器网络地址的公共字符串。原因是客户端可能无法判断同一服务器是否正在侦听多个网络地址。如果客户机向此类服务器的每个网络地址发出具有相同id字符串的SETCLIENTID，则服务器将认为它是同一个客户机，并且每个连续的SETCLIENTID将导致服务器开始删除客户机以前的租用状态。
o The algorithm for generating the string should not assume that the client's network address won't change. This includes changes between client incarnations and even changes while the client is still running in its current incarnation. This means that if the client includes just the client's and server's network address in
o 生成字符串的算法不应假定客户端的网络地址不会改变。这包括客户端化身之间的更改，甚至在客户端仍在当前化身中运行时的更改。这意味着，如果客户端仅包括客户端和服务器的网络地址
the id string, there is a real risk, after the client gives up the network address, that another client, using a similar algorithm for generating the id string, will generate a conflicting id string.
id字符串，在客户端放弃网络地址后，另一个客户端使用类似的算法生成id字符串，将生成冲突的id字符串，这是一个真正的风险。
Given the above considerations, an example of a well-generated id string is one that includes:
鉴于上述考虑，生成良好的id字符串示例包括：
o The server's network address.
o 服务器的网络地址。
o The client's network address.
o 客户端的网络地址。
o For a user-level NFSv4 client, it should contain additional information to distinguish the client from other user-level clients running on the same host, such as a universally unique identifier (UUID).
o 对于用户级NFSv4客户机，它应该包含其他信息，以便将客户机与运行在同一主机上的其他用户级客户机区分开来，例如通用唯一标识符（UUID）。
o Additional information that tends to be unique, such as one or more of:
o 倾向于唯一的附加信息，例如一个或多个：
* The client machine's serial number (for privacy reasons, it is best to perform some one-way function on the serial number).
* 客户端计算机的序列号（出于隐私原因，最好对序列号执行一些单向功能）。
* A MAC address (for privacy reasons, it is best to perform some one-way function on the MAC address).
* MAC地址（出于隐私考虑，最好在MAC地址上执行一些单向功能）。
* The timestamp of when the NFSv4 software was first installed on the client (though this is subject to the previously mentioned caution about using information that is stored in a file, because the file might only be accessible over NFSv4).
* NFSv4软件首次安装到客户端时的时间戳（尽管这取决于前面提到的关于使用存储在文件中的信息的注意事项，因为该文件可能只能通过NFSv4访问）。
* A true random number. However, since this number ought to be the same between client incarnations, this shares the same problem as that of using the timestamp of the software installation.
* 真随机数。然而，由于此数字在客户端化身之间应该是相同的，因此这与使用软件安装的时间戳的问题相同。
As a security measure, the server MUST NOT cancel a client's leased state if the principal that established the state for a given id string is not the same as the principal issuing the SETCLIENTID.
作为安全措施，如果为给定id字符串建立状态的主体与发出SETCLIENTID的主体不同，则服务器不得取消客户端的租用状态。
Note that SETCLIENTID (Section 16.33) and SETCLIENTID_CONFIRM (Section 16.34) have a secondary purpose of establishing the information the server needs to make callbacks to the client for the purpose of supporting delegations. It is permitted to change this information via SETCLIENTID and SETCLIENTID_CONFIRM within the same incarnation of the client without removing the client's leased state.
请注意，SETCLIENTID（第16.33节）和SETCLIENTID_CONFIRM（第16.34节）的第二个目的是建立服务器回调客户端以支持委托所需的信息。允许在客户端的同一版本中通过SETCLIENTID和SETCLIENTID_CONFIRM更改此信息，而无需删除客户端的已租用状态。
Once a SETCLIENTID and SETCLIENTID_CONFIRM sequence has successfully completed, the client uses the shorthand client identifier, of type clientid4, instead of the longer and less compact nfs_client_id4 structure. This shorthand client identifier (a client ID) is assigned by the server and should be chosen so that it will not conflict with a client ID previously assigned by the server. This applies across server restarts or reboots. When a client ID is presented to a server and that client ID is not recognized, as would happen after a server reboot, the server will reject the request with the error NFS4ERR_STALE_CLIENTID. When this happens, the client must obtain a new client ID by use of the SETCLIENTID operation and then proceed to any other necessary recovery for the server reboot case (see Section 9.6.2).
成功完成SETCLIENTID和SETCLIENTID_确认序列后，客户端将使用ClientD4类型的速记客户端标识符，而不是较长且不太紧凑的nfs_client_id4结构。此速记客户端标识符（客户端ID）由服务器分配，应进行选择，以使其不会与服务器先前分配的客户端ID冲突。这适用于服务器重新启动或重新启动。当客户机ID显示给服务器，而该客户机ID无法识别时（服务器重新启动后会发生这种情况），服务器将拒绝请求，错误为NFS4ERR\u STALE\u CLIENTID。发生这种情况时，客户端必须通过使用SETCLIENTID操作获得新的客户端ID，然后进行服务器重新启动情况下的任何其他必要恢复（请参阅第9.6.2节）。
The client must also employ the SETCLIENTID operation when it receives an NFS4ERR_STALE_STATEID error using a stateid derived from its current client ID, since this also indicates a server reboot, which has invalidated the existing client ID (see Section 9.6.2 for details).
当客户端使用从其当前客户端ID派生的STATEID接收到NFS4ERR_STALE_STATEID错误时，还必须使用SETCLIENTID操作，因为这也表示服务器重新启动，导致现有客户端ID无效（有关详细信息，请参阅第9.6.2节）。
See the detailed descriptions of SETCLIENTID (Section 16.33.4) and SETCLIENTID_CONFIRM (Section 16.34.4) for a complete specification of the operations.
有关操作的完整规范，请参见SETCLIENTID（第16.33.4节）和SETCLIENTID_CONFIRM（第16.34.4节）的详细说明。
If the server determines that the client holds no associated state for its client ID, the server may choose to release the client ID. The server may make this choice for an inactive client so that resources are not consumed by those intermittently active clients. If the client contacts the server after this release, the server must ensure that the client receives the appropriate error so that it will use the SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new identity. It should be clear that the server must be very hesitant to release a client ID since the resulting work on the client to recover from such an event will be the same burden as if the server had failed and restarted. Typically, a server would not release a client ID unless there had been no activity from that client for many minutes.
如果服务器确定客户机没有其客户机ID的关联状态，则服务器可以选择释放客户机ID。服务器可以对非活动客户机进行此选择，以便这些间歇性活动的客户机不会占用资源。如果客户机在此版本后联系服务器，服务器必须确保客户机收到适当的错误，以便使用SETCLIENTID/SETCLIENTID_确认序列来建立新标识。应该清楚的是，服务器在释放客户机ID时一定会非常犹豫，因为在客户机上从此类事件中恢复的结果工作将与服务器发生故障并重新启动时的负担相同。通常，服务器不会释放客户机ID，除非该客户机在几分钟内没有任何活动。
Note that if the id string in a SETCLIENTID request is properly constructed, and if the client takes care to use the same principal for each successive use of SETCLIENTID, then, barring an active denial-of-service attack, NFS4ERR_CLID_INUSE should never be returned.
请注意，如果SETCLIENTID请求中的id字符串构造正确，并且如果客户端注意在每次连续使用SETCLIENTID时使用相同的主体，则除非发生主动拒绝服务攻击，否则不应返回NFS4ERR_CLID_INUSE。
However, client bugs, server bugs, or perhaps a deliberate change of the principal owner of the id string (such as the case of a client that changes security flavors, and under the new flavor there is no mapping to the previous owner) will in rare cases result in NFS4ERR_CLID_INUSE.
但是，客户端错误、服务器错误，或者故意更改id字符串的主要所有者（例如更改安全风格的客户端，在新风格下没有映射到以前的所有者）在极少数情况下会导致NFS4ERR_CLID_使用。
In that event, when the server gets a SETCLIENTID for a client ID that currently has no state, or it has state but the lease has expired, rather than returning NFS4ERR_CLID_INUSE, the server MUST allow the SETCLIENTID and confirm the new client ID if followed by the appropriate SETCLIENTID_CONFIRM.
在这种情况下，当服务器获取当前没有状态的客户端ID的SETCLIENTID，或者它有状态但租约已过期，而不是返回NFS4ERR_CLID_INUSE时，服务器必须允许SETCLIENTID并确认新的客户端ID（如果后跟相应的SETCLIENTID_confirm）。
In several contexts, 32-bit sequence values called "seqids" are used as part of managing locking state. Such values are used:
在一些上下文中，称为“seqid”的32位序列值用作管理锁定状态的一部分。使用以下值：
o To provide an ordering of locking-related operations associated with a particular lock-owner or open-owner. See Section 9.1.7 for a detailed explanation.
o 提供与特定锁所有者或打开所有者相关的锁相关操作的顺序。详细说明见第9.1.7节。
o To define an ordered set of instances of a set of locks sharing a particular set of ownership characteristics. See Section 9.1.4.2 for a detailed explanation.
o 定义共享一组特定所有权特征的一组锁的有序实例集。详细说明见第9.1.4.2节。
Successive seqid values for the same object are normally arrived at by incrementing the current value by one. This pattern continues until the seqid is incremented past NFS4_UINT32_MAX, in which case one (rather than zero) is to be the next seqid value.
同一对象的连续seqid值通常是通过将当前值增加1来获得的。此模式持续，直到seqid增加超过NFS4_UINT32_MAX，在这种情况下，一个（而不是零）将成为下一个seqid值。
When two seqid values are to be compared to determine which of the two is later, the possibility of wraparound needs to be considered. In many cases, the values are such that simple numeric comparisons can be used. For example, if the seqid values to be compared are both less than one million, the higher value can be considered the later. On the other hand, if one of the values is at or near NFS_UINT32_MAX and the other is less than one million, then implementations can reasonably decide that the lower value has had one more wraparound and is thus, while numerically lower, actually later.
当比较两个seqid值以确定哪一个更晚时，需要考虑环绕的可能性。在许多情况下，这些值可以使用简单的数字比较。例如，如果要比较的seqid值都小于一百万，则可以认为较高的值较低。另一方面，如果其中一个值等于或接近NFS_UINT32_MAX，而另一个值小于一百万，则实现可以合理地确定较低的值多了一个概括值，因此，虽然数值较低，但实际上是在以后。
Implementations can compare seqids in the presence of potential wraparound by adopting the reasonable assumption that the chain of increments from one to the other is shorter than 2**31. So, if the difference between the two seqids is less than 2**31, then the lower seqid is to be treated as earlier. If, however, the difference
通过采用从一个到另一个的增量链小于2**31的合理假设，实现可以在存在潜在概括的情况下比较SeqID。因此，如果两个seqid之间的差值小于2**31，则较低的seqid将被视为较早的值。但是，如果差异
between the two seqids is greater than or equal to 2**31, then it can be assumed that the lower seqid has encountered one more wraparound and can be treated as later.
如果两个seqid之间的值大于或等于2**31，则可以假设较低的seqid遇到了一个以上的环绕，并且可以稍后处理。
When the server grants a lock of any type (including opens, byte-range locks, and delegations), it responds with a unique stateid that represents a set of locks (often a single lock) for the same file, of the same type, and sharing the same ownership characteristics. Thus, opens of the same file by different open-owners each have an identifying stateid. Similarly, each set of byte-range locks on a file owned by a specific lock-owner has its own identifying stateid. Delegations also have associated stateids by which they may be referenced. The stateid is used as a shorthand reference to a lock or set of locks, and given a stateid, the server can determine the associated state-owner or state-owners (in the case of an open-owner/lock-owner pair) and the associated filehandle. When stateids are used, the current filehandle must be the one associated with that stateid.
当服务器授予任何类型的锁（包括打开、字节范围锁和委派）时，它将使用唯一的stateid进行响应，该stateid表示同一文件、同一类型和共享相同所有权特征的一组锁（通常是单个锁）。因此，由不同的打开所有者打开的同一个文件都有一个标识stateid。类似地，特定锁所有者拥有的文件上的每一组字节范围锁都有自己的标识stateid。代表团还具有相关的StateID，可通过该ID引用代表团。stateid用作一个锁或一组锁的简写引用，并且给定stateid，服务器可以确定关联的一个或多个状态所有者（在打开所有者/锁所有者对的情况下）和关联的文件句柄。使用stateid时，当前文件句柄必须是与该stateid关联的文件句柄。
All stateids associated with a given client ID are associated with a common lease that represents the claim of those stateids and the objects they represent to be maintained by the server. See Section 9.5 for a discussion of the lease.
与给定客户机ID关联的所有StateID都与一个公共租约关联，该租约表示这些StateID及其表示的要由服务器维护的对象的声明。有关租赁的讨论，请参见第9.5节。
Each stateid must be unique to the server. Many operations take a stateid as an argument but not a clientid, so the server must be able to infer the client from the stateid.
每个stateid对于服务器都必须是唯一的。许多操作将stateid作为参数，而不是clientid，因此服务器必须能够从stateid推断客户机。
With the exception of special stateids (see Section 9.1.4.3), each stateid represents locking objects of one of a set of types defined by the NFSv4 protocol. Note that in all these cases, where we speak of a guarantee, it is understood there are situations such as a client restart, or lock revocation, that allow the guarantee to be voided.
除特殊stateid（见第9.1.4.3节）外，每个stateid表示NFSv4协议定义的一组类型之一的锁定对象。请注意，在所有这些情况下，当我们谈到担保时，可以理解存在允许担保无效的情况，例如客户端重新启动或锁撤销。
o Stateids may represent opens of files.
o StateID可以表示打开的文件。
Each stateid in this case represents the OPEN state for a given client ID/open-owner/filehandle triple. Such stateids are subject to change (with consequent incrementing of the stateid's seqid) in response to OPENs that result in upgrade and OPEN_DOWNGRADE operations.
本例中的每个stateid表示给定客户机ID/开放所有者/filehandle三元组的开放状态。此类stateid可能会随着导致升级和OPEN\u降级操作的打开而更改（随后stateid的seqid会增加）。
o Stateids may represent sets of byte-range locks.
o StateID可以表示字节范围锁的集合。
All locks held on a particular file by a particular owner and all gotten under the aegis of a particular open file are associated with a single stateid, with the seqid being incremented whenever LOCK and LOCKU operations affect that set of locks.
特定所有者持有的特定文件上的所有锁以及在特定打开文件的保护下获得的所有锁都与单个stateid关联，只要锁和LOCKU操作影响到该组锁，seqid就会增加。
o Stateids may represent file delegations, which are recallable guarantees by the server to the client that other clients will not reference, or will not modify, a particular file until the delegation is returned.
o StateID可以表示文件委托，这是服务器向客户机提供的可收回保证，在委托返回之前，其他客户机不会引用或修改特定文件。
A stateid represents a single delegation held by a client for a particular filehandle.
stateid表示客户端为特定文件句柄持有的单个委托。
Stateids are divided into two fields: a 96-bit "other" field identifying the specific set of locks and a 32-bit "seqid" sequence value. Except in the case of special stateids (see Section 9.1.4.3), a particular value of the "other" field denotes a set of locks of the same type (for example, byte-range locks, opens, or delegations), for a specific file or directory, and sharing the same ownership characteristics. The seqid designates a specific instance of such a set of locks, and is incremented to indicate changes in such a set of locks, by either the addition or deletion of locks from the set, a change in the byte-range they apply to, or an upgrade or downgrade in the type of one or more locks.
StateID分为两个字段：一个96位的“other”字段标识特定的锁集，另一个32位的“seqid”序列值。除特殊StateID（见第9.1.4.3节）外，“其他”字段的特定值表示一组相同类型的锁（例如，字节范围锁、打开或委托），用于特定文件或目录，并共享相同的所有权特征。seqid指定此类锁集合的特定实例，并通过从集合中添加或删除锁、更改其应用的字节范围或升级或降级一个或多个锁的类型来递增以指示此类锁集合中的更改。
When such a set of locks is first created, the server returns a stateid with a seqid value of one. On subsequent operations that modify the set of locks, the server is required to advance the seqid field by one whenever it returns a stateid for the same state-owner/file/type combination and the operation is one that might make some change in the set of locks actually designated. In this case, the server will return a stateid with an "other" field the same as previously used for that state-owner/file/type combination, with an incremented seqid field.
当第一次创建这样一组锁时，服务器返回一个seqid值为1的stateid。在修改锁集的后续操作中，每当服务器返回同一状态所有者/文件/类型组合的stateid时，服务器都需要将seqid字段提前1，并且该操作可能会对实际指定的锁集进行一些更改。在这种情况下，服务器将返回一个stateid，其中包含一个“other”字段，该字段与之前用于该状态所有者/文件/类型组合的字段相同，并包含一个递增的seqid字段。
Seqids will be compared, by both the client and the server. The client uses such comparisons to determine the order of operations, while the server uses them to determine whether the NFS4ERR_OLD_STATEID error is to be returned. In all cases, the possibility of seqid wraparound needs to be taken into account, as discussed in Section 9.1.3.
SeqID将由客户端和服务器进行比较。客户端使用这种比较来确定操作顺序，而服务器使用它们来确定是否返回NFS4ERR_OLD_STATEID错误。在所有情况下，如第9.1.3节所述，需要考虑seqid环绕的可能性。
Stateid values whose "other" field is either all zeros or all ones are reserved. They MUST NOT be assigned by the server but have special meanings defined by the protocol. The particular meaning depends on whether the "other" field is all zeros or all ones and the specific value of the seqid field.
“其他”字段为全零或全1的Stateid值被保留。它们不能由服务器分配，但具有协议定义的特殊含义。具体含义取决于“其他”字段是全零还是全1以及seqid字段的具体值。
The following combinations of "other" and seqid are defined in NFSv4:
NFSv4中定义了以下“其他”和seqid的组合：
Anonymous Stateid: When "other" and seqid are both zero, the stateid is treated as a special anonymous stateid, which can be used in READ, WRITE, and SETATTR requests to indicate the absence of any open state associated with the request. When an anonymous stateid value is used, and an existing open denies the form of access requested, then access will be denied to the request.
Anonymous Stateid：当“other”和seqid均为零时，Stateid被视为一个特殊的匿名Stateid，可在读、写和SETATTR请求中使用，以指示不存在与请求相关的任何打开状态。当使用匿名stateid值，并且现有的open拒绝请求的访问形式时，将拒绝对请求的访问。
READ Bypass Stateid: When "other" and seqid are both all ones, the stateid is a special READ bypass stateid. When this value is used in WRITE or SETATTR, it is treated like the anonymous value. When used in READ, the server MAY grant access, even if access would normally be denied to READ requests.
读取旁路Stateid：当“other”和seqid都是1时，Stateid是一个特殊的读取旁路Stateid。在WRITE或SETATTR中使用此值时，它将被视为匿名值。在读取中使用时，服务器可能会授予访问权限，即使对读取请求的访问通常会被拒绝。
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 MUST return the error NFS4ERR_BAD_STATEID.
如果使用的stateid值在“other”字段中为全零或全一，但与上述情况之一不匹配，则服务器必须返回错误NFS4ERR_BAD_stateid。
Special stateids, unlike other stateids, are not associated with individual client IDs or filehandles and can be used with all valid client IDs and filehandles.
与其他StateID不同，特殊StateID与单个客户端ID或文件句柄不关联，可以与所有有效的客户端ID和文件句柄一起使用。
Stateids must remain valid until either a client restart or a server restart, or until the client returns all of the locks associated with the stateid by means of an operation such as CLOSE or DELEGRETURN. If the locks are lost due to revocation, as long as the client ID is valid, the stateid remains a valid designation of that revoked state. Stateids associated with byte-range locks are an exception. They remain valid even if a LOCKU frees all remaining locks, so long as the open file with which they are associated remains open.
stateid必须保持有效，直到客户端重新启动或服务器重新启动，或者直到客户端通过关闭或删除返回与stateid关联的所有锁。如果锁因吊销而丢失，只要客户端ID有效，stateid仍然是该吊销状态的有效指定。与字节范围锁关联的StateID是一个例外。即使锁释放了所有剩余的锁，只要与它们关联的打开文件保持打开状态，它们仍然有效。
It should be noted that there are situations in which the client's locks become invalid, without the client requesting they be returned. These include lease expiration and a number of forms of lock revocation within the lease period. It is important to note that in these situations, the stateid remains valid and the client can use it to determine the disposition of the associated lost locks.
应该注意的是，在某些情况下，客户机的锁变得无效，而客户机没有请求返回这些锁。这些措施包括租赁到期和租赁期内多种形式的锁撤销。需要注意的是，在这些情况下，stateid仍然有效，客户端可以使用它来确定相关丢失锁的处置。
An "other" value must never be reused for a different purpose (i.e., different filehandle, owner, or type of locks) within the context of 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 it does so, it must maintain seqid continuity with previous values.
在单个客户端ID的上下文中，“其他”值决不能用于不同的目的（即不同的文件句柄、所有者或锁类型）。服务器可能会出于相同的目的保留“其他”值，但如果这样做，则必须与以前的值保持seqid连续性。
One mechanism that may be used to satisfy the requirement that the server recognize invalid and out-of-date stateids is for the server to divide the "other" field of the stateid into two fields:
可用于满足服务器识别无效和过期stateid要求的一种机制是，服务器将stateid的“其他”字段分为两个字段：
o An index into a table of locking-state structures.
o 锁定状态结构表的索引。
o A generation number that is incremented on each allocation of a table entry for a particular use.
o 一种生成编号，在为特定用途分配表项时递增。
And then store the following in each table entry:
然后在每个表条目中存储以下内容：
o The client ID with which the stateid is associated.
o 与stateid关联的客户端ID。
o The current generation number for the (at most one) valid stateid sharing this index value.
o 共享此索引值的有效stateid（最多一个）的当前生成号。
o The filehandle of the file on which the locks are taken.
o 对其进行锁定的文件的filehandle。
o An indication of the type of stateid (open, byte-range lock, file delegation).
o stateid类型的指示（打开、字节范围锁定、文件委派）。
o The last seqid value returned corresponding to the current "other" value.
o 返回的最后一个seqid值与当前“其他”值相对应。
o An indication of the current status of the locks associated with this stateid -- in particular, whether these have been revoked and, if so, for what reason.
o 指示与此stateid关联的锁的当前状态，特别是这些锁是否已被撤销，如果已撤销，原因是什么。
With this information, an incoming stateid can be validated and the appropriate error returned when necessary. Special and non-special stateids are handled separately. (See Section 9.1.4.3 for a discussion of special stateids.)
有了这些信息，可以验证传入的stateid，并在必要时返回相应的错误。特殊和非特殊stateID分别处理。（有关特殊状态ID的讨论，请参见第9.1.4.3节。）
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 combination for a special stateid is done and the results determined as follows:
当测试stateid时，“其他”字段为全零或全1，检查“其他”和seqid字段是否与特殊stateid的定义组合匹配，结果确定如下：
o If the "other" and seqid fields do not match a defined combination associated with a special stateid, the error NFS4ERR_BAD_STATEID is returned.
o 如果“other”和seqid字段不匹配与特殊stateid关联的已定义组合，则返回错误NFS4ERR_BAD_stateid。
o 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 stateid is used when an open stateid is required in a LOCK operation), the error NFS4ERR_BAD_STATEID is also returned.
o 如果组合通常有效，但不适用于使用stateid的上下文（例如，当锁操作中需要打开stateid时使用全零stateid），则还将返回错误NFS4ERR_BAD_stateid。
o Otherwise, the check is completed and the special stateid is accepted as valid.
o 否则，检查将完成，并且特殊stateid将被接受为有效。
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 an incoming stateid and return an appropriate error, when necessary, assuming that the "other" field would be divided into a table index and an entry generation. Note that the terms "earlier" and "later" used in connection with seqid comparison are to be understood as explained in Section 9.1.3.
当测试stateid时，“other”字段既不是全零也不是全1，可以使用以下过程验证传入的stateid并在必要时返回适当的错误，假设“other”字段将被划分为表索引和条目生成。请注意，与seqid比较相关的术语“较早”和“较晚”应理解为第9.1.3节中的解释。
o If the table index field is outside the range of the associated table, return NFS4ERR_BAD_STATEID.
o 如果表索引字段不在关联表的范围内，则返回NFS4ERR\u BAD\u STATEID。
o If the selected table entry is of a different generation than that specified in the incoming stateid, return NFS4ERR_BAD_STATEID.
o 如果所选表项的生成与传入stateid中指定的不同，则返回NFS4ERR\u BAD\u stateid。
o If the selected table entry does not match the current filehandle, return NFS4ERR_BAD_STATEID.
o 如果所选表项与当前文件句柄不匹配，则返回NFS4ERR\U BAD\U STATEID。
o If the stateid represents revoked state or state lost as a result of lease expiration, then return NFS4ERR_EXPIRED, NFS4ERR_BAD_STATEID, or NFS4ERR_ADMIN_REVOKED, as appropriate.
o 如果stateid表示吊销状态或由于租约到期而丢失的状态，则根据需要返回NFS4ERR_EXPIRED、NFS4ERR_BAD_stateid或NFS4ERR_ADMIN_reversed。
o If the stateid type is not valid for the context in which the stateid appears, return NFS4ERR_BAD_STATEID. Note that a stateid may be valid in general but invalid for a particular operation, as, for 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 stateid that does not represent an open is passed to CLOSE or OPEN_DOWNGRADE. In such cases, the server MUST return NFS4ERR_BAD_STATEID.
o 如果stateid类型对于stateid出现的上下文无效，则返回NFS4ERR\u BAD\u stateid。请注意，stateid通常有效，但对于特定操作无效，例如，当不表示字节范围锁的stateid传递给非from\u open LOCK或to LOCKU时，或者当不表示open的stateid传递给CLOSE或open\u降级时。在这种情况下，服务器必须返回NFS4ERR_BAD_STATEID。
o If the seqid field is not zero and it is later than the current sequence value corresponding to the current "other" field, return NFS4ERR_BAD_STATEID.
o 如果seqid字段不为零且晚于当前“其他”字段对应的当前序列值，则返回NFS4ERR_BAD_STATEID。
o If the seqid field is earlier than the current sequence value corresponding to the current "other" field, return NFS4ERR_OLD_STATEID.
o 如果seqid字段早于当前“其他”字段对应的当前序列值，则返回NFS4ERR_OLD_STATEID。
o Otherwise, the stateid is valid, and the table entry should contain any additional information about the type of stateid and information associated with that particular type of stateid, such as the associated set of locks (e.g., open-owner and lock-owner information), as well as information on the specific locks themselves, such as open modes and byte ranges.
o 否则，stateid是有效的，并且表条目应该包含关于stateid类型的任何附加信息以及与特定类型的stateid关联的信息，例如关联的锁集（例如，打开的所有者和锁所有者信息），以及关于特定锁本身的信息，例如打开模式和字节范围。
Clients performing Input/Output (I/O) operations need to select an appropriate stateid based on the locks (including opens and delegations) held by the client and the various types of state-owners sending the I/O requests. SETATTR operations that change the file size are treated like I/O operations in this regard.
执行输入/输出（I/O）操作的客户端需要根据客户端持有的锁（包括打开和委托）以及发送I/O请求的各种类型的状态所有者选择适当的stateid。在这方面，更改文件大小的SETATTR操作被视为I/O操作。
The following rules, applied in order of decreasing priority, govern the selection of the appropriate stateid. In following these rules, the client will only consider locks of which it has actually received notification by an appropriate operation response or callback.
以下规则按优先级降低的顺序应用，用于管理适当stateid的选择。在遵循这些规则时，客户端只考虑通过实际操作响应或回调实际接收到通知的锁。
o If the client holds a delegation for the file in question, the delegation stateid SHOULD be used.
o 如果客户机持有相关文件的委托，则应使用委托stateid。
o 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 associated open file, then the byte-range lock stateid for that lock-owner and open file SHOULD be used.
o 否则，如果与发送I/O的锁所有者（例如，进程）对应的实体具有关联打开文件的字节范围lock stateid，则应使用该锁所有者和打开文件的字节范围lock stateid。
o If there is no byte-range lock stateid, then the OPEN stateid for the current open-owner, i.e., the OPEN stateid for the open file in question, SHOULD be used.
o 如果没有字节范围锁定stateid，则应使用当前打开所有者的打开stateid，即相关打开文件的打开stateid。
o Finally, if none of the above apply, then a special stateid SHOULD be used.
o 最后，如果上述任何一项都不适用，那么应该使用一个特殊的stateid。
Ignoring these rules may result in situations in which the server does not have information necessary to properly process the request. For example, when mandatory byte-range locks are in effect, if the stateid does not indicate the proper lock-owner, via a lock stateid, a request might be avoidably rejected.
忽略这些规则可能会导致服务器没有正确处理请求所需的信息。例如，当强制字节范围锁生效时，如果stateid没有通过lock stateid指示正确的锁所有者，则请求可能会被拒绝。
The server, however, should not try to enforce these ordering rules and should use whatever information is available to properly process I/O requests. In particular, when a client has a delegation for a given file, it SHOULD take note of this fact in processing a request, even if it is sent with a special stateid.
但是，服务器不应尝试强制执行这些排序规则，而应使用任何可用信息来正确处理I/O请求。特别是，当客户机对给定文件具有委托时，它应该在处理请求时注意这一事实，即使请求是使用特殊的stateid发送的。
In the case of SETATTR operations, a stateid is present. In cases other than those that set the file size, the client may send either a special stateid or, when a delegation is held for the file in question, a delegation stateid. While the server SHOULD validate the stateid and may use the stateid to optimize the determination as to whether a delegation is held, it SHOULD note the presence of a delegation even when a special stateid is sent, and MUST accept a valid delegation stateid when sent.
在SETATTR操作的情况下，存在stateid。在设置文件大小的情况之外的情况下，客户机可以发送特殊的stateid，或者在为相关文件保留委托时，发送委托stateid。虽然服务器应验证stateid，并可使用stateid优化是否保留委派的确定，但即使发送了特殊stateid，也应注意委派的存在，并且在发送时必须接受有效的委派stateid。
When requesting a lock, the client must present to the server the client ID and an identifier for the owner of the requested lock. These two fields comprise the lock-owner and are defined as follows:
请求锁时，客户端必须向服务器提供客户端ID和请求锁所有者的标识符。这两个字段构成锁所有者，定义如下：
o A client ID returned by the server as part of the client's use of the SETCLIENTID operation.
o 作为客户端使用SETCLIENTID操作的一部分，服务器返回的客户端ID。
o A variable-length opaque array used to uniquely define the owner of a lock managed by the client.
o 可变长度不透明数组，用于唯一定义由客户端管理的锁的所有者。
This may be a thread id, process id, or other unique value.
这可能是线程id、进程id或其他唯一值。
When the server grants the lock, it responds with a unique stateid. The stateid is used as a shorthand reference to the lock-owner, since the server will be maintaining the correspondence between them.
当服务器授予锁时，它将使用唯一的stateid进行响应。stateid用作锁所有者的简写引用，因为服务器将维护它们之间的通信。
All READ, WRITE, and SETATTR operations contain a stateid. For the purposes of this section, SETATTR operations that change the size attribute of a file are treated as if they are writing the area between the old and new size (i.e., the range truncated or added to the file by means of the SETATTR), even where SETATTR is not explicitly mentioned in the text. The stateid passed to one of these operations must be one that represents an OPEN (e.g., via the open-owner), a set of byte-range locks, or a delegation, or it may be a special stateid representing anonymous access or the READ bypass stateid.
所有读、写和SETATTR操作都包含stateid。在本节中，更改文件大小属性的SETATTR操作被视为写入新旧大小之间的区域（即通过SETATTR截断或添加到文件中的范围），即使文本中未明确提及SETATTR。传递给这些操作之一的stateid必须是表示打开（例如，通过打开的所有者）、一组字节范围锁或委派的stateid，也可以是表示匿名访问或读取旁路stateid的特殊stateid。
If the state-owner performs a READ or WRITE in a situation in which it has established a lock or share reservation on the server (any OPEN constitutes a share reservation), the stateid (previously returned by the server) must be used to indicate what locks, including both byte-range locks and share reservations, are held by the state-owner. If no state is established by the client -- either
如果状态所有者在其已在服务器上建立锁或共享保留的情况下执行读或写操作（任何打开都构成共享保留），则必须使用stateid（服务器先前返回的）来指示状态所有者持有哪些锁，包括字节范围锁和共享保留。如果客户端未建立任何状态，则
byte-range lock or share reservation -- the anonymous stateid is used. Regardless of whether an anonymous stateid or a stateid returned by the server is used, if there is a conflicting share reservation or mandatory byte-range lock held on the file, the server MUST refuse to service the READ or WRITE operation.
字节范围锁定或共享保留--使用匿名stateid。无论使用匿名stateid还是服务器返回的stateid，如果文件上存在冲突的共享保留或强制字节范围锁，服务器必须拒绝为读或写操作提供服务。
Share reservations are established by OPEN operations and by their nature are mandatory in that when the OPEN denies READ or WRITE operations, that denial results in such operations being rejected with error NFS4ERR_LOCKED. Byte-range locks may be implemented by the server as either mandatory or advisory, or the choice of mandatory or advisory behavior may be determined by the server on the basis of the file being accessed (for example, some UNIX-based servers support a "mandatory lock bit" on the mode attribute such that if set, byte-range locks are required on the file before I/O is possible). When byte-range locks are advisory, they only prevent the granting of conflicting lock requests and have no effect on READs or WRITEs. Mandatory byte-range locks, however, prevent conflicting I/O operations. When they are attempted, they are rejected with NFS4ERR_LOCKED. When the client gets NFS4ERR_LOCKED on a file it knows it has the proper share reservation for, it will need to issue a LOCK request on the region of the file that includes the region the I/O was to be performed on, with an appropriate locktype (i.e., READ*_LT for a READ operation, WRITE*_LT for a WRITE operation).
共享保留是由开放操作建立的，其性质是强制性的，因为当开放操作拒绝读或写操作时，该拒绝会导致此类操作被拒绝，并出现错误NFS4ERR_LOCKED。字节范围锁可由服务器实现为强制或建议，或者强制或建议行为的选择可由服务器根据所访问的文件确定（例如，一些基于UNIX的服务器支持“强制锁位”在mode属性上，如果设置了，则需要在文件上设置字节范围锁，然后才能进行I/O）。当字节范围锁是建议性的时，它们只会阻止授予冲突的锁请求，对读或写没有影响。但是，强制字节范围锁可防止I/O操作冲突。尝试这些操作时，会被拒绝并锁定NFS4ERR_。当客户端在其知道其具有适当的共享保留的文件上锁定NFS4ERR_时，它将需要在文件的区域上发出锁定请求，该区域包括要执行I/O的区域，并具有适当的锁定类型（即，读操作为READ*_LT，写操作为WRITE*_LT）。
With NFSv3, there was no notion of a stateid, so there was no way to tell if the application process of the client sending the READ or WRITE operation had also acquired the appropriate byte-range lock on the file. Thus, there was no way to implement mandatory locking. With the stateid construct, this barrier has been removed.
对于NFSv3，没有stateid的概念，因此无法判断发送读或写操作的客户端的应用程序进程是否也在文件上获得了适当的字节范围锁。因此，无法实现强制锁定。通过stateid构造，该障碍已被移除。
Note that for UNIX environments that support mandatory file locking, the distinction between advisory and mandatory locking is subtle. In fact, advisory and mandatory byte-range locks are exactly the same insofar as the APIs and requirements on implementation are concerned. If the mandatory lock attribute is set on the file, the server checks to see if the lock-owner has an appropriate shared (read) or exclusive (write) byte-range lock on the region it wishes to read or write to. If there is no appropriate lock, the server checks if there is a conflicting lock (which can be done by attempting to acquire the conflicting lock on behalf of the lock-owner and, if successful, release the lock after the READ or WRITE is done), and if there is, the server returns NFS4ERR_LOCKED.
请注意，对于支持强制文件锁定的UNIX环境，建议锁定和强制锁定之间的区别很微妙。事实上，就API和实现要求而言，建议和强制字节范围锁是完全相同的。如果在文件上设置了强制锁定属性，服务器将检查锁定所有者在其希望读取或写入的区域上是否具有适当的共享（读取）或独占（写入）字节范围锁定。如果没有合适的锁，服务器将检查是否存在冲突的锁（这可以通过代表锁所有者尝试获取冲突的锁来实现，如果成功，则在读取或写入完成后释放锁），如果存在，服务器将返回NFS4ERR_LOCKED。
For Windows environments, there are no advisory byte-range locks, so the server always checks for byte-range locks during I/O requests.
对于Windows环境，没有建议的字节范围锁，因此服务器在I/O请求期间始终检查字节范围锁。
Thus, the NFSv4 LOCK operation does not need to distinguish between advisory and mandatory byte-range locks. It is the NFSv4 server's processing of the READ and WRITE operations that introduces the distinction.
因此，NFSv4锁操作不需要区分建议锁和强制字节范围锁。正是NFSv4服务器对读写操作的处理引入了区别。
Every stateid other than the special stateid values noted in this section, whether returned by an OPEN-type operation (i.e., OPEN, OPEN_DOWNGRADE) or by a LOCK-type operation (i.e., LOCK or LOCKU), defines an access mode for the file (i.e., READ, WRITE, or READ-WRITE) as established by the original OPEN that began the stateid sequence, and as modified by subsequent OPENs and OPEN_DOWNGRADEs within that stateid sequence. When a READ, WRITE, or SETATTR that specifies the size attribute is done, the operation is subject to checking against the access mode to verify that the operation is appropriate given the OPEN with which the operation is associated.
除本节中注明的特殊stateid值外的每个stateid，无论是由开放式操作（即OPEN、OPEN_降级）还是由锁式操作（即LOCK或LOCKU）返回，都定义了由开始stateid序列的原始OPEN建立的文件访问模式（即读、写或读写），并在该stateid序列中通过后续OPEN和OPEN_降级进行修改。当完成指定大小属性的读、写或SETATTR时，该操作将根据访问模式进行检查，以验证该操作是否适合与该操作关联的打开项。
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 and return an NFS4ERR_OPENMODE error if it does not. In the case of READ, the server may perform the corresponding check on the access mode, or it may choose to allow READ on opens for WRITE only, to accommodate clients whose write implementation may unavoidably do reads (e.g., due to buffer cache constraints). However, even if READs are allowed in these circumstances, the server MUST still check for locks that conflict with the READ (e.g., another open specifying denial of READs). Note that a server that does enforce the access mode check on READs need not explicitly check for conflicting share reservations since the existence of OPEN for read access guarantees that no conflicting share reservation can exist.
对于写入类型操作（即设置大小的写入和设置属性），服务器必须验证访问模式是否允许写入，如果不允许，则返回NFS4ERR_OPENMODE错误。在读取的情况下，服务器可以对访问模式执行相应的检查，或者它可以选择允许仅为写而打开的读操作，以容纳其写实现可能不可避免地进行读取的客户端（例如，由于缓冲区缓存约束）。但是，即使在这些情况下允许读取，服务器仍必须检查与读取冲突的锁（例如，另一个open指定拒绝读取）。请注意，对读取执行访问模式检查的服务器不需要显式检查冲突的共享保留，因为开放式读取访问的存在保证不存在冲突的共享保留。
A READ bypass stateid MAY allow READ operations to bypass locking checks at the server. However, WRITE operations with a READ bypass stateid MUST NOT bypass locking checks and are treated exactly the same as if an anonymous stateid were used.
READ bypass stateid允许读取操作绕过服务器上的锁定检查。但是，具有读取旁路stateid的写入操作不能绕过锁定检查，并且被视为与使用匿名stateid时完全相同。
A lock may not be granted while a READ or WRITE operation using one of the special stateids is being performed and the range of the lock request conflicts with the range of the READ or WRITE operation. For the purposes of this paragraph, a conflict occurs when a shared lock is requested and a WRITE operation is being performed, or an exclusive lock is requested and either a READ or a WRITE operation is being performed. A SETATTR that sets size is treated similarly to a WRITE as discussed above.
在执行使用一个特殊StateID的读或写操作时，可能不会授予锁，并且锁请求的范围与读或写操作的范围冲突。在本段中，当请求共享锁并执行写入操作时，或请求独占锁并执行读取或写入操作时，会发生冲突。设置大小的SETATTR与上面讨论的写入类似。
Locking is different than most NFS operations as it requires "at-most-one" semantics that are not provided by ONC RPC. ONC RPC over a reliable transport is not sufficient because a sequence of locking requests may span multiple TCP connections. In the face of retransmission or reordering, lock or unlock requests must have a well-defined and consistent behavior. To accomplish this, each lock request contains a sequence number that is a consecutively increasing integer. Different state-owners have different sequences. The server maintains the last sequence number (L) received and the response that was returned. The server SHOULD assign a seqid value of one for the first request issued for any given state-owner. Subsequent values are arrived at by incrementing the seqid value, subject to wraparound as described in Section 9.1.3.
锁定与大多数NFS操作不同，因为它需要ONC RPC未提供的“最多一个”语义。可靠传输上的ONC RPC是不够的，因为一系列锁定请求可能跨越多个TCP连接。在面临重新传输或重新排序时，锁定或解锁请求必须具有定义良好且一致的行为。为了实现这一点，每个锁请求都包含一个连续递增的整数序列号。不同的国家所有者有不同的顺序。服务器维护接收到的最后一个序列号（L）和返回的响应。服务器应该为任何给定状态所有者发出的第一个请求分配一个seqid值1。后续值通过增加seqid值得出，并按照第9.1.3节所述进行概括。
Note that for requests that contain a sequence number, for each state-owner, there should be no more than one outstanding request.
请注意，对于包含序列号的请求，对于每个状态所有者，不应该有多个未完成的请求。
When a request is received, its sequence number (r) is compared to that of the last one received (L). Only if it has the correct next sequence, normally L + 1, is the request processed beyond the point of seqid checking. Given a properly functioning client, the response to (r) must have been received before the last request (L) was sent. If a duplicate of last request (r == L) is received, the stored response is returned. If the sequence value received is any other value, it is rejected with the return of error NFS4ERR_BAD_SEQID. Sequence history is reinitialized whenever the SETCLIENTID/ SETCLIENTID_CONFIRM sequence changes the client verifier.
当接收到一个请求时，将其序列号（r）与上次接收的序列号（L）进行比较。只有当它具有正确的下一个序列（通常为L+1）时，请求才会在seqid检查点之外被处理。如果客户端功能正常，则必须在发送最后一个请求（L）之前收到对（r）的响应。如果接收到上一个请求（r==L）的副本，则返回存储的响应。如果接收到的序列值是任何其他值，则拒绝该序列值，并返回错误NFS4ERR_BAD_SEQID。每当SETCLIENTID/SETCLIENTID\u确认序列更改客户端验证器时，序列历史将重新初始化。
It is critical that the server maintain the last response sent to the client to provide a more reliable cache of duplicate non-idempotent requests than that of the traditional cache described in [Chet]. The traditional duplicate request cache uses a least recently used algorithm for removing unneeded requests. However, the last lock request and response on a given state-owner must be cached as long as the lock state exists on the server.
与[Chet]中所述的传统缓存相比，服务器必须维护发送给客户端的最后一个响应，以便为重复的非幂等请求提供更可靠的缓存。传统的重复请求缓存使用最近最少使用的算法来删除不需要的请求。但是，只要服务器上存在锁状态，就必须缓存给定状态所有者上的最后一个锁请求和响应。
The client MUST advance the sequence number for the CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE operations. This is true even in the event that the previous operation that used the sequence number received an error. The only exception to this rule is if the previous operation received one of the following errors: NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID, NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR, NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE, or NFS4ERR_MOVED.
客户必须提前输入关闭、锁定、锁定、打开、打开确认和打开降级操作的序列号。即使在使用序列号的前一个操作收到错误的情况下也是如此。此规则的唯一例外是，如果上一个操作收到以下错误之一：NFS4ERR_STALE_CLIENTID、NFS4ERR_STALE_STATEID、NFS4ERR_BAD_STATEID、NFS4ERR_BAD_SEQID、NFS4ERR_BADXDR、NFS4ERR_RESOURCE、NFS4ERR_NOFILEHANDLE或NFS4ERR_MOVED。
As described above, the sequence number is per state-owner. As long as the server maintains the last sequence number received and follows the methods described above, there are no risks of a Byzantine router re-sending old requests. The server need only maintain the (state-owner, sequence number) state as long as there are open files or closed files with locks outstanding.
如上所述，序列号是每个州所有者的。只要服务器保持接收到的最后一个序列号并遵循上述方法，就不存在拜占庭式路由器重新发送旧请求的风险。只要存在未锁定的打开文件或关闭文件，服务器只需维护（状态所有者、序列号）状态。
LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, and CLOSE each contain a sequence number, and therefore the risk of the replay of these operations resulting in undesired effects is non-existent while the server maintains the state-owner state.
LOCK、LOCKU、OPEN、OPEN_降级和CLOSE每个都包含一个序列号，因此，在服务器保持状态所有者状态时，这些操作的重播导致不期望的效果的风险是不存在的。
Some operations may have multiple sources of data for request sequence checking and retransmission determination. Some operations have multiple sequence values associated with multiple types of state-owners. In addition, such operations may also have a stateid with its own seqid value, that will be checked for validity.
一些操作可能有多个数据源用于请求序列检查和重传确定。某些操作具有多个与多种类型的状态所有者关联的序列值。此外，此类操作还可能有一个stateid及其自身的seqid值，将对其有效性进行检查。
As noted above, there may be multiple sequence values to check. The following rules should be followed by the server in processing these multiple sequence values within a single operation.
如上所述，可能需要检查多个序列值。服务器在单个操作中处理这些多个序列值时应遵循以下规则。
o When a sequence value associated with a state-owner is unavailable for checking because the state-owner is unknown to the server, it takes no part in the comparison.
o 当与状态所有者关联的序列值因服务器未知而无法进行检查时，它将不参与比较。
o When any of the state-owner sequence values are invalid, NFS4ERR_BAD_SEQID is returned. When a stateid sequence is checked, NFS4ERR_BAD_STATEID or NFS4ERR_OLD_STATEID is returned as appropriate, but NFS4ERR_BAD_SEQID has priority.
o 当任何状态所有者序列值无效时，将返回NFS4ERR_BAD_SEQID。检查stateid序列时，会根据需要返回NFS4ERR_BAD_stateid或NFS4ERR_OLD_stateid，但NFS4ERR_BAD_SEQID具有优先级。
o When any one of the sequence values matches a previous request, for a state-owner, it is treated as a retransmission and not re-executed. When the type of the operation does not match that originally used, NFS4ERR_BAD_SEQID is returned. When the server can determine that the request differs from the original, it may return NFS4ERR_BAD_SEQID.
o 当序列值中的任何一个与前一个请求匹配时，对于状态所有者，它将被视为重传，而不是重新执行。当操作类型与最初使用的不匹配时，将返回NFS4ERR_BAD_SEQID。当服务器可以确定请求与原始请求不同时，它可能会返回NFS4ERR_BAD_SEQID。
o When multiple sequence values match previous operations but the operations are not the same, NFS4ERR_BAD_SEQID is returned.
o 当多个序列值与以前的操作匹配但操作不相同时，将返回NFS4ERR_BAD_SEQID。
o When there are no sequence values available for comparison and the operation is an OPEN, the server indicates to the client that an OPEN_CONFIRM is required, unless it can conclusively determine that confirmation is not required (e.g., by knowing that no open-owner state has ever been released for the current clientid).
o 当没有可用于比较的序列值且操作是开放的时，服务器向客户端指示需要开放的确认，除非它能够最终确定不需要确认（例如，通过知道当前clientid从未发布开放的所有者状态）。
When a particular state-owner no longer holds open or file locking state at the server, the server may choose to release the sequence number state associated with the state-owner. The server may make this choice based on lease expiration, the reclamation of server memory, or other implementation-specific details. Note that when this is done, a retransmitted request, normally identified by a matching state-owner sequence, may not be correctly recognized, so that the client will not receive the original response that it would have if the state-owner state was not released.
当特定状态所有者不再在服务器上保持打开或文件锁定状态时，服务器可以选择释放与状态所有者关联的序列号状态。服务器可以根据租约到期、服务器内存回收或其他特定于实现的详细信息进行选择。请注意，当完成此操作时，通常由匹配的状态所有者序列标识的重新传输请求可能无法正确识别，因此客户端将不会接收到在状态所有者状态未释放时将具有的原始响应。
If the server were able to be sure that a given state-owner would never again be used by a client, such an issue could not arise. Even when the state-owner state is released and the client subsequently uses that state-owner, retransmitted requests will be detected as invalid and the request not executed, although the client may have a recovery path that is more complicated than simply getting the original response back transparently.
如果服务器能够确保给定的状态所有者不再被客户端使用，那么就不会出现这样的问题。即使当状态所有者状态被释放并且客户端随后使用该状态所有者时，重新传输的请求也将被检测为无效且请求未执行，尽管客户端可能具有比简单透明地获取原始响应更复杂的恢复路径。
In any event, the server is able to safely release state-owner state (in the sense that retransmitted requests will not be erroneously acted upon) when the state-owner is not currently being utilized by the client (i.e., there are no open files associated with an open-owner and no lock stateids associated with a lock-owner). The server may choose to hold the state-owner state in order to simplify the recovery path, in the case in which retransmissions of currently active requests are received. However, the period for which it chooses to hold this state is implementation specific.
在任何情况下，当客户端当前未使用状态所有者时（即，没有与打开的所有者相关联的打开的文件，也没有与锁所有者相关联的锁stateids），服务器都能够安全地释放状态所有者状态（在某种意义上，不会错误地处理重新传输的请求）。在接收到当前活动请求的重传的情况下，服务器可以选择保持状态所有者状态以简化恢复路径。然而，它选择保持这种状态的期限是具体实施的。
In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is retransmitted after the server has previously released the state-owner state, the server will find that the state-owner has no files open and an error will be returned to the client. If the state-owner does have a file open, the stateid will not match and again an error is returned to the client.
如果在服务器先前释放状态所有者状态后重新传输锁定、锁定、打开降级或关闭，服务器将发现状态所有者没有打开的文件，并将向客户端返回错误。如果状态所有者确实打开了一个文件，则stateid将不匹配，并再次向客户端返回一个错误。
In the case that an OPEN is retransmitted and the open-owner is being used for the first time or the open-owner state has been previously released by the server, the use of the OPEN_CONFIRM operation will prevent incorrect behavior. When the server observes the use of the open-owner for the first time, it will direct the client to perform the OPEN_CONFIRM for the corresponding OPEN. This sequence establishes the use of an open-owner and associated sequence number. Since the OPEN_CONFIRM sequence connects a new open-owner on the server with an existing open-owner on a client, the sequence number may have any valid (i.e., non-zero) value. The OPEN_CONFIRM step assures the server that the value received is the correct one. (See Section 16.18 for further details.)
如果重新传输打开的文件，并且打开的所有者第一次被使用，或者服务器先前已释放打开的所有者状态，则使用打开确认操作将防止错误行为。当服务器第一次观察到OpenOwner的使用时，它将指示客户端对相应的OpenOwner执行OpenU确认。该序列确定了开放所有者和相关序列号的使用。由于OPEN_CONFIRM序列将服务器上的新开放所有者与客户端上的现有开放所有者连接起来，因此序列号可能具有任何有效（即非零）值。打开确认步骤可确保服务器收到的值是正确的。（详见第16.18节。）
There are a number of situations in which the requirement to confirm an OPEN would pose difficulties for the client and server, in that they would be prevented from acting in a timely fashion on information received, because that information would be provisional, subject to deletion upon non-confirmation. Fortunately, these are situations in which the server can avoid the need for confirmation when responding to open requests. The two constraints are:
在许多情况下，确认开放的要求会给客户机和服务器带来困难，因为它们无法及时处理收到的信息，因为这些信息是临时性的，在未确认时会被删除。幸运的是，在这些情况下，服务器可以避免在响应打开的请求时进行确认。这两个限制是：
o The server must not bestow a delegation for any open that would require confirmation.
o 服务器不得为任何需要确认的打开授予委派。
o The server MUST NOT require confirmation on a reclaim-type open (i.e., one specifying claim type CLAIM_PREVIOUS or CLAIM_DELEGATE_PREV).
o 服务器不得要求确认打开的回收类型（即指定索赔类型claim_PREVIOUS或claim_DELEGATE_PREV的类型）。
These constraints are related in that reclaim-type opens are the only ones in which the server may be required to send a delegation. For CLAIM_NULL, sending the delegation is optional, while for CLAIM_DELEGATE_CUR, no delegation is sent.
这些约束是相关的，因为回收类型是服务器可能需要发送委派的唯一约束。对于CLAIM_NULL，发送委派是可选的，而对于CLAIM_DELEGATE_CUR，不发送委派。
Delegations being sent with an open requiring confirmation are troublesome because recovering from non-confirmation adds undue complexity to the protocol, while requiring confirmation on reclaim-type opens poses difficulties in that the inability to resolve the status of the reclaim until lease expiration may make it difficult to have timely determination of the set of locks being reclaimed (since the grace period may expire).
发出要求确认的开放式授权的代表团很麻烦，因为从未确认中恢复会给协议增加不必要的复杂性，虽然要求确认回收类型打开会带来困难，因为在租约到期之前无法解决回收状态可能会导致难以及时确定要回收的锁集（因为宽限期可能到期）。
Requiring open confirmation on reclaim-type opens is avoidable because of the nature of the environments in which such opens are done. For CLAIM_PREVIOUS opens, this is immediately after server reboot, so there should be no time for open-owners to be created, found to be unused, and recycled. For CLAIM_DELEGATE_PREV opens,
由于执行此类打开的环境的性质，可以避免要求对回收类型打开进行打开确认。对于之前打开的声明，这是在服务器重新启动后立即打开的，因此应该没有时间创建、发现未使用和回收打开的所有者。对于索赔(委托)(上一页),，
we are dealing with either a client reboot situation or a network partition resulting in deletion of lease state (and returning NFS4ERR_EXPIRED). A server that supports delegations can be sure that no open-owners for that client have been recycled since client initialization or deletion of lease state and thus can be confident that confirmation will not be required.
我们正在处理导致租约状态删除（并返回NFS4ERR_EXPIRED）的客户端重新启动情况或网络分区。支持委托的服务器可以确保在客户端初始化或删除租约状态后，该客户端的开放所有者没有被回收，因此可以确信不需要确认。
The protocol allows a lock-owner to request a lock with a byte range and then either upgrade or unlock a sub-range of the initial lock. It is expected that this will be an uncommon type of request. In any case, servers or server file systems may not be able to support sub-range lock semantics. In the event that a server receives a locking request that represents a sub-range of current locking state for the lock-owner, the server is allowed to return the error NFS4ERR_LOCK_RANGE to signify that it does not support sub-range lock operations. Therefore, the client should be prepared to receive this error and, if appropriate, report the error to the requesting application.
该协议允许锁所有者请求具有字节范围的锁，然后升级或解锁初始锁的子范围。预计这将是一种不常见的请求类型。在任何情况下，服务器或服务器文件系统都可能无法支持子范围锁语义。如果服务器接收到表示锁所有者当前锁定状态子范围的锁定请求，则允许服务器返回错误NFS4ERR_lock_range，以表示它不支持子范围锁定操作。因此，客户机应该准备好接收此错误，并在适当的情况下向请求的应用程序报告此错误。
The client is discouraged from combining multiple independent locking ranges that happen to be adjacent into a single request, since the server may not support sub-range requests, and for reasons related to the recovery of file locking state in the event of server failure. As discussed in Section 9.6.2 below, the server may employ certain optimizations during recovery that work effectively only when the client's behavior during lock recovery is similar to the client's locking behavior prior to server failure.
由于服务器可能不支持子范围请求，并且由于与服务器故障时恢复文件锁定状态有关的原因，不鼓励客户端将碰巧相邻的多个独立锁定范围合并到单个请求中。如下文第9.6.2节所述，服务器可能在恢复期间采用某些优化，这些优化只有在锁定恢复期间的客户端行为与服务器故障之前的客户端锁定行为类似时才能有效工作。
If a client has a write lock on a record, it can request an atomic downgrade of the lock to a read lock via the LOCK request, by setting the type to READ_LT. If the server supports atomic downgrade, the request will succeed. If not, it will return NFS4ERR_LOCK_NOTSUPP. The client should be prepared to receive this error and, if appropriate, report the error to the requesting application.
如果客户机在记录上有写锁，它可以通过锁请求请求将锁的原子降级为读锁，方法是将类型设置为read\LT。如果服务器支持原子降级，则请求将成功。否则，它将返回NFS4ERR\u LOCK\u NOTSUPP。客户端应准备好接收此错误，并在适当的情况下向请求的应用程序报告此错误。
If a client has a read lock on a record, it can request an atomic upgrade of the lock to a write lock via the LOCK request by setting the type to WRITE_LT or WRITEW_LT. If the server does not support atomic upgrade, it will return NFS4ERR_LOCK_NOTSUPP. If the upgrade can be achieved without an existing conflict, the request will succeed. Otherwise, the server will return either NFS4ERR_DENIED or NFS4ERR_DEADLOCK. The error NFS4ERR_DEADLOCK is returned if the client issued the LOCK request with the type set to WRITEW_LT and the
如果客户机对记录具有读锁，则可以通过将类型设置为write_LT或WRITEW_LT，通过锁请求将锁的原子升级为写锁。如果服务器不支持原子升级，它将返回NFS4ERR_lock_NOTSUPP。如果可以在不存在冲突的情况下实现升级，则请求将成功。否则，服务器将返回NFS4ERR_DENIED或NFS4ERR_DEADLOCK。如果客户端发出类型设置为WRITEW_LT的锁请求，并且
server has detected a deadlock. The client should be prepared to receive such errors and, if appropriate, report them to the requesting application.
服务器检测到死锁。客户应做好接收此类错误的准备，并在适当情况下向请求的应用程序报告这些错误。
Some clients require the support of blocking locks. The NFSv4 protocol must not rely on a callback mechanism and therefore is unable to notify a client when a previously denied lock has been granted. Clients have no choice but to continually poll for the lock. This presents a fairness problem. Two new lock types are added, READW and WRITEW, and are used to indicate to the server that the client is requesting a blocking lock. The server should maintain an ordered list of pending blocking locks. When the conflicting lock is released, the server may wait the lease period for the first waiting client to re-request the lock. After the lease period expires, the next waiting client request is allowed the lock. Clients are required to poll at an interval sufficiently small that it is likely to acquire the lock in a timely manner. The server is not required to maintain a list of pending blocked locks, as it is not used to provide correct operation but only to increase fairness. Because of the unordered nature of crash recovery, storing of lock state to stable storage would be required to guarantee ordered granting of blocking locks.
有些客户机需要阻塞锁的支持。NFSv4协议不能依赖回调机制，因此无法在授予先前被拒绝的锁时通知客户端。客户端别无选择，只能不断轮询锁。这是一个公平问题。添加了两种新的锁类型READW和WRITEW，用于向服务器指示客户端正在请求阻塞锁。服务器应该维护挂起的阻塞锁的有序列表。当冲突锁被释放时，服务器可能会等待租约期，等待第一个等待的客户端重新请求锁。租赁期到期后，允许下一个等待的客户端请求锁定。客户端需要以足够小的间隔进行轮询，以便能够及时获取锁。服务器不需要维护挂起的阻塞锁列表，因为它不用于提供正确的操作，而仅用于提高公平性。由于崩溃恢复的无序性，需要将锁状态存储到稳定存储，以保证阻塞锁的有序授予。
Servers may also note the lock types and delay returning denial of the request to allow extra time for a conflicting lock to be released, allowing a successful return. In this way, clients can avoid the burden of needlessly frequent polling for blocking locks. The server should take care with the length of delay in the event that the client retransmits the request.
服务器还可能会注意到锁的类型，并延迟请求的返回拒绝，以允许释放冲突锁的额外时间，从而允许成功返回。这样，客户机就可以避免不必要的频繁轮询阻塞锁的负担。在客户端重新传输请求时，服务器应注意延迟的长度。
If a server receives a blocking lock request, denies it, and then later receives a non-blocking request for the same lock, which is also denied, then it should remove the lock in question from its list of pending blocking locks. Clients should use such a non-blocking request to indicate to the server that this is the last time they intend to poll for the lock, as may happen when the process requesting the lock is interrupted. This is a courtesy to the server, to prevent it from unnecessarily waiting a lease period before granting other lock requests. However, clients are not required to perform this courtesy, and servers must not depend on them doing so. Also, clients must be prepared for the possibility that this final locking request will be accepted.
如果服务器收到一个阻塞锁请求并拒绝它，然后又收到一个针对同一个锁的非阻塞请求（该请求也被拒绝），那么它应该将该锁从其挂起的阻塞锁列表中移除。客户端应该使用这样一个非阻塞请求来向服务器指示这是他们最后一次打算轮询锁，当请求锁的进程中断时可能会发生这种情况。这是对服务器的一种礼貌，以防止它在授予其他锁请求之前不必要地等待租用期。但是，客户机不需要执行这种礼节，服务器也不能依赖客户机这样做。此外，客户必须准备好接受最终锁定请求的可能性。
The purpose of a lease is to allow a server to remove stale locks that are held by a client that has crashed or is otherwise unreachable. It is not a mechanism for cache consistency, and lease renewals may not be denied if the lease interval has not expired.
租约的目的是允许服务器删除已崩溃或无法访问的客户端持有的过时锁。它不是缓存一致性的机制，如果租约间隔未过期，则租约续订可能不会被拒绝。
The client can implicitly provide a positive indication that it is still active and that the associated state held at the server, for the client, is still valid. Any operation made with a valid clientid (DELEGPURGE, LOCK, LOCKT, OPEN, RELEASE_LOCKOWNER, or RENEW) or a valid stateid (CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, READ, SETATTR, or WRITE) informs the server to renew all of the leases for that client (i.e., all those sharing a given client ID). In the latter case, the stateid must not be one of the special stateids (anonymous stateid or READ bypass stateid).
客户端可以隐式地提供一个积极的指示，表明它仍然处于活动状态，并且服务器上为客户端保留的关联状态仍然有效。使用有效的clientid（DELEGPURGE、LOCK、LOCKT、OPEN、RELEASE\u LOCKOWNER或RENEW）或有效的stateid（CLOSE、DELEGRETURN、LOCK、LOCKU、OPEN、OPEN\u CONFIRM、OPEN\u Degrade、READ、SETATTR或WRITE）执行的任何操作都会通知服务器续订该客户端的所有租约（即，所有共享给定客户端ID的人）。在后一种情况下，stateid不能是特殊stateid（匿名stateid或读取旁路stateid）之一。
Note that if the client had restarted or rebooted, the client would not be making these requests without issuing the SETCLIENTID/ SETCLIENTID_CONFIRM sequence. The use of the SETCLIENTID/ SETCLIENTID_CONFIRM sequence (one that changes the client verifier) notifies the server to drop the locking state associated with the client. SETCLIENTID/SETCLIENTID_CONFIRM never renews a lease.
请注意，如果客户端已重新启动或重新启动，则在未发出SETCLIENTID/SETCLIENTID_确认序列的情况下，客户端不会发出这些请求。使用SETCLIENTID/SETCLIENTID_确认序列（更改客户端验证器的序列）通知服务器放弃与客户端关联的锁定状态。SETCLIENTID/SETCLIENTID\u确认从不续订租约。
If the server has rebooted, the stateids (NFS4ERR_STALE_STATEID error) or the client ID (NFS4ERR_STALE_CLIENTID error) will not be valid, hence preventing spurious renewals.
如果服务器已重新启动，STATEID（NFS4ERR\u STALE\u STATEID错误）或客户端ID（NFS4ERR\u STALE\u CLIENTID错误）将无效，从而防止虚假续订。
This approach allows for low-overhead lease renewal, which scales well. In the typical case, no extra RPCs are required for lease renewal, and in the worst case, one RPC is required every lease period (i.e., a RENEW operation). The number of locks held by the client is not a factor since all state for the client is involved with the lease renewal action.
这种方法允许低管理费用的租赁续期，这可以很好地扩展。在典型情况下，续租不需要额外的RPC，在最坏的情况下，每个租赁期需要一个RPC（即续租操作）。客户端持有的锁的数量不是一个因素，因为客户端的所有状态都与租约续订操作有关。
Since all operations that create a new lease also renew existing leases, the server must maintain a common lease expiration time for all valid leases for a given client. This lease time can then be easily updated upon implicit lease renewal actions.
由于创建新租约的所有操作也会续订现有租约，因此服务器必须为给定客户端的所有有效租约维护一个公共租约到期时间。然后，可以根据隐式租约续订操作轻松更新此租约时间。
The important requirement in crash recovery is that both the client and the server know when the other has failed. Additionally, it is required that a client sees a consistent view of data across server restarts or reboots. All READ and WRITE operations that may have been queued within the client or network buffers must wait until the client has successfully recovered the locks protecting the READ and WRITE operations.
崩溃恢复的重要要求是，客户端和服务器都知道另一方何时出现故障。此外，要求客户端在服务器重新启动或重新启动时看到一致的数据视图。在客户端或网络缓冲区内排队的所有读写操作必须等待，直到客户端成功恢复保护读写操作的锁。
In the event that a client fails, the server may recover the client's locks when the associated leases have expired. Conflicting locks from another client may only be granted after this lease expiration. If the client is able to restart or reinitialize within the lease period, the client may be forced to wait the remainder of the lease period before obtaining new locks.
如果客户端出现故障，服务器可能会在相关租约过期时恢复客户端的锁。来自其他客户端的冲突锁只能在此租约到期后授予。如果客户端能够在租约期内重新启动或重新初始化，则客户端可能会被迫等待租约期的剩余时间，然后才能获得新锁。
To minimize client delay upon restart, open and lock requests are associated with an instance of the client by a client-supplied verifier. This verifier is part of the initial SETCLIENTID call made by the client. The server returns a client ID as a result of the SETCLIENTID operation. The client then confirms the use of the client ID with SETCLIENTID_CONFIRM. The client ID in combination with an opaque owner field is then used by the client to identify the open-owner for OPEN. This chain of associations is then used to identify all locks for a particular client.
为了最小化重启时的客户端延迟，打开和锁定请求由客户端提供的验证器与客户端实例相关联。此验证器是客户端进行的初始SETCLIENTID调用的一部分。服务器返回一个客户端ID作为SETCLIENTID操作的结果。然后，客户机使用SETCLIENTID\u CONFIRM确认客户机ID的使用。然后，客户机使用客户机ID和不透明所有者字段来标识open的open所有者。然后，该关联链用于标识特定客户端的所有锁。
Since the verifier will be changed by the client upon each initialization, the server can compare a new verifier to the verifier associated with currently held locks and determine that they do not match. This signifies the client's new instantiation and subsequent loss of locking state. As a result, the server is free to release all locks held that are associated with the old client ID that was derived from the old verifier.
由于客户端在每次初始化时都会更改验证器，因此服务器可以将新的验证器与与当前持有的锁关联的验证器进行比较，并确定它们不匹配。这表示客户端的新实例化和随后的锁定状态丢失。因此，服务器可以自由地释放与从旧验证器派生的旧客户端ID关联的所有锁。
Note that the verifier must have the same uniqueness properties of the verifier for the COMMIT operation.
请注意，对于提交操作，验证器必须具有与验证器相同的唯一性属性。
If the server loses locking state (usually as a result of a restart or reboot), it must allow clients time to discover this fact and re-establish the lost locking state. The client must be able to re-establish the locking state without having the server deny valid requests because the server has granted conflicting access to another client. Likewise, if there is the possibility that clients have
如果服务器失去锁定状态（通常是由于重新启动或重新启动），它必须让客户端有时间发现这一事实并重新建立失去的锁定状态。客户端必须能够重新建立锁定状态，而无需服务器拒绝有效请求，因为服务器已授予另一客户端冲突的访问权限。同样，如果客户有可能
not yet re-established their locking state for a file, the server must disallow READ and WRITE operations for that file. The duration of this recovery period is equal to the duration of the lease period.
尚未重新建立文件的锁定状态，服务器必须禁止该文件的读写操作。此恢复期的持续时间等于租赁期的持续时间。
A client can determine that server failure (and thus loss of locking state) has occurred, when it receives one of two errors. The NFS4ERR_STALE_STATEID error indicates a stateid invalidated by a reboot or restart. The NFS4ERR_STALE_CLIENTID error indicates a client ID invalidated by reboot or restart. When either of these is received, the client must establish a new client ID (see Section 9.1.1) and re-establish the locking state as discussed below.
当客户端收到两个错误中的一个错误时，它可以确定服务器发生故障（从而失去锁定状态）。NFS4ERR\u STALE\u STATEID错误表示STATEID因重新启动或重新启动而无效。NFS4ERR_STALE_CLIENTID错误表示客户端ID因重新启动或重新启动而无效。当收到其中任何一个时，客户机必须建立一个新的客户机ID（见第9.1.1节），并重新建立锁定状态，如下所述。
The period of special handling of locking and READs and WRITEs, equal in duration to the lease period, is referred to as the "grace period". During the grace period, clients recover locks and the associated state by reclaim-type locking requests (i.e., LOCK requests with reclaim set to TRUE and OPEN operations with a claim type of either CLAIM_PREVIOUS or CLAIM_DELEGATE_PREV). During the grace period, the server must reject READ and WRITE operations and non-reclaim locking requests (i.e., other LOCK and OPEN operations) with an error of NFS4ERR_GRACE.
锁定和读写的特殊处理期限与租赁期限相等，称为“宽限期”。在宽限期内，客户端通过回收类型锁定请求（即，将回收设置为TRUE的锁定请求和索赔类型为claim_PREVIOUS或claim_DELEGATE_PREV的打开操作）恢复锁和关联状态。在宽限期内，服务器必须拒绝读写操作和非回收锁定请求（即其他锁定和打开操作），错误为NFS4ERR_grace。
If the server can reliably determine that granting a non-reclaim request will not conflict with reclamation of locks by other clients, the NFS4ERR_GRACE error does not have to be returned and the non-reclaim client request can be serviced. For the server to be able to service READ and WRITE operations during the grace period, it must again be able to guarantee that no possible conflict could arise between an impending reclaim locking request and the READ or WRITE operation. If the server is unable to offer that guarantee, the NFS4ERR_GRACE error must be returned to the client.
如果服务器能够可靠地确定授予非回收请求不会与其他客户端的锁回收冲突，则不必返回NFS4ERR_GRACE错误，并且可以为非回收客户端请求提供服务。为了使服务器能够在宽限期内为读写操作提供服务，它必须再次能够保证即将到来的回收锁定请求与读写操作之间不会出现任何可能的冲突。如果服务器无法提供该保证，则必须将NFS4ERR_GRACE错误返回给客户端。
For a server to provide simple, valid handling during the grace period, the easiest method is to simply reject all non-reclaim locking requests and READ and WRITE operations by returning the NFS4ERR_GRACE error. However, a server may keep information about granted locks in stable storage. With this information, the server could determine if a regular lock or READ or WRITE operation can be safely processed.
对于要在宽限期内提供简单有效的处理的服务器，最简单的方法是通过返回NFS4ERR_宽限期错误，简单地拒绝所有非回收锁定请求和读写操作。但是，服务器可能会在稳定的存储中保留有关已授予锁的信息。有了这些信息，服务器可以确定是否可以安全地处理常规锁定或读写操作。
For example, if a count of locks on a given file is available in stable storage, the server can track reclaimed locks for the file, and when all reclaims have been processed, non-reclaim locking requests may be processed. This way, the server can ensure that non-reclaim locking requests will not conflict with potential reclaim requests. With respect to I/O requests, if the server is able to
例如，如果给定文件上的锁数量在稳定存储中可用，则服务器可以跟踪该文件的回收锁，并且在处理完所有回收后，可以处理非回收锁定请求。这样，服务器可以确保非回收锁定请求不会与潜在的回收请求冲突。对于I/O请求，如果服务器能够
determine that there are no outstanding reclaim requests for a file by information from stable storage or another similar mechanism, the processing of I/O requests could proceed normally for the file.
如果通过稳定存储或其他类似机制中的信息确定没有未完成的文件回收请求，则文件的I/O请求处理可以正常进行。
To reiterate, for a server that allows non-reclaim lock and I/O requests to be processed during the grace period, it MUST determine that no lock subsequently reclaimed will be rejected and that no lock subsequently reclaimed would have prevented any I/O operation processed during the grace period.
重申一下，对于允许在宽限期内处理非回收锁和I/O请求的服务器，必须确定随后回收的锁不会被拒绝，并且随后回收的锁不会阻止宽限期内处理的任何I/O操作。
Clients should be prepared for the return of NFS4ERR_GRACE errors for non-reclaim lock and I/O requests. In this case, the client should employ a retry mechanism for the request. A delay (on the order of several seconds) between retries should be used to avoid overwhelming the server. Further discussion of the general issue is included in [Floyd]. The client must account for the server that is able to perform I/O and non-reclaim locking requests within the grace period as well as those that cannot do so.
客户端应准备好返回非回收锁和I/O请求的NFS4ERR_GRACE错误。在这种情况下，客户端应该对请求采用重试机制。重试之间应使用延迟（大约几秒钟），以避免服务器无法正常工作。关于一般性问题的进一步讨论载于[Floyd]。客户机必须说明能够在宽限期内执行I/O和非回收锁定请求的服务器以及不能执行这些请求的服务器。
A reclaim-type locking request outside the server's grace period can only succeed if the server can guarantee that no conflicting lock or I/O request has been granted since reboot or restart.
只有在服务器能够保证自重新启动或重新启动后未授予任何冲突的锁定或I/O请求的情况下，服务器宽限期之外的回收类型锁定请求才能成功。
A server may, upon restart, establish a new value for the lease period. Therefore, clients should, once a new client ID is established, refetch the lease_time attribute and use it as the basis for lease renewal for the lease associated with that server. However, the server must establish, for this restart event, a grace period at least as long as the lease period for the previous server instantiation. This allows the client state obtained during the previous server instance to be reliably re-established.
服务器可以在重新启动时为租赁期建立新值。因此，一旦建立了新的客户机ID，客户机应重新蚀刻lease_time属性，并将其用作与该服务器关联的租约的租约续订基础。但是，对于此重新启动事件，服务器必须建立一个宽限期，该宽限期至少与上一个服务器实例化的租用期一样长。这允许可靠地重新建立在上一个服务器实例期间获得的客户端状态。
If the duration of a network partition is greater than the lease period provided by the server, the server will have not received a lease renewal from the client. If this occurs, the server may cancel the lease and free all locks held for the client. As a result, all stateids held by the client will become invalid or stale. Once the client is able to reach the server after such a network partition, all I/O submitted by the client with the now invalid stateids will fail with the server returning the error NFS4ERR_EXPIRED. Once this error is received, the client will suitably notify the application that held the lock.
如果网络分区的持续时间大于服务器提供的租约期限，则服务器将不会从客户端收到租约续订。如果发生这种情况，服务器可能会取消租约并释放为客户端保留的所有锁。因此，客户端持有的所有StateID都将变得无效或过时。一旦客户机能够在这样一个网络分区之后到达服务器，客户机提交的所有I/O以及现在无效的StateID都将失败，服务器返回错误NFS4ERR_EXPIRED。一旦收到此错误，客户端将适当地通知持有锁的应用程序。
As a courtesy to the client or as an optimization, the server may continue to hold locks, including delegations, on behalf of a client for which recent communication has extended beyond the lease period, delaying the cancellation of the lease. If the server receives a lock or I/O request that conflicts with one of these courtesy locks or if it runs out of resources, the server MAY cause lease cancellation to occur at that time and henceforth return NFS4ERR_EXPIRED when any of the stateids associated with the freed locks is used. If lease cancellation has not occurred and the server receives a lock or I/O request that conflicts with one of the courtesy locks, the requirements are as follows:
作为对客户机的礼貌或作为优化，服务器可以代表最近的通信已经延长到租赁期之外的客户机继续持有锁，包括委托，从而延迟租赁的取消。如果服务器接收到与这些礼貌锁之一冲突的锁或I/O请求，或者如果资源耗尽，则服务器可能会导致此时发生租约取消，并在使用与释放的锁关联的任何StateID时返回NFS4ERR_EXPIRED。如果租赁取消未发生，且服务器收到与其中一个门控锁冲突的锁或I/O请求，则要求如下：
o In the case of a courtesy lock that is not a delegation, it MUST free the courtesy lock and grant the new request.
o 如果门控锁不是委托，则必须释放门控锁并批准新请求。
o In the case of a lock or an I/O request that conflicts with a delegation that is being held as a courtesy lock, the server MAY delay resolution of the request but MUST NOT reject the request and MUST free the delegation and grant the new request eventually.
o 如果锁或I/O请求与作为礼节锁持有的委托冲突，服务器可能会延迟请求的解决，但不得拒绝请求，并且必须释放委托并最终授予新请求。
o In the case of a request for a delegation that conflicts with a delegation that is being held as a courtesy lock, the server MAY grant the new request or not as it chooses, but if it grants the conflicting request, the delegation held as a courtesy lock MUST be freed.
o 如果委托请求与作为礼节锁保留的委托冲突，服务器可以根据选择授予或不授予新请求，但如果授予冲突请求，则必须释放作为礼节锁保留的委托。
If the server does not reboot or cancel the lease before the network partition is healed, when the original client tries to access a courtesy lock that was freed, the server SHOULD send back an NFS4ERR_BAD_STATEID to the client. If the client tries to access a courtesy lock that was not freed, then the server SHOULD mark all of the courtesy locks as implicitly being renewed.
如果服务器在网络分区修复之前未重新启动或取消租约，则当原始客户端尝试访问已释放的门控锁时，服务器应向客户端发回NFS4ERR_BAD_STATEID。如果客户端试图访问未释放的门控锁，则服务器应将所有门控锁标记为隐式续订。
As a result of lease expiration, leases may be canceled, either immediately upon expiration or subsequently, depending on the occurrence of a conflicting lock or extension of the period of partition beyond what the server will tolerate.
租约到期后，租约可能会立即取消，也可能会在到期后取消，具体取决于发生冲突的锁或分区期限的延长超出服务器所能容忍的范围。
When a lease is canceled, all locking state associated with it is freed, and the use of any of the associated stateids will result in NFS4ERR_EXPIRED being returned. Similarly, the use of the associated clientid will result in NFS4ERR_EXPIRED being returned.
当租约被取消时，与之关联的所有锁定状态将被释放，并且使用任何关联的StateID都将导致返回NFS4ERR_EXPIRED。类似地，使用关联的clientid将导致返回NFS4ERR_EXPIRED。
The client should recover from this situation by using SETCLIENTID followed by SETCLIENTID_CONFIRM, in order to establish a new clientid. Once a lock is obtained using this clientid, a lease will be established.
客户端应使用SETCLIENTID，然后使用SETCLIENTID_CONFIRM从这种情况中恢复，以便建立新的clientid。使用此clientid获得锁后，将建立租约。
There is no way for a client to predetermine how a given server is going to behave during a network partition. When the partition heals, the client still has either all of its locks, some of its locks, or none of them. The client will be able to examine the various error return values to determine its response.
客户端无法预先确定给定服务器在网络分区期间的行为。当分区恢复时，客户机仍然拥有它的所有锁、一些锁或没有锁。客户端将能够检查各种错误返回值以确定其响应。
NFS4ERR_EXPIRED:
NFS4ERR_已过期：
All locks have been freed as a result of a lease cancellation that occurred during the partition. The client should use a SETCLIENTID to recover.
由于分区期间发生的租约取消，所有锁都已释放。客户端应使用SETCLIENTID进行恢复。
NFS4ERR_ADMIN_REVOKED:
NFS4ERR_ADMIN_已撤销：
The current lock has been revoked before, during, or after the partition. The client SHOULD handle this error as it normally would.
当前锁已在分区之前、期间或之后撤销。客户端应该像平常一样处理这个错误。
NFS4ERR_BAD_STATEID:
NFS4ERR_BAD_STATEID:
The current lock has been revoked/released during the partition, and the server did not reboot. Other locks MAY still be renewed. The client need not do a SETCLIENTID and instead SHOULD probe via a RENEW call.
当前锁已在分区期间被撤销/释放，服务器未重新启动。其他锁仍可能更新。客户端不需要执行SETCLIENTID，而是应该通过续订呼叫进行探测。
NFS4ERR_RECLAIM_BAD:
NFS4ERR_receive_BAD:
The current lock has been revoked during the partition, and the server rebooted. The server might have no information on the other locks. They may still be renewable.
当前锁已在分区期间被撤销，服务器已重新启动。服务器可能没有关于其他锁的信息。它们可能仍然是可再生的。
NFS4ERR_NO_GRACE:
NFS4ERR_NO_GRACE：
The client's locks have been revoked during the partition, and the server rebooted. None of the client's locks will be renewable.
在分区期间，客户端的锁已被撤销，服务器已重新启动。客户端的锁都不可更新。
NFS4ERR_OLD_STATEID:
NFS4ERR_OLD_STATEID:
The server has not rebooted. The client SHOULD handle this error as it normally would.
服务器尚未重新启动。客户端应该像平常一样处理这个错误。
When a network partition is combined with a server reboot, then both the server and client have responsibilities to ensure that the client does not reclaim a lock that it should no longer be able to access. Briefly, those are:
当网络分区与服务器重新启动相结合时，服务器和客户机都有责任确保客户机不会回收其不再能够访问的锁。简而言之，这些是：
o Client's responsibility: A client MUST NOT attempt to reclaim any locks that it did not hold at the end of its most recent successfully established client lease.
o 客户的责任：客户不得试图收回其在最近成功建立的客户租约结束时未持有的任何锁。
o Server's responsibility: A server MUST NOT allow a client to reclaim a lock unless it knows that it could not have since granted a conflicting lock. However, in deciding whether a conflicting lock could have been granted, it is permitted to assume that its clients are responsible, as above.
o 服务器的责任：服务器不得允许客户机回收锁，除非它知道此后不可能授予冲突的锁。但是，在决定是否可以授予冲突锁时，允许假定其客户机负责，如上所述。
A server may consider a client's lease "successfully established" once it has received an OPEN operation from that client.
一旦客户端从该客户端接收到打开的操作，服务器可以考虑“成功建立”租约。
The above are directed to CLAIM_PREVIOUS reclaims and not to CLAIM_DELEGATE_PREV reclaims, which generally do not involve a server reboot. However, when a server persistently stores delegation information to support CLAIM_DELEGATE_PREV across a period in which both client and server are down at the same time, similar strictures apply.
上述内容旨在声明_先前的回收，而不是声明_委托_先前的回收，这通常不涉及服务器重新启动。但是，当服务器在客户端和服务器同时停机的期间内持续存储委托信息以支持CLAIM_DELEGATE_PREV时，也会应用类似的限制。
The next sections give examples showing what can go wrong if these responsibilities are neglected and also provide examples of server implementation strategies that could meet a server's responsibilities.
接下来的部分给出了一些示例，说明了如果忽略这些责任，可能会出现什么问题，并提供了可以满足服务器责任的服务器实现策略的示例。
The first edge condition has the following scenario:
第一条边条件具有以下情况：
1. Client A acquires a lock.
1. 客户端A获得一个锁。
2. Client A and the server experience mutual network partition, such that client A is unable to renew its lease.
2. 客户端A和服务器经历相互的网络分区，因此客户端A无法续订其租约。
3. Client A's lease expires, so the server releases the lock.
3. 客户端A的租约到期，因此服务器将释放锁。
4. Client B acquires a lock that would have conflicted with that of client A.
4. 客户端B获取的锁可能与客户端a的锁冲突。
5. Client B releases the lock.
5. 客户端B释放锁。
6. The server reboots.
6. 服务器重新启动。
7. The network partition between client A and the server heals.
7. 客户端A和服务器之间的网络分区将修复。
8. Client A issues a RENEW operation and gets back an NFS4ERR_STALE_CLIENTID.
8. 客户端A发出续订操作并获取NFS4ERR\u STALE\u CLIENTID。
9. Client A reclaims its lock within the server's grace period.
9. 客户端A在服务器的宽限期内收回其锁。
Thus, at the final step, the server has erroneously granted client A's lock reclaim. If client B modified the object the lock was protecting, client A will experience object corruption.
因此，在最后一步，服务器错误地授予客户端A的锁回收。如果客户端B修改了锁所保护的对象，客户端A将经历对象损坏。
The second known edge condition follows:
第二个已知边条件如下所示：
1. Client A acquires a lock.
1. 客户端A获得一个锁。
2. The server reboots.
2. 服务器重新启动。
3. Client A and the server experience mutual network partition, such that client A is unable to reclaim its lock within the grace period.
3. 客户端A和服务器经历相互的网络分区，因此客户端A无法在宽限期内收回其锁。
4. The server's reclaim grace period ends. Client A has no locks recorded on the server.
4. 服务器的回收宽限期结束。客户端A在服务器上没有记录锁。
5. Client B acquires a lock that would have conflicted with that of client A.
5. 客户端B获取的锁可能与客户端a的锁冲突。
6. Client B releases the lock.
6. 客户端B释放锁。
7. The server reboots a second time.
7. 服务器将再次重新启动。
8. The network partition between client A and the server heals.
8. 客户端A和服务器之间的网络分区将修复。
9. Client A issues a RENEW operation and gets back an NFS4ERR_STALE_CLIENTID.
9. 客户端A发出续订操作并获取NFS4ERR\u STALE\u CLIENTID。
10. Client A reclaims its lock within the server's grace period.
10. 客户端A在服务器的宽限期内收回其锁。
As with the first edge condition, the final step of the scenario of the second edge condition has the server erroneously granting client A's lock reclaim.
与第一个边缘条件一样，第二个边缘条件场景的最后一步是服务器错误地授予客户端A的锁回收。
In both of the above examples, the client attempts reclaim of a lock that it held at the end of its most recent successfully established lease; thus, it has fulfilled its responsibility.
在上述两个示例中，客户机尝试收回其在最近成功建立的租约结束时持有的锁；因此，它履行了自己的责任。
The server, however, has failed, by granting a reclaim, despite having granted a conflicting lock since the reclaimed lock was last held.
然而，尽管自上次持有回收的锁以来已授予冲突的锁，但服务器已通过授予回收而失败。
Solving these edge conditions requires that the server either (1) assume after it reboots that an edge condition occurs, and thus return NFS4ERR_NO_GRACE for all reclaim attempts, or (2) record some information in stable storage. The amount of information the server records in stable storage is in inverse proportion to how harsh the server wants to be whenever the edge conditions occur. The server that is completely tolerant of all edge conditions will record in stable storage every lock that is acquired, removing the lock record from stable storage only when the lock is unlocked by the client and the lock's owner advances the sequence number such that the lock release is not the last stateful event for the owner's sequence. For the two aforementioned edge conditions, the harshest a server can be, and still support a grace period for reclaims, requires that the server record in stable storage some minimal information. For example, a server implementation could, for each client, save in stable storage a record containing:
解决这些边缘条件要求服务器（1）在重新启动后假设出现边缘条件，从而为所有回收尝试返回NFS4ERR_NO_GRACE，或者（2）在稳定存储中记录一些信息。服务器在稳定存储中记录的信息量与每当出现边缘条件时服务器希望达到的苛刻程度成反比。完全容忍所有边缘条件的服务器将在稳定存储中记录获取的每个锁，只有当客户端解锁锁并且锁的所有者提前输入序列号，从而使锁释放不是所有者序列的最后一个有状态事件时，才会从稳定存储中删除锁记录。对于上述两种边缘条件，服务器可能是最苛刻的，并且仍然支持回收的宽限期，要求服务器在稳定存储中记录一些最小的信息。例如，服务器实现可以为每个客户机在稳定存储中保存一条记录，其中包含：
o the client's id string.
o 客户端的id字符串。
o a boolean that indicates if the client's lease expired or if there was administrative intervention (see Section 9.8) to revoke a byte-range lock, share reservation, or delegation.
o 一个布尔值，指示客户端的租约是否过期，或者是否有管理干预（参见第9.8节）来撤销字节范围锁、共享保留或委派。
o a timestamp that is updated the first time after a server boot or reboot the client acquires byte-range locking, share reservation, or delegation state on the server. The timestamp need not be updated on subsequent lock requests until the server reboots.
o 服务器启动或重新启动后，客户端在服务器上获取字节范围锁定、共享保留或委派状态时第一次更新的时间戳。在服务器重新启动之前，不需要在后续锁定请求中更新时间戳。
The server implementation would also record in stable storage the timestamps from the two most recent server reboots.
服务器实现还将在稳定存储器中记录最近两次服务器重新启动的时间戳。
Assuming the above record keeping, for the first edge condition, after the server reboots, the record that client A's lease expired means that another client could have acquired a conflicting record lock, share reservation, or delegation. Hence, the server must reject a reclaim from client A with the error NFS4ERR_NO_GRACE or NFS4ERR_RECLAIM_BAD.
假设上述记录保留，对于第一个边缘条件，在服务器重新启动后，客户机A的租约过期的记录意味着另一个客户机可能获得了冲突的记录锁、共享保留或委派。因此，服务器必须拒绝来自客户端a的回收，错误为NFS4ERR_NO_GRACE或NFS4ERR_reclain_BAD。
For the second edge condition, after the server reboots for a second time, the record that the client had an unexpired record lock, share reservation, or delegation established before the server's previous incarnation means that the server must reject a reclaim from client A with the error NFS4ERR_NO_GRACE or NFS4ERR_RECLAIM_BAD.
对于第二个边缘条件，在服务器第二次重新启动后，在服务器上一次运行之前，客户端已建立了未过期的记录锁定、共享保留或委派，这意味着服务器必须拒绝客户端a的回收，错误为NFS4ERR_NO_GRACE或NFS4ERR_reclain_BAD。
Regardless of the level and approach to record keeping, the server MUST implement one of the following strategies (which apply to reclaims of share reservations, byte-range locks, and delegations):
无论记录保留的级别和方法如何，服务器都必须实施以下策略之一（适用于回收共享保留、字节范围锁和委派）：
1. Reject all reclaims with NFS4ERR_NO_GRACE. This is extremely harsh but is necessary if the server does not want to record lock state in stable storage.
1. 使用NFS4ERR_NO_GRACE拒绝所有回收。这非常苛刻，但如果服务器不想在稳定存储中记录锁定状态，则必须这样做。
2. Record sufficient state in stable storage to meet its responsibilities. In doubt, the server should err on the side of being harsh.
2. 在稳定的存储中记录足够的状态，以满足其职责。毫无疑问，服务器的错误在于过于苛刻。
In the event that, after a server reboot, the server determines that there is unrecoverable damage or corruption to stable storage, then for all clients and/or locks affected, the server MUST return NFS4ERR_NO_GRACE.
如果服务器重新启动后，服务器确定稳定存储存在无法恢复的损坏或损坏，则对于所有受影响的客户端和/或锁，服务器必须返回NFS4ERR_NO_GRACE。
A third edge condition affects the client and not the server. If the server reboots in the middle of the client reclaiming some locks and then a network partition is established, the client might be in the situation of having reclaimed some, but not all, locks. In that case, a conservative client would assume that the non-reclaimed locks were revoked.
第三个边缘条件影响客户端而不是服务器。如果服务器重新启动在客户端的中间，回收一些锁，然后建立一个网络分区，客户端可能处于回收一些但不是全部锁的情况。在这种情况下，保守的客户端会假定未回收的锁已被撤销。
The third known edge condition follows:
第三个已知边条件如下所示：
1. Client A acquires a lock 1.
1. 客户端A获得锁1。
2. Client A acquires a lock 2.
2. 客户端A获得锁2。
3. The server reboots.
3. 服务器重新启动。
4. Client A issues a RENEW operation and gets back an NFS4ERR_STALE_CLIENTID.
4. 客户端A发出续订操作并获取NFS4ERR\u STALE\u CLIENTID。
5. Client A reclaims its lock 1 within the server's grace period.
5. 客户端A在服务器的宽限期内回收其锁1。
6. Client A and the server experience mutual network partition, such that client A is unable to reclaim its remaining locks within the grace period.
6. 客户端A和服务器经历相互的网络分区，因此客户端A无法在宽限期内回收其剩余的锁。
7. The server's reclaim grace period ends.
7. 服务器的回收宽限期结束。
8. Client B acquires a lock that would have conflicted with client A's lock 2.
8. 客户端B获取的锁可能与客户端a的锁2冲突。
9. Client B releases the lock.
9. 客户端B释放锁。
10. The server reboots a second time.
10. 服务器将再次重新启动。
11. The network partition between client A and the server heals.
11. 客户端A和服务器之间的网络分区将修复。
12. Client A issues a RENEW operation and gets back an NFS4ERR_STALE_CLIENTID.
12. 客户端A发出续订操作并获取NFS4ERR\u STALE\u CLIENTID。
13. Client A reclaims both lock 1 and lock 2 within the server's grace period.
13. 客户端A在服务器的宽限期内回收锁1和锁2。
At the last step, the client reclaims lock 2 as if it had held that lock continuously, when in fact a conflicting lock was granted to client B.
在最后一步中，客户机回收锁2，就好像它一直持有该锁一样，而实际上一个冲突的锁被授予了客户机B。
This occurs because the client failed its responsibility, by attempting to reclaim lock 2 even though it had not held that lock at the end of the lease that was established by the SETCLIENTID after the first server reboot. (The client did hold lock 2 on a previous lease, but it is only the most recent lease that matters.)
发生这种情况的原因是，客户机未能履行其职责，尝试回收锁2，即使它在第一次服务器重新启动后由SETCLIENTID建立的租约结束时未持有该锁。（客户确实在以前的租约中持有锁2，但这只是最新的租约。）
A server could avoid this situation by rejecting the reclaim of lock 2. However, to do so accurately, it would have to ensure that additional information about individual locks held survives a reboot. Server implementations are not required to do that, so the client must not assume that the server will.
服务器可以通过拒绝回收锁2来避免这种情况。但是，为了准确地执行此操作，它必须确保有关持有的各个锁的附加信息在重新启动后仍然有效。服务器实现不需要这样做，因此客户端不能假设服务器会这样做。
Instead, a client MUST reclaim only those locks that it successfully 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.
相反，客户机必须只回收它从以前的服务器实例成功获取的锁，而忽略它在重新启动之前未能回收的任何锁。因此，在上面的最后一步中，客户端A应该只回收锁1。
A mandate for the client's handling of the NFS4ERR_NO_GRACE and NFS4ERR_RECLAIM_BAD errors is outside the scope of this specification, since the strategies for such handling are very dependent on the client's operating environment. However, one potential approach is described below.
客户处理NFS4ERR_NO_GRACE和NFS4ERR_Receive_错误的授权不在本规范的范围内，因为此类处理策略非常依赖于客户的操作环境。然而，下文描述了一种可能的方法。
When the client's reclaim fails, it could examine the change attribute of the objects the client is trying to reclaim state for, and use that to determine whether to re-establish the state via normal OPEN or LOCK requests. This is acceptable, provided the client's operating environment allows it. In other words, the client implementer is advised to document the behavior for his users. The client could also inform the application that its byte-range lock or share reservations (whether they were delegated or not) have been lost, such as via a UNIX signal, a GUI pop-up window, etc. See Section 10.5 for a discussion of what the client should do for dealing with unreclaimed delegations on client state.
当客户机的回收失败时，它可以检查客户机试图回收状态的对象的change属性，并使用该属性确定是否通过正常的OPEN或LOCK请求重新建立状态。只要客户的操作环境允许，这是可以接受的。换句话说，建议客户机实现者为其用户记录行为。客户端还可以通知应用程序其字节范围锁或共享保留（无论它们是否被委派）已丢失，例如通过UNIX信号、GUI弹出窗口等。有关客户端应如何处理客户端状态下未委派的委派的讨论，请参阅第10.5节。
For further discussion of revocation of locks, see Section 9.8.
有关撤销锁的进一步讨论，请参见第9.8节。
In the event a lock request times out, a client may decide to not retry the request. The client may also abort the request when the process for which it was issued is terminated (e.g., in UNIX due to a signal). It is possible, though, that the server received the request and acted upon it. This would change the state on the server without the client being aware of the change. It is paramount that the client resynchronize state with the server before it attempts any other operation that takes a seqid and/or a stateid with the same state-owner. This is straightforward to do without a special resynchronize operation.
如果锁定请求超时，客户端可能会决定不重试该请求。当为其发出请求的进程终止时（例如，在UNIX中，由于信号），客户端也可能中止请求。不过，服务器有可能接收到请求并对其执行操作。这将在客户端不知道更改的情况下更改服务器上的状态。最重要的是，客户机在尝试使用seqid和/或具有相同状态所有者的stateid的任何其他操作之前，必须与服务器重新同步状态。不需要特殊的重新同步操作，这是很简单的。
Since the server maintains the last lock request and response received on the state-owner, for each state-owner, the client should cache the last lock request it sent such that the lock request did not receive a response. From this, the next time the client does a lock operation for the state-owner, it can send the cached request, if there is one, and if the request was one that established state (e.g., a LOCK or OPEN operation), the server will return the cached result or, if it never saw the request, perform it. The client can follow up with a request to remove the state (e.g., a LOCKU or CLOSE operation). With this approach, the sequencing and stateid information on the client and server for the given state-owner will resynchronize, and in turn the lock state will resynchronize.
由于服务器维护在状态所有者上接收的最后一个锁请求和响应，因此对于每个状态所有者，客户端应该缓存它发送的最后一个锁请求，以便锁请求不会收到响应。因此，下次客户端为状态所有者执行锁定操作时，它可以发送缓存的请求（如果有），并且如果请求是建立状态的请求（例如，锁定或打开操作），服务器将返回缓存的结果，或者，如果它从未看到请求，则执行该请求。客户端可以通过请求来删除状态（例如，锁定或关闭操作）。使用这种方法，客户机和服务器上给定状态所有者的序列和stateid信息将重新同步，而锁状态将重新同步。
At any point, the server can revoke locks held by a client and the client must be prepared for this event. When the client detects that its locks have been or may have been revoked, the client is responsible for validating the state information between itself and the server. Validating locking state for the client means that it must verify or reclaim state for each lock currently held.
在任何时候，服务器都可以撤销客户机持有的锁，客户机必须为此事件做好准备。当客户端检测到其锁已被或可能已被撤销时，客户端负责验证自身和服务器之间的状态信息。验证客户端的锁定状态意味着它必须验证或回收当前持有的每个锁的状态。
The first instance of lock revocation is upon server reboot or re-initialization. In this instance, the client will receive an error (NFS4ERR_STALE_STATEID or NFS4ERR_STALE_CLIENTID) and the client will proceed with normal crash recovery as described in the previous section.
锁撤销的第一个实例是在服务器重新启动或重新初始化时。在这种情况下，客户端将收到一个错误（NFS4ERR_STALE_STATEID或NFS4ERR_STALE_CLIENTID），客户端将按照上一节中所述继续进行正常崩溃恢复。
The second lock revocation event is the inability to renew the lease before expiration. While this is considered a rare or unusual event, the client must be prepared to recover. Both the server and client will be able to detect the failure to renew the lease and are capable of recovering without data corruption. For the server, it tracks the last renewal event serviced for the client and knows when the lease will expire. Similarly, the client must track operations that will renew the lease period. Using the time that each such request was sent and the time that the corresponding reply was received, the client should bound the time that the corresponding renewal could have occurred on the server and thus determine if it is possible that a lease period expiration could have occurred.
第二个锁撤销事件是无法在租约到期前续订租约。虽然这被认为是罕见或不寻常的事件，但客户必须做好恢复的准备。服务器和客户端都能够检测到续订租约失败，并且能够在不损坏数据的情况下进行恢复。对于服务器，它跟踪上次为客户端服务的续订事件，并知道租约何时到期。同样，客户必须跟踪将延长租赁期的运营情况。使用发送每个此类请求的时间和收到相应回复的时间，客户机应绑定服务器上可能发生的相应续订时间，从而确定是否可能发生租赁期到期。
The third lock revocation event can occur as a result of administrative intervention within the lease period. While this is considered a rare event, it is possible that the server's administrator has decided to release or revoke a particular lock held by the client. As a result of revocation, the client will receive an error of NFS4ERR_ADMIN_REVOKED. In this instance, the client may assume that only the state-owner's locks have been lost. The client notifies the lock holder appropriately. The client cannot assume that the lease period has been renewed as a result of a failed operation.
第三个锁撤销事件可能是由于租赁期内的管理干预而发生的。虽然这被认为是罕见的事件，但服务器管理员可能已决定释放或撤销客户端持有的特定锁。撤销后，客户端将收到NFS4ERR_ADMIN_reversed错误。在这种情况下，客户端可能会假定只有状态所有者的锁丢失。客户端会适当地通知锁持有者。客户不能假定由于操作失败而续订了租赁期。
When the client determines the lease period may have expired, the client must mark all locks held for the associated lease as "unvalidated". This means the client has been unable to re-establish or confirm the appropriate lock state with the server. As described in Section 9.6, there are scenarios in which the server may grant conflicting locks after the lease period has expired for a client. When it is possible that the lease period has expired, the client must validate each lock currently held to ensure that a conflicting lock has not been granted. The client may accomplish this task by issuing an I/O request; if there is no relevant I/O pending, a zero-length read specifying the stateid associated with the lock in question can be synthesized to trigger the renewal. If the response to the request is success, the client has validated all of the locks governed by that stateid and re-established the appropriate state between itself and the server.
当客户确定租赁期可能已到期时，客户必须将为相关租赁持有的所有锁标记为“未验证”。这意味着客户端无法与服务器重新建立或确认适当的锁定状态。如第9.6节所述，在某些情况下，服务器可能会在客户机的租赁期到期后授予冲突锁。当租赁期可能已过期时，客户端必须验证当前持有的每个锁，以确保未授予冲突的锁。客户端可以通过发出I/O请求来完成此任务；如果没有相关的I/O挂起，则可以合成一个零长度读取，指定与所讨论的锁关联的stateid，以触发续订。如果对请求的响应是成功的，则客户端已经验证了由该stateid管理的所有锁，并在其自身和服务器之间重新建立了适当的状态。
If the I/O request is not successful, then one or more of the locks associated with the stateid were revoked by the server, and the client must notify the owner.
如果I/O请求未成功，则服务器将撤销与stateid关联的一个或多个锁，客户端必须通知所有者。
A share reservation is a mechanism to control access to a file. It is a separate and independent mechanism from byte-range locking. When a client opens a file, it issues an OPEN operation to the server specifying the type of access required (READ, WRITE, or BOTH) and the type of access to deny others (OPEN4_SHARE_DENY_NONE, OPEN4_SHARE_DENY_READ, OPEN4_SHARE_DENY_WRITE, or OPEN4_SHARE_DENY_BOTH). If the OPEN fails, the client will fail the application's open request.
共享保留是一种控制文件访问的机制。它是一种独立于字节范围锁定的机制。当客户端打开一个文件时，它会向服务器发出一个打开操作，指定所需的访问类型（读、写或两者）和拒绝其他人访问的类型（OPEN4_共享\u拒绝\u无、OPEN4_共享\u拒绝\u读、OPEN4_共享\u拒绝\u写或OPEN4_共享\u拒绝\u两者）。如果打开失败，客户端将使应用程序的打开请求失败。
Pseudo-code definition of the semantics:
语义的伪代码定义：
if (request.access == 0) return (NFS4ERR_INVAL) else if ((request.access & file_state.deny) || (request.deny & file_state.access)) return (NFS4ERR_DENIED)
if（request.access==0）返回（NFS4ERR_INVAL）else if（（request.access&file_state.deny）| |（request.deny&file_state.access））返回（NFS4ERR_DENIED）
This checking of share reservations on OPEN is done with no exception for an existing OPEN for the same open-owner.
对于同一开放所有者的现有开放，在开放时对共享保留进行检查，没有例外。
The constants used for the OPEN and OPEN_DOWNGRADE operations for the access and deny fields are as follows:
access和deny字段的OPEN和OPEN_降级操作使用的常量如下：
const OPEN4_SHARE_ACCESS_READ = 0x00000001;
const OPEN4_SHARE_ACCESS_WRITE = 0x00000002;
const OPEN4_SHARE_ACCESS_BOTH = 0x00000003;
const OPEN4_SHARE_ACCESS_READ = 0x00000001;
const OPEN4_SHARE_ACCESS_WRITE = 0x00000002;
const OPEN4_SHARE_ACCESS_BOTH = 0x00000003;
const OPEN4_SHARE_DENY_NONE = 0x00000000;
const OPEN4_SHARE_DENY_READ = 0x00000001;
const OPEN4_SHARE_DENY_WRITE = 0x00000002;
const OPEN4_SHARE_DENY_BOTH = 0x00000003;
const OPEN4_SHARE_DENY_NONE = 0x00000000;
const OPEN4_SHARE_DENY_READ = 0x00000001;
const OPEN4_SHARE_DENY_WRITE = 0x00000002;
const OPEN4_SHARE_DENY_BOTH = 0x00000003;
To provide correct share semantics, a client MUST use the OPEN operation to obtain the initial filehandle and indicate the desired access and what access, if any, to deny. Even if the client intends to use one of the special stateids (anonymous stateid or READ bypass stateid), it must still obtain the filehandle for the regular file with the OPEN operation so the appropriate share semantics can be
为了提供正确的共享语义，客户端必须使用OPEN操作来获取初始文件句柄，并指示所需的访问以及要拒绝的访问（如果有）。即使客户机打算使用一个特殊的stateid（匿名stateid或READ-bypass-stateid），它仍然必须通过OPEN操作获得常规文件的filehandle，以便可以使用适当的共享语义
applied. Clients that do not have a deny mode built into their programming interfaces for opening a file should request a deny mode of OPEN4_SHARE_DENY_NONE.
应用如果客户端的编程接口中没有内置用于打开文件的拒绝模式，则应请求OPEN4_SHARE_deny_NONE的拒绝模式。
The OPEN operation with the CREATE flag also subsumes the CREATE operation for regular files as used in previous versions of the NFS protocol. This allows a create with a share to be done atomically.
带有CREATE标志的OPEN操作还包含NFS协议早期版本中使用的常规文件的CREATE操作。这允许以原子方式创建共享。
The CLOSE operation removes all share reservations held by the open-owner on that file. If byte-range locks are held, the client SHOULD release all locks before issuing a CLOSE. The server MAY free all outstanding locks on CLOSE, but some servers may not support the CLOSE of a file that still has byte-range locks held. The server MUST return failure, NFS4ERR_LOCKS_HELD, if any locks would exist after the CLOSE.
关闭操作将删除打开的所有者对该文件持有的所有共享保留。如果持有字节范围锁，客户端应在发出关闭之前释放所有锁。服务器可能会在关闭时释放所有未完成的锁，但某些服务器可能不支持关闭仍保留字节范围锁的文件。如果关闭后存在任何锁，服务器必须返回failure，NFS4ERR_LOCKS_hold。
The LOOKUP operation will return a filehandle without establishing any lock state on the server. Without a valid stateid, the server will assume that the client has the least access. For example, if one client opened a file with OPEN4_SHARE_DENY_BOTH and another client accesses the file via a filehandle obtained through LOOKUP, the second client could only read the file using the special READ bypass stateid. The second client could not WRITE the file at all because it would not have a valid stateid from OPEN and the special anonymous stateid would not be allowed access.
查找操作将返回文件句柄，而不会在服务器上建立任何锁定状态。如果没有有效的stateid，服务器将假定客户端具有最少的访问权限。例如，如果一个客户机同时使用OPEN4_SHARE_DENY_打开一个文件，而另一个客户机通过通过查找获得的文件句柄访问该文件，则第二个客户机只能使用特殊的读取旁路stateid读取该文件。第二个客户端根本无法写入该文件，因为它没有来自OPEN的有效stateid，并且不允许访问特殊的匿名stateid。
Since a CLOSE operation requests deallocation of a stateid, dealing with retransmission of the CLOSE may pose special difficulties, since the state information, which normally would be used to determine the state of the open file being designated, might be deallocated, resulting in an NFS4ERR_BAD_STATEID error.
由于关闭操作请求释放stateid，因此处理关闭的重新传输可能会带来特殊困难，因为通常用于确定指定的打开文件的状态的状态信息可能会被释放，从而导致NFS4ERR_BAD_stateid错误。
Servers may deal with this problem in a number of ways. To provide the greatest degree of assurance that the protocol is being used properly, a server should, rather than deallocate the stateid, mark it as close-pending, and retain the stateid with this status, until later deallocation. In this way, a retransmitted CLOSE can be recognized since the stateid points to state information with this distinctive status, so that it can be handled without error.
服务器可以通过多种方式处理此问题。为了最大程度地保证协议被正确使用，服务器应该将stateid标记为close pending，而不是解除分配，并将stateid保留为此状态，直到以后解除分配。通过这种方式，可以识别重新传输的关闭，因为stateid指向具有此独特状态的状态信息，因此可以无误地处理它。
When adopting this strategy, a server should retain the state information until the earliest of:
采用此策略时，服务器应保留状态信息，直到以下时间最早：
o Another validly sequenced request for the same open-owner, that is not a retransmission.
o 对同一开放所有者的另一个有效排序的请求，这不是重传。
o The time that an open-owner is freed by the server due to period with no activity.
o 由于没有活动的时间段，服务器释放打开的所有者的时间。
o All locks for the client are freed as a result of a SETCLIENTID.
o 由于SETCLIENTID，客户端的所有锁都被释放。
Servers may avoid this complexity, at the cost of less complete protocol error checking, by simply responding NFS4_OK in the event of a CLOSE for a deallocated stateid, on the assumption that this case must be caused by a retransmitted close. When adopting this approach, it is desirable to at least log an error when returning a no-error indication in this situation. If the server maintains a reply-cache mechanism, it can verify that the CLOSE is indeed a retransmission and avoid error logging in most cases.
服务器可以避免这种复杂性，但代价是协议错误检查不太完整，只要在释放的stateid关闭时响应NFS4_OK即可，前提是这种情况必须由重新传输的关闭引起。当采用这种方法时，希望在这种情况下返回无错误指示时至少记录错误。如果服务器维护应答缓存机制，它可以验证关闭是否确实是重新传输，并在大多数情况下避免错误日志记录。
When an OPEN is done for a file and the open-owner for which the open is being done already has the file open, the result is to upgrade the open file status maintained on the server to include the access and deny bits specified by the new OPEN as well as those for the existing OPEN. The result is that there is one open file, as far as the protocol is concerned, and it includes the union of the access and deny bits for all of the OPEN requests completed. Only a single CLOSE will be done to reset the effects of both OPENs. Note that the client, when issuing the OPEN, may not know that the same file is in fact being opened. The above only applies if both OPENs result in the OPENed object being designated by the same filehandle.
当对某个文件执行打开操作，并且正在执行打开操作的打开所有者已打开该文件时，结果是升级服务器上维护的打开文件状态，以包括新打开指定的访问和拒绝位以及现有打开指定的访问和拒绝位。结果是，就协议而言，有一个打开的文件，它包括所有已完成的打开请求的访问位和拒绝位的联合。只有一次关闭才能重置两次打开的效果。请注意，客户端在发出OPEN命令时，可能不知道实际上正在打开同一个文件。仅当两次打开都导致打开的对象由同一个filehandle指定时，上述内容才适用。
When the server chooses to export multiple filehandles corresponding to the same file object and returns different filehandles on two different OPENs of the same file object, the server MUST NOT "OR" together the access and deny bits and coalesce the two open files. Instead, the server must maintain separate OPENs with separate stateids and will require separate CLOSEs to free them.
当服务器选择导出对应于同一文件对象的多个文件句柄，并在同一文件对象的两个不同打开上返回不同的文件句柄时，服务器不得将访问和拒绝位“或”组合在一起，并合并两个打开的文件。相反，服务器必须使用单独的stateID维护单独的打开，并且需要单独的关闭来释放它们。
When multiple open files on the client are merged into a single open file object on the server, the close of one of the open files (on the client) may necessitate change of the access and deny status of the open file on the server. This is because the union of the access and deny bits for the remaining opens may be smaller (i.e., a proper subset) than previously. The OPEN_DOWNGRADE operation is used to make the necessary change, and the client should use it to update the
当客户端上的多个打开的文件合并到服务器上的单个打开的文件对象中时，关闭其中一个打开的文件（客户端上）可能需要更改服务器上打开的文件的访问和拒绝状态。这是因为剩余打开的访问位和拒绝位的联合可能比以前更小（即，适当的子集）。OPEN_降级操作用于进行必要的更改，客户端应使用它更新
server so that share reservation requests by other clients are handled properly. The stateid returned has the same "other" field as that passed to the server. The seqid value in the returned stateid MUST be incremented (Section 9.1.4), even in situations in which there has been no change to the access and deny bits for the file.
服务器，以便正确处理其他客户端的共享保留请求。返回的stateid与传递给服务器的stateid具有相同的“other”字段。即使在文件的访问位和拒绝位没有更改的情况下，返回的stateid中的seqid值也必须增加（第9.1.4节）。
When determining the time period for the server lease, the usual lease trade-offs apply. Short leases are good for fast server recovery at a cost of increased RENEW or READ (with zero length) requests. Longer leases are certainly kinder and gentler to servers trying to handle very large numbers of clients. The number of RENEW requests drops in proportion to the lease time. The disadvantages of long leases are slower recovery after server failure (the server must wait for the leases to expire and the grace period to elapse before granting new lock requests) and increased file contention (if the client fails to transmit an unlock request, then the server must wait for lease expiration before granting new locks).
在确定服务器租用的时间段时，通常的租用权衡适用。短租约有利于快速服务器恢复，但代价是续订或读取（长度为零）请求增加。对于试图处理大量客户机的服务器来说，较长的租赁期当然更友好、更温和。续订请求的数量与租赁时间成比例下降。长租约的缺点是服务器故障后恢复较慢（服务器必须等待租约到期，宽限期过后才能授予新锁请求）和文件争用加剧（如果客户端无法传输解锁请求，则服务器必须等待租约到期后再授予新锁）。
Long leases are usable if the server is able to store lease state in non-volatile memory. Upon recovery, the server can reconstruct the lease state from its non-volatile memory and continue operation with its clients, and therefore long leases would not be an issue.
如果服务器能够在非易失性内存中存储租约状态，则长租约是可用的。恢复后，服务器可以从其非易失性内存重建租约状态，并继续与客户端一起操作，因此长租约不会成为问题。
To avoid the need for synchronized clocks, lease times are granted by the server as a time delta. However, there is a requirement that the client and server clocks do not drift excessively over the duration of the lock. There is also the issue of propagation delay across the network -- which could easily be several hundred milliseconds -- as well as the possibility that requests will be lost and need to be retransmitted.
为了避免需要同步时钟，服务器将租赁时间作为时间增量授予。但是，有一个要求，即客户机和服务器时钟在锁定期间不会过度漂移。还有一个问题是网络中的传播延迟——可能很容易达到几百毫秒——以及请求丢失和需要重新传输的可能性。
To take propagation delay into account, the client should subtract it from lease times (e.g., if the client estimates the one-way propagation delay as 200 msec, then it can assume that the lease is already 200 msec old when it gets it). In addition, it will take another 200 msec to get a response back to the server. So the client must send a lock renewal or write data back to the server 400 msec before the lease would expire.
为了将传播延迟考虑在内，客户机应将其从租约时间中减去（例如，如果客户机估计单向传播延迟为200毫秒，则可以假设在获得租约时，租约已经存在200毫秒）。此外，还需要200毫秒才能将响应返回到服务器。因此，客户端必须在租约到期前400毫秒向服务器发送锁续订或写回数据。
The server's lease period configuration should take into account the network distance of the clients that will be accessing the server's resources. It is expected that the lease period will take into account the network propagation delays and other network delay
服务器的租用期配置应考虑将要访问服务器资源的客户端的网络距离。预计租赁期将考虑网络传播延迟和其他网络延迟
factors for the client population. Since the protocol does not allow for an automatic method to determine an appropriate lease period, the server's administrator may have to tune the lease period.
客户群体的因素。由于协议不允许使用自动方法来确定适当的租赁期，服务器管理员可能必须调整租赁期。
When responsibility for handling a given file system is transferred to a new server (migration) or the client chooses to use an alternative server (e.g., in response to server unresponsiveness) in the context of file system replication, the appropriate handling of state shared between the client and server (i.e., locks, leases, stateids, and client IDs) is as described below. The handling differs between migration and replication. For a related discussion of file server state and recovery of same, see the subsections of Section 9.6.
当处理给定文件系统的责任转移到新服务器（迁移）或客户端选择在文件系统复制上下文中使用替代服务器（例如，响应服务器无响应）时，客户端和服务器之间共享的状态的适当处理（即锁、租约、状态ID和客户端ID）如下所述。迁移和复制的处理方式不同。有关文件服务器状态和恢复的相关讨论，请参阅第9.6节的小节。
In cases in which one server is expected to accept opaque values from the client that originated from another server, the servers SHOULD encode the opaque values in big-endian byte order. If this is done, the new server will be able to parse values like stateids, directory cookies, filehandles, etc. even if their native byte order is different from that of other servers cooperating in the replication and migration of the file system.
如果期望一台服务器接受来自另一台服务器的客户端的不透明值，则服务器应以大端字节顺序对不透明值进行编码。如果这样做，新服务器将能够解析stateID、目录cookie、文件句柄等值，即使它们的本机字节顺序与在文件系统的复制和迁移中协作的其他服务器的本机字节顺序不同。
In the case of migration, the servers involved in the migration of a file system SHOULD transfer all server state from the original server to the new server. This must be done in a way that is transparent to the client. This state transfer will ease the client's transition when a file system migration occurs. If the servers are successful in transferring all state, the client will continue to use stateids assigned by the original server. Therefore, the new server must recognize these stateids as valid. This holds true for the client ID as well. Since responsibility for an entire file system is transferred with a migration event, there is no possibility that conflicts will arise on the new server as a result of the transfer of locks.
在迁移的情况下，参与文件系统迁移的服务器应将所有服务器状态从原始服务器传输到新服务器。这必须以对客户端透明的方式完成。当发生文件系统迁移时，此状态传输将简化客户端的转换。如果服务器成功传输所有状态，客户端将继续使用原始服务器分配的StateID。因此，新服务器必须将这些stateID识别为有效。对于客户端ID也是如此。由于整个文件系统的责任是通过迁移事件转移的，因此不可能由于锁的转移而在新服务器上产生冲突。
As part of the transfer of information between servers, leases would be transferred as well. The leases being transferred to the new server will typically have a different expiration time from those for the same client, previously on the old server. To maintain the property that all leases on a given server for a given client expire at the same time, the server should advance the expiration time to the later of the leases being transferred or the leases already present. This allows the client to maintain lease renewal of both classes without special effort.
作为服务器间信息传输的一部分，租约也将进行传输。传输到新服务器的租约的到期时间通常与以前在旧服务器上传输到同一客户机的租约的到期时间不同。要维护给定客户端的给定服务器上的所有租约同时到期的属性，服务器应将到期时间提前到正在传输的租约或已存在的租约中的较晚者。这允许客户无需特别努力即可维持这两个类别的租赁续期。
The servers may choose not to transfer the state information upon migration. However, this choice is discouraged. In this case, when the client presents state information from the original server (e.g., in a RENEW operation or a READ operation of zero length), the client must be prepared to receive either NFS4ERR_STALE_CLIENTID or NFS4ERR_STALE_STATEID from the new server. The client should then recover its state information as it normally would in response to a server failure. The new server must take care to allow for the recovery of state information as it would in the event of server restart.
服务器可以选择在迁移时不传输状态信息。然而，这种选择是不可取的。在这种情况下，当客户端显示来自原始服务器的状态信息时（例如，在续订操作或长度为零的读取操作中），客户端必须准备从新服务器接收NFS4ERR_STALE_CLIENTID或NFS4ERR_STALE_STATEID。然后，客户机应恢复其状态信息，这与正常情况下响应服务器故障时一样。新服务器必须注意恢复状态信息，就像服务器重新启动时一样。
A client SHOULD re-establish new callback information with the new server as soon as possible, according to sequences described in Sections 16.33 and 16.34. This ensures that server operations are not blocked by the inability to recall delegations.
客户机应根据第16.33节和第16.34节中描述的顺序，尽快与新服务器重新建立新的回调信息。这可确保服务器操作不会因无法调用委派而受阻。
Since client switch-over in the case of replication is not under server control, the handling of state is different. In this case, leases, stateids, and client IDs do not have validity across a transition from one server to another. The client must re-establish its locks on the new server. This can be compared to the re-establishment of locks by means of reclaim-type requests after a server reboot. The difference is that the server has no provision to distinguish requests reclaiming locks from those obtaining new locks or to defer the latter. Thus, a client re-establishing a lock on the new server (by means of a LOCK or OPEN request), may have the requests denied due to a conflicting lock. Since replication is intended for read-only use of file systems, such denial of locks should not pose large difficulties in practice. When an attempt to re-establish a lock on a new server is denied, the client should treat the situation as if its original lock had been revoked.
由于复制情况下的客户端切换不受服务器控制，因此状态的处理是不同的。在这种情况下，租约、StateID和客户端ID在从一台服务器到另一台服务器的转换过程中不具有有效性。客户端必须在新服务器上重新建立其锁。这可以与服务器重新启动后通过回收类型请求重新建立锁进行比较。不同之处在于，服务器没有规定区分请求回收锁和请求获得新锁或延迟后者。因此，在新服务器上重新建立锁的客户端（通过锁或打开请求）可能会由于锁冲突而拒绝请求。由于复制旨在以只读方式使用文件系统，因此这种拒绝锁定在实践中不会造成很大困难。当在新服务器上重新建立锁的尝试被拒绝时，客户端应将此情况视为其原始锁已被撤销。
In the case of lease renewal, the client may not be submitting requests for a file system that has been migrated to another server. This can occur because of the implicit lease renewal mechanism. The client renews leases for all file systems when submitting a request to any one file system at the server.
在租约续订的情况下，客户端可能不会提交已迁移到另一台服务器的文件系统的请求。这可能是由于隐式租约续订机制造成的。当向服务器上的任何一个文件系统提交请求时，客户端将续订所有文件系统的租约。
In order for the client to schedule renewal of leases that may have been relocated to the new server, the client must find out about lease relocation before those leases expire. To accomplish this, all operations that implicitly renew leases for a client (such as OPEN, CLOSE, READ, WRITE, RENEW, LOCK, and others) will return the error NFS4ERR_LEASE_MOVED if responsibility for any of the leases to be
为了让客户端计划可能已重新定位到新服务器的租约的续订，客户端必须在这些租约到期之前了解租约重新定位。为了实现这一点，所有隐式续订客户机租约的操作（如打开、关闭、读取、写入、续订、锁定和其他操作）都将返回错误NFS4ERR_LEASE_MOVED，前提是要删除对任何租约的责任
renewed has been transferred to a new server. This condition will continue until the client receives an NFS4ERR_MOVED error and the server receives the subsequent GETATTR(fs_locations) for an access to each file system for which a lease has been moved to a new server. By convention, the compound including the GETATTR(fs_locations) SHOULD append a RENEW operation to permit the server to identify the client doing the access.
续订的已传输到新服务器。此情况将持续，直到客户端收到NFS4ERR_MOVED错误，并且服务器收到后续GETATTR（fs_位置）以访问已将租约移动到新服务器的每个文件系统。按照惯例，包括GETATTR（fs_位置）的复合应该附加一个续订操作，以允许服务器识别进行访问的客户端。
Upon receiving the NFS4ERR_LEASE_MOVED error, a client that supports file system migration MUST probe all file systems from that server on which it holds open state. Once the client has successfully probed all those file systems that are migrated, the server MUST resume normal handling of stateful requests from that client.
接收到NFS4ERR_LEASE_MOVED错误后，支持文件系统迁移的客户端必须从其保持打开状态的服务器探测所有文件系统。一旦客户机成功探测到所有迁移的文件系统，服务器必须恢复对来自该客户机的有状态请求的正常处理。
In order to support legacy clients that do not handle the NFS4ERR_LEASE_MOVED error correctly, the server SHOULD time out after a wait of at least two lease periods, at which time it will resume normal handling of stateful requests from all clients. If a client attempts to access the migrated files, the server MUST reply with NFS4ERR_MOVED.
为了支持未正确处理NFS4ERR_LEASE_MOVED错误的旧客户端，服务器应在至少两个租用期等待后超时，此时将恢复正常处理来自所有客户端的有状态请求。如果客户端试图访问迁移的文件，服务器必须使用NFS4ERR_MOVED进行回复。
When the client receives an NFS4ERR_MOVED error, the client can follow the normal process to obtain the new server information (through the fs_locations attribute) and perform renewal of those leases on the new server. If the server has not had state transferred to it transparently, the client will receive either NFS4ERR_STALE_CLIENTID or NFS4ERR_STALE_STATEID from the new server, as described above. The client can then recover state information as it does in the event of server failure.
当客户端接收到NFS4ERR_MOVED错误时，客户端可以按照正常过程获取新服务器信息（通过fs_locations属性），并在新服务器上执行这些租约的续订。如果服务器尚未将状态透明地传输给它，则客户端将从新服务器接收NFS4ERR_STALE_CLIENTID或NFS4ERR_STALE_STATEID，如上所述。然后，客户端可以像在服务器发生故障时一样恢复状态信息。
In order that the client may appropriately manage its leases in the case of migration, the destination server must establish proper values for the lease_time attribute.
为了在迁移的情况下客户端可以适当地管理其租约，目标服务器必须为租约时间属性建立适当的值。
When state is transferred transparently, that state should include the correct value of the lease_time attribute. The lease_time attribute on the destination server must never be less than that on the source since this would result in premature expiration of leases granted by the source server. Upon migration, in which state is transferred transparently, the client is under no obligation to refetch the lease_time attribute and may continue to use the value previously fetched (on the source server).
当状态以透明方式传输时，该状态应包含lease_time属性的正确值。目标服务器上的租约时间属性不得小于源服务器上的租约时间属性，因为这将导致源服务器授予的租约提前到期。在迁移时，状态是透明传输的，客户端没有义务重新蚀刻lease_time属性，并且可以继续使用以前获取的值（在源服务器上）。
If state has not been transferred transparently (i.e., the client sees a real or simulated server reboot), the client should fetch the value of lease_time on the new (i.e., destination) server and use it
如果状态没有被透明地传输（即，客户端看到真实或模拟的服务器重新启动），客户端应该获取新（即，目标）服务器上的租约时间值并使用它
for subsequent locking requests. However, the server must respect a grace period at least as long as the lease_time on the source server, in order to ensure that clients have ample time to reclaim their locks before potentially conflicting non-reclaimed locks are granted. The means by which the new server obtains the value of lease_time on the old server is left to the server implementations. It is not specified by the NFSv4 protocol.
用于后续锁定请求。但是，服务器必须遵守至少与源服务器上的租约时间一样长的宽限期，以确保在授予潜在冲突的未回收锁之前，客户端有足够的时间回收其锁。新服务器获取旧服务器上的租赁时间值的方法留给服务器实现。NFSv4协议没有指定它。
Client-side caching of data, file attributes, and filenames is essential to providing good performance with the NFS protocol. Providing distributed cache coherence is a difficult problem, and previous versions of the NFS protocol have not attempted it. Instead, several NFS client implementation techniques have been used to reduce the problems that a lack of coherence poses for users. These techniques have not been clearly defined by earlier protocol specifications, and it is often unclear what is valid or invalid client behavior.
数据、文件属性和文件名的客户端缓存对于使用NFS协议提供良好性能至关重要。提供分布式缓存一致性是一个难题，以前版本的NFS协议没有尝试过。相反，使用了几种NFS客户端实现技术来减少缺乏一致性给用户带来的问题。这些技术在早期的协议规范中没有明确定义，并且通常不清楚什么是有效的或无效的客户端行为。
The NFSv4 protocol uses many techniques similar to those that have been used in previous protocol versions. The NFSv4 protocol does not provide distributed cache coherence. However, it defines a more limited set of caching guarantees to allow locks and share reservations to be used without destructive interference from client-side caching.
NFSv4协议使用了许多与以前协议版本中使用的技术类似的技术。NFSv4协议不提供分布式缓存一致性。但是，它定义了一组更有限的缓存保证，以允许在不受客户端缓存破坏性干扰的情况下使用锁和共享保留。
In addition, the NFSv4 protocol introduces a delegation mechanism that allows many decisions normally made by the server to be made locally by clients. This mechanism provides efficient support of the common cases where sharing is infrequent or where sharing is read-only.
此外，NFSv4协议引入了一种委托机制，允许客户端在本地做出通常由服务器做出的许多决策。此机制为共享不频繁或共享为只读的常见情况提供了有效支持。
Caching techniques used in previous versions of the NFS protocol have been successful in providing good performance. However, several scalability challenges can arise when those techniques are used with very large numbers of clients. This is particularly true when clients are geographically distributed, which classically increases the latency for cache revalidation requests.
NFS协议早期版本中使用的缓存技术已经成功地提供了良好的性能。然而，当这些技术用于大量客户机时，可能会出现一些可伸缩性挑战。当客户端分布在不同的地理位置时尤其如此，这通常会增加缓存重新验证请求的延迟。
The previous versions of the NFS protocol repeat their file data cache validation requests at the time the file is opened. This behavior can have serious performance drawbacks. A common case is one in which a file is only accessed by a single client. Therefore, sharing is infrequent.
NFS协议的早期版本在打开文件时重复其文件数据缓存验证请求。这种行为可能有严重的性能缺陷。一种常见的情况是，一个文件只能由一个客户端访问。因此，共享很少。
In this case, repeated reference to the server to find that no conflicts exist is expensive. A better option with regards to performance is to allow a client that repeatedly opens a file to do so without reference to the server. This is done until potentially conflicting operations from another client actually occur.
在这种情况下，重复引用服务器以发现不存在冲突是非常昂贵的。关于性能，一个更好的选择是允许重复打开文件的客户机这样做，而无需参考服务器。这将一直执行，直到来自另一个客户端的潜在冲突操作实际发生为止。
A similar situation arises in connection with file locking. Sending file lock and unlock requests to the server as well as the READ and WRITE requests necessary to make data caching consistent with the locking semantics (see Section 10.3.2) can severely limit performance. When locking is used to provide protection against infrequent conflicts, a large penalty is incurred. This penalty may discourage the use of file locking by applications.
在文件锁定方面也会出现类似的情况。向服务器发送文件锁定和解锁请求以及使数据缓存与锁定语义一致所需的读写请求（参见第10.3.2节）会严重限制性能。如果使用锁定来防止不经常发生的冲突，则会产生很大的损失。此惩罚可能会阻止应用程序使用文件锁定。
The NFSv4 protocol provides more aggressive caching strategies with the following design goals:
NFSv4协议提供了更积极的缓存策略，具有以下设计目标：
o Compatibility with a large range of server semantics.
o 与大量服务器语义的兼容性。
o Providing the same caching benefits as previous versions of the NFS protocol when unable to provide the more aggressive model.
o 在无法提供更具攻击性的模型时，提供与以前版本的NFS协议相同的缓存好处。
o Organizing requirements for aggressive caching so that a large portion of the benefit can be obtained even when not all of the requirements can be met.
o 组织主动缓存的需求，以便即使不能满足所有需求，也能获得大部分好处。
The appropriate requirements for the server are discussed in later sections, in which specific forms of caching are covered (see Section 10.4).
服务器的适当要求将在后面的章节中讨论，其中介绍了缓存的具体形式（参见第10.4节）。
Recallable delegation of server responsibilities for a file to a client improves performance by avoiding repeated requests to the server in the absence of inter-client conflict. With the use of a "callback" RPC from server to client, a server recalls delegated responsibilities when another client engages in the sharing of a delegated file.
在没有客户端间冲突的情况下，通过避免向服务器重复请求，将文件的服务器责任可重新分配给客户端，从而提高了性能。通过使用从服务器到客户端的“回调”RPC，当另一个客户端参与共享委托文件时，服务器会调用委托的职责。
A delegation is passed from the server to the client, specifying the object of the delegation and the type of delegation. There are different types of delegations, but each type contains a stateid to be used to represent the delegation when performing operations that depend on the delegation. This stateid is similar to those associated with locks and share reservations but differs in that the stateid for a delegation is associated with a client ID and may be
委托从服务器传递到客户端，指定委托对象和委托类型。有不同类型的委托，但每种类型都包含一个stateid，用于在执行依赖于委托的操作时表示委托。此stateid类似于与锁和共享保留相关联的stateid，但不同之处在于委托的stateid与客户端ID相关联，并且可能是
used on behalf of all the open-owners for the given client. A delegation is made to the client as a whole and not to any specific process or thread of control within it.
代表给定客户端的所有开放所有者使用。委托是作为一个整体委托给客户机的，而不是委托给客户机中的任何特定进程或控制线程。
Because callback RPCs may not work in all environments (due to firewalls, for example), correct protocol operation does not depend on them. Preliminary testing of callback functionality by means of a CB_NULL procedure determines whether callbacks can be supported. The CB_NULL procedure checks the continuity of the callback path. A server makes a preliminary assessment of callback availability to a given client and avoids delegating responsibilities until it has determined that callbacks are supported. Because the granting of a delegation is always conditional upon the absence of conflicting access, clients must not assume that a delegation will be granted, and they must always be prepared for OPENs to be processed without any delegations being granted.
由于回调RPC可能无法在所有环境中工作（例如，由于防火墙），因此正确的协议操作并不依赖于它们。通过CB_NULL过程对回调功能进行初步测试，确定是否支持回调。CB_NULL过程检查回调路径的连续性。服务器对给定客户端的回调可用性进行初步评估，并在确定回调受支持之前避免委派责任。由于授予委托始终以不存在冲突访问为条件，因此客户端不得假设将授予委托，并且必须始终准备好在未授予任何委托的情况下进行处理。
Once granted, a delegation behaves in most ways like a lock. There is an associated lease that is subject to renewal, together with all of the other leases held by that client.
一旦授权，委托的行为在大多数情况下都像锁一样。有一项相关租赁以及该客户持有的所有其他租赁需要续签。
Unlike locks, an operation by a second client to a delegated file will cause the server to recall a delegation through a callback.
与锁不同，第二个客户端对委托文件的操作将导致服务器通过回调调用委托。
On recall, the client holding the delegation must flush modified state (such as modified data) to the server and return the delegation. The conflicting request will not be acted on until the recall is complete. The recall is considered complete when the client returns the delegation or the server times out its wait for the delegation to be returned and revokes the delegation as a result of the timeout. In the interim, the server will either delay responding to conflicting requests or respond to them with NFS4ERR_DELAY. Following the resolution of the recall, the server has the information necessary to grant or deny the second client's request.
调用时，持有委托的客户端必须将修改状态（如修改的数据）刷新到服务器并返回委托。在召回完成之前，不会对冲突请求采取行动。当客户端返回委派或服务器超时等待委派返回并由于超时而撤消委派时，调用被视为完成。在此期间，服务器将延迟响应冲突请求，或使用NFS4ERR_延迟响应冲突请求。在解决召回问题后，服务器具有批准或拒绝第二个客户端请求所需的信息。
At the time the client receives a delegation recall, it may have substantial state that needs to be flushed to the server. Therefore, the server should allow sufficient time for the delegation to be returned since it may involve numerous RPCs to the server. If the server is able to determine that the client is diligently flushing state to the server as a result of the recall, the server MAY extend the usual time allowed for a recall. However, the time allowed for recall completion should not be unbounded.
在客户机接收到委派回调时，它可能具有需要刷新到服务器的实质性状态。因此，服务器应该为委托返回留出足够的时间，因为它可能涉及到服务器的多个RPC。如果服务器能够确定客户机由于调用而正在向服务器刷新状态，则服务器可以延长允许调用的通常时间。然而，召回完成所允许的时间不应该是无界的。
An example of this is when responsibility to mediate opens on a given file is delegated to a client (see Section 10.4). The server will not know what opens are in effect on the client. Without this knowledge, the server will be unable to determine if the access and deny state for the file allows any particular open until the delegation for the file has been returned.
这方面的一个例子是，将对给定文件进行调解的责任委托给客户（见第10.4节）。服务器将不知道在客户端上打开的是什么。如果不知道这一点，服务器将无法确定文件的访问和拒绝状态是否允许任何特定的打开，直到返回文件的委派。
A client failure or a network partition can result in failure to respond to a recall callback. In this case, the server will revoke the delegation; this in turn will render useless any modified state still on the client.
客户端故障或网络分区可能导致无法响应回调。在这种情况下，服务器将撤销委托；这反过来会使客户端上的任何修改状态变得无用。
Clients need to be aware that server implementers may enforce practical limitations on the number of delegations issued. Further, as there is no way to determine which delegations to revoke, the server is allowed to revoke any. If the server is implemented to revoke another delegation held by that client, then the client may be able to determine that a limit has been reached because each new delegation request results in a revoke. The client could then determine which delegations it may not need and preemptively release them.
客户机需要知道，服务器实现者可能会对发出的委托数量实施实际限制。此外，由于无法确定要撤销哪些委托，因此允许服务器撤销任何委托。如果服务器被实现为撤销该客户机持有的另一个委托，那么客户机可能能够确定已达到限制，因为每个新的委托请求都会导致撤销。然后，客户可以确定它可能不需要哪些委托，并先发制人地释放它们。
There are three situations that delegation recovery must deal with:
授权恢复必须处理三种情况：
o Client reboot or restart
o 客户端重新启动或重新启动
o Server reboot or restart (see Section 9.6.3.1)
o 服务器重新启动或重新启动（见第9.6.3.1节）
o Network partition (full or callback-only)
o 网络分区（完全或仅回调）
In the event that the client reboots or restarts, the confirmation of a SETCLIENTID done with an nfs_client_id4 with a new verifier4 value will result in the release of byte-range locks and share reservations. Delegations, however, may be treated a bit differently.
在客户端重新启动或重新启动的情况下，使用新的verifier4值确认nfs_客户端_id4完成的SETCLIENTID将导致释放字节范围锁和共享保留。然而，代表团的待遇可能有所不同。
There will be situations in which delegations will need to be re-established after a client reboots or restarts. The reason for this is the client may have file data stored locally and this data was associated with the previously held delegations. The client will need to re-establish the appropriate file state on the server.
在某些情况下，客户机重新启动或重新启动后，需要重新建立委托关系。原因是客户机可能在本地存储了文件数据，并且该数据与以前持有的委托相关。客户端需要在服务器上重新建立适当的文件状态。
To allow for this type of client recovery, the server MAY allow delegations to be retained after other sorts of locks are released. This implies that requests from other clients that conflict with these delegations will need to wait. Because the normal recall
为了允许这种类型的客户端恢复，服务器可以允许在释放其他类型的锁后保留委派。这意味着与这些委托冲突的其他客户机的请求将需要等待。因为正常的回忆
process may require significant time for the client to flush changed state to the server, other clients need to be prepared for delays that occur because of a conflicting delegation. In order to give clients a chance to get through the reboot process -- during which leases will not be renewed -- the server MAY extend the period for delegation recovery beyond the typical lease expiration period. For open delegations, such delegations that are not released are reclaimed using OPEN with a claim type of CLAIM_DELEGATE_PREV. (See Sections 10.5 and 16.16 for discussions of open delegation and the details of OPEN, respectively.)
该过程可能需要很长的时间，以便客户端将更改的状态刷新到服务器，其他客户端需要为由于委托冲突而发生的延迟做好准备。为了让客户端有机会完成重新启动过程（在此过程中，租约将不被续订），服务器可以将委派恢复时间延长到典型租约到期时间之外。对于开放式委托，使用索赔类型为claim_DELEGATE_PREV的open回收未释放的此类委托。（关于公开授权的讨论和公开授权的详细信息，分别参见第10.5节和第16.16节。）
A server MAY support a claim type of CLAIM_DELEGATE_PREV, but if it does, it MUST NOT remove delegations upon SETCLIENTID_CONFIRM and instead MUST make them available for client reclaim using CLAIM_DELEGATE_PREV. The server MUST NOT remove the delegations until either the client does a DELEGPURGE or one lease period has elapsed from the time -- whichever is later -- of the SETCLIENTID_CONFIRM or the last successful CLAIM_DELEGATE_PREV reclaim.
服务器可能支持claim_DELEGATE_PREV的声明类型，但如果支持，则在SETCLIENTID_CONFIRM时不能删除委托，而是必须使用claim_DELEGATE_PREV使委托可用于客户端回收。在客户端执行DELEGPURGE或从SETCLIENTID\u CONFIRM或上一次成功的CLAIM\u DELEGATE\u PREV Reclain开始（以较晚者为准）经过一个租用期之前，服务器不得删除委托。
Note that the requirement stated above is not meant to imply that, when the server is no longer obliged, as required above, to retain delegation information, it should necessarily dispose of it. Some specific cases are:
请注意，上述要求并不意味着，当服务器不再有义务（如上所述）保留委派信息时，它必须将其处理掉。一些具体情况如下：
o When the period is terminated by the occurrence of DELEGPURGE, deletion of unreclaimed delegations is appropriate and desirable.
o 当该期限因发生授权终止时，删除未申报的授权是适当和可取的。
o When the period is terminated by a lease period elapsing without a successful CLAIM_DELEGATE_PREV reclaim, and that situation appears to be the result of a network partition (i.e., lease expiration has occurred), a server's lease expiration approach, possibly including the use of courtesy locks, would normally provide for the retention of unreclaimed delegations. Even in the event that lease cancellation occurs, such delegation should be reclaimed using CLAIM_DELEGATE_PREV as part of network partition recovery.
o 当租期在未成功索赔_DELEGATE _prevreclain的情况下终止，并且这种情况似乎是网络分区的结果（即发生了租期到期），服务器的租期到期方法，可能包括使用门控锁，通常将规定保留未申报的代表团。即使在发生租约取消的情况下，也应使用CLAIM_DELEGATE_PREV作为网络分区恢复的一部分回收此类委派。
o When the period of non-communicating is followed by a client reboot, unreclaimed delegations should also be reclaimable by use of CLAIM_DELEGATE_PREV as part of client reboot recovery.
o 当非通信期间之后是客户端重新启动时，作为客户端重新启动恢复的一部分，还应使用CLAIM_DELEGATE_PREV回收未回收的委派。
o When the period is terminated by a lease period elapsing without a successful CLAIM_DELEGATE_PREV reclaim, and lease renewal is occurring, the server may well conclude that unreclaimed delegations have been abandoned and consider the situation as one in which an implied DELEGPURGE should be assumed.
o 当一个租赁期结束时，如果没有一个成功的CalimaPraveTyPrv回收和租赁续期正在发生，服务器可以很好地断定未收回的代表团已经被放弃，并认为这种情况是一个隐含的委托清洗应该被假定的情况。
A server that supports a claim type of CLAIM_DELEGATE_PREV MUST support the DELEGPURGE operation, and similarly, a server that supports DELEGPURGE MUST support CLAIM_DELEGATE_PREV. A server that does not support CLAIM_DELEGATE_PREV MUST return NFS4ERR_NOTSUPP if the client attempts to use that feature or performs a DELEGPURGE operation.
支持claim_DELEGATE_PREV的声明类型的服务器必须支持delegpuse操作，同样，支持delegpuse的服务器必须支持claim_DELEGATE_PREV。如果客户端尝试使用该功能或执行delegpuke操作，则不支持CLAIM_DELEGATE_PREV的服务器必须返回NFS4ERR_NOTSUPP。
Support for a claim type of CLAIM_DELEGATE_PREV is often referred to as providing for "client-persistent delegations" in that they allow the use of persistent storage on the client to store data written by the client, even across a client restart. It should be noted that, with the optional exception noted below, this feature requires persistent storage to be used on the client and does not add to persistent storage requirements on the server.
对claim_DELEGATE_PREV的声明类型的支持通常被称为提供“客户端持久性委托”，因为它们允许在客户端上使用持久性存储来存储客户端写入的数据，即使在客户端重新启动时也是如此。应该注意的是，除了下面提到的可选例外情况外，此功能要求在客户端上使用持久性存储，而不会增加服务器上的持久性存储要求。
One good way to think about client-persistent delegations is that for the most part, they function like "courtesy locks", with special semantic adjustments to allow them to be retained across a client restart, which cause all other sorts of locks to be freed. Such locks are generally not retained across a server restart. The one exception is the case of simultaneous failure of the client and server and is discussed below.
考虑客户端持久性委托的一个好方法是，在大多数情况下，它们的功能类似于“礼貌锁”，并进行特殊的语义调整，以允许它们在客户端重新启动时保留，从而释放所有其他类型的锁。这种锁通常不会在服务器重启期间保留。一个例外是客户端和服务器同时发生故障的情况，将在下面讨论。
When the server indicates support of CLAIM_DELEGATE_PREV (implicitly) by returning NFS_OK to DELEGPURGE, a client with a write delegation can use write-back caching for data to be written to the server, deferring the write-back until such time as the delegation is recalled, possibly after intervening client restarts. Similarly, when the server indicates support of CLAIM_DELEGATE_PREV, a client with a read delegation and an open-for-write subordinate to that delegation may be sure of the integrity of its persistently cached copy of the file after a client restart without specific verification of the change attribute.
当服务器通过将NFS_OK返回给DELEGPURGE来表示支持CLAIM_DELEGATE_PREV（隐式）时，具有写委派的客户端可以对要写入服务器的数据使用写回缓存，将写回延迟到调用委派的时间，可能是在干预客户端重新启动之后。类似地，当服务器指示支持CLAIM_DELEGATE_PREV时，具有读委托和从属于该委托的open for write的客户端可以确保在客户端重新启动后其持久缓存的文件副本的完整性，而无需具体验证更改属性。
When the server reboots or restarts, delegations are reclaimed (using the OPEN operation with CLAIM_PREVIOUS) in a similar fashion to byte-range locks and share reservations. However, there is a slight semantic difference. In the normal case, if the server decides that a delegation should not be granted, it performs the requested action (e.g., OPEN) without granting any delegation. For reclaim, the server grants the delegation, but a special designation is applied so that the client treats the delegation as having been granted but recalled by the server. Because of this, the client has the duty to
当服务器重新启动或重新启动时，将以与字节范围锁和共享保留类似的方式回收委派（使用CLAIM_PREVIOUS的OPEN操作）。然而，有一点语义上的差异。在正常情况下，如果服务器决定不应授予委派，它将执行请求的操作（例如，打开），而不授予任何委派。对于回收，服务器授予委托，但应用了一个特殊的指定，以便客户端将委托视为已被授予但被服务器调用。因此，客户有义务
write all modified state to the server and then return the delegation. This process of handling delegation reclaim reconciles three principles of the NFSv4 protocol:
将所有修改的状态写入服务器，然后返回委派。处理委托回收的过程符合NFSv4协议的三个原则：
o Upon reclaim, a client claiming resources assigned to it by an earlier server instance must be granted those resources.
o 回收时，必须向声称由早期服务器实例分配给它的资源的客户机授予这些资源。
o The server has unquestionable authority to determine whether delegations are to be granted and, once granted, whether they are to be continued.
o 服务器无疑有权决定是否授予委托，一旦授予，是否继续。
o The use of callbacks is not to be depended upon until the client has proven its ability to receive them.
o 在客户机证明其有能力接收回调之前，不能依赖回调的使用。
When a client has more than a single open associated with a delegation, state for those additional opens can be established using OPEN operations of type CLAIM_DELEGATE_CUR. When these are used to establish opens associated with reclaimed delegations, the server MUST allow them when made within the grace period.
当客户端有多个与委托关联的打开时，可以使用CLAIM\u DELEGATE\u CUR类型的打开操作来建立这些额外打开的状态。当这些用于建立与回收的委派关联的打开时，服务器必须在宽限期内允许这些打开。
Situations in which there is a series of client and server restarts where there is no restart of both at the same time are dealt with via a combination of CLAIM_DELEGATE_PREV and CLAIM_PREVIOUS reclaim cycles. Persistent storage is needed only on the client. For each server failure, a CLAIM_PREVIOUS reclaim cycle is done, while for each client restart, a CLAIM_DELEGATE_PREV reclaim cycle is done.
通过CLAIM_DELEGATE_PREV和CLAIM_PREVIOUS回收周期的组合来处理一系列客户端和服务器重启的情况，其中客户端和服务器没有同时重启。仅在客户端上需要持久存储。对于每一个服务器故障，都会执行一个CLAIM_上一个回收周期，而对于每一个客户端重新启动，都会执行一个CLAIM_DELEGATE_上一个回收周期。
To deal with the possibility of simultaneous failure of client and server (e.g., a data center power outage), the server MAY persistently store delegation information so that it can respond to a CLAIM_DELEGATE_PREV reclaim request that it receives from a restarting client. This is the one case in which persistent delegation state can be retained across a server restart. A server is not required to store this information, but if it does do so, it should do so for write delegations and for read delegations, during the pendency of which (across multiple client and/or server instances), some open-for-write was done as part of delegation. When the space to persistently record such information is limited, the server should recall delegations in this class in preference to keeping them active without persistent storage recording.
为了处理客户端和服务器同时发生故障的可能性（例如，数据中心断电），服务器可以持续存储委派信息，以便能够响应从重新启动的客户端接收到的CLAIM_DELEGATE_PREV Reclain请求。这是一种可以在服务器重启期间保留持久委派状态的情况。服务器不需要存储此信息，但如果它这样做，则它应该为写委派和读委派存储此信息，在挂起期间（跨多个客户端和/或服务器实例），一些开放供写的操作是作为委派的一部分完成的。当持久记录此类信息的空间有限时，服务器应该调用此类中的委派，而不是在不进行持久存储记录的情况下使委派保持活动状态。
When a network partition occurs, delegations are subject to freeing by the server when the lease renewal period expires. This is similar to the behavior for locks and share reservations, and as for locks and share reservations, it may be modified by support for "courtesy locks" in which locks are not freed in the absence of a conflicting lock request. Whereas for locks and share reservations the freeing of locks will occur immediately upon the appearance of a conflicting
当发生网络分区时，当租约续订期到期时，服务器将释放委派。这类似于锁和共享保留的行为，对于锁和共享保留，可以通过支持“礼貌锁”进行修改，在这种情况下，在没有冲突的锁请求的情况下不会释放锁。而对于锁和共享保留，一旦出现冲突，锁将立即释放
request, for delegations, the server MAY institute a period during which conflicting requests are held off. Eventually, the occurrence of a conflicting request from another client will cause revocation of the delegation.
请求，对于委托，服务器可能会设置一段时间，在这段时间内，冲突的请求会被延迟。最终，来自另一个客户端的冲突请求将导致委托的撤销。
A loss of the callback path (e.g., by a later network configuration change) will have a similar effect in that it can also result in revocation of a delegation. A recall request will fail, and revocation of the delegation will result.
回调路径的丢失（例如，由于以后的网络配置更改）也会产生类似的影响，因为它也会导致委托的撤销。召回请求将失败，并将导致撤销委托。
A client normally finds out about revocation of a delegation when it uses a stateid associated with a delegation and receives one of the errors NFS4ERR_EXPIRED, NFS4ERR_BAD_STATEID, or NFS4ERR_ADMIN_REVOKED (NFS4ERR_EXPIRED indicates that all lock state associated with the client has been lost). It also may find out about delegation revocation after a client reboot when it attempts to reclaim a delegation and receives NFS4ERR_EXPIRED. Note that in the case of a revoked OPEN_DELEGATE_WRITE delegation, there are issues because data may have been modified by the client whose delegation is revoked and, separately, by other clients. See Section 10.5.1 for a discussion of such issues. Note also that when delegations are revoked, information about the revoked delegation will be written by the server to stable storage (as described in Section 9.6). This is done to deal with the case in which a server reboots after revoking a delegation but before the client holding the revoked delegation is notified about the revocation.
当客户端使用与委派关联的stateid并收到以下错误之一时，通常会发现委派的吊销（NFS4ERR_EXPIRED、NFS4ERR_BAD_stateid或NFS4ERR_ADMIN_Revered）（NFS4ERR_EXPIRED表示与客户端关联的所有锁状态都已丢失）。它还可以在客户端重新启动后，当它尝试回收委派并收到NFS4ERR_过期时，发现有关委派吊销的信息。请注意，如果是已撤销的OPEN_DELEGATE_WRITE委派，则会出现问题，因为数据可能已被其委派已撤销的客户端修改，也可能被其他客户端单独修改。有关此类问题的讨论，请参见第10.5.1节。还请注意，当委托被撤销时，服务器将把有关被撤销委托的信息写入稳定存储器（如第9.6节所述）。这样做是为了处理这样的情况，即服务器在撤销委派之后，但在持有已撤销委派的客户端收到有关撤销的通知之前重新启动。
Note that when there is a loss of a delegation, due to a network partition in which all locks associated with the lease are lost, the client will also receive the error NFS4ERR_EXPIRED. This case can be distinguished from other situations in which delegations are revoked by seeing that the associated clientid becomes invalid so that NFS4ERR_STALE_CLIENTID is returned when it is used.
请注意，当由于网络分区丢失与租约相关的所有锁而导致委托丢失时，客户端还将收到错误NFS4ERR_EXPIRED。通过查看关联的clientid变为无效，从而在使用时返回NFS4ERR_STALE_clientid，可以将这种情况与撤销委托的其他情况区分开来。
When NFS4ERR_EXPIRED is returned, the server MAY retain information about the delegations held by the client, deleting those that are invalidated by a conflicting request. Retaining such information will allow the client to recover all non-invalidated delegations using the claim type CLAIM_DELEGATE_PREV, once the SETCLIENTID_CONFIRM is done to recover. Attempted recovery of a delegation that the client has no record of, typically because they were invalidated by conflicting requests, will result in the error NFS4ERR_BAD_RECLAIM. Once a reclaim is attempted for all delegations that the client held, it SHOULD do a DELEGPURGE to allow any remaining server delegation information to be freed.
当返回NFS4ERR_EXPIRED时，服务器可能会保留有关客户端持有的委托的信息，删除那些因冲突请求而无效的委托。保留此类信息将允许客户端在完成SETCLIENTID_CONFIRM恢复后，使用索赔类型claim_DELEGATE_PREV恢复所有未失效的委托。尝试恢复客户端没有记录的委派（通常是因为它们被冲突的请求无效）将导致错误NFS4ERR_BAD_receive。一旦尝试对客户端持有的所有委派进行回收，它应该执行DELEGPURGE以允许释放任何剩余的服务器委派信息。
When applications share access to a set of files, they need to be implemented so as to take account of the possibility of conflicting access by another application. This is true whether the applications in question execute on different clients or reside on the same client.
当应用程序共享对一组文件的访问时，需要实现它们，以便考虑到另一个应用程序访问冲突的可能性。无论所讨论的应用程序是在不同的客户机上执行还是驻留在同一客户机上，都是如此。
Share reservations and byte-range locks are the facilities the NFSv4 protocol provides to allow applications to coordinate access by providing mutual exclusion facilities. The NFSv4 protocol's data caching must be implemented such that it does not invalidate the assumptions that those using these facilities depend upon.
共享保留和字节范围锁是NFSv4协议提供的功能，允许应用程序通过提供互斥功能来协调访问。NFSv4协议的数据缓存的实现必须确保不会使使用这些设施的人所依赖的假设失效。
In order to avoid invalidating the sharing assumptions that applications rely on, NFSv4 clients should not provide cached data to 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 operation.
为了避免应用程序所依赖的共享假设失效，当通过读或写操作获取或修改相同数据无效时，NFSv4客户端不应向应用程序提供缓存数据或代表应用程序修改缓存数据。
Furthermore, in the absence of open delegation (see Section 10.4), two additional rules apply. Note that these rules are obeyed in practice by many NFSv2 and NFSv3 clients.
此外，在没有公开授权的情况下（见第10.4节），适用另外两条规则。请注意，许多NFSv2和NFSv3客户端在实践中都遵守这些规则。
o First, cached data present on a client must be revalidated after doing an OPEN. Revalidating means that the client fetches the change attribute from the server, compares it with the cached change attribute, and, if different, declares the cached data (as well as the cached attributes) as invalid. This is to ensure that 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 OPEN operation includes DENY=WRITE or BOTH, thus terminating a period in which other clients may have had the opportunity to open the file with WRITE access. Clients may choose to do the revalidation more often (such as at OPENs specifying DENY=NONE) to parallel the NFSv3 protocol's practice for the benefit of users assuming this degree of cache revalidation.
o 首先，客户端上存在的缓存数据必须在执行打开后重新验证。重新验证意味着客户端从服务器获取更改属性，将其与缓存的更改属性进行比较，如果不同，则将缓存数据（以及缓存的属性）声明为无效。这是为了确保已打开文件的数据仍然正确地反映在客户端缓存中。至少当客户端的打开操作包括DENY=WRITE或两者时，必须执行此验证，从而终止其他客户端可能有机会使用写访问权限打开文件的时间段。客户机可以选择更频繁地进行重新验证（例如，在指定DENY=NONE的打开处），以并行NFSv3协议的实践，从而使用户能够假定这种缓存重新验证的程度。
Since the change attribute is updated for data and metadata modifications, some client implementers may be tempted to use the time_modify attribute and not the change attribute to validate cached data, so that metadata changes do not spuriously invalidate clean data. The implementer is cautioned against this approach. The change attribute is guaranteed to change for each update to the file, whereas time_modify is guaranteed to change only at the
由于更改属性是为数据和元数据修改而更新的，因此一些客户机实现人员可能会尝试使用time_modify属性而不是change属性来验证缓存的数据，以便元数据更改不会错误地使干净的数据无效。要提醒实施者不要使用这种方法。对于文件的每次更新，change属性都保证更改，而time\u modify只保证在更新时更改
granularity of the time_delta attribute. Use by the client's data cache validation logic of time_modify and not the change attribute runs the risk of the client incorrectly marking stale data as valid.
时间增量属性的粒度。客户机的数据缓存验证逻辑使用time_modify而不是change属性会导致客户机错误地将过时数据标记为有效数据的风险。
o Second, modified data must be flushed to the server before closing a file OPENed for write. This is complementary to the first rule. If the data is not flushed at CLOSE, the revalidation done after the client OPENs a file is unable to achieve its purpose. The other aspect to flushing the data before close is that the data must be committed to stable storage, at the server, before the CLOSE operation is requested by the client. In the case of a server reboot or restart and a CLOSEd file, it may not be possible to retransmit the data to be written to the file -- hence, this requirement.
o 其次，在关闭为写入而打开的文件之前，必须将修改后的数据刷新到服务器。这是对第一条规则的补充。如果关闭时未刷新数据，则在客户端打开文件后进行的重新验证无法达到其目的。关闭前刷新数据的另一个方面是，在客户端请求关闭操作之前，必须将数据提交到服务器上的稳定存储中。在服务器重新启动或重新启动以及文件关闭的情况下，可能无法重新传输要写入文件的数据——因此，这是一个要求。
For those applications that choose to use file locking instead of share reservations to exclude inconsistent file access, there is an analogous set of constraints that apply to client-side data caching. These rules are effective only if the file locking is used in a way that matches in an equivalent way the actual READ and WRITE operations executed. This is as opposed to file locking that is based on pure convention. For example, it is possible to manipulate a two-megabyte file by dividing the file into two one-megabyte regions and protecting access to the two regions by file locks on bytes zero and one. A lock for write on byte zero of the file would represent the right to do READ and WRITE operations on the first region. A lock for write on byte one of the file would represent the right to do READ and WRITE operations on the second region. As long as all applications manipulating the file obey this convention, they will work on a local file system. However, they may not work with the NFSv4 protocol unless clients refrain from data caching.
对于那些选择使用文件锁定而不是共享保留来排除不一致的文件访问的应用程序，有一组类似的约束适用于客户端数据缓存。这些规则只有在文件锁定的使用方式与实际执行的读写操作相匹配时才有效。这与基于纯约定的文件锁定相反。例如，可以通过将文件划分为两个1兆字节的区域，并通过对字节0和字节1的文件锁定来保护对这两个区域的访问，从而操纵一个2兆字节的文件。文件字节0上的写锁定表示对第一个区域执行读写操作的权限。文件字节1上的写锁定表示对第二个区域执行读写操作的权限。只要操作文件的所有应用程序都遵守此约定，它们就可以在本地文件系统上工作。但是，除非客户端避免数据缓存，否则它们可能无法与NFSv4协议一起工作。
The rules for data caching in the file locking environment are:
文件锁定环境中的数据缓存规则包括：
o First, when a client obtains a file lock for a particular region, the data cache corresponding to that region (if any cached data exists) must be revalidated. If the change attribute indicates that the file may have been updated since the cached data was obtained, the client must flush or invalidate the cached data for the newly locked region. A client might choose to invalidate all of the non-modified cached data that it has for the file, but the only requirement for correct operation is to invalidate all of the data in the newly locked region.
o 首先，当客户端获得特定区域的文件锁时，必须重新验证与该区域对应的数据缓存（如果存在任何缓存数据）。如果change属性指示文件可能在获取缓存数据后已更新，则客户端必须刷新或使新锁定区域的缓存数据无效。客户机可能会选择使文件中所有未修改的缓存数据无效，但正确操作的唯一要求是使新锁定区域中的所有数据无效。
o Second, before releasing a write lock for a region, all modified data for that region must be flushed to the server. The modified data must also be written to stable storage.
o 其次，在释放区域的写锁之前，必须将该区域的所有修改数据刷新到服务器。修改后的数据还必须写入稳定的存储器。
Note that flushing data to the server and the invalidation of cached data must reflect the actual byte ranges locked or unlocked. Rounding these up or down to reflect client cache block boundaries will cause problems if not carefully done. For example, writing a modified block when only half of that block is within an area being unlocked may cause invalid modification to the region outside the unlocked area. This, in turn, may be part of a region locked by another client. Clients can avoid this situation by synchronously performing portions of WRITE operations that overlap that portion (initial or final) that is not a full block. Similarly, invalidating a locked area that is not an integral number of full buffer blocks would require the client to read one or two partial blocks from the server if the revalidation procedure shows that the data that the client possesses may not be valid.
请注意，将数据刷新到服务器和缓存数据的失效必须反映锁定或解锁的实际字节范围。如果不小心，向上或向下舍入这些值以反映客户端缓存块边界将导致问题。例如，当修改后的块只有一半在解锁区域内时写入该块可能会导致对解锁区域外区域的无效修改。反过来，这可能是另一个客户端锁定的区域的一部分。客户端可以通过同步执行与非完整块部分（初始或最终）重叠的写入操作部分来避免这种情况。类似地，如果重新验证过程表明客户机拥有的数据可能无效，则使非整数个完整缓冲区块的锁定区域无效将需要客户机从服务器读取一个或两个部分块。
The data that is written to the server as a prerequisite to the unlocking of a region must be written, at the server, to stable storage. The client may accomplish this either with synchronous writes or by following asynchronous writes with a COMMIT operation. This is required because retransmission of the modified data after a server reboot might conflict with a lock held by another client.
作为解锁区域的先决条件写入服务器的数据必须在服务器上写入稳定存储。客户机可以通过同步写入或使用提交操作跟踪异步写入来完成这一点。这是必需的，因为在服务器重新启动后重新传输修改后的数据可能会与另一个客户端持有的锁冲突。
A client implementation may choose to accommodate applications that use byte-range locking in non-standard ways (e.g., using a byte-range lock as a global semaphore) by flushing to the server more data upon a LOCKU than is covered by the locked range. This may include modified data within files other than the one for which the unlocks are being done. In such cases, the client must not interfere with applications whose READs and WRITEs are being done only within the bounds of record locks that the application holds. For example, an application locks a single byte of a file and proceeds to write that single byte. A client that chose to handle a LOCKU by flushing all modified data to the server could validly write that single byte in response to an unrelated unlock. However, it would not be valid to write the entire block in which that single written byte was located since it includes an area that is not locked and might be locked by another client. Client implementations can avoid this problem by dividing files with modified data into those for which all modifications are done to areas covered by an appropriate byte-range lock and those for which there are modifications not covered by a byte-range lock. Any writes done for the former class of files must not include areas not locked and thus not modified on the client.
客户机实现可以通过向服务器刷新锁上超过锁定范围覆盖的更多数据来选择以非标准方式（例如，使用字节范围锁作为全局信号量）使用字节范围锁定的应用程序。这可能包括文件中的修改数据，而不是正在进行解锁的文件。在这种情况下，客户机不得干扰仅在应用程序持有的记录锁的范围内进行读写的应用程序。例如，应用程序锁定文件的一个字节并继续写入该字节。选择通过将所有修改的数据刷新到服务器来处理锁定的客户端可以有效地写入该单个字节以响应不相关的解锁。但是，写入单个写入字节所在的整个块是无效的，因为它包含一个未锁定的区域，并且可能被另一个客户端锁定。客户端实现可以通过将具有修改数据的文件划分为对适当字节范围锁覆盖的区域进行所有修改的文件和未被字节范围锁覆盖的文件来避免此问题。为前一类文件执行的任何写入操作都不得包括未锁定的区域，因此也不得在客户端上修改这些区域。
Client-side data caching needs to respect mandatory file locking when it is in effect. The presence of mandatory file locking for a given file is indicated when the client gets back NFS4ERR_LOCKED from a READ or WRITE on a file it has an appropriate share reservation for. When mandatory locking is in effect for a file, the client must check for an appropriate file lock for data being read or written. If a lock exists for the range being read or written, the client may satisfy the request using the client's validated cache. If an appropriate file lock is not held for the range of the READ or WRITE, the READ or WRITE request must not be satisfied by the client's cache and the request must be sent to the server for processing. When a READ or WRITE request partially overlaps a locked region, the request should be subdivided into multiple pieces with each region (locked or not) treated appropriately.
客户端数据缓存在生效时需要遵守强制文件锁定。当客户端从其具有适当共享保留的文件的读或写操作中恢复NFS4ERR_LOCKED时，将指示给定文件是否存在强制文件锁定。当强制锁定对文件生效时，客户端必须为正在读取或写入的数据检查适当的文件锁定。如果正在读取或写入的范围存在锁，则客户端可以使用客户端的已验证缓存满足请求。如果没有为读或写的范围保留适当的文件锁，则客户端缓存不能满足读或写请求，并且必须将请求发送到服务器进行处理。当读或写请求与锁定区域部分重叠时，应将请求细分为多个部分，并适当处理每个区域（锁定或未锁定）。
When clients cache data, the file data needs to be organized according to the file system object to which the data belongs. For NFSv3 clients, the typical practice has been to assume for the purpose of caching that distinct filehandles represent distinct file system objects. The client then has the choice to organize and maintain the data cache on this basis.
当客户端缓存数据时，需要根据数据所属的文件系统对象组织文件数据。对于NFSv3客户机，典型的做法是为了缓存，假定不同的文件句柄表示不同的文件系统对象。然后，客户机可以在此基础上选择组织和维护数据缓存。
In the NFSv4 protocol, there is now the possibility of having significant deviations from a "one filehandle per object" model, because a filehandle may be constructed on the basis of the object's pathname. Therefore, clients need a reliable method to determine if two filehandles designate the same file system object. If clients were simply to assume that all distinct filehandles denote distinct objects and proceed to do data caching on this basis, caching inconsistencies would arise between the distinct client-side objects that mapped to the same server-side object.
在NFSv4协议中，现在可能与“每个对象一个文件句柄”模型存在重大偏差，因为文件句柄可以基于对象的路径名构建。因此，客户端需要一种可靠的方法来确定两个文件句柄是否指定相同的文件系统对象。如果客户端只是假设所有不同的文件句柄都表示不同的对象，并在此基础上继续进行数据缓存，那么映射到同一服务器端对象的不同客户端对象之间就会出现缓存不一致的情况。
By providing a method to differentiate filehandles, the NFSv4 protocol alleviates a potential functional regression in comparison with the NFSv3 protocol. Without this method, caching inconsistencies within the same client could occur, and this has not been present in previous versions of the NFS protocol. Note that it is possible to have such inconsistencies with applications executing on multiple clients, but that is not the issue being addressed here.
通过提供一种区分文件句柄的方法，与NFSv3协议相比，NFSv4协议减轻了潜在的功能回归。如果没有此方法，可能会在同一客户机中发生缓存不一致，这在以前版本的NFS协议中是不存在的。请注意，在多个客户端上执行的应用程序可能存在这种不一致，但这不是本文要解决的问题。
For the purposes of data caching, the following steps allow an NFSv4 client to determine whether two distinct filehandles denote the same server-side object:
出于数据缓存的目的，以下步骤允许NFSv4客户端确定两个不同的文件句柄是否表示相同的服务器端对象：
o If GETATTR directed to two filehandles returns different values of the fsid attribute, then the filehandles represent distinct objects.
o 如果指向两个filehandles的GETATTR返回不同的fsid属性值，则filehandles表示不同的对象。
o If GETATTR for any file with an fsid that matches the fsid of the two filehandles in question returns a unique_handles attribute with a value of TRUE, then the two objects are distinct.
o 如果fsid与两个文件句柄的fsid相匹配的任何文件的GETATTR返回一个值为TRUE的唯一_handles属性，则这两个对象是不同的。
o If GETATTR directed to the two filehandles does not return the fileid attribute for both of the handles, then it cannot be determined whether the two objects are the same. Therefore, operations that depend on that knowledge (e.g., client-side data caching) cannot be done reliably. Note that if GETATTR does not return the fileid attribute for both filehandles, it will return it for neither of the filehandles, since the fsid for both filehandles is the same.
o 如果指向两个FileHandle的GETATTR没有为这两个句柄返回fileid属性，则无法确定这两个对象是否相同。因此，依赖于该知识的操作（例如，客户端数据缓存）无法可靠地完成。请注意，如果GETATTR没有为两个filehandles返回fileid属性，那么它将为两个filehandles都返回该属性，因为两个filehandles的fsid相同。
o If GETATTR directed to the two filehandles returns different values for the fileid attribute, then they are distinct objects.
o 如果指向两个FileHandle的GETATTR为fileid属性返回不同的值，则它们是不同的对象。
o Otherwise, they are the same object.
o 否则，它们是相同的对象。
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 delegation is recallable, since the circumstances that allowed for the delegation are subject to change. In particular, the server may receive a conflicting OPEN from another client; the server must recall the delegation before deciding whether the OPEN from the other client may be granted. Making a delegation is up to the server, and clients should not assume that any particular OPEN either will or will not result in an open delegation. The following is a typical set of conditions that servers might use in deciding whether OPEN should be delegated:
打开文件时，服务器可以将该文件的打开和关闭的进一步处理委托给打开的客户端。任何此类授权都是可撤销的，因为允许授权的情况可能会发生变化。具体地，服务器可以从另一客户端接收冲突的OPEN；服务器必须在决定是否可以授予从其他客户端打开的权限之前调用委托。委托由服务器决定，客户机不应认为任何特定的开放式委托会或不会导致开放式委托。以下是服务器在决定是否委派OPEN时可能使用的一组典型条件：
o The client must be able to respond to the server's callback requests. The server will use the CB_NULL procedure for a test of callback ability.
o 客户端必须能够响应服务器的回调请求。服务器将使用CB_NULL过程来测试回调能力。
o The client must have responded properly to previous recalls.
o 客户必须对之前的召回做出正确响应。
o There must be no current open conflicting with the requested delegation.
o 必须没有与请求的委派冲突的当前打开。
o There should be no current delegation that conflicts with the delegation being requested.
o 当前不应存在与所请求的授权冲突的授权。
o The probability of future conflicting open requests should be low, based on the recent history of the file.
o 根据文件最近的历史记录，未来发生冲突的开放请求的概率应该很低。
o The existence of any server-specific semantics of OPEN/CLOSE that would make the required handling incompatible with the prescribed handling that the delegated client would apply (see below).
o 存在任何特定于服务器的打开/关闭语义，这将使所需的处理与委托客户端将应用的指定处理不兼容（见下文）。
There are two types of open delegations: OPEN_DELEGATE_READ and OPEN_DELEGATE_WRITE. An OPEN_DELEGATE_READ delegation allows a client to handle, on its own, requests to open a file for reading that do not deny read access to others. It MUST, however, continue to send all requests to open a file for writing to the server. Multiple OPEN_DELEGATE_READ delegations may be outstanding simultaneously and do not conflict. An OPEN_DELEGATE_WRITE delegation allows the client to handle, on its own, all opens. Only one OPEN_DELEGATE_WRITE delegation may exist for a given file at a given time, and it is inconsistent with any OPEN_DELEGATE_READ delegations.
开放式委托有两种类型：开放式委托读取和开放式委托写入。OPEN_DELEGATE_READ delegation允许客户端自行处理打开文件进行读取的请求，而不拒绝其他客户端的读取访问。但是，它必须继续发送打开文件以写入服务器的所有请求。多个开放式委托书可以同时未完成且不冲突。OPEN_DELEGATE_WRITE委托允许客户端自行处理所有打开的文件。给定文件在给定时间只能存在一个OPEN_DELEGATE_WRITE委托，它与任何OPEN_DELEGATE_READ委托不一致。
When a single client holds an OPEN_DELEGATE_READ delegation, it is assured that no other client may modify the contents or attributes of the file. If more than one client holds an OPEN_DELEGATE_READ delegation, then the contents and attributes of that file are not allowed to change. When a client has an OPEN_DELEGATE_WRITE delegation, it may modify the file data since no other client will be accessing the file's data. The client holding an OPEN_DELEGATE_WRITE delegation may only affect file attributes that are intimately connected with the file data: size, time_modify, and change.
当单个客户机持有OPEN_DELEGATE_READ委托时，可以确保没有其他客户机可以修改文件的内容或属性。如果有多个客户端持有OPEN_DELEGATE_READ委派，则不允许更改该文件的内容和属性。当一个客户端有一个OPEN_DELEGATE_WRITE委托时，它可能会修改文件数据，因为没有其他客户端会访问该文件的数据。持有OPEN_DELEGATE_WRITE delegation的客户端可能只影响与文件数据密切相关的文件属性：大小、时间、修改和更改。
When a client has an open delegation, it does not send OPENs or CLOSEs to the server but updates the appropriate status internally. For an OPEN_DELEGATE_READ delegation, opens that cannot be handled locally (opens for write or that deny read access) must be sent to the server.
当客户机具有打开的委派时，它不会向服务器发送打开或关闭，而是在内部更新相应的状态。对于OPEN_DELEGATE_READ delegation，必须将无法在本地处理的打开（打开以进行写入或拒绝读取访问）发送到服务器。
When an open delegation is made, the response to the OPEN contains an open delegation structure that specifies the following:
进行开放式委派时，对开放式委派的响应包含一个开放式委派结构，该结构指定以下内容：
o the type of delegation (read or write)
o 委托的类型（读或写）
o space limitation information to control flushing of data on close (OPEN_DELEGATE_WRITE delegation only; see Section 10.4.1)
o 用于控制关闭时数据刷新的空间限制信息（仅开放\u委托\u写入委托；参见第10.4.1节）
o an nfsace4 specifying read and write permissions
o 指定读写权限的nfsace4
o a stateid to represent the delegation for READ and WRITE
o 表示读写委托的stateid
The delegation stateid is separate and distinct from the stateid for the OPEN proper. The standard stateid, unlike the delegation stateid, is associated with a particular open-owner and will continue to be valid after the delegation is recalled and the file remains open.
委托stateid是独立的，并且与开放数据库的stateid不同。与委托stateid不同，标准stateid与特定的打开所有者相关联，并且在调用委托并且文件保持打开状态后将继续有效。
When a request internal to the client is made to open a file and open delegation is in effect, it will be accepted or rejected solely on the basis of the following conditions. Any requirement for other checks to be made by the delegate should result in open delegation being denied so that the checks can be made by the server itself.
当向客户发出打开文件的内部请求且“打开委托”生效时，将仅根据以下条件接受或拒绝该请求。委托进行其他检查的任何要求都应导致开放委托被拒绝，以便服务器本身可以进行检查。
o The access and deny bits for the request and the file, as described in Section 9.9.
o 请求和文件的访问和拒绝位，如第9.9节所述。
o The read and write permissions, as determined below.
o 读取和写入权限，如下所示。
The nfsace4 passed with delegation can be used to avoid frequent ACCESS calls. The permission check should be as follows:
通过委派传递的nfsace4可用于避免频繁的访问调用。权限检查应如下所示：
o If the nfsace4 indicates that the open may be done, then it should be granted without reference to the server.
o 如果nfsace4指示可以完成打开，则应在不参考服务器的情况下授予打开。
o 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 answer.
o 如果nfsace4指示可能无法打开，则必须向服务器发送访问请求以获得最终答案。
The server may return an nfsace4 that is more restrictive than the actual ACL of the file. This includes an nfsace4 that specifies denial of all access. Note that some common practices, such as mapping the traditional user "root" to the user "nobody", may make it incorrect to return the actual ACL of the file in the delegation response.
服务器可能返回比文件的实际ACL更严格的nfsace4。这包括指定拒绝所有访问的nfsace4。请注意，一些常见做法（如将传统用户“root”映射到用户“nobody”）可能会导致在委派响应中返回文件的实际ACL不正确。
The use of delegation, together with various other forms of caching, creates the possibility that no server authentication will ever be performed for a given user since all of the user's requests might be satisfied locally. Where the client is depending on the server for authentication, the client should be sure authentication occurs for each user by use of the ACCESS operation. This should be the case even if an ACCESS operation would not be required otherwise. As mentioned before, the server may enforce frequent authentication by returning an nfsace4 denying all access with every open delegation.
委托的使用，加上各种其他形式的缓存，使得不会对给定用户执行服务器身份验证，因为用户的所有请求都可能在本地得到满足。当客户端依赖服务器进行身份验证时，客户端应确保通过使用访问操作为每个用户进行身份验证。即使不需要访问操作，也应如此。如前所述，服务器可以通过返回一个nfsace4来强制执行频繁身份验证，该nfsace4拒绝每个打开的委托的所有访问。
OPEN delegation allows much of the message overhead associated with the opening and closing files to be eliminated. An open when an open delegation is in effect does not require that a validation message be sent to the server unless there exists a potential for conflict with the requested share mode. The continued endurance of the "OPEN_DELEGATE_READ delegation" provides a guarantee that no OPEN for write and thus no write has occurred that did not originate from this client. Similarly, when closing a file opened for write and if OPEN_DELEGATE_WRITE delegation is in effect, the data written does not have to be flushed to the server until the open delegation is recalled. The continued endurance of the open delegation provides a guarantee that no open and thus no read or write has been done by another client.
开放式委派允许消除和打开和关闭文件相关的大部分消息开销。开放式委派生效时的开放式委派不要求向服务器发送验证消息，除非与请求的共享模式存在潜在冲突。“开放式委托-读取委托”的持续持久性保证了不会出现开放式写操作，因此不会发生非源于此客户端的写操作。类似地，在关闭为写入而打开的文件时，如果“打开的委托”或“写入的委托”生效，则在调用“打开的委托”之前，写入的数据不必刷新到服务器。开放委托的持续持久性保证了另一个客户机没有进行开放操作，因此也没有进行读写操作。
For the purposes of open delegation, READs and WRITEs done without an OPEN (anonymous and READ bypass stateids) are treated as the functional equivalents of a corresponding type of OPEN. READs and WRITEs done with an anonymous stateid done by another client will force the server to recall an OPEN_DELEGATE_WRITE delegation. A WRITE with an anonymous stateid done by another client will force a recall of OPEN_DELEGATE_READ delegations. The handling of a READ bypass stateid is identical, except that a READ done with a READ bypass stateid will not force a recall of an OPEN_DELEGATE_READ delegation.
出于开放式委托的目的，在没有open（匿名和读绕过stateID）的情况下进行的读写操作被视为相应类型的open的功能等价物。由另一个客户端使用匿名stateid执行的读写操作将强制服务器调用OPEN_DELEGATE_WRITE委派。由另一个客户端使用匿名stateid进行的写入将强制调用OPEN_DELEGATE_READ委托。读取旁路stateid的处理是相同的，除了使用读取旁路stateid完成的读取不会强制调用打开的\u委托\u读取委托。
With delegations, a client is able to avoid writing data to the server when the CLOSE of a file is serviced. The file close system call is the usual point at which the client is notified of a lack of stable storage for the modified file data generated by the application. At the close, file data is written to the server, and through normal accounting the server is able to determine if the available file system space for the data has been exceeded (i.e., the server returns NFS4ERR_NOSPC or NFS4ERR_DQUOT). This accounting includes quotas. The introduction of delegations requires that an alternative method be in place for the same type of communication to occur between client and server.
通过委托，客户机可以避免在文件关闭时向服务器写入数据。文件关闭系统调用是一个通常的点，在这个点上，客户端会被通知缺少用于应用程序生成的修改文件数据的稳定存储。在结束时，文件数据被写入服务器，通过正常记帐，服务器能够确定是否超出了数据的可用文件系统空间（即，服务器返回NFS4ERR_NOSPC或NFS4ERR_DQUOT）。这种核算包括配额。委托的引入要求为客户机和服务器之间发生相同类型的通信提供一种替代方法。
In the delegation response, the server provides either the limit of the size of the file or the number of modified blocks and associated block size. The server must ensure that the client will be able to flush to the server data of a size equal to that provided in the original delegation. The server must make this assurance for all outstanding delegations. Therefore, the server must be careful in its management of available space for new or modified data, taking into account available file system space and any applicable quotas. The server can recall delegations as a result of managing the
在委托响应中，服务器提供文件大小的限制或修改的块数和关联的块大小。服务器必须确保客户端能够刷新到服务器上的数据，其大小等于原始委托中提供的数据大小。服务器必须为所有未完成的委派做出此保证。因此，服务器在管理新数据或修改数据的可用空间时必须谨慎，同时考虑可用文件系统空间和任何适用的配额。服务器可以通过管理
available file system space. The client should abide by the server's state space limits for delegations. If the client exceeds the stated limits for the delegation, the server's behavior is undefined.
可用的文件系统空间。客户机应该遵守服务器的状态空间限制。如果客户端超过了指定的委托限制，则服务器的行为未定义。
Based on server conditions, quotas, or available file system space, the server may grant OPEN_DELEGATE_WRITE delegations with very restrictive space limitations. The limitations may be defined in a way that will always force modified data to be flushed to the server on close.
根据服务器条件、配额或可用的文件系统空间，服务器可以授予具有非常严格的空间限制的OPEN_DELEGATE_WRITE委派。这些限制的定义方式可能总是强制在关闭时将修改后的数据刷新到服务器。
With respect to authentication, flushing modified data to the server after a CLOSE has occurred may be problematic. For example, the user of the application may have logged off the client, and unexpired authentication credentials may not be present. In this case, the client may need to take special care to ensure that local unexpired credentials will in fact be available. One way that this may be accomplished is by tracking the expiration time of credentials and flushing data well in advance of their expiration.
关于身份验证，在关闭后将修改的数据刷新到服务器可能会有问题。例如，应用程序的用户可能已注销客户端，并且未过期的身份验证凭据可能不存在。在这种情况下，客户端可能需要特别小心，以确保本地未过期的凭据实际上可用。实现这一点的一种方法是跟踪凭据的过期时间，并在其过期之前刷新数据。
When a client holds an OPEN_DELEGATE_WRITE delegation, lock operations may be performed locally. This includes those required for mandatory file locking. This can be done since the delegation implies that there can be no conflicting locks. Similarly, all of the revalidations that would normally be associated with obtaining locks and the flushing of data associated with the releasing of locks need not be done.
当客户端持有OPEN_DELEGATE_WRITE委派时，可以在本地执行锁定操作。这包括强制文件锁定所需的文件。这是可以做到的，因为委托意味着不可能有冲突的锁。类似地，通常与获取锁相关的所有重新验证以及与释放锁相关的数据刷新都不需要完成。
When a client holds an OPEN_DELEGATE_READ delegation, lock operations are not performed locally. All lock operations, including those requesting non-exclusive locks, are sent to the server for resolution.
当客户端持有OPEN_DELEGATE_READ委派时，不会在本地执行锁定操作。所有锁操作（包括请求非独占锁的操作）都将发送到服务器进行解析。
The server needs to employ special handling for a GETATTR where the target is a file that has an OPEN_DELEGATE_WRITE delegation in effect. The reason for this is that the client holding the OPEN_DELEGATE_WRITE delegation may have modified the data, and the server needs to reflect this change to the second client that submitted the GETATTR. Therefore, the client holding the OPEN_DELEGATE_WRITE delegation needs to be interrogated. The server will use the CB_GETATTR operation. The only attributes that the server can reliably query via CB_GETATTR are size and change.
服务器需要对GETATTR进行特殊处理，其中目标是一个有效的OPEN_DELEGATE_WRITE委托的文件。这是因为持有OPEN_DELEGATE_WRITE委托的客户端可能修改了数据，服务器需要将此更改反映到提交GETATTR的第二个客户端。因此，需要询问持有OPEN_DELEGATE_WRITE委托的客户机。服务器将使用CB_GETATTR操作。服务器可以通过CB_GETATTR可靠查询的唯一属性是大小和更改。
Since CB_GETATTR is being used to satisfy another client's GETATTR request, the server only needs to know if the client holding the delegation has a modified version of the file. If the client's copy of the delegated file is not modified (data or size), the server can satisfy the second client's GETATTR request from the attributes stored locally at the server. If the file is modified, the server only needs to know about this modified state. If the server determines that the file is currently modified, it will respond to the second client's GETATTR as if the file had been modified locally at the server.
由于CB_GETATTR用于满足另一个客户机的GETATTR请求，因此服务器只需要知道持有委托的客户机是否具有文件的修改版本。如果委托文件的客户端副本未被修改（数据或大小），则服务器可以从服务器本地存储的属性满足第二个客户端的GETATTR请求。如果文件被修改，服务器只需要知道此修改状态。如果服务器确定该文件当前已修改，它将响应第二个客户端的GETATTR，就像该文件已在服务器本地修改一样。
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 method of communicating the modified state of the file. For the size attribute, the client will report its current view of the file size. For the change attribute, the handling is more involved.
由于更改属性的形式由服务器决定，并且对客户机来说是不透明的，因此客户机和服务器需要就传递文件修改状态的方法达成一致。对于“大小”属性，客户端将报告其文件大小的当前视图。对于change属性，处理更为复杂。
For the client, the following steps will be taken when receiving an OPEN_DELEGATE_WRITE delegation:
对于客户端，在接收OPEN_DELEGATE_WRITE委派时，将采取以下步骤：
o The value of the change attribute will be obtained from the server and cached. Let this value be represented by c.
o 更改属性的值将从服务器获取并缓存。让这个值用c表示。
o The client will create a value greater than c that will be used for communicating that modified data is held at the client. Let this value be represented by d.
o 客户端将创建一个大于c的值，该值将用于通信客户端保存的修改数据。让这个值用d表示。
o When the client is queried via CB_GETATTR for the change attribute, it checks to see if it holds modified data. If the file is modified, the value d is returned for the change attribute value. If this file is not currently modified, the client returns the value c for the change attribute.
o 当通过CB_GETATTR查询客户机的change属性时，它会检查客户机是否保存修改后的数据。如果文件被修改，则会为更改属性值返回值d。如果当前未修改此文件，则客户端将返回change属性的值c。
For simplicity of implementation, the client MAY for each CB_GETATTR return the same value d. This is true even if, between successive CB_GETATTR operations, the client again modifies in the file's data or 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 server that the client holds modified data. Therefore, the value of d may always be c + 1.
为简化实现，客户机可能会为每个CB_GETATTR返回相同的值d。即使在连续的CB_GETATTR操作之间，客户端再次修改其缓存中文件的数据或元数据，这也是正确的。客户机可以返回相同的值，因为唯一的要求是客户机能够向服务器指示客户机持有修改后的数据。因此，d的值可能总是c+1。
While the change attribute is opaque to the client in the sense that it has no idea what units of time, if any, the server is counting change with, it is not opaque in that the client has to treat it as an unsigned integer, and the server has to be able to see the results of the client's changes to that integer. Therefore, the server MUST encode the change attribute in network byte order when sending it to the client. The client MUST decode it from network byte order to its
虽然change属性对客户端来说是不透明的，因为它不知道服务器使用什么时间单位（如果有的话）计算更改，但它不是不透明的，因为客户端必须将其视为无符号整数，服务器必须能够看到客户端对该整数所做更改的结果。因此，服务器在将更改属性发送到客户端时，必须按网络字节顺序对其进行编码。客户端必须将其从网络字节顺序解码为
native order when receiving it, and the client MUST encode it in network byte order when sending it to the server. For this reason, the change attribute is defined as an unsigned integer rather than an opaque array of bytes.
接收时按本机顺序，客户端发送到服务器时必须按网络字节顺序对其进行编码。因此，change属性被定义为无符号整数，而不是不透明的字节数组。
For the server, the following steps will be taken when providing an OPEN_DELEGATE_WRITE delegation:
对于服务器，在提供OPEN_DELEGATE_WRITE委派时将采取以下步骤：
o Upon providing an OPEN_DELEGATE_WRITE delegation, the server will cache a copy of the change attribute in the data structure it uses to record the delegation. Let this value be represented by sc.
o 在提供OPEN_DELEGATE_WRITE委派后，服务器将在用于记录委派的数据结构中缓存change属性的副本。让这个值用sc表示。
o When a second client sends a GETATTR operation on the same file to the server, the server obtains the change attribute from the first client. Let this value be cc.
o 当第二个客户机向服务器发送同一文件上的GETATTR操作时，服务器从第一个客户机获取change属性。将此值设为cc。
o 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 time_modify (for example) to the second client.
o 如果值cc等于sc，则不会修改文件，服务器会将更改、时间\元数据和时间\修改（例如）的当前值返回给第二个客户端。
o 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 a future time. The server then uses its current time to construct attribute values for time_metadata and time_modify. A new value of sc, which we will call nsc, is computed by the server, such that nsc >= sc + 1. The server then returns the constructed time_metadata, time_modify, and nsc values to the requester. The server replaces sc in the delegation record with nsc. To prevent the possibility of time_modify, time_metadata, and change from appearing to go backward (which would happen if the client holding the delegation fails to write its modified data to the server before the delegation is revoked or returned), the server SHOULD update the file's metadata record with the constructed attribute values. For reasons of reasonable performance, committing the constructed attribute values to stable storage is OPTIONAL.
o 如果值cc不等于sc，则文件当前在第一个客户端修改，并且很可能在将来在服务器上修改。然后，服务器使用其当前时间为time\u元数据和time\u modify构造属性值。服务器会计算一个新的sc值，我们称之为nsc，这样nsc>=sc+1。然后，服务器将构造的time_元数据、time_modify和nsc值返回给请求者。服务器用nsc替换委派记录中的sc。为了防止时间\修改、时间\元数据和更改出现倒退的可能性（如果持有委托的客户端在撤销或返回委托之前未能将其修改的数据写入服务器，则会发生这种情况），服务器应使用构造的属性值更新文件的元数据记录。出于合理性能的考虑，将构造的属性值提交到稳定存储是可选的。
As discussed earlier in this section, the client MAY return the same cc value on subsequent CB_GETATTR calls, even if the file was modified in the client's cache yet again between successive CB_GETATTR calls. Therefore, the server must assume that the file has been modified yet again and MUST take care to ensure that the new nsc it constructs and returns is greater than the previous nsc it returned. An example implementation's delegation record would satisfy this mandate by including a boolean field (let us call it "modified") that is set to FALSE when the delegation is granted, and an sc value set at the time of grant to the change attribute value. The modified field would be set to TRUE the first time cc != sc and
如本节前面所述，客户机可能会在后续CB_GETATTR调用中返回相同的cc值，即使在连续CB_GETATTR调用之间再次在客户机缓存中修改了文件。因此，服务器必须假设文件已再次修改，并且必须注意确保它构造和返回的新nsc大于它返回的前一个nsc。一个示例实现的委托记录将通过包含一个布尔字段（我们称之为“修改”）来满足这一要求，该布尔字段在授予委托时设置为FALSE，以及在授予更改属性值时设置的sc值。修改后的字段将在第一次抄送时设置为TRUE！=理学士及
would stay TRUE until the delegation is returned or revoked. The processing for constructing nsc, time_modify, and time_metadata would use this pseudo-code:
将保持为TRUE，直到委托被返回或撤销。用于构造nsc、time\u modify和time\u元数据的处理将使用以下伪代码：
if (!modified) {
do CB_GETATTR for change and size;
if (!modified) {
do CB_GETATTR for change and size;
if (cc != sc)
modified = TRUE;
} else {
do CB_GETATTR for size;
}
if (cc != sc)
modified = TRUE;
} else {
do CB_GETATTR for size;
}
if (modified) {
sc = sc + 1;
time_modify = time_metadata = current_time;
update sc, time_modify, time_metadata into file's metadata;
}
if (modified) {
sc = sc + 1;
time_modify = time_metadata = current_time;
update sc, time_modify, time_metadata into file's metadata;
}
This would return to the client (that sent GETATTR) the attributes it requested but would make sure that size comes from what CB_GETATTR returned. The server would not update the file's metadata with the client's modified size.
这将向客户端（发送GETATTR的客户端）返回它请求的属性，但会确保大小来自CB_GETATTR返回的属性。服务器不会使用客户端修改的大小更新文件的元数据。
In the case that the file attribute size is different than the server's current value, the server treats this as a modification regardless of the value of the change attribute retrieved via CB_GETATTR and responds to the second client as in the last step.
如果文件属性大小不同于服务器的当前值，则服务器将此视为修改，而不管通过CB_GETATTR检索的更改属性的值如何，并像上一步一样响应第二个客户端。
This methodology resolves issues of clock differences between client and server and other scenarios where the use of CB_GETATTR breaks down.
这种方法解决了客户机和服务器之间的时钟差异问题，以及使用CB_GETATTR出现故障的其他场景。
It should be noted that the server is under no obligation to use CB_GETATTR; therefore, the server MAY simply recall the delegation to avoid its use.
需要注意的是，服务器没有义务使用CB_GETATTR；因此，服务器可以简单地调用委派以避免使用委派。
The following events necessitate the recall of an open delegation:
以下事件需要召回一个公开的代表团：
o Potentially conflicting OPEN request (or READ/WRITE done with "special" stateid)
o 潜在冲突的开放请求（或使用“特殊”stateid完成读/写操作）
o SETATTR issued by another client
o 由另一个客户端发出的SETATTR
o REMOVE request for the file
o 删除对该文件的请求
o RENAME request for the file as either source or target of the RENAME
o 将文件重命名为重命名的源或目标的请求
Whether a RENAME of a directory in the path leading to the file results in the recall of an open delegation depends on the semantics of the server file system. If that file system denies such RENAMEs when a file is open, the recall must be performed to determine whether the file in question is, in fact, open.
对指向文件的路径中的目录进行重命名是否会导致调用打开的委托，这取决于服务器文件系统的语义。如果文件系统在文件打开时拒绝此类重命名，则必须执行回调以确定所涉及的文件实际上是否已打开。
In addition to the situations above, the server may choose to recall open delegations at any time if resource constraints make it advisable to do so. Clients should always be prepared for the possibility of a recall.
除上述情况外，如果资源限制允许，服务器可以随时选择召回开放的委托。客户应随时做好召回的准备。
When a client receives a recall for an open delegation, it needs to update state on the server before returning the delegation. These same updates must be done whenever a client chooses to return a delegation voluntarily. The following items of state need to be dealt with:
当客户机收到打开的委派的回调时，它需要在返回委派之前更新服务器上的状态。每当客户机选择自愿返回委托时，必须执行这些相同的更新。需要处理下列国家事项：
o If the file associated with the delegation is no longer open and no previous CLOSE operation has been sent to the server, a CLOSE operation must be sent to the server.
o 如果与委派关联的文件不再打开，并且以前的关闭操作未发送到服务器，则必须向服务器发送关闭操作。
o If a file has other open references at the client, then OPEN operations must be sent to the server. The appropriate stateids will be provided by the server for subsequent use by the client since the delegation stateid will not longer be valid. These OPEN requests are done with the claim type of CLAIM_DELEGATE_CUR. This will allow the presentation of the delegation stateid so that the client can establish the appropriate rights to perform the OPEN. (See Section 16.16 for details.)
o 如果文件在客户端具有其他打开引用，则必须将打开操作发送到服务器。服务器将提供适当的stateid供客户端后续使用，因为委托stateid将不再有效。这些打开的请求使用claim_DELEGATE_CUR的claim类型完成。这将允许呈现委托stateid，以便客户机可以建立适当的权限来执行OPEN。（详见第16.16节。）
o If there are granted file locks, the corresponding LOCK operations need to be performed. This applies to the OPEN_DELEGATE_WRITE delegation case only.
o 如果已授予文件锁，则需要执行相应的锁操作。这仅适用于OPEN_DELEGATE_WRITE委派案例。
o For an OPEN_DELEGATE_WRITE delegation, if at the time of the recall the file is not open for write, all modified data for the file must be flushed to the server. If the delegation had not existed, the client would have done this data flush before the CLOSE operation.
o 对于OPEN_DELEGATE_WRITE delegation，如果在回调时文件未打开进行写入，则必须将文件的所有修改数据刷新到服务器。如果委托不存在，客户机将在关闭操作之前完成此数据刷新。
o For an OPEN_DELEGATE_WRITE delegation, when a file is still open at the time of the recall, any modified data for the file needs to be flushed to the server.
o 对于OPEN_DELEGATE_WRITE delegation，当调用时文件仍处于打开状态时，需要将文件的任何修改数据刷新到服务器。
o With the OPEN_DELEGATE_WRITE delegation in place, it is possible that the file was truncated during the duration of the delegation. For example, the truncation could have occurred as a result of an OPEN UNCHECKED4 with a size attribute value of zero. Therefore, if a truncation of the file has occurred and this operation has not been propagated to the server, the truncation must occur before any modified data is written to the server.
o 在OPEN_DELEGATE_WRITE委派就绪的情况下，文件可能在委派期间被截断。例如，截断可能是由于大小属性值为零的未选中打开的4导致的。因此，如果发生了文件截断，并且此操作尚未传播到服务器，则必须在将任何修改的数据写入服务器之前进行截断。
In the case of an OPEN_DELEGATE_WRITE delegation, file locking imposes some additional requirements. To precisely maintain the associated invariant, it is required to flush any modified data in any region for which a write lock was released while the OPEN_DELEGATE_WRITE delegation was in effect. However, because the OPEN_DELEGATE_WRITE delegation implies no other locking by other clients, a simpler implementation is to flush all modified data for the file (as described just above) if any write lock has been released while the OPEN_DELEGATE_WRITE delegation was in effect.
在开放委托和写委托的情况下，文件锁定带来了一些额外的要求。为了精确地维护关联的不变量，需要刷新在OPEN_DELEGATE_write delegation有效时为其释放写锁的任何区域中的任何修改数据。但是，由于OPEN_DELEGATE_WRITE delegation并不意味着其他客户端进行其他锁定，因此更简单的实现是，如果在OPEN_DELEGATE_WRITE delegation有效时释放了任何写锁，则刷新文件的所有修改数据（如上所述）。
An implementation need not wait until delegation recall (or deciding to voluntarily return a delegation) to perform any of the above actions, if implementation considerations (e.g., resource availability constraints) make that desirable. Generally, however, the fact that the actual open state of the file may continue to change makes it not worthwhile to send information about opens and closes to the server, except as part of delegation return. Only in the case of closing the open that resulted in obtaining the delegation would clients be likely to do this early, since, in that case, the close once done will not be undone. Regardless of the client's choices on scheduling these actions, all must be performed before the delegation is returned, including (when applicable) the close that corresponds to the open that resulted in the delegation. These actions can be performed either in previous requests or in previous operations in the same COMPOUND request.
如果实现考虑（例如，资源可用性约束）使执行上述任何操作成为可取的，则实现无需等到委托召回（或决定自愿返回委托）后再执行。但是，通常情况下，文件的实际打开状态可能会继续更改，因此不值得向服务器发送有关打开和关闭的信息，除非作为委托返回的一部分。只有在关闭导致获得委托的未结项的情况下，客户才可能提前这样做，因为在这种情况下，一旦完成，关闭将不会撤消。无论客户选择如何安排这些操作，都必须在返回委派之前执行所有操作，包括（如果适用）与导致委派的打开对应的关闭。这些操作可以在以前的请求中执行，也可以在同一复合请求中的以前操作中执行。
The server informs the client of a recall via a CB_RECALL. A race case that may develop is when the delegation is immediately recalled before the COMPOUND that established the delegation is returned to the client. As the CB_RECALL provides both a stateid and a filehandle for which the client has no mapping, it cannot honor the recall attempt. At this point, the client has two choices: either do not respond or respond with NFS4ERR_BADHANDLE. If it does not respond, then it runs the risk of the server deciding to not grant it further delegations.
服务器通过CB_回调通知客户端回调。可能发生的种族案件是，在建立委托关系的化合物返回给客户之前，立即召回委托关系。由于CB_回调同时提供stateid和filehandle，客户端没有映射，因此它不能接受回调尝试。此时，客户端有两个选择：要么不响应，要么使用NFS4ERR_BADHANDLE响应。如果它没有响应，那么它将面临服务器决定不授予它进一步授权的风险。
If instead it does reply with NFS4ERR_BADHANDLE, then both the client and the server might be able to detect that a race condition is occurring. The client can keep a list of pending delegations. When it receives a CB_RECALL for an unknown delegation, it can cache the stateid and filehandle on a list of pending recalls. When it is provided with a delegation, it would only use it if it was not on the pending recall list. Upon the next CB_RECALL, it could immediately return the delegation.
相反，如果它使用NFS4ERR_BADHANDLE进行应答，那么客户端和服务器都可能能够检测到正在发生竞争情况。客户可以保留一份待处理委托的列表。当它收到未知委托的CB_回调时，它可以在挂起的回调列表上缓存stateid和filehandle。当向其提供委托时，只有在其不在待召回名单上时，才会使用该委托。在下一次CB_召回时，它可以立即返回代表团。
In turn, the server can keep track of when it issues a delegation and assume that if a client responds to the CB_RECALL with an NFS4ERR_BADHANDLE, then the client has yet to receive the delegation. The server SHOULD give the client a reasonable time both to get this delegation and to return it before revoking the delegation. Unlike a failed callback path, the server should periodically probe the client with CB_RECALL to see if it has received the delegation and is ready to return it.
反过来，服务器可以跟踪何时发出委托，并假设如果客户机使用NFS4ERR_BADHANDLE响应CB_调用，则客户机尚未收到委托。服务器应该给客户端一段合理的时间来获取此委派，并在撤消委派之前返回委派。与失败的回调路径不同，服务器应该定期使用CB_RECALL探测客户机，以查看它是否已收到委托并准备返回委托。
When the server finally determines that enough time has elapsed, it SHOULD revoke the delegation and it SHOULD NOT revoke the lease. During this extended recall process, the server SHOULD be renewing the client lease. The intent here is that the client not pay too onerous a burden for a condition caused by the server.
当服务器最终确定已经过了足够的时间时，它应该撤销委托，而不应该撤销租约。在此扩展召回过程中，服务器应续订客户端租约。这里的目的是，客户机不必为服务器造成的状况支付太沉重的负担。
A client may fail to respond to a recall for various reasons, such as a failure of the callback path from the server to the client. The client may be unaware of a failure in the callback path. This lack of awareness could result in the client finding out long after the failure that its delegation has been revoked, and another client has modified the data for which the client had a delegation. This is especially a problem for the client that held an OPEN_DELEGATE_WRITE delegation.
客户端可能由于各种原因无法响应回调，例如从服务器到客户端的回调路径失败。客户端可能不知道回调路径中有故障。这种缺乏意识的情况可能会导致客户机在失败很久之后发现其委托已被撤销，而另一个客户机已修改了该客户机具有委托的数据。这对于持有开放式委托的客户机来说尤其是一个问题。
The server also has a dilemma in that the client that fails to respond to the recall might also be sending other NFS requests, including those that renew the lease before the lease expires. Without returning an error for those lease-renewing operations, the server leads the client to believe that the delegation it has is in force.
服务器还面临一个难题，即未能响应召回的客户端可能还发送其他NFS请求，包括那些在租约到期之前续订租约的请求。在不为这些租约续订操作返回错误的情况下，服务器会引导客户机相信它所拥有的委托已生效。
This difficulty is solved by the following rules:
此困难可通过以下规则解决：
o When the callback path is down, the server MUST NOT revoke the delegation if one of the following occurs:
o 当回调路径关闭时，如果发生以下情况之一，服务器不得撤消委派：
* The client has issued a RENEW operation, and the server has returned an NFS4ERR_CB_PATH_DOWN error. The server MUST renew the lease for any byte-range locks and share reservations the client has that the server has known about (as opposed to those locks and share reservations the client has established but not yet sent to the server, due to the delegation). The server SHOULD give the client a reasonable time to return its delegations to the server before revoking the client's delegations.
* 客户端已发出续订操作，服务器已返回NFS4ERR\u CB\u PATH\u DOWN错误。服务器必须为客户端已知的任何字节范围锁和共享保留续订租约（与客户端已建立但由于委派尚未发送到服务器的锁和共享保留相反）。在撤销客户机的委托之前，服务器应该给客户机一段合理的时间将其委托返回给服务器。
* The client has not issued a RENEW operation for some period of time after the server attempted to recall the delegation. This period of time MUST NOT be less than the value of the lease_time attribute.
* 在服务器尝试调用委派后，客户端有一段时间未发出续订操作。此时间段不得小于lease_time属性的值。
o When the client holds a delegation, it cannot rely on operations, except for RENEW, that take a stateid, to renew delegation leases across callback path failures. The client that wants to keep delegations in force across callback path failures must use RENEW to do so.
o 当客户机持有委派时，它不能依赖操作（RENEW除外）跨回调路径故障续订委派租约，该操作采用stateid。希望在回调路径失败时保持委托有效的客户端必须使用“续订”来执行此操作。
At the point a delegation is revoked, if there are associated opens on the client, the applications holding these opens need to be notified. This notification usually occurs by returning errors for READ/WRITE operations or when a close is attempted for the open file.
在委托被撤销时，如果客户端上存在关联的打开，则需要通知持有这些打开的应用程序。此通知通常在读/写操作返回错误或试图关闭打开的文件时发生。
If no opens exist for the file at the point the delegation is revoked, then notification of the revocation is unnecessary. However, if there is modified data present at the client for the file, the user of the application should be notified. Unfortunately, it may not be possible to notify the user since active applications may not be present at the client. See Section 10.5.1 for additional details.
如果在撤销委派时不存在文件的打开，则不需要通知撤销。但是，如果文件的客户端存在修改的数据，则应通知应用程序的用户。不幸的是，由于客户端可能不存在活动应用程序，因此可能无法通知用户。更多详情见第10.5.1节。
When locks and delegations are revoked, the assumptions upon which successful caching depend are no longer guaranteed. For any locks or share reservations that have been revoked, the corresponding owner needs to be notified. This notification includes applications with a file open that has a corresponding delegation that has been revoked.
当锁和委托被撤销时，成功缓存所依赖的假设将不再得到保证。对于任何已撤销的锁或共享保留，需要通知相应的所有者。此通知包括打开文件的应用程序，该文件具有已撤销的相应委派。
Cached data associated with the revocation must be removed from the client. In the case of modified data existing in the client's cache, that data must be removed from the client without it being written to the server. As mentioned, the assumptions made by the client are no longer valid at the point when a lock or delegation has been revoked. For example, another client may have been granted a conflicting lock after the revocation of the lock at the first client. Therefore, the data within the lock range may have been modified by the other client. Obviously, the first client is unable to guarantee to the application what has occurred to the file in the case of revocation.
必须从客户端删除与吊销关联的缓存数据。如果客户端缓存中存在已修改的数据，则必须在不将数据写入服务器的情况下从客户端删除该数据。如前所述，当锁或委托被撤销时，客户端所做的假设不再有效。例如，在第一个客户端撤销锁后，另一个客户端可能已被授予冲突锁。因此，锁定范围内的数据可能已被其他客户端修改。显然，第一个客户端无法向应用程序保证在撤销文件的情况下该文件发生了什么。
Notification to a lock-owner will in many cases consist of simply returning an error on the next and all subsequent READs/WRITEs to the open file or on the close. Where the methods available to a client make such notification impossible because errors for certain operations may not be returned, more drastic action, such as signals or process termination, may be appropriate. The justification for this is that an invariant on which an application depends may be violated. Depending on how errors are typically treated for the client operating environment, further levels of notification, including logging, console messages, and GUI pop-ups, may be appropriate.
在许多情况下，对锁所有者的通知只包括在下一次和所有后续读/写打开的文件或关闭时返回错误。如果由于某些操作的错误可能不会被返回，客户机可用的方法使得此类通知无法进行，则更激烈的操作（如信号或进程终止）可能是合适的。这样做的理由是可能会违反应用程序所依赖的不变量。根据客户端操作环境通常如何处理错误，进一步的通知级别（包括日志记录、控制台消息和GUI弹出窗口）可能是合适的。
Revocation recovery for an OPEN_DELEGATE_WRITE delegation poses the special issue of modified data in the client cache while the file is not open. In this situation, any client that does not flush modified data to the server on each close must ensure that the user receives appropriate notification of the failure as a result of the revocation. Since such situations may require human action to correct problems, notification schemes in which the appropriate user or administrator is notified may be necessary. Logging and console messages are typical examples.
打开的_委托_写入委托的吊销恢复会在文件未打开时引起客户端缓存中修改数据的特殊问题。在这种情况下，每次关闭时未将修改后的数据刷新到服务器的任何客户端都必须确保用户收到由于撤销而导致的故障的适当通知。由于此类情况可能需要人为措施来纠正问题，因此可能需要通知相应用户或管理员的通知方案。日志和控制台消息是典型的例子。
If there is modified data on the client, it must not be flushed normally to the server. A client may attempt to provide a copy of the file data as modified during the delegation under a different name in the file system namespace to ease recovery. Note that when the client can determine that the file has not been modified by any other client, or when the client has a complete cached copy of the file in question, such a saved copy of the client's view of the file may be of particular value for recovery. In other cases, recovery using a copy of the file, based partially on the client's cached data and partially on the server copy as modified by other clients, will be anything but straightforward, so clients may avoid saving file contents in these situations or mark the results specially to warn users of possible problems.
如果客户端上有修改过的数据，则不能将其正常刷新到服务器。客户机可能会尝试以文件系统命名空间中的不同名称提供在委派期间修改的文件数据副本，以便于恢复。请注意，当客户机可以确定文件未被任何其他客户机修改时，或者当客户机具有所讨论文件的完整缓存副本时，这种保存的客户机文件视图副本对于恢复可能具有特定价值。在其他情况下，使用文件副本（部分基于客户端的缓存数据，部分基于由其他客户端修改的服务器副本）进行恢复并不简单，因此客户端可能会避免在这些情况下保存文件内容，或专门标记结果以警告用户可能出现的问题。
The saving of such modified data in delegation revocation situations may be limited to files of a certain size or might be used only when sufficient disk space is available within the target file system. Such saving may also be restricted to situations when the client has sufficient buffering resources to keep the cached copy available until it is properly stored to the target file system.
在委托撤销情况下保存此类修改后的数据可能仅限于特定大小的文件，或者可能仅在目标文件系统中有足够的可用磁盘空间时使用。这种保存也可能被限制在客户端有足够的缓冲资源来保持缓存副本可用，直到它正确存储到目标文件系统的情况下。
The attributes discussed in this section do not include named attributes. Individual named attributes are analogous to files, and caching of the data for these needs to be handled just as data caching is for regular files. Similarly, LOOKUP results from an OPENATTR directory are to be cached on the same basis as any other pathnames and similarly for directory contents.
本节中讨论的属性不包括命名属性。单个命名属性类似于文件，需要处理这些属性的数据缓存，就像处理常规文件的数据缓存一样。类似地，来自OPENATTR目录的查找结果将与任何其他路径名一样进行缓存，对于目录内容也是如此。
Clients may cache file attributes obtained from the server and use them to avoid subsequent GETATTR requests. This cache is write through caching in that any modifications to the file attributes are always done by means of requests to the server, which means the modifications should not be done locally and should not be cached. Exceptions to this are modifications to attributes that are intimately connected with data caching. Therefore, extending a file by writing data to the local data cache is reflected immediately in the size as seen on the client without this change being immediately reflected on the server. Normally, such changes are not propagated directly to the server, but when the modified data is flushed to the server, analogous attribute changes are made on the server. When open delegation is in effect, the modified attributes may be returned to the server in the response to a CB_GETATTR call.
客户端可以缓存从服务器获得的文件属性，并使用它们来避免后续的GETATTR请求。此缓存是直写缓存，因为对文件属性的任何修改都始终通过向服务器发出请求来完成，这意味着不应在本地进行修改，也不应缓存这些修改。例外情况是修改与数据缓存密切相关的属性。因此，通过将数据写入本地数据缓存来扩展文件会立即反映在客户机上看到的大小中，而不会立即反映在服务器上。通常，此类更改不会直接传播到服务器，但当修改的数据刷新到服务器时，会在服务器上进行类似的属性更改。当开放委派生效时，修改的属性可能会在响应CB_GETATTR调用时返回给服务器。
The result of local caching of attributes is that the attribute caches maintained on individual clients will not be coherent. Changes made in one order on the server may be seen in a different order on one client and in a third order on a different client.
属性的本地缓存的结果是，在单个客户端上维护的属性缓存将不一致。在服务器上按一个顺序所做的更改可能在一个客户端上以不同的顺序显示，在另一个客户端上以第三个顺序显示。
The typical file system application programming interfaces do not provide means to atomically modify or interrogate attributes for multiple files at the same time. The following rules provide an environment where the potential incoherency mentioned above can be reasonably managed. These rules are derived from the practice of previous NFS protocols.
典型的文件系统应用程序编程接口不提供同时原子地修改或查询多个文件属性的方法。以下规则提供了一个可以合理管理上述潜在不一致性的环境。这些规则源自以前NFS协议的实践。
o All attributes for a given file (per-fsid attributes excepted) are cached as a unit at the client so that no non-serializability can arise within the context of a single file.
o 给定文件的所有属性（每个fsid属性除外）都作为一个单元缓存在客户机上，因此在单个文件的上下文中不会出现非序列化。
o An upper time boundary is maintained on how long a client cache entry can be kept without being refreshed from the server.
o 对于客户端缓存项在不从服务器刷新的情况下可以保留多长时间，将保留一个时间上限。
o When operations are performed that modify attributes at the server, the updated attribute set is requested as part of the containing RPC. This includes directory operations that update attributes indirectly. This is accomplished by following the modifying operation with a GETATTR operation and then using the results of the GETATTR to update the client's cached attributes.
o 在服务器上执行修改属性的操作时，更新的属性集作为包含RPC的一部分被请求。这包括间接更新属性的目录操作。这是通过使用GETATTR操作执行修改操作，然后使用GETATTR的结果更新客户端的缓存属性来实现的。
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 attributes obtained via GETATTR.
请注意，如果READDIR请求要缓存的完整属性集，则客户机可以按照与通过GETATTR获得的属性相同的基础来缓存结果。
A client may validate its cached version of attributes for a file by only fetching both the change and time_access attributes and assuming that if the change attribute has the same value as it did when the attributes were cached, then no attributes other than time_access have changed. The time_access attribute is also fetched because many servers operate in environments where the operation that updates change does not update time_access. For example, POSIX file semantics do not update access time when a file is modified by the write system call. Therefore, the client that wants a current time_access value should fetch it with change during the attribute cache validation processing and update its cached time_access.
客户端可以通过仅获取更改和时间访问属性，并假设如果更改属性具有与缓存属性时相同的值，则除了时间访问之外，没有其他属性发生更改，从而验证文件属性的缓存版本。由于许多服务器在更新更改的操作不更新时间访问的环境中运行，因此也会获取时间访问属性。例如，当写入系统调用修改文件时，POSIX文件语义不会更新访问时间。因此，需要当前时间访问值的客户端应在属性缓存验证处理期间获取该值，并更新其缓存的时间访问。
The client may maintain a cache of modified attributes for those attributes intimately connected with data of modified regular files (size, time_modify, and change). Other than those three attributes, the client MUST NOT maintain a cache of modified attributes. Instead, attribute changes are immediately sent to the server.
客户端可以为那些与修改的常规文件（大小、修改时间和更改）的数据密切相关的属性维护修改属性的缓存。除这三个属性外，客户端不得维护已修改属性的缓存。相反，属性更改会立即发送到服务器。
In some operating environments, the equivalent to time_access is expected to be implicitly updated by each read of the content of the file object. If an NFS client is caching the content of a file object, whether it is a regular file, directory, or symbolic link, the client SHOULD NOT update the time_access attribute (via SETATTR or a small READ or READDIR request) on the server with each read that is satisfied from cache. The reason is that this can defeat the performance benefits of caching content, especially since an explicit SETATTR of time_access may alter the change attribute on the server. If the change attribute changes, clients that are caching the content will think the content has changed and will re-read unmodified data from the server. Nor is the client encouraged to maintain a modified version of time_access in its cache, since this would mean that the client either will eventually have to write the access time to the server with bad performance effects or would never update the server's time_access, thereby resulting in a situation where an
在某些操作环境中，每次读取文件对象的内容时，都会隐式地更新相当于time_访问的值。如果NFS客户端正在缓存文件对象的内容（无论是常规文件、目录还是符号链接），则客户端不应使用缓存满足的每次读取更新服务器上的time_access属性（通过SETATTR或小型读取或READDIR请求）。原因是，这可能会破坏缓存内容的性能优势，特别是因为时间访问的显式SETATTR可能会改变服务器上的change属性。如果更改属性更改，缓存内容的客户端将认为内容已更改，并将从服务器重新读取未修改的数据。也不鼓励客户机在其缓存中维护修改后的time_访问版本，因为这意味着客户机最终将不得不将访问时间写入服务器，从而产生不良性能影响，或者永远不会更新服务器的time_访问，从而导致
application that caches access time between a close and open of the same file observes the access time oscillating between the past and present. The time_access attribute always means the time of last access to a file by a READ that was satisfied by the server. This way, clients will tend to see only time_access changes that go forward in time.
在同一文件的关闭和打开之间缓存访问时间的应用程序会观察访问时间在过去和现在之间的振荡。time_access属性始终表示服务器满足的读取上次访问文件的时间。通过这种方式，客户端将倾向于只看到随时间推移的时间访问更改。
Some operating environments include the capability for an application to map a file's content into the application's address space. Each time the application accesses a memory location that corresponds to a block that has not been loaded into the address space, a page fault occurs and the file is read (or if the block does not exist in the file, the block is allocated and then instantiated in the application's address space).
一些操作环境包括应用程序将文件内容映射到应用程序地址空间的功能。每次应用程序访问与未加载到地址空间的块相对应的内存位置时，都会发生页面错误并读取文件（或者，如果文件中不存在该块，则分配该块，然后在应用程序的地址空间中实例化）。
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 access and modification (time_access, time_metadata, time_modify, and change) will be updated. However, in many operating environments, when page faults are not required, these attributes will not be updated on reads or updates to the file via memory access (regardless of whether the file is a local file or is being accessed remotely). A client or server MAY fail to update attributes of a file that is being accessed via memory-mapped I/O. This has several implications:
只要对文件的每个内存映射访问都需要一个页面错误，用于检测访问和修改的文件的相关属性（时间访问、时间元数据、时间修改和更改）就会更新。但是，在许多操作环境中，当不需要页面错误时，这些属性不会在读取或通过内存访问更新文件时更新（无论文件是本地文件还是远程访问）。客户机或服务器可能无法更新通过内存映射I/O访问的文件的属性。这有几个含义：
o 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 to get a consistent value of the change attribute to determine whether its cache is stale or not. A server that knows that the file is memory mapped could always pessimistically return updated 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 the negative performance implications of this, such behavior is OPTIONAL.
o 如果服务器上的应用程序内存映射了客户端也正在访问的文件，则客户端可能无法获取更改属性的一致值以确定其缓存是否过时。知道文件是内存映射的服务器可能总是悲观地返回更新的值以进行更改，从而强制应用程序始终获取文件的最新数据和元数据。但是，由于这会对性能产生负面影响，此类行为是可选的。
o 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 interface, the client will not see an updated time_access attribute. However, in many operating environments, neither will any process running on the server. Thus, NFS clients are at no disadvantage with respect to local processes.
o 如果服务器上没有修改内存映射文件，而只是由应用程序通过内存映射接口读取，则客户端将看不到更新的时间访问属性。但是，在许多操作环境中，服务器上运行的任何进程都不会。因此，NFS客户端在本地进程方面并不处于劣势。
o If there is another client that is memory mapping the file and if that client is holding an OPEN_DELEGATE_WRITE delegation, the same set of issues as discussed in the previous two bullet items apply. So, when a server does a CB_GETATTR to a file that the client has
o 如果有另一个客户机正在映射文件，并且该客户机持有OPEN_DELEGATE_WRITE委托，则适用前两个项目符号中讨论的相同问题集。因此，当服务器对客户端拥有的文件执行CB_GETATTR时
modified in its cache, the response from CB_GETATTR will not necessarily be accurate. As discussed earlier, the client's obligation is to report that the file has been modified since the delegation was granted, not whether it has been modified again between successive CB_GETATTR calls, and the server MUST assume that any file the client has modified in cache has been modified again between successive CB_GETATTR calls. Depending on the nature of the client's memory management system, this weak obligation may not be possible. A client MAY return stale information in CB_GETATTR whenever the file is memory mapped.
在缓存中修改后，来自CB_GETATTR的响应不一定准确。如前所述，客户机的义务是报告自授予委派以来文件已被修改，而不是在连续的CB_GETATTR调用之间是否再次修改，并且服务器必须假设客户机在缓存中修改的任何文件在连续的CB_GETATTR调用之间再次被修改。根据客户机内存管理系统的性质，这种弱义务可能是不可能的。每当文件被内存映射时，客户端可能会在CB_GETATTR中返回过时信息。
o The mixture of memory mapping and file locking on the same file is problematic. Consider the following scenario, where the page size on each client is 8192 bytes.
o 在同一个文件上混合使用内存映射和文件锁定是有问题的。考虑下面的场景，其中每个客户机上的页面大小是8192字节。
* Client A memory maps first page (8192 bytes) of file X.
* 客户端A内存映射文件X的第一页（8192字节）。
* Client B memory maps first page (8192 bytes) of file X.
* 客户端B内存映射文件X的第一页（8192字节）。
* Client A write locks first 4096 bytes.
* 客户端A写锁定前4096个字节。
* Client B write locks second 4096 bytes.
* 客户端B写锁定第二个4096字节。
* Client A, via a STORE instruction, modifies part of its locked region.
* 客户端A通过存储指令修改其锁定区域的一部分。
* Simultaneous to client A, client B issues a STORE on part of its locked region.
* 与客户端A同时，客户端B在其锁定区域的一部分上发布存储。
Here, the challenge is for each client to resynchronize to get a correct view of the first page. In many operating environments, the virtual memory management systems on each client only know a page is modified, not that a subset of the page corresponding to the respective lock regions has been modified. So it is not possible for each client to do the right thing, which is to only write to the server 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 page, client A's data is lost.
在这里，挑战在于每个客户端都要重新同步以获得第一页的正确视图。在许多操作环境中，每个客户机上的虚拟内存管理系统只知道修改了一个页面，而不知道修改了对应于各个锁定区域的页面子集。因此，不可能每个客户机都做正确的事情，也就是只向服务器写入页面中被锁定的部分。例如，如果客户机A只是写出页面，然后客户机B写出页面，则客户机A的数据将丢失。
Moreover, if mandatory locking is enabled on the file, then we have a different problem. When clients A and B issue the STORE instructions, the resulting page faults require a byte-range lock on the entire page. Each client then tries to extend their locked range to the entire page, which results in a deadlock.
此外，如果对文件启用了强制锁定，则会出现另一个问题。当客户端A和B发出存储指令时，产生的页面错误需要在整个页面上锁定字节范围。然后，每个客户机尝试将其锁定范围扩展到整个页面，从而导致死锁。
Communicating the NFS4ERR_DEADLOCK error to a STORE instruction is difficult at best.
将NFS4ERR_死锁错误传送到存储指令充其量是困难的。
If a client is locking the entire memory-mapped file, there is no problem with advisory or mandatory byte-range locking, at least until the client unlocks a region in the middle of the file.
如果客户端锁定整个内存映射文件，则至少在客户端解锁文件中间的区域之前，没有咨询或强制字节范围锁定的问题。
Given the above issues, the following are permitted:
鉴于上述问题，允许以下情况：
o Clients and servers MAY deny memory mapping a file they know there are byte-range locks for.
o 客户端和服务器可能会拒绝内存映射他们知道有字节范围锁的文件。
o Clients and servers MAY deny a byte-range lock on a file they know is memory mapped.
o 客户端和服务器可能会拒绝他们知道是内存映射的文件上的字节范围锁。
o A client MAY deny memory mapping a file that it knows requires mandatory locking for I/O. If mandatory locking is enabled after the file is opened and mapped, the client MAY deny the application further access to its mapped file.
o 客户端可能会拒绝内存映射它知道需要强制锁定I/O的文件。如果在打开和映射文件后启用强制锁定，客户端可能会拒绝应用程序对其映射文件的进一步访问。
The results of LOOKUP and READDIR operations may be cached to avoid the cost of subsequent LOOKUP operations. Just as in the case of attribute caching, inconsistencies may arise among the various client caches. To mitigate the effects of these inconsistencies and given the context of typical file system APIs, an upper time boundary is maintained on how long a client name cache entry can be kept without verifying that the entry has not been made invalid by a directory change operation performed by another client.
查找和READDIR操作的结果可以缓存，以避免后续查找操作的开销。与属性缓存一样，不同的客户端缓存之间可能会出现不一致。为了减轻这些不一致性的影响，并考虑到典型文件系统API的上下文，在不验证另一个客户端执行的目录更改操作是否使该项无效的情况下，对客户端名称缓存项可以保留的时间上限进行了维护。
When a client is not making changes to a directory for which there exist name cache entries, the client needs to periodically fetch attributes for that directory to ensure that it is not being modified. After determining that no modification has occurred, the expiration time for the associated name cache entries may be updated to be the current time plus the name cache staleness bound.
当客户端不更改存在名称缓存项的目录时，客户端需要定期获取该目录的属性，以确保该目录未被修改。在确定未发生任何修改后，关联名称缓存项的过期时间可能会更新为当前时间加上名称缓存过时界限。
When a client is making changes to a given directory, it needs to determine whether there have been changes made to the directory by other clients. It does this by using the change attribute as reported before and after the directory operation in the associated change_info4 value returned for the operation. The server is able to communicate to the client whether the change_info4 data is provided atomically with respect to the directory operation. If the change values are provided atomically, the client is then able to compare the pre-operation change value with the change value in the client's name cache. If the comparison indicates that the directory was updated by another client, the name cache associated with the modified directory is purged from the client. If the comparison indicates no modification, the name cache can be updated on the
当客户端对给定目录进行更改时，它需要确定是否有其他客户端对该目录进行了更改。它通过使用为操作返回的关联change_info4值中目录操作前后报告的change属性来完成此操作。服务器能够与客户机通信，以确定是否以原子方式提供了与目录操作相关的更改信息4数据。如果以原子方式提供更改值，则客户端可以将操作前更改值与客户端名称缓存中的更改值进行比较。如果比较表明目录已由另一个客户端更新，则与修改后的目录关联的名称缓存将从客户端中清除。如果比较结果表明没有修改，则可以在服务器上更新名称缓存
client to reflect the directory operation and the associated timeout extended. The post-operation change value needs to be saved as the basis for future change_info4 comparisons.
客户端以反映目录操作和相关的超时扩展。需要保存操作后更改值，作为将来更改比较的基础。
As demonstrated by the scenario above, name caching requires that the client revalidate name cache data by inspecting the change attribute of a directory at the point when the name cache item was cached. This requires that the server update the change attribute for directories when the contents of the corresponding directory are modified. For a client to use the change_info4 information appropriately and correctly, the server must report the pre- and post-operation change attribute values atomically. When the server is unable to report the before and after values atomically with respect to the directory operation, the server must indicate that fact in the change_info4 return value. When the information is not atomically reported, the client should not assume that other clients have not changed the directory.
如上面的场景所示，名称缓存要求客户端通过在缓存名称缓存项时检查目录的change属性来重新验证名称缓存数据。这要求服务器在修改相应目录的内容时更新目录的change属性。为了让客户端正确地使用change_info4信息，服务器必须以原子方式报告操作前和操作后的change属性值。当服务器无法原子地报告与目录操作相关的before和after值时，服务器必须在change_info4返回值中指出这一事实。当信息未按原子方式报告时，客户端不应假定其他客户端未更改目录。
The results of READDIR operations may be used to avoid subsequent READDIR operations. Just as in the cases of attribute and name caching, inconsistencies may arise among the various client caches. To mitigate the effects of these inconsistencies, and given the context of typical file system APIs, the following rules should be followed:
READDIR操作的结果可用于避免后续的READDIR操作。与属性和名称缓存的情况一样，不同的客户端缓存之间可能会出现不一致。为了减轻这些不一致的影响，并考虑到典型文件系统API的上下文，应遵循以下规则：
o Cached READDIR information for a directory that is not obtained in a single READDIR operation must always be a consistent snapshot of directory contents. This is determined by using a GETATTR before the first READDIR and after the last READDIR that contributes to the cache.
o 未在单个READDIR操作中获得的目录的缓存READDIR信息必须始终是目录内容的一致快照。这是通过在第一个READDIR之前和最后一个参与缓存的READDIR之后使用GETATTR来确定的。
o An upper time boundary is maintained to indicate the length of time a directory cache entry is considered valid before the client must revalidate the cached information.
o 维护时间上限，以指示在客户端必须重新验证缓存信息之前，目录缓存项被视为有效的时间长度。
The revalidation technique parallels that discussed in the case of name caching. When the client is not changing the directory in question, checking the change attribute of the directory with GETATTR is adequate. The lifetime of the cache entry can be extended at these checkpoints. When a client is modifying the directory, the client needs to use the change_info4 data to determine whether there are other clients modifying the directory. If it is determined that no other client modifications are occurring, the client may update its directory cache to reflect its own changes.
重新验证技术与在名称缓存中讨论的技术类似。当客户机没有更改有问题的目录时，用GETATTR检查目录的change属性就足够了。可以在这些检查点延长缓存项的生存期。当客户端修改目录时，客户端需要使用change_info4数据来确定是否有其他客户端修改目录。如果确定没有发生其他客户端修改，则客户端可以更新其目录缓存以反映其自身的更改。
As demonstrated previously, directory caching requires that the client revalidate directory cache data by inspecting the change attribute of a directory at the point when the directory was cached. This requires that the server update the change attribute for directories when the contents of the corresponding directory are modified. For a client to use the change_info4 information appropriately and correctly, the server must report the pre- and post-operation change attribute values atomically. When the server is unable to report the before and after values atomically with respect to the directory operation, the server must indicate that fact in the change_info4 return value. When the information is not atomically reported, the client should not assume that other clients have not changed the directory.
如前所述，目录缓存要求客户端通过在缓存目录时检查目录的change属性来重新验证目录缓存数据。这要求服务器在修改相应目录的内容时更新目录的change属性。为了让客户端正确地使用change_info4信息，服务器必须以原子方式报告操作前和操作后的change属性值。当服务器无法原子地报告与目录操作相关的before和after值时，服务器必须在change_info4返回值中指出这一事实。当信息未按原子方式报告时，客户端不应假定其他客户端未更改目录。
To address the requirement of an NFS protocol that can evolve as the need arises, the NFSv4 protocol contains the rules and framework to allow for future minor changes or versioning.
为了满足NFS协议的需求，该协议可以随着需要而发展，NFSv4协议包含规则和框架，以允许将来进行小的更改或版本控制。
The base assumption with respect to minor versioning is that any future accepted minor version must follow the IETF process and be documented in a Standards Track RFC. Therefore, each minor version number will correspond to an RFC. Minor version 0 of the NFSv4 protocol is represented by this RFC. The COMPOUND and CB_COMPOUND procedures support the encoding of the minor version being requested by the client.
关于次要版本控制的基本假设是，任何未来接受的次要版本必须遵循IETF流程，并记录在标准跟踪RFC中。因此，每个次要版本号将对应一个RFC。NFSv4协议的次要版本0由此RFC表示。复合和CB_复合过程支持对客户端请求的次要版本进行编码。
Future minor versions will extend, rather than replace, the XDR for the preceding minor version, as had been done in moving from NFSv2 to NFSv3 and from NFSv3 to NFSv4.0.
未来的次要版本将扩展而不是取代先前次要版本的XDR，正如从NFSv2到NFSv3以及从NFSv3到NFSv4.0所做的那样。
Specification of detailed rules for the construction of minor versions will be addressed in documents defining early minor versions or, more desirably, in an RFC establishing a versioning framework for NFSv4 as a whole.
次要版本构造的详细规则规范将在定义早期次要版本的文件中进行说明，或者更理想的是，在为NFSv4整体建立版本控制框架的RFC中进行说明。
Internationalization is a complex topic with its own set of terminology (see [RFC6365]). The topic is made more complex in NFSv4.0 by the tangled history and state of NFS implementations. This section describes what we might call "NFSv4.0 internationalization" (i.e., internationalization as implemented by existing clients and servers) as the basis upon which NFSv4.0 clients may implement internationalization support.
国际化是一个复杂的主题，有自己的术语集（请参见[RFC6365]）。在NFSv4.0中，由于NFS实现的复杂历史和状态，该主题变得更加复杂。本节描述了我们可以称之为“NFSv4.0国际化”（即，由现有客户端和服务器实现的国际化）的内容，作为NFSv4.0客户端实现国际化支持的基础。
This section is based on the behavior of existing implementations. Note that the behaviors described are each demonstrated by a combination of an NFSv4 server implementation proper and a server-side physical file system. It is common for servers and physical file systems to be configurable as to the behavior shown. In the discussion below, each configuration that shows different behavior is considered separately.
本节基于现有实现的行为。注意，所描述的每个行为都通过NFSv4服务器实现和服务器端物理文件系统的组合进行了演示。服务器和物理文件系统通常可以根据显示的行为进行配置。在下面的讨论中，将分别考虑显示不同行为的每个配置。
Note that in this section, the key words "MUST", "SHOULD", and "MAY" retain their normal meanings. However, in deriving this specification from implementation patterns, we document below how the normative terms used derive from the behavior of existing implementations, in those situations in which existing implementation behavior patterns can be determined.
请注意，在本节中，关键词“必须”、“应该”和“可能”保留其正常含义。然而，在从实现模式派生本规范的过程中，我们在下面记录了在可以确定现有实现行为模式的情况下，所使用的规范术语是如何从现有实现的行为派生的。
o Behavior implemented by all existing clients or servers is described using "MUST", since new implementations need to follow existing ones to be assured of interoperability. While it is possible that different behavior might be workable, we have found no case where this seems reasonable.
o 所有现有客户机或服务器实现的行为都使用“必须”来描述，因为新的实现需要遵循现有的实现以确保互操作性。虽然不同的行为可能是可行的，但我们还没有发现任何合理的情况。
The converse holds for "MUST NOT": if a type of behavior poses interoperability problems, it MUST NOT be implemented by any existing clients or servers.
相反的说法是“不得”：如果一种行为造成互操作性问题，那么任何现有的客户端或服务器都不能实现它。
o Behavior implemented by most existing clients or servers, where that behavior is more desirable than any alternative, is described using "SHOULD", since new implementations need to follow that existing practice unless there are strong reasons to do otherwise.
o 由大多数现有客户机或服务器实现的行为（这种行为比任何替代方案都更可取）使用“应该”来描述，因为新的实现需要遵循现有的实践，除非有充分的理由这样做。
The converse holds for "SHOULD NOT".
“不应该”的意思正好相反。
o Behavior implemented by some, but not all, existing clients or servers is described using "MAY", indicating that new implementations have a choice as to whether they will behave in that way. Thus, new implementations will have the same flexibility that existing ones do.
o 由一些（但不是全部）现有客户机或服务器实现的行为用“可能”来描述，这表示新的实现可以选择是否以这种方式进行。因此，新的实现将具有与现有实现相同的灵活性。
o Behavior implemented by all existing clients or servers, so far as is known -- but where there remains some uncertainty as to details -- is described using "should". Such cases primarily concern details of error returns. New implementations should follow existing practice even though such situations generally do not affect interoperability.
o 所有现有客户机或服务器实现的行为，就目前所知——但在细节方面仍然存在一些不确定性——使用“应该”来描述。此类案例主要涉及错误返回的详细信息。新的实现应该遵循现有的实践，即使这种情况通常不会影响互操作性。
There are also cases in which certain server behaviors, while not known to exist, cannot be reliably determined not to exist. In part, this is a consequence of the long period of time that has elapsed
还有一些情况下，某些服务器行为虽然不知道存在，但无法可靠地确定不存在。在某种程度上，这是经过了很长一段时间的结果
since the publication of [RFC3530], resulting in a situation in which those involved in the implementation may no longer be involved in or aware of working group activities.
自[RFC3530]发布以来，导致参与实施的人员可能不再参与或了解工作组的活动。
In the case of possible server behavior that is neither known to exist nor known not to exist, we use "SHOULD NOT" and "MUST NOT" as follows, and similarly for "SHOULD" and "MUST".
对于既不知道存在也不知道不存在的可能的服务器行为，我们使用“不应该”和“不应该”，如下所示，类似地使用“应该”和“必须”。
o In some cases, the potential behavior is not known to exist but is of such a nature that, if it were in fact implemented, interoperability difficulties would be expected and reported, giving us cause to conclude that the potential behavior is not implemented. For such behavior, we use "MUST NOT". Similarly, we use "MUST" to apply to the contrary behavior.
o 在某些情况下，我们不知道潜在行为是否存在，但其性质是，如果实际实现了该行为，则会出现预期和报告的互操作性困难，这使我们有理由断定潜在行为未实现。对于这种行为，我们使用“不得”。同样，我们用“必须”来表示相反的行为。
o In other cases, potential behavior is not known to exist but the behavior, while undesirable, is not of such a nature that we are able to draw any conclusions about its potential existence. In such cases, we use "SHOULD NOT". Similarly, we use "SHOULD" to apply to the contrary behavior.
o 在其他情况下，我们不知道潜在行为是否存在，但该行为虽然不受欢迎，但其性质不足以让我们对其潜在存在得出任何结论。在这种情况下，我们使用“不应该”。同样，我们用“应该”来表示相反的行为。
In the case of a "MAY", "SHOULD", or "SHOULD NOT" that applies to servers, clients need to be aware that there are servers that may or may not take the specified action, and they need to be prepared for either eventuality.
在适用于服务器的“可能”、“应该”或“不应该”的情况下，客户机需要知道，有些服务器可能会或可能不会采取指定的操作，并且他们需要为这两种情况做好准备。
12.2. Limitations on Internationalization-Related Processing in the NFSv4 Context
12.2. NFSv4上下文中国际化相关处理的限制
There are a number of noteworthy circumstances that limit the degree to which internationalization-related processing can be made universal with regard to NFSv4 clients and servers:
有许多值得注意的情况限制了NFSv4客户端和服务器国际化相关处理的通用性：
o The NFSv4 client is part of an extensive set of client-side software components whose design and internal interfaces are not within the IETF's purview, limiting the degree to which a particular character encoding may be made standard.
o NFSv4客户端是一组广泛的客户端软件组件的一部分，其设计和内部接口不在IETF的权限范围内，从而限制了特定字符编码的标准化程度。
o Server-side handling of file component names is typically implemented within a server-side physical file system, whose handling of character encoding and normalization is not specifiable by the IETF.
o 文件组件名称的服务器端处理通常在服务器端物理文件系统中实现，IETF无法指定其字符编码和规范化处理。
o Typical implementation patterns in UNIX systems result in the NFSv4 client having no knowledge of the character encoding being used, which may even vary between processes on the same client system.
o UNIX系统中的典型实现模式导致NFSv4客户端不知道正在使用的字符编码，这甚至可能在同一客户端系统上的进程之间有所不同。
o Users may need access to files stored previously with non-UTF-8 encodings, or with UTF-8 encodings that do not match any particular normalization form.
o 用户可能需要访问以前使用非UTF-8编码存储的文件，或者使用与任何特定规范化形式不匹配的UTF-8编码存储的文件。
As mentioned in Section 12.6, servers MAY reject component name strings that are not valid UTF-8. This leads to a number of types of valid server behavior, as outlined below. When these are combined with the valid normalization-related behaviors as described in Section 12.4, this leads to the combined behaviors outlined below.
如第12.6节所述，服务器可能会拒绝无效UTF-8的组件名称字符串。这将导致许多类型的有效服务器行为，如下所述。当这些行为与第12.4节中描述的有效规范化相关行为相结合时，这将导致下面概述的组合行为。
o Servers that limit file component names to UTF-8 strings exist with normalization-related handling as described in Section 12.4. These are best described as "UTF-8-only servers".
o 将文件组件名称限制为UTF-8字符串的服务器具有第12.4节所述的规范化相关处理。最好将其描述为“仅UTF-8服务器”。
o Servers that do not limit file component names to UTF-8 strings are very common and are necessary to deal with clients/ applications not oriented to the use of UTF-8. Such servers ignore normalization-related issues, and there is no way for them to implement either normalization or representation-independent lookups. These are best described as "UTF-8-unaware servers", since they treat file component names as uninterpreted strings of bytes and have no knowledge of the characters represented. See Section 12.7 for details.
o 不将文件组件名称限制为UTF-8字符串的服务器非常常见，对于处理不使用UTF-8的客户机/应用程序是必要的。这样的服务器忽略了与规范化相关的问题，它们无法实现规范化或独立于表示的查找。最好将它们描述为“UTF-8-Unknowledge服务器”，因为它们将文件组件名称视为未解释的字节字符串，并且不知道所表示的字符。详见第12.7节。
o It is possible for a server to allow component names that are not valid UTF-8, while still being aware of the structure of UTF-8 strings. Such servers could implement either normalization or representation-independent lookups but apply those techniques only to valid UTF-8 strings. Such servers are not common, but it is possible to configure at least one known server to have this behavior. This behavior SHOULD NOT be used due to the possibility that a filename using one character set may, by coincidence, have the appearance of a UTF-8 filename; the results of UTF-8 normalization or representation-independent lookups are unlikely to be correct in all cases with respect to the other character set.
o 服务器可以允许组件名称不是有效的UTF-8，同时仍然知道UTF-8字符串的结构。这样的服务器可以实现规范化或独立于表示的查找，但这些技术仅应用于有效的UTF-8字符串。这样的服务器并不常见，但可以将至少一个已知服务器配置为具有这种行为。不应使用此行为，因为使用一个字符集的文件名可能碰巧具有UTF-8文件名的外观；UTF-8规范化或表示独立查找的结果不可能在所有情况下都与其他字符集相关。
Strings that potentially contain characters outside the ASCII range [RFC20] are generally represented in NFSv4 using the UTF-8 encoding [RFC3629] of Unicode [UNICODE]. See [RFC3629] for precise encoding and decoding rules.
可能包含ASCII范围[RFC20]以外字符的字符串通常在NFSv4中使用Unicode[Unicode]的UTF-8编码[RFC3629]表示。有关精确的编码和解码规则，请参见[RFC3629]。
Some details of the protocol treatment depend on the type of string:
协议处理的一些细节取决于字符串的类型：
o For strings that are component names, the preferred encoding for any non-ASCII characters is the UTF-8 representation of Unicode.
o 对于作为组件名称的字符串，任何非ASCII字符的首选编码是Unicode的UTF-8表示。
In many cases, clients have no knowledge of the encoding being used, with the encoding done at the user level under the control of a per-process locale specification. As a result, it may be impossible for the NFSv4 client to enforce the use of UTF-8. The use of non-UTF-8 encodings can be problematic, since it may interfere with access to files stored using other forms of name encoding. Also, normalization-related processing (see Section 12.5) of a string not encoded in UTF-8 could result in inappropriate name modification or aliasing. In cases in which one has a non-UTF-8 encoded name that accidentally conforms to UTF-8 rules, substitution of canonically equivalent strings can change the non-UTF-8 encoded name drastically.
在许多情况下，客户机不知道正在使用的编码，编码是在每个进程区域设置规范的控制下在用户级别完成的。因此，NFSv4客户端可能无法强制使用UTF-8。使用非UTF-8编码可能会有问题，因为它可能会干扰对使用其他形式的名称编码存储的文件的访问。此外，未在UTF-8中编码的字符串的规范化相关处理（见第12.5节）可能会导致不适当的名称修改或别名。如果有一个非UTF-8编码的名称意外地符合UTF-8规则，则替换规范等效字符串可能会彻底更改非UTF-8编码的名称。
The kinds of modification and aliasing mentioned here can lead to both false negatives and false positives, depending on the strings in question, which can result in security issues such as elevation of privilege and denial of service (see [RFC6943] for further discussion).
此处提到的修改和别名类型可能会导致误报和误报，具体取决于所讨论的字符串，这可能会导致安全问题，如特权提升和拒绝服务（有关进一步讨论，请参阅[RFC6943]）。
o For strings based on domain names, non-ASCII characters MUST be represented using the UTF-8 encoding of Unicode, and additional string format restrictions apply. See Section 12.6 for details.
o 对于基于域名的字符串，必须使用Unicode的UTF-8编码表示非ASCII字符，并应用其他字符串格式限制。详见第12.6节。
o The contents of symbolic links (of type linktext4 in the XDR) MUST be treated as opaque data by NFSv4 servers. Although UTF-8 encoding is often used, it need not be. In this respect, the contents of symbolic links are like the contents of regular files in that their encoding is not within the scope of this specification.
o NFSv4服务器必须将符号链接（XDR中的linktext4类型）的内容视为不透明数据。虽然经常使用UTF-8编码，但不需要。在这方面，符号链接的内容类似于常规文件的内容，因为它们的编码不在本规范的范围内。
o For other sorts of strings, any non-ASCII characters SHOULD be represented using the UTF-8 encoding of Unicode.
o 对于其他类型的字符串，应使用Unicode的UTF-8编码来表示任何非ASCII字符。
The client and server operating environments may differ in their policies and operational methods with respect to character normalization (see [UNICODE] for a discussion of normalization forms). This difference may also exist between applications on the same client. This adds to the difficulty of providing a single normalization policy for the protocol that allows for maximal interoperability. This issue is similar to the issues of character case where the server may or may not support case-insensitive
客户端和服务器操作环境在字符规范化方面的策略和操作方法可能有所不同（有关规范化形式的讨论，请参见[UNICODE]）。同一客户端上的应用程序之间也可能存在这种差异。这增加了为协议提供单一规范化策略以实现最大互操作性的难度。此问题类似于服务器可能支持或不支持大小写不敏感的字符大小写问题
filename matching and may or may not preserve the character case when storing filenames. The protocol does not mandate a particular behavior but allows for a range of useful behaviors.
文件名匹配，存储文件名时可能保留字符大小写，也可能不保留字符大小写。该协议不要求特定的行为，但允许一系列有用的行为。
The NFSv4 protocol does not mandate the use of a particular normalization form at this time. A subsequent minor version of the NFSv4 protocol might specify a particular normalization form. Therefore, the server and client can expect that they may receive unnormalized characters within protocol requests and responses. If the operating environment requires normalization, then the implementation will need to normalize the various UTF-8 encoded strings within the protocol before presenting the information to an application (at the client) or local file system (at the server).
NFSv4协议此时不强制使用特定的规范化表单。NFSv4协议的后续次要版本可能会指定特定的规范化形式。因此，服务器和客户机可能会在协议请求和响应中接收到非规范化字符。如果操作环境需要规范化，那么在将信息呈现给应用程序（客户端）或本地文件系统（服务器）之前，实现将需要规范化协议中的各种UTF-8编码字符串。
Server implementations MAY normalize filenames to conform to a particular normalization form before using the resulting string when looking up or creating a file. Servers MAY also perform normalization-insensitive string comparisons without modifying the names to match a particular normalization form. Except in cases in which component names are excluded from normalization-related handling because they are not valid UTF-8 strings, a server MUST make the same choice (as to whether to normalize or not, the target form of normalization, and whether to do normalization-insensitive string comparisons) in the same way for all accesses to a particular file system. Servers SHOULD NOT reject a filename because it does not conform to a particular normalization form, as this may deny access to clients that use a different normalization form.
在查找或创建文件时使用生成的字符串之前，服务器实现可以规范化文件名以符合特定的规范化表单。服务器还可以执行不区分规范化的字符串比较，而无需修改名称以匹配特定的规范化表单。除了组件名称由于不是有效的UTF-8字符串而被排除在与规范化相关的处理之外，服务器必须做出相同的选择（关于是否规范化、规范化的目标形式以及是否进行不区分规范化的字符串比较）以相同的方式访问特定文件系统。服务器不应该拒绝文件名，因为它不符合特定的规范化表单，因为这可能会拒绝对使用不同规范化表单的客户端的访问。
There are two types of strings that NFSv4 deals with that are based on domain names. Processing of such strings is defined by other Internet standards, and hence the processing behavior for such strings should be consistent across all server operating systems and server file systems.
NFSv4处理两种类型的基于域名的字符串。此类字符串的处理由其他Internet标准定义，因此此类字符串的处理行为应在所有服务器操作系统和服务器文件系统中保持一致。
These are as follows:
详情如下:
o Server names as they appear in the fs_locations attribute. Note that for most purposes, such server names will only be sent by the server to the client. The exception is the use of the fs_locations attribute in a VERIFY or NVERIFY operation.
o “fs_位置”属性中显示的服务器名称。请注意，在大多数情况下，此类服务器名称将仅由服务器发送到客户端。例外情况是在验证或NVERIFY操作中使用fs_locations属性。
o Principal suffixes that are used to denote sets of users and groups, and are in the form of domain names.
o 主要后缀，用于表示用户和组的集合，以域名的形式出现。
The general rules for handling all of these domain-related strings are similar and independent of the role of the sender or receiver as client or server, although the consequences of failure to obey these rules may be different for client or server. The server can report errors when it is sent invalid strings, whereas the client will simply ignore invalid string or use a default value in their place.
处理所有这些域相关字符串的一般规则是相似的，与发送方或接收方作为客户机或服务器的角色无关，尽管不遵守这些规则对客户机或服务器的后果可能不同。当发送无效字符串时，服务器可能会报告错误，而客户端只会忽略无效字符串或在其位置使用默认值。
The string sent SHOULD be in the form of one or more U-labels as defined by [RFC5890]. If that is impractical, it can instead be in the form of one or more LDH labels [RFC5890] or a UTF-8 domain name that contains labels that are not properly formatted U-labels. The receiver needs to be able to accept domain and server names in any of the formats allowed. The server MUST reject, using the error NFS4ERR_INVAL, a string that is not valid UTF-8, or that contains an ASCII label that is not a valid LDH label, or that contains an XN-label (begins with "xn--") for which the characters after "xn--" are not valid output of the Punycode algorithm [RFC3492].
发送的字符串应采用[RFC5890]定义的一个或多个U型标签的形式。如果这是不切实际的，它可以采用一个或多个LDH标签[RFC5890]或UTF-8域名的形式，其中包含未正确格式化的U型标签。接收方需要能够接受任何允许格式的域名和服务器名。服务器必须使用错误NFS4ERR_INVAL拒绝无效UTF-8的字符串，或包含无效LDH标签的ASCII标签的字符串，或包含XN标签（以“XN--”开头）的字符串，“XN--”之后的字符不是Punycode算法[RFC3492]的有效输出。
When a domain string is part of id@domain or group@domain, there are two possible approaches:
当域字符串是id@domain或group@domain，有两种可能的方法：
1. The server treats the domain string as a series of U-labels. In cases where the domain string is a series of A-labels or Non-Reserved LDH (NR-LDH) labels, it converts them to U-labels using the Punycode algorithm [RFC3492]. In cases where the domain string is a series of other sorts of LDH labels, the server can use the ToUnicode function defined in [RFC3490] to convert the string to a series of labels that generally conform to the U-label syntax. In cases where the domain string is a UTF-8 string that contains non-U-labels, the server can attempt to use the ToASCII function defined in [RFC3490] and then the ToUnicode function on the string to convert it to a series of labels that generally conform to the U-label syntax. As a result, the domain string returned within a user id on a GETATTR may not match that sent when the user id is set using SETATTR, although when this happens, the domain will be in the form that generally conforms to the U-label syntax.
1. 服务器将域字符串视为一系列U形标签。如果域字符串是一系列a标签或非保留LDH（NR-LDH）标签，则使用Punycode算法[RFC3492]将其转换为U标签。如果域字符串是一系列其他种类的LDH标签，则服务器可以使用[RFC3490]中定义的ToUnicode函数将字符串转换为通常符合U-label语法的一系列标签。如果域字符串是包含非U标签的UTF-8字符串，则服务器可以尝试使用[RFC3490]中定义的ToASCII函数，然后使用字符串上的ToUnicode函数将其转换为通常符合U标签语法的一系列标签。因此，GETATTR上用户id内返回的域字符串可能与使用SETATTR设置用户id时发送的域字符串不匹配，尽管在这种情况下，域的形式通常符合U-label语法。
2. The server does not attempt to treat the domain string as a series of U-labels; specifically, it does not map a domain string that is not a U-label into a U-label using the methods described above. As a result, the domain string returned on a GETATTR of the user id MUST be the same as that used when setting the user id by the SETATTR.
2. 服务器不尝试将域字符串视为一系列U标签；具体而言，它不会使用上述方法将非U标签的域字符串映射到U标签。因此，用户id的GETATTR上返回的域字符串必须与SETATTR设置用户id时使用的域字符串相同。
A server SHOULD use the first method.
服务器应该使用第一种方法。
For VERIFY and NVERIFY, additional string processing requirements apply to verification of the owner and owner_group attributes; see Section 5.9.
对于VERIFY和NVERIFY，额外的字符串处理要求适用于所有者和所有者组属性的验证；见第5.9节。
Where the client sends an invalid UTF-8 string, the server MAY return an NFS4ERR_INVAL error. This includes cases in which inappropriate prefixes are detected and where the count includes trailing bytes that do not constitute a full Universal Multiple-Octet Coded Character Set (UCS) character.
当客户端发送无效的UTF-8字符串时，服务器可能会返回NFS4ERR_INVAL错误。这包括检测到不适当前缀的情况，以及计数包括不构成完整通用多八位字节编码字符集（UCS）字符的尾随字节的情况。
Requirements for server handling of component names that are not valid UTF-8, when a server does not return NFS4ERR_INVAL in response to receiving them, are described in Section 12.8.
第12.8节描述了服务器在接收到无效UTF-8的组件名称时不返回NFS4ERR_INVAL的服务器处理要求。
Where the string supplied by the client is not rejected with NFS4ERR_INVAL but contains characters that are not supported by the server as a value for that string (e.g., names containing slashes, or characters that do not fit into 16 bits when converted from UTF-8 to a Unicode codepoint), the server should return an NFS4ERR_BADCHAR error.
如果客户端提供的字符串未被NFS4ERR_INVAL拒绝，但包含服务器不支持作为该字符串值的字符（例如，包含斜杠的名称，或从UTF-8转换为Unicode码点时不适合16位的字符），则服务器应返回NFS4ERR_BADCHAR错误。
Where a UTF-8 string is used as a filename, and the file system, while supporting all of the characters within the name, does not allow that particular name to be used, the server should return the error NFS4ERR_BADNAME. This includes such situations as file system prohibitions of "." and ".." as filenames for certain operations, and similar constraints.
如果使用UTF-8字符串作为文件名，并且文件系统支持名称中的所有字符，但不允许使用该特定名称，则服务器应返回错误NFS4ERR_BADNAME。这包括文件系统禁止将“.”和“.”作为某些操作的文件名，以及类似的限制。
12.8. Servers That Accept File Component Names That Are Not Valid UTF-8 Strings
12.8. 接受无效UTF-8字符串的文件组件名称的服务器
As stated previously, servers MAY accept, on all or on some subset of the physical file systems exported, component names that are not valid UTF-8 strings. A typical pattern is for a server to use UTF-8-unaware physical file systems that treat component names as uninterpreted strings of bytes, rather than having any awareness of the character set being used.
如前所述，服务器可以在导出的物理文件系统的所有或某些子集上接受无效UTF-8字符串的组件名称。一种典型的模式是服务器使用UTF-8不知道的物理文件系统，该系统将组件名称视为未解释的字节字符串，而不知道正在使用的字符集。
Such servers SHOULD NOT change the stored representation of component names from those received on the wire and SHOULD use an octet-by-octet comparison of component name strings to determine equivalence (as opposed to any broader notion of string comparison). This is because the server has no knowledge of the character encoding being used.
此类服务器不应更改存储的组件名称表示形式，而应使用组件名称字符串的八进制比较来确定等效性（与任何更广泛的字符串比较概念相反）。这是因为服务器不知道正在使用的字符编码。
Nonetheless, when such a server uses a broader notion of string equivalence than what is recommended in the preceding paragraph, the following considerations apply:
尽管如此，当这样的服务器使用比上一段中建议的更广泛的字符串等价性概念时，以下注意事项适用：
o Outside of 7-bit ASCII, string processing that changes string contents is usually specific to a character set and hence is generally unsafe when the character set is unknown. This processing could change the filename in an unexpected fashion, rendering the file inaccessible to the application or client that created or renamed the file and to others expecting the original filename. Hence, such processing should not be performed, because doing so is likely to result in incorrect string modification or aliasing.
o 在7位ASCII之外，更改字符串内容的字符串处理通常特定于字符集，因此当字符集未知时通常是不安全的。此处理可能以意外方式更改文件名，使创建或重命名文件的应用程序或客户端以及其他需要原始文件名的用户无法访问文件。因此，不应执行此类处理，因为这样做可能会导致错误的字符串修改或别名。
o Unicode normalization is particularly dangerous, as such processing assumes that the string is UTF-8. When that assumption is false because a different character set was used to create the filename, normalization may corrupt the filename with respect to that character set, rendering the file inaccessible to the application that created it and others expecting the original filename. Hence, Unicode normalization SHOULD NOT be performed, because it may cause incorrect string modification or aliasing.
o Unicode规范化尤其危险，因为这种处理假定字符串是UTF-8。如果由于使用不同的字符集创建文件名而导致该假设为假，则规范化可能会损坏该字符集的文件名，从而使创建该文件的应用程序和其他需要原始文件名的应用程序无法访问该文件。因此，不应执行Unicode规范化，因为它可能会导致不正确的字符串修改或别名。
When the above recommendations are not followed, the resulting string modification and aliasing can lead to both false negatives and false positives, depending on the strings in question, which can result in security issues such as elevation of privilege and denial of service (see [RFC6943] for further discussion).
如果不遵循上述建议，则产生的字符串修改和别名可能会导致误报和误报，具体取决于所讨论的字符串，这可能会导致安全问题，如特权提升和拒绝服务（有关进一步讨论，请参阅[RFC6943]）。
NFS error numbers are assigned to failed operations within a COMPOUND or CB_COMPOUND request. A COMPOUND request contains a number of NFS operations that have their results encoded in sequence in a COMPOUND reply. The results of successful operations will consist of an NFS4_OK status followed by the encoded results of the operation. If an NFS operation fails, an error status will be entered in the reply, and the COMPOUND request will be terminated.
NFS错误号分配给复合请求或CB_复合请求中的失败操作。复合请求包含许多NFS操作，这些操作的结果在复合应答中按顺序编码。成功操作的结果将包括NFS4_OK状态，然后是编码的操作结果。如果NFS操作失败，将在回复中输入错误状态，并终止复合请求。
+-----------------------------+--------+-------------------+
| Error | Number | Description |
+-----------------------------+--------+-------------------+
| NFS4_OK | 0 | Section 13.1.3.1 |
| NFS4ERR_ACCESS | 13 | Section 13.1.6.1 |
| NFS4ERR_ADMIN_REVOKED | 10047 | Section 13.1.5.1 |
| NFS4ERR_ATTRNOTSUPP | 10032 | Section 13.1.11.1 |
| NFS4ERR_BADCHAR | 10040 | Section 13.1.7.1 |
| NFS4ERR_BADHANDLE | 10001 | Section 13.1.2.1 |
| NFS4ERR_BADNAME | 10041 | Section 13.1.7.2 |
| NFS4ERR_BADOWNER | 10039 | Section 13.1.11.2 |
| NFS4ERR_BADTYPE | 10007 | Section 13.1.4.1 |
| NFS4ERR_BADXDR | 10036 | Section 13.1.1.1 |
| NFS4ERR_BAD_COOKIE | 10003 | Section 13.1.1.2 |
| NFS4ERR_BAD_RANGE | 10042 | Section 13.1.8.1 |
| NFS4ERR_BAD_SEQID | 10026 | Section 13.1.8.2 |
| NFS4ERR_BAD_STATEID | 10025 | Section 13.1.5.2 |
| NFS4ERR_CB_PATH_DOWN | 10048 | Section 13.1.12.1 |
| NFS4ERR_CLID_INUSE | 10017 | Section 13.1.10.1 |
| NFS4ERR_DEADLOCK | 10045 | Section 13.1.8.3 |
| NFS4ERR_DELAY | 10008 | Section 13.1.1.3 |
| NFS4ERR_DENIED | 10010 | Section 13.1.8.4 |
| NFS4ERR_DQUOT | 69 | Section 13.1.4.2 |
| NFS4ERR_EXIST | 17 | Section 13.1.4.3 |
| NFS4ERR_EXPIRED | 10011 | Section 13.1.5.3 |
| NFS4ERR_FBIG | 27 | Section 13.1.4.4 |
| NFS4ERR_FHEXPIRED | 10014 | Section 13.1.2.2 |
| NFS4ERR_FILE_OPEN | 10046 | Section 13.1.4.5 |
| NFS4ERR_GRACE | 10013 | Section 13.1.9.1 |
| NFS4ERR_INVAL | 22 | Section 13.1.1.4 |
| NFS4ERR_IO | 5 | Section 13.1.4.6 |
| NFS4ERR_ISDIR | 21 | Section 13.1.2.3 |
| NFS4ERR_LEASE_MOVED | 10031 | Section 13.1.5.4 |
| NFS4ERR_LOCKED | 10012 | Section 13.1.8.5 |
| NFS4ERR_LOCKS_HELD | 10037 | Section 13.1.8.6 |
| NFS4ERR_LOCK_NOTSUPP | 10043 | Section 13.1.8.7 |
| NFS4ERR_LOCK_RANGE | 10028 | Section 13.1.8.8 |
| NFS4ERR_MINOR_VERS_MISMATCH | 10021 | Section 13.1.3.2 |
| NFS4ERR_MLINK | 31 | Section 13.1.4.7 |
| NFS4ERR_MOVED | 10019 | Section 13.1.2.4 |
| NFS4ERR_NAMETOOLONG | 63 | Section 13.1.7.3 |
| NFS4ERR_NOENT | 2 | Section 13.1.4.8 |
| NFS4ERR_NOFILEHANDLE | 10020 | Section 13.1.2.5 |
| NFS4ERR_NOSPC | 28 | Section 13.1.4.9 |
| NFS4ERR_NOTDIR | 20 | Section 13.1.2.6 |
| NFS4ERR_NOTEMPTY | 66 | Section 13.1.4.10 |
+-----------------------------+--------+-------------------+
| Error | Number | Description |
+-----------------------------+--------+-------------------+
| NFS4_OK | 0 | Section 13.1.3.1 |
| NFS4ERR_ACCESS | 13 | Section 13.1.6.1 |
| NFS4ERR_ADMIN_REVOKED | 10047 | Section 13.1.5.1 |
| NFS4ERR_ATTRNOTSUPP | 10032 | Section 13.1.11.1 |
| NFS4ERR_BADCHAR | 10040 | Section 13.1.7.1 |
| NFS4ERR_BADHANDLE | 10001 | Section 13.1.2.1 |
| NFS4ERR_BADNAME | 10041 | Section 13.1.7.2 |
| NFS4ERR_BADOWNER | 10039 | Section 13.1.11.2 |
| NFS4ERR_BADTYPE | 10007 | Section 13.1.4.1 |
| NFS4ERR_BADXDR | 10036 | Section 13.1.1.1 |
| NFS4ERR_BAD_COOKIE | 10003 | Section 13.1.1.2 |
| NFS4ERR_BAD_RANGE | 10042 | Section 13.1.8.1 |
| NFS4ERR_BAD_SEQID | 10026 | Section 13.1.8.2 |
| NFS4ERR_BAD_STATEID | 10025 | Section 13.1.5.2 |
| NFS4ERR_CB_PATH_DOWN | 10048 | Section 13.1.12.1 |
| NFS4ERR_CLID_INUSE | 10017 | Section 13.1.10.1 |
| NFS4ERR_DEADLOCK | 10045 | Section 13.1.8.3 |
| NFS4ERR_DELAY | 10008 | Section 13.1.1.3 |
| NFS4ERR_DENIED | 10010 | Section 13.1.8.4 |
| NFS4ERR_DQUOT | 69 | Section 13.1.4.2 |
| NFS4ERR_EXIST | 17 | Section 13.1.4.3 |
| NFS4ERR_EXPIRED | 10011 | Section 13.1.5.3 |
| NFS4ERR_FBIG | 27 | Section 13.1.4.4 |
| NFS4ERR_FHEXPIRED | 10014 | Section 13.1.2.2 |
| NFS4ERR_FILE_OPEN | 10046 | Section 13.1.4.5 |
| NFS4ERR_GRACE | 10013 | Section 13.1.9.1 |
| NFS4ERR_INVAL | 22 | Section 13.1.1.4 |
| NFS4ERR_IO | 5 | Section 13.1.4.6 |
| NFS4ERR_ISDIR | 21 | Section 13.1.2.3 |
| NFS4ERR_LEASE_MOVED | 10031 | Section 13.1.5.4 |
| NFS4ERR_LOCKED | 10012 | Section 13.1.8.5 |
| NFS4ERR_LOCKS_HELD | 10037 | Section 13.1.8.6 |
| NFS4ERR_LOCK_NOTSUPP | 10043 | Section 13.1.8.7 |
| NFS4ERR_LOCK_RANGE | 10028 | Section 13.1.8.8 |
| NFS4ERR_MINOR_VERS_MISMATCH | 10021 | Section 13.1.3.2 |
| NFS4ERR_MLINK | 31 | Section 13.1.4.7 |
| NFS4ERR_MOVED | 10019 | Section 13.1.2.4 |
| NFS4ERR_NAMETOOLONG | 63 | Section 13.1.7.3 |
| NFS4ERR_NOENT | 2 | Section 13.1.4.8 |
| NFS4ERR_NOFILEHANDLE | 10020 | Section 13.1.2.5 |
| NFS4ERR_NOSPC | 28 | Section 13.1.4.9 |
| NFS4ERR_NOTDIR | 20 | Section 13.1.2.6 |
| NFS4ERR_NOTEMPTY | 66 | Section 13.1.4.10 |
| NFS4ERR_NOTSUPP | 10004 | Section 13.1.1.5 |
| NFS4ERR_NOT_SAME | 10027 | Section 13.1.11.3 |
| NFS4ERR_NO_GRACE | 10033 | Section 13.1.9.2 |
| NFS4ERR_NXIO | 6 | Section 13.1.4.11 |
| NFS4ERR_OLD_STATEID | 10024 | Section 13.1.5.5 |
| NFS4ERR_OPENMODE | 10038 | Section 13.1.8.9 |
| NFS4ERR_OP_ILLEGAL | 10044 | Section 13.1.3.3 |
| NFS4ERR_PERM | 1 | Section 13.1.6.2 |
| NFS4ERR_RECLAIM_BAD | 10034 | Section 13.1.9.3 |
| NFS4ERR_RECLAIM_CONFLICT | 10035 | Section 13.1.9.4 |
| NFS4ERR_RESOURCE | 10018 | Section 13.1.3.4 |
| NFS4ERR_RESTOREFH | 10030 | Section 13.1.4.12 |
| NFS4ERR_ROFS | 30 | Section 13.1.4.13 |
| NFS4ERR_SAME | 10009 | Section 13.1.11.4 |
| NFS4ERR_SERVERFAULT | 10006 | Section 13.1.1.6 |
| NFS4ERR_SHARE_DENIED | 10015 | Section 13.1.8.10 |
| NFS4ERR_STALE | 70 | Section 13.1.2.7 |
| NFS4ERR_STALE_CLIENTID | 10022 | Section 13.1.10.2 |
| NFS4ERR_STALE_STATEID | 10023 | Section 13.1.5.6 |
| NFS4ERR_SYMLINK | 10029 | Section 13.1.2.8 |
| NFS4ERR_TOOSMALL | 10005 | Section 13.1.1.7 |
| NFS4ERR_WRONGSEC | 10016 | Section 13.1.6.3 |
| NFS4ERR_XDEV | 18 | Section 13.1.4.14 |
+-----------------------------+--------+-------------------+
| NFS4ERR_NOTSUPP | 10004 | Section 13.1.1.5 |
| NFS4ERR_NOT_SAME | 10027 | Section 13.1.11.3 |
| NFS4ERR_NO_GRACE | 10033 | Section 13.1.9.2 |
| NFS4ERR_NXIO | 6 | Section 13.1.4.11 |
| NFS4ERR_OLD_STATEID | 10024 | Section 13.1.5.5 |
| NFS4ERR_OPENMODE | 10038 | Section 13.1.8.9 |
| NFS4ERR_OP_ILLEGAL | 10044 | Section 13.1.3.3 |
| NFS4ERR_PERM | 1 | Section 13.1.6.2 |
| NFS4ERR_RECLAIM_BAD | 10034 | Section 13.1.9.3 |
| NFS4ERR_RECLAIM_CONFLICT | 10035 | Section 13.1.9.4 |
| NFS4ERR_RESOURCE | 10018 | Section 13.1.3.4 |
| NFS4ERR_RESTOREFH | 10030 | Section 13.1.4.12 |
| NFS4ERR_ROFS | 30 | Section 13.1.4.13 |
| NFS4ERR_SAME | 10009 | Section 13.1.11.4 |
| NFS4ERR_SERVERFAULT | 10006 | Section 13.1.1.6 |
| NFS4ERR_SHARE_DENIED | 10015 | Section 13.1.8.10 |
| NFS4ERR_STALE | 70 | Section 13.1.2.7 |
| NFS4ERR_STALE_CLIENTID | 10022 | Section 13.1.10.2 |
| NFS4ERR_STALE_STATEID | 10023 | Section 13.1.5.6 |
| NFS4ERR_SYMLINK | 10029 | Section 13.1.2.8 |
| NFS4ERR_TOOSMALL | 10005 | Section 13.1.1.7 |
| NFS4ERR_WRONGSEC | 10016 | Section 13.1.6.3 |
| NFS4ERR_XDEV | 18 | Section 13.1.4.14 |
+-----------------------------+--------+-------------------+
Table 6: Protocol Error Definitions
表6：协议错误定义
This section deals with errors that are applicable to a broad set of different purposes.
本节讨论适用于各种不同目的的错误。
The arguments for this operation do not match those specified in the XDR definition. This includes situations in which the request ends before all the arguments have been seen. Note that this error applies when fixed enumerations (these include booleans) have a value within the input stream that is not valid for the enum. A replier may pre-parse all operations for a COMPOUND procedure before doing any operation execution and return RPC-level XDR errors in that case.
此操作的参数与XDR定义中指定的参数不匹配。这包括请求在看到所有参数之前结束的情况。请注意，当固定枚举（包括布尔值）在输入流中具有对枚举无效的值时，此错误适用。应答器可以在执行任何操作之前预解析复合过程的所有操作，并在这种情况下返回RPC级别的XDR错误。
This error is used for operations that provide a set of information indexed by some quantity provided by the client or cookie sent by the server for an earlier invocation. Where the value cannot be used for its intended purpose, this error results.
此错误用于提供一组信息的操作，这些信息按客户机提供的数量或服务器为早期调用发送的cookie进行索引。如果该值不能用于预期目的，则会导致此错误。
For any of a number of reasons, the replier could not process this operation in what was deemed a reasonable time. The client should wait and then try the request with a new RPC transaction ID.
由于多种原因之一，回复人无法在合理时间内处理此操作。客户端应等待，然后使用新的RPC事务ID尝试该请求。
The following are two examples of what might lead to this situation:
以下是可能导致这种情况的两个例子：
o A server that supports hierarchical storage receives a request to process a file that had been migrated.
o 支持分层存储的服务器接收处理已迁移文件的请求。
o An operation requires a delegation recall to proceed, and waiting for this delegation recall makes processing this request in a timely fashion impossible.
o 一个操作需要一个委派调用才能继续，而等待该委派调用使得无法及时处理该请求。
The arguments for this operation are not valid for some reason, even though they do match those specified in the XDR definition for the request.
由于某种原因，此操作的参数无效，即使它们与请求的XDR定义中指定的参数匹配。
The operation is not supported, either because the operation is an OPTIONAL one and is not supported by this server or because the operation MUST NOT be implemented in the current minor version.
不支持该操作，这可能是因为该操作是可选操作且此服务器不支持该操作，也可能是因为该操作不能在当前次要版本中实现。
An error that does not map to any of the specific legal NFSv4 protocol error values occurred on the server. The client should translate this into an appropriate error. UNIX clients may choose to translate this to EIO.
服务器上发生了未映射到任何特定合法NFSv4协议错误值的错误。客户机应将此转换为适当的错误。UNIX客户端可以选择将其转换为EIO。
This error is used where an operation returns a variable amount of data, with a limit specified by the client. Where the data returned cannot be fitted within the limit specified by the client, this error results.
如果操作返回的数据量可变，且客户端指定了限制，则使用此错误。如果返回的数据无法在客户端指定的限制内拟合，则会导致此错误。
These errors deal with the situation in which the current or saved filehandle, or the filehandle passed to PUTFH intended to become the current filehandle, is invalid in some way. This includes situations in which the filehandle is a valid filehandle in general but is not of the appropriate object type for the current operation.
这些错误处理的情况是，当前或保存的文件句柄，或传递给PUTFH（打算成为当前文件句柄）的文件句柄在某种程度上无效。这包括以下情况：filehandle通常是有效的filehandle，但不是当前操作的适当对象类型。
Where the error description indicates a problem with the current or saved filehandle, it is to be understood that filehandles are only checked for the condition if they are implicit arguments of the operation in question.
如果错误描述表明当前或保存的文件句柄存在问题，则应理解，只有当文件句柄是相关操作的隐式参数时，才会检查其条件。
This error is generated for an illegal NFS filehandle for the current server. The current filehandle failed internal consistency checks. Once accepted as valid (by PUTFH), no subsequent status change can cause the filehandle to generate this error.
此错误是为当前服务器的非法NFS文件句柄生成的。当前文件句柄未通过内部一致性检查。一旦被（PUTFH）接受为有效，任何后续状态更改都不会导致filehandle生成此错误。
A current or saved filehandle that is an argument to the current operation is volatile and has expired at the server.
作为当前操作参数的当前或保存的filehandle是不稳定的，并且已在服务器上过期。
The current or saved filehandle designates a directory when the current operation does not allow a directory to be accepted as the target of this operation.
当当前操作不允许接受目录作为此操作的目标时，当前或保存的文件句柄将指定一个目录。
The file system that contains the current filehandle object is not present at the server. It may have been relocated or migrated to another server, or may have never been present. The client may obtain the new file system location by obtaining the "fs_locations" attribute for the current filehandle. For further discussion, refer to Section 8.
服务器上不存在包含当前filehandle对象的文件系统。它可能已重新定位或迁移到另一台服务器，或者可能从未出现过。客户端可以通过获取当前文件句柄的“fs_locations”属性来获取新的文件系统位置。有关进一步讨论，请参阅第8节。
The logical current or saved filehandle value is required by the current operation and is not set. This may be a result of a malformed COMPOUND operation (i.e., no PUTFH or PUTROOTFH before an operation that requires that the current filehandle be set).
当前操作需要逻辑当前或保存的filehandle值，未设置该值。这可能是由于复合操作格式错误（即，在需要设置当前文件句柄的操作之前没有PUTFH或PUTROOTFH）。
The current (or saved) filehandle designates an object that is not a directory for an operation in which a directory is required.
当前（或保存的）文件句柄指定的对象不是需要目录的操作的目录。
The current or saved filehandle value designating an argument to the current operation is invalid. The file system object referred to by that filehandle no longer exists, or access to it has been revoked.
指定当前操作参数的当前或保存的filehandle值无效。该文件句柄引用的文件系统对象不再存在，或者对该对象的访问已被吊销。
The current filehandle designates a symbolic link when the current operation does not allow a symbolic link as the target.
当当前操作不允许将符号链接作为目标时，当前文件句柄指定符号链接。
This section deals with errors that relate to the overall structure of a COMPOUND request (by which we mean to include both COMPOUND and CB_COMPOUND), rather than to particular operations.
本节讨论与复合请求的整体结构（我们的意思是同时包括复合和CB_复合）相关的错误，而不是与特定操作相关的错误。
There are a number of basic constraints on the operations that may appear in a COMPOUND request.
复合请求中可能出现的操作有许多基本约束。
NFS_OK indicates that the operation completed successfully, in that all of the constituent operations completed without error.
NFS_OK表示操作已成功完成，因为所有组成操作均已完成且无错误。
The minor version specified is not one that the current listener supports. This value is returned in the overall status for the COMPOUND procedure but is not associated with a specific operation, since the results must specify a result count of zero.
指定的次要版本不是当前侦听器支持的版本。此值以复合过程的整体状态返回，但与特定操作无关，因为结果必须指定结果计数为零。
The operation code is not a valid one for the current COMPOUND procedure. The opcode in the result stream matched with this error is the ILLEGAL value, although the value that appears in the request stream may be different. Where an illegal value appears and the replier pre-parses all operations for a COMPOUND procedure before doing any operation execution, an RPC-level XDR error may be returned in this case.
操作代码不是当前复合过程的有效代码。与此错误匹配的结果流中的操作码是非法值，尽管请求流中出现的值可能不同。如果出现非法值，并且应答器在执行任何操作之前预解析复合过程的所有操作，则在这种情况下可能会返回RPC级别的XDR错误。
For the processing of the COMPOUND procedure, the server may exhaust available resources and cannot continue processing operations within the COMPOUND procedure. This error will be returned from the server in those instances of resource exhaustion related to the processing of the COMPOUND procedure.
对于复合过程的处理，服务器可能会耗尽可用资源，并且无法继续复合过程中的处理操作。在与复合过程处理相关的资源耗尽实例中，服务器将返回此错误。
These errors describe situations that occurred in the underlying file system implementation rather than in the protocol or any NFSv4.x feature.
这些错误描述了在底层文件系统实现中发生的情况，而不是在协议或任何NFSv4.x功能中发生的情况。
An attempt was made to create an object with an inappropriate type specified to CREATE. This may be because the type is undefined; because it is a type not supported by the server; or because it is a type for which create is not intended, such as a regular file or named attribute, for which OPEN is used to do the file creation.
试图使用指定要创建的不适当类型创建对象。这可能是因为类型未定义；因为它是服务器不支持的类型；或者因为它是一种不打算创建的类型，例如使用OPEN创建文件的常规文件或命名属性。
The resource (quota) hard limit has been exceeded. The user's resource limit on the server has been exceeded.
已超过资源（配额）硬限制。已超过服务器上用户的资源限制。
A file system object of the specified target name (when creating, renaming, or linking) already exists.
具有指定目标名称的文件系统对象（在创建、重命名或链接时）已存在。
The file system object is too large. The operation would have caused a file system object to grow beyond the server's limit.
文件系统对象太大。该操作会导致文件系统对象增长超过服务器的限制。
The operation is not allowed because a file system object involved in the operation is currently open. Servers may, but are not required to, disallow linking to, removing, or renaming open file system objects.
不允许该操作，因为该操作涉及的文件系统对象当前处于打开状态。服务器可以（但不是必须）禁止链接、删除或重命名打开的文件系统对象。
This indicates that an I/O error occurred for which the file system was unable to provide recovery.
这表示发生了I/O错误，文件系统无法提供恢复。
The request would have caused the server's limit for the number of hard links a file system object may have to be exceeded.
该请求可能会导致服务器超过文件系统对象的硬链接数限制。
This indicates no such file or directory. The file system object referenced by the name specified does not exist.
这表示没有这样的文件或目录。指定名称引用的文件系统对象不存在。
This indicates no space left on the device. The operation would have caused the server's file system to exceed its limit.
这表示设备上没有剩余空间。该操作将导致服务器的文件系统超出其限制。
An attempt was made to remove a directory that was not empty.
试图删除一个非空目录。
This indicates an I/O error. There is no such device or address.
这表示存在I/O错误。没有这样的设备或地址。
The RESTOREFH operation does not have a saved filehandle (identified by SAVEFH) to operate upon.
RESTOREFH操作没有可操作的已保存文件句柄（由SAVEFH标识）。
This indicates a read-only file system. A modifying operation was attempted on a read-only file system.
这表示只读文件系统。试图在只读文件系统上执行修改操作。
This indicates an attempt to do an operation, such as linking, that inappropriately crosses a boundary. For example, this may be due to a boundary between:
这表示试图执行不适当跨越边界的操作（如链接）。例如，这可能是由于以下两者之间存在边界：
o File systems (where the fsids are different).
o 文件系统（其中fsid不同）。
o Different named attribute directories, or between a named attribute directory and an ordinary directory.
o 不同的命名属性目录，或在命名属性目录和普通目录之间。
o Regions of a file system that the file system implementation treats as separate (for example, for space accounting purposes), and where cross-connection between the regions is not allowed.
o 文件系统实现将其视为单独的文件系统区域（例如，出于空间核算的目的），并且不允许区域之间的交叉连接。
These errors indicate problems with the stateid (or one of the stateids) passed to a given operation. This includes situations in which the stateid is invalid, as well as situations in which the stateid is valid but designates revoked locking state. Depending on the operation, the stateid, when valid, may designate opens, byte-range locks, or file delegations.
这些错误表示传递给给定操作的stateid（或其中一个stateid）存在问题。这包括stateid无效的情况，以及stateid有效但指定已撤销锁定状态的情况。根据操作的不同，stateid在有效时可以指定打开、字节范围锁定或文件委派。
A stateid designates locking state of any type that has been revoked due to administrative interaction, possibly while the lease is valid, or because a delegation was revoked because of failure to return it, while the lease was valid.
stateid指定由于管理交互而被撤销的任何类型的锁定状态，可能是在租约有效时，或者是因为无法返回委派而被撤销，而租约有效时。
A stateid generated by the current server instance was used that either:
使用了由当前服务器实例生成的stateid，该ID可以是：
o Does not designate any locking state (either current or superseded) for a current (state-owner, file) pair.
o 不为当前（状态所有者、文件）对指定任何锁定状态（当前或被取代）。
o Designates locking state that was freed after lease expiration but without any lease cancellation, as may happen in the handling of "courtesy locks".
o 指定在租约到期后释放但没有任何租约取消的锁定状态，如在处理“门控锁”时可能发生的情况。
A stateid or clientid designates locking state of any type that has been revoked or released due to cancellation of the client's lease, either immediately upon lease expiration, or following a later request for a conflicting lock.
stateid或clientid指定任何类型的锁定状态，该锁定状态在租约到期后立即被撤销或释放，或者在稍后请求冲突的锁后被撤销或释放。
A lease being renewed is associated with a file system that has been migrated to a new server.
正在续订的租约与已迁移到新服务器的文件系统相关联。
A stateid is provided with a seqid value that is not the most current.
stateid提供的seqid值不是最新的。
A stateid generated by an earlier server instance was used.
使用了由早期服务器实例生成的stateid。
These are the various permission-related errors in NFSv4.
这些是NFSv4中与权限相关的各种错误。
This indicates permission denied. The caller does not have the correct permission to perform the requested operation. Contrast this with NFS4ERR_PERM (Section 13.1.6.2), which restricts itself to owner or privileged user permission failures.
这表示权限被拒绝。调用方没有执行请求的操作的正确权限。这与NFS4ERR_PERM（第13.1.6.2节）形成对比，NFS4ERR_PERM将自身限制为所有者或特权用户权限失败。
This indicates that the requester is not the owner. The operation was not allowed because the caller is neither a privileged user (root) nor the owner of the target of the operation.
这表示请求者不是所有者。不允许该操作，因为调用方既不是特权用户（根用户），也不是操作目标的所有者。
This indicates that the security mechanism being used by the client for the operation does not match the server's security policy. The client should change the security mechanism being used and re-send the operation. SECINFO can be used to determine the appropriate mechanism.
这表示客户端用于操作的安全机制与服务器的安全策略不匹配。客户端应更改正在使用的安全机制并重新发送操作。SECINFO可用于确定适当的机制。
Names in NFSv4 are UTF-8 strings. When the strings are not of length zero, the error NFS4ERR_INVAL results. When they are not valid UTF-8, the error NFS4ERR_INVAL also results, but servers may accommodate file systems with different character formats and not return this error. Besides this, there are a number of other errors to indicate specific problems with names.
NFSv4中的名称是UTF-8字符串。当字符串长度不为零时，将产生错误NFS4ERR_INVAL。当它们不是有效的UTF-8时，也会产生错误NFS4ERR_INVAL，但服务器可能会适应具有不同字符格式的文件系统，并且不会返回此错误。除此之外，还有许多其他错误表明名称存在特定问题。
A UTF-8 string contains a character that is not supported by the server in the context in which it is being used.
UTF-8字符串包含服务器在其使用的上下文中不支持的字符。
A name string in a request consisted of valid UTF-8 characters supported by the server, but the name is not supported by the server as a valid name for current operation. An example might be creating a file or directory named ".." on a server whose file system uses that name for links to parent directories.
请求中的名称字符串由服务器支持的有效UTF-8字符组成，但服务器不支持该名称作为当前操作的有效名称。例如，在服务器上创建名为“.”的文件或目录，其文件系统使用该名称链接到父目录。
This error should not be returned due to a normalization issue in a string. When a file system keeps names in a particular normalization form, it is the server's responsibility to do the appropriate normalization, rather than rejecting the name.
由于字符串中存在规范化问题，因此不应返回此错误。当文件系统以特定的规范化形式保存名称时，服务器负责执行适当的规范化，而不是拒绝该名称。
This is returned when the filename in an operation exceeds the server's implementation limit.
当操作中的文件名超过服务器的实现限制时，将返回此值。
This section deals with errors related to locking -- both share reservations and byte-range locking. It does not deal with errors specific to the process of reclaiming locks. Those are dealt with in the next section.
本节讨论与锁定相关的错误——共享保留和字节范围锁定。它不处理特定于回收锁过程的错误。下一节将讨论这些问题。
The range for a LOCK, LOCKT, or LOCKU operation is not appropriate to the allowable range of offsets for the server. For example, this error results when a server that only supports 32-bit ranges receives a range that cannot be handled by that server. (See Section 16.10.4.)
锁定、锁定或锁定操作的范围不适合服务器允许的偏移范围。例如，当仅支持32位范围的服务器接收到该服务器无法处理的范围时，会出现此错误。（见第16.10.4节。）
The sequence number (seqid) in a locking request is neither the next expected number nor the last number processed.
锁定请求中的序列号（seqid）既不是下一个预期的数字，也不是处理的最后一个数字。
The server has been able to determine a file locking deadlock condition for a blocking lock request.
服务器已经能够确定阻止锁定请求的文件锁定死锁条件。
An attempt to lock a file is denied. Since this may be a temporary condition, the client is encouraged to re-send the lock request until the lock is accepted. See Section 9.4 for a discussion of the re-send.
锁定文件的尝试被拒绝。由于这可能是一个临时条件，因此鼓励客户端重新发送锁请求，直到锁被接受为止。有关重新发送的讨论，请参见第9.4节。
A READ or WRITE operation was attempted on a file where there was a conflict between the I/O and an existing lock:
尝试对I/O和现有锁之间存在冲突的文件执行读或写操作：
o There is a share reservation inconsistent with the I/O being done.
o 存在与正在执行的I/O不一致的共享保留。
o The range to be read or written intersects an existing mandatory byte-range lock.
o 要读取或写入的范围与现有的强制字节范围锁相交。
An operation was prevented by the unexpected presence of locks.
由于意外出现锁，操作被阻止。
A locking request was attempted that would require the upgrade or downgrade of a lock range already held by the owner when the server does not support atomic upgrade or downgrade of locks.
尝试了一个锁定请求，当服务器不支持锁的原子升级或降级时，该请求将要求升级或降级所有者已持有的锁范围。
A lock request is operating on a range that partially overlaps a currently held lock for the current lock-owner and does not precisely match a single such lock, where the server does not support this type of request and thus does not implement POSIX locking semantics [fcntl]. See Sections 16.10.5, 16.11.5, and 16.12.5 for a discussion of how this applies to LOCK, LOCKT, and LOCKU, respectively.
锁请求在与当前锁所有者的当前持有的锁部分重叠的范围内运行，并且与单个此类锁不精确匹配，其中服务器不支持此类请求，因此不实现POSIX锁语义[fcntl]。参见第16.10.5节、第16.11.5节和第16.12.5节，分别讨论这如何适用于锁、锁和锁。
The client attempted a READ, WRITE, LOCK, or other operation not sanctioned by the stateid passed (e.g., writing to a file opened only for read).
客户端尝试了读取、写入、锁定或其他未经传递的stateid批准的操作（例如，写入仅为读取而打开的文件）。
An attempt to OPEN a file with a share reservation has failed because of a share conflict.
由于共享冲突，尝试打开具有共享保留的文件失败。
These errors relate to the process of reclaiming locks after a server restart.
这些错误与服务器重新启动后回收锁的过程有关。
The server is in its recovery or grace period, which should at least match the lease period of the server. A locking request other than a reclaim could not be granted during that period.
服务器处于恢复期或宽限期，这至少应与服务器的租用期相匹配。在此期间，无法授予除回收之外的锁定请求。
The server cannot guarantee that it has not granted state to another client that may conflict with this client's state. No further reclaims from this client will succeed.
服务器无法保证未将状态授予可能与此客户端状态冲突的其他客户端。从此客户端进行的进一步回收将不会成功。
The server cannot guarantee that it has not granted state to another client that may conflict with the requested state. However, this applies only to the state requested in this call; further reclaims may succeed.
服务器无法保证它没有将状态授予另一个可能与请求状态冲突的客户端。但是，这仅适用于此呼叫中请求的状态；进一步回收可能成功。
Unlike NFS4ERR_RECLAIM_CONFLICT, this can occur between correctly functioning clients and servers: the "edge condition" scenarios described in Section 9.6.3.4 leave only the server knowing whether the client's locks are still valid, and NFS4ERR_RECLAIM_BAD is the server's way of informing the client that they are not.
与NFS4ERR_Reclain_冲突不同，这可能发生在正常运行的客户端和服务器之间：第9.6.3.4节中描述的“边缘条件”场景只让服务器知道客户端的锁是否仍然有效，而NFS4ERR_Reclain_BAD是服务器通知客户端它们不有效的方式。
The reclaim attempted by the client conflicts with a lock already held by another client. Unlike NFS4ERR_RECLAIM_BAD, this can only occur if one of the clients misbehaved.
客户端尝试的回收与另一客户端已持有的锁冲突。与NFS4ERR_reclain_BAD不同，这仅在其中一个客户端行为不当时才会发生。
This section deals with errors associated with requests used to create and manage client IDs.
本节讨论与用于创建和管理客户端ID的请求相关的错误。
The SETCLIENTID operation has found that a clientid is already in use by another client.
SETCLIENTID操作发现另一个客户端已在使用clientid。
A client ID not recognized by the server was used in a locking or SETCLIENTID_CONFIRM request.
锁定或SETCLIENTID_确认请求中使用了服务器无法识别的客户端ID。
This section deals with errors specific to attribute handling within NFSv4.
本节讨论NFSv4中特定于属性处理的错误。
An attribute specified is not supported by the server. This error MUST NOT be returned by the GETATTR operation.
服务器不支持指定的属性。GETATTR操作不能返回此错误。
This error is returned when an owner or owner_group attribute value or the who field of an ace within an ACL attribute value cannot be translated to a local representation.
当无法将ACL属性值中ace的所有者或所有者组属性值或who字段转换为本地表示形式时，将返回此错误。
This error is returned by the VERIFY operation to signify that the attributes compared were not the same as those provided in the client's request.
验证操作返回此错误，表示比较的属性与客户端请求中提供的属性不同。
This error is returned by the NVERIFY operation to signify that the attributes compared were the same as those provided in the client's request.
NVERIFY操作返回此错误，表示比较的属性与客户端请求中提供的属性相同。
There is a problem contacting the client via the callback path.
通过回调路径与客户端联系时出现问题。
This section contains a table that gives the valid error returns for each protocol operation. The error code NFS4_OK (indicating no error) is not listed but should be understood to be returnable by all operations except ILLEGAL.
本节包含一个表，该表给出了每个协议操作的有效错误返回。错误代码NFS4_OK（表示无错误）未列出，但应理解为可由所有操作返回，非法操作除外。
+---------------------+---------------------------------------------+
| Operation | Errors |
+---------------------+---------------------------------------------+
| ACCESS | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| CLOSE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_ISDIR, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKS_HELD, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| COMMIT | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK |
| | |
| CREATE | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADNAME, NFS4ERR_BADOWNER, |
| | NFS4ERR_BADTYPE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, |
| | NFS4ERR_PERM, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
+---------------------+---------------------------------------------+
| Operation | Errors |
+---------------------+---------------------------------------------+
| ACCESS | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| CLOSE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_ISDIR, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKS_HELD, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| COMMIT | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK |
| | |
| CREATE | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADNAME, NFS4ERR_BADOWNER, |
| | NFS4ERR_BADTYPE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, |
| | NFS4ERR_PERM, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
| | |
| DELEGPURGE | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_NOTSUPP, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE_CLIENTID |
| | |
| DELEGRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| GETATTR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| GETFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
| | |
| ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL |
| | |
| LINK | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_EXIST, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MLINK, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_WRONGSEC, NFS4ERR_XDEV |
| | |
| | |
| DELEGPURGE | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_NOTSUPP, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE_CLIENTID |
| | |
| DELEGRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| GETATTR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| GETFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
| | |
| ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL |
| | |
| LINK | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_EXIST, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MLINK, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_WRONGSEC, NFS4ERR_XDEV |
| | |
| LOCK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_RANGE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DEADLOCK, |
| | NFS4ERR_DELAY, NFS4ERR_DENIED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCK_NOTSUPP, NFS4ERR_LOCK_RANGE, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_RECLAIM_CONFLICT, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_CLIENTID, |
| | NFS4ERR_STALE_STATEID |
| | |
| LOCKT | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_RANGE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DENIED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_CLIENTID |
| | |
| LOCKU | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_RANGE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_STALE_STATEID |
| | |
| LOCK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_RANGE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DEADLOCK, |
| | NFS4ERR_DELAY, NFS4ERR_DENIED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCK_NOTSUPP, NFS4ERR_LOCK_RANGE, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_RECLAIM_CONFLICT, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_CLIENTID, |
| | NFS4ERR_STALE_STATEID |
| | |
| LOCKT | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_RANGE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DENIED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_CLIENTID |
| | |
| LOCKU | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_RANGE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_STALE_STATEID |
| | |
| LOOKUP | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_WRONGSEC |
| | |
| LOOKUPP | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_WRONGSEC |
| | |
| NVERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_SAME, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| OPEN | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADOWNER, NFS4ERR_BAD_SEQID, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NO_GRACE, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_PERM, NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_RECLAIM_CONFLICT, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_SHARE_DENIED, NFS4ERR_STALE, |
| | NFS4ERR_STALE_CLIENTID, NFS4ERR_SYMLINK, |
| | NFS4ERR_WRONGSEC |
| | |
| LOOKUP | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_WRONGSEC |
| | |
| LOOKUPP | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_WRONGSEC |
| | |
| NVERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_SAME, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| OPEN | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADOWNER, NFS4ERR_BAD_SEQID, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NO_GRACE, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_PERM, NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_RECLAIM_CONFLICT, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_SHARE_DENIED, NFS4ERR_STALE, |
| | NFS4ERR_STALE_CLIENTID, NFS4ERR_SYMLINK, |
| | NFS4ERR_WRONGSEC |
| | |
| OPENATTR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTSUPP, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
| | |
| OPEN_CONFIRM | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| OPEN_DOWNGRADE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCKS_HELD, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| PUTFH | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_WRONGSEC |
| | |
| PUTPUBFH | NFS4ERR_DELAY, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_WRONGSEC |
| | |
| PUTROOTFH | NFS4ERR_DELAY, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_WRONGSEC |
| | |
| OPENATTR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTSUPP, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
| | |
| OPEN_CONFIRM | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| OPEN_DOWNGRADE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCKS_HELD, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| PUTFH | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_WRONGSEC |
| | |
| PUTPUBFH | NFS4ERR_DELAY, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_WRONGSEC |
| | |
| PUTROOTFH | NFS4ERR_DELAY, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_WRONGSEC |
| | |
| READ | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID, NFS4ERR_SYMLINK |
| | |
| READDIR | NFS4ERR_ACCESS, NFS4ERR_BAD_COOKIE, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_NOT_SAME, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOOSMALL |
| | |
| READLINK | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| RELEASE_LOCKOWNER | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKS_HELD, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE_CLIENTID |
| | |
| REMOVE | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTDIR, NFS4ERR_NOTEMPTY, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| READ | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID, NFS4ERR_SYMLINK |
| | |
| READDIR | NFS4ERR_ACCESS, NFS4ERR_BAD_COOKIE, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_NOT_SAME, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOOSMALL |
| | |
| READLINK | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| RELEASE_LOCKOWNER | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKS_HELD, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE_CLIENTID |
| | |
| REMOVE | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTDIR, NFS4ERR_NOTEMPTY, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| RENAME | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_EXIST, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, |
| | NFS4ERR_NOTEMPTY, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_WRONGSEC, |
| | NFS4ERR_XDEV |
| | |
| RENEW | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_CB_PATH_DOWN, NFS4ERR_EXPIRED, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE_CLIENTID |
| | |
| RESTOREFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_RESOURCE, |
| | NFS4ERR_RESTOREFH, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_WRONGSEC |
| | |
| SAVEFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
| | |
| SECINFO | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTDIR, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| RENAME | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_EXIST, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, |
| | NFS4ERR_NOTEMPTY, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_WRONGSEC, |
| | NFS4ERR_XDEV |
| | |
| RENEW | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_CB_PATH_DOWN, NFS4ERR_EXPIRED, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE_CLIENTID |
| | |
| RESTOREFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_RESOURCE, |
| | NFS4ERR_RESTOREFH, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_WRONGSEC |
| | |
| SAVEFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
| | |
| SECINFO | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTDIR, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| SETATTR | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADOWNER, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_PERM, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| SETCLIENTID | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT |
| | |
| SETCLIENTID_CONFIRM | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, |
| | NFS4ERR_DELAY, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE_CLIENTID |
| | |
| VERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOT_SAME, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
| | |
| SETATTR | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADOWNER, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_PERM, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID |
| | |
| SETCLIENTID | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT |
| | |
| SETCLIENTID_CONFIRM | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, |
| | NFS4ERR_DELAY, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE_CLIENTID |
| | |
| VERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOT_SAME, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE |
| | |
| WRITE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NXIO, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_STALE_STATEID, |
| | NFS4ERR_SYMLINK |
| | |
+---------------------+---------------------------------------------+
| WRITE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NXIO, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_STALE_STATEID, |
| | NFS4ERR_SYMLINK |
| | |
+---------------------+---------------------------------------------+
Table 7: Valid Error Returns for Each Protocol Operation
表7：每个协议操作的有效错误返回
This section contains a table that gives the valid error returns for each callback operation. The error code NFS4_OK (indicating no error) is not listed but should be understood to be returnable by all callback operations, with the exception of CB_ILLEGAL.
本节包含一个表，该表为每个回调操作提供有效的错误返回。错误代码NFS4_OK（表示无错误）未列出，但应理解为可由所有回调操作返回，CB_非法除外。
+-------------+-----------------------------------------------------+
| Callback | Errors |
| Operation | |
+-------------+-----------------------------------------------------+
| CB_GETATTR | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_SERVERFAULT |
| | |
| CB_ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL |
| | |
| CB_RECALL | NFS4ERR_BADHANDLE, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, NFS4ERR_SERVERFAULT |
| | |
+-------------+-----------------------------------------------------+
+-------------+-----------------------------------------------------+
| Callback | Errors |
| Operation | |
+-------------+-----------------------------------------------------+
| CB_GETATTR | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_SERVERFAULT |
| | |
| CB_ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL |
| | |
| CB_RECALL | NFS4ERR_BADHANDLE, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, NFS4ERR_SERVERFAULT |
| | |
+-------------+-----------------------------------------------------+
Table 8: Valid Error Returns for Each Protocol Callback Operation
表8：每个协议回调操作的有效错误返回
+--------------------------+----------------------------------------+
| Error | Operations |
+--------------------------+----------------------------------------+
| NFS4ERR_ACCESS | ACCESS, COMMIT, CREATE, GETATTR, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, READ, |
| | READDIR, READLINK, REMOVE, RENAME, |
| | RENEW, SECINFO, SETATTR, VERIFY, WRITE |
| | |
| NFS4ERR_ADMIN_REVOKED | CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_ATTRNOTSUPP | CREATE, NVERIFY, OPEN, SETATTR, VERIFY |
| | |
| NFS4ERR_BADCHAR | CREATE, LINK, LOOKUP, NVERIFY, OPEN, |
| | REMOVE, RENAME, SECINFO, SETATTR, |
| | VERIFY |
| | |
| NFS4ERR_BADHANDLE | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, |
| | COMMIT, CREATE, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE |
| | |
| NFS4ERR_BADNAME | CREATE, LINK, LOOKUP, OPEN, REMOVE, |
| | RENAME, SECINFO |
| | |
| NFS4ERR_BADOWNER | CREATE, OPEN, SETATTR |
| | |
| NFS4ERR_BADTYPE | CREATE |
| | |
| NFS4ERR_BADXDR | ACCESS, CB_GETATTR, CB_ILLEGAL, |
| | CB_RECALL, CLOSE, COMMIT, CREATE, |
| | DELEGPURGE, DELEGRETURN, GETATTR, |
| | ILLEGAL, LINK, LOCK, LOCKT, LOCKU, |
| | LOOKUP, NVERIFY, OPEN, OPENATTR, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, PUTFH, |
| | READ, READDIR, RELEASE_LOCKOWNER, |
| | REMOVE, RENAME, RENEW, SECINFO, |
| | SETATTR, SETCLIENTID, |
| | SETCLIENTID_CONFIRM, VERIFY, WRITE |
| | |
+--------------------------+----------------------------------------+
| Error | Operations |
+--------------------------+----------------------------------------+
| NFS4ERR_ACCESS | ACCESS, COMMIT, CREATE, GETATTR, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, READ, |
| | READDIR, READLINK, REMOVE, RENAME, |
| | RENEW, SECINFO, SETATTR, VERIFY, WRITE |
| | |
| NFS4ERR_ADMIN_REVOKED | CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_ATTRNOTSUPP | CREATE, NVERIFY, OPEN, SETATTR, VERIFY |
| | |
| NFS4ERR_BADCHAR | CREATE, LINK, LOOKUP, NVERIFY, OPEN, |
| | REMOVE, RENAME, SECINFO, SETATTR, |
| | VERIFY |
| | |
| NFS4ERR_BADHANDLE | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, |
| | COMMIT, CREATE, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE |
| | |
| NFS4ERR_BADNAME | CREATE, LINK, LOOKUP, OPEN, REMOVE, |
| | RENAME, SECINFO |
| | |
| NFS4ERR_BADOWNER | CREATE, OPEN, SETATTR |
| | |
| NFS4ERR_BADTYPE | CREATE |
| | |
| NFS4ERR_BADXDR | ACCESS, CB_GETATTR, CB_ILLEGAL, |
| | CB_RECALL, CLOSE, COMMIT, CREATE, |
| | DELEGPURGE, DELEGRETURN, GETATTR, |
| | ILLEGAL, LINK, LOCK, LOCKT, LOCKU, |
| | LOOKUP, NVERIFY, OPEN, OPENATTR, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, PUTFH, |
| | READ, READDIR, RELEASE_LOCKOWNER, |
| | REMOVE, RENAME, RENEW, SECINFO, |
| | SETATTR, SETCLIENTID, |
| | SETCLIENTID_CONFIRM, VERIFY, WRITE |
| | |
| NFS4ERR_BAD_COOKIE | READDIR |
| | |
| NFS4ERR_BAD_RANGE | LOCK, LOCKT, LOCKU |
| | |
| NFS4ERR_BAD_SEQID | CLOSE, LOCK, LOCKU, OPEN, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE |
| | |
| NFS4ERR_BAD_STATEID | CB_RECALL, CLOSE, DELEGRETURN, LOCK, |
| | LOCKU, OPEN, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, SETATTR, WRITE |
| | |
| NFS4ERR_CB_PATH_DOWN | RENEW |
| | |
| NFS4ERR_CLID_INUSE | SETCLIENTID, SETCLIENTID_CONFIRM |
| | |
| NFS4ERR_DEADLOCK | LOCK |
| | |
| NFS4ERR_DELAY | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, |
| | COMMIT, CREATE, DELEGPURGE, |
| | DELEGRETURN, GETATTR, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, |
| | OPEN_DOWNGRADE, PUTFH, PUTPUBFH, |
| | PUTROOTFH, READ, READDIR, READLINK, |
| | REMOVE, RENAME, SECINFO, SETATTR, |
| | SETCLIENTID, SETCLIENTID_CONFIRM, |
| | VERIFY, WRITE |
| | |
| NFS4ERR_DENIED | LOCK, LOCKT |
| | |
| NFS4ERR_DQUOT | CREATE, LINK, OPEN, OPENATTR, RENAME, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_EXIST | CREATE, LINK, OPEN, RENAME |
| | |
| NFS4ERR_EXPIRED | CLOSE, DELEGRETURN, LOCK, LOCKT, |
| | LOCKU, OPEN, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, |
| | RELEASE_LOCKOWNER, RENEW, SETATTR, |
| | WRITE |
| | |
| NFS4ERR_FBIG | OPEN, SETATTR, WRITE |
| | |
| NFS4ERR_BAD_COOKIE | READDIR |
| | |
| NFS4ERR_BAD_RANGE | LOCK, LOCKT, LOCKU |
| | |
| NFS4ERR_BAD_SEQID | CLOSE, LOCK, LOCKU, OPEN, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE |
| | |
| NFS4ERR_BAD_STATEID | CB_RECALL, CLOSE, DELEGRETURN, LOCK, |
| | LOCKU, OPEN, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, SETATTR, WRITE |
| | |
| NFS4ERR_CB_PATH_DOWN | RENEW |
| | |
| NFS4ERR_CLID_INUSE | SETCLIENTID, SETCLIENTID_CONFIRM |
| | |
| NFS4ERR_DEADLOCK | LOCK |
| | |
| NFS4ERR_DELAY | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, |
| | COMMIT, CREATE, DELEGPURGE, |
| | DELEGRETURN, GETATTR, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, |
| | OPEN_DOWNGRADE, PUTFH, PUTPUBFH, |
| | PUTROOTFH, READ, READDIR, READLINK, |
| | REMOVE, RENAME, SECINFO, SETATTR, |
| | SETCLIENTID, SETCLIENTID_CONFIRM, |
| | VERIFY, WRITE |
| | |
| NFS4ERR_DENIED | LOCK, LOCKT |
| | |
| NFS4ERR_DQUOT | CREATE, LINK, OPEN, OPENATTR, RENAME, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_EXIST | CREATE, LINK, OPEN, RENAME |
| | |
| NFS4ERR_EXPIRED | CLOSE, DELEGRETURN, LOCK, LOCKT, |
| | LOCKU, OPEN, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, |
| | RELEASE_LOCKOWNER, RENEW, SETATTR, |
| | WRITE |
| | |
| NFS4ERR_FBIG | OPEN, SETATTR, WRITE |
| | |
| NFS4ERR_FHEXPIRED | ACCESS, CLOSE, COMMIT, CREATE, |
| | GETATTR, GETFH, LINK, LOCK, LOCKT, |
| | LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE |
| | |
| NFS4ERR_FILE_OPEN | LINK, REMOVE, RENAME |
| | |
| NFS4ERR_GRACE | GETATTR, LOCK, LOCKT, LOCKU, NVERIFY, |
| | OPEN, READ, REMOVE, RENAME, SETATTR, |
| | VERIFY, WRITE |
| | |
| NFS4ERR_INVAL | ACCESS, CB_GETATTR, CLOSE, COMMIT, |
| | CREATE, DELEGRETURN, GETATTR, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, NVERIFY, |
| | OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, |
| | READ, READDIR, READLINK, REMOVE, |
| | RENAME, SECINFO, SETATTR, SETCLIENTID, |
| | VERIFY, WRITE |
| | |
| NFS4ERR_IO | ACCESS, COMMIT, CREATE, GETATTR, LINK, |
| | LOOKUP, LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, READ, READDIR, READLINK, |
| | REMOVE, RENAME, SETATTR, VERIFY, WRITE |
| | |
| NFS4ERR_ISDIR | CLOSE, COMMIT, LINK, LOCK, LOCKT, |
| | LOCKU, OPEN, OPEN_CONFIRM, READ, |
| | READLINK, SETATTR, WRITE |
| | |
| NFS4ERR_LEASE_MOVED | CLOSE, DELEGPURGE, DELEGRETURN, LOCK, |
| | LOCKT, LOCKU, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, |
| | RELEASE_LOCKOWNER, RENEW, SETATTR, |
| | WRITE |
| | |
| NFS4ERR_LOCKED | READ, SETATTR, WRITE |
| | |
| NFS4ERR_LOCKS_HELD | CLOSE, OPEN_DOWNGRADE, |
| | RELEASE_LOCKOWNER |
| | |
| NFS4ERR_LOCK_NOTSUPP | LOCK |
| | |
| NFS4ERR_LOCK_RANGE | LOCK, LOCKT, LOCKU |
| | |
| NFS4ERR_MLINK | LINK |
| NFS4ERR_FHEXPIRED | ACCESS, CLOSE, COMMIT, CREATE, |
| | GETATTR, GETFH, LINK, LOCK, LOCKT, |
| | LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE |
| | |
| NFS4ERR_FILE_OPEN | LINK, REMOVE, RENAME |
| | |
| NFS4ERR_GRACE | GETATTR, LOCK, LOCKT, LOCKU, NVERIFY, |
| | OPEN, READ, REMOVE, RENAME, SETATTR, |
| | VERIFY, WRITE |
| | |
| NFS4ERR_INVAL | ACCESS, CB_GETATTR, CLOSE, COMMIT, |
| | CREATE, DELEGRETURN, GETATTR, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, NVERIFY, |
| | OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, |
| | READ, READDIR, READLINK, REMOVE, |
| | RENAME, SECINFO, SETATTR, SETCLIENTID, |
| | VERIFY, WRITE |
| | |
| NFS4ERR_IO | ACCESS, COMMIT, CREATE, GETATTR, LINK, |
| | LOOKUP, LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, READ, READDIR, READLINK, |
| | REMOVE, RENAME, SETATTR, VERIFY, WRITE |
| | |
| NFS4ERR_ISDIR | CLOSE, COMMIT, LINK, LOCK, LOCKT, |
| | LOCKU, OPEN, OPEN_CONFIRM, READ, |
| | READLINK, SETATTR, WRITE |
| | |
| NFS4ERR_LEASE_MOVED | CLOSE, DELEGPURGE, DELEGRETURN, LOCK, |
| | LOCKT, LOCKU, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, |
| | RELEASE_LOCKOWNER, RENEW, SETATTR, |
| | WRITE |
| | |
| NFS4ERR_LOCKED | READ, SETATTR, WRITE |
| | |
| NFS4ERR_LOCKS_HELD | CLOSE, OPEN_DOWNGRADE, |
| | RELEASE_LOCKOWNER |
| | |
| NFS4ERR_LOCK_NOTSUPP | LOCK |
| | |
| NFS4ERR_LOCK_RANGE | LOCK, LOCKT, LOCKU |
| | |
| NFS4ERR_MLINK | LINK |
| | |
| NFS4ERR_MOVED | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE |
| | |
| NFS4ERR_NAMETOOLONG | CREATE, LINK, LOOKUP, OPEN, REMOVE, |
| | RENAME, SECINFO |
| | |
| NFS4ERR_NOENT | LINK, LOOKUP, LOOKUPP, OPEN, OPENATTR, |
| | REMOVE, RENAME, SECINFO |
| | |
| NFS4ERR_NOFILEHANDLE | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, READDIR, |
| | READLINK, REMOVE, RENAME, SAVEFH, |
| | SECINFO, SETATTR, VERIFY, WRITE |
| | |
| NFS4ERR_NOSPC | CREATE, LINK, OPEN, OPENATTR, RENAME, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_NOTDIR | CREATE, LINK, LOOKUP, LOOKUPP, OPEN, |
| | READDIR, REMOVE, RENAME, SECINFO |
| | |
| NFS4ERR_NOTEMPTY | REMOVE, RENAME |
| | |
| NFS4ERR_NOTSUPP | DELEGPURGE, DELEGRETURN, LINK, OPEN, |
| | OPENATTR, READLINK |
| | |
| NFS4ERR_NOT_SAME | READDIR, VERIFY |
| | |
| NFS4ERR_NO_GRACE | LOCK, OPEN |
| | |
| NFS4ERR_NXIO | WRITE |
| | |
| NFS4ERR_OLD_STATEID | CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_OPENMODE | LOCK, READ, SETATTR, WRITE |
| | |
| NFS4ERR_OP_ILLEGAL | CB_ILLEGAL, ILLEGAL |
| | |
| NFS4ERR_MOVED | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE |
| | |
| NFS4ERR_NAMETOOLONG | CREATE, LINK, LOOKUP, OPEN, REMOVE, |
| | RENAME, SECINFO |
| | |
| NFS4ERR_NOENT | LINK, LOOKUP, LOOKUPP, OPEN, OPENATTR, |
| | REMOVE, RENAME, SECINFO |
| | |
| NFS4ERR_NOFILEHANDLE | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, READDIR, |
| | READLINK, REMOVE, RENAME, SAVEFH, |
| | SECINFO, SETATTR, VERIFY, WRITE |
| | |
| NFS4ERR_NOSPC | CREATE, LINK, OPEN, OPENATTR, RENAME, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_NOTDIR | CREATE, LINK, LOOKUP, LOOKUPP, OPEN, |
| | READDIR, REMOVE, RENAME, SECINFO |
| | |
| NFS4ERR_NOTEMPTY | REMOVE, RENAME |
| | |
| NFS4ERR_NOTSUPP | DELEGPURGE, DELEGRETURN, LINK, OPEN, |
| | OPENATTR, READLINK |
| | |
| NFS4ERR_NOT_SAME | READDIR, VERIFY |
| | |
| NFS4ERR_NO_GRACE | LOCK, OPEN |
| | |
| NFS4ERR_NXIO | WRITE |
| | |
| NFS4ERR_OLD_STATEID | CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_OPENMODE | LOCK, READ, SETATTR, WRITE |
| | |
| NFS4ERR_OP_ILLEGAL | CB_ILLEGAL, ILLEGAL |
| | |
| NFS4ERR_PERM | CREATE, OPEN, SETATTR |
| | |
| NFS4ERR_RECLAIM_BAD | LOCK, OPEN |
| | |
| NFS4ERR_RECLAIM_CONFLICT | LOCK, OPEN |
| | |
| NFS4ERR_RESOURCE | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGPURGE, DELEGRETURN, GETATTR, |
| | GETFH, LINK, LOCK, LOCKT, LOCKU, |
| | LOOKUP, LOOKUPP, OPEN, OPENATTR, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | READDIR, READLINK, RELEASE_LOCKOWNER, |
| | REMOVE, RENAME, RENEW, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, SETCLIENTID, |
| | SETCLIENTID_CONFIRM, VERIFY, WRITE |
| | |
| NFS4ERR_RESTOREFH | RESTOREFH |
| | |
| NFS4ERR_ROFS | COMMIT, CREATE, LINK, OPEN, OPENATTR, |
| | OPEN_DOWNGRADE, REMOVE, RENAME, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_SAME | NVERIFY |
| | |
| NFS4ERR_SERVERFAULT | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, |
| | COMMIT, CREATE, DELEGPURGE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, PUTPUBFH, |
| | PUTROOTFH, READ, READDIR, READLINK, |
| | RELEASE_LOCKOWNER, REMOVE, RENAME, |
| | RENEW, RESTOREFH, SAVEFH, SECINFO, |
| | SETATTR, SETCLIENTID, |
| | SETCLIENTID_CONFIRM, VERIFY, WRITE |
| | |
| NFS4ERR_SHARE_DENIED | OPEN |
| | |
| NFS4ERR_STALE | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE |
| | |
| | |
| NFS4ERR_PERM | CREATE, OPEN, SETATTR |
| | |
| NFS4ERR_RECLAIM_BAD | LOCK, OPEN |
| | |
| NFS4ERR_RECLAIM_CONFLICT | LOCK, OPEN |
| | |
| NFS4ERR_RESOURCE | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGPURGE, DELEGRETURN, GETATTR, |
| | GETFH, LINK, LOCK, LOCKT, LOCKU, |
| | LOOKUP, LOOKUPP, OPEN, OPENATTR, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | READDIR, READLINK, RELEASE_LOCKOWNER, |
| | REMOVE, RENAME, RENEW, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, SETCLIENTID, |
| | SETCLIENTID_CONFIRM, VERIFY, WRITE |
| | |
| NFS4ERR_RESTOREFH | RESTOREFH |
| | |
| NFS4ERR_ROFS | COMMIT, CREATE, LINK, OPEN, OPENATTR, |
| | OPEN_DOWNGRADE, REMOVE, RENAME, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_SAME | NVERIFY |
| | |
| NFS4ERR_SERVERFAULT | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, |
| | COMMIT, CREATE, DELEGPURGE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, PUTPUBFH, |
| | PUTROOTFH, READ, READDIR, READLINK, |
| | RELEASE_LOCKOWNER, REMOVE, RENAME, |
| | RENEW, RESTOREFH, SAVEFH, SECINFO, |
| | SETATTR, SETCLIENTID, |
| | SETCLIENTID_CONFIRM, VERIFY, WRITE |
| | |
| NFS4ERR_SHARE_DENIED | OPEN |
| | |
| NFS4ERR_STALE | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE |
| | |
| NFS4ERR_STALE_CLIENTID | DELEGPURGE, LOCK, LOCKT, OPEN, |
| | RELEASE_LOCKOWNER, RENEW, |
| | SETCLIENTID_CONFIRM |
| | |
| NFS4ERR_STALE_STATEID | CLOSE, DELEGRETURN, LOCK, LOCKU, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_SYMLINK | COMMIT, LOOKUP, LOOKUPP, OPEN, READ, |
| | WRITE |
| | |
| NFS4ERR_TOOSMALL | READDIR |
| | |
| NFS4ERR_WRONGSEC | LINK, LOOKUP, LOOKUPP, OPEN, PUTFH, |
| | PUTPUBFH, PUTROOTFH, RENAME, RESTOREFH |
| | |
| NFS4ERR_XDEV | LINK, RENAME |
| | |
+--------------------------+----------------------------------------+
| NFS4ERR_STALE_CLIENTID | DELEGPURGE, LOCK, LOCKT, OPEN, |
| | RELEASE_LOCKOWNER, RENEW, |
| | SETCLIENTID_CONFIRM |
| | |
| NFS4ERR_STALE_STATEID | CLOSE, DELEGRETURN, LOCK, LOCKU, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE |
| | |
| NFS4ERR_SYMLINK | COMMIT, LOOKUP, LOOKUPP, OPEN, READ, |
| | WRITE |
| | |
| NFS4ERR_TOOSMALL | READDIR |
| | |
| NFS4ERR_WRONGSEC | LINK, LOOKUP, LOOKUPP, OPEN, PUTFH, |
| | PUTPUBFH, PUTROOTFH, RENAME, RESTOREFH |
| | |
| NFS4ERR_XDEV | LINK, RENAME |
| | |
+--------------------------+----------------------------------------+
Table 9: Errors and the Operations That Use Them
表9：错误和使用它们的操作
For the NFSv4 RPC program, there are two traditional RPC procedures: NULL and COMPOUND. All other functionality is defined as a set of operations, and these operations are defined in normal XDR/RPC syntax and semantics. However, these operations are encapsulated within the COMPOUND procedure. This requires that the client combine one or more of the NFSv4 operations into a single request.
对于NFSv4 RPC程序，有两个传统的RPC过程：NULL和component。所有其他功能都被定义为一组操作，这些操作是在正常的XDR/RPC语法和语义中定义的。但是，这些操作被封装在复合过程中。这要求客户端将一个或多个NFSv4操作合并到一个请求中。
The NFS4_CALLBACK program is used to provide server-to-client signaling and is constructed in a fashion similar to the NFSv4 program. The procedures CB_NULL and CB_COMPOUND are defined in the same way as NULL and COMPOUND are within the NFS program. The CB_COMPOUND request also encapsulates the remaining operations of the NFS4_CALLBACK program. There is no predefined RPC program number for the NFS4_CALLBACK program. It is up to the client to specify a program number in the "transient" program range. The program and port numbers of the NFS4_CALLBACK program are provided by the client as part of the SETCLIENTID/SETCLIENTID_CONFIRM sequence. The program and port can be changed by another SETCLIENTID/SETCLIENTID_CONFIRM sequence, and it is possible to use the sequence to change them within a client incarnation without removing relevant leased client state.
NFS4_回调程序用于提供服务器到客户端的信令，其构造方式与NFSv4程序类似。CB_NULL和CB_component过程的定义方式与NFS程序中的NULL和component过程相同。CB_复合请求还封装了NFS4_回调程序的其余操作。NFS4_回调程序没有预定义的RPC程序编号。由客户机在“瞬态”程序范围内指定程序编号。NFS4_回调程序的程序和端口号由客户端作为SETCLIENTID/SETCLIENTID_确认序列的一部分提供。程序和端口可以由另一个SETCLIENTID/SETCLIENTID_确认序列更改，并且可以使用该序列在客户端化身中更改它们，而无需删除相关的租用客户端状态。
The COMPOUND procedure provides the opportunity for better performance within high-latency networks. The client can avoid cumulative latency of multiple RPCs by combining multiple dependent operations into a single COMPOUND procedure. A COMPOUND operation may provide for protocol simplification by allowing the client to combine basic procedures into a single request that is customized for the client's environment.
复合过程提供了在高延迟网络中获得更好性能的机会。客户端可以通过将多个相关操作组合到一个复合过程中来避免多个RPC的累积延迟。复合操作可通过允许客户机将基本过程组合成针对客户机环境定制的单个请求来提供协议简化。
The CB_COMPOUND procedure precisely parallels the features of COMPOUND as described above.
CB_复合程序与上述复合物的特征完全平行。
The basic structure of the COMPOUND procedure is:
复合程序的基本结构是：
+-----+--------------+--------+-----------+-----------+-----------+--
| tag | minorversion | numops | op + args | op + args | op + args |
+-----+--------------+--------+-----------+-----------+-----------+--
+-----+--------------+--------+-----------+-----------+-----------+--
| tag | minorversion | numops | op + args | op + args | op + args |
+-----+--------------+--------+-----------+-----------+-----------+--
and the reply's structure is:
答覆的结构如下：
+------------+-----+--------+-----------------------+--
|last status | tag | numres | status + op + results |
+------------+-----+--------+-----------------------+--
+------------+-----+--------+-----------------------+--
|last status | tag | numres | status + op + results |
+------------+-----+--------+-----------------------+--
The numops and numres fields, used in the depiction above, represent the count for the counted array encoding used to signify the number of arguments or results encoded in the request and response. As per the XDR encoding, these counts must match exactly the number of operation arguments or results encoded.
上面描述中使用的numops和numres字段表示计数数组编码的计数，用于表示请求和响应中编码的参数或结果的数量。根据XDR编码，这些计数必须与编码的操作参数或结果的数量完全匹配。
The server will process the COMPOUND procedure by evaluating each of the operations within the COMPOUND procedure in order. Each component operation consists of a 32-bit operation code, followed by the argument of length determined by the type of operation. The results of each operation are encoded in sequence into a reply buffer. The results of each operation are preceded by the opcode and a status code (normally zero). If an operation results in a non-zero status code, the status will be encoded, evaluation of the COMPOUND sequence will halt, and the reply will be returned. Note that evaluation stops even in the event of "non-error" conditions such as NFS4ERR_SAME.
服务器将通过按顺序评估复合过程中的每个操作来处理复合过程。每个组件操作都由一个32位操作代码组成，后跟由操作类型确定的长度参数。每个操作的结果按顺序编码到应答缓冲区中。每个操作的结果前面都有操作码和状态码（通常为零）。如果操作导致非零状态代码，则状态将被编码，复合序列的评估将停止，并返回应答。请注意，即使在出现“非错误”条件（如NFS4ERR_）时，评估也会停止。
There are no atomicity requirements for the operations contained within the COMPOUND procedure. The operations being evaluated as part of a COMPOUND request may be evaluated simultaneously with other COMPOUND requests that the server receives.
复合程序中包含的操作没有原子性要求。作为复合请求一部分评估的操作可以与服务器接收的其他复合请求同时评估。
A COMPOUND is not a transaction, and it is the client's responsibility to recover from any partially completed COMPOUND procedure. These may occur at any point due to errors such as NFS4ERR_RESOURCE and NFS4ERR_DELAY. Note that these errors can occur in an otherwise valid operation string. Further, a server reboot that occurs in the middle of processing a COMPOUND procedure may leave the client with the difficult task of determining how far COMPOUND processing has proceeded. Therefore, the client should avoid overly complex COMPOUND procedures in the event of the failure of an operation within the procedure.
化合物不是交易，客户有责任从任何部分完成的化合物程序中恢复。由于NFS4ERR_资源和NFS4ERR_延迟等错误，这些错误可能会在任何时候发生。请注意，这些错误可能发生在其他有效的操作字符串中。此外，在处理复合过程的过程中发生的服务器重启可能会给客户端留下一个困难的任务，即确定复合处理已经进行了多远。因此，如果程序中的操作失败，客户应避免过于复杂的复合程序。
Each operation assumes a current filehandle and a saved filehandle that are available as part of the execution context of the COMPOUND request. Operations may set, change, or return the current filehandle. The saved filehandle is used for temporary storage of a filehandle value and as operands for the RENAME and LINK operations.
每个操作都假定一个当前文件句柄和一个保存的文件句柄，它们作为复合请求的执行上下文的一部分可用。操作可以设置、更改或返回当前文件句柄。保存的文件句柄用于临时存储文件句柄值，并用作重命名和链接操作的操作数。
NFSv4 operations that modify the file system are synchronous. When an operation is successfully completed at the server, the client can trust that any data associated with the request is now in stable storage (the one exception is in the case of the file data in a WRITE operation with the UNSTABLE4 option specified).
修改文件系统的NFSv4操作是同步的。当操作在服务器上成功完成时，客户机可以相信与请求相关联的任何数据现在都在稳定存储中（一个例外是在指定了UNSTABLE4选项的写操作中的文件数据）。
This implies that any previous operations within the same COMPOUND request are also reflected in stable storage. This behavior enables the client's ability to recover from a partially executed COMPOUND request that may have resulted from the failure of the server. For example, if a COMPOUND request contains operations A and B and the server is unable to send a response to the client, then depending on the progress the server made in servicing the request, the result of both operations may be reflected in stable storage or just operation A may be reflected. The server must not have just the results of operation B in stable storage.
这意味着同一复合请求中的任何先前操作也会反映在稳定存储中。此行为使客户端能够从可能由服务器故障导致的部分执行的复合请求中恢复。例如，如果一个复合请求包含操作a和B，而服务器无法向客户端发送响应，则根据服务器在服务该请求方面取得的进展，这两个操作的结果可能会反映在稳定存储中，或者只反映操作a。服务器不能只有稳定存储中的操作B的结果。
The operations encoded in the COMPOUND procedure are identified by operation values. To avoid overlap with the RPC procedure numbers, operations 0 (zero) and 1 are not defined. Operation 2 is not defined but is reserved for future use with minor versioning.
复合过程中编码的操作由操作值标识。为避免与RPC过程编号重叠，未定义操作0（零）和1。操作2未定义，但保留供将来使用，并带有次要版本控制。
<null>
<null>
void;
无效的
void;
无效的
Standard NULL procedure. Void argument, void response. This procedure has no functionality associated with it. Because of this, it is sometimes used to measure the overhead of processing a service request. Therefore, the server should ensure that no unnecessary work is done in servicing this procedure.
标准的空过程。无效的论点，无效的回应。此过程没有与之关联的功能。因此，它有时用于测量处理服务请求的开销。因此，服务器应确保在维护此过程时不会进行不必要的工作。
compoundargs -> compoundres
合成标记->合成标记
union nfs_argop4 switch (nfs_opnum4 argop) {
case <OPCODE>: <argument>;
...
};
union nfs_argop4 switch (nfs_opnum4 argop) {
case <OPCODE>: <argument>;
...
};
struct COMPOUND4args {
utf8str_cs tag;
uint32_t minorversion;
nfs_argop4 argarray<>;
};
struct COMPOUND4args {
utf8str_cs tag;
uint32_t minorversion;
nfs_argop4 argarray<>;
};
union nfs_resop4 switch (nfs_opnum4 resop) {
case <OPCODE>: <argument>;
...
};
union nfs_resop4 switch (nfs_opnum4 resop) {
case <OPCODE>: <argument>;
...
};
struct COMPOUND4res {
nfsstat4 status;
utf8str_cs tag;
nfs_resop4 resarray<>;
};
struct COMPOUND4res {
nfsstat4 status;
utf8str_cs tag;
nfs_resop4 resarray<>;
};
The COMPOUND procedure is used to combine one or more of the NFS operations into a single RPC request. The main NFS RPC program has two main procedures: NULL and COMPOUND. All other operations use the COMPOUND procedure as a wrapper.
复合过程用于将一个或多个NFS操作组合到单个RPC请求中。主NFS RPC程序有两个主要过程：NULL和component。所有其他操作都将复合过程用作包装器。
The COMPOUND procedure is used to combine individual operations into a single RPC request. The server interprets each of the operations in turn. If an operation is executed by the server and the status of that operation is NFS4_OK, then the next operation in the COMPOUND procedure is executed. The server continues this process until there are no more operations to be executed or one of the operations has a status value other than NFS4_OK.
复合过程用于将单个操作合并到单个RPC请求中。服务器依次解释每个操作。如果服务器执行一个操作，且该操作的状态为NFS4_OK，则执行复合过程中的下一个操作。服务器将继续此过程，直到不再执行任何操作，或者其中一个操作的状态值不是NFS4_OK。
In the processing of the COMPOUND procedure, the server may find that it does not have the available resources to execute any or all of the operations within the COMPOUND sequence. In this case, the error NFS4ERR_RESOURCE will be returned for the particular operation within the COMPOUND procedure where the resource exhaustion occurred. This assumes that all previous operations within the COMPOUND sequence have been evaluated successfully. The results for all of the evaluated operations must be returned to the client.
在复合过程的处理过程中，服务器可能会发现它没有可用的资源来执行复合序列中的任何或所有操作。在这种情况下，对于发生资源耗尽的复合过程中的特定操作，将返回错误NFS4ERR_资源。这假设复合序列中以前的所有操作都已成功评估。必须将所有已评估操作的结果返回给客户端。
The server will generally choose between two methods of decoding the client's request. The first would be the traditional one-pass XDR decode, in which decoding of the entire COMPOUND precedes execution of any operation within it. If there is an XDR decoding error in this case, an RPC XDR decode error would be returned. The second method would be to make an initial pass to decode the basic COMPOUND request and then to XDR decode each of the individual operations, as the server is ready to execute it. In this case, the server may encounter an XDR decode error during such an operation decode, after previous operations within the COMPOUND have been executed. In this case, the server would return the error NFS4ERR_BADXDR to signify the decode error.
服务器通常会在两种解码客户端请求的方法之间进行选择。第一种是传统的单通XDR解码，在这种解码中，整个化合物的解码先于其中任何操作的执行。如果在这种情况下存在XDR解码错误，将返回RPC XDR解码错误。第二种方法是在服务器准备执行基本复合请求时，进行初始传递以解码基本复合请求，然后对每个单独的操作进行XDR解码。在这种情况下，在执行了化合物内的先前操作之后，服务器可能在这样的解码操作期间遇到XDR解码错误。在这种情况下，服务器将返回错误NFS4ERR_BADXDR以表示解码错误。
The COMPOUND arguments contain a minorversion field. The initial and default value for this field is 0 (zero). This field will be used by future minor versions such that the client can communicate to the server what minor version is being requested. If the server receives a COMPOUND procedure with a minorversion field value that it does not support, the server MUST return an error of NFS4ERR_MINOR_VERS_MISMATCH and a zero-length resultdata array.
复合参数包含minorversion字段。此字段的初始值和默认值为0（零）。此字段将由将来的次要版本使用，以便客户端可以与服务器通信请求的次要版本。如果服务器接收到一个复合过程，其minorversion字段值不受支持，则服务器必须返回NFS4ERR_MINOR_VERS_MISMATCH错误和长度为零的resultdata数组。
Contained within the COMPOUND results is a status field. If the results array length is non-zero, this status must be equivalent to the status of the last operation that was executed within the COMPOUND procedure. Therefore, if an operation incurred an error, then the status value will be the same error value as is being returned for the operation that failed.
复合结果中包含一个状态字段。如果结果数组长度非零，则此状态必须与在复合过程中执行的最后一个操作的状态相等。因此，如果操作发生错误，则状态值将与为失败的操作返回的错误值相同。
Note that operations 0 (zero), 1 (one), and 2 (two) are not defined for the COMPOUND procedure. It is possible that the server receives a request that contains an operation that is less than the first legal operation (OP_ACCESS) or greater than the last legal operation (OP_RELEASE_LOCKOWNER). In this case, the server's response will encode the opcode OP_ILLEGAL rather than the illegal opcode of the request. The status field in the ILLEGAL return results will be set to NFS4ERR_OP_ILLEGAL. The COMPOUND procedure's return results will also be NFS4ERR_OP_ILLEGAL.
请注意，没有为复合过程定义操作0（零）、1（一）和2（二）。服务器接收到的请求可能包含小于第一个合法操作（OP_访问）或大于最后一个合法操作（OP_释放锁定所有者）的操作。在这种情况下，服务器的响应将把操作码OP_编码为非法，而不是请求的非法操作码。非法返回结果中的状态字段将设置为NFS4ERR_OP_非法。复合过程的返回结果也将是NFS4ERR_OP_非法的。
The definition of the "tag" in the request is left to the implementer. It may be used to summarize the content of the COMPOUND request for the benefit of packet sniffers and engineers debugging implementations. However, the value of "tag" in the response SHOULD be the same value as the value provided in the request. This applies to the tag field of the CB_COMPOUND procedure as well.
请求中“标记”的定义留给实现者。它可以用来总结复合请求的内容，以便包嗅探器和工程师调试实现。但是，响应中“tag”的值应该与请求中提供的值相同。这也适用于CB_复合过程的标记字段。
The current filehandle and the saved filehandle are used throughout the protocol. Most operations implicitly use the current filehandle as an argument, and many set the current filehandle as part of the results. The combination of client-specified sequences of operations and current and saved filehandle arguments and results allows for greater protocol flexibility. The best or easiest example of current filehandle usage is a sequence like the following:
当前文件句柄和保存的文件句柄在整个协议中使用。大多数操作隐式使用当前文件句柄作为参数，许多操作将当前文件句柄设置为结果的一部分。客户端指定的操作序列与当前和保存的filehandle参数和结果的组合允许更大的协议灵活性。当前filehandle用法的最佳或最简单示例是如下所示的序列：
PUTFH fh1 {fh1}
LOOKUP "compA" {fh2}
GETATTR {fh2}
LOOKUP "compB" {fh3}
GETATTR {fh3}
LOOKUP "compC" {fh4}
GETATTR {fh4}
GETFH
PUTFH fh1 {fh1}
LOOKUP "compA" {fh2}
GETATTR {fh2}
LOOKUP "compB" {fh3}
GETATTR {fh3}
LOOKUP "compC" {fh4}
GETATTR {fh4}
GETFH
Figure 1: Filehandle Usage Example
图1:Filehandle使用示例
In this example, the PUTFH (Section 16.20) operation explicitly sets the current filehandle value, while the result of each LOOKUP operation sets the current filehandle value to the resultant file system object. Also, the client is able to insert GETATTR operations using the current filehandle as an argument.
在本例中，PUTFH（第16.20节）操作显式设置当前filehandle值，而每个查找操作的结果将当前filehandle值设置为结果文件系统对象。此外，客户端还可以使用当前文件句柄作为参数插入GETATTR操作。
The PUTROOTFH (Section 16.22) and PUTPUBFH (Section 16.21) operations also set the current filehandle. The above example would replace "PUTFH fh1" with PUTROOTFH or PUTPUBFH with no filehandle argument in order to achieve the same effect (on the assumption that "compA" is directly below the root of the namespace).
PUTROOTFH（第16.22节）和PUTPUBFH（第16.21节）操作也设置当前文件句柄。上面的示例将“PUTFH fh1”替换为PUTROOTFH或PUTPUBFH（不带filehandle参数），以实现相同的效果（假设“compA”位于名称空间根的正下方）。
Along with the current filehandle, there is a saved filehandle. While the current filehandle is set as the result of operations like LOOKUP, the saved filehandle must be set directly with the use of the SAVEFH operation. The SAVEFH operation copies the current filehandle value to the saved value. The saved filehandle value is used in combination with the current filehandle value for the LINK and RENAME operations. The RESTOREFH operation will copy the saved filehandle
除了当前文件句柄之外，还有一个已保存的文件句柄。虽然当前文件句柄设置为查找等操作的结果，但必须使用SAVEFH操作直接设置保存的文件句柄。SAVEFH操作将当前文件句柄值复制到保存的值。保存的filehandle值与链接和重命名操作的当前filehandle值结合使用。RESTOREFH操作将复制保存的文件句柄
value to the current filehandle value; as a result, the saved filehandle value may be used as a sort of "scratch" area for the client's series of operations.
值设置为当前filehandle值；因此，保存的filehandle值可以用作客户端一系列操作的一种“暂存”区域。
Since an error of any type may occur after only a portion of the operations have been evaluated, the client must be prepared to recover from any failure. If the source of an NFS4ERR_RESOURCE error was a complex or lengthy set of operations, it is likely that if the number of operations were reduced the server would be able to evaluate them successfully. Therefore, the client is responsible for dealing with this type of complexity in recovery.
由于任何类型的错误都可能在仅评估了部分操作之后发生，因此客户机必须准备好从任何故障中恢复。如果NFS4ERR_资源错误的来源是一组复杂或冗长的操作，则如果操作数量减少，服务器很可能能够成功评估这些操作。因此，客户机负责处理恢复中的此类复杂性。
A single compound should not contain multiple operations that have different values for the clientid field used in OPEN, LOCK, or RENEW. This can cause confusion in cases in which operations that do not contain clientids have potential interactions with operations that do. When only a single clientid has been used, it is clear what client is being referenced. For a particular example involving the interaction of OPEN and GETATTR, see Section 16.16.6.
一个复合项不应包含多个操作，这些操作在“打开”、“锁定”或“续订”中使用的clientid字段的值不同。如果不包含clientId的操作与包含clientId的操作存在潜在交互，则这可能会导致混淆。当只使用了一个clientid时，很清楚引用的是什么客户端。有关涉及OPEN和GETATTR交互的特定示例，请参见第16.16.6节。
(cfh), accessreq -> supported, accessrights
（cfh），accessreq->支持，accessrights
const ACCESS4_READ = 0x00000001;
const ACCESS4_LOOKUP = 0x00000002;
const ACCESS4_MODIFY = 0x00000004;
const ACCESS4_EXTEND = 0x00000008;
const ACCESS4_DELETE = 0x00000010;
const ACCESS4_EXECUTE = 0x00000020;
const ACCESS4_READ = 0x00000001;
const ACCESS4_LOOKUP = 0x00000002;
const ACCESS4_MODIFY = 0x00000004;
const ACCESS4_EXTEND = 0x00000008;
const ACCESS4_DELETE = 0x00000010;
const ACCESS4_EXECUTE = 0x00000020;
struct ACCESS4args {
/* CURRENT_FH: object */
uint32_t access;
};
struct ACCESS4args {
/* CURRENT_FH: object */
uint32_t access;
};
struct ACCESS4resok {
uint32_t supported;
uint32_t access;
};
struct ACCESS4resok {
uint32_t supported;
uint32_t access;
};
union ACCESS4res switch (nfsstat4 status) {
case NFS4_OK:
ACCESS4resok resok4;
default:
void;
};
union ACCESS4res switch (nfsstat4 status) {
case NFS4_OK:
ACCESS4resok resok4;
default:
void;
};
ACCESS determines the access rights that a user, as identified by the credentials in the RPC request, has with respect to the file system object specified by the current filehandle. The client encodes the set of access rights that are to be checked in the bitmask "access". The server checks the permissions encoded in the bitmask. If a status of NFS4_OK is returned, two bitmasks are included in the response. The first, "supported", represents the access rights for which the server can verify reliably. The second, "access", represents the access rights available to the user for the filehandle provided. On success, the current filehandle retains its value.
ACCESS确定用户（由RPC请求中的凭据标识）对当前filehandle指定的文件系统对象具有的访问权限。客户端对要在位掩码“访问”中检查的访问权限集进行编码。服务器检查位掩码中编码的权限。如果返回NFS4_OK状态，则响应中包括两个位掩码。第一个“受支持”表示服务器可以可靠验证的访问权限。第二个“access”表示用户对提供的文件句柄的访问权限。成功后，当前文件句柄将保留其值。
Note that the supported field will contain only as many values as were originally sent in the arguments. For example, if the client sends an ACCESS operation with only the ACCESS4_READ value set and the server supports this value, the server will return only ACCESS4_READ even if it could have reliably checked other values.
请注意，支持的字段将只包含最初在参数中发送的值。例如，如果客户端发送的访问操作仅设置了ACCESS4\u读取值，并且服务器支持此值，则即使服务器可以可靠地检查其他值，服务器也将仅返回ACCESS4\u读取。
The results of this operation are necessarily advisory in nature. A return status of NFS4_OK and the appropriate bit set in the bitmask do not imply that such access will be allowed to the file system object in the future. This is because access rights can be revoked by the server at any time.
这一行动的结果必然具有咨询性质。NFS4_OK的返回状态和位掩码中设置的适当位并不意味着将来将允许对文件系统对象进行此类访问。这是因为服务器可以随时撤销访问权限。
The following access permissions may be requested:
可能会请求以下访问权限：
ACCESS4_READ: Read data from file or read a directory.
ACCESS4\u READ：从文件中读取数据或读取目录。
ACCESS4_LOOKUP: Look up a name in a directory (no meaning for non-directory objects).
ACCESS4\u查找：在目录中查找名称（对于非目录对象没有意义）。
ACCESS4_MODIFY: Rewrite existing file data or modify existing directory entries.
ACCESS4\u MODIFY：重写现有文件数据或修改现有目录项。
ACCESS4_EXTEND: Write new data or add directory entries.
ACCESS4\u EXTEND：写入新数据或添加目录项。
ACCESS4_DELETE: Delete an existing directory entry.
ACCESS4\u DELETE：删除现有目录项。
ACCESS4_EXECUTE: Execute file (no meaning for a directory).
ACCESS4\u EXECUTE:EXECUTE file（对目录没有意义）。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
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 file attributes or by attempting to interpret the contents of the ACL attribute. This is because the server may perform uid or gid mapping or enforce additional access control restrictions. It is also possible that the server may not be in the same ID space as the client. In these cases (and perhaps others), the client cannot reliably perform an access check with only current file attributes.
通常，客户端仅通过检查文件属性中的uid、gid和mode字段或尝试解释ACL属性的内容来推断访问权限是不够的。这是因为服务器可能会执行uid或gid映射，或者强制执行其他访问控制限制。服务器也可能与客户端不在同一ID空间中。在这些情况下（可能还有其他情况），客户机无法仅使用当前文件属性可靠地执行访问检查。
In the NFSv2 protocol, the only reliable way to determine whether an operation was allowed was to try it and see if it succeeded or failed. Using the ACCESS operation in the NFSv4 protocol, the client can ask the server to indicate whether or not one or more classes of operations are permitted. The ACCESS operation is provided to allow clients to check before doing a series of operations that might result in an access failure. The OPEN operation provides a point
在NFSv2协议中，确定是否允许操作的唯一可靠方法是尝试操作并查看操作是否成功。使用NFSv4协议中的访问操作，客户机可以要求服务器指示是否允许一个或多个操作类。提供访问操作是为了允许客户端在执行可能导致访问失败的一系列操作之前进行检查。打开操作提供了一个点
where the server can verify access to the file object and the method to return that information to the client. The ACCESS operation is still useful for directory operations or for use in the case where the UNIX API "access" is used on the client.
其中，服务器可以验证对文件对象的访问以及将该信息返回给客户端的方法。ACCESS操作对于目录操作或在客户端使用UNIX API“ACCESS”的情况下仍然有用。
The information returned by the server in response to an ACCESS call is not permanent. It was correct at the exact time that the server performed the checks, but not necessarily afterward. The server can revoke access permission at any time.
服务器响应访问调用返回的信息不是永久性的。服务器执行检查的确切时间是正确的，但不一定是在检查之后。服务器可以随时撤消访问权限。
The client should use the effective credentials of the user to build the authentication information in the ACCESS request used to determine access rights. It is the effective user and group credentials that are used in subsequent READ and WRITE operations.
客户端应使用用户的有效凭据在用于确定访问权限的访问请求中构建身份验证信息。在后续读写操作中使用的是有效的用户和组凭据。
Many implementations do not directly support the ACCESS4_DELETE permission. Operating systems like UNIX will ignore the ACCESS4_DELETE bit if set on an access request on a non-directory object. In these systems, delete permission on a file is determined by the access permissions on the directory in which the file resides, instead of being determined by the permissions of the file itself. Therefore, the mask returned enumerating which access rights can be supported will have the ACCESS4_DELETE value set to 0. This indicates to the client that the server was unable to check that particular access right. The ACCESS4_DELETE bit in the access mask returned will then be ignored by the client.
许多实现不直接支持ACCESS4_DELETE权限。如果在非目录对象的访问请求上设置了ACCESS4\u DELETE位，则UNIX等操作系统将忽略该位。在这些系统中，文件的删除权限由文件所在目录的访问权限决定，而不是由文件本身的权限决定。因此，返回的用于枚举可支持哪些访问权限的掩码将ACCESS4_DELETE值设置为0。这向客户端表明服务器无法检查特定的访问权限。然后，客户端将忽略返回的访问掩码中的ACCESS4_DELETE位。
(cfh), seqid, open_stateid -> open_stateid
（cfh），seqid，open_stateid->open_stateid
struct CLOSE4args {
/* CURRENT_FH: object */
seqid4 seqid;
stateid4 open_stateid;
};
struct CLOSE4args {
/* CURRENT_FH: object */
seqid4 seqid;
stateid4 open_stateid;
};
union CLOSE4res switch (nfsstat4 status) {
case NFS4_OK:
stateid4 open_stateid;
default:
void;
};
union CLOSE4res switch (nfsstat4 status) {
case NFS4_OK:
stateid4 open_stateid;
default:
void;
};
The CLOSE operation releases share reservations for the regular or named attribute file as specified by the current filehandle. The share reservations and other state information released at the server as a result of this CLOSE are only associated with the supplied stateid. The sequence id provides for the correct ordering. State associated with other OPENs is not affected.
关闭操作释放由当前文件句柄指定的常规或命名属性文件的共享保留。由于此关闭而在服务器上发布的共享保留和其他状态信息仅与提供的stateid关联。序列id提供了正确的顺序。与其他打开关联的状态不受影响。
If byte-range locks are held, the client SHOULD release all locks before issuing a CLOSE. The server MAY free all outstanding locks on CLOSE, but some servers may not support the CLOSE of a file that still has byte-range locks held. The server MUST return failure if any locks would exist after the CLOSE.
如果持有字节范围锁，客户端应在发出关闭之前释放所有锁。服务器可能会在关闭时释放所有未完成的锁，但某些服务器可能不支持关闭仍保留字节范围锁的文件。如果关闭后存在任何锁，服务器必须返回failure。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
Even though CLOSE returns a stateid, this stateid is not useful to the client and should be treated as deprecated. CLOSE "shuts down" the state associated with all OPENs for the file by a single open-owner. As noted above, CLOSE will either release all file locking state or return an error. Therefore, the stateid returned by CLOSE is not useful for the operations that follow.
即使CLOSE返回stateid，该stateid对客户端也没有用处，应视为已弃用。关闭“关闭”与单个打开所有者为文件打开的所有文件关联的状态。如上所述，CLOSE将释放所有文件锁定状态或返回错误。因此，CLOSE返回的stateid对于后面的操作没有用处。
(cfh), offset, count -> verifier
（cfh），偏移量，计数->验证器
struct COMMIT4args {
/* CURRENT_FH: file */
offset4 offset;
count4 count;
};
struct COMMIT4args {
/* CURRENT_FH: file */
offset4 offset;
count4 count;
};
struct COMMIT4resok {
verifier4 writeverf;
};
struct COMMIT4resok {
verifier4 writeverf;
};
union COMMIT4res switch (nfsstat4 status) {
case NFS4_OK:
COMMIT4resok resok4;
default:
void;
};
union COMMIT4res switch (nfsstat4 status) {
case NFS4_OK:
COMMIT4resok resok4;
default:
void;
};
The COMMIT operation forces or flushes data to stable storage for the file specified by the current filehandle. The flushed data is that which was previously written with a WRITE operation that had the stable field set to UNSTABLE4.
提交操作强制或刷新数据到由当前filehandle指定的文件的稳定存储中。刷新的数据是以前使用写入操作写入的数据，该操作的稳定字段设置为不稳定4。
The offset specifies the position within the file where the flush is to begin. An offset value of 0 (zero) means to flush data starting at the beginning of the file. The count specifies the number of bytes of data to flush. If count is 0 (zero), a flush from the offset to the end of the file is done.
偏移量指定文件中开始刷新的位置。偏移量值为0（零）表示从文件开头开始刷新数据。计数指定要刷新的数据字节数。如果计数为0（零），则完成从偏移量到文件末尾的刷新。
The server returns a write verifier upon successful completion of the COMMIT. The write verifier is used by the client to determine if the server has restarted or rebooted between the initial WRITE(s) and the COMMIT. The client does this by comparing the write verifier returned from the initial writes and the verifier returned by the COMMIT operation. The server must vary the value of the write verifier at each server event or instantiation that may lead to a
服务器在成功完成提交后返回写验证程序。客户机使用写入验证器来确定服务器在初始写入和提交之间是否已重新启动或重新启动。客户端通过比较从初始写入返回的写入验证器和提交操作返回的验证器来实现这一点。服务器必须在每个服务器事件或实例化时更改写入验证器的值，这可能导致
loss of uncommitted data. Most commonly, this occurs when the server is rebooted; however, other events at the server may result in uncommitted data loss as well.
丢失未提交的数据。最常见的情况是，服务器重新启动时会发生这种情况；但是，服务器上的其他事件也可能导致未提交的数据丢失。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
The COMMIT operation is similar in operation and semantics to the POSIX fsync() [fsync] system call that synchronizes a file's state with the disk (file data and metadata are flushed to disk or stable storage). COMMIT performs the same operation for a client, flushing any unsynchronized data and metadata on the server to the server's disk or stable storage for the specified file. Like fsync(), it may be that there is some modified data or no modified data to synchronize. The data may have been synchronized by the server's normal periodic buffer synchronization activity. COMMIT should return NFS4_OK, unless there has been an unexpected error.
提交操作在操作和语义上与POSIX fsync（）[fsync]系统调用类似，后者将文件状态与磁盘同步（文件数据和元数据刷新到磁盘或稳定存储）。COMMIT对客户端执行相同的操作，将服务器上的任何未同步数据和元数据刷新到服务器的磁盘或指定文件的稳定存储中。与fsync（）类似，可能有一些修改过的数据或没有修改过的数据需要同步。数据可能已由服务器的正常定期缓冲区同步活动同步。COMMIT应返回NFS4\u OK，除非出现意外错误。
COMMIT differs from fsync() in that it is possible for the client to flush a range of the file (most likely triggered by a buffer-reclamation scheme on the client before the file has been completely written).
COMMIT与fsync（）的不同之处在于，客户端可以刷新文件的某个范围（很可能是在文件完全写入之前由客户端上的缓冲区回收方案触发）。
The server implementation of COMMIT is reasonably simple. If the server receives a full file COMMIT request that is starting at offset 0 and count 0, it should do the equivalent of fsync()'ing the file. Otherwise, it should arrange to have the cached data in the range specified by offset and count to be flushed to stable storage. In both cases, any metadata associated with the file must be flushed to stable storage before returning. It is not an error for there to be nothing to flush on the server. This means that the data and metadata that needed to be flushed have already been flushed or lost during the last server failure.
提交的服务器实现相当简单。如果服务器接收到从偏移量0和计数0开始的完整文件提交请求，它应该执行与fsync（）相同的操作。否则，它应该将缓存数据安排在由offset和count指定的范围内，以便刷新到稳定存储中。在这两种情况下，在返回之前，必须将与文件关联的任何元数据刷新到稳定存储中。服务器上没有要刷新的内容不是错误。这意味着需要刷新的数据和元数据在上次服务器故障期间已被刷新或丢失。
The client implementation of COMMIT is a little more complex. There are two reasons for wanting to commit a client buffer to stable storage. The first is that the client wants to reuse a buffer. In this case, the offset and count of the buffer are sent to the server in the COMMIT request. The server then flushes any cached data based on the offset and count, and flushes any metadata associated with the file. It then returns the status of the flush and the write verifier. The other reason for the client to generate a COMMIT is for a full file flush, such as may be done at CLOSE. In this case, the client would gather all of the buffers for this file that contain uncommitted data, do the COMMIT operation with an offset of 0 and count of 0, and then free all of those buffers. Any other dirty buffers would be sent to the server in the normal fashion.
提交的客户端实现稍微复杂一些。想要将客户机缓冲区提交到稳定存储有两个原因。首先，客户机希望重用缓冲区。在这种情况下，缓冲区的偏移量和计数将在提交请求中发送到服务器。然后，服务器根据偏移量和计数刷新所有缓存数据，并刷新与文件关联的所有元数据。然后，它返回刷新和写入验证器的状态。客户机生成提交的另一个原因是进行完整的文件刷新，例如在关闭时进行。在这种情况下，客户端将为此文件收集包含未提交数据的所有缓冲区，使用偏移量0和计数0执行提交操作，然后释放所有这些缓冲区。任何其他脏缓冲区都将以正常方式发送到服务器。
After a buffer is written by the client with the stable parameter set to UNSTABLE4, the buffer must be considered modified by the client until the buffer has been either flushed via a COMMIT operation or written via a WRITE operation with the stable parameter set to FILE_SYNC4 or DATA_SYNC4. This is done to prevent the buffer from being freed and reused before the data can be flushed to stable storage on the server.
客户端在稳定参数设置为UNSTABLE4的情况下写入缓冲区后，必须认为客户端修改了缓冲区，直到通过提交操作刷新缓冲区或通过写入操作写入缓冲区，并将稳定参数设置为FILE_SYNC4或DATA_SYNC4。这样做是为了防止在将数据刷新到服务器上的稳定存储之前释放和重用缓冲区。
When a response is returned from either a WRITE or a COMMIT operation and it contains a write verifier that is different than previously returned by the server, the client will need to retransmit all of the buffers containing uncommitted cached data to the server. How this is to be done is up to the implementer. If there is only one buffer of interest, then it should probably be sent back over in a WRITE request with the appropriate stable parameter. If there is more than one buffer, it might be worthwhile to retransmit all of the buffers in WRITE requests with the stable parameter set to UNSTABLE4 and then retransmit the COMMIT operation to flush all of the data on the server to stable storage. The timing of these retransmissions is left to the implementer.
当从写操作或提交操作返回响应，并且其中包含与服务器先前返回的不同的写验证程序时，客户端需要将包含未提交缓存数据的所有缓冲区重新传输到服务器。如何做到这一点取决于实现者。如果只有一个感兴趣的缓冲区，那么可能应该在写请求中使用适当的稳定参数将其发送回。如果存在多个缓冲区，则可能值得在stable参数设置为UNSTABLE4的情况下重新传输写请求中的所有缓冲区，然后重新传输COMMIT操作以将服务器上的所有数据刷新到稳定存储。这些重传的时间留给实现者。
The above description applies to page-cache-based systems as well as buffer-cache-based systems. In those systems, the virtual memory system will need to be modified instead of the buffer cache.
上述描述适用于基于页面缓存的系统以及基于缓冲区缓存的系统。在这些系统中，需要修改虚拟内存系统，而不是缓存。
(cfh), name, type, attrs -> (cfh), cinfo, attrset
（cfh）、名称、类型、属性->（cfh）、cinfo、属性集
union createtype4 switch (nfs_ftype4 type) {
case NF4LNK:
linktext4 linkdata;
case NF4BLK:
case NF4CHR:
specdata4 devdata;
case NF4SOCK:
case NF4FIFO:
case NF4DIR:
void;
default:
void; /* server should return NFS4ERR_BADTYPE */
};
union createtype4 switch (nfs_ftype4 type) {
case NF4LNK:
linktext4 linkdata;
case NF4BLK:
case NF4CHR:
specdata4 devdata;
case NF4SOCK:
case NF4FIFO:
case NF4DIR:
void;
default:
void; /* server should return NFS4ERR_BADTYPE */
};
struct CREATE4args {
/* CURRENT_FH: directory for creation */
createtype4 objtype;
component4 objname;
fattr4 createattrs;
};
struct CREATE4args {
/* CURRENT_FH: directory for creation */
createtype4 objtype;
component4 objname;
fattr4 createattrs;
};
struct CREATE4resok {
change_info4 cinfo;
bitmap4 attrset; /* attributes set */
};
struct CREATE4resok {
change_info4 cinfo;
bitmap4 attrset; /* attributes set */
};
union CREATE4res switch (nfsstat4 status) {
case NFS4_OK:
CREATE4resok resok4;
default:
void;
};
union CREATE4res switch (nfsstat4 status) {
case NFS4_OK:
CREATE4resok resok4;
default:
void;
};
The CREATE operation creates a non-regular file object in a directory with a given name. The OPEN operation is used to create a regular file.
创建操作在具有给定名称的目录中创建一个非常规文件对象。“打开”操作用于创建常规文件。
The objname specifies the name for the new object. The objtype determines the type of object to be created: directory, symlink, etc.
objname指定新对象的名称。objtype确定要创建的对象的类型：目录、符号链接等。
If an object of the same name already exists in the directory, the server will return the error NFS4ERR_EXIST.
如果目录中已存在同名对象，服务器将返回错误NFS4ERR_EXIST。
For the directory where the new file object was created, the server returns change_info4 information in cinfo. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the file object creation.
对于创建新文件对象的目录，服务器返回cinfo中的change_info4信息。使用change_info4结构的原子字段，服务器将指示是否以原子方式获得了与文件对象创建相关的更改前后属性。
If the objname is of zero length, NFS4ERR_INVAL will be returned. The objname is also subject to the normal UTF-8, character support, and name checks. See Section 12.7 for further discussion.
如果对象名的长度为零，则将返回NFS4ERR_INVAL。objname还受正常UTF-8、字符支持和名称检查的约束。进一步讨论见第12.7节。
The current filehandle is replaced by that of the new object.
当前文件句柄将替换为新对象的文件句柄。
The createattrs field specifies the initial set of attributes for the object. The set of attributes may include any writable attribute valid for the object type. When the operation is successful, the server will return to the client an attribute mask signifying which attributes were successfully set for the object.
createattrs字段指定对象的初始属性集。属性集可以包括对对象类型有效的任何可写属性。操作成功后，服务器将向客户端返回一个属性掩码，表示已成功为对象设置了哪些属性。
If createattrs includes neither the owner attribute nor an ACL with an ACE for the owner, and if the server's file system both supports and requires an owner attribute (or an owner ACE), then the server MUST derive the owner (or the owner ACE). This would typically be from the principal indicated in the RPC credentials of the call, but the server's operating environment or file system semantics may dictate other methods of derivation. Similarly, if createattrs includes neither the group attribute nor a group ACE, and if the server's file system both supports and requires the notion of a group attribute (or group ACE), the server MUST derive the group attribute (or the corresponding owner ACE) for the file. This could be from the RPC's credentials, such as the group principal if the credentials include it (such as with AUTH_SYS), from the group identifier associated with the principal in the credentials (e.g., POSIX systems have a user database [getpwnam] that has the group identifier for every user identifier), inherited from the directory the object is
如果createattrs既不包含所有者属性，也不包含具有所有者ACE的ACL，并且如果服务器的文件系统既支持也需要所有者属性（或所有者ACE），则服务器必须派生所有者（或所有者ACE）。这通常来自调用的RPC凭据中指示的主体，但服务器的操作环境或文件系统语义可能会指定其他派生方法。类似地，如果createattrs既不包括组属性也不包括组ACE，并且如果服务器的文件系统既支持也需要组属性（或组ACE）的概念，则服务器必须派生文件的组属性（或相应的所有者ACE）。这可能来自RPC的凭据，例如，如果凭据包括组主体（例如使用AUTH_SYS），则来自与凭据中的主体关联的组标识符（例如，POSIX系统有一个用户数据库[getpwnam]，其中包含每个用户标识符的组标识符），从对象所在的目录继承
created in, or whatever else the server's operating environment or file system semantics dictate. This applies to the OPEN operation too.
在中创建，或服务器的操作环境或文件系统语义规定的任何其他内容。这也适用于打开操作。
Conversely, it is possible the client will specify in createattrs an owner attribute, group attribute, or ACL that the principal indicated the RPC's credentials does not have permissions to create files for. The error to be returned in this instance is NFS4ERR_PERM. This applies to the OPEN operation too.
相反，客户端可能会在createattrs中指定所有者属性、组属性或ACL，主体指示RPC的凭据没有为其创建文件的权限。此实例中返回的错误是NFS4ERR\u PERM。这也适用于打开操作。
If the client desires to set attribute values after the create, a SETATTR operation can be added to the COMPOUND request so that the appropriate attributes will be set.
如果客户端希望在创建后设置属性值，则可以向复合请求添加SETATTR操作，以便设置适当的属性。
clientid ->
clientid->
struct DELEGPURGE4args {
clientid4 clientid;
};
struct DELEGPURGE4args {
clientid4 clientid;
};
struct DELEGPURGE4res {
nfsstat4 status;
};
struct DELEGPURGE4res {
nfsstat4 status;
};
DELEGPURGE purges all of the delegations awaiting recovery for a given client. This is useful for clients that do not commit delegation information to stable storage, to indicate that conflicting requests need not be delayed by the server awaiting recovery of delegation information.
DELEGPURGE清除给定客户端等待恢复的所有委派。这对于不将委派信息提交到稳定存储的客户机非常有用，以表明冲突请求不需要由等待恢复委派信息的服务器延迟。
This operation is provided to support clients that record delegation information in stable storage on the client. In this case, DELEGPURGE should be issued immediately after doing delegation recovery (using CLAIM_DELEGATE_PREV) on all delegations known to the client. Doing so will notify the server that no additional delegations for the client will be recovered, allowing it to free resources and avoid delaying other clients who make requests that conflict with the unrecovered delegations. All clients SHOULD use DELEGPURGE as part of recovery once it is known that no further CLAIM_DELEGATE_PREV recovery will be done. This includes clients that do not record delegation information in stable storage, who would then do a DELEGPURGE immediately after SETCLIENTID_CONFIRM.
提供此操作是为了支持在客户端的稳定存储中记录委派信息的客户端。在这种情况下，应在对客户已知的所有委托进行委托恢复（使用CLAIM_DELEGATE_PREV）后立即发出DELEGPURGE。这样做将通知服务器不会恢复客户端的其他委派，从而允许服务器释放资源，避免延迟发出与未恢复委派冲突的请求的其他客户端。一旦知道不再进行进一步的索赔_DELEGATE _PREV恢复，所有客户都应使用delegpunce作为恢复的一部分。这包括不在稳定存储中记录委派信息的客户机，这些客户机将在SETCLIENTID\u确认后立即执行DELEGPURGE。
The set of delegations known to the server and the client may be different. The reasons for this include:
服务器和客户端已知的委托集可能不同。原因包括：
o A client may fail after making a request that resulted in delegation but before it received the results and committed them to the client's stable storage.
o 客户机在发出导致委派的请求后，但在收到结果并将其提交到客户机的稳定存储之前，可能会失败。
o A client may fail after deleting its indication that a delegation exists but before the delegation return is fully processed by the server.
o 在删除委托存在的指示后，但在服务器完全处理委托返回之前，客户端可能会失败。
o In the case in which the server and the client restart, the server may have limited persistent recording of delegations to a subset of those in existence.
o 在服务器和客户机重新启动的情况下，服务器可能将委托的持久记录限制为现有委托的子集。
o A client may have only persistently recorded information about a subset of delegations.
o 客户可能只持续记录有关委托子集的信息。
The server MAY support DELEGPURGE, but its support or non-support should match that of CLAIM_DELEGATE_PREV:
服务器可能支持DELEGPURGE，但其支持或不支持应与CLAIM_DELEGATE_PREV的支持或不支持相匹配：
o A server may support both DELEGPURGE and CLAIM_DELEGATE_PREV.
o 服务器可能同时支持DELEGPURGE和CLAIM_DELEGATE_PREV。
o A server may support neither DELEGPURGE nor CLAIM_DELEGATE_PREV.
o 服务器既不支持DELEGPURGE，也不支持CLAIM_DELEGATE_PREV。
This fact allows a client starting up to determine if the server is prepared to support persistent storage of delegation information and thus whether it may use write-back caching to local persistent storage, relying on CLAIM_DELEGATE_PREV recovery to allow such changed data to be flushed safely to the server in the event of client restart.
这一事实允许客户端启动以确定服务器是否准备好支持委派信息的持久存储，从而确定它是否可以使用对本地持久存储的写回缓存，依靠CLAIM_DELEGATE_PREV recovery允许在客户端重新启动时将更改的数据安全地刷新到服务器。
(cfh), stateid ->
（cfh），stateid->
struct DELEGRETURN4args {
/* CURRENT_FH: delegated file */
stateid4 deleg_stateid;
};
struct DELEGRETURN4args {
/* CURRENT_FH: delegated file */
stateid4 deleg_stateid;
};
struct DELEGRETURN4res {
nfsstat4 status;
};
struct DELEGRETURN4res {
nfsstat4 status;
};
DELEGRETURN returns the delegation represented by the current filehandle and stateid.
DELEGRETURN返回由当前文件句柄和stateid表示的委托。
Delegations may be returned when recalled or voluntarily (i.e., before the server has recalled them). In either case, the client must properly propagate state changed under the context of the delegation to the server before returning the delegation.
可以在撤回或自愿（即，在服务器撤回委托之前）返回委托。在任何一种情况下，客户机都必须在返回委托之前将委托上下文中更改的状态正确地传播到服务器。
(cfh), attrbits -> attrbits, attrvals
（cfh），属性->属性，属性
struct GETATTR4args {
/* CURRENT_FH: directory or file */
bitmap4 attr_request;
};
struct GETATTR4args {
/* CURRENT_FH: directory or file */
bitmap4 attr_request;
};
struct GETATTR4resok {
fattr4 obj_attributes;
};
struct GETATTR4resok {
fattr4 obj_attributes;
};
union GETATTR4res switch (nfsstat4 status) {
case NFS4_OK:
GETATTR4resok resok4;
default:
void;
};
union GETATTR4res switch (nfsstat4 status) {
case NFS4_OK:
GETATTR4resok resok4;
default:
void;
};
The GETATTR operation will obtain attributes for the file system object specified by the current filehandle. The client sets a bit in the bitmap argument for each attribute value that it would like the server to return. The server returns an attribute bitmap that indicates the attribute values for which it was able to return values, followed by the attribute values ordered lowest attribute number first.
GETATTR操作将获取由当前filehandle指定的文件系统对象的属性。客户端在位图参数中为希望服务器返回的每个属性值设置一位。服务器返回一个属性位图，该位图指示它能够返回值的属性值，然后是按最低属性编号排序的属性值。
The server MUST return a value for each attribute that the client requests if the attribute is supported by the server. If the server does not support an attribute or cannot approximate a useful value, then it MUST NOT return the attribute value and MUST NOT set the attribute bit in the result bitmap. The server MUST return an error if it supports an attribute on the target but cannot obtain its value. In that case, no attribute values will be returned.
如果服务器支持客户端请求的每个属性，则服务器必须为该属性返回一个值。如果服务器不支持属性或无法近似使用值，则它不得返回属性值，也不得在结果位图中设置属性位。如果服务器支持目标上的属性但无法获取其值，则必须返回错误。在这种情况下，不会返回任何属性值。
File systems that are absent should be treated as having support for a very small set of attributes as described in Section 8.3.1 -- even if previously, when the file system was present, more attributes were supported.
不存在的文件系统应被视为支持第8.3.1节中所述的一组非常小的属性——即使之前，当文件系统存在时，支持更多的属性。
All servers MUST support the REQUIRED attributes, as specified in Section 5, for all file systems, with the exception of absent file systems.
所有服务器必须支持所有文件系统所需的属性，如第5节所述，不存在的文件系统除外。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
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 set of attributes being interrogated. The server has two choices. First, the server can obtain the actual current value of these attributes from the client holding the delegation by using the CB_GETATTR callback. Second, the server, particularly when the delegated client is unresponsive, can recall the delegation in question. The GETATTR MUST NOT proceed until one of the following occurs:
假设另一个客户机为所讨论的文件持有一个OPEN_DELEGATE_WRITE委托，并且正在查询的属性集中包含大小和/或更改。服务器有两种选择。首先，服务器可以使用CB_GETATTR回调从持有委托的客户端获取这些属性的实际当前值。第二，服务器，特别是当委托的客户机没有响应时，可以调用有问题的委托。在发生以下情况之一之前，GETATTR不得继续：
o The requested attribute values are returned in the response to CB_GETATTR.
o 请求的属性值在对CB_GETATTR的响应中返回。
o The OPEN_DELEGATE_WRITE delegation is returned.
o 返回打开的委托和写入委托。
o The OPEN_DELEGATE_WRITE delegation is revoked.
o 已撤消开放委托和写入委托。
Unless one of the above happens very quickly, one or more NFS4ERR_DELAY errors will be returned while a delegation is outstanding.
除非上述任何一种情况很快发生，否则在委托未完成时将返回一个或多个NFS4ERR_延迟错误。
(cfh) -> filehandle
（cfh）->文件句柄
/* CURRENT_FH: */
void;
/* CURRENT_FH: */
void;
struct GETFH4resok {
nfs_fh4 object;
};
struct GETFH4resok {
nfs_fh4 object;
};
union GETFH4res switch (nfsstat4 status) {
case NFS4_OK:
GETFH4resok resok4;
default:
void;
};
union GETFH4res switch (nfsstat4 status) {
case NFS4_OK:
GETFH4resok resok4;
default:
void;
};
This operation returns the current filehandle value.
此操作返回当前的filehandle值。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
Operations that change the current filehandle, like LOOKUP or CREATE, do not automatically return the new filehandle as a result. For instance, if a client needs to look up a directory entry and obtain its filehandle, then the following request is needed.
更改当前文件句柄的操作（如查找或创建）不会自动返回新的文件句柄。例如，如果客户机需要查找目录条目并获取其文件句柄，则需要以下请求。
PUTFH (directory filehandle) LOOKUP (entry name) GETFH
PUTFH（目录文件句柄）查找（条目名称）GETFH
(sfh), (cfh), newname -> (cfh), cinfo
（sfh），（cfh），新名称->（cfh），cinfo
struct LINK4args {
/* SAVED_FH: source object */
/* CURRENT_FH: target directory */
component4 newname;
};
struct LINK4args {
/* SAVED_FH: source object */
/* CURRENT_FH: target directory */
component4 newname;
};
struct LINK4resok {
change_info4 cinfo;
};
struct LINK4resok {
change_info4 cinfo;
};
union LINK4res switch (nfsstat4 status) {
case NFS4_OK:
LINK4resok resok4;
default:
void;
};
union LINK4res switch (nfsstat4 status) {
case NFS4_OK:
LINK4resok resok4;
default:
void;
};
The LINK operation creates an additional newname for the file represented by the saved filehandle, as set by the SAVEFH operation, in the directory represented by the current filehandle. The existing file and the target directory must reside within the same file system on the server. On success, the current filehandle will continue to be the target directory. If an object exists in the target directory with the same name as newname, the server must return NFS4ERR_EXIST.
链接操作在当前文件句柄表示的目录中为保存的文件句柄表示的文件创建一个额外的新名称，如SAVEFH操作所设置的。现有文件和目标目录必须位于服务器上的同一文件系统中。成功后，当前文件句柄将继续作为目标目录。如果目标目录中存在与newname同名的对象，则服务器必须返回NFS4ERR_EXIST。
For the target directory, the server returns change_info4 information in cinfo. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the link creation.
对于目标目录，服务器返回cinfo中的change_info4信息。使用change_info4结构的原子字段，服务器将指示是否以原子方式获得了与链接创建相关的更改前后属性。
If newname has a length of 0 (zero), or if newname does not obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned.
如果newname的长度为0（零），或者如果newname不符合UTF-8定义，则将返回错误NFS4ERR_INVAL。
Changes to any property of the "hard" linked files are reflected in all of the linked files. When a link is made to a file, the attributes for the file should have a value for numlinks that is one greater than the value before the LINK operation.
对“硬”链接文件的任何属性所做的更改都会反映在所有链接文件中。链接到文件时，文件的属性的numlinks值应大于链接操作之前的值。
The statement "file and the target directory must reside within the same file system on the server" means that the fsid fields in the attributes for the objects are the same. If they reside on different file systems, the error NFS4ERR_XDEV is returned. This error may be returned by some servers when there is an internal partitioning of a file system that the LINK operation would violate.
语句“文件和目标目录必须位于服务器上的同一文件系统中”表示对象属性中的fsid字段相同。如果它们驻留在不同的文件系统上，则返回错误NFS4ERR_XDEV。当链接操作违反文件系统的内部分区时，某些服务器可能会返回此错误。
On some servers, "." and ".." are illegal values for newname, and the error NFS4ERR_BADNAME will be returned if they are specified.
在某些服务器上，“.”和“.”是newname的非法值，如果指定了它们，将返回错误NFS4ERR_BADNAME。
When the current filehandle designates a named attribute directory and the object to be linked (the saved filehandle) is not a named attribute for the same object, the error NFS4ERR_XDEV MUST be returned. When the saved filehandle designates a named attribute and the current filehandle is not the appropriate named attribute directory, the error NFS4ERR_XDEV MUST also be returned.
当当前文件句柄指定了命名属性目录，并且要链接的对象（保存的文件句柄）不是同一对象的命名属性时，必须返回错误NFS4ERR_XDEV。如果保存的filehandle指定了命名属性，而当前filehandle不是相应的命名属性目录，则还必须返回错误NFS4ERR_XDEV。
When the current filehandle designates a named attribute directory and the object to be linked (the saved filehandle) is a named attribute within that directory, the server MAY return the error NFS4ERR_NOTSUPP.
当当前文件句柄指定命名属性目录，并且要链接的对象（保存的文件句柄）是该目录中的命名属性时，服务器可能返回错误NFS4ERR_NOTSUPP。
In the case that newname is already linked to the file represented by the saved filehandle, the server will return NFS4ERR_EXIST.
如果newname已经链接到保存的文件句柄表示的文件，服务器将返回NFS4ERR_EXIST。
Note that symbolic links are created with the CREATE operation.
请注意，符号链接是通过创建操作创建的。
(cfh) locktype, reclaim, offset, length, locker -> stateid
（cfh）锁类型、回收、偏移、长度、锁->状态ID
enum nfs_lock_type4 {
READ_LT = 1,
WRITE_LT = 2,
READW_LT = 3, /* blocking read */
WRITEW_LT = 4 /* blocking write */
};
enum nfs_lock_type4 {
READ_LT = 1,
WRITE_LT = 2,
READW_LT = 3, /* blocking read */
WRITEW_LT = 4 /* blocking write */
};
/*
* For LOCK, transition from open_owner to new lock_owner
*/
struct open_to_lock_owner4 {
seqid4 open_seqid;
stateid4 open_stateid;
seqid4 lock_seqid;
lock_owner4 lock_owner;
};
/*
* For LOCK, transition from open_owner to new lock_owner
*/
struct open_to_lock_owner4 {
seqid4 open_seqid;
stateid4 open_stateid;
seqid4 lock_seqid;
lock_owner4 lock_owner;
};
/*
* For LOCK, existing lock_owner continues to request file locks
*/
struct exist_lock_owner4 {
stateid4 lock_stateid;
seqid4 lock_seqid;
};
/*
* For LOCK, existing lock_owner continues to request file locks
*/
struct exist_lock_owner4 {
stateid4 lock_stateid;
seqid4 lock_seqid;
};
union locker4 switch (bool new_lock_owner) {
case TRUE:
open_to_lock_owner4 open_owner;
case FALSE:
exist_lock_owner4 lock_owner;
};
union locker4 switch (bool new_lock_owner) {
case TRUE:
open_to_lock_owner4 open_owner;
case FALSE:
exist_lock_owner4 lock_owner;
};
/*
* LOCK/LOCKT/LOCKU: Record lock management
*/
struct LOCK4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
bool reclaim;
offset4 offset;
length4 length;
locker4 locker;
};
/*
* LOCK/LOCKT/LOCKU: Record lock management
*/
struct LOCK4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
bool reclaim;
offset4 offset;
length4 length;
locker4 locker;
};
struct LOCK4denied {
offset4 offset;
length4 length;
nfs_lock_type4 locktype;
lock_owner4 owner;
};
struct LOCK4denied {
offset4 offset;
length4 length;
nfs_lock_type4 locktype;
lock_owner4 owner;
};
struct LOCK4resok {
stateid4 lock_stateid;
};
struct LOCK4resok {
stateid4 lock_stateid;
};
union LOCK4res switch (nfsstat4 status) {
case NFS4_OK:
LOCK4resok resok4;
case NFS4ERR_DENIED:
LOCK4denied denied;
default:
void;
};
union LOCK4res switch (nfsstat4 status) {
case NFS4_OK:
LOCK4resok resok4;
case NFS4ERR_DENIED:
LOCK4denied denied;
default:
void;
};
The LOCK operation requests a byte-range lock for the byte range specified by the offset and length parameters. The lock type is also specified to be one of the nfs_lock_type4s. If this is a reclaim request, the reclaim parameter will be TRUE.
锁定操作请求对偏移和长度参数指定的字节范围进行字节范围锁定。锁类型也指定为nfs_lock_类型4s之一。如果这是回收请求，则回收参数将为TRUE。
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 through the end-of-file (no matter how long the file actually is), use a length field with all bits set to 1 (one). If the length is zero, or if a length that is not all bits set to one is specified, and the length when added to the offset exceeds the maximum 64-bit unsigned integer value, the error NFS4ERR_INVAL will result.
文件中的字节可能会被锁定，即使这些字节当前未分配给该文件。要从特定偏移量到文件末尾锁定文件（无论文件实际有多长），请使用所有位都设置为1（一）的长度字段。如果长度为零，或者指定了并非所有位都设置为1的长度，并且添加到偏移量时的长度超过最大64位无符号整数值，则将导致错误NFS4ERR_INVAL。
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 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, then such a 32-bit server MUST return the error NFS4ERR_BAD_RANGE.
32位服务器是支持锁定适合32位（即小于或等于NFS4_UINT32_MAX）的字节偏移量的服务器。如果客户端指定的范围与偏移量NFS4\u UINT32\u MAX以外的一个或多个字节重叠，但不以偏移量NFS4\u UINT64\u MAX结束，则此类32位服务器必须返回错误NFS4ERR\u BAD\u range。
In the case that the lock is denied, the owner, offset, and length of a conflicting lock are returned.
在锁被拒绝的情况下，将返回冲突锁的所有者、偏移量和长度。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
If the server is unable to determine the exact offset and length of the conflicting lock, the same offset and length that were provided in the arguments should be returned in the denied results. Section 9 contains a full description of this and the other file locking operations.
如果服务器无法确定冲突锁的确切偏移量和长度，则应在拒绝结果中返回参数中提供的相同偏移量和长度。第9节包含此操作和其他文件锁定操作的完整描述。
LOCK operations are subject to permission checks and to checks against the access type of the associated file. However, the specific rights and modes required for various types of locks reflect the semantics of the server-exported file system, and are not specified by the protocol. For example, Windows 2000 allows a write lock of a file open for READ, while a POSIX-compliant system does not.
锁定操作需要进行权限检查，并根据相关文件的访问类型进行检查。但是，各种类型的锁所需的特定权限和模式反映了服务器导出的文件系统的语义，协议没有指定这些权限和模式。例如，Windows 2000允许对打开读取的文件进行写锁定，而POSIX兼容系统则不允许。
When the client makes a lock request that corresponds to a range that the lock-owner has locked already (with the same or different lock type), or to a sub-region of such a range, or to a region that includes multiple locks already granted to that lock-owner, in whole or in part, and the server does not support such locking operations (i.e., does not support POSIX locking semantics), the server will return the error NFS4ERR_LOCK_RANGE. In that case, the client may return an error, or it may emulate the required operations, using only LOCK for ranges that do not include any bytes already locked by that lock-owner and LOCKU of locks held by that lock-owner (specifying an exactly matching range and type). Similarly, when the client makes a lock request that amounts to upgrading (changing from a read lock to a write lock) or downgrading (changing from a write lock to a read lock) an existing record lock and the server does not support such a lock, the server will return NFS4ERR_LOCK_NOTSUPP. Such operations may not perfectly reflect the required semantics in the face of conflicting lock requests from other clients.
当客户端发出与锁所有者已锁定的范围（使用相同或不同的锁类型）或该范围的子区域，或包含已全部或部分授予该锁所有者的多个锁的区域相对应的锁请求，并且服务器不支持此类锁定操作时（即，不支持POSIX锁定语义），服务器将返回错误NFS4ERR_LOCK_RANGE。在这种情况下，客户端可能会返回错误，或者它可能会模拟所需的操作，仅对不包括该锁所有者已锁定的任何字节的范围使用锁，并对该锁所有者持有的锁使用锁（指定完全匹配的范围和类型）。类似地，当客户端发出相当于升级（从读锁更改为写锁）或降级（从写锁更改为读锁）的锁请求时如果存在记录锁，且服务器不支持该锁，则服务器将返回NFS4ERR_lock_NOTSUPP。当来自其他客户端的锁请求发生冲突时，此类操作可能无法完美反映所需的语义。
When a client holds an OPEN_DELEGATE_WRITE delegation, the client holding that delegation is assured that there are no opens by other clients. Thus, there can be no conflicting LOCK operations from such
当一个客户机持有一个开放的委托书时，持有该委托书的客户机将确保没有其他客户机打开该委托书。因此，这种类型的锁操作不会发生冲突
clients. Therefore, the client may be handling locking requests locally, without doing LOCK operations on the server. If it does that, it must be prepared to update the lock status on the server by sending appropriate LOCK and LOCKU operations before returning the delegation.
客户。因此，客户端可能在本地处理锁定请求，而不在服务器上执行锁定操作。如果它这样做了，则必须准备在返回委派之前通过发送适当的锁定和锁定操作来更新服务器上的锁定状态。
When one or more clients hold OPEN_DELEGATE_READ delegations, any LOCK operation where the server is implementing mandatory locking semantics MUST result in the recall of all such delegations. The LOCK operation may not be granted until all such delegations are returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be returned to requests made while the delegation remains outstanding.
当一个或多个客户端持有OPEN_DELEGATE_READ委托时，服务器正在实现强制锁定语义的任何锁定操作都必须导致调用所有此类委托。在返回或撤销所有此类委托之前，不得授予锁定操作。除非这种情况发生得很快，否则在委托仍然未完成的情况下，一个或多个NFS4ERR_延迟错误将返回到请求。
The locker argument specifies the lock-owner that is associated with the LOCK request. The locker4 structure is a switched union that indicates whether the client has already created byte-range locking state associated with the current open file and lock-owner. There are multiple cases to be considered, corresponding to possible combinations of whether locking state has been created for the current open file and lock-owner, and whether the boolean new_lock_owner is set. In all of the cases, there is a lock_seqid specified, whether the lock-owner is specified explicitly or implicitly. This seqid value is used for checking lock-owner sequencing/replay issues. When the given lock-owner is not known to the server, this establishes an initial sequence value for the new lock-owner.
locker参数指定与锁请求关联的锁所有者。locker4结构是一个交换联合，它指示客户端是否已经创建了与当前打开的文件和锁所有者关联的字节范围锁定状态。有多种情况需要考虑，对应于是否为当前打开的文件和锁所有者创建了锁定状态，以及是否设置了布尔值new_lock_owner的可能组合。在所有情况下，无论是显式还是隐式指定锁所有者，都会指定一个锁seqid。此seqid值用于检查锁所有者排序/重播问题。当服务器不知道给定的锁所有者时，这将为新锁所有者建立初始序列值。
o In the case in which the state has been created and the boolean is false, the only part of the argument other than lock_seqid is just a stateid representing the set of locks associated with that open file and lock-owner.
o 在已创建状态且布尔值为false的情况下，除了lock_seqid之外，参数的唯一部分只是表示与打开的文件和锁所有者关联的锁集的stateid。
o In the case in which the state has been created and the boolean is true, the server rejects the request with the error NFS4ERR_BAD_SEQID. The only exception is where there is a retransmission of a previous request in which the boolean was true. In this case, the lock_seqid will match the original request, and the response will reflect the final case, below.
o 在已创建状态且布尔值为true的情况下，服务器将拒绝请求，错误为NFS4ERR_BAD_SEQID。唯一的例外是重新传输布尔值为true的前一个请求。在这种情况下，lock_seqid将匹配原始请求，响应将反映下面的最终情况。
o In the case where no byte-range locking state has been established and the boolean is true, the argument contains an open_to_lock_owner structure that specifies the stateid of the open file and the lock-owner to be used for the lock. Note that although the open-owner is not given explicitly, the open_seqid associated with it is used to check for open-owner sequencing issues. This case provides a method to use the established state of the open_stateid to transition to the use of a lock stateid.
o 在未建立字节范围锁定状态且布尔值为true的情况下，参数包含一个open_to_lock_owner结构，该结构指定打开文件的stateid和用于锁的锁所有者。请注意，尽管未明确给出开放所有者，但与之关联的开放seqid用于检查开放所有者排序问题。本例提供了一种使用open_stateid的已建立状态转换为使用lock stateid的方法。
(cfh) locktype, offset, length, owner -> {void, NFS4ERR_DENIED ->
owner}
(cfh) locktype, offset, length, owner -> {void, NFS4ERR_DENIED ->
owner}
struct LOCKT4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
offset4 offset;
length4 length;
lock_owner4 owner;
};
struct LOCKT4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
offset4 offset;
length4 length;
lock_owner4 owner;
};
union LOCKT4res switch (nfsstat4 status) {
case NFS4ERR_DENIED:
LOCK4denied denied;
case NFS4_OK:
void;
default:
void;
};
union LOCKT4res switch (nfsstat4 status) {
case NFS4ERR_DENIED:
LOCK4denied denied;
case NFS4_OK:
void;
default:
void;
};
The LOCKT operation tests the lock as specified in the arguments. If a conflicting lock exists, the owner, offset, length, and type of the conflicting lock are returned; if no lock is held, nothing other than NFS4_OK is returned. Lock types READ_LT and READW_LT are processed in the same way in that a conflicting lock test is done without regard to blocking or non-blocking. The same is true for WRITE_LT and WRITEW_LT.
LOCKT操作按照参数中的指定测试锁。如果存在冲突锁，则返回冲突锁的所有者、偏移量、长度和类型；如果没有锁定，则只返回NFS4_OK。锁类型READ_LT和READW_LT的处理方式与执行冲突锁测试的方式相同，不考虑阻塞或非阻塞。WRITE_LT和WRITEW_LT也是如此。
The ranges are specified as for LOCK. The NFS4ERR_INVAL and NFS4ERR_BAD_RANGE errors are returned under the same circumstances as for LOCK.
这些范围指定为“锁定”。NFS4ERR_INVAL和NFS4ERR_BAD_范围错误在与LOCK相同的情况下返回。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
If the server is unable to determine the exact offset and length of the conflicting lock, the same offset and length that were provided in the arguments should be returned in the denied results. Section 9 contains further discussion of the file locking mechanisms.
如果服务器无法确定冲突锁的确切偏移量和长度，则应在拒绝结果中返回参数中提供的相同偏移量和长度。第9节进一步讨论了文件锁定机制。
LOCKT uses a lock_owner4, rather than a stateid4 as is used in LOCK, to identify the owner. This is because the client does not have to open the file to test for the existence of a lock, so a stateid may not be available.
LOCKT使用lock_owner4来标识所有者，而不是lock中使用的stateid4。这是因为客户端不必打开文件来测试是否存在锁，因此stateid可能不可用。
The test for conflicting locks SHOULD exclude locks for the current lock-owner. Note that since such locks are not examined the possible existence of overlapping ranges may not affect the results of LOCKT. If the server does examine locks that match the lock-owner for the purpose of range checking, NFS4ERR_LOCK_RANGE may be returned. In the event that it returns NFS4_OK, clients may do a LOCK and receive NFS4ERR_LOCK_RANGE on the LOCK request because of the flexibility provided to the server.
冲突锁的测试应排除当前锁所有者的锁。注意，由于未检查此类锁，重叠范围的可能存在可能不会影响锁的结果。如果服务器出于范围检查的目的检查与锁所有者匹配的锁，则可能会返回NFS4ERR_lock_range。在返回NFS4_OK的情况下，由于服务器提供的灵活性，客户端可能会执行锁定并在锁定请求上接收NFS4ERR_LOCK_范围。
When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose (see Section 16.10.5) to handle LOCK requests locally. In such a case, LOCKT requests will similarly be handled locally.
当客户端持有OPEN_DELEGATE_WRITE委派时，它可以选择（参见第16.10.5节）在本地处理锁定请求。在这种情况下，LOCKT请求将类似地在本地处理。
(cfh) type, seqid, stateid, offset, length -> stateid
（cfh）类型，序号ID，状态ID，偏移量，长度->状态ID
struct LOCKU4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
seqid4 seqid;
stateid4 lock_stateid;
offset4 offset;
length4 length;
};
struct LOCKU4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
seqid4 seqid;
stateid4 lock_stateid;
offset4 offset;
length4 length;
};
union LOCKU4res switch (nfsstat4 status) {
case NFS4_OK:
stateid4 lock_stateid;
default:
void;
};
union LOCKU4res switch (nfsstat4 status) {
case NFS4_OK:
stateid4 lock_stateid;
default:
void;
};
The LOCKU operation unlocks the byte-range lock specified by the parameters. The client may set the locktype field to any value that is legal for the nfs_lock_type4 enumerated type, and the server MUST accept any legal value for locktype. Any legal value for locktype has no effect on the success or failure of the LOCKU operation.
LOCKU操作解锁参数指定的字节范围锁。客户端可以将locktype字段设置为nfs_lock_type4枚举类型的任何合法值，服务器必须接受locktype的任何合法值。locktype的任何法律价值对LOCKU操作的成功或失败没有影响。
The ranges are specified as for LOCK. The NFS4ERR_INVAL and NFS4ERR_BAD_RANGE errors are returned under the same circumstances as for LOCK.
这些范围指定为“锁定”。NFS4ERR_INVAL和NFS4ERR_BAD_范围错误在与LOCK相同的情况下返回。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
If the area to be unlocked does not correspond exactly to a lock actually held by the lock-owner, the server may return the error NFS4ERR_LOCK_RANGE. This includes the cases where (1) the area is not locked, (2) the area is a sub-range of the area locked, (3) it overlaps the area locked without matching exactly, or (4) the area specified includes multiple locks held by the lock-owner. In all of these cases, allowed by POSIX locking [fcntl] semantics, a client receiving this error should, if it desires support for such operations, simulate the operation using LOCKU on ranges corresponding to locks it actually holds, possibly followed by LOCK requests for the sub-ranges not being unlocked.
如果要解锁的区域与锁所有者实际持有的锁不完全对应，服务器可能返回错误NFS4ERR_lock_RANGE。这包括以下情况：（1）该区域未锁定，（2）该区域是锁定区域的子范围，（3）该区域与锁定区域重叠但不完全匹配，或（4）指定区域包括锁所有者持有的多个锁。在所有这些情况下，POSIX locking[fcntl]语义允许，如果接收到此错误的客户端希望支持此类操作，则应在其实际持有的锁对应的范围上使用LOCKU模拟该操作，随后可能会对未解锁的子范围发出锁请求。
When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose (see Section 16.10.5) to handle LOCK requests locally. In such a case, LOCKU requests will similarly be handled locally.
当客户端持有OPEN_DELEGATE_WRITE委派时，它可以选择（参见第16.10.5节）在本地处理锁定请求。在这种情况下，LOCKU请求也将在本地处理。
(cfh), component -> (cfh)
（cfh），组件->（cfh）
struct LOOKUP4args {
/* CURRENT_FH: directory */
component4 objname;
};
struct LOOKUP4args {
/* CURRENT_FH: directory */
component4 objname;
};
struct LOOKUP4res {
/* CURRENT_FH: object */
nfsstat4 status;
};
struct LOOKUP4res {
/* CURRENT_FH: object */
nfsstat4 status;
};
This operation performs a LOOKUP or finds a file system object using the directory specified by the current filehandle. LOOKUP evaluates the component and if the object exists the current filehandle is replaced with the component's filehandle.
此操作使用当前文件句柄指定的目录执行查找或查找文件系统对象。查找计算组件，如果对象存在，则当前文件句柄将替换为组件的文件句柄。
If the component cannot be evaluated because either it does not exist or the client does not have permission to evaluate it, then an error will be returned, and the current filehandle will be unchanged.
如果由于组件不存在或客户端没有对其求值的权限而无法对其求值，则将返回一个错误，并且当前文件句柄将保持不变。
If the component is of zero length, NFS4ERR_INVAL will be returned. The component is also subject to the normal UTF-8, character support, and name checks. See Section 12.7 for further discussion.
如果组件长度为零，将返回NFS4ERR_INVAL。该组件还需要进行常规UTF-8、字符支持和名称检查。进一步讨论见第12.7节。
If the client wants to achieve the effect of a multi-component lookup, it may construct a COMPOUND request such as the following (and obtain each filehandle):
如果客户端希望实现多组件查找的效果，它可以构造一个复合请求，如以下所示（并获取每个文件句柄）：
PUTFH (directory filehandle) LOOKUP "pub" GETFH LOOKUP "foo" GETFH LOOKUP "bar" GETFH
PUTFH（目录文件句柄）查找“pub”GETFH查找“foo”GETFH查找“bar”GETFH
NFSv4 servers depart from the semantics of previous NFS versions in allowing LOOKUP requests to cross mount points on the server. The client can detect a mount point crossing by comparing the fsid attribute of the directory with the fsid attribute of the directory looked up. If the fsids are different, then the new directory is a server mount point. UNIX clients that detect a mount point crossing will need to mount the server's file system. This needs to be done to maintain the file object identity-checking mechanisms common to UNIX clients.
NFSv4服务器允许查找请求跨服务器上的装载点，这与以前的NFS版本的语义不同。客户端可以通过比较目录的fsid属性和查找的目录的fsid属性来检测装载点交叉。如果FSID不同，则新目录是服务器装载点。检测到装载点交叉的UNIX客户端需要装载服务器的文件系统。需要这样做才能维护UNIX客户机通用的文件对象身份检查机制。
Servers that limit NFS access to "shares" or "exported" file systems should provide a pseudo-file system into which the exported file systems can be integrated, so that clients can browse the server's namespace. The clients' view of a pseudo-file system will be limited to paths that lead to exported file systems.
限制NFS访问“共享”或“导出”文件系统的服务器应该提供一个虚拟文件系统，导出的文件系统可以集成到其中，以便客户端可以浏览服务器的命名空间。客户端对伪文件系统的视图将限于指向导出文件系统的路径。
Note: Previous versions of the protocol assigned special semantics to the names "." and "..". NFSv4 assigns no special semantics to these names. The LOOKUPP operator must be used to look up a parent directory.
注：协议的早期版本为名称“.”和“.”指定了特殊语义。NFSv4没有为这些名称指定特殊的语义。必须使用LOOKUPP运算符查找父目录。
Note that this operation does not follow symbolic links. The client is responsible for all parsing of filenames, including filenames that are modified by symbolic links encountered during the lookup process.
请注意，此操作不遵循符号链接。客户端负责所有文件名的解析，包括在查找过程中遇到的符号链接修改的文件名。
If the current filehandle supplied is not a directory but a symbolic link, NFS4ERR_SYMLINK is returned as the error. For all other non-directory file types, the error NFS4ERR_NOTDIR is returned.
如果提供的当前文件句柄不是目录而是符号链接，则NFS4ERR_SYMLINK将作为错误返回。对于所有其他非目录文件类型，将返回错误NFS4ERR_NOTDIR。
(cfh) -> (cfh)
（cfh）->（cfh）
/* CURRENT_FH: object */
void;
/* CURRENT_FH: object */
void;
struct LOOKUPP4res {
/* CURRENT_FH: directory */
nfsstat4 status;
};
struct LOOKUPP4res {
/* CURRENT_FH: directory */
nfsstat4 status;
};
The current filehandle is assumed to refer to a regular directory or a named attribute directory. LOOKUPP assigns the filehandle for its parent directory to be the current filehandle. If there is no parent directory, an NFS4ERR_NOENT error must be returned. Therefore, NFS4ERR_NOENT will be returned by the server when the current filehandle is at the root or top of the server's file tree.
假定当前文件句柄引用常规目录或命名属性目录。LOOKUPP将其父目录的文件句柄指定为当前文件句柄。如果没有父目录，则必须返回NFS4ERR\u NOENT错误。因此，当当前文件句柄位于服务器文件树的根或顶部时，服务器将返回NFS4ERR_NOENT。
As for LOOKUP, LOOKUPP will also cross mount points.
至于查找，LOOKUPP还将跨装入点。
If the current filehandle is not a directory or named attribute directory, the error NFS4ERR_NOTDIR is returned.
如果当前文件句柄不是目录或命名属性目录，则返回错误NFS4ERR\u NOTDIR。
If the current filehandle is a named attribute directory that is associated with a file system object via OPENATTR (i.e., not a subdirectory of a named attribute directory), LOOKUPP SHOULD return the filehandle of the associated file system object.
如果当前文件句柄是通过OPENATTR与文件系统对象关联的命名属性目录（即，不是命名属性目录的子目录），LOOKUPP应返回关联文件系统对象的文件句柄。
(cfh), fattr -> -
(cfh), fattr -> -
struct NVERIFY4args {
/* CURRENT_FH: object */
fattr4 obj_attributes;
};
struct NVERIFY4args {
/* CURRENT_FH: object */
fattr4 obj_attributes;
};
struct NVERIFY4res {
nfsstat4 status;
};
struct NVERIFY4res {
nfsstat4 status;
};
This operation is used to prefix a sequence of operations to be performed if one or more attributes have changed on some file system object. If all the attributes match, then the error NFS4ERR_SAME must be returned.
如果某个文件系统对象上的一个或多个属性已更改，则此操作用于为要执行的操作序列添加前缀。如果所有属性都匹配，则必须返回错误NFS4ERR_SAME。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
This operation is useful as a cache validation operator. If the object to which the attributes belong has changed, then the following operations may obtain new data associated with that object -- for instance, to check if a file has been changed and obtain new data if it has:
此操作作为缓存验证运算符很有用。如果属性所属的对象已更改，则以下操作可能会获取与该对象关联的新数据——例如，检查文件是否已更改，如果已更改，则获取新数据：
PUTFH (public) LOOKUP "foobar" NVERIFY attrbits attrs READ 0 32767
PUTFH（公共）查找“foobar”n验证属性位属性读取0 32767
In the case that a RECOMMENDED attribute is specified in the NVERIFY operation and the server does not support that attribute for the file system object, the error NFS4ERR_ATTRNOTSUPP is returned to the client.
如果在NVERIFY操作中指定了建议的属性，并且服务器不支持文件系统对象的该属性，则会将错误NFS4ERR_ATTRNOTSUPP返回给客户端。
When the attribute rdattr_error or any write-only attribute (e.g., time_modify_set) is specified, the error NFS4ERR_INVAL is returned to the client.
当指定属性rdattr_error或任何只写属性（例如，time_modify_set）时，错误NFS4ERR_INVAL将返回给客户端。
(cfh), seqid, share_access, share_deny, owner, openhow, claim -> (cfh), stateid, cinfo, rflags, attrset, delegation
（cfh）、seqid、共享访问、共享拒绝、所有者、openhow、索赔->（cfh）、stateid、cinfo、rflags、属性集、委托
/*
* Various definitions for OPEN
*/
enum createmode4 {
UNCHECKED4 = 0,
GUARDED4 = 1,
EXCLUSIVE4 = 2
};
/*
* Various definitions for OPEN
*/
enum createmode4 {
UNCHECKED4 = 0,
GUARDED4 = 1,
EXCLUSIVE4 = 2
};
union createhow4 switch (createmode4 mode) {
case UNCHECKED4:
case GUARDED4:
fattr4 createattrs;
case EXCLUSIVE4:
verifier4 createverf;
};
union createhow4 switch (createmode4 mode) {
case UNCHECKED4:
case GUARDED4:
fattr4 createattrs;
case EXCLUSIVE4:
verifier4 createverf;
};
enum opentype4 {
OPEN4_NOCREATE = 0,
OPEN4_CREATE = 1
};
enum opentype4 {
OPEN4_NOCREATE = 0,
OPEN4_CREATE = 1
};
union openflag4 switch (opentype4 opentype) {
case OPEN4_CREATE:
createhow4 how;
default:
void;
};
union openflag4 switch (opentype4 opentype) {
case OPEN4_CREATE:
createhow4 how;
default:
void;
};
/* Next definitions used for OPEN delegation */
enum limit_by4 {
NFS_LIMIT_SIZE = 1,
NFS_LIMIT_BLOCKS = 2
/* others as needed */
};
/* Next definitions used for OPEN delegation */
enum limit_by4 {
NFS_LIMIT_SIZE = 1,
NFS_LIMIT_BLOCKS = 2
/* others as needed */
};
struct nfs_modified_limit4 {
uint32_t num_blocks;
uint32_t bytes_per_block;
};
struct nfs_modified_limit4 {
uint32_t num_blocks;
uint32_t bytes_per_block;
};
union nfs_space_limit4 switch (limit_by4 limitby) {
/* limit specified as file size */
case NFS_LIMIT_SIZE:
uint64_t filesize;
/* limit specified by number of blocks */
case NFS_LIMIT_BLOCKS:
nfs_modified_limit4 mod_blocks;
};
union nfs_space_limit4 switch (limit_by4 limitby) {
/* limit specified as file size */
case NFS_LIMIT_SIZE:
uint64_t filesize;
/* limit specified by number of blocks */
case NFS_LIMIT_BLOCKS:
nfs_modified_limit4 mod_blocks;
};
enum open_delegation_type4 {
OPEN_DELEGATE_NONE = 0,
OPEN_DELEGATE_READ = 1,
OPEN_DELEGATE_WRITE = 2
};
enum open_delegation_type4 {
OPEN_DELEGATE_NONE = 0,
OPEN_DELEGATE_READ = 1,
OPEN_DELEGATE_WRITE = 2
};
enum open_claim_type4 {
CLAIM_NULL = 0,
CLAIM_PREVIOUS = 1,
CLAIM_DELEGATE_CUR = 2,
CLAIM_DELEGATE_PREV = 3
};
enum open_claim_type4 {
CLAIM_NULL = 0,
CLAIM_PREVIOUS = 1,
CLAIM_DELEGATE_CUR = 2,
CLAIM_DELEGATE_PREV = 3
};
struct open_claim_delegate_cur4 {
stateid4 delegate_stateid;
component4 file;
};
struct open_claim_delegate_cur4 {
stateid4 delegate_stateid;
component4 file;
};
union open_claim4 switch (open_claim_type4 claim) {
/*
* No special rights to file.
* Ordinary OPEN of the specified file.
*/
case CLAIM_NULL:
/* CURRENT_FH: directory */
component4 file;
/*
* Right to the file established by an
* open previous to server reboot. File
* identified by filehandle obtained at
* that time rather than by name.
*/
case CLAIM_PREVIOUS:
/* CURRENT_FH: file being reclaimed */
open_delegation_type4 delegate_type;
union open_claim4 switch (open_claim_type4 claim) {
/*
* No special rights to file.
* Ordinary OPEN of the specified file.
*/
case CLAIM_NULL:
/* CURRENT_FH: directory */
component4 file;
/*
* Right to the file established by an
* open previous to server reboot. File
* identified by filehandle obtained at
* that time rather than by name.
*/
case CLAIM_PREVIOUS:
/* CURRENT_FH: file being reclaimed */
open_delegation_type4 delegate_type;
/*
* Right to file based on a delegation
* granted by the server. File is
* specified by name.
*/
case CLAIM_DELEGATE_CUR:
/* CURRENT_FH: directory */
open_claim_delegate_cur4 delegate_cur_info;
/*
* Right to file based on a delegation
* granted by the server. File is
* specified by name.
*/
case CLAIM_DELEGATE_CUR:
/* CURRENT_FH: directory */
open_claim_delegate_cur4 delegate_cur_info;
/*
* Right to file based on a delegation
* granted to a previous boot instance
* of the client. File is specified by name.
*/
case CLAIM_DELEGATE_PREV:
/* CURRENT_FH: directory */
component4 file_delegate_prev;
};
/*
* Right to file based on a delegation
* granted to a previous boot instance
* of the client. File is specified by name.
*/
case CLAIM_DELEGATE_PREV:
/* CURRENT_FH: directory */
component4 file_delegate_prev;
};
/*
* OPEN: Open a file, potentially receiving an open delegation
*/
struct OPEN4args {
seqid4 seqid;
uint32_t share_access;
uint32_t share_deny;
open_owner4 owner;
openflag4 openhow;
open_claim4 claim;
};
/*
* OPEN: Open a file, potentially receiving an open delegation
*/
struct OPEN4args {
seqid4 seqid;
uint32_t share_access;
uint32_t share_deny;
open_owner4 owner;
openflag4 openhow;
open_claim4 claim;
};
struct open_read_delegation4 {
stateid4 stateid; /* Stateid for delegation */
bool recall; /* Pre-recalled flag for
delegations obtained
by reclaim (CLAIM_PREVIOUS) */
struct open_read_delegation4 {
stateid4 stateid; /* Stateid for delegation */
bool recall; /* Pre-recalled flag for
delegations obtained
by reclaim (CLAIM_PREVIOUS) */
nfsace4 permissions; /* Defines users who don't
need an ACCESS call to
open for read */
};
nfsace4 permissions; /* Defines users who don't
need an ACCESS call to
open for read */
};
struct open_write_delegation4 {
stateid4 stateid; /* Stateid for delegation */
bool recall; /* Pre-recalled flag for
delegations obtained
by reclaim
(CLAIM_PREVIOUS) */
struct open_write_delegation4 {
stateid4 stateid; /* Stateid for delegation */
bool recall; /* Pre-recalled flag for
delegations obtained
by reclaim
(CLAIM_PREVIOUS) */
nfs_space_limit4
space_limit; /* Defines condition that
the client must check to
determine whether the
file needs to be flushed
to the server on close */
nfs_space_limit4
space_limit; /* Defines condition that
the client must check to
determine whether the
file needs to be flushed
to the server on close */
nfsace4 permissions; /* Defines users who don't
need an ACCESS call as
part of a delegated
open */
};
nfsace4 permissions; /* Defines users who don't
need an ACCESS call as
part of a delegated
open */
};
union open_delegation4 switch
(open_delegation_type4 delegation_type) {
case OPEN_DELEGATE_NONE:
void;
case OPEN_DELEGATE_READ:
open_read_delegation4 read;
case OPEN_DELEGATE_WRITE:
open_write_delegation4 write;
};
union open_delegation4 switch
(open_delegation_type4 delegation_type) {
case OPEN_DELEGATE_NONE:
void;
case OPEN_DELEGATE_READ:
open_read_delegation4 read;
case OPEN_DELEGATE_WRITE:
open_write_delegation4 write;
};
/*
* Result flags
*/
/*
* Result flags
*/
/* Client must confirm open */
const OPEN4_RESULT_CONFIRM = 0x00000002;
/* Type of file locking behavior at the server */
const OPEN4_RESULT_LOCKTYPE_POSIX = 0x00000004;
/* Client must confirm open */
const OPEN4_RESULT_CONFIRM = 0x00000002;
/* Type of file locking behavior at the server */
const OPEN4_RESULT_LOCKTYPE_POSIX = 0x00000004;
struct OPEN4resok {
stateid4 stateid; /* Stateid for open */
change_info4 cinfo; /* Directory change info */
uint32_t rflags; /* Result flags */
bitmap4 attrset; /* attribute set for create */
open_delegation4 delegation; /* Info on any open
delegation */
};
struct OPEN4resok {
stateid4 stateid; /* Stateid for open */
change_info4 cinfo; /* Directory change info */
uint32_t rflags; /* Result flags */
bitmap4 attrset; /* attribute set for create */
open_delegation4 delegation; /* Info on any open
delegation */
};
union OPEN4res switch (nfsstat4 status) {
case NFS4_OK:
/* CURRENT_FH: opened file */
OPEN4resok resok4;
default:
void;
};
union OPEN4res switch (nfsstat4 status) {
case NFS4_OK:
/* CURRENT_FH: opened file */
OPEN4resok resok4;
default:
void;
};
OPEN resembles LOOKUP in that it generates a filehandle for the client to use. Unlike LOOKUP, though, OPEN creates server state on the filehandle. In normal circumstances, the client can only release this state with a CLOSE operation. CLOSE uses the current filehandle to determine which file to close. Therefore, the client MUST follow every OPEN operation with a GETFH operation in the same COMPOUND procedure. This will supply the client with the filehandle such that CLOSE can be used appropriately.
OpenLookup类似于查找，它生成供客户端使用的文件句柄。不过，与查找不同，OPEN在文件句柄上创建服务器状态。在正常情况下，客户端只能通过关闭操作释放此状态。CLOSE使用当前文件句柄确定要关闭的文件。因此，客户机必须在同一复合过程中使用GETFH操作来跟踪每个打开的操作。这将为客户端提供文件句柄，以便可以适当地使用CLOSE。
Simply waiting for the lease on the file to expire is insufficient because the server may maintain the state indefinitely as long as another client does not attempt to make a conflicting access to the same file.
仅仅等待文件租约到期是不够的，因为只要另一个客户端不尝试对同一文件进行冲突访问，服务器就可以无限期地保持该状态。
The OPEN operation creates and/or opens a regular file in a directory with the provided name. If the file does not exist at the server and creation is desired, specification of the method of creation is provided by the openhow parameter. The client has the choice of three creation methods: UNCHECKED4, GUARDED4, or EXCLUSIVE4.
“打开”操作使用提供的名称在目录中创建和/或打开常规文件。如果该文件在服务器上不存在并且需要创建，则openhow参数将提供创建方法的规范。客户可以选择三种创建方法：UNCHECKED4、GUARDED4或EXCLUSIVE4。
If the current filehandle is a named attribute directory, OPEN will then create or open a named attribute file. Note that exclusive create of a named attribute is not supported. If the createmode is EXCLUSIVE4 and the current filehandle is a named attribute directory, the server will return EINVAL.
如果当前文件句柄是命名属性目录，则OPEN将创建或打开命名属性文件。请注意，不支持以独占方式创建命名属性。如果createmode是EXCLUSIVE4且当前文件句柄是命名属性目录，则服务器将返回EINVAL。
UNCHECKED4 means that the file should be created if a file of that name does not exist and encountering an existing regular file of that name is not an error. For this type of create, createattrs specifies the initial set of attributes for the file. The set of attributes may include any writable attribute valid for regular files. When an UNCHECKED4 create encounters an existing file, the attributes specified by createattrs are not used, except that when a size of zero is specified, the existing file is truncated. If GUARDED4 is specified, the server checks for the presence of a duplicate object by name before performing the create. If a duplicate exists, an error of NFS4ERR_EXIST is returned as the status. If the object does not exist, the request is performed as described for UNCHECKED4. For each of these cases (UNCHECKED4 and GUARDED4), where the operation is successful, the server will return to the client an attribute mask signifying which attributes were successfully set for the object.
UNCHECKED4表示如果该名称的文件不存在，并且遇到该名称的现有常规文件不是错误，则应创建该文件。对于这种类型的创建，createattrs指定文件的初始属性集。属性集可以包括对常规文件有效的任何可写属性。当未选中的4 create遇到现有文件时，将不使用createattrs指定的属性，除非指定了零大小，否则现有文件将被截断。如果指定了GUARDED4，服务器将在执行创建之前按名称检查是否存在重复的对象。如果存在重复项，则返回NFS4ERR_EXIST错误作为状态。如果对象不存在，则按照UNCHECKED4所述执行请求。对于这些情况中的每一种（UNCHECKED4和GUARDED4），如果操作成功，服务器将向客户端返回一个属性掩码，表示为对象成功设置了哪些属性。
EXCLUSIVE4 specifies that the server is to follow exclusive creation semantics, using the verifier to ensure exclusive creation of the target. The server should check for the presence of a duplicate object by name. If the object does not exist, the server creates the object and stores the verifier with the object. If the object does exist and the stored verifier matches the verifier provided by the client, the server uses the existing object as the newly created object. If the stored verifier does not match, then an error of NFS4ERR_EXIST is returned. No attributes may be provided in this case, since the server may use an attribute of the target object to store the verifier. If the server uses an attribute to store the exclusive create verifier, it will signify which attribute was used by setting the appropriate bit in the attribute mask that is returned in the results.
EXCLUSIVE4指定服务器遵循独占创建语义，使用验证器确保以独占方式创建目标。服务器应按名称检查是否存在重复的对象。如果对象不存在，服务器将创建该对象并将验证器与该对象一起存储。如果对象确实存在并且存储的验证器与客户端提供的验证器匹配，则服务器将使用现有对象作为新创建的对象。如果存储的验证器不匹配，则返回NFS4ERR_EXIST错误。在这种情况下不能提供属性，因为服务器可以使用目标对象的属性来存储验证器。如果服务器使用一个属性来存储独占创建验证器，它将通过在结果中返回的属性掩码中设置适当的位来指示使用了哪个属性。
For the target directory, the server returns change_info4 information in cinfo. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the link creation.
对于目标目录，服务器返回cinfo中的change_info4信息。使用change_info4结构的原子字段，服务器将指示是否以原子方式获得了与链接创建相关的更改前后属性。
Upon successful creation, the current filehandle is replaced by that of the new object.
成功创建后，当前文件句柄将替换为新对象的文件句柄。
The OPEN operation provides for Windows share reservation capability with the use of the share_access and share_deny fields of the OPEN arguments. The client specifies at OPEN the required share_access
“打开”操作使用打开参数的“共享访问”和“共享拒绝”字段提供Windows共享保留功能。客户端在打开时指定所需的共享访问权限
and share_deny modes. For clients that do not directly support SHAREs (i.e., UNIX), the expected deny value is DENY_NONE. In the case that there is an existing share reservation that conflicts with the OPEN request, the server returns the error NFS4ERR_SHARE_DENIED. For a complete SHARE request, the client must provide values for the owner and seqid fields for the OPEN argument. For additional discussion of share semantics, see Section 9.9.
共享和拒绝模式。对于不直接支持共享（即UNIX）的客户端，预期的拒绝值为deny_NONE。如果存在与打开请求冲突的现有共享保留，服务器将返回错误NFS4ERR_share_DENIED。对于完整的共享请求，客户端必须为OPEN参数提供owner和seqid字段的值。有关共享语义的更多讨论，请参见第9.9节。
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 the request is meant to reclaim state previously held.
在客户机正在从服务器故障恢复状态的情况下，OPEN参数的claim字段用于表示该请求旨在恢复先前持有的状态。
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 possess. There are four basic claim types that cover the various situations for an OPEN. They are as follows:
OPEN参数的claim字段用于指定要打开的文件以及客户端声称拥有的状态信息。有四种基本索赔类型，涵盖开放式索赔的各种情况。详情如下:
CLAIM_NULL: For the client, this is a new OPEN request, and there is no previous state associated with the file for the client.
CLAIM_NULL：对于客户端，这是一个新的打开请求，并且没有与客户端文件关联的先前状态。
CLAIM_PREVIOUS: The client is claiming basic OPEN state for a file that was held previous to a server reboot. This is generally used when a server is returning persistent filehandles; the client may not have the filename to reclaim the OPEN.
CLAIM_PREVIOUS：客户端正在声明在服务器重新启动之前保留的文件的基本打开状态。这通常在服务器返回持久文件句柄时使用；客户端可能没有文件名来回收打开的文件。
CLAIM_DELEGATE_CUR: The client is claiming a delegation for OPEN as granted by the server. This is generally done as part of recalling a delegation.
CLAIM_DELEGATE_CUR：客户机正在请求服务器授予的开放委托。这通常是作为召回代表团的一部分进行的。
CLAIM_DELEGATE_PREV: The client is claiming a delegation granted to a previous client instance. This claim type is for use after a SETCLIENTID_CONFIRM and before the corresponding DELEGPURGE in two situations: after a client reboot and after a lease expiration that resulted in loss of all lock state. The server MAY support CLAIM_DELEGATE_PREV. If it does support CLAIM_DELEGATE_PREV, SETCLIENTID_CONFIRM MUST NOT remove the client's delegation state, and the server MUST support the DELEGPURGE operation.
CLAIM_DELEGATE_PREV：客户端正在声明授予前一个客户端实例的委托。此声明类型在SETCLIENTID_确认之后和相应的DELEGPURGE之前用于两种情况：客户端重新启动之后和导致所有锁状态丢失的租约到期之后。服务器可能支持CLAIM_DELEGATE_PREV。如果它确实支持CLAIM_DELEGATE_PREV，则SETCLIENTID_CONFIRM不能删除客户端的委派状态，并且服务器必须支持DELEGPURGE操作。
The following errors apply to use of the CLAIM_DELEGATE_PREV claim type:
以下错误适用于使用CLAIM_DELEGATE_PREV索赔类型：
o NFS4ERR_NOTSUPP is returned if the server does not support this claim type.
o 如果服务器不支持此声明类型，则返回NFS4ERR_NOTSUPP。
o NFS4ERR_INVAL is returned if the reclaim is done at an inappropriate time, e.g., after DELEGPURGE has been done.
o 如果回收是在不适当的时间完成的，例如，在完成DELEGPURCE之后，则返回NFS4ERR_INVAL。
o NFS4ERR_BAD_RECLAIM is returned if the other error conditions do not apply and the server has no record of the delegation whose reclaim is being attempted.
o 如果其他错误条件不适用，并且服务器没有尝试回收的委派的记录，则返回NFS4ERR\u BAD\u回收。
For OPEN requests whose claim type is other than CLAIM_PREVIOUS (i.e., requests other than those devoted to reclaiming opens after a server reboot) that reach the server during its grace or lease expiration period, the server returns an error of NFS4ERR_GRACE.
对于声明类型不是claim_PREVIOUS的打开请求（即，服务器重新启动后用于回收打开的请求除外），在宽限期或租约到期期间到达服务器，服务器返回NFS4ERR_宽限期错误。
For any OPEN request, the server may return an open delegation, which 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 server to decide. The client should never assume that delegation will or will not be granted in a particular instance. It should always be prepared for either case. A partial exception is the reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed. In this case, delegation will always be granted, although the server may specify an immediate recall in the delegation structure.
对于任何打开的请求，服务器可能返回一个打开的委托，这允许进一步的打开和关闭在客户端本地处理，如第10.4节所述。请注意，委派由服务器决定。客户不应假设在特定实例中会或不会授予委托。无论是哪种情况，都应该随时做好准备。部分例外情况是Reclain（CLAIM_PREVIOUS）案例，在该案例中声明了委托类型。在这种情况下，将始终授予委派，尽管服务器可以在委派结构中指定立即调用。
The rflags returned by a successful OPEN allow the server to return information governing how the open file is to be handled.
成功打开所返回的RFLAG允许服务器返回控制如何处理打开的文件的信息。
OPEN4_RESULT_CONFIRM indicates that the client MUST execute an OPEN_CONFIRM operation before using the open file. OPEN4_RESULT_LOCKTYPE_POSIX indicates that the server's file locking behavior supports the complete set of POSIX locking techniques [fcntl]. From this, the client can choose to manage file locking state in such a way as to handle a mismatch of file locking management.
OPEN4_RESULT_CONFIRM表示客户端在使用打开的文件之前必须执行打开确认操作。OPEN4_RESULT_LOCKTYPE_POSIX表示服务器的文件锁定行为支持整套POSIX锁定技术[fcntl]。由此，客户机可以选择以处理文件锁定管理不匹配的方式来管理文件锁定状态。
If the component is of zero length, NFS4ERR_INVAL will be returned. The component is also subject to the normal UTF-8, character support, and name checks. See Section 12.7 for further discussion.
如果组件长度为零，将返回NFS4ERR_INVAL。该组件还需要进行常规UTF-8、字符支持和名称检查。进一步讨论见第12.7节。
When an OPEN is done and the specified open-owner already has the resulting filehandle open, the result is to "OR" together the new share and deny status, together with the existing status. In this case, only a single CLOSE need be done, even though multiple OPENs were completed. When such an OPEN is done, checking of share reservations for the new OPEN proceeds normally, with no exception for the existing OPEN held by the same owner. In this case, the stateid returned has an "other" field that matches that of the previous open, while the seqid field is incremented to reflect the changed status due to the new open (Section 9.1.4).
当打开操作完成且指定的打开所有者已打开结果文件句柄时，结果是将新共享和拒绝状态与现有状态一起“或”。在这种情况下，即使多个打开已完成，也只需完成一次关闭。当此类公开交易完成后，对新公开交易的股份保留的检查将正常进行，同一所有者持有的现有公开交易也不例外。在这种情况下，返回的stateid有一个“other”字段，该字段与先前打开的字段相匹配，而seqid字段则递增，以反映由于新打开而改变的状态（第9.1.4节）。
If the underlying file system at the server is only accessible in a read-only mode and the OPEN request has specified OPEN4_SHARE_ACCESS_WRITE or OPEN4_SHARE_ACCESS_BOTH, the server will return NFS4ERR_ROFS to indicate a read-only file system.
如果服务器上的底层文件系统只能以只读模式访问，并且OPEN请求指定了OPEN4_SHARE_ACCESS_WRITE或OPEN4_SHARE_ACCESS_，则服务器将返回NFS4ERR_ROFS以指示只读文件系统。
As with the CREATE operation, the server MUST derive the owner, owner ACE, group, or group ACE if any of the four attributes are required and supported by the server's file system. For an OPEN with the EXCLUSIVE4 createmode, the server has no choice, since such OPEN calls do not include the createattrs field. Conversely, if createattrs is specified and includes owner or group (or corresponding ACEs) that the principal in the RPC's credentials does not have authorization to create files for, then the server may return NFS4ERR_PERM.
与创建操作一样，如果服务器的文件系统需要并支持这四个属性中的任何一个，则服务器必须派生所有者、所有者ACE、组或组ACE。对于具有EXCLUSIVE4 createmode的OPEN，服务器没有选择，因为此类OPEN调用不包括createattrs字段。相反，如果指定了createattrs，并且包含RPC凭据中的主体无权为其创建文件的所有者或组（或相应的ACE），则服务器可能会返回NFS4ERR_PERM。
In the case where an OPEN specifies a size of zero (e.g., truncation) and the file has named attributes, the named attributes are left as is. They are not removed.
如果OPEN指定大小为零（例如截断），并且文件具有命名属性，则命名属性保持原样。它们没有被移除。
The OPEN operation contains support for EXCLUSIVE4 create. The mechanism is similar to the support in NFSv3 [RFC1813]. As in NFSv3, this mechanism provides reliable exclusive creation. Exclusive create is invoked when the how parameter is EXCLUSIVE4. In this case, the client provides a verifier that can reasonably be expected to be unique. A combination of a client identifier, perhaps the client network address, and a unique number generated by the client, perhaps the RPC transaction identifier, may be appropriate.
OPEN操作包含对EXCLUSIVE4 create的支持。该机制类似于NFSv3[RFC1813]中的支持。与NFSv3一样，此机制提供可靠的独占创建。当how参数为EXCLUSIVE4时，将调用exclusivecreate。在这种情况下，客户机提供了一个可以合理预期是唯一的验证器。客户端标识符（可能是客户端网络地址）和由客户端生成的唯一号码（可能是RPC事务标识符）的组合可能是合适的。
If the object does not exist, the server creates the object and stores the verifier in stable storage. For file systems that do not provide a mechanism for the storage of arbitrary file attributes, the server may use one or more elements of the object metadata to store the verifier. The verifier must be stored in stable storage to prevent erroneous failure on retransmission of the request. It is assumed that an exclusive create is being performed because exclusive semantics are critical to the application. Because of the expected usage, exclusive create does not rely solely on the normally volatile duplicate request cache for storage of the verifier. The duplicate request cache in volatile storage does not survive a crash and may actually flush on a long network partition, opening failure windows. In the UNIX local file system environment, the expected storage location for the verifier on creation is the metadata (timestamps) of the object. For this reason, an exclusive object create may not include initial attributes because the server would have nowhere to store the verifier.
如果对象不存在，服务器将创建该对象并将验证器存储在稳定的存储器中。对于不提供用于存储任意文件属性的机制的文件系统，服务器可以使用对象元数据的一个或多个元素来存储验证器。验证器必须存储在稳定的存储器中，以防止请求重新传输时出现错误故障。假定正在执行独占创建，因为独占语义对应用程序至关重要。由于预期用途，exclusive create不完全依赖通常易失性的复制请求缓存来存储验证器。易失性存储中的重复请求缓存在崩溃后无法生存，可能会在长网络分区上刷新，从而打开故障窗口。在UNIX本地文件系统环境中，创建时验证器的预期存储位置是对象的元数据（时间戳）。因此，独占对象创建可能不包括初始属性，因为服务器将无处存储验证器。
If the server cannot support these exclusive create semantics, possibly because of the requirement to commit the verifier to stable storage, it should fail the OPEN request with the error NFS4ERR_NOTSUPP.
如果服务器无法支持这些独占创建语义，可能是因为需要将验证器提交到稳定存储，那么它应该会导致打开请求失败，错误为NFS4ERR_NOTSUPP。
During an exclusive CREATE request, if the object already exists, the server reconstructs the object's verifier and compares it with 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 an earlier, successful request for which the reply was lost and that the server duplicate request cache mechanism did not detect. If the verifiers do not match, the request is rejected with the status NFS4ERR_EXIST.
在独占创建请求期间，如果对象已经存在，服务器将重建对象的验证器，并将其与请求中的验证器进行比较。如果它们匹配，服务器会将请求视为成功。该请求被假定为先前成功请求的副本，该请求的答复已丢失，并且服务器重复请求缓存机制未检测到该请求。如果验证器不匹配，请求将被拒绝，状态为NFS4ERR_EXIST。
Once the client has performed a successful exclusive create, it must issue a SETATTR to set the correct object attributes. Until it does so, it should not rely upon any of the object attributes, since the server implementation may need to overload object metadata to store the verifier. The subsequent SETATTR must not occur in the same COMPOUND request as the OPEN. This separation will guarantee that the exclusive create mechanism will continue to function properly in the face of retransmission of the request.
客户机成功执行独占创建后，必须发出SETATTR以设置正确的对象属性。在此之前，它不应该依赖任何对象属性，因为服务器实现可能需要重载对象元数据来存储验证器。后续SETATTR不能与OPEN在同一复合请求中发生。这种分离将保证独占创建机制在重新传输请求时继续正常工作。
Use of the GUARDED4 attribute does not provide "exactly-once" semantics. In particular, if a reply is lost and the server does not detect the retransmission of the request, the operation can fail with NFS4ERR_EXIST, even though the create was performed successfully. The client would use this behavior in the case that the application has not requested an exclusive create but has asked to have the file truncated when the file is opened. In the case of the client timing out and retransmitting the create request, the client can use GUARDED4 to prevent a sequence such as create, write, create (retransmitted) from occurring.
GUARDED4属性的使用不提供“恰好一次”语义。特别是，如果应答丢失且服务器未检测到请求的重新传输，则即使创建已成功执行，操作也可能因NFS4ERR_存在而失败。如果应用程序未请求独占创建，但在打开文件时请求截断文件，则客户端将使用此行为。在客户端超时并重新传输创建请求的情况下，客户端可以使用GUARDED4来防止诸如创建、写入、创建（重新传输）之类的序列发生。
For share reservations (see Section 9.9), the client must specify a value for share_access that is one of OPEN4_SHARE_ACCESS_READ, OPEN4_SHARE_ACCESS_WRITE, or OPEN4_SHARE_ACCESS_BOTH. For share_deny, the client must specify one of OPEN4_SHARE_DENY_NONE, OPEN4_SHARE_DENY_READ, OPEN4_SHARE_DENY_WRITE, or OPEN4_SHARE_DENY_BOTH. If the client fails to do this, the server must return NFS4ERR_INVAL.
对于共享保留（请参见第9.9节），客户端必须为共享访问指定一个值，该值为OPEN4共享访问访问访问读、OPEN4共享访问访问访问写或OPEN4共享访问访问读和写。对于share_deny，客户端必须指定OPEN4_share_deny_NONE、OPEN4_share_deny_READ、OPEN4_share_deny_WRITE或OPEN4_share_deny_两者中的一个。如果客户端无法执行此操作，服务器必须返回NFS4ERR_INVAL。
Based on the share_access value (OPEN4_SHARE_ACCESS_READ, OPEN4_SHARE_ACCESS_WRITE, or OPEN4_SHARE_ACCESS_BOTH), the client should check that the requester has the proper access rights to perform the specified operation. This would generally be the results of applying the ACL access rules to the file for the current requester. However, just as with the ACCESS operation, the client
根据share\u访问值（OPEN4\u share\u access\u READ、OPEN4\u share\u access\u WRITE或OPEN4\u share\u access\u两者），客户端应检查请求者是否具有执行指定操作的正确访问权限。这通常是对当前请求者的文件应用ACL访问规则的结果。但是，与访问操作一样，客户端
should not attempt to second-guess the server's decisions, as access rights may change and may be subject to server administrative controls outside the ACL framework. If the requester is not authorized to READ or WRITE (depending on the share_access value), the server must return NFS4ERR_ACCESS. Note that since the NFSv4 protocol does not impose any requirement that READs and WRITEs issued for an open file have the same credentials as the OPEN itself, the server still must do appropriate access checking on the READs and WRITEs themselves.
不应试图猜测服务器的决定，因为访问权限可能会更改，并且可能受ACL框架之外的服务器管理控制。如果请求者未被授权读取或写入（取决于share_访问值），服务器必须返回NFS4ERR_访问。请注意，由于NFSv4协议没有强制要求为打开的文件发出的读写操作与打开的文件本身具有相同的凭据，因此服务器仍然必须对读写操作本身进行适当的访问检查。
If the component provided to OPEN resolves to something other than a regular file (or a named attribute), an error will be returned to the client. If it is a directory, NFS4ERR_ISDIR is returned; otherwise, NFS4ERR_SYMLINK is returned. Note that NFS4ERR_SYMLINK is returned for both symlinks and for special files of other types; NFS4ERR_INVAL would be inappropriate, since the arguments provided by the client were correct, and the client cannot necessarily know at the time it sent the OPEN that the component would resolve to a non-regular file.
如果提供用于打开的组件解析为常规文件（或命名属性）以外的内容，则会向客户端返回错误。如果是目录，则返回NFS4ERR_ISDIR；否则，将返回NFS4ERR_符号链接。注意，对于符号链接和其他类型的特殊文件，都会返回NFS4ERR_符号链接；NFS4ERR_INVAL是不合适的，因为客户端提供的参数是正确的，并且客户端在发送OPEN时不一定知道组件将解析为非常规文件。
If the current filehandle is not a directory, the error NFS4ERR_NOTDIR will be returned.
如果当前文件句柄不是目录，将返回错误NFS4ERR_NOTDIR。
If a COMPOUND contains an OPEN that establishes an OPEN_DELEGATE_WRITE delegation, then subsequent GETATTRs normally result in a CB_GETATTR being sent to the client holding the delegation. However, in the case in which the OPEN and GETATTR are part of the same COMPOUND, the server SHOULD understand that the operations are for the same client ID and avoid querying the client, which will not be able to respond. This sequence of OPEN and GETATTR SHOULD be understood to be the retrieval of the size and change attributes at the time of OPEN. Further, as explained in Section 15.2.5, the client should not construct a COMPOUND that mixes operations for different client IDs.
如果化合物包含建立OPEN_DELEGATE_WRITE委派的OPEN，则后续GETATTR通常会导致将CB_GETATTR发送给持有委派的客户端。但是，如果OPEN和GETATTR是同一化合物的一部分，服务器应该理解这些操作是针对相同的客户机ID的，并且避免查询无法响应的客户机。OPEN和GETATTR的顺序应理解为在打开时检索size和change属性。此外，如第15.2.5节所述，客户不应构建混合不同客户ID操作的化合物。
(cfh) createdir -> (cfh)
（cfh）createdir->（cfh）
struct OPENATTR4args {
/* CURRENT_FH: object */
bool createdir;
};
struct OPENATTR4args {
/* CURRENT_FH: object */
bool createdir;
};
struct OPENATTR4res {
/* CURRENT_FH: named attr directory */
nfsstat4 status;
};
struct OPENATTR4res {
/* CURRENT_FH: named attr directory */
nfsstat4 status;
};
The OPENATTR operation is used to obtain the filehandle of the named attribute directory associated with the current filehandle. The result of the OPENATTR will be a filehandle to an object of type NF4ATTRDIR. From this filehandle, READDIR and LOOKUP operations can be used to obtain filehandles for the various named attributes associated with the original file system object. Filehandles returned within the named attribute directory will have a type of NF4NAMEDATTR.
OPENATTR操作用于获取与当前文件句柄关联的命名属性目录的文件句柄。OPENATTR的结果将是NF4ATTRDIR类型对象的文件句柄。通过该文件句柄，可以使用READDIR和LOOKUP操作获取与原始文件系统对象关联的各种命名属性的文件句柄。在命名属性目录中返回的文件句柄的类型为NF4NAMEDATTR。
The createdir argument allows the client to signify if a named attribute directory should be created as a result of the OPENATTR operation. Some clients may use the OPENATTR operation with a value of FALSE for createdir to determine if any named attributes exist for the object. If none exist, then NFS4ERR_NOENT will be returned. If createdir has a value of TRUE and no named attribute directory exists, one is created. The creation of a named attribute directory assumes that the server has implemented named attribute support in this fashion and is not required to do so by this definition.
createdir参数允许客户端指示是否应作为OPENATTR操作的结果创建命名属性目录。某些客户端可能会使用OPENATTR操作（createdir的值为FALSE）来确定对象是否存在任何命名属性。如果不存在，则将返回NFS4ERR\u NOENT。如果createdir的值为TRUE，并且不存在命名属性目录，则会创建一个。命名属性目录的创建假定服务器以这种方式实现了命名属性支持，并且此定义不要求这样做。
If the server does not support named attributes for the current filehandle, an error of NFS4ERR_NOTSUPP will be returned to the client.
如果服务器不支持当前文件句柄的命名属性，则会向客户端返回NFS4ERR_NOTSUPP错误。
(cfh), seqid, stateid -> stateid
（cfh），seqid，stateid->stateid
struct OPEN_CONFIRM4args {
/* CURRENT_FH: opened file */
stateid4 open_stateid;
seqid4 seqid;
};
struct OPEN_CONFIRM4args {
/* CURRENT_FH: opened file */
stateid4 open_stateid;
seqid4 seqid;
};
struct OPEN_CONFIRM4resok {
stateid4 open_stateid;
};
struct OPEN_CONFIRM4resok {
stateid4 open_stateid;
};
union OPEN_CONFIRM4res switch (nfsstat4 status) {
case NFS4_OK:
OPEN_CONFIRM4resok resok4;
default:
void;
};
union OPEN_CONFIRM4res switch (nfsstat4 status) {
case NFS4_OK:
OPEN_CONFIRM4resok resok4;
default:
void;
};
This operation is used to confirm the sequence id usage for the first time that an open-owner is used by a client. The stateid returned from the OPEN operation is used as the argument for this operation along with the next sequence id for the open-owner. The sequence id passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid passed to the OPEN operation (Section 9.1.4). If the server receives an unexpected sequence id with respect to the original OPEN, then the server assumes that the client will not confirm the original OPEN and all state associated with the original OPEN is released by the server.
此操作用于确认客户端首次使用开放所有者时序列id的使用情况。从打开操作返回的stateid与打开所有者的下一个序列id一起用作此操作的参数。传递给打开确认的序列id必须比传递给打开操作的序列id大1（一）（第9.1.4节）。如果服务器收到与原始打开相关的意外序列id，则服务器假定客户端不会确认原始打开，并且与原始打开相关的所有状态都由服务器释放。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
A given client might generate many open_owner4 data structures for a given client ID. The client will periodically either dispose of its open_owner4s or stop using them for indefinite periods of time. The latter situation is why the NFSv4 protocol does not have an explicit
给定的客户机可能会为给定的客户机ID生成许多open_owner4数据结构。该客户机将定期处理其open_owner4或无限期停止使用这些数据结构。后一种情况是NFSv4协议没有明确定义的原因
operation to exit an open_owner4: such an operation is of no use in that situation. Instead, to avoid unbounded memory use, the server needs to implement a strategy for disposing of open_owner4s that have no current open state for any files and have not been used recently. The time period used to determine when to dispose of open_owner4s is an implementation choice. The time period should certainly be no less than the lease time plus any grace period the server wishes to implement beyond a lease time. The OPEN_CONFIRM operation allows the server to safely dispose of unused open_owner4 data structures.
退出开放所有者的操作4：这种操作在这种情况下没有用处。相反，为了避免无限制的内存使用，服务器需要实施一种策略来处理当前没有任何文件打开状态且最近没有使用过的打开所有者。用于确定何时处置open_owner4s的时间段是一种实现选择。时间段当然应该不小于租赁时间加上服务器希望在租赁时间之后实施的任何宽限期。OPEN_CONFIRM操作允许服务器安全地处置未使用的OPEN_owner4数据结构。
In the case that a client issues an OPEN operation and the server no longer has a record of the open_owner4, the server needs to ensure that this is a new OPEN and not a replay or retransmission.
如果客户端发出开放操作，而服务器不再具有开放所有者的记录4，服务器需要确保这是一个新的开放操作，而不是重播或重新传输。
Servers MUST NOT require confirmation on OPENs that grant delegations or are doing reclaim operations. See Section 9.1.11 for details. The server can easily avoid this by noting whether it has disposed of one open_owner4 for the given client ID. If the server does not support delegation, it might simply maintain a single bit that notes whether any open_owner4 (for any client) has been disposed of.
服务器不得要求对授予委派或正在执行回收操作的打开进行确认。详见第9.1.11节。服务器可以通过注意是否已为给定的客户端ID处置了一个open_owner4来轻松避免这种情况。如果服务器不支持委派，它可能只需保留一个位来记录是否已处置了任何open_owner4（对于任何客户端）。
The server must hold unconfirmed OPEN state until one of three events occurs. First, the client sends an OPEN_CONFIRM request with the appropriate sequence id and stateid within the lease period. In this case, the OPEN state on the server goes to confirmed, and the open_owner4 on the server is fully established.
服务器必须保持未确认的打开状态，直到发生三个事件之一。首先，客户机在租赁期内发送具有适当序列id和stateid的OPEN_CONFIRM请求。在这种情况下，服务器上的打开状态变为已确认，服务器上的打开所有者4已完全建立。
Second, the client sends another OPEN request with a sequence id that is incorrect for the open_owner4 (out of sequence). In this case, the server assumes the second OPEN request is valid and the first one is a replay. The server cancels the OPEN state of the first OPEN request, establishes an unconfirmed OPEN state for the second OPEN request, and responds to the second OPEN request with an indication that an OPEN_CONFIRM is needed. The process then repeats itself. While there is a potential for a denial-of-service attack on the client, it is mitigated if the client and server require the use of a security flavor based on Kerberos V5 or some other flavor that uses cryptography.
其次，客户端发送另一个OPEN请求，其序列id对于OPEN_owner4不正确（顺序错误）。在这种情况下，服务器假定第二个打开请求有效，第一个是重播。服务器取消第一个打开请求的打开状态，为第二个打开请求建立未确认的打开状态，并响应第二个打开请求，指示需要打开确认。然后这个过程会重复。虽然客户机上存在拒绝服务攻击的可能性，但如果客户机和服务器需要使用基于Kerberos V5的安全版本或使用加密技术的其他版本，则可以减轻这种攻击。
What if the server is in the unconfirmed OPEN state for a given open_owner4, and it receives an operation on the open_owner4 that has a stateid but the operation is not OPEN, or it is OPEN_CONFIRM but with the wrong stateid? Then, even if the seqid is correct, the server returns NFS4ERR_BAD_STATEID, because the server assumes the operation is a replay: if the server has no established OPEN state, then there is no way, for example, a LOCK operation could be valid.
如果服务器对于给定的OPEN_owner4处于未确认的OPEN状态，并且它在OPEN_owner4上接收到具有stateid但操作未打开的操作，或者服务器处于OPEN_CONFIRM状态但具有错误的stateid，该怎么办？然后，即使seqid是正确的，服务器也会返回NFS4ERR_BAD_STATEID，因为服务器假定该操作是一个重播：如果服务器没有建立的打开状态，那么就没有办法，例如，锁定操作可能是有效的。
Third, neither of the two aforementioned events occurs for the open_owner4 within the lease period. In this case, the OPEN state is canceled and disposal of the open_owner4 can occur.
第三，上述两个事件均未在租赁期内发生。在这种情况下，打开状态被取消，并且可以处理打开的所有者4。
(cfh), stateid, seqid, access, deny -> stateid
（cfh），stateid，seqid，访问，拒绝->stateid
struct OPEN_DOWNGRADE4args {
/* CURRENT_FH: opened file */
stateid4 open_stateid;
seqid4 seqid;
uint32_t share_access;
uint32_t share_deny;
};
struct OPEN_DOWNGRADE4args {
/* CURRENT_FH: opened file */
stateid4 open_stateid;
seqid4 seqid;
uint32_t share_access;
uint32_t share_deny;
};
struct OPEN_DOWNGRADE4resok {
stateid4 open_stateid;
};
struct OPEN_DOWNGRADE4resok {
stateid4 open_stateid;
};
union OPEN_DOWNGRADE4res switch (nfsstat4 status) {
case NFS4_OK:
OPEN_DOWNGRADE4resok resok4;
default:
void;
};
union OPEN_DOWNGRADE4res switch (nfsstat4 status) {
case NFS4_OK:
OPEN_DOWNGRADE4resok resok4;
default:
void;
};
This operation is used to adjust the share_access and share_deny bits for a given open. This is necessary when a given open-owner opens the same file multiple times with different share_access and share_deny flags. In this situation, a close of one of the opens may change the appropriate share_access and share_deny flags to remove bits associated with opens no longer in effect.
此操作用于调整给定open的share_访问和share_拒绝位。当给定的打开所有者使用不同的共享访问和共享拒绝标志多次打开同一文件时，这是必需的。在这种情况下，关闭一个打开可能会更改相应的share_access和share_deny标志，以删除与不再有效的打开相关的位。
The share_access and share_deny bits specified in this operation replace the current ones for the specified open file. The share_access and share_deny bits specified must be exactly equal to the union of the share_access and share_deny bits specified for some subset of the OPENs in effect for the current open-owner on the current file. If that constraint is not respected, the error NFS4ERR_INVAL should be returned. Since share_access and share_deny bits are subsets of those already granted, it is not possible for this request to be denied because of conflicting share reservations.
此操作中指定的共享访问和共享拒绝位将替换指定打开文件的当前位。指定的share_access和share_deny位必须完全等于为当前文件上当前打开所有者有效打开的某些子集指定的share_access和share_deny位的并集。如果不遵守该约束，则应返回错误NFS4ERR_INVAL。由于share_access和share_deny位是已授予的这些位的子集，因此不可能拒绝此请求，因为存在冲突的共享保留。
As the OPEN_DOWNGRADE may change a file to be not-open-for-write and a write byte-range lock might be held, the server may have to reject the OPEN_DOWNGRADE with an NFS4ERR_LOCKS_HELD.
由于OPEN_降级可能会将文件更改为未打开进行写入，并且可能会持有写入字节范围锁，因此服务器可能必须在持有NFS4ERR_锁的情况下拒绝OPEN_降级。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
filehandle -> (cfh)
文件句柄->（cfh）
struct PUTFH4args {
nfs_fh4 object;
};
struct PUTFH4args {
nfs_fh4 object;
};
struct PUTFH4res {
/* CURRENT_FH: */
nfsstat4 status;
};
struct PUTFH4res {
/* CURRENT_FH: */
nfsstat4 status;
};
PUTFH replaces the current filehandle with the filehandle provided as an argument.
PUTFH将当前文件句柄替换为作为参数提供的文件句柄。
If the security mechanism used by the requester does not meet the requirements of the filehandle provided to this operation, the server MUST return NFS4ERR_WRONGSEC.
如果请求者使用的安全机制不符合为此操作提供的filehandle的要求，则服务器必须返回NFS4ERR_-ErrorSec。
See Section 15.2.4.1 for more details on the current filehandle.
有关当前文件句柄的更多详细信息，请参见第15.2.4.1节。
PUTFH is commonly used as the first operator in an NFS request to set the context for operations that follow it.
PUTFH通常用作NFS请求中的第一个操作符，用于为随后的操作设置上下文。
- -> (cfh)
- ->（cfh）
void;
无效的
struct PUTPUBFH4res {
/* CURRENT_FH: public fh */
nfsstat4 status;
};
struct PUTPUBFH4res {
/* CURRENT_FH: public fh */
nfsstat4 status;
};
PUTPUBFH replaces the current filehandle with the filehandle that represents the public filehandle of the server's namespace. This filehandle may be different from the root filehandle, which may be associated with some other directory on the server.
PUTPUBFH将当前文件句柄替换为表示服务器命名空间的公共文件句柄的文件句柄。此文件句柄可能不同于根文件句柄，根文件句柄可能与服务器上的其他目录相关联。
The public filehandle concept was introduced in [RFC2054], [RFC2055], and [RFC2224]. The intent for NFSv4 is that the public filehandle (represented by the PUTPUBFH operation) be used as a method of providing compatibility with the WebNFS server of NFSv2 and NFSv3.
[RFC2054]、[RFC2055]和[RFC2224]中引入了公共文件句柄概念。NFSv4的目的是将公共文件句柄（由PUTPUBFH操作表示）用作提供与NFSv2和NFSv3的WebNFS服务器的兼容性的方法。
The public filehandle and the root filehandle (represented by the PUTROOTFH operation) should be equivalent. If the public and root filehandles are not equivalent, then the public filehandle MUST be a descendant of the root filehandle.
公共文件句柄和根文件句柄（由PUTROOTFH操作表示）应该是等效的。如果公共文件句柄和根文件句柄不相等，则公共文件句柄必须是根文件句柄的后代。
PUTPUBFH is used as the first operator in an NFS request to set the context for operations that follow it.
PUTPUBFH用作NFS请求中的第一个操作符，用于为随后的操作设置上下文。
With the NFSv2 and NFSv3 public filehandle, the client is able to specify whether the pathname provided in the LOOKUP should be evaluated as either an absolute path relative to the server's root or relative to the public filehandle. [RFC2224] contains further discussion of the functionality. With NFSv4, that type of specification is not directly available in the LOOKUP operation. The reason for this is because the component separators needed to specify absolute versus relative are not allowed in NFSv4. Therefore, the client is responsible for constructing its request such that either PUTROOTFH or PUTPUBFH is used to signify absolute or relative evaluation of an NFS URL, respectively.
使用NFSv2和NFSv3公共文件句柄，客户机可以指定是将查找中提供的路径名计算为相对于服务器根的绝对路径还是相对于公共文件句柄的绝对路径。[RFC2224]包含对功能的进一步讨论。对于NFSv4，该类型的规范在查找操作中不直接可用。这是因为NFSv4中不允许指定绝对与相对所需的组件分隔符。因此，客户机负责构造其请求，以便使用PUTROOTFH或PUTPUBFH分别表示NFS URL的绝对或相对评估。
Note that there are warnings mentioned in [RFC2224] with respect to the use of absolute evaluation and the restrictions the server may place on that evaluation with respect to how much of its namespace has been made available. These same warnings apply to NFSv4. It is likely, therefore, that because of server implementation details an NFSv3 absolute public filehandle lookup may behave differently than an NFSv4 absolute resolution.
请注意，[RFC2224]中提到了有关绝对求值的使用的警告，以及服务器可能对该求值施加的限制，这些限制涉及其名称空间的可用性。这些警告同样适用于NFSv4。因此，由于服务器实现的细节，NFSv3绝对公共文件句柄查找可能与NFSv4绝对解析的行为不同。
There is a form of security negotiation as described in [RFC2755] that uses the public filehandle as a method of employing the Simple and Protected GSS-API Negotiation Mechanism (SNEGO) [RFC4178]. This method is not available with NFSv4, as filehandles are not overloaded with special meaning and therefore do not provide the same framework as NFSv2 and NFSv3. Clients should therefore use the security negotiation mechanisms described in this RFC.
[RFC2755]中描述了一种形式的安全协商，它使用公共文件句柄作为采用简单且受保护的GSS-API协商机制（SNEGO）[RFC4178]的方法。此方法不适用于NFSv4，因为文件句柄没有特殊意义的重载，因此不提供与NFSv2和NFSv3相同的框架。因此，客户端应使用本RFC中描述的安全协商机制。
- -> (cfh)
- ->（cfh）
void;
无效的
struct PUTROOTFH4res {
/* CURRENT_FH: root fh */
nfsstat4 status;
};
struct PUTROOTFH4res {
/* CURRENT_FH: root fh */
nfsstat4 status;
};
PUTROOTFH replaces the current filehandle with the filehandle that represents the root of the server's namespace. From this filehandle, a LOOKUP operation can locate any other filehandle on the server. This filehandle may be different from the public filehandle, which may be associated with some other directory on the server.
PUTROOTFH将当前文件句柄替换为表示服务器命名空间根的文件句柄。通过此文件句柄，查找操作可以找到服务器上的任何其他文件句柄。此文件句柄可能不同于公用文件句柄，公用文件句柄可能与服务器上的其他目录相关联。
See Section 15.2.4.1 for more details on the current filehandle.
有关当前文件句柄的更多详细信息，请参见第15.2.4.1节。
PUTROOTFH is commonly used as the first operator in an NFS request to set the context for operations that follow it.
PUTROOTFH通常用作NFS请求中的第一个操作符，用于为随后的操作设置上下文。
(cfh), stateid, offset, count -> eof, data
（cfh），状态ID，偏移量，计数->eof，数据
struct READ4args {
/* CURRENT_FH: file */
stateid4 stateid;
offset4 offset;
count4 count;
};
struct READ4args {
/* CURRENT_FH: file */
stateid4 stateid;
offset4 offset;
count4 count;
};
struct READ4resok {
bool eof;
opaque data<>;
};
struct READ4resok {
bool eof;
opaque data<>;
};
union READ4res switch (nfsstat4 status) {
case NFS4_OK:
READ4resok resok4;
default:
void;
};
union READ4res switch (nfsstat4 status) {
case NFS4_OK:
READ4resok resok4;
default:
void;
};
The READ operation reads data from the regular file identified by the current filehandle.
读取操作从由当前文件句柄标识的常规文件中读取数据。
The client provides an offset of where the READ is to start and a count of how many bytes are to be read. An offset of 0 (zero) means to read data starting at the beginning of the file. If the offset is greater than or equal to the size of the file, the status, NFS4_OK, is returned with a data length set to 0 (zero), and eof is set to TRUE. The READ is subject to access permissions checking.
客户端提供读取开始位置的偏移量和读取字节数的计数。偏移量为0（零）表示从文件开头开始读取数据。如果偏移量大于或等于文件大小，则返回状态NFS4_OK，数据长度设置为0（零），eof设置为TRUE。读取受访问权限检查的约束。
If the client specifies a count value of 0 (zero), the READ succeeds and returns 0 (zero) bytes of data (subject to access permissions checking). The server may choose to return fewer bytes than specified by the client. The client needs to check for this condition and handle the condition appropriately.
如果客户端指定的计数值为0（零），则读取成功并返回0（零）字节的数据（取决于访问权限检查）。服务器可以选择返回的字节数少于客户端指定的字节数。客户需要检查该情况并适当处理该情况。
The stateid value for a READ request represents a value returned from a previous byte-range lock or share reservation request, or the stateid associated with a delegation. The stateid is used by the server to verify that the associated share reservation and any byte-range locks are still valid and to update lease timeouts for the client.
读取请求的stateid值表示从以前的字节范围锁定或共享保留请求返回的值，或与委派关联的stateid。服务器使用stateid验证关联的共享保留和任何字节范围锁是否仍然有效，并更新客户端的租约超时。
If the READ ended at the end-of-file (formally, in a correctly formed READ request, if offset + count is equal to the size of the file), or the READ request extends beyond the size of the file (if offset + count is greater than the size of the file), eof is returned as TRUE; otherwise, it is FALSE. A successful READ of an empty file will always return eof as TRUE.
如果读取在文件末尾结束（正式地说，在格式正确的读取请求中，如果偏移量+计数等于文件的大小），或者读取请求超出了文件的大小（如果偏移量+计数大于文件的大小），则eof返回为TRUE；否则，这是错误的。成功读取空文件将始终将eof返回为TRUE。
If the current filehandle is not a regular file, an error will be returned to the client. In the case where the current filehandle represents a directory, NFS4ERR_ISDIR is returned; otherwise, NFS4ERR_INVAL is returned.
如果当前文件句柄不是常规文件，则会向客户端返回错误。如果当前文件句柄表示目录，则返回NFS4ERR_ISDIR；否则，将返回NFS4ERR_INVAL。
For a READ using the special anonymous stateid, the server MAY allow the READ to be serviced subject to mandatory file locks or the current share_deny modes for the file. For a READ using the special READ bypass stateid, the server MAY allow READ operations to bypass locking checks at the server.
对于使用特殊匿名stateid的读取，服务器可能允许根据文件的强制文件锁定或当前共享拒绝模式对读取进行服务。对于使用特殊读取旁路stateid的读取，服务器可能允许读取操作绕过服务器上的锁定检查。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
If the server returns a "short read" (i.e., less data than requested and eof is set to FALSE), the client should send another READ to get the remaining data. A server may return less data than requested under several circumstances. The file may have been truncated by another client or perhaps on the server itself, changing the file size from what the requesting client believes to be the case. This would reduce the actual amount of data available to the client. It is possible that the server reduces the transfer size and so returns a short read result. Server resource exhaustion may also result in a short read.
如果服务器返回“短读”（即数据少于请求的数据，且eof设置为FALSE），则客户端应发送另一次读取以获取剩余数据。在几种情况下，服务器返回的数据可能少于请求的数据。该文件可能已被另一个客户端或服务器本身截断，从而改变了请求客户端认为的文件大小。这将减少客户端可用的实际数据量。服务器可能会减小传输大小，从而返回短读取结果。服务器资源耗尽也可能导致短读。
If mandatory byte-range locking is in effect for the file, and if the byte range corresponding to the data to be read from the file is WRITE_LT locked by an owner not associated with the stateid, the server will return the NFS4ERR_LOCKED error. The client should try to get the appropriate READ_LT via the LOCK operation before re-attempting the READ. When the READ completes, the client should release the byte-range lock via LOCKU.
如果强制字节范围锁定对文件生效，并且如果与要从文件读取的数据相对应的字节范围由与stateid不关联的所有者进行写锁定，则服务器将返回NFS4ERR_锁定错误。在重新尝试读取之前，客户端应尝试通过锁定操作获取适当的读取。读取完成后，客户端应通过LOCKU释放字节范围锁。
If another client has an OPEN_DELEGATE_WRITE delegation for the file being read, the delegation must be recalled, and the operation cannot proceed until that delegation is returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be returned to requests made while the delegation remains outstanding. Normally, delegations will not be recalled as a result of a READ operation, since the recall will occur as a result of an earlier OPEN. However, since it is possible for a READ to be done with a special stateid, the server needs to check for this case even though the client should have done an OPEN previously.
如果另一个客户端对正在读取的文件具有OPEN_DELEGATE_WRITE委派，则必须重新调用该委派，并且在该委派被返回或撤销之前，操作无法继续。除非这种情况发生得很快，否则在委托仍然未完成的情况下，一个或多个NFS4ERR_延迟错误将返回到请求。通常情况下，不会因读取操作而召回代表团，因为召回将因先前的打开操作而发生。但是，由于可以使用特殊的stateid进行读取，因此服务器需要检查这种情况，即使客户机以前应该进行过打开操作。
(cfh), cookie, cookieverf, dircount, maxcount, attr_request ->
cookieverf { cookie, name, attrs }
(cfh), cookie, cookieverf, dircount, maxcount, attr_request ->
cookieverf { cookie, name, attrs }
struct READDIR4args {
/* CURRENT_FH: directory */
nfs_cookie4 cookie;
verifier4 cookieverf;
count4 dircount;
count4 maxcount;
bitmap4 attr_request;
};
struct READDIR4args {
/* CURRENT_FH: directory */
nfs_cookie4 cookie;
verifier4 cookieverf;
count4 dircount;
count4 maxcount;
bitmap4 attr_request;
};
struct entry4 {
nfs_cookie4 cookie;
component4 name;
fattr4 attrs;
entry4 *nextentry;
};
struct entry4 {
nfs_cookie4 cookie;
component4 name;
fattr4 attrs;
entry4 *nextentry;
};
struct dirlist4 {
entry4 *entries;
bool eof;
};
struct dirlist4 {
entry4 *entries;
bool eof;
};
struct READDIR4resok {
verifier4 cookieverf;
dirlist4 reply;
};
struct READDIR4resok {
verifier4 cookieverf;
dirlist4 reply;
};
union READDIR4res switch (nfsstat4 status) {
case NFS4_OK:
READDIR4resok resok4;
default:
void;
};
union READDIR4res switch (nfsstat4 status) {
case NFS4_OK:
READDIR4resok resok4;
default:
void;
};
The READDIR operation retrieves a variable number of entries from a file system directory and for each entry returns attributes that were requested by the client, along with information to allow the client to request additional directory entries in a subsequent READDIR.
READDIR操作从文件系统目录中检索数量可变的条目，对于每个条目，返回客户端请求的属性，以及允许客户端在后续READDIR中请求其他目录条目的信息。
The arguments contain a cookie value that represents where the READDIR should start within the directory. A value of 0 (zero) for the cookie is used to start reading at the beginning of the directory. For subsequent READDIR requests, the client specifies a cookie value that is provided by the server in a previous READDIR request.
这些参数包含一个cookie值，该值表示READDIR在目录中的起始位置。cookie的值0（零）用于开始读取目录的开头。对于后续的READDIR请求，客户机指定一个cookie值，该值由服务器在先前的READDIR请求中提供。
The cookieverf value should be set to 0 (zero) when the cookie value is 0 (zero) (first directory read). On subsequent requests, it should be a cookieverf as returned by the server. The cookieverf must match that returned by the READDIR in which the cookie was acquired. If the server determines that the cookieverf is no longer valid for the directory, the error NFS4ERR_NOT_SAME must be returned.
当cookie值为0（零）（第一次读取目录）时，cookieverf值应设置为0（零）。在后续请求中，它应该是服务器返回的cookieverf。cookieverf必须与获取cookie的READDIR返回的值匹配。如果服务器确定cookieverf对目录不再有效，则必须返回错误NFS4ERR_NOT_SAME。
The dircount portion of the argument is a hint of the maximum number of bytes of directory information that should be returned. This value represents the length of the names of the directory entries and the cookie value for these entries. This length represents the XDR encoding of the data (names and cookies) and not the length in the native format of the server.
参数的dircount部分是应该返回的目录信息的最大字节数的提示。此值表示目录项名称的长度以及这些项的cookie值。此长度表示数据（名称和cookie）的XDR编码，而不是服务器本机格式的长度。
The maxcount value of the argument is the maximum number of bytes for the result. This maximum size represents all of the data being returned within the READDIR4resok structure and includes the XDR overhead. The server may return less data. If the server is unable to return a single directory entry within the maxcount limit, the error NFS4ERR_TOOSMALL will be returned to the client.
参数的maxcount值是结果的最大字节数。此最大大小表示READDIR4resok结构中返回的所有数据，并包括XDR开销。服务器可能返回较少的数据。如果服务器无法返回maxcount限制内的单个目录项，则会将错误NFS4ERR_Toosall返回给客户端。
Finally, attr_request represents the list of attributes to be returned for each directory entry supplied by the server.
最后，attr_request表示要为服务器提供的每个目录项返回的属性列表。
On successful return, the server's response will provide a list of directory entries. Each of these entries contains the name of the directory entry, a cookie value for that entry, and the associated attributes as requested. The "eof" flag has a value of TRUE if there are no more entries in the directory.
成功返回后，服务器的响应将提供目录项列表。每个条目都包含目录条目的名称、该条目的cookie值以及请求的相关属性。如果目录中没有更多条目，“eof”标志的值为TRUE。
The cookie value is only meaningful to the server and is used as a "bookmark" for the directory entry. As mentioned, this cookie is used by the client for subsequent READDIR operations so that it may continue reading a directory. The cookie is similar in concept to a
cookie值仅对服务器有意义，并用作目录项的“书签”。如前所述，客户端将此cookie用于后续的READDIR操作，以便它可以继续读取目录。cookie在概念上类似于
READ offset but should not be interpreted as such by the client. The server SHOULD try to accept cookie values issued with READDIR responses even if the directory has been modified between the READDIR calls but MAY return NFS4ERR_NOT_VALID if this is not possible, as might be the case if the server has rebooted in the interim.
读取偏移量，但客户端不应将其解释为读取偏移量。即使在READDIR调用之间修改了目录，服务器也应尝试接受随READDIR响应发出的cookie值，但如果不可能，则可能返回NFS4ERR_NOT_VALID，如服务器在此期间重新启动。
In some cases, the server may encounter an error while obtaining the attributes for a directory entry. Instead of returning an error for the entire READDIR operation, the server can instead return the attribute 'fattr4_rdattr_error'. With this, the server is able to communicate the failure to the client and not fail the entire operation in the instance of what might be a transient failure. Obviously, the client must request the fattr4_rdattr_error attribute for this method to work properly. If the client does not request the attribute, the server has no choice but to return failure for the entire READDIR operation.
在某些情况下，服务器在获取目录项的属性时可能会遇到错误。服务器可以返回属性“fattr4\u rdattr\u error”，而不是返回整个READDIR操作的错误。这样，服务器就能够将故障告知客户机，而不会在可能是暂时故障的情况下使整个操作失败。显然，客户端必须请求fattr4_rdattr_error属性才能使此方法正常工作。如果客户端不请求该属性，服务器别无选择，只能返回整个READDIR操作的失败。
For some file system environments, the directory entries "." and ".." have special meaning, and in other environments, they may not. If the server supports these special entries within a directory, they should not be returned to the client as part of the READDIR response. To enable some client environments, the cookie values of 0, 1, and 2 are to be considered reserved. Note that the UNIX client will use these values when combining the server's response and local representations to enable a fully formed UNIX directory presentation to the application.
对于某些文件系统环境，目录项“.”和“.”具有特殊含义，而在其他环境中，它们可能没有特殊含义。如果服务器支持目录中的这些特殊条目，则不应将它们作为READDIR响应的一部分返回给客户端。要启用某些客户端环境，cookie值0、1和2将被视为保留。请注意，UNIX客户端将在组合服务器的响应和本地表示时使用这些值，以便为应用程序启用完全格式的UNIX目录表示。
For READDIR arguments, cookie values of 1 and 2 SHOULD NOT be used, and for READDIR results, cookie values of 0, 1, and 2 MUST NOT be returned.
对于READDIR参数，不应使用cookie值1和2，对于READDIR结果，不得返回cookie值0、1和2。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
The server's file system directory representations can differ greatly. A client's programming interfaces may also be bound to the local operating environment in a way that does not translate well into the NFS protocol. Therefore, the dircount and maxcount fields are provided to allow the client the ability to provide guidelines to the server. If the client is aggressive about attribute collection during a READDIR, the server has an idea of how to limit the encoded response. The dircount field provides a hint on the number of entries based solely on the names of the directory entries. Since it is a hint, it may be possible that a dircount value is zero. In this case, the server is free to ignore the dircount value and return directory information based on the specified maxcount value.
服务器的文件系统目录表示形式可能会有很大差异。客户端的编程接口也可能以无法很好地转换为NFS协议的方式绑定到本地操作环境。因此，提供dircount和maxcount字段是为了让客户机能够向服务器提供指导。如果客户机在READDIR过程中对属性收集非常积极，那么服务器就知道如何限制编码响应。dircount字段仅根据目录项的名称提供有关项数的提示。因为这是一个提示，所以dircount值可能为零。在这种情况下，服务器可以忽略dircount值，并根据指定的maxcount值返回目录信息。
As there is no way for the client to indicate that a cookie value, once received, will not be subsequently used, server implementations should avoid schemes that allocate memory corresponding to a returned cookie. Such allocation can be avoided if the server bases cookie values on a value such as the offset within the directory where the scan is to be resumed.
由于客户端无法指示一旦接收到cookie值，随后将不会使用该值，因此服务器实现应避免分配与返回的cookie对应的内存的方案。如果服务器将cookie值基于某个值（如要恢复扫描的目录中的偏移量），则可以避免这种分配。
Cookies generated by such techniques should be designed to remain valid despite modification of the associated directory. If a server were to invalidate a cookie because of a directory modification, READDIRs of large directories might never finish.
通过此类技术生成的cookie应设计为在修改相关目录的情况下仍然有效。如果服务器因为目录修改而使cookie无效，那么大目录的readdir可能永远不会完成。
If a directory is deleted after the client has carried out one or more READDIR operations on the directory, the cookies returned will become invalid; however, the server does not need to be concerned, as the directory filehandle used previously would have become stale and would be reported as such on subsequent READDIR operations. The server would not need to check the cookie verifier in this case.
如果在客户端对目录执行一个或多个READDIR操作后删除目录，则返回的Cookie将无效；但是，不需要担心服务器，因为以前使用的目录filehandle可能已经过时，并且在后续的READDIR操作中会被报告为过时。在这种情况下，服务器不需要检查cookie验证器。
However, certain reorganization operations on a directory (including directory compaction) may invalidate READDIR cookies previously given out. When such a situation occurs, the server should modify the cookie verifier so as to disallow the use of cookies that would otherwise no longer be valid.
但是，目录上的某些重组操作（包括目录压缩）可能会使以前提供的READDIR Cookie无效。出现这种情况时，服务器应修改cookie验证器，以禁止使用否则将不再有效的cookie。
The cookieverf may be used by the server to help manage cookie values that may become stale. It should be a rare occurrence that a server is unable to continue properly reading a directory with the provided cookie/cookieverf pair. The server should make every effort to avoid this condition since the application at the client may not be able to properly handle this type of failure.
服务器可以使用cookieverf来帮助管理可能过时的cookie值。服务器无法使用提供的cookie/cookieverf对继续正确读取目录的情况应该很少发生。服务器应尽一切努力避免这种情况，因为客户端的应用程序可能无法正确处理此类故障。
The use of the cookieverf will also protect the client from using READDIR cookie values that may be stale. For example, if the file system has been migrated, the server may or may not be able to use the same cookie values to service READDIR as the previous server used. With the client providing the cookieverf, the server is able to provide the appropriate response to the client. This prevents the case where the server may accept a cookie value but the underlying directory has changed and the response is invalid from the client's context of its previous READDIR.
cookieverf的使用还将保护客户端不使用可能过时的READDIR cookie值。例如，如果文件系统已迁移，则服务器可能无法使用与先前使用的服务器相同的cookie值为READDIR提供服务。通过客户机提供cookieverf，服务器能够向客户机提供适当的响应。这可以防止服务器可能接受cookie值，但基础目录已更改，并且响应在其先前READDIR的客户端上下文中无效的情况。
Since some servers will not be returning "." and ".." entries as has been done with previous versions of the NFS protocol, the client that requires these entries be present in READDIR responses must fabricate them.
由于某些服务器不会像以前版本的NFS协议那样返回“.”和“.”条目，因此要求这些条目出现在READDIR响应中的客户端必须创建它们。
(cfh) -> linktext
（cfh）->链接文本
/* CURRENT_FH: symlink */
void;
/* CURRENT_FH: symlink */
void;
struct READLINK4resok {
linktext4 link;
};
struct READLINK4resok {
linktext4 link;
};
union READLINK4res switch (nfsstat4 status) {
case NFS4_OK:
READLINK4resok resok4;
default:
void;
};
union READLINK4res switch (nfsstat4 status) {
case NFS4_OK:
READLINK4resok resok4;
default:
void;
};
READLINK reads the data associated with a symbolic link. The data is a UTF-8 string that is opaque to the server. That is, whether created by an NFS client or created locally on the server, the data in a symbolic link is not interpreted when created but is simply stored.
READLINK读取与符号链接关联的数据。数据是对服务器不透明的UTF-8字符串。也就是说，无论是由NFS客户端创建的还是在服务器上本地创建的，符号链接中的数据在创建时都不会解释，而只是存储。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
A symbolic link is nominally a pointer to another file. The data is not necessarily interpreted by the server; it is just stored in the file. It is possible for a client implementation to store a pathname that is not meaningful to the server operating system in a symbolic link. A READLINK operation returns the data to the client for interpretation. If different implementations want to share access to symbolic links, then they must agree on the interpretation of the data in the symbolic link.
符号链接名义上是指向另一个文件的指针。数据不一定由服务器解释；它只是存储在文件中。客户端实现可以将对服务器操作系统没有意义的路径名存储在符号链接中。READLINK操作将数据返回给客户端进行解释。如果不同的实现想要共享对符号链接的访问，那么它们必须就符号链接中数据的解释达成一致。
The READLINK operation is only allowed on objects of type NF4LNK. The server should return the error NFS4ERR_INVAL if the object is not of type NF4LNK.
仅允许对NF4LNK类型的对象执行READLINK操作。如果对象不是NF4LNK类型，则服务器应返回错误NFS4ERR_INVAL。
(cfh), filename -> change_info
（cfh），文件名->更改信息
struct REMOVE4args {
/* CURRENT_FH: directory */
component4 target;
};
struct REMOVE4args {
/* CURRENT_FH: directory */
component4 target;
};
struct REMOVE4resok {
change_info4 cinfo;
};
struct REMOVE4resok {
change_info4 cinfo;
};
union REMOVE4res switch (nfsstat4 status) {
case NFS4_OK:
REMOVE4resok resok4;
default:
void;
};
union REMOVE4res switch (nfsstat4 status) {
case NFS4_OK:
REMOVE4resok resok4;
default:
void;
};
The REMOVE operation removes (deletes) a directory entry named by filename from the directory corresponding to the current filehandle. If the entry in the directory was the last reference to the corresponding file system object, the object may be destroyed.
移除操作从与当前文件句柄对应的目录中移除（删除）以文件名命名的目录项。如果目录中的条目是对相应文件系统对象的最后一次引用，则该对象可能会被销毁。
For the directory where the filename was removed, the server returns change_info4 information in cinfo. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the removal.
对于删除文件名的目录，服务器返回cinfo中的change_info4信息。使用change_info4结构的原子字段，服务器将指示是否以原子方式获得了与删除相关的更改前后属性。
If the target is of zero length, NFS4ERR_INVAL will be returned. The target is also subject to the normal UTF-8, character support, and name checks. See Section 12.7 for further discussion.
如果目标长度为零，将返回NFS4ERR_INVAL。目标还需要进行常规UTF-8、字符支持和名称检查。进一步讨论见第12.7节。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
NFSv3 required a different operator -- RMDIR -- for directory removal, and REMOVE for non-directory removal. This allowed clients to skip checking the file type when being passed a non-directory delete system call (e.g., unlink() [unlink] in POSIX) to remove a directory, as well as the converse (e.g., a rmdir() on a non-directory), because they knew the server would check the file type. NFSv4 REMOVE can be used to delete any directory entry, independent of its file type. The implementer of an NFSv4 client's entry points from the unlink() and rmdir() system calls should first check the file type against the types the system call is allowed to remove before issuing a REMOVE. Alternatively, the implementer can produce a COMPOUND call that includes a LOOKUP/VERIFY sequence to verify the file type before a REMOVE operation in the same COMPOUND call.
NFSv3需要一个不同的操作符RMDIR来删除目录，REMOVE来删除非目录。这允许客户端在通过非目录删除系统调用（如POSIX中的unlink（）[unlink]）删除目录时跳过检查文件类型，反之亦然（如非目录中的rmdir（）），因为他们知道服务器将检查文件类型。NFSv4 REMOVE可用于删除任何目录项，与其文件类型无关。来自unlink（）和rmdir（）系统调用的NFSv4客户端入口点的实现者应首先根据系统调用允许删除的类型检查文件类型，然后再发出删除命令。或者，实现者可以生成包含查找/验证序列的复合调用，以在同一复合调用中的删除操作之前验证文件类型。
The concept of last reference is server specific. However, if the numlinks field in the previous attributes of the object had the value 1, the client should not rely on referring to the object via a filehandle. Likewise, the client should not rely on the resources (disk space, directory entry, and so on) formerly associated with the object becoming immediately available. Thus, if a client needs to be able to continue to access a file after using REMOVE to remove it, the client should take steps to make sure that the file will still be accessible. The usual mechanism used is to RENAME the file from its old name to a new hidden name.
最后一个引用的概念是特定于服务器的。但是，如果对象先前属性中的numlinks字段的值为1，则客户端不应依赖于通过文件句柄引用对象。同样，客户机也不应该依赖于以前与对象关联的资源（磁盘空间、目录项等）立即可用。因此，如果客户机在使用REMOVE删除文件后需要能够继续访问该文件，则客户机应采取步骤确保该文件仍然可以访问。通常使用的机制是将文件从旧名称重命名为新的隐藏名称。
If the server finds that the file is still open when the REMOVE arrives:
如果服务器在删除到达时发现文件仍处于打开状态：
o The server SHOULD NOT delete the file's directory entry if the file was opened with OPEN4_SHARE_DENY_WRITE or OPEN4_SHARE_DENY_BOTH.
o 如果文件是用OPEN4_SHARE_DENY_WRITE或OPEN4_SHARE_DENY_WRITE打开的，则服务器不应删除文件的目录项。
o If the file was not opened with OPEN4_SHARE_DENY_WRITE or OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's directory entry. However, until the last CLOSE of the file, the server MAY continue to allow access to the file via its filehandle.
o 如果文件不是用OPEN4_SHARE_DENY_WRITE或OPEN4_SHARE_DENY_两者打开的，服务器应该删除文件的目录条目。但是，在文件最后一次关闭之前，服务器可能会继续允许通过其文件句柄访问文件。
(sfh), oldname, (cfh), newname -> source_cinfo, target_cinfo
（sfh）、旧名称（cfh）、新名称->源信息、目标信息
struct RENAME4args {
/* SAVED_FH: source directory */
component4 oldname;
/* CURRENT_FH: target directory */
component4 newname;
};
struct RENAME4args {
/* SAVED_FH: source directory */
component4 oldname;
/* CURRENT_FH: target directory */
component4 newname;
};
struct RENAME4resok {
change_info4 source_cinfo;
change_info4 target_cinfo;
};
struct RENAME4resok {
change_info4 source_cinfo;
change_info4 target_cinfo;
};
union RENAME4res switch (nfsstat4 status) {
case NFS4_OK:
RENAME4resok resok4;
default:
void;
};
union RENAME4res switch (nfsstat4 status) {
case NFS4_OK:
RENAME4resok resok4;
default:
void;
};
The RENAME operation renames the object identified by oldname in the source directory corresponding to the saved filehandle, as set by the SAVEFH operation, to newname in the target directory corresponding to the current filehandle. The operation is required to be atomic to the client. Source and target directories must reside on the same file system on the server. On success, the current filehandle will continue to be the target directory.
重命名操作将SAVEFH操作设置的与保存的文件句柄相对应的源目录中由oldname标识的对象重命名为与当前文件句柄相对应的目标目录中的newname。该操作对于客户端来说必须是原子的。源目录和目标目录必须位于服务器上的同一文件系统上。成功后，当前文件句柄将继续作为目标目录。
If the target directory already contains an entry with the name newname, the source object must be compatible with the target: either both are non-directories, or both are directories, and the target must be empty. If compatible, the existing target is removed before the rename occurs (see Section 16.26 for client and server actions whenever a target is removed). If they are not compatible or if the target is a directory but not empty, the server will return the error NFS4ERR_EXIST.
如果目标目录已包含名为newname的条目，则源对象必须与目标对象兼容：或者两者都是非目录，或者两者都是目录，并且目标对象必须为空。如果兼容，则在重命名之前删除现有目标（有关删除目标时的客户端和服务器操作，请参阅第16.26节）。如果它们不兼容，或者如果目标是目录但不是空的，服务器将返回错误NFS4ERR_EXIST。
If oldname and newname both refer to the same file (they might be hard links of each other), then RENAME should perform no action and return success.
如果oldname和newname都引用同一个文件（它们可能是彼此的硬链接），则RENAME不应执行任何操作并返回success。
For both directories involved in the RENAME, the server returns change_info4 information. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the rename.
对于重命名中涉及的两个目录，服务器返回change_info4信息。使用change_info4结构的原子字段，服务器将指示是否以原子方式获得了与重命名相关的更改前后属性。
If the oldname refers to a named attribute and the saved and current filehandles refer to the named attribute directories of different file system objects, the server will return NFS4ERR_XDEV, just as if the saved and current filehandles represented directories on different file systems.
如果oldname引用一个命名属性，而保存的和当前的文件句柄引用不同文件系统对象的命名属性目录，则服务器将返回NFS4ERR_XDEV，就像保存的和当前的文件句柄表示不同文件系统上的目录一样。
If the oldname or newname is of zero length, NFS4ERR_INVAL will be returned. The oldname and newname are also subject to the normal UTF-8, character support, and name checks. See Section 12.7 for further discussion.
如果oldname或newname的长度为零，则将返回NFS4ERR_INVAL。oldname和newname还需要进行常规UTF-8、字符支持和名称检查。进一步讨论见第12.7节。
The RENAME operation must be atomic to the client. The statement "source and target directories must reside on the same file system on the server" means that the fsid fields in the attributes for the directories are the same. If they reside on different file systems, the error NFS4ERR_XDEV is returned.
重命名操作必须是客户端的原子操作。语句“源目录和目标目录必须位于服务器上的同一文件系统”表示目录属性中的fsid字段相同。如果它们驻留在不同的文件系统上，则返回错误NFS4ERR_XDEV。
Based on the value of the fh_expire_type attribute for the object, the filehandle may or may not expire on a RENAME. However, server implementers are strongly encouraged to attempt to keep filehandles from expiring in this fashion.
根据对象的fh_expire_type属性的值，文件句柄可能会在重命名时过期，也可能不会过期。但是，强烈建议服务器实现人员尝试以这种方式防止文件句柄过期。
On some servers, the filenames "." and ".." are illegal as either oldname or newname and will result in the error NFS4ERR_BADNAME. In addition, on many servers the case of oldname or newname being an alias for the source directory will be checked for. Such servers will return the error NFS4ERR_INVAL in these cases.
在某些服务器上，文件名“.”和“.”作为oldname或newname都是非法的，将导致错误NFS4ERR_BADNAME。此外，在许多服务器上，将检查oldname或newname作为源目录别名的情况。在这些情况下，此类服务器将返回错误NFS4ERR_INVAL。
If either of the source or target filehandles are not directories, the server will return NFS4ERR_NOTDIR.
如果源或目标文件句柄中的任何一个不是目录，服务器将返回NFS4ERR\u NOTDIR。
clientid -> ()
clientid->（）
struct RENEW4args {
clientid4 clientid;
};
struct RENEW4args {
clientid4 clientid;
};
struct RENEW4res {
nfsstat4 status;
};
struct RENEW4res {
nfsstat4 status;
};
The RENEW operation is used by the client to renew leases that it currently holds at a server. In processing the RENEW request, the server renews all leases associated with the client. The associated leases are determined by the clientid provided via the SETCLIENTID operation.
续订操作由客户端用于续订其当前在服务器上持有的租约。在处理续订请求时，服务器续订与客户端关联的所有租约。关联的租约由通过SETCLIENTID操作提供的clientid确定。
When the client holds delegations, it needs to use RENEW to detect when the server has determined that the callback path is down. When the server has made such a determination, only the RENEW operation will renew the lease on delegations. If the server determines the callback path is down, it returns NFS4ERR_CB_PATH_DOWN. Even though it returns NFS4ERR_CB_PATH_DOWN, the server MUST renew the lease on the byte-range locks and share reservations that the client has established on the server. If for some reason the lock and share reservation lease cannot be renewed, then the server MUST return an error other than NFS4ERR_CB_PATH_DOWN, even if the callback path is also down. In the event that the server has conditions such that it could return either NFS4ERR_CB_PATH_DOWN or NFS4ERR_LEASE_MOVED, NFS4ERR_LEASE_MOVED MUST be handled first.
当客户端持有委托时，它需要使用“续订”来检测服务器何时确定回调路径已关闭。当服务器做出这样的决定时，只有续订操作将续订委托租约。如果服务器确定回调路径已关闭，则返回NFS4ERR\u CB\u path\u down。即使返回NFS4ERR_CB_PATH_DOWN，服务器也必须续订字节范围锁的租约，并共享客户端在服务器上建立的保留。如果由于某种原因无法续订锁和共享保留租约，则服务器必须返回NFS4ERR_CB_PATH_DOWN以外的错误，即使回调路径也已关闭。如果服务器有条件返回NFS4ERR_CB_PATH_DOWN或NFS4ERR_LEASE_MOVED，则必须首先处理NFS4ERR_LEASE_MOVED。
The client that issues RENEW MUST choose the principal, RPC security flavor, and, if applicable, GSS-API mechanism and service via one of the following algorithms:
发出续订的客户端必须通过以下算法之一选择主体、RPC安全风格以及GSS-API机制和服务（如果适用）：
o The client uses the same principal, RPC security flavor, and -- if the flavor was RPCSEC_GSS -- the same mechanism and service that were used when the client ID was established via SETCLIENTID_CONFIRM.
o 客户端使用相同的主体RPC security flavor，如果flavor是RPCSEC_GSS，则使用通过SETCLIENTID_CONFIRM建立客户端ID时使用的相同机制和服务。
o The client uses any principal, RPC security flavor, mechanism, and service combination that currently has an OPEN file on the server. That is, the same principal had a successful OPEN operation; the file is still open by that principal; and the flavor, mechanism, and service of RENEW match that of the previous OPEN.
o 客户端使用服务器上当前有打开文件的任何主体、RPC安全风格、机制和服务组合。也就是说，同一个委托人进行了成功的公开操作；该文件仍由该负责人打开；更新的风格、机制和服务与之前的公开赛相匹配。
The server MUST reject a RENEW that does not use one of the aforementioned algorithms, with the error NFS4ERR_ACCESS.
服务器必须拒绝不使用上述算法之一的续订，错误为NFS4ERR_ACCESS。
(sfh) -> (cfh)
（sfh）->（cfh）
/* SAVED_FH: */
void;
/* SAVED_FH: */
void;
struct RESTOREFH4res {
/* CURRENT_FH: value of saved fh */
nfsstat4 status;
};
struct RESTOREFH4res {
/* CURRENT_FH: value of saved fh */
nfsstat4 status;
};
Set the current filehandle to the value in the saved filehandle. If there is no saved filehandle, then return the error NFS4ERR_RESTOREFH.
将当前文件句柄设置为保存的文件句柄中的值。如果没有保存的文件句柄，则返回错误NFS4ERR\u RESTOREFH。
Operations like OPEN and LOOKUP use the current filehandle to represent a directory and replace it with a new filehandle. Assuming that the previous filehandle was saved with a SAVEFH operator, the previous filehandle can be restored as the current filehandle. This is commonly used to obtain post-operation attributes for the directory, e.g.,
像OPEN和LOOKUP这样的操作使用当前文件句柄来表示目录，并用新的文件句柄替换它。假设前一个filehandle是使用SAVEFH运算符保存的，则可以将前一个filehandle还原为当前filehandle。这通常用于获取目录的操作后属性，例如。，
PUTFH (directory filehandle) SAVEFH GETATTR attrbits (pre-op dir attrs) CREATE optbits "foo" attrs GETATTR attrbits (file attributes) RESTOREFH GETATTR attrbits (post-op dir attrs)
PUTFH（目录文件句柄）SAVEFH GETATTR attrbits（操作前目录attrs）创建optbits“foo”attrs GETATTR attrbits（文件属性）RESTOREFH GETATTR attrbits（操作后目录attrs）
(cfh) -> (sfh)
（cfh）->（sfh）
/* CURRENT_FH: */
void;
/* CURRENT_FH: */
void;
struct SAVEFH4res {
/* SAVED_FH: value of current fh */
nfsstat4 status;
};
struct SAVEFH4res {
/* SAVED_FH: value of current fh */
nfsstat4 status;
};
Save the current filehandle. If a previous filehandle was saved, then it is no longer accessible. The saved filehandle can be restored as the current filehandle with the RESTOREFH operator.
保存当前文件句柄。如果保存了以前的文件句柄，则无法再访问它。使用RESTOREFH操作符可以将保存的文件句柄还原为当前文件句柄。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
(cfh), name -> { secinfo }
(cfh), name -> { secinfo }
struct SECINFO4args {
/* CURRENT_FH: directory */
component4 name;
};
struct SECINFO4args {
/* CURRENT_FH: directory */
component4 name;
};
/*
* From RFC 2203
*/
enum rpc_gss_svc_t {
RPC_GSS_SVC_NONE = 1,
RPC_GSS_SVC_INTEGRITY = 2,
RPC_GSS_SVC_PRIVACY = 3
};
/*
* From RFC 2203
*/
enum rpc_gss_svc_t {
RPC_GSS_SVC_NONE = 1,
RPC_GSS_SVC_INTEGRITY = 2,
RPC_GSS_SVC_PRIVACY = 3
};
struct rpcsec_gss_info {
sec_oid4 oid;
qop4 qop;
rpc_gss_svc_t service;
};
struct rpcsec_gss_info {
sec_oid4 oid;
qop4 qop;
rpc_gss_svc_t service;
};
/* RPCSEC_GSS has a value of '6'. See RFC 2203 */
union secinfo4 switch (uint32_t flavor) {
case RPCSEC_GSS:
rpcsec_gss_info flavor_info;
default:
void;
};
/* RPCSEC_GSS has a value of '6'. See RFC 2203 */
union secinfo4 switch (uint32_t flavor) {
case RPCSEC_GSS:
rpcsec_gss_info flavor_info;
default:
void;
};
typedef secinfo4 SECINFO4resok<>;
typedef secinfo4 SECINFO4resok<>;
union SECINFO4res switch (nfsstat4 status) {
case NFS4_OK:
SECINFO4resok resok4;
default:
void;
};
union SECINFO4res switch (nfsstat4 status) {
case NFS4_OK:
SECINFO4resok resok4;
default:
void;
};
The SECINFO operation is used by the client to obtain a list of valid RPC authentication flavors for a specific directory filehandle, filename pair. SECINFO should apply the same access methodology used for LOOKUP when evaluating the name. Therefore, if the requester does not have the appropriate access to perform a LOOKUP for the name, then SECINFO must behave the same way and return NFS4ERR_ACCESS.
客户端使用SECINFO操作获取特定目录文件句柄、文件名对的有效RPC身份验证样式列表。在评估名称时，SECINFO应采用与查找相同的访问方法。因此，如果请求者没有适当的权限来执行名称查找，那么SECINFO必须以相同的方式运行并返回NFS4ERR_访问。
The result will contain an array that represents the security mechanisms available, with an order corresponding to the server's preferences, the most preferred being first in the array. The client is free to pick whatever security mechanism it both desires and supports, or to pick -- in the server's preference order -- the first one it supports. The array entries are represented by the secinfo4 structure. The field 'flavor' will contain a value of AUTH_NONE, AUTH_SYS (as defined in [RFC5531]), or RPCSEC_GSS (as defined in [RFC2203]).
结果将包含一个表示可用安全机制的数组，其顺序与服务器的首选项相对应，最首选的是数组中的第一个。客户机可以自由选择它希望和支持的任何安全机制，或者按照服务器的优先顺序选择它支持的第一个安全机制。数组项由secinfo4结构表示。字段“flavor”将包含AUTH_NONE、AUTH_SYS（定义见[RFC5531]）或RPCSEC_GSS（定义见[RFC2203]）的值。
For the flavors AUTH_NONE and AUTH_SYS, no additional security information is returned. For a return value of RPCSEC_GSS, a security triple is returned that contains the mechanism object id (as defined in [RFC2743]), the quality of protection (as defined in [RFC2743]), and the service type (as defined in [RFC2203]). It is possible for SECINFO to return multiple entries with flavor equal to RPCSEC_GSS, with different security triple values.
对于AUTH_NONE和AUTH_SYS，不会返回其他安全信息。对于RPCSEC_GSS的返回值，将返回一个包含机制对象id（如[RFC2743]中定义）、保护质量（如[RFC2743]中定义）和服务类型（如[RFC2203]中定义）的安全三元组。SECINFO可以返回多个与RPCSEC_GSS味道相同的条目，并使用不同的安全三重值。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
If the name has a length of 0 (zero), or if the name does not obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned.
如果名称的长度为0（零），或者名称不符合UTF-8定义，则将返回错误NFS4ERR_INVAL。
The SECINFO operation is expected to be used by the NFS client when the error value of NFS4ERR_WRONGSEC is returned from another NFS operation. This signifies to the client that the server's security policy is different from what the client is currently using. At this point, the client is expected to obtain a list of possible security flavors and choose what best suits its policies.
当从另一个NFS操作返回NFS4ERR_errosec的错误值时，NFS客户端将使用SECINFO操作。这向客户端表示服务器的安全策略与客户端当前使用的不同。此时，客户机将获得可能的安全风格列表，并选择最适合其策略的。
As mentioned, the server's security policies will determine when a client request receives NFS4ERR_WRONGSEC. The operations that may receive this error are LINK, LOOKUP, LOOKUPP, OPEN, PUTFH, PUTPUBFH, PUTROOTFH, RENAME, RESTOREFH, and, indirectly, READDIR. LINK and RENAME will only receive this error if the security used for the operation is inappropriate for the saved filehandle. With the
如前所述，服务器的安全策略将确定客户端请求何时接收NFS4ERR_错误。可能收到此错误的操作包括链接、查找、查找、打开、PUTFH、PUTPUBFH、PUTROOTFH、重命名、恢复EFH，以及间接的READDIR。链接和重命名仅在用于操作的安全性不适合保存的文件句柄时才会收到此错误。和
exception of READDIR, these operations represent the point at which the client can instantiate a filehandle into the current filehandle at the server. The filehandle is either provided by the client (PUTFH, PUTPUBFH, PUTROOTFH) or generated as a result of a name-to-filehandle translation (LOOKUP and OPEN). RESTOREFH is different because the filehandle is a result of a previous SAVEFH. Even though the filehandle, for RESTOREFH, might have previously passed the server's inspection for a security match, the server will check it again on RESTOREFH to ensure that the security policy has not changed.
除了READDIR之外，这些操作表示客户端可以在服务器上将文件句柄实例化为当前文件句柄的点。文件句柄由客户机提供（PUTFH、PUTPUBFH、PUTROOTFH），或者由名称到文件句柄的转换（查找和打开）生成。RESTOREFH不同，因为filehandle是先前SAVEFH的结果。即使RESTOREFH的文件句柄以前可能已经通过了服务器的安全匹配检查，服务器也会在RESTOREFH上再次检查它，以确保安全策略没有更改。
If the client wants to resolve an error return of NFS4ERR_WRONGSEC, the following will occur:
如果客户端希望解决NFS4ERR_ErrorSec的错误返回，将发生以下情况：
o For LOOKUP and OPEN, the client will use SECINFO with the same current filehandle and name as provided in the original LOOKUP or OPEN to enumerate the available security triples.
o 对于查找和打开，客户端将使用与原始查找或打开中提供的具有相同当前文件句柄和名称的SECINFO枚举可用的安全三元组。
o For LINK, PUTFH, RENAME, and RESTOREFH, the client will use SECINFO and provide the parent directory filehandle and the object name that corresponds to the filehandle originally provided by the PUTFH or RESTOREFH, or, for LINK and RENAME, the SAVEFH.
o 对于LINK、PUTFH、RENAME和RESTOREFH，客户端将使用SECINFO并提供父目录filehandle和对象名，该名称与PUTFH或RESTOREFH最初提供的filehandle相对应，对于LINK和RENAME，则与SAVEFH相对应。
o For LOOKUPP, PUTROOTFH, and PUTPUBFH, the client will be unable to use the SECINFO operation since SECINFO requires a current filehandle and none exist for these three operations. Therefore, the client must iterate through the security triples available at the client and re-attempt the PUTROOTFH or PUTPUBFH operation. In the unfortunate event that none of the MANDATORY security triples are supported by the client and server, the client SHOULD try using others that support integrity. Failing that, the client can try using AUTH_NONE, but because such forms lack integrity checks, this puts the client at risk. Nonetheless, the server SHOULD allow the client to use whatever security form the client requests and the server supports, since the risks of doing so are on the client.
o 对于LOOKUPP、PUTROOTFH和PUTPUBFH，客户端将无法使用SECINFO操作，因为SECINFO需要当前文件句柄，并且这三个操作都不存在。因此，客户端必须遍历客户端可用的安全三元组，并重新尝试PUTROOTFH或PUTPUBFH操作。如果不幸的是，客户端和服务器都不支持强制安全性三元组，那么客户端应该尝试使用其他支持完整性的安全性三元组。如果做不到这一点，客户端可以尝试使用AUTH_NONE，但由于此类表单缺少完整性检查，这会使客户端面临风险。尽管如此，服务器应该允许客户机使用客户机请求和服务器支持的任何安全形式，因为这样做的风险在客户机上。
The READDIR operation will not directly return the NFS4ERR_WRONGSEC error. However, if the READDIR request included a request for attributes, it is possible that the READDIR request's security triple does not match that of a directory entry. If this is the case and the client has requested the rdattr_error attribute, the server will return the NFS4ERR_WRONGSEC error in rdattr_error for the entry.
READDIR操作不会直接返回NFS4ERR_ErrorSec错误。但是，如果READDIR请求包含属性请求，则READDIR请求的安全性三元组可能与目录项的安全性三元组不匹配。如果是这种情况，并且客户端请求了rdattr_error属性，则服务器将在rdattr_error中为条目返回NFS4ERR_errosec错误。
Note that a server MAY use the AUTH_NONE flavor to signify that the client is allowed to attempt to use authentication flavors that are not explicitly listed in the SECINFO results. Instead of using a listed flavor, the client might then, for instance, opt to use an otherwise unlisted RPCSEC_GSS mechanism instead of AUTH_NONE. It may wish to do so in order to meet an application requirement for data integrity or privacy. In choosing to use an unlisted flavor, the client SHOULD always be prepared to handle a failure by falling back to using AUTH_NONE or another listed flavor. It cannot assume that identity mapping is supported and should be prepared for the fact that its identity is squashed.
请注意，服务器可以使用AUTH_NONE风格来表示允许客户端尝试使用SECINFO结果中未明确列出的身份验证风格。例如，客户端可能会选择使用未列出的RPCSEC_GSS机制而不是AUTH_NONE，而不是使用列出的风格。它可能希望这样做，以满足数据完整性或隐私的应用要求。在选择使用未列出的香精时，客户机应始终准备好使用AUTH_NONE或其他列出的香精来处理失败。它不能假设身份映射是受支持的，并且应该为其身份被挤压的事实做好准备。
See Section 19 for a discussion on the recommendations for security flavors used by SECINFO.
有关SECINFO使用的安全风格建议的讨论，请参见第19节。
(cfh), stateid, attrmask, attr_vals -> attrsset
（cfh）、状态ID、属性掩码、属性值->属性集
struct SETATTR4args {
/* CURRENT_FH: target object */
stateid4 stateid;
fattr4 obj_attributes;
};
struct SETATTR4args {
/* CURRENT_FH: target object */
stateid4 stateid;
fattr4 obj_attributes;
};
struct SETATTR4res {
nfsstat4 status;
bitmap4 attrsset;
};
struct SETATTR4res {
nfsstat4 status;
bitmap4 attrsset;
};
The SETATTR operation changes one or more of the attributes of a file system object. The new attributes are specified with a bitmap and the attributes that follow the bitmap in bit order.
SETATTR操作更改文件系统对象的一个或多个属性。新属性由位图和位图后面按位顺序的属性指定。
The stateid argument for SETATTR is used to provide byte-range locking context that is necessary for SETATTR requests that set the size attribute. Since setting the size attribute modifies the file's data, it has the same locking requirements as a corresponding WRITE. Any SETATTR that sets the size attribute is incompatible with a share reservation that specifies OPEN4_SHARE_DENY_WRITE. The area between the old end-of-file and the new end-of-file is considered to be modified just as would have been the case had the area in question been specified as the target of WRITE, for the purpose of checking conflicts with byte-range locks, for those cases in which a server is implementing mandatory byte-range locking behavior. A valid stateid SHOULD always be specified. When the file size attribute is not set, the special anonymous stateid MAY be passed.
SETATTR的stateid参数用于提供设置size属性的SETATTR请求所需的字节范围锁定上下文。由于设置size属性会修改文件的数据，因此它具有与相应写入相同的锁定要求。任何设置size属性的SETATTR都与指定OPEN4\u share\u DENY\u WRITE的共享保留不兼容。对于服务器正在实施强制字节范围锁定行为的情况，为了检查与字节范围锁的冲突，将旧文件结尾和新文件结尾之间的区域视为已修改，就像将该区域指定为写入目标一样。应始终指定有效的stateid。未设置文件大小属性时，可能会传递特殊的匿名stateid。
On either success or failure of the operation, the server will return the attrsset bitmask to represent what (if any) attributes were successfully set. The attrsset in the response is a subset of the bitmap4 that is part of the obj_attributes in the argument.
操作成功或失败时，服务器将返回attrsset位掩码，以表示成功设置了哪些属性（如果有）。响应中的属性集是作为参数中obj_属性一部分的位图4的子集。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
If the request specifies the owner attribute to be set, the server SHOULD allow the operation to succeed if the current owner of the object matches the value specified in the request. Some servers may be implemented in such a way as to prohibit the setting of the owner attribute unless the requester has the privilege to do so. If the server is lenient in this one case of matching owner values, the client implementation may be simplified in cases of creation of an object (e.g., an exclusive create via OPEN) followed by a SETATTR.
如果请求指定要设置的所有者属性，则如果对象的当前所有者与请求中指定的值匹配，服务器应允许操作成功。某些服务器的实现方式可能会禁止设置所有者属性，除非请求者有权限这样做。如果服务器在匹配所有者值的这种情况下比较宽松，那么在创建对象（例如，通过OPEN创建独占的create）然后创建SETATTR的情况下，可以简化客户端实现。
The file size attribute is used to request changes to the size of a file. A value of zero causes the file to be truncated, a value less than the current size of the file causes data from the new size to the end of the file to be discarded, and a size greater than the current size of the file causes logically zeroed data bytes to be added to the end of the file. Servers are free to implement this using holes or actual zero data bytes. Clients should not make any assumptions regarding a server's implementation of this feature, beyond that the bytes returned will be zeroed. Servers MUST support extending the file size via SETATTR.
文件大小属性用于请求更改文件大小。值为零会导致文件被截断，小于文件当前大小的值会导致从新大小到文件结尾的数据被丢弃，大于文件当前大小的值会导致逻辑上归零的数据字节被添加到文件结尾。服务器可以自由地使用洞或实际的零数据字节来实现这一点。客户端不应该对服务器实现此功能做出任何假设，超过此假设，返回的字节将归零。服务器必须支持通过SETATTR扩展文件大小。
SETATTR is not guaranteed atomic. A failed SETATTR may partially change a file's attributes -- hence, the reason why the reply always includes the status and the list of attributes that were set.
SETATTR不保证是原子的。失败的SETATTR可能会部分更改文件的属性——因此，回复总是包括已设置的状态和属性列表的原因。
If the object whose attributes are being changed has a file delegation that is held by a client other than the one doing the SETATTR, the delegation(s) must be recalled, and the operation cannot proceed to actually change an attribute until each such delegation is returned or revoked. In all cases in which delegations are recalled, the server is likely to return one or more NFS4ERR_DELAY errors while the delegation(s) remains outstanding, although it might not do that if the delegations are returned quickly.
如果属性正在更改的对象具有由执行SETATTR的客户机以外的客户机持有的文件委派，则必须调用委派，并且在返回或撤销每个此类委派之前，操作无法继续实际更改属性。在调用委托的所有情况下，服务器都可能返回一个或多个NFS4ERR_延迟错误，而委托仍然未完成，但如果快速返回委托，则可能不会返回。
Changing the size of a file with SETATTR indirectly changes the time_modify and change attributes. A client must account for this, as size changes can result in data deletion.
使用SETATTR更改文件大小会间接更改修改和更改属性的时间。客户机必须对此负责，因为大小更改可能导致数据删除。
The attributes time_access_set and time_modify_set are write-only attributes constructed as a switched union so the client can direct the server in setting the time values. If the switched union specifies SET_TO_CLIENT_TIME4, the client has provided an nfstime4 to be used for the operation. If the switch union does not specify SET_TO_CLIENT_TIME4, the server is to use its current time for the SETATTR operation.
属性time_access_set和time_modify_set是构造为交换联合的仅写属性，因此客户端可以指导服务器设置时间值。如果交换的联合指定SET_TO_CLIENT_TIME4，则客户端已提供用于该操作的nfstime4。如果交换机联合未指定SET_TO_CLIENT_TIME4，则服务器将使用其当前时间执行SETATTR操作。
If server and client times differ, programs that compare client times to file times can break. A time maintenance protocol should be used to limit client/server time skew.
如果服务器和客户端时间不同，则将客户端时间与文件时间进行比较的程序可能会中断。应该使用时间维护协议来限制客户机/服务器的时间偏差。
Use of a COMPOUND containing a VERIFY operation specifying only the change attribute, immediately followed by a SETATTR, provides a means whereby a client may specify a request that emulates the functionality of the SETATTR guard mechanism of NFSv3. Since the function of the guard mechanism is to avoid changes to the file attributes based on stale information, delays between checking of the guard condition and the setting of the attributes have the potential to compromise this function, as would the corresponding delay in the NFSv4 emulation. Therefore, NFSv4 servers should take care to avoid such delays, to the degree possible, when executing such a request.
使用包含仅指定更改属性的验证操作的复合，紧接着是SETATTR，这提供了一种方法，客户机可以通过该方法指定模拟NFSv3的SETATTR保护机制功能的请求。由于保护机制的功能是避免基于过时信息对文件属性进行更改，因此检查保护条件和设置属性之间的延迟可能会影响此功能，NFSv4仿真中的相应延迟也可能会影响此功能。因此，在执行这样的请求时，NFSv4服务器应尽可能避免此类延迟。
If the server does not support an attribute as requested by the client, the server should return NFS4ERR_ATTRNOTSUPP.
如果服务器不支持客户端请求的属性，则服务器应返回NFS4ERR_ATTRNOTSUPP。
A mask of the attributes actually set is returned by SETATTR in all cases. That mask MUST NOT include attribute bits not requested to be set by the client. If the attribute masks in the request and reply are equal, the status field in the reply MUST be NFS4_OK.
在所有情况下，SETATTR都会返回实际设置的属性的掩码。该掩码不得包含客户端未请求设置的属性位。如果请求和回复中的属性掩码相等，则回复中的状态字段必须为NFS4_OK。
client, callback, callback_ident -> clientid, setclientid_confirm
客户端，回调，回调识别->客户端ID，设置客户端ID\u确认
struct SETCLIENTID4args {
nfs_client_id4 client;
cb_client4 callback;
uint32_t callback_ident;
};
struct SETCLIENTID4args {
nfs_client_id4 client;
cb_client4 callback;
uint32_t callback_ident;
};
struct SETCLIENTID4resok {
clientid4 clientid;
verifier4 setclientid_confirm;
};
struct SETCLIENTID4resok {
clientid4 clientid;
verifier4 setclientid_confirm;
};
union SETCLIENTID4res switch (nfsstat4 status) {
case NFS4_OK:
SETCLIENTID4resok resok4;
case NFS4ERR_CLID_INUSE:
clientaddr4 client_using;
default:
void;
};
union SETCLIENTID4res switch (nfsstat4 status) {
case NFS4_OK:
SETCLIENTID4resok resok4;
case NFS4ERR_CLID_INUSE:
clientaddr4 client_using;
default:
void;
};
The client uses the SETCLIENTID operation to notify the server of its intention to use a particular client identifier, callback, and callback_ident for subsequent requests that entail creating lock, share reservation, and delegation state on the server. Upon successful completion the server will return a shorthand client ID that, if confirmed via a separate step, will be used in subsequent file locking and file open requests. Confirmation of the client ID must be done via the SETCLIENTID_CONFIRM operation to return the client ID and setclientid_confirm values, as verifiers, to the server. Two verifiers are necessary because it is possible to use SETCLIENTID and SETCLIENTID_CONFIRM to modify the callback and callback_ident information but not the shorthand client ID. In that event, the setclientid_confirm value is effectively the only verifier.
客户端使用SETCLIENTID操作通知服务器，它打算为后续请求使用特定的客户端标识符、回调和回调标识，这些请求需要在服务器上创建锁、共享保留和委派状态。成功完成后，服务器将返回一个速记客户端ID，如果通过单独的步骤确认，该ID将用于后续的文件锁定和文件打开请求。必须通过SETCLIENTID_确认操作确认客户端ID，以将客户端ID和SETCLIENTID_确认值作为验证器返回到服务器。需要两个验证器，因为可以使用SETCLIENTID和SETCLIENTID_确认来修改回调和回调标识信息，但不能修改速记客户端ID。在这种情况下，SETCLIENTID_确认值实际上是唯一的验证器。
The callback information provided in this operation will be used if the client is provided an open delegation at a future point. Therefore, the client must correctly reflect the program and port numbers for the callback program at the time SETCLIENTID is used.
如果在将来某个时间点向客户端提供了开放委托，则将使用此操作中提供的回调信息。因此，在使用SETCLIENTID时，客户端必须正确反映回调程序的程序和端口号。
The callback_ident value is used by the server on the callback. The client can leverage the callback_ident to eliminate the need for more than one callback RPC program number, while still being able to determine which server is initiating the callback.
服务器在回调上使用回调_ident值。客户端可以利用回调标识消除对多个回调RPC程序号的需要，同时仍然能够确定哪个服务器正在启动回调。
To understand how to implement SETCLIENTID, make the following notations. Let:
要了解如何实现SETCLIENTID，请使用以下符号。让我们：
x be the value of the client.id subfield of the SETCLIENTID4args structure.
x是SetClientIDArgs结构的client.id子字段的值。
v be the value of the client.verifier subfield of the SETCLIENTID4args structure.
v是SetClientIDArgs结构的client.verifier子字段的值。
c be the value of the client ID field returned in the SETCLIENTID4resok structure.
c是SetClientIDResok结构中返回的客户端ID字段的值。
k represent the value combination of the callback and callback_ident fields of the SETCLIENTID4args structure.
k表示SetClientIDArgs结构的回调和回调标识字段的值组合。
s be the setclientid_confirm value returned in the SETCLIENTID4resok structure.
s是setclientid\u确认值，该值在SetClientD4Resok结构中返回。
{ v, x, c, k, s } be a quintuple for a client record. A client record is confirmed if there has been a SETCLIENTID_CONFIRM operation to confirm it. Otherwise, it is unconfirmed. An unconfirmed record is established by a SETCLIENTID call.
{v，x，c，k，s}对于客户端记录来说是五元组。如果已通过SETCLIENTID_确认操作对客户端记录进行确认，则会确认客户端记录。否则，这是未确认的。通过SETCLIENTID调用建立未确认的记录。
Since SETCLIENTID is a non-idempotent operation, let us assume that the server is implementing the duplicate request cache (DRC).
由于SETCLIENTID是一个非幂等操作，因此让我们假设服务器正在实现重复请求缓存（DRC）。
When the server gets a SETCLIENTID { v, x, k } request, it processes it in the following manner.
当服务器收到SETCLIENTID{v，x，k}请求时，它将按照以下方式处理它。
o It first looks up the request in the DRC. If there is a hit, it returns the result cached in the DRC. The server does NOT remove client state (locks, shares, delegations), nor does it modify any recorded callback and callback_ident information for client { x }.
o 它首先在DRC中查找请求。如果有命中，它将返回缓存在DRC中的结果。服务器不会删除客户端状态（锁、共享、委派），也不会修改客户端{x}的任何记录的回调和回调标识信息。
For any DRC miss, the server takes the client ID string x, and searches for client records for x that the server may have recorded from previous SETCLIENTID calls. For any confirmed record with the same id string x, if the recorded principal does not match that of the SETCLIENTID call, then the server returns an NFS4ERR_CLID_INUSE error.
对于任何DRC未命中，服务器将获取客户端ID字符串x，并搜索服务器可能已从以前的SETCLIENTID调用中记录的x的客户端记录。对于具有相同id字符串x的任何已确认记录，如果记录的主体与SETCLIENTID调用的主体不匹配，则服务器返回NFS4ERR_CLID_INUSE错误。
For brevity of discussion, the remaining description of the processing assumes that there was a DRC miss, and that where the server has previously recorded a confirmed record for client x, the aforementioned principal check has successfully passed.
为了便于讨论，处理的其余描述假定存在DRC未命中，并且服务器先前已为客户端x记录了确认的记录，上述主体检查已成功通过。
o The server checks if it has recorded a confirmed record for { v, x, c, l, s }, where l may or may not equal k. If so, and since the id verifier v of the request matches that which is confirmed and recorded, the server treats this as a probable callback information update and records an unconfirmed { v, x, c, k, t } and leaves the confirmed { v, x, c, l, s } in place, such that t != s. It does not matter whether k equals l or not. Any pre-existing unconfirmed { v, x, c, *, * } is removed.
o 服务器检查它是否记录了{v，x，c，l，s}的确认记录，其中l可能等于或不等于k。如果是，并且由于请求的id验证器v与确认和记录的id验证器v匹配，服务器将此视为可能的回调信息更新，并记录未确认的{v，x，c，k，t}，并将确认的{v，x，c，l，s}保留在适当的位置，使得t！=sk是否等于l并不重要。任何预先存在的未确认{v，x，c，*，*}将被删除。
The server returns { c, t }. It is indeed returning the old clientid4 value c, because the client apparently only wants to update callback value k to value l. It's possible this request is one from the Byzantine router that has stale callback information, but this is not a problem. The callback information update is only confirmed if followed up by a SETCLIENTID_CONFIRM { c, t }.
服务器返回{c，t}。它确实返回了旧的client4值c，因为客户端显然只想将回调值k更新为值l。这个请求可能来自拜占庭路由器，它有过时的回调信息，但这不是问题。回调信息更新仅在随后是SETCLIENTID_CONFIRM{c，t}时确认。
The server awaits confirmation of k via SETCLIENTID_CONFIRM { c, t }.
服务器通过SETCLIENTID_CONFIRM{c，t}等待k的确认。
The server does NOT remove client (lock/share/delegation) state for x.
服务器未删除x的客户端（锁定/共享/委派）状态。
o The server has previously recorded a confirmed { u, x, c, l, s } record such that v != u, l may or may not equal k, and has not recorded any unconfirmed { *, x, *, *, * } record for x. The server records an unconfirmed { v, x, d, k, t } (d != c, t != s).
o 服务器以前记录了一个已确认的{u，x，c，l，s}记录，因此v！=u、 l可能等于或不等于k，并且没有记录x的任何未经确认的{*，x，*，*，*}记录。服务器记录一个未确认的{v，x，d，k，t}（d！=c，t！=s）。
The server returns { d, t }.
服务器返回{d，t}。
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM { d, t }.
服务器等待通过SETCLIENTID_CONFIRM{d，t}确认{d，k}。
The server does NOT remove client (lock/share/delegation) state for x.
服务器未删除x的客户端（锁定/共享/委派）状态。
o The server has previously recorded a confirmed { u, x, c, l, s } record such that v != u, l may or may not equal k, and recorded an unconfirmed { w, x, d, m, t } record such that c != d, t != s, m may or may not equal k, m may or may not equal l, and k may or may not equal l. Whether w == v or w != v makes no difference. The server simply removes the unconfirmed { w, x, d, m, t } record and replaces it with an unconfirmed { v, x, e, k, r } record, such that e != d, e != c, r != t, r != s.
o 服务器以前记录了一个已确认的{u，x，c，l，s}记录，因此v！=u、 l可以等于k，也可以不等于k，并且记录了一个未确认的{w，x，d，m，t}记录，使得c！=d、 t！=s、 m可以等于或不等于k，m可以等于或不等于l，k可以等于或不等于l。无论w==v还是w！=v没有区别。服务器只是删除未确认的{w，x，d，m，t}记录，并将其替换为未确认的{v，x，e，k，r}记录，这样e！=d、 e！=c、 r！=t、 r！=s
The server returns { e, r }.
服务器返回{e，r}。
The server awaits confirmation of { e, k } via SETCLIENTID_CONFIRM { e, r }.
服务器等待通过SETCLIENTID_CONFIRM{e，r}确认{e，k}。
The server does NOT remove client (lock/share/delegation) state for x.
服务器未删除x的客户端（锁定/共享/委派）状态。
o The server has no confirmed { *, x, *, *, * } for x. It may or may not have recorded an unconfirmed { u, x, c, l, s }, where l may or may not equal k, and u may or may not equal v. Any unconfirmed record { u, x, c, l, * }, regardless of whether u == v or l == k, is replaced with an unconfirmed record { v, x, d, k, t } where d != c, t != s.
o 服务器没有确认x的{*，x，*，*，*，*}。它可能记录了也可能没有记录了一个未确认的{u，x，c，l，s}，其中l可能等于或不等于k，u可能等于或不等于v。任何未确认记录{u，x，c，l，*}，无论u==v还是l==k，都将替换为未确认记录{v，x，d，k，t}，其中d！=c、 t！=s
The server returns { d, t }.
服务器返回{d，t}。
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM { d, t }. The server does NOT remove client (lock/share/ delegation) state for x.
服务器等待通过SETCLIENTID_CONFIRM{d，t}确认{d，k}。服务器未删除x的客户端（锁定/共享/委派）状态。
The server generates the clientid and setclientid_confirm values and must take care to ensure that these values are extremely unlikely to ever be regenerated.
服务器生成clientid和setclientid_确认值，并且必须注意确保这些值不太可能重新生成。
clientid, setclientid_confirm -> -
clientid, setclientid_confirm -> -
struct SETCLIENTID_CONFIRM4args {
clientid4 clientid;
verifier4 setclientid_confirm;
};
struct SETCLIENTID_CONFIRM4args {
clientid4 clientid;
verifier4 setclientid_confirm;
};
struct SETCLIENTID_CONFIRM4res {
nfsstat4 status;
};
struct SETCLIENTID_CONFIRM4res {
nfsstat4 status;
};
This operation is used by the client to confirm the results from a previous call to SETCLIENTID. The client provides the server-supplied (from a SETCLIENTID response) client ID. The server responds with a simple status of success or failure.
客户端使用此操作确认以前调用SETCLIENTID的结果。客户端提供服务器提供的（来自SETCLIENTID响应）客户端ID。服务器以简单的成功或失败状态进行响应。
The client must use the SETCLIENTID_CONFIRM operation to confirm the following two distinct cases:
客户端必须使用SETCLIENTID_确认操作来确认以下两种不同情况：
o The client's use of a new shorthand client identifier (as returned from the server in the response to SETCLIENTID), a new callback value (as specified in the arguments to SETCLIENTID), and a new callback_ident value (as specified in the arguments to SETCLIENTID). The client's use of SETCLIENTID_CONFIRM in this case also confirms the removal of any of the client's previous relevant leased state. Relevant leased client state includes byte-range locks, share reservations, and -- where the server does not support the CLAIM_DELEGATE_PREV claim type -- delegations. If the server supports CLAIM_DELEGATE_PREV, then SETCLIENTID_CONFIRM MUST NOT remove delegations for this client; relevant leased client state would then just include byte-range locks and share reservations.
o 客户端使用新的速记客户端标识符（在响应SETCLIENTID时从服务器返回）、新的回调值（在SETCLIENTID的参数中指定）和新的回调识别值（在SETCLIENTID的参数中指定）。在这种情况下，客户使用SETCLIENTID_CONFIRM也确认删除了客户以前的任何相关租赁状态。相关的租用客户端状态包括字节范围锁、共享保留，以及——如果服务器不支持CLAIM_DELEGATE_PREV CLAIM类型——委托。如果服务器支持CLAIM_DELEGATE_PREV，则SETCLIENTID_CONFIRM不能删除此客户端的委托；然后，相关的租用客户机状态将只包括字节范围锁和共享保留。
o The client's reuse of an old, previously confirmed shorthand client identifier; a new callback value; and a new callback_ident value. The client's use of SETCLIENTID_CONFIRM in this case MUST NOT result in the removal of any previous leased state (locks, share reservations, and delegations).
o 客户重复使用以前确认的旧速记客户标识符；一个新的回调值；和一个新的回调识别值。在这种情况下，客户使用SETCLIENTID_CONFIRM不得导致删除任何以前的租赁状态（锁、共享保留和委托）。
We use the same notation and definitions for v, x, c, k, s, and unconfirmed and confirmed client records as introduced in the description of the SETCLIENTID operation. The arguments to SETCLIENTID_CONFIRM are indicated by the notation { c, s }, where c is a value of type clientid4, and s is a value of type verifier4 corresponding to the setclientid_confirm field.
我们对v、x、c、k、s以及未确认和已确认的客户端记录使用与SETCLIENTID操作描述中介绍的相同的符号和定义。SETCLIENTID_CONFIRM的参数由符号{c，s}表示，其中c是clientd4类型的值，s是对应于SETCLIENTID_CONFIRM字段的verifier4类型的值。
As with SETCLIENTID, SETCLIENTID_CONFIRM is a non-idempotent operation, and we assume that the server is implementing the duplicate request cache (DRC).
与SETCLIENTID一样，SETCLIENTID_CONFIRM是一个非幂等操作，我们假设服务器正在实现重复请求缓存（DRC）。
When the server gets a SETCLIENTID_CONFIRM { c, s } request, it processes it in the following manner.
当服务器收到SETCLIENTID_CONFIRM{c，s}请求时，它将按照以下方式处理它。
o It first looks up the request in the DRC. If there is a hit, it returns the result cached in the DRC. The server does not remove any relevant leased client state, nor does it modify any recorded callback and callback_ident information for client { x } as represented by the shorthand value c.
o 它首先在DRC中查找请求。如果有命中，它将返回缓存在DRC中的结果。服务器不会删除任何相关的租用客户端状态，也不会修改由速记值c表示的客户端{x}的任何记录的回调和回调标识信息。
For a DRC miss, the server checks for client records that match the shorthand value c. The processing cases are as follows:
对于DRC未命中，服务器将检查与速记值c匹配的客户端记录。处理个案如下：
o The server has recorded an unconfirmed { v, x, c, k, s } record and a confirmed { v, x, c, l, t } record, such that s != t. If the principals of the records do not match that of the SETCLIENTID_CONFIRM, the server returns NFS4ERR_CLID_INUSE, and no relevant leased client state is removed and no recorded callback and callback_ident information for client { x } is changed. Otherwise, the confirmed { v, x, c, l, t } record is removed and the unconfirmed { v, x, c, k, s } is marked as confirmed, thereby modifying recorded and confirmed callback and callback_ident information for client { x }.
o 服务器已记录未确认的{v，x，c，k，s}记录和已确认的{v，x，c，l，t}记录，因此s！=T如果记录的主体与SETCLIENTID_CONFIRM的主体不匹配，服务器将返回NFS4ERR_CLID_INUSE，并且不会删除任何相关的租用客户端状态，也不会更改客户端{x}的已记录回调和回调标识信息。否则，将删除已确认的{v，x，c，l，t}记录，并将未确认的{v，x，c，k，s}标记为已确认，从而修改客户端{x}的已记录和已确认的回调和回调标识信息。
The server does not remove any relevant leased client state.
服务器不会删除任何相关的已租用客户端状态。
The server returns NFS4_OK.
服务器返回NFS4\u OK。
o The server has not recorded an unconfirmed { v, x, c, *, * } and has recorded a confirmed { v, x, c, *, s }. If the principals of the record and of SETCLIENTID_CONFIRM do not match, the server returns NFS4ERR_CLID_INUSE without removing any relevant leased client state, and without changing recorded callback and callback_ident values for client { x }.
o 服务器未记录未确认的{v，x，c，*，*}，但已记录已确认的{v，x，c，*，s}。如果记录和SETCLIENTID_确认的主体不匹配，服务器将返回NFS4ERR_CLID_INUSE，而不删除任何相关的租用客户端状态，也不更改客户端{x}的已记录回调和回调标识值。
If the principals match, then what has likely happened is that the client never got the response from the SETCLIENTID_CONFIRM, and the DRC entry has been purged. Whatever the scenario, since the principals match, as well as { c, s } matching a confirmed record, the server leaves client x's relevant leased client state intact, leaves its callback and callback_ident values unmodified, and returns NFS4_OK.
如果主体匹配，那么可能发生的情况是客户端从未收到来自SETCLIENTID\u确认的响应，并且DRC条目已被清除。无论在何种情况下，由于主体匹配，以及{c，s}匹配确认的记录，服务器保持客户端x的相关租用客户端状态不变，保持其回调和回调标识值不变，并返回NFS4_OK。
o The server has not recorded a confirmed { *, *, c, *, * } and has recorded an unconfirmed { *, x, c, k, s }. Even if this is a retry from the client, nonetheless the client's first SETCLIENTID_CONFIRM attempt was not received by the server. Retry or not, the server doesn't know, but it processes it as if it were a first try. If the principal of the unconfirmed { *, x, c, k, s } record mismatches that of the SETCLIENTID_CONFIRM request, the server returns NFS4ERR_CLID_INUSE without removing any relevant leased client state.
o 服务器尚未记录已确认的{*，*，c，*，*}，并且已记录未确认的{*，x，c，k，s}。即使这是来自客户端的重试，但服务器未收到客户端的第一次SETCLIENTID_确认尝试。不管是否重试，服务器都不知道，但它会像第一次尝试一样进行处理。如果未确认的{*，x，c，k，s}记录的主体与SETCLIENTID_确认请求的主体不匹配，服务器将返回NFS4ERR_CLID_INUSE，而不删除任何相关的租用客户端状态。
Otherwise, the server records a confirmed { *, x, c, k, s }. If there is also a confirmed { *, x, d, *, t }, the server MUST remove client x's relevant leased client state and overwrite the callback state with k. The confirmed record { *, x, d, *, t } is removed.
否则，服务器将记录一个已确认的{*，x，c，k，s}。如果还有一个已确认的{*，x，d，*，t}，则服务器必须删除客户机x的相关租用客户机状态，并用k覆盖回调状态。已确认的记录{*，x，d，*，t}被删除。
The server returns NFS4_OK.
服务器返回NFS4\u OK。
o The server has no record of a confirmed or unconfirmed { *, *, c, *, s }. The server returns NFS4ERR_STALE_CLIENTID. The server does not remove any relevant leased client state, nor does it modify any recorded callback and callback_ident information for any client.
o 服务器没有已确认或未确认{*，*，c，*，s}的记录。服务器返回NFS4ERR\u STALE\u CLIENTID。服务器不会删除任何相关的租用客户端状态，也不会修改任何客户端记录的回调和回调标识信息。
The server needs to cache unconfirmed { v, x, c, k, s } client records and await for some time their confirmation. As should be clear from the discussions of record processing for SETCLIENTID and SETCLIENTID_CONFIRM, there are cases where the server does not deterministically remove unconfirmed client records. To avoid running out of resources, the server is not required to hold unconfirmed records indefinitely. One strategy the server might use is to set a limit on how many unconfirmed client records it will maintain and then, when the limit would be exceeded, remove the
服务器需要缓存未确认的{v，x，c，k，s}客户端记录，并等待它们的确认一段时间。从SETCLIENTID和SETCLIENTID_CONFIRM的记录处理讨论中可以清楚地看到，在某些情况下，服务器无法确定地删除未确认的客户端记录。为了避免资源耗尽，服务器不需要无限期地保存未确认的记录。服务器可能使用的一种策略是设置其将维护的未确认客户端记录的数量限制，然后在超过该限制时，删除
oldest record. Another strategy might be to remove an unconfirmed record when some amount of time has elapsed. The choice of the amount of time is fairly arbitrary, but it is surely no higher than the server's lease time period. Consider that leases need to be renewed before the lease time expires via an operation from the client. If the client cannot issue a SETCLIENTID_CONFIRM after a SETCLIENTID before a period of time equal to a lease expiration time, then the client is unlikely to be able to maintain state on the server during steady-state operation.
最古老的记录。另一种策略可能是在经过一定时间后删除未确认的记录。时间量的选择相当随意，但肯定不会高于服务器的租用时间。考虑租约在租赁时间到期后通过客户的操作进行更新。如果客户机无法在与租约到期时间相等的时间段之前发出SETCLIENTID之后的SETCLIENTID\u确认，则客户机不太可能在稳态操作期间保持服务器上的状态。
If the client does send a SETCLIENTID_CONFIRM for an unconfirmed record that the server has already deleted, the client will get NFS4ERR_STALE_CLIENTID back. If so, the client should then start over, and send SETCLIENTID to re-establish an unconfirmed client record and get back an unconfirmed client ID and setclientid_confirm verifier. The client should then send the SETCLIENTID_CONFIRM to confirm the client ID.
如果客户端确实为服务器已删除的未确认记录发送SETCLIENTID\u确认，则客户端将返回NFS4ERR\u STALE\u CLIENTID。如果是这样，客户端应该重新开始，并发送SETCLIENTID以重新建立未确认的客户端记录，并获取未确认的客户端ID和SETCLIENTID\u确认验证器。然后，客户端应发送SETCLIENTID\u确认以确认客户端ID。
SETCLIENTID_CONFIRM does not establish or renew a lease. However, if SETCLIENTID_CONFIRM removes relevant leased client state, and that state does not include existing delegations, the server MUST allow the client a period of time no less than the value of the lease_time attribute, to reclaim (via the CLAIM_DELEGATE_PREV claim type of the OPEN operation) its delegations before removing unreclaimed delegations.
SETCLIENTID_CONFIRM不会建立或续订租约。但是，如果SETCLIENTID\u CONFIRM删除了相关的租用客户端状态，并且该状态不包括现有的委托，则服务器必须允许客户端有一段不小于lease\u time属性值的时间来回收（通过打开操作的CLAIM\u DELEGATE\u PREV CLAIM类型）在取消未申报的代表团之前，应先取消其代表团。
(cfh), fattr -> -
(cfh), fattr -> -
struct VERIFY4args {
/* CURRENT_FH: object */
fattr4 obj_attributes;
};
struct VERIFY4args {
/* CURRENT_FH: object */
fattr4 obj_attributes;
};
struct VERIFY4res {
nfsstat4 status;
};
struct VERIFY4res {
nfsstat4 status;
};
The VERIFY operation is used to verify that attributes have a value assumed by the client before proceeding with subsequent operations in the COMPOUND request. If any of the attributes do not match, then the error NFS4ERR_NOT_SAME must be returned. The current filehandle retains its value after successful completion of the operation.
VERIFY操作用于在继续复合请求中的后续操作之前验证属性是否具有客户端假定的值。如果任何属性不匹配，则必须返回错误NFS4ERR_not_SAME。成功完成操作后，当前文件句柄将保留其值。
One possible use of the VERIFY operation is the following COMPOUND sequence. With this, the client is attempting to verify that the file being removed will match what the client expects to be removed. This sequence can help prevent the unintended deletion of a file.
验证操作的一个可能用途是以下复合序列。这样，客户端将尝试验证要删除的文件是否与客户端希望删除的文件匹配。此顺序有助于防止意外删除文件。
PUTFH (directory filehandle) LOOKUP (filename) VERIFY (filehandle == fh) PUTFH (directory filehandle) REMOVE (filename)
PUTFH（目录文件句柄）查找（文件名）验证（文件句柄==fh）PUTFH（目录文件句柄）删除（文件名）
This sequence does not prevent a second client from removing and creating a new file in the middle of this sequence, but it does help avoid the unintended result.
这个序列不会阻止第二个客户端在这个序列中间移除和创建一个新文件，但是它确实有助于避免意外的结果。
In the case that a RECOMMENDED attribute is specified in the VERIFY operation and the server does not support that attribute for the file system object, the error NFS4ERR_ATTRNOTSUPP is returned to the client.
如果在验证操作中指定了推荐的属性，并且服务器不支持文件系统对象的该属性，则会将错误NFS4ERR_ATTRNOTSUPP返回给客户端。
When the attribute rdattr_error or any write-only attribute (e.g., time_modify_set) is specified, the error NFS4ERR_INVAL is returned to the client.
当指定属性rdattr_error或任何只写属性（例如，time_modify_set）时，错误NFS4ERR_INVAL将返回给客户端。
(cfh), stateid, offset, stable, data -> count, committed, writeverf
（cfh）、stateid、偏移量、稳定、数据->计数、已提交、已写入
enum stable_how4 {
UNSTABLE4 = 0,
DATA_SYNC4 = 1,
FILE_SYNC4 = 2
};
enum stable_how4 {
UNSTABLE4 = 0,
DATA_SYNC4 = 1,
FILE_SYNC4 = 2
};
struct WRITE4args {
/* CURRENT_FH: file */
stateid4 stateid;
offset4 offset;
stable_how4 stable;
opaque data<>;
};
struct WRITE4args {
/* CURRENT_FH: file */
stateid4 stateid;
offset4 offset;
stable_how4 stable;
opaque data<>;
};
struct WRITE4resok {
count4 count;
stable_how4 committed;
verifier4 writeverf;
};
struct WRITE4resok {
count4 count;
stable_how4 committed;
verifier4 writeverf;
};
union WRITE4res switch (nfsstat4 status) {
case NFS4_OK:
WRITE4resok resok4;
default:
void;
};
union WRITE4res switch (nfsstat4 status) {
case NFS4_OK:
WRITE4resok resok4;
default:
void;
};
The WRITE operation is used to write data to a regular file. The target file is specified by the current filehandle. The offset specifies the offset where the data should be written. An offset of 0 (zero) specifies that the write should start at the beginning of the file. The count, as encoded as part of the opaque data parameter, represents the number of bytes of data that are to be written. If the count is 0 (zero), the WRITE will succeed and return a count of 0 (zero) subject to permissions checking. The server may choose to write fewer bytes than requested by the client.
写入操作用于将数据写入常规文件。目标文件由当前文件句柄指定。偏移量指定写入数据的偏移量。偏移量为0（零）指定写入应从文件的开头开始。作为不透明数据参数的一部分编码的计数表示要写入的数据字节数。如果计数为0（零），则写入将成功，并返回0（零）的计数，然后进行权限检查。服务器可以选择写入的字节数少于客户端请求的字节数。
Part of the WRITE request is a specification of how the WRITE is to be performed. The client specifies with the stable parameter the method of how the data is to be processed by the server. If stable is FILE_SYNC4, the server must commit the data written plus all file system metadata to stable storage before returning results. This corresponds to the NFSv2 protocol semantics. Any other behavior constitutes a protocol violation. If stable is DATA_SYNC4, then the server must commit all of the data to stable storage and enough of the metadata to retrieve the data before returning. The server implementer is free to implement DATA_SYNC4 in the same fashion as FILE_SYNC4, but with a possible performance drop. If stable is UNSTABLE4, the server is free to commit any part of the data and the metadata to stable storage, including all or none, before returning a reply to the client. There is no guarantee whether or when any uncommitted data will subsequently be committed to stable storage. The only guarantees made by the server are that it will not destroy any data without changing the value of verf and that it will not commit the data and metadata at a level less than that requested by the client.
写入请求的一部分是如何执行写入的规范。客户机使用stable参数指定服务器如何处理数据的方法。如果stable是FILE_SYNC4，则服务器必须在返回结果之前将写入的数据加上所有文件系统元数据提交到stable存储。这与NFSv2协议语义相对应。任何其他行为都构成违反协议。如果stable是DATA_SYNC4，则服务器必须将所有数据提交到稳定存储，并在返回之前提交足够的元数据以检索数据。服务器实现者可以自由地以与文件同步4相同的方式实现数据同步4，但可能会导致性能下降。如果stable是不稳定的4，则服务器可以自由地将数据和元数据的任何部分提交到稳定存储，包括全部或全部，然后再向客户端返回回复。无法保证任何未提交的数据随后是否或何时提交到稳定存储。服务器所做的唯一保证是在不更改verf值的情况下不会销毁任何数据，并且不会以低于客户端请求的级别提交数据和元数据。
The stateid value for a WRITE request represents a value returned from a previous byte-range lock or share reservation request or the stateid associated with a delegation. The stateid is used by the server to verify that the associated share reservation and any byte-range locks are still valid and to update lease timeouts for the client.
写入请求的stateid值表示从以前的字节范围锁定或共享保留请求返回的值，或与委派关联的stateid。服务器使用stateid验证关联的共享保留和任何字节范围锁是否仍然有效，并更新客户端的租约超时。
Upon successful completion, the following results are returned. 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 number of bytes written starting at location, offset, is returned.
成功完成后，返回以下结果。计数结果是写入文件的数据字节数。服务器写入的字节数可能少于请求的字节数。如果是，则返回从位置offset开始写入的实际字节数。
The server also returns an indication of the level of commitment of the data and metadata via committed. If the server committed all data and metadata to stable storage, committed should be set to FILE_SYNC4. If the level of commitment was at least as strong as DATA_SYNC4, then committed should be set to DATA_SYNC4. Otherwise, committed must be returned as UNSTABLE4. If stable was FILE4_SYNC, then committed must also be FILE_SYNC4: anything else constitutes a protocol violation. If stable was DATA_SYNC4, then committed may be FILE_SYNC4 or DATA_SYNC4: anything else constitutes a protocol violation. If stable was UNSTABLE4, then committed may be either FILE_SYNC4, DATA_SYNC4, or UNSTABLE4.
服务器还通过提交返回数据和元数据的提交级别指示。如果服务器将所有数据和元数据提交到稳定存储中，则应将提交设置为文件\u SYNC4。如果承诺级别至少与DATA_SYNC4相同，则应将committed设置为DATA_SYNC4。否则，committed必须作为UNSTABLE4返回。如果stable是FILE4\u SYNC，那么committed也必须是FILE\u SYNC4：任何其他内容都构成协议冲突。如果stable是DATA_SYNC4，那么提交的可能是FILE_SYNC4或DATA_SYNC4：任何其他内容都构成协议冲突。如果stable是UNSTABLE4，那么提交的可能是FILE\u SYNC4、DATA\u SYNC4或UNSTABLE4。
The final portion of the result is the write verifier. The write verifier is a cookie that the client can use to determine whether the server has changed instance (boot) state between a call to WRITE and a subsequent call to either WRITE or COMMIT. This cookie must be consistent during a single instance of the NFSv4 protocol service and must be unique between instances of the NFSv4 protocol server, where uncommitted data may be lost.
结果的最后一部分是写验证器。写入验证器是一个cookie，客户端可以使用它来确定服务器是否在调用write和后续调用write或COMMIT之间更改了实例（启动）状态。此cookie在NFSv4协议服务的单个实例期间必须一致，并且在NFSv4协议服务器的实例之间必须唯一，未提交的数据可能会丢失。
If a client writes data to the server with the stable argument set to UNSTABLE4 and the reply yields a committed response of DATA_SYNC4 or UNSTABLE4, the client will follow up at some time in the future with a COMMIT operation to synchronize outstanding asynchronous data and metadata with the server's stable storage, barring client error. It is possible that due to client crash or other error a subsequent COMMIT will not be received by the server.
如果客户端将stable参数设置为UNSTABLE4时将数据写入服务器，并且回复产生data_SYNC4或UNSTABLE4的提交响应，则客户端将在将来的某个时间执行提交操作，以将未完成的异步数据和元数据与服务器的稳定存储同步，从而避免客户端错误。由于客户端崩溃或其他错误，服务器可能无法接收后续提交。
For a WRITE using the special anonymous stateid, the server MAY allow the WRITE to be serviced subject to mandatory file locks or the current share deny modes for the file. For a WRITE using the special READ bypass stateid, the server MUST NOT allow the WRITE operation to bypass locking checks at the server, and the WRITE is treated exactly the same as if the anonymous stateid were used.
对于使用特殊匿名stateid的写操作，服务器可能允许根据文件的强制文件锁定或当前共享拒绝模式为写操作提供服务。对于使用特殊读取绕过stateid的写入操作，服务器不得允许写入操作绕过服务器上的锁定检查，并且写入操作的处理方式与使用匿名stateid时完全相同。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
It is possible for the server to write fewer bytes of data than requested by the client. In this case, the server should not return an error unless no data was written at all. If the server writes less than the number of bytes specified, the client should issue another WRITE to write the remaining data.
服务器写入的数据字节数可能少于客户端请求的字节数。在这种情况下，除非根本没有写入数据，否则服务器不应返回错误。如果服务器写入的字节数小于指定的字节数，则客户端应发出另一次写入操作以写入剩余的数据。
It is assumed that the act of writing data to a file will cause the time_modify attribute of the file to be updated. However, the time_modify attribute of the file should not be changed unless the contents of the file are changed. Thus, a WRITE request with count set to 0 should not cause the time_modify attribute of the file to be updated.
假设将数据写入文件的行为将导致文件的“修改时间”属性更新。但是，除非文件的内容发生更改，否则不应更改文件的“修改时间”属性。因此，计数设置为0的写入请求不应导致更新文件的time_modify属性。
The definition of stable storage has been historically a point of contention. The following expected properties of stable storage may help in resolving design issues in the implementation. Stable storage is persistent storage that survives:
稳定存储的定义历来是争论的焦点。稳定存储的以下预期属性可能有助于解决实现中的设计问题。稳定存储是一种持久性存储，可在以下情况下生存：
1. Repeated power failures.
1. 反复停电。
2. Hardware failures (of any board, power supply, etc.).
2. 硬件故障（任何板、电源等）。
3. Repeated software crashes, including reboot cycle.
3. 重复的软件崩溃，包括重新启动周期。
This definition does not address failure of the stable storage module itself.
此定义不解决稳定存储模块本身的故障。
The verifier is defined to allow a client to detect different instances of an NFSv4 protocol server over which cached, uncommitted data may be lost. In the most likely case, the verifier allows the client to detect server reboots. This information is required so that the client can safely determine whether the server could have lost cached data. If the server fails unexpectedly and the client has uncommitted data from previous WRITE requests (done with the stable argument set to UNSTABLE4 and in which the result committed was returned as UNSTABLE4 as well), it may not have flushed cached data to stable storage. The burden of recovery is on the client, and the client will need to retransmit the data to the server.
验证器被定义为允许客户端检测NFSv4协议服务器的不同实例，在该实例上缓存的未提交数据可能会丢失。在最可能的情况下，验证器允许客户端检测服务器重新启动。需要此信息，以便客户端可以安全地确定服务器是否可能丢失了缓存数据。如果服务器意外失败，并且客户端具有来自以前写入请求的未提交数据（在将stable参数设置为UNSTABLE4的情况下完成，并且提交的结果也返回为UNSTABLE4），则它可能没有将缓存数据刷新到稳定存储中。恢复的负担由客户端承担，客户端需要将数据重新传输到服务器。
One suggested way to use the verifier would be to use the time that the server was booted or the time the server was last started (if restarting the server without a reboot results in lost buffers).
建议使用验证器的一种方法是使用服务器启动的时间或服务器上次启动的时间（如果在没有重新启动的情况下重新启动服务器会导致缓冲区丢失）。
The committed field in the results allows the client to do more effective caching. If the server is committing all WRITE requests to stable storage, then it should return with committed set to FILE_SYNC4, regardless of the value of the stable field in the arguments. A server that uses an NVRAM accelerator may choose to implement this policy. The client can use this to increase the effectiveness of the cache by discarding cached data that has already been committed on the server.
结果中的提交字段允许客户端执行更有效的缓存。如果服务器正在将所有写请求提交到稳定存储，则无论参数中稳定字段的值是多少，它都应返回并将提交集设置为FILE_SYNC4。使用NVRAM加速器的服务器可以选择实施此策略。客户机可以通过丢弃已在服务器上提交的缓存数据来提高缓存的有效性。
Some implementations may return NFS4ERR_NOSPC instead of NFS4ERR_DQUOT when a user's quota is exceeded. In the case that the current filehandle is a directory, the server will return NFS4ERR_ISDIR. If the current filehandle is not a regular file or a directory, the server will return NFS4ERR_INVAL.
当超过用户配额时，某些实现可能返回NFS4ERR_NOSPC而不是NFS4ERR_DQUOT。如果当前文件句柄是目录，服务器将返回NFS4ERR_ISDIR。如果当前文件句柄不是常规文件或目录，服务器将返回NFS4ERR_INVAL。
If mandatory file locking is on for the file, and a corresponding record of the data to be written to file is read or write locked by an owner that is not associated with the stateid, the server will return NFS4ERR_LOCKED. If so, the client must check if the owner corresponding to the stateid used with the WRITE operation has a conflicting read lock that overlaps with the region that was to be written. If the stateid's owner has no conflicting read lock, then the client should try to get the appropriate write byte-range lock via the LOCK operation before re-attempting the WRITE. When the WRITE completes, the client should release the byte-range lock via LOCKU.
如果文件的强制文件锁定处于启用状态，并且要写入文件的数据的相应记录由与stateid不关联的所有者进行读写锁定，则服务器将返回NFS4ERR_locked。如果是这样，客户端必须检查与写入操作使用的stateid对应的所有者是否具有与要写入的区域重叠的冲突读取锁。如果stateid的所有者没有冲突的读锁，则客户端应在重新尝试写入之前，通过锁定操作尝试获取适当的写入字节范围锁。写入完成后，客户端应通过LOCKU释放字节范围锁。
If the stateid's owner had a conflicting read lock, then the client has no choice but to return an error to the application that attempted the WRITE. The reason is that since the stateid's owner had a read lock, the server either (1) attempted to temporarily effectively upgrade this read lock to a write lock or (2) has no upgrade capability. If the server attempted to upgrade the read lock and failed, it is pointless for the client to re-attempt the upgrade via the LOCK operation, because there might be another client also trying to upgrade. If two clients are blocked trying to upgrade the same lock, the clients deadlock. If the server has no upgrade capability, then it is pointless to try a LOCK operation to upgrade.
如果stateid的所有者具有冲突的读锁，则客户端别无选择，只能向尝试写入的应用程序返回错误。原因是由于stateid的所有者有一个读锁，服务器（1）试图临时有效地将该读锁升级为写锁，或者（2）没有升级功能。如果服务器尝试升级读锁但失败，则客户端通过锁定操作重新尝试升级是毫无意义的，因为可能还有另一个客户端也在尝试升级。如果两个客户端在升级同一个锁时被阻止，则客户端会死锁。如果服务器没有升级功能，那么尝试锁定操作进行升级是毫无意义的。
lock-owner -> ()
锁所有者->（）
struct RELEASE_LOCKOWNER4args {
lock_owner4 lock_owner;
};
struct RELEASE_LOCKOWNER4args {
lock_owner4 lock_owner;
};
struct RELEASE_LOCKOWNER4res {
nfsstat4 status;
};
struct RELEASE_LOCKOWNER4res {
nfsstat4 status;
};
This operation is used to notify the server that the lock_owner is no longer in use by the client and that future client requests will not reference this lock_owner. This allows the server to release cached state related to the specified lock_owner. If file locks associated with the lock_owner are held at the server, the error NFS4ERR_LOCKS_HELD will be returned and no further action will be taken.
此操作用于通知服务器客户端不再使用锁所有者，并且将来的客户端请求将不会引用此锁所有者。这允许服务器释放与指定锁所有者相关的缓存状态。如果与锁所有者关联的文件锁保存在服务器上，则会返回错误NFS4ERR\U locks\U HOLDED，并且不会采取进一步的操作。
The client may choose to use this operation to ease the amount of server state that is held. Information that can be released when a RELEASE_LOCKOWNER is done includes the specified lock-owner string, the seqid associated with the lock-owner, any saved reply for the lock-owner, and any lock stateids associated with that lock-owner.
客户端可以选择使用此操作来减轻服务器状态的保留量。释放锁定所有者时可以释放的信息包括指定的锁定所有者字符串、与锁定所有者关联的seqid、为锁定所有者保存的任何回复以及与该锁定所有者关联的任何锁定状态ID。
Depending on the behavior of applications at the client, it may be important for the client to use this operation since the server has certain obligations with respect to holding a reference to lock-owner-associated state as long as an associated file is open. Therefore, if the client knows for certain that the lock_owner will no longer be used to either reference existing lock stateids associated with the lock-owner or create new ones, it should use RELEASE_LOCKOWNER.
根据客户机上应用程序的行为，客户机使用此操作可能很重要，因为只要相关文件处于打开状态，服务器就有义务保持对锁所有者相关状态的引用。因此，如果客户端确实知道锁所有者将不再用于引用与锁所有者关联的现有锁stateID或创建新的锁stateID，则应使用RELEASE\u LOCKOWNER。
<null> -> ()
<null> -> ()
void;
无效的
struct ILLEGAL4res {
nfsstat4 status;
};
struct ILLEGAL4res {
nfsstat4 status;
};
This operation is a placeholder for encoding a result to handle the case of the client sending an operation code within COMPOUND that is not supported. See Section 15.2.4 for more details.
此操作是一个占位符，用于对结果进行编码，以处理客户端在不支持的复合内发送操作代码的情况。详见第15.2.4节。
The status field of ILLEGAL4res MUST be set to NFS4ERR_OP_ILLEGAL.
ILLEGAL4res的状态字段必须设置为NFS4ERR_OP_非法。
A client will probably not send an operation with code OP_ILLEGAL, but if it does, the response will be ILLEGAL4res, just as it would be with any other invalid operation code. Note that if the server gets an illegal operation code that is not OP_ILLEGAL, and if the server checks for legal operation codes during the XDR decode phase, then the ILLEGAL4res would not be returned.
客户端可能不会发送代码为OP_非法的操作，但如果发送，响应将是非法4res，就像发送任何其他无效操作代码一样。请注意，如果服务器获取的非法操作代码不是OP_非法的，并且如果服务器在XDR解码阶段检查合法操作代码，则不会返回非法4res。
The procedures used for callbacks are defined in the following sections. In the interest of clarity, the terms "client" and "server" refer to NFS clients and servers, despite the fact that for an individual callback RPC, the sense of these terms would be precisely the opposite.
用于回调的过程在以下部分中定义。为了清楚起见，术语“客户机”和“服务器”指的是NFS客户机和服务器，尽管对于单个回调RPC，这些术语的含义正好相反。
<null>
<null>
void;
无效的
void;
无效的
Standard NULL procedure. Void argument, void response. Even though there is no direct functionality associated with this procedure, the server will use CB_NULL to confirm the existence of a path for RPCs from server to client.
标准的空过程。无效的论点，无效的回应。即使没有与此过程相关联的直接功能，服务器也将使用CB_NULL来确认存在从服务器到客户端的RPC路径。
compoundargs -> compoundres
合成标记->合成标记
enum nfs_cb_opnum4 {
OP_CB_GETATTR = 3,
OP_CB_RECALL = 4,
OP_CB_ILLEGAL = 10044
};
enum nfs_cb_opnum4 {
OP_CB_GETATTR = 3,
OP_CB_RECALL = 4,
OP_CB_ILLEGAL = 10044
};
union nfs_cb_argop4 switch (unsigned argop) {
case OP_CB_GETATTR:
CB_GETATTR4args opcbgetattr;
case OP_CB_RECALL:
CB_RECALL4args opcbrecall;
case OP_CB_ILLEGAL: void;
};
union nfs_cb_argop4 switch (unsigned argop) {
case OP_CB_GETATTR:
CB_GETATTR4args opcbgetattr;
case OP_CB_RECALL:
CB_RECALL4args opcbrecall;
case OP_CB_ILLEGAL: void;
};
struct CB_COMPOUND4args {
utf8str_cs tag;
uint32_t minorversion;
uint32_t callback_ident;
nfs_cb_argop4 argarray<>;
};
struct CB_COMPOUND4args {
utf8str_cs tag;
uint32_t minorversion;
uint32_t callback_ident;
nfs_cb_argop4 argarray<>;
};
union nfs_cb_resop4 switch (unsigned resop) {
case OP_CB_GETATTR: CB_GETATTR4res opcbgetattr;
case OP_CB_RECALL: CB_RECALL4res opcbrecall;
case OP_CB_ILLEGAL: CB_ILLEGAL4res opcbillegal;
};
union nfs_cb_resop4 switch (unsigned resop) {
case OP_CB_GETATTR: CB_GETATTR4res opcbgetattr;
case OP_CB_RECALL: CB_RECALL4res opcbrecall;
case OP_CB_ILLEGAL: CB_ILLEGAL4res opcbillegal;
};
struct CB_COMPOUND4res {
nfsstat4 status;
utf8str_cs tag;
nfs_cb_resop4 resarray<>;
};
struct CB_COMPOUND4res {
nfsstat4 status;
utf8str_cs tag;
nfs_cb_resop4 resarray<>;
};
The CB_COMPOUND procedure is used to combine one or more of the callback procedures into a single RPC request. The main callback RPC program has two main procedures: CB_NULL and CB_COMPOUND. All other operations use the CB_COMPOUND procedure as a wrapper.
CB_复合过程用于将一个或多个回调过程组合到单个RPC请求中。主回调RPC程序有两个主要过程：CB_NULL和CB_component。所有其他操作都使用CB_复合过程作为包装。
In the processing of the CB_COMPOUND procedure, the client may find that it does not have the available resources to execute any or all of the operations within the CB_COMPOUND sequence. In this case, the error NFS4ERR_RESOURCE will be returned for the particular operation within the CB_COMPOUND procedure where the resource exhaustion occurred. This assumes that all previous operations within the CB_COMPOUND sequence have been evaluated successfully.
在CB_复合过程的处理过程中，客户端可能会发现它没有可用的资源来执行CB_复合序列中的任何或所有操作。在这种情况下，对于发生资源耗尽的CB_复合过程中的特定操作，将返回错误NFS4ERR_资源。这假设CB_复合序列中的所有先前操作都已成功评估。
Contained within the CB_COMPOUND results is a status field. This status must be equivalent to the status of the last operation that was executed within the CB_COMPOUND procedure. Therefore, if an operation incurred an error, then the status value will be the same error value as is being returned for the operation that failed.
CB_复合结果中包含一个状态字段。此状态必须与CB_复合过程中执行的最后一个操作的状态相同。因此，如果操作发生错误，则状态值将与为失败的操作返回的错误值相同。
For the definition of the tag field, see Section 15.2.
有关标记字段的定义，请参见第15.2节。
The value of callback_ident is supplied by the client during SETCLIENTID. The server must use the client-supplied callback_ident during the CB_COMPOUND to allow the client to properly identify the server.
callback_ident的值由客户端在SETCLIENTID期间提供。在CB_复合期间，服务器必须使用客户端提供的回调_ident，以允许客户端正确标识服务器。
Illegal operation codes are handled in the same way as they are handled for the COMPOUND procedure.
非法操作代码的处理方式与复合程序的处理方式相同。
The CB_COMPOUND procedure is used to combine individual operations into a single RPC request. The client interprets each of the 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 CB_COMPOUND procedure is executed. The client continues this process until there are no more operations to be executed or one of the operations has a status value other than NFS4_OK.
CB_复合过程用于将单个操作合并到单个RPC请求中。客户机依次解释每个操作。如果客户端执行一个操作，并且该操作的状态为NFS4_OK，则执行CB_复合过程中的下一个操作。客户端将继续此过程，直到不再执行任何操作，或者其中一个操作的状态值不是NFS4_OK。
fh, attr_request -> attrmask, attr_vals
fh，属性请求->属性掩码，属性值
struct CB_GETATTR4args {
nfs_fh4 fh;
bitmap4 attr_request;
};
struct CB_GETATTR4args {
nfs_fh4 fh;
bitmap4 attr_request;
};
struct CB_GETATTR4resok {
fattr4 obj_attributes;
};
struct CB_GETATTR4resok {
fattr4 obj_attributes;
};
union CB_GETATTR4res switch (nfsstat4 status) {
case NFS4_OK:
CB_GETATTR4resok resok4;
default:
void;
};
union CB_GETATTR4res switch (nfsstat4 status) {
case NFS4_OK:
CB_GETATTR4resok resok4;
default:
void;
};
The CB_GETATTR operation is used by the server to obtain the current modified state of a file that has been OPEN_DELEGATE_WRITE delegated. The size attribute and the change attribute are the only ones guaranteed to be serviced by the client. See Section 10.4.3 for a full description of how the client and server are to interact with the use of CB_GETATTR.
服务器使用CB_GETATTR操作获取已打开的文件的当前修改状态。size属性和change属性是唯一保证由客户机提供服务的属性。有关客户端和服务器如何与CB_GETATTR的使用交互的完整描述，请参见第10.4.3节。
If the filehandle specified is not one for which the client holds an OPEN_DELEGATE_WRITE delegation, an NFS4ERR_BADHANDLE error is returned.
如果指定的filehandle不是客户端持有OPEN_DELEGATE_WRITE委派的文件句柄，则返回NFS4ERR_BADHANDLE错误。
The client returns attrmask bits and the associated attribute values only for the change attribute, and attributes that it may change (time_modify and size).
客户机仅为更改属性和可能更改的属性（时间和大小）返回属性掩码位和相关属性值。
stateid, truncate, fh -> ()
stateid，截断，fh->（）
struct CB_RECALL4args {
stateid4 stateid;
bool truncate;
nfs_fh4 fh;
};
struct CB_RECALL4args {
stateid4 stateid;
bool truncate;
nfs_fh4 fh;
};
struct CB_RECALL4res {
nfsstat4 status;
};
struct CB_RECALL4res {
nfsstat4 status;
};
The CB_RECALL operation is used to begin the process of recalling an open delegation and returning it to the server.
CB_回调操作用于开始回调打开的委托并将其返回到服务器的过程。
The truncate flag is used to optimize a recall for a file that is about to be truncated to zero. When it is set, the client is freed of obligation to propagate modified data for the file to the server, since this data is irrelevant.
truncate标志用于优化即将被截断为零的文件的调用。设置后，客户机无需将修改后的文件数据传播到服务器，因为这些数据是无关的。
If the handle specified is not one for which the client holds an open delegation, an NFS4ERR_BADHANDLE error is returned.
如果指定的句柄不是客户端持有开放委托的句柄，则返回NFS4ERR_BADHANDLE错误。
If the stateid specified is not one corresponding to an open delegation for the file specified by the filehandle, an NFS4ERR_BAD_STATEID is returned.
如果指定的stateid不是与filehandle指定的文件的开放委派相对应的stateid，则返回NFS4ERR_BAD_stateid。
The client should reply to the callback immediately. Replying does not complete the recall, except when an error was returned. The recall is not complete until the delegation is returned using a DELEGRETURN.
客户端应该立即回复回调。回复不会完成调用，除非返回错误。只有使用DELEGRETURN返回委托，召回才算完成。
<null> -> ()
<null> -> ()
void;
无效的
/*
* CB_ILLEGAL: Response for illegal operation numbers
*/
struct CB_ILLEGAL4res {
nfsstat4 status;
};
/*
* CB_ILLEGAL: Response for illegal operation numbers
*/
struct CB_ILLEGAL4res {
nfsstat4 status;
};
This operation is a placeholder for encoding a result to handle the case of the client sending an operation code within COMPOUND that is not supported. See Section 15.2.4 for more details.
此操作是一个占位符，用于对结果进行编码，以处理客户端在不支持的复合内发送操作代码的情况。详见第15.2.4节。
The status field of CB_ILLEGAL4res MUST be set to NFS4ERR_OP_ILLEGAL.
CB_ILLEGAL4res的状态字段必须设置为NFS4ERR_OP_ILLEGAL。
A server will probably not send an operation with code OP_CB_ILLEGAL, but if it does, the response will be CB_ILLEGAL4res, just as it would be with any other invalid operation code. Note that if the client gets an illegal operation code that is not OP_ILLEGAL, and if the client checks for legal operation codes during the XDR decode phase, then the CB_ILLEGAL4res would not be returned.
服务器可能不会发送代码为OP_CB_非法的操作，但如果发送，响应将是CB_非法4res，就像发送任何其他无效操作代码一样。请注意，如果客户端获得的非法操作代码不是OP_非法，并且如果客户端在XDR解码阶段检查合法操作代码，则不会返回CB_非法4res。
NFS has historically used a model where, from an authentication perspective, the client was the entire machine, or at least the source IP address of the machine. The NFS server relied on the NFS client to make the proper authentication of the end-user. The NFS server in turn shared its files only to specific clients, as identified by the client's source IP address. Given this model, the AUTH_SYS RPC security flavor simply identified the end-user using the client to the NFS server. When processing NFS responses, the client ensured that the responses came from the same IP address and port number that the request was sent to. While such a model is easy to implement and simple to deploy and use, it is certainly not a safe model. Thus, NFSv4 mandates that implementations support a security model that uses end-to-end authentication, where an end-user on a client mutually authenticates (via cryptographic schemes that do not expose passwords or keys in the clear on the network) to a principal on an NFS server. Consideration should also be given to the integrity and privacy of NFS requests and responses. The issues of end-to-end mutual authentication, integrity, and privacy are discussed as part of Section 3.
从身份验证的角度来看，NFS历史上使用的模型中，客户端是整个机器，或者至少是机器的源IP地址。NFS服务器依赖NFS客户端对最终用户进行正确的身份验证。NFS服务器反过来只将其文件共享给特定的客户端，由客户端的源IP地址标识。考虑到这个模型，AUTH_SYS RPC安全特性只识别使用NFS服务器客户端的最终用户。在处理NFS响应时，客户端确保响应来自发送请求的相同IP地址和端口号。虽然这样的模型易于实现、部署和使用简单，但它肯定不是一个安全的模型。因此，NFSv4要求实现支持使用端到端身份验证的安全模型，其中客户端上的最终用户向NFS服务器上的主体进行相互身份验证（通过不公开网络上清除的密码或密钥的加密方案）。还应考虑NFS请求和响应的完整性和隐私性。第3节讨论了端到端相互认证、完整性和隐私问题。
When an NFSv4 mandated security model is used and a security principal or an NFSv4 name in user@dns_domain form needs to be translated to or from a local representation as described in Section 5.9, the translation SHOULD be done in a secure manner that preserves the integrity of the translation. For communication with a name service such as the Lightweight Directory Access Protocol (LDAP) ([RFC4511]), this means employing a security service that uses authentication and data integrity. Kerberos and Transport Layer Security (TLS) ([RFC5246]) are examples of such a security service.
当使用NFSv4强制安全模型且在user@dns_domain如第5.9节所述，表格需要翻译成本地代表或从本地代表处翻译过来，翻译应以安全的方式进行，以保持翻译的完整性。对于与名称服务（如轻量级目录访问协议（LDAP）（[RFC4511]）的通信，这意味着使用使用身份验证和数据完整性的安全服务。Kerberos和传输层安全性（TLS）（[RFC5246]）就是此类安全服务的示例。
Note that being REQUIRED to implement does not mean REQUIRED to use; AUTH_SYS can be used by NFSv4 clients and servers. However, AUTH_SYS is merely an OPTIONAL security flavor in NFSv4, and so interoperability via AUTH_SYS is not assured.
注意，需要实施并不意味着需要使用；NFSv4客户端和服务器可以使用AUTH_SYS。然而，AUTH_SYS只是NFSv4中可选的安全特性，因此无法保证通过AUTH_SYS的互操作性。
For reasons of reduced administration overhead, better performance, and/or reduction of CPU utilization, users of NFSv4 implementations may choose to not use security mechanisms that enable integrity protection on each remote procedure call and response. The use of mechanisms without integrity leaves the customer vulnerable to an attacker in between the NFS client and server that modifies the RPC request and/or the response. While implementations are free to provide the option to use weaker security mechanisms, there are two operations in particular that warrant the implementation overriding user choices.
出于减少管理开销、提高性能和/或降低CPU利用率的原因，NFSv4实现的用户可以选择不使用在每个远程过程调用和响应上启用完整性保护的安全机制。使用没有完整性的机制会使客户容易受到NFS客户端和服务器之间的攻击者的攻击，从而修改RPC请求和/或响应。虽然实现可以自由地提供使用较弱安全机制的选项，但有两种操作特别保证实现覆盖用户选择。
The first such operation is SECINFO. It is recommended that the client issue the SECINFO call such that it is protected with a security flavor that has integrity protection, such as RPCSEC_GSS with a security triple that uses either rpc_gss_svc_integrity or rpc_gss_svc_privacy (rpc_gss_svc_privacy includes integrity protection) service. Without integrity protection encapsulating SECINFO and therefore its results, an attacker in the middle could modify results such that the client might select a weaker algorithm in the set allowed by the server, making the client and/or server vulnerable to further attacks.
第一个这样的操作是SECINFO。建议客户端发出SECINFO调用，以便使用具有完整性保护的安全特性对其进行保护，例如使用rpc_GSS_svc_完整性或rpc_GSS_svc_隐私（rpc_GSS_svc_隐私包括完整性保护）服务的RPCSEC_GSS。如果没有完整性保护封装SECIFO，因此其结果，中间的攻击者可以修改结果，使得客户端可以在服务器允许的集合中选择较弱的算法，使得客户端和/或服务器容易受到进一步攻击。
The second operation that SHOULD use integrity protection is any GETATTR for the fs_locations attribute. The attack has two steps. First, the attacker modifies the unprotected results of some operation to return NFS4ERR_MOVED. Second, when the client follows up with a GETATTR for the fs_locations attribute, the attacker modifies the results to cause the client to migrate its traffic to a server controlled by the attacker.
第二个应该使用完整性保护的操作是fs_locations属性的任何GETATTR。攻击分为两个步骤。首先，攻击者修改某些操作的未受保护结果以返回NFS4ERR_MOVED。其次，当客户机使用fs_locations属性的GETATTR进行后续操作时，攻击者会修改结果，使客户机将其流量迁移到由攻击者控制的服务器。
Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are responsible for the release of client state, it is imperative that the principal used for these operations is checked against and matches with the previous use of these operations. See Section 9.1.1 for further discussion.
由于SETCLIENTID/SETCLIENTID_CONFIRM操作负责释放客户端状态，因此必须检查用于这些操作的主体，并与以前使用的这些操作进行匹配。进一步讨论见第9.1.1节。
Unicode in the form of UTF-8 is used for file component names (i.e., both directory and file components), as well as the owner and owner_group attributes; other character sets may also be allowed for file component names. String processing (e.g., Unicode normalization) raises security concerns for string comparison. See Sections 5.9 and 12 for further discussion, and see [RFC6943] for related identifier comparison security considerations. File component names are identifiers with respect to the identifier comparison discussion in [RFC6943] because they are used to identify the objects to which ACLs are applied; see Section 6.
UTF-8形式的Unicode用于文件组件名称（即目录和文件组件），以及所有者和所有者组属性；文件组件名称也可以使用其他字符集。字符串处理（例如Unicode规范化）会引起字符串比较的安全问题。有关进一步讨论，请参见第5.9节和第12节，有关标识符比较安全注意事项，请参见[RFC6943]。文件组件名称是[RFC6943]中关于标识符比较讨论的标识符，因为它们用于标识应用ACL的对象；见第6节。
This section uses terms that are defined in [RFC5226].
本节使用[RFC5226]中定义的术语。
IANA has created a registry called the "NFSv4 Named Attribute Definitions Registry" for [RFC3530] and [RFC5661]. This section introduces no new changes, but it does recap the intent.
IANA为[RFC3530]和[RFC5661]创建了一个名为“NFSv4命名属性定义注册表”的注册表。本节不介绍任何新的更改，但它会重述其意图。
The NFSv4 protocol supports the association of a file with zero or more named attributes. The namespace identifiers for these attributes are defined as string names. The protocol does not define the specific assignment of the namespace for these file attributes. The IANA registry promotes interoperability where common interests exist. While application developers are allowed to define and use attributes as needed, they are encouraged to register the attributes with IANA.
NFSv4协议支持文件与零个或多个命名属性的关联。这些属性的命名空间标识符定义为字符串名称。协议没有为这些文件属性定义命名空间的特定分配。IANA注册中心在存在共同利益的地方促进互操作性。虽然允许应用程序开发人员根据需要定义和使用属性，但鼓励他们向IANA注册属性。
Such registered named attributes are presumed to apply to all minor versions of NFSv4, including those defined subsequently to the registration. Where the named attribute is intended to be limited with regard to the minor versions for which they are not to be used, the assignment in the registry will clearly state the applicable limits.
此类注册的命名属性假定适用于NFSv4的所有次要版本，包括注册后定义的版本。如果指定属性旨在限制不使用的次要版本，则注册表中的分配将明确说明适用的限制。
The registry is to be maintained using the Specification Required policy as defined in Section 4.1 of [RFC5226].
使用[RFC5226]第4.1节中定义的规范要求策略维护注册表。
Under the NFSv4 specification, the name of a named attribute can in theory be up to 2^32 - 1 bytes in length, but in practice NFSv4 clients and servers will be unable to handle a string that long. IANA should reject any assignment request with a named attribute that exceeds 128 UTF-8 characters. To give the IESG the flexibility to set up bases of assignment of Experimental Use and Standards Action, the prefixes of "EXPE" and "STDS" are Reserved. The zero-length named attribute name is Reserved.
在NFSv4规范下，命名属性的名称在理论上可以达到2^32-1字节的长度，但在实践中，NFSv4客户端和服务器将无法处理这么长的字符串。IANA应拒绝任何命名属性超过128个UTF-8字符的分配请求。为了使IESG能够灵活地建立实验使用和标准行动的分配基础，保留了“EXPE”和“std”的前缀。名为属性名的零长度是保留的。
The prefix "PRIV" is allocated for Private Use. A site that wants to make use of unregistered named attributes without risk of conflicting with an assignment in IANA's registry should use the prefix "PRIV" in all of its named attributes.
前缀“PRIV”分配给私人使用。如果站点希望使用未注册的命名属性，而不存在与IANA注册中心的分配冲突的风险，则应在其所有命名属性中使用前缀“PRIV”。
Because some NFSv4 clients and servers have case-insensitive semantics, the fifteen additional lowercase and mixed-case permutations of each of "EXPE", "PRIV", and "STDS" are Reserved (e.g., "expe", "expE", "exPe", etc. are Reserved). Similarly, IANA must not allow two assignments that would conflict if both named attributes were converted to a common case.
由于某些NFSv4客户端和服务器具有不区分大小写的语义，因此保留了“EXPE”、“PRIV”和“std”的15个额外的小写和混合大小写排列（例如，“EXPE”、“EXPE”、“EXPE”等）。类似地，如果两个命名属性都转换为公共案例，IANA不得允许两个分配发生冲突。
The registry of named attributes is a list of assignments, each containing three fields for each assignment.
命名属性的注册表是一个分配列表，每个分配包含三个字段。
1. A US-ASCII string name that is the actual name of the attribute. This name must be unique. This string name can be 1 to 128 UTF-8 characters long.
1. 作为属性实际名称的US-ASCII字符串名称。此名称必须是唯一的。此字符串名称的长度可以是1到128个UTF-8字符。
2. A reference to the specification of the named attribute. The reference can consume up to 256 bytes (or more, if IANA permits).
2. 对命名属性规范的引用。引用最多可以消耗256个字节（如果IANA允许，可以消耗更多字节）。
3. The point of contact of the registrant. The point of contact can consume up to 256 bytes (or more, if IANA permits).
3. 注册人的联系人。接触点最多可以消耗256个字节（如果IANA允许，可以更多）。
There is no initial registry.
没有初始注册表。
The registrant is always permitted to update the point of contact field. To make any other change will require Expert Review or IESG Approval.
注册人始终被允许更新联系人字段。进行任何其他变更都需要专家审查或IESG批准。
In addition, because this document obsoletes RFC 3530, IANA has
此外，由于本文件淘汰了RFC 3530，IANA
o replaced all references to RFC 3530 in the Network Identifier (r_netid) registry with references to this document.
o 将网络标识符（r_netid）注册表中对RFC 3530的所有引用替换为对本文档的引用。
o replaced the reference to the nfs registration's reference to RFC 3530 in the GSSAPI/Kerberos/SASL Service names registry with a reference to this document.
o 将GSSAPI/Kerberos/SASL服务名称注册表中nfs注册对RFC 3530的引用替换为对本文档的引用。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997, <http://www.rfc-editor.org/info/rfc2203>.
[RFC2203]Eisler，M.，Chiu，A.，和L.Ling，“RPCSEC_GSS协议规范”，RFC 2203，1997年9月<http://www.rfc-editor.org/info/rfc2203>.
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月<http://www.rfc-editor.org/info/rfc2743>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003, <http://www.rfc-editor.org/info/rfc3490>.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月<http://www.rfc-editor.org/info/rfc3490>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003, <http://www.rfc-editor.org/info/rfc3492>.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月<http://www.rfc-editor.org/info/rfc3492>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February 2009, <http://www.rfc-editor.org/info/rfc5403>.
[RFC5403]Eisler，M.“RPCSEC_GSS版本2”，RFC 5403，2009年2月<http://www.rfc-editor.org/info/rfc5403>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5531]Thurlow，R.，“RPC:远程过程调用协议规范版本2”，RFC 55312009年5月<http://www.rfc-editor.org/info/rfc5531>.
[RFC5665] Eisler, M., "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats", RFC 5665, January 2010, <http://www.rfc-editor.org/info/rfc5665>.
[RFC5665]Eisler，M.“远程过程调用（RPC）网络标识符和通用地址格式的IANA注意事项”，RFC 5665，2010年1月<http://www.rfc-editor.org/info/rfc5665>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月<http://www.rfc-editor.org/info/rfc5891>.
[RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos", BCP 179, RFC 6649, July 2012, <http://www.rfc-editor.org/info/rfc6649>.
[RFC6649]Hornquist Astrand，L.和T.Yu，“反对Kerberos中的DES、RC4-HMAC-EXP和其他弱加密算法”，BCP 179，RFC 6649，2012年7月<http://www.rfc-editor.org/info/rfc6649>.
[RFC7531] Haynes, T., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description", RFC 7531, March 2015, <http://www.rfc-editor.org/info/rfc7531>.
[RFC7531]Haynes，T.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）第4版外部数据表示标准（XDR）说明”，RFC 75312015年3月<http://www.rfc-editor.org/info/rfc7531>.
[SPECIALCASING] The Unicode Consortium, "SpecialCasing-7.0.0.txt", Unicode Character Database, March 2014, <http://www.unicode.org/ Public/UCD/latest/ucd/SpecialCasing.txt>.
[SPECIALCASING]Unicode联盟，“SPECIALCASING-7.0.0.txt”，Unicode字符数据库，2014年3月<http://www.unicode.org/ Public/UCD/latest/UCD/SpecialCasing.txt>。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 7.0.0", (Mountain View, CA: The Unicode Consortium, 2014 ISBN 978-1-936213-09-2), June 2014, <http://www.unicode.org/versions/latest/>.
[UNICODE]UNICODE联盟，“UNICODE标准，7.0.0版”，（加利福尼亚州山景城：UNICODE联盟，2014年ISBN 978-1-936213-09-2），2014年6月<http://www.unicode.org/versions/latest/>.
[openg_symlink] The Open Group, "Section 3.372 of Chapter 3 of Base Definitions of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[openg_symlink]开放集团，“开放集团基础规范第7期基础定义第3章第3.372节”，IEEE Std 1003.12013版（HTML版），ISBN 1937218287，2013年4月<http://www.opengroup.org/>.
[Chet] Juszczak, C., "Improving the Performance and Correctness of an NFS Server", USENIX Conference Proceedings, June 1990.
[Chet]Juszczak，C.，“改进NFS服务器的性能和正确性”，USENIX会议记录，1990年6月。
[Floyd] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking 2(2), pp. 122-136, April 1994.
[Floyd]Floyd，S.和V.Jacobson，“定期路由消息的同步”，IEEE/ACM网络事务2（2），第122-136页，1994年4月。
[IESG_ERRATA] IESG, "IESG Processing of RFC Errata for the IETF Stream", July 2008.
[IESG_勘误表]IESG，“IESG处理IETF流的RFC勘误表”，2008年7月。
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB) Protocol Specification", MS-SMB 43.0, May 2014.
[MS-SMB]微软公司，“服务器消息块（SMB）协议规范”，MS-SMB 43.0，2014年5月。
[P1003.1e] Institute of Electrical and Electronics Engineers, Inc., "IEEE Draft P1003.1e", 1997.
[P1003.1e]电气和电子工程师协会，“IEEE P1003.1e草案”，1997年。
[RFC1094] Nowicki, B., "NFS: Network File System Protocol specification", RFC 1094, March 1989, <http://www.rfc-editor.org/info/rfc1094>.
[RFC1094]Nowicki，B.，“NFS:网络文件系统协议规范”，RFC10941989年3月<http://www.rfc-editor.org/info/rfc1094>.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995, <http://www.rfc-editor.org/info/rfc1813>.
[RFC1813]Callaghan，B.，Pawlowski，B.，和P.Staubach，“NFS版本3协议规范”，RFC 1813，1995年6月<http://www.rfc-editor.org/info/rfc1813>.
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995, <http://www.rfc-editor.org/info/rfc1833>.
[RFC1833]Srinivasan，R.，“ONC RPC版本2的绑定协议”，RFC 1833，1995年8月<http://www.rfc-editor.org/info/rfc1833>.
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996, <http://www.rfc-editor.org/info/rfc2054>.
[RFC2054]Callaghan，B.，“WebNFS客户端规范”，RFC20541996年10月<http://www.rfc-editor.org/info/rfc2054>.
[RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055, October 1996, <http://www.rfc-editor.org/info/rfc2055>.
[RFC2055]Callaghan，B.，“WebNFS服务器规范”，RFC20551996年10月<http://www.rfc-editor.org/info/rfc2055>.
[RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997, <http://www.rfc-editor.org/info/rfc2224>.
[RFC2224]Callaghan，B.，“NFS URL方案”，RFC 22242997年10月<http://www.rfc-editor.org/info/rfc2224>.
[RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999, <http://www.rfc-editor.org/info/rfc2623>.
[RFC2623]Eisler，M.，“NFS版本2和版本3的安全问题以及NFS协议对RPCSEC_GSS和Kerberos V5的使用”，RFC 2623，1999年6月<http://www.rfc-editor.org/info/rfc2623>.
[RFC2624] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, June 1999, <http://www.rfc-editor.org/info/rfc2624>.
[RFC2624]Shepler，S.，“NFS版本4设计注意事项”，RFC 26242999年6月<http://www.rfc-editor.org/info/rfc2624>.
[RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation for WebNFS", RFC 2755, January 2000, <http://www.rfc-editor.org/info/rfc2755>.
[RFC2755]Chiu，A.，Eisler，M.，和B.Callaghan，“WebNFS的安全协商”，RFC 2755，2000年1月<http://www.rfc-editor.org/info/rfc2755>.
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000, <http://www.rfc-editor.org/info/rfc3010>.
[RFC3010]Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.，和D.Noveck，“NFS版本4协议”，RFC3010，2000年12月<http://www.rfc-editor.org/info/rfc3010>.
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002, <http://www.rfc-editor.org/info/rfc3232>.
[RFC3232]Reynolds，J.，Ed.，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月<http://www.rfc-editor.org/info/rfc3232>.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003, <http://www.rfc-editor.org/info/rfc3530>.
[RFC3530]Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.，和D.Noveck，“网络文件系统（NFS）版本4协议”，RFC3530，2003年4月<http://www.rfc-editor.org/info/rfc3530>.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005, <http://www.rfc-editor.org/info/rfc4121>.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 41212005年7月<http://www.rfc-editor.org/info/rfc4121>.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005, <http://www.rfc-editor.org/info/rfc4178>.
[RFC4178]Zhu，L.，Leach，P.，Jaganathan，K.，和W.Ingersoll，“简单和受保护的通用安全服务应用程序接口（GSS-API）协商机制”，RFC 4178，2005年10月<http://www.rfc-editor.org/info/rfc4178>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006, <http://www.rfc-editor.org/info/rfc4506>.
[RFC4506]艾斯勒，M.，编辑，“XDR：外部数据表示标准”，STD 67，RFC 4506，2006年5月<http://www.rfc-editor.org/info/rfc4506>.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006, <http://www.rfc-editor.org/info/rfc4511>.
[RFC4511]Sermersheim，J.，Ed.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年6月<http://www.rfc-editor.org/info/rfc4511>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010, <http://www.rfc-editor.org/info/rfc5661>.
[RFC5661]Shepler，S.，Ed.，Eisler，M.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1协议”，RFC 56612010年1月<http://www.rfc-editor.org/info/rfc5661>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011, <http://www.rfc-editor.org/info/rfc6365>.
[RFC6365]Hoffman，P.和J.Klensin，“IETF国际化中使用的术语”，BCP 166，RFC 63652011年9月<http://www.rfc-editor.org/info/rfc6365>.
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>.
[RFC6943]Thaler，D.，Ed.“出于安全目的的标识符比较问题”，RFC 69432013年5月<http://www.rfc-editor.org/info/rfc6943>.
[fcntl] The Open Group, "Section 'fcntl()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[fcntl]开放组，“开放组基本规范第7期系统接口的“fcntl（）”部分”，IEEE Std 1003.12013版（HTML版），ISBN 1937218287，2013年4月<http://www.opengroup.org/>.
[fsync] The Open Group, "Section 'fsync()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[fsync]开放组，“开放组基本规范第7期系统接口的'fsync（）'部分”，IEEE Std 1003.12013版（HTML版），ISBN 1937218287，2013年4月<http://www.opengroup.org/>.
[getpwnam] The Open Group, "Section 'getpwnam()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[getpwnam]开放组，“开放组基本规范第7期系统接口的“getpwnam（）”部分”，IEEE Std 1003.12013版（HTML版），ISBN 1937218287，2013年4月<http://www.opengroup.org/>.
[read_api] The Open Group, "Section 'read()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[read_api]开放组，“开放组基本规范第7期系统接口的“read（）”部分”，IEEE Std 1003.11913版（HTML版），ISBN 1937218287，2013年4月<http://www.opengroup.org/>.
[readdir_api] The Open Group, "Section 'readdir()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[readdir_api]开放组，“开放组基本规范第7版系统接口的'readdir（）'部分”，IEEE Std 1003.12013版（HTML版），ISBN 1937218287，2013年4月<http://www.opengroup.org/>.
[stat] The Open Group, "Section 'stat()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[stat]开放组，“开放组基本规范第7期系统接口“stat（）”部分”，IEEE Std 1003.12013版（HTML版），ISBN 1937218287，2013年4月<http://www.opengroup.org/>.
[unlink] The Open Group, "Section 'unlink()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[unlink]开放组，“开放组基本规范第7期系统接口的“unlink（）”部分”，IEEE Std 1003.11913版（HTML版），ISBN 1937218287，2013年4月<http://www.opengroup.org/>.
[write_api] The Open Group, "Section 'write()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[write_api]开放组，“开放组基本规范第7期系统接口的“write（）”部分”，IEEE Std 1003.12013版（HTML版），ISBN 1937218287，2013年4月<http://www.opengroup.org/>.
[xnfs] The Open Group, "Protocols for Interworking: XNFS, Version 3W, ISBN 1-85912-184-5", February 1998.
[xnfs]开放组，“互通协议：xnfs，3W版，ISBN 1-85912-184-5”，1998年2月。
Acknowledgments
致谢
A bis is certainly built on the shoulders of the first attempt. Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, Carl Beame, Mike Eisler, and David Noveck are responsible for a great deal of the effort in this work.
bis当然是建立在第一次尝试的基础上的。斯宾塞·谢普勒、布伦特·卡拉汉、大卫·罗宾逊、罗伯特·瑟洛、卡尔·比姆、迈克·艾斯勒和大卫·诺维克在这项工作中付出了巨大的努力。
Tom Haynes would like to thank NetApp, Inc. for its funding of his time on this project.
Tom Haynes感谢NetApp，Inc.为此项目提供资金。
Rob Thurlow clarified how a client should contact a new server if a migration has occurred.
Rob Thurlow阐明了如果发生迁移，客户端应如何联系新服务器。
David Black, Nico Williams, Mike Eisler, Trond Myklebust, James Lentini, and Mike Kupfer read many earlier draft versions of Section 12 and contributed numerous useful suggestions, without which the necessary revision of that section for this document would not have been possible.
David Black、Nico Williams、Mike Eisler、Trond Myklebust、James Lentini和Mike Kupfer阅读了第12节的许多早期草案版本，并提出了许多有用的建议，如果没有这些建议，本文件就不可能对该节进行必要的修订。
Peter Staubach read almost all of the earlier draft versions of Section 12, leading to the published result, and his numerous comments were always useful and contributed substantially to improving the quality of the final result.
Peter Staubach阅读了第12节的几乎所有早期草案版本，从而得出了公布的结果，他的许多评论总是有用的，并为提高最终结果的质量做出了重大贡献。
Peter Saint-Andre was gracious enough to read the most recent draft version of Section 12 and provided some key insight as to the concerns of the Internationalization community.
彼得·圣安德烈（Peter Saint Andre）很有礼貌地阅读了第12节的最新草案，并就国际化社区的担忧提供了一些关键见解。
James Lentini graciously read the rewrite of Section 8, and his comments were vital in improving the quality of that effort.
詹姆斯·兰提尼（James Lentini）优雅地阅读了第8节的重写，他的评论对于提高这项工作的质量至关重要。
Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond Myklebust were faithful attendants of the biweekly triage meeting and accepted many an action item.
Rob Thurlow、Sorin Faibish、James Lentini、Bruce Fields和Trond Myklebust是每两周一次的分流会议的忠实参与者，他们接受了许多行动项目。
Bruce Fields was a good sounding board for both the third edge condition and courtesy locks in general. He was also the leading advocate of stamping out backport issues from [RFC5661].
布鲁斯·菲尔兹在第三边缘条件和礼貌锁方面都是一个很好的传声筒。他也是[RFC5661]中消除后台问题的主要倡导者。
Marcel Telka was a champion of straightening out the difference between a lock-owner and an open-owner. He has also been diligent in reviewing the final document.
马塞尔·特尔卡（Marcel Telka）是一位理顺锁所有人和开放式所有人之间差异的倡导者。他还认真审查了最后文件。
Benjamin Kaduk reminded us that DES is dead, and Nico Williams helped us close the lid on the coffin.
本杰明·卡杜克提醒我们德斯已经死了，尼科·威廉姆斯帮我们盖上棺材盖。
Elwyn Davies provided a very thorough and engaging Gen-ART review; thanks!
Elwyn Davies提供了一份非常全面和引人入胜的Gen艺术评论；谢谢
Authors' Addresses
作者地址
Thomas Haynes (editor) Primary Data, Inc. 4300 El Camino Real Ste 100 Los Altos, CA 94022 United States
Thomas Haynes（编辑）Primary Data，Inc.4300 El Camino Real Ste 100 Los Altos，加利福尼亚州94022
Phone: +1 408 215 1519
EMail: thomas.haynes@primarydata.com
Phone: +1 408 215 1519
EMail: thomas.haynes@primarydata.com
David Noveck (editor) Dell 300 Innovative Way Nashua, NH 03062 United States
David Noveck（编辑）美国新罕布什尔州纳舒亚戴尔300创新之路03062
Phone: +1 781 572 8038
EMail: dave_noveck@dell.com
Phone: +1 781 572 8038
EMail: dave_noveck@dell.com