Internet Engineering Task Force (IETF) S. Shepler, Ed.
Request for Comments: 5661 Storspeed, Inc.
Category: Standards Track M. Eisler, Ed.
ISSN: 2070-1721 D. Noveck, Ed.
NetApp
January 2010
Internet Engineering Task Force (IETF) S. Shepler, Ed.
Request for Comments: 5661 Storspeed, Inc.
Category: Standards Track M. Eisler, Ed.
ISSN: 2070-1721 D. Noveck, Ed.
NetApp
January 2010
Network File System (NFS) Version 4 Minor Version 1 Protocol
网络文件系统（NFS）版本4次要版本1协议
Abstract
摘要
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server.
本文档介绍网络文件系统（NFS）版本4次要版本1，包括从基本协议（NFS版本4次要版本0，在RFC 3530中指定）保留的功能以及随后进行的协议扩展。NFS版本4次要版本1中引入的主要扩展包括会话、目录委派和并行NFS（pNFS）。NFS版本4次要版本1与NFS版本4次要版本0没有依赖关系，它被视为一个单独的协议。因此，本文件既不更新也不废弃RFC 3530。NFS次要版本1被视为优于NFS次要版本0，且不会丢失功能，并且其使用优于版本0。NFS次要版本0和1都可以在同一网络上、同一客户端和服务器之间同时使用。
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/rfc5661.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5661.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................9
1.1. The NFS Version 4 Minor Version 1 Protocol .................9
1.2. Requirements Language ......................................9
1.3. Scope of This Document .....................................9
1.4. NFSv4 Goals ...............................................10
1.5. NFSv4.1 Goals .............................................10
1.6. General Definitions .......................................11
1.7. Overview of NFSv4.1 Features ..............................13
1.8. Differences from NFSv4.0 ..................................17
2. Core Infrastructure ............................................18
2.1. Introduction ..............................................18
2.2. RPC and XDR ...............................................19
2.3. COMPOUND and CB_COMPOUND ..................................22
2.4. Client Identifiers and Client Owners ......................23
2.5. Server Owners .............................................28
2.6. Security Service Negotiation ..............................29
2.7. Minor Versioning ..........................................34
2.8. Non-RPC-Based Security Services ...........................37
2.9. Transport Layers ..........................................37
2.10. Session ..................................................40
3. Protocol Constants and Data Types ..............................86
3.1. Basic Constants ...........................................86
3.2. Basic Data Types ..........................................87
3.3. Structured Data Types .....................................89
4. Filehandles ....................................................97
4.1. Obtaining the First Filehandle ............................98
4.2. Filehandle Types ..........................................99
4.3. One Method of Constructing a Volatile Filehandle .........101
4.4. Client Recovery from Filehandle Expiration ...............102
5. File Attributes ...............................................103
5.1. REQUIRED Attributes ......................................104
5.2. RECOMMENDED Attributes ...................................104
5.3. Named Attributes .........................................105
5.4. Classification of Attributes .............................106
5.5. Set-Only and Get-Only Attributes .........................107
5.6. REQUIRED Attributes - List and Definition References .....107
5.7. RECOMMENDED Attributes - List and Definition References ..108
5.8. Attribute Definitions ....................................110
5.9. Interpreting owner and owner_group .......................119
5.10. Character Case Attributes ...............................121
5.11. Directory Notification Attributes .......................121
5.12. pNFS Attribute Definitions ..............................122
5.13. Retention Attributes ....................................123
6. Access Control Attributes .....................................126
6.1. Goals ....................................................126
6.2. File Attributes Discussion ...............................128
1. Introduction ....................................................9
1.1. The NFS Version 4 Minor Version 1 Protocol .................9
1.2. Requirements Language ......................................9
1.3. Scope of This Document .....................................9
1.4. NFSv4 Goals ...............................................10
1.5. NFSv4.1 Goals .............................................10
1.6. General Definitions .......................................11
1.7. Overview of NFSv4.1 Features ..............................13
1.8. Differences from NFSv4.0 ..................................17
2. Core Infrastructure ............................................18
2.1. Introduction ..............................................18
2.2. RPC and XDR ...............................................19
2.3. COMPOUND and CB_COMPOUND ..................................22
2.4. Client Identifiers and Client Owners ......................23
2.5. Server Owners .............................................28
2.6. Security Service Negotiation ..............................29
2.7. Minor Versioning ..........................................34
2.8. Non-RPC-Based Security Services ...........................37
2.9. Transport Layers ..........................................37
2.10. Session ..................................................40
3. Protocol Constants and Data Types ..............................86
3.1. Basic Constants ...........................................86
3.2. Basic Data Types ..........................................87
3.3. Structured Data Types .....................................89
4. Filehandles ....................................................97
4.1. Obtaining the First Filehandle ............................98
4.2. Filehandle Types ..........................................99
4.3. One Method of Constructing a Volatile Filehandle .........101
4.4. Client Recovery from Filehandle Expiration ...............102
5. File Attributes ...............................................103
5.1. REQUIRED Attributes ......................................104
5.2. RECOMMENDED Attributes ...................................104
5.3. Named Attributes .........................................105
5.4. Classification of Attributes .............................106
5.5. Set-Only and Get-Only Attributes .........................107
5.6. REQUIRED Attributes - List and Definition References .....107
5.7. RECOMMENDED Attributes - List and Definition References ..108
5.8. Attribute Definitions ....................................110
5.9. Interpreting owner and owner_group .......................119
5.10. Character Case Attributes ...............................121
5.11. Directory Notification Attributes .......................121
5.12. pNFS Attribute Definitions ..............................122
5.13. Retention Attributes ....................................123
6. Access Control Attributes .....................................126
6.1. Goals ....................................................126
6.2. File Attributes Discussion ...............................128
6.3. Common Methods ...........................................144
6.4. Requirements .............................................147
7. Single-Server Namespace .......................................153
7.1. Server Exports ...........................................153
7.2. Browsing Exports .........................................153
7.3. Server Pseudo File System ................................154
7.4. Multiple Roots ...........................................155
7.5. Filehandle Volatility ....................................155
7.6. Exported Root ............................................155
7.7. Mount Point Crossing .....................................156
7.8. Security Policy and Namespace Presentation ...............156
8. State Management ..............................................157
8.1. Client and Session ID ....................................158
8.2. Stateid Definition .......................................158
8.3. Lease Renewal ............................................167
8.4. Crash Recovery ...........................................170
8.5. Server Revocation of Locks ...............................181
8.6. Short and Long Leases ....................................182
8.7. Clocks, Propagation Delay, and Calculating Lease
Expiration ...............................................182
8.8. Obsolete Locking Infrastructure from NFSv4.0 .............183
9. File Locking and Share Reservations ...........................184
9.1. Opens and Byte-Range Locks ...............................184
9.2. Lock Ranges ..............................................188
9.3. Upgrading and Downgrading Locks ..........................188
9.4. Stateid Seqid Values and Byte-Range Locks ................189
9.5. Issues with Multiple Open-Owners .........................189
9.6. Blocking Locks ...........................................190
9.7. Share Reservations .......................................191
9.8. OPEN/CLOSE Operations ....................................192
9.9. Open Upgrade and Downgrade ...............................192
9.10. Parallel OPENs ..........................................193
9.11. Reclaim of Open and Byte-Range Locks ....................194
10. Client-Side Caching ..........................................194
10.1. Performance Challenges for Client-Side Caching ..........195
10.2. Delegation and Callbacks ................................196
10.3. Data Caching ............................................200
10.4. Open Delegation .........................................205
10.5. Data Caching and Revocation .............................216
10.6. Attribute Caching .......................................218
10.7. Data and Metadata Caching and Memory Mapped Files .......220
10.8. Name and Directory Caching without Directory
Delegations .............................................222
10.9. Directory Delegations ...................................225
11. Multi-Server Namespace .......................................228
11.1. Location Attributes .....................................228
11.2. File System Presence or Absence .........................229
11.3. Getting Attributes for an Absent File System ............230
6.3. Common Methods ...........................................144
6.4. Requirements .............................................147
7. Single-Server Namespace .......................................153
7.1. Server Exports ...........................................153
7.2. Browsing Exports .........................................153
7.3. Server Pseudo File System ................................154
7.4. Multiple Roots ...........................................155
7.5. Filehandle Volatility ....................................155
7.6. Exported Root ............................................155
7.7. Mount Point Crossing .....................................156
7.8. Security Policy and Namespace Presentation ...............156
8. State Management ..............................................157
8.1. Client and Session ID ....................................158
8.2. Stateid Definition .......................................158
8.3. Lease Renewal ............................................167
8.4. Crash Recovery ...........................................170
8.5. Server Revocation of Locks ...............................181
8.6. Short and Long Leases ....................................182
8.7. Clocks, Propagation Delay, and Calculating Lease
Expiration ...............................................182
8.8. Obsolete Locking Infrastructure from NFSv4.0 .............183
9. File Locking and Share Reservations ...........................184
9.1. Opens and Byte-Range Locks ...............................184
9.2. Lock Ranges ..............................................188
9.3. Upgrading and Downgrading Locks ..........................188
9.4. Stateid Seqid Values and Byte-Range Locks ................189
9.5. Issues with Multiple Open-Owners .........................189
9.6. Blocking Locks ...........................................190
9.7. Share Reservations .......................................191
9.8. OPEN/CLOSE Operations ....................................192
9.9. Open Upgrade and Downgrade ...............................192
9.10. Parallel OPENs ..........................................193
9.11. Reclaim of Open and Byte-Range Locks ....................194
10. Client-Side Caching ..........................................194
10.1. Performance Challenges for Client-Side Caching ..........195
10.2. Delegation and Callbacks ................................196
10.3. Data Caching ............................................200
10.4. Open Delegation .........................................205
10.5. Data Caching and Revocation .............................216
10.6. Attribute Caching .......................................218
10.7. Data and Metadata Caching and Memory Mapped Files .......220
10.8. Name and Directory Caching without Directory
Delegations .............................................222
10.9. Directory Delegations ...................................225
11. Multi-Server Namespace .......................................228
11.1. Location Attributes .....................................228
11.2. File System Presence or Absence .........................229
11.3. Getting Attributes for an Absent File System ............230
11.4. Uses of Location Information ............................232
11.5. Location Entries and Server Identity ....................236
11.6. Additional Client-Side Considerations ...................237
11.7. Effecting File System Transitions .......................238
11.8. Effecting File System Referrals .........................251
11.9. The Attribute fs_locations ..............................258
11.10. The Attribute fs_locations_info ........................261
11.11. The Attribute fs_status ................................273
12. Parallel NFS (pNFS) ..........................................277
12.1. Introduction ............................................277
12.2. pNFS Definitions ........................................278
12.3. pNFS Operations .........................................284
12.4. pNFS Attributes .........................................285
12.5. Layout Semantics ........................................285
12.6. pNFS Mechanics ..........................................300
12.7. Recovery ................................................302
12.8. Metadata and Storage Device Roles .......................307
12.9. Security Considerations for pNFS ........................307
13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type ..309
13.1. Client ID and Session Considerations ....................309
13.2. File Layout Definitions .................................312
13.3. File Layout Data Types ..................................312
13.4. Interpreting the File Layout ............................317
13.5. Data Server Multipathing ................................324
13.6. Operations Sent to NFSv4.1 Data Servers .................325
13.7. COMMIT through Metadata Server ..........................327
13.8. The Layout Iomode .......................................328
13.9. Metadata and Data Server State Coordination .............329
13.10. Data Server Component File Size ........................332
13.11. Layout Revocation and Fencing ..........................333
13.12. Security Considerations for the File Layout Type .......334
14. Internationalization .........................................334
14.1. Stringprep profile for the utf8str_cs type ..............336
14.2. Stringprep profile for the utf8str_cis type .............337
14.3. Stringprep profile for the utf8str_mixed type ...........338
14.4. UTF-8 Capabilities ......................................340
14.5. UTF-8 Related Errors ....................................340
15. Error Values .................................................341
15.1. Error Definitions .......................................341
15.2. Operations and Their Valid Errors .......................361
15.3. Callback Operations and Their Valid Errors ..............376
15.4. Errors and the Operations That Use Them .................379
16. NFSv4.1 Procedures ...........................................391
16.1. Procedure 0: NULL - No Operation ........................392
16.2. Procedure 1: COMPOUND - Compound Operations .............392
17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL ...............403
18. NFSv4.1 Operations ...........................................407
18.1. Operation 3: ACCESS - Check Access Rights ...............407
11.4. Uses of Location Information ............................232
11.5. Location Entries and Server Identity ....................236
11.6. Additional Client-Side Considerations ...................237
11.7. Effecting File System Transitions .......................238
11.8. Effecting File System Referrals .........................251
11.9. The Attribute fs_locations ..............................258
11.10. The Attribute fs_locations_info ........................261
11.11. The Attribute fs_status ................................273
12. Parallel NFS (pNFS) ..........................................277
12.1. Introduction ............................................277
12.2. pNFS Definitions ........................................278
12.3. pNFS Operations .........................................284
12.4. pNFS Attributes .........................................285
12.5. Layout Semantics ........................................285
12.6. pNFS Mechanics ..........................................300
12.7. Recovery ................................................302
12.8. Metadata and Storage Device Roles .......................307
12.9. Security Considerations for pNFS ........................307
13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type ..309
13.1. Client ID and Session Considerations ....................309
13.2. File Layout Definitions .................................312
13.3. File Layout Data Types ..................................312
13.4. Interpreting the File Layout ............................317
13.5. Data Server Multipathing ................................324
13.6. Operations Sent to NFSv4.1 Data Servers .................325
13.7. COMMIT through Metadata Server ..........................327
13.8. The Layout Iomode .......................................328
13.9. Metadata and Data Server State Coordination .............329
13.10. Data Server Component File Size ........................332
13.11. Layout Revocation and Fencing ..........................333
13.12. Security Considerations for the File Layout Type .......334
14. Internationalization .........................................334
14.1. Stringprep profile for the utf8str_cs type ..............336
14.2. Stringprep profile for the utf8str_cis type .............337
14.3. Stringprep profile for the utf8str_mixed type ...........338
14.4. UTF-8 Capabilities ......................................340
14.5. UTF-8 Related Errors ....................................340
15. Error Values .................................................341
15.1. Error Definitions .......................................341
15.2. Operations and Their Valid Errors .......................361
15.3. Callback Operations and Their Valid Errors ..............376
15.4. Errors and the Operations That Use Them .................379
16. NFSv4.1 Procedures ...........................................391
16.1. Procedure 0: NULL - No Operation ........................392
16.2. Procedure 1: COMPOUND - Compound Operations .............392
17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL ...............403
18. NFSv4.1 Operations ...........................................407
18.1. Operation 3: ACCESS - Check Access Rights ...............407
18.2. Operation 4: CLOSE - Close File .........................413
18.3. Operation 5: COMMIT - Commit Cached Data ................414
18.4. Operation 6: CREATE - Create a Non-Regular File Object ..417
18.5. Operation 7: DELEGPURGE - Purge Delegations
Awaiting Recovery .......................................419
18.6. Operation 8: DELEGRETURN - Return Delegation ............420
18.7. Operation 9: GETATTR - Get Attributes ...................421
18.8. Operation 10: GETFH - Get Current Filehandle ............423
18.9. Operation 11: LINK - Create Link to a File ..............424
18.10. Operation 12: LOCK - Create Lock .......................426
18.11. Operation 13: LOCKT - Test for Lock ....................430
18.12. Operation 14: LOCKU - Unlock File ......................432
18.13. Operation 15: LOOKUP - Lookup Filename .................433
18.14. Operation 16: LOOKUPP - Lookup Parent Directory ........435
18.15. Operation 17: NVERIFY - Verify Difference in
Attributes .............................................436
18.16. Operation 18: OPEN - Open a Regular File ...............437
18.17. Operation 19: OPENATTR - Open Named Attribute
Directory ..............................................458
18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File
Access .................................................459
18.19. Operation 22: PUTFH - Set Current Filehandle ...........461
18.20. Operation 23: PUTPUBFH - Set Public Filehandle .........461
18.21. Operation 24: PUTROOTFH - Set Root Filehandle ..........463
18.22. Operation 25: READ - Read from File ....................464
18.23. Operation 26: READDIR - Read Directory .................466
18.24. Operation 27: READLINK - Read Symbolic Link ............469
18.25. Operation 28: REMOVE - Remove File System Object .......470
18.26. Operation 29: RENAME - Rename Directory Entry ..........473
18.27. Operation 31: RESTOREFH - Restore Saved Filehandle .....477
18.28. Operation 32: SAVEFH - Save Current Filehandle .........478
18.29. Operation 33: SECINFO - Obtain Available Security ......479
18.30. Operation 34: SETATTR - Set Attributes .................482
18.31. Operation 37: VERIFY - Verify Same Attributes ..........485
18.32. Operation 38: WRITE - Write to File ....................486
18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control ....491
18.34. Operation 41: BIND_CONN_TO_SESSION - Associate
Connection with Session ................................492
18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID ......495
18.36. Operation 43: CREATE_SESSION - Create New
Session and Confirm Client ID ..........................513
18.37. Operation 44: DESTROY_SESSION - Destroy a Session ......523
18.38. Operation 45: FREE_STATEID - Free Stateid with
No Locks ...............................................525
18.39. Operation 46: GET_DIR_DELEGATION - Get a
Directory Delegation ...................................526
18.40. Operation 47: GETDEVICEINFO - Get Device Information ...530
18.41. Operation 48: GETDEVICELIST - Get All Device
18.2. Operation 4: CLOSE - Close File .........................413
18.3. Operation 5: COMMIT - Commit Cached Data ................414
18.4. Operation 6: CREATE - Create a Non-Regular File Object ..417
18.5. Operation 7: DELEGPURGE - Purge Delegations
Awaiting Recovery .......................................419
18.6. Operation 8: DELEGRETURN - Return Delegation ............420
18.7. Operation 9: GETATTR - Get Attributes ...................421
18.8. Operation 10: GETFH - Get Current Filehandle ............423
18.9. Operation 11: LINK - Create Link to a File ..............424
18.10. Operation 12: LOCK - Create Lock .......................426
18.11. Operation 13: LOCKT - Test for Lock ....................430
18.12. Operation 14: LOCKU - Unlock File ......................432
18.13. Operation 15: LOOKUP - Lookup Filename .................433
18.14. Operation 16: LOOKUPP - Lookup Parent Directory ........435
18.15. Operation 17: NVERIFY - Verify Difference in
Attributes .............................................436
18.16. Operation 18: OPEN - Open a Regular File ...............437
18.17. Operation 19: OPENATTR - Open Named Attribute
Directory ..............................................458
18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File
Access .................................................459
18.19. Operation 22: PUTFH - Set Current Filehandle ...........461
18.20. Operation 23: PUTPUBFH - Set Public Filehandle .........461
18.21. Operation 24: PUTROOTFH - Set Root Filehandle ..........463
18.22. Operation 25: READ - Read from File ....................464
18.23. Operation 26: READDIR - Read Directory .................466
18.24. Operation 27: READLINK - Read Symbolic Link ............469
18.25. Operation 28: REMOVE - Remove File System Object .......470
18.26. Operation 29: RENAME - Rename Directory Entry ..........473
18.27. Operation 31: RESTOREFH - Restore Saved Filehandle .....477
18.28. Operation 32: SAVEFH - Save Current Filehandle .........478
18.29. Operation 33: SECINFO - Obtain Available Security ......479
18.30. Operation 34: SETATTR - Set Attributes .................482
18.31. Operation 37: VERIFY - Verify Same Attributes ..........485
18.32. Operation 38: WRITE - Write to File ....................486
18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control ....491
18.34. Operation 41: BIND_CONN_TO_SESSION - Associate
Connection with Session ................................492
18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID ......495
18.36. Operation 43: CREATE_SESSION - Create New
Session and Confirm Client ID ..........................513
18.37. Operation 44: DESTROY_SESSION - Destroy a Session ......523
18.38. Operation 45: FREE_STATEID - Free Stateid with
No Locks ...............................................525
18.39. Operation 46: GET_DIR_DELEGATION - Get a
Directory Delegation ...................................526
18.40. Operation 47: GETDEVICEINFO - Get Device Information ...530
18.41. Operation 48: GETDEVICELIST - Get All Device
Mappings for a File System .............................533
18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made
Using a Layout .........................................534
18.43. Operation 50: LAYOUTGET - Get Layout Information .......538
18.44. Operation 51: LAYOUTRETURN - Release Layout
Information ............................................547
18.45. Operation 52: SECINFO_NO_NAME - Get Security on
Unnamed Object .........................................552
18.46. Operation 53: SEQUENCE - Supply Per-Procedure
Sequencing and Control .................................553
18.47. Operation 54: SET_SSV - Update SSV for a Client ID .....559
18.48. Operation 55: TEST_STATEID - Test Stateids for
Validity ...............................................561
18.49. Operation 56: WANT_DELEGATION - Request Delegation .....563
18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID ...566
18.51. Operation 58: RECLAIM_COMPLETE - Indicates
Reclaims Finished ......................................567
18.52. Operation 10044: ILLEGAL - Illegal Operation ...........569
19. NFSv4.1 Callback Procedures ..................................570
19.1. Procedure 0: CB_NULL - No Operation .....................570
19.2. Procedure 1: CB_COMPOUND - Compound Operations ..........571
20. NFSv4.1 Callback Operations ..................................574
20.1. Operation 3: CB_GETATTR - Get Attributes ................574
20.2. Operation 4: CB_RECALL - Recall a Delegation ............575
20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout
from Client .............................................576
20.4. Operation 6: CB_NOTIFY - Notify Client of
Directory Changes .......................................580
20.5. Operation 7: CB_PUSH_DELEG - Offer Previously
Requested Delegation to Client ..........................583
20.6. Operation 8: CB_RECALL_ANY - Keep Any N
Recallable Objects ......................................584
20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal
Resources for Recallable Objects ........................588
20.8. Operation 10: CB_RECALL_SLOT - Change Flow
Control Limits ..........................................588
20.9. Operation 11: CB_SEQUENCE - Supply Backchannel
Sequencing and Control ..................................589
20.10. Operation 12: CB_WANTS_CANCELLED - Cancel
Pending Delegation Wants ...............................592
20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of
Possible Lock Availability .............................593
20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify
Client of Device ID Changes ............................594
20.13. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation ..............................................596
21. Security Considerations ......................................597
22. IANA Considerations ..........................................598
Mappings for a File System .............................533
18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made
Using a Layout .........................................534
18.43. Operation 50: LAYOUTGET - Get Layout Information .......538
18.44. Operation 51: LAYOUTRETURN - Release Layout
Information ............................................547
18.45. Operation 52: SECINFO_NO_NAME - Get Security on
Unnamed Object .........................................552
18.46. Operation 53: SEQUENCE - Supply Per-Procedure
Sequencing and Control .................................553
18.47. Operation 54: SET_SSV - Update SSV for a Client ID .....559
18.48. Operation 55: TEST_STATEID - Test Stateids for
Validity ...............................................561
18.49. Operation 56: WANT_DELEGATION - Request Delegation .....563
18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID ...566
18.51. Operation 58: RECLAIM_COMPLETE - Indicates
Reclaims Finished ......................................567
18.52. Operation 10044: ILLEGAL - Illegal Operation ...........569
19. NFSv4.1 Callback Procedures ..................................570
19.1. Procedure 0: CB_NULL - No Operation .....................570
19.2. Procedure 1: CB_COMPOUND - Compound Operations ..........571
20. NFSv4.1 Callback Operations ..................................574
20.1. Operation 3: CB_GETATTR - Get Attributes ................574
20.2. Operation 4: CB_RECALL - Recall a Delegation ............575
20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout
from Client .............................................576
20.4. Operation 6: CB_NOTIFY - Notify Client of
Directory Changes .......................................580
20.5. Operation 7: CB_PUSH_DELEG - Offer Previously
Requested Delegation to Client ..........................583
20.6. Operation 8: CB_RECALL_ANY - Keep Any N
Recallable Objects ......................................584
20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal
Resources for Recallable Objects ........................588
20.8. Operation 10: CB_RECALL_SLOT - Change Flow
Control Limits ..........................................588
20.9. Operation 11: CB_SEQUENCE - Supply Backchannel
Sequencing and Control ..................................589
20.10. Operation 12: CB_WANTS_CANCELLED - Cancel
Pending Delegation Wants ...............................592
20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of
Possible Lock Availability .............................593
20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify
Client of Device ID Changes ............................594
20.13. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation ..............................................596
21. Security Considerations ......................................597
22. IANA Considerations ..........................................598
22.1. Named Attribute Definitions .............................598
22.2. Device ID Notifications .................................600
22.3. Object Recall Types .....................................601
22.4. Layout Types ............................................603
22.5. Path Variable Definitions ...............................606
23. References ...................................................609
23.1. Normative References ....................................609
23.2. Informative References ..................................612
Appendix A. Acknowledgments ....................................615
22.1. Named Attribute Definitions .............................598
22.2. Device ID Notifications .................................600
22.3. Object Recall Types .....................................601
22.4. Layout Types ............................................603
22.5. Path Variable Definitions ...............................606
23. References ...................................................609
23.1. Normative References ....................................609
23.2. Informative References ..................................612
Appendix A. Acknowledgments ....................................615
The NFS version 4 minor version 1 (NFSv4.1) protocol is the second minor version of the NFS version 4 (NFSv4) protocol. The first minor version, NFSv4.0, is described in [30]. It generally follows the guidelines for minor versioning that are listed in Section 10 of RFC 3530. However, it diverges from guidelines 11 ("a client and server that support minor version X must support minor versions 0 through X-1") and 12 ("no new features may be introduced as mandatory in a minor version"). These divergences are due to the introduction of the sessions model for managing non-idempotent operations and the RECLAIM_COMPLETE operation. These two new features are infrastructural in nature and simplify implementation of existing and other new features. Making them anything but REQUIRED would add undue complexity to protocol definition and implementation. NFSv4.1 accordingly updates the minor versioning guidelines (Section 2.7).
NFS版本4次要版本1（NFSv4.1）协议是NFS版本4（NFSv4）协议的第二次要版本。[30]中描述了第一个次要版本NFSv4.0。它通常遵循RFC 3530第10节中列出的次要版本控制指南。但是，它与准则11（“支持次要版本X的客户端和服务器必须支持次要版本0到X-1”）和准则12（“次要版本中不得强制引入新功能”）不同。这些差异是由于引入了用于管理非幂等运算的会话模型和Recreal_COMPLETE运算。这两项新功能本质上是基础设施，简化了现有功能和其他新功能的实现。如果不要求它们，就会给协议的定义和实现增加不必要的复杂性。NFSv4.1相应地更新了次要版本控制指南（第2.7节）。
As a minor version, NFSv4.1 is consistent with the overall goals for NFSv4, but extends the protocol so as to better meet those goals, based on experiences with NFSv4.0. In addition, NFSv4.1 has adopted some additional goals, which motivate some of the major extensions in NFSv4.1.
作为次要版本，NFSv4.1与NFSv4的总体目标一致，但根据NFSv4.0的经验，对协议进行了扩展，以便更好地实现这些目标。此外，NFSv4.1还采用了一些额外的目标，这些目标推动了NFSv4.1中的一些主要扩展。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This document describes the NFSv4.1 protocol. With respect to NFSv4.0, this document does not:
本文档描述了NFSv4.1协议。关于NFSv4.0，本文件不：
o describe the NFSv4.0 protocol, except where needed to contrast with NFSv4.1.
o 描述NFSv4.0协议，除非需要与NFSv4.1进行对比。
o modify the specification of the NFSv4.0 protocol.
o 修改NFSv4.0协议的规范。
o clarify the NFSv4.0 protocol.
o 澄清NFSv4.0协议。
The NFSv4 protocol is a further revision of the NFS protocol defined already by NFSv3 [31]. It retains the essential characteristics of previous versions: easy recovery; independence of transport protocols, operating systems, and file systems; simplicity; and good performance. NFSv4 has the following goals:
NFSv4协议是NFSv3[31]已经定义的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 ONCRPC working group in supporting the RPCSEC_GSS protocol. Additionally, the NFSv4.1 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.
该协议以ONCRPC工作组支持RPCSEC_GSS协议的工作为基础。此外，NFSv4.1协议提供了一种机制，允许客户端和服务器协商安全性，并要求客户端和服务器支持一组最小的安全方案。
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 within a framework that enables and encourages backward compatibility.
该协议旨在接受框架内的标准扩展，该框架支持并鼓励向后兼容。
NFSv4.1 has the following goals, within the framework established by the overall NFSv4 goals.
NFSv4.1在总体NFSv4目标建立的框架内，有以下目标。
o To correct significant structural weaknesses and oversights discovered in the base protocol.
o 纠正基本协议中发现的重大结构缺陷和疏忽。
o To add clarity and specificity to areas left unaddressed or not addressed in sufficient detail in the base protocol. However, as stated in Section 1.3, it is not a goal to clarify the NFSv4.0 protocol in the NFSv4.1 specification.
o 为基础协议中未解决或未充分详细解决的区域增加清晰性和特殊性。然而，如第1.3节所述，在NFSv4.1规范中澄清NFSv4.0协议不是目的。
o To add specific features based on experience with the existing protocol and recent industry developments.
o 根据现有协议的经验和最近的行业发展添加特定功能。
o To provide protocol support to take advantage of clustered server deployments including the ability to provide scalable parallel access to files distributed among multiple servers.
o 提供协议支持，以利用群集服务器部署，包括提供对分布在多台服务器之间的文件的可扩展并行访问的能力。
The following definitions provide an appropriate context for the reader.
以下定义为读者提供了适当的上下文。
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服务器的逻辑的应用程序。客户端也可以是为一组应用程序提供远程文件系统服务的传统操作系统客户端。
A client is uniquely identified by a client owner.
客户端由客户端所有者唯一标识。
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, short-hand reference to a client-supplied verifier and client owner. The server is responsible for supplying the client ID.
客户机ID：客户机ID是一个64位的数量，用作对客户机提供的验证器和客户机所有者的唯一、简短的引用。服务器负责提供客户端ID。
Client Owner: The client owner is a unique string, opaque to the server, that identifies a client. Multiple network connections and source network addresses originating from those connections may share a client owner. The server is expected to treat requests from connections with the same client owner as coming from the same client.
客户机所有者：客户机所有者是唯一的字符串，对服务器不透明，用于标识客户机。来自这些连接的多个网络连接和源网络地址可能共享一个客户端所有者。服务器应将来自同一客户机所有者的连接的请求视为来自同一客户机的请求。
File System: The file system is the collection of objects on a server (as identified by the major identifier of a server owner, which is defined later in this section) 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 locks. At the end of a lease period, locks may be revoked if the lease has not been extended. A lock must be revoked if a conflicting lock has been granted after the lease interval.
租约：租约是由服务器定义的一段时间间隔，对于该时间间隔，客户端被不可撤销地授予锁。在租赁期结束时，如果租赁期未延长，则可撤销锁定。如果在租约间隔后授予了冲突的锁，则必须撤销锁。
A server grants a client a single lease for all state.
服务器向客户端授予所有状态的单一租约。
Lock: The term "lock" is used to refer to byte-range (in UNIX environments, also known as record) locks, share reservations, delegations, or layouts unless specifically stated otherwise.
锁：术语“锁”用于指字节范围（在UNIX环境中，也称为记录）锁、共享保留、委派或布局，除非另有特别说明。
Secret State Verifier (SSV): The SSV is a unique secret key shared between a client and server. The SSV serves as the secret key for an internal (that is, internal to NFSv4.1) Generic Security Services (GSS) mechanism (the SSV GSS mechanism; see Section 2.10.9). The SSV GSS mechanism uses the SSV to compute message integrity code (MIC) and Wrap tokens. See Section 2.10.8.3 for more details on how NFSv4.1 uses the SSV and the SSV GSS mechanism.
秘密状态验证器（SSV）：SSV是客户端和服务器之间共享的唯一密钥。SSV用作内部（即NFSv4.1内部）通用安全服务（GSS）机制（SSV GSS机制；参见第2.10.9节）的密钥。SSV GSS机制使用SSV计算消息完整性代码（MIC）并包装令牌。有关NFSv4.1如何使用SSV和SSV GSS机制的更多详细信息，请参见第2.10.8.3节。
Server: The Server is the entity responsible for coordinating client access to a set of file systems and is identified by a server owner. A server can span multiple network addresses.
服务器：服务器是负责协调客户端对一组文件系统的访问的实体，由服务器所有者标识。服务器可以跨越多个网络地址。
Server Owner: The server owner identifies the server to the client. The server owner consists of a major identifier and a minor identifier. When the client has two connections each to a peer with the same major identifier, the client assumes that both peers are the same server (the server namespace is the same via each connection) and that lock state is sharable across both connections. When each peer has both the same major and minor identifiers, the client assumes that each connection might be associable with the same session.
服务器所有者：服务器所有者向客户端标识服务器。服务器所有者由主标识符和次标识符组成。当客户端有两个连接，每个连接到具有相同主标识符的对等方时，客户端假定两个对等方都是相同的服务器（通过每个连接，服务器名称空间是相同的），并且锁状态可在两个连接之间共享。当每个对等方都具有相同的主标识符和次标识符时，客户端会假定每个连接都可以与同一会话关联。
Stable Storage: Stable storage is storage from which data stored by an NFSv4.1 server can be recovered without data loss from multiple power failures (including cascading power failures, that is, several power failures in quick succession), operating system failures, and/or hardware failure of components other than the storage medium itself (such as disk, nonvolatile RAM, flash memory, etc.).
稳定存储：稳定存储是指NFSv4.1服务器存储的数据可以从中恢复，而不会因多个电源故障（包括级联电源故障，即多个连续电源故障）、操作系统故障和/或存储介质本身以外的组件硬件故障而丢失数据的存储（如磁盘、非易失性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 uninterruptible power system (UPS) and recovery software.
4. 使用不间断电源系统（UPS）和恢复软件进行缓存提交。
Stateid: A stateid is a 128-bit quantity returned by a server that uniquely defines 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 major features of the NFSv4.1 protocol will be reviewed in brief. This will be 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, there is still a set of fundamental knowledge that is expected. The reader should be familiar with the External Data Representation (XDR) and Remote Procedure Call (RPC) protocols as described in [2] and [3]. A basic knowledge of file systems and distributed file systems is expected as well.
将简要回顾NFSv4.1协议的主要特点。这样做是为了为熟悉以前版本的NFS协议的读者和不熟悉NFS协议的读者提供适当的上下文。对于初次接触NFS协议的读者来说，仍然需要一组基本知识。读者应熟悉[2]和[3]中所述的外部数据表示（XDR）和远程过程调用（RPC）协议。具备文件系统和分布式文件系统的基本知识。
In general, this specification of NFSv4.1 will not distinguish those features added in minor version 1 from those present in the base protocol but will treat NFSv4.1 as a unified whole. See Section 1.8 for a summary of the differences between NFSv4.0 and NFSv4.1.
通常，NFSv4.1的本规范不会将次要版本1中添加的功能与基本协议中存在的功能区分开来，而是将NFSv4.1视为一个统一的整体。NFSv4.0和NFSv4.1之间的差异汇总见第1.8节。
As with previous versions of NFS, the External Data Representation (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4.1 protocol are those defined in [2] and [3]. To meet end-to-end security requirements, the RPCSEC_GSS framework [4] is used to extend the basic RPC security. With the use of RPCSEC_GSS, various mechanisms can be provided to offer authentication, integrity, and
与以前版本的NFS一样，NFSv4.1协议使用的外部数据表示（XDR）和远程过程调用（RPC）机制是[2]和[3]中定义的机制。为了满足端到端安全性要求，使用RPCSEC_GSS框架[4]扩展基本RPC安全性。通过使用RPCSEC_GSS，可以提供各种机制来提供身份验证、完整性和安全性
privacy to the NFSv4 protocol. Kerberos V5 is used as described in [5] to provide one security framework. With the use of RPCSEC_GSS, other mechanisms may also be specified and used for NFSv4.1 security.
NFSv4协议的隐私。Kerberos V5如[5]所述用于提供一个安全框架。通过使用RPCSEC_GSS，还可以指定其他机制并用于NFSv4.1安全性。
To enable in-band security negotiation, the NFSv4.1 protocol has operations that provide the client 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.1协议的操作为客户端提供了一种查询服务器策略的方法，该策略涉及访问服务器文件系统资源必须使用哪些安全机制。这样，客户机就可以安全地匹配满足客户机和服务器上指定的策略的安全机制。
NFSv4.1 introduces parallel access (see Section 1.7.2.2), which is called pNFS. The security framework described in this section is significantly modified by the introduction of pNFS (see Section 12.9), because data access is sometimes not over RPC. The level of significance varies with the storage protocol (see Section 12.2.5) and can be as low as zero impact (see Section 13.12).
NFSv4.1引入了并行访问（见第1.7.2.2节），称为pNFS。由于pNFS的引入（参见第12.9节），本节中描述的安全框架得到了显著修改，因为数据访问有时不是通过RPC进行的。重要程度因存储协议而异（见第12.2.5节），可低至零影响（见第13.12节）。
Unlike NFSv3, which used a series of ancillary protocols (e.g., NLM, NSM (Network Status Monitor), MOUNT), within all minor versions of NFSv4 a single RPC protocol is used to make requests to the server. Facilities that had been separate protocols, such as locking, are now integrated within a single unified protocol.
与使用一系列辅助协议（例如NLM、NSM（网络状态监视器）、MOUNT）的NFSv3不同，在NFSv4的所有次要版本中，使用单个RPC协议向服务器发出请求。以前是单独协议的设施，例如锁定，现在集成到单个统一协议中。
Minor version 1 supports high-performance data access to a clustered server implementation by enabling a separation of metadata access and data access, with the latter done to multiple servers in parallel.
Minor版本1支持对集群服务器实现的高性能数据访问，实现了元数据访问和数据访问的分离，后者并行地对多个服务器进行访问。
Such parallel data access is controlled by recallable objects known as "layouts", which are integrated into the protocol locking model. Clients direct requests for data access to a set of data servers specified by the layout via a data storage protocol which may be NFSv4.1 or may be another protocol.
这种并行数据访问由称为“布局”的可重新调用对象控制，这些对象集成到协议锁定模型中。客户端通过数据存储协议（可能是NFSv4.1或其他协议）将数据访问请求直接发送到布局指定的一组数据服务器。
Because the protocols used for parallel data access are not necessarily RPC-based, the RPC-based security model (Section 1.7.1) is obviously impacted (see Section 12.9). The degree of impact varies with the storage protocol (see Section 12.2.5) used for data access, and can be as low as zero (see Section 13.12).
由于用于并行数据访问的协议不一定基于RPC，因此基于RPC的安全模型（第1.7.1节）明显受到影响（见第12.9节）。影响程度因用于数据访问的存储协议（见第12.2.5节）而异，可低至零（见第13.12节）。
The general file system model used for the NFSv4.1 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.1协议使用的通用文件系统模型与以前的版本相同。服务器文件系统是分层的，其中包含的常规文件被视为不透明字节流。稍微不同的是，文件名和目录名用UTF-8编码，以处理国际化的基础知识。
The NFSv4.1 protocol does not require a separate protocol to provide for the initial mapping between path name and filehandle. All file systems exported by a server are presented as a tree so that all file systems are reachable from a special per-server global root filehandle. This allows LOOKUP operations to be used to perform functions previously provided by the MOUNT protocol. The server provides any necessary pseudo file systems to bridge any gaps that arise due to unexported gaps between exported file systems.
NFSv4.1协议不需要单独的协议来提供路径名和文件句柄之间的初始映射。服务器导出的所有文件系统都以树的形式显示，这样所有文件系统都可以通过特殊的每服务器全局根文件句柄访问。这允许使用查找操作来执行先前由装载协议提供的功能。服务器提供任何必要的伪文件系统，以弥补由于导出的文件系统之间未报告的间隙而产生的任何间隙。
As in previous versions of the NFS protocol, opaque filehandles are used to identify individual files and directories. Lookup-type and create operations translate file and directory names to filehandles, which are then used to identify objects in subsequent operations.
与以前版本的NFS协议一样，不透明文件句柄用于标识单个文件和目录。“查找类型”和“创建”操作将文件名和目录名转换为文件句柄，然后用于在后续操作中标识对象。
The NFSv4.1 protocol provides support for persistent filehandles, guaranteed to be valid for the lifetime of the file system object designated. In addition, it provides support to servers to provide filehandles with more limited validity guarantees, called volatile filehandles.
NFSv4.1协议提供对持久化文件句柄的支持，保证在指定的文件系统对象的生存期内有效。此外，它还支持服务器为文件句柄提供更有限的有效性保证，称为volatile文件句柄。
The NFSv4.1 protocol has a rich and extensible file object attribute structure, which is divided into REQUIRED, RECOMMENDED, and named attributes (see Section 5).
NFSv4.1协议具有丰富且可扩展的文件对象属性结构，该结构分为必需属性、推荐属性和命名属性（参见第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 [31]). 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的属性派生的（参见[31]中fattr3数据类型的定义）。所需属性的一个示例是文件对象的类型（第5.8.1.2节），以便将常规文件与目录（在某些操作环境中也称为文件夹）和其他类型的对象区分开来。第5.1节讨论了所需属性。
An example of three RECOMMENDED attributes are acl, sacl, and dacl. These attributes define an Access Control List (ACL) on a file object (Section 6). An ACL provides directory and file access control beyond the model used in NFSv3. The ACL definition allows for
三个推荐属性的示例是acl、sacl和dacl。这些属性定义文件对象上的访问控制列表（ACL）（第6节）。ACL提供了NFSv3中使用的模型之外的目录和文件访问控制。ACL定义允许
specification of specific sets of permissions for individual users and groups. In addition, ACL inheritance allows propagation of access permissions and restrictions down a directory tree as file system objects are created. RECOMMENDED attributes are discussed in Section 5.2.
为单个用户和组指定特定权限集。此外，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节中讨论。
NFSv4.1 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 alternate or new locations for that file system.
NFSv4.1包含许多功能，允许实现跨越服务器边界的名称空间，并允许和促进在服务器之间无中断地传输对单个文件系统的支持。它们都基于允许一个文件系统为该文件系统指定备用位置或新位置的属性。
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 alternate 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 alternate servers.
o 当以前存在的文件系统不存在时，可以提供位置属性。这允许无中断地将文件系统迁移到备用服务器。
As mentioned previously, NFSv4.1 is a single protocol that includes locking facilities. These locking facilities include support for many types of locks including a number of sorts of recallable locks.
如前所述，NFSv4.1是一个包含锁定功能的单一协议。这些锁定设施包括支持多种类型的锁，包括多种类型的可重装锁。
Recallable locks such as delegations allow the client to be assured that certain events will not occur so long as that lock is held. When circumstances change, the lock is recalled via a callback request. The assurances provided by delegations allow more extensive caching to be done safely when circumstances allow it.
可重新调用的锁（如委托）允许客户机确信，只要保持该锁，某些事件就不会发生。当情况发生变化时，通过回调请求调用锁。各代表团提供的保证允许在情况允许时安全地进行更广泛的缓存。
The types of locks are:
锁的类型有：
o Share reservations as established by OPEN operations.
o 共享开放式运营建立的预订。
o Byte-range locks.
o 字节范围锁。
o File delegations, which are recallable locks that assure the holder that inconsistent opens and file changes cannot occur so long as the delegation is held.
o 文件委派，是一种可重新调用的锁，可确保持有者在委派保持期间不会打开不一致的文件并更改文件。
o Directory delegations, which are recallable locks that assure the holder that inconsistent directory modifications cannot occur so long as the delegation is held.
o 目录委托，这是一种可重新调用的锁，可确保持有者在保留委托的情况下不会发生不一致的目录修改。
o Layouts, which are recallable objects that assure the holder that direct access to the file data may be performed directly by the client and that no change to the data's location that is inconsistent with that access may be made so long as the layout is held.
o 布局，是可重新调用的对象，可确保持有人直接访问文件数据可由客户直接执行，并且只要保持布局，就不会对数据位置进行与该访问不一致的更改。
All locks for a given client are tied together under a single client-wide lease. All requests made on sessions associated with the client renew that lease. When the client's lease is not promptly renewed, the client's locks are subject to revocation. In the event of server restart, clients have the opportunity to safely reclaim their locks within a special grace period.
给定客户机的所有锁都在单个客户机范围的租约下绑定在一起。在与客户端关联的会话上发出的所有请求都将续订该租约。如果客户的租约未及时续约，客户的锁将被撤销。在服务器重新启动的情况下，客户端有机会在一个特殊的宽限期内安全地回收其锁。
The following summarizes the major differences between minor version 1 and the base protocol:
以下总结了次要版本1和基本协议之间的主要差异：
o Implementation of the sessions model (Section 2.10).
o 会话模型的实施（第2.10节）。
o Parallel access to data (Section 12).
o 并行访问数据（第12节）。
o Addition of the RECLAIM_COMPLETE operation to better structure the lock reclamation process (Section 18.51).
o 添加回收完整操作，以更好地构建船闸回收流程（第18.51节）。
o Enhanced delegation support as follows.
o 加强代表团支持如下。
* Delegations on directories and other file types in addition to regular files (Section 18.39, Section 18.49).
* 除常规文件外，对目录和其他文件类型的授权（第18.39节，第18.49节）。
* Operations to optimize acquisition of recalled or denied delegations (Section 18.49, Section 20.5, Section 20.7).
* 优化收回或拒绝授权的获取的操作（第18.49节、第20.5节、第20.7节）。
* Notifications of changes to files and directories (Section 18.39, Section 20.4).
* 文件和目录更改通知（第18.39节，第20.4节）。
* A method to allow a server to indicate that it is recalling one or more delegations for resource management reasons, and thus a method to allow the client to pick which delegations to return (Section 20.6).
* 一种允许服务器指示其出于资源管理原因调用一个或多个委托的方法，以及一种允许客户端选择返回哪些委托的方法（第20.6节）。
o Attributes can be set atomically during exclusive file create via the OPEN operation (see the new EXCLUSIVE4_1 creation method in Section 18.16).
o 在通过OPEN操作创建独占文件的过程中，可以自动设置属性（请参阅第18.16节中新的EXCLUSIVE4_1创建方法）。
o Open files can be preserved if removed and the hard link count ("hard link" is defined in an Open Group [6] standard) goes to zero, thus obviating the need for clients to rename deleted files to partially hidden names -- colloquially called "silly rename" (see the new OPEN4_RESULT_PRESERVE_UNLINKED reply flag in Section 18.16).
o 如果删除打开的文件，并且硬链接计数（“硬链接”在开放组[6]标准中定义）变为零，则可以保留打开的文件，从而避免客户端需要将删除的文件重命名为部分隐藏的名称——通俗地称为“愚蠢的重命名”（请参阅第18.16节中新的OPEN4_RESULT_PRESERVE_UNLINKED reply标志）。
o Improved compatibility with Microsoft Windows for Access Control Lists (Section 6.2.3, Section 6.2.2, Section 6.4.3.2).
o 改进了与Microsoft Windows访问控制列表的兼容性（第6.2.3节、第6.2.2节、第6.4.3.2节）。
o Data retention (Section 5.13).
o 数据保留（第5.13节）。
o Identification of the implementation of the NFS client and server (Section 18.35).
o NFS客户端和服务器实现的标识（第18.35节）。
o Support for notification of the availability of byte-range locks (see the new OPEN4_RESULT_MAY_NOTIFY_LOCK reply flag in Section 18.16 and see Section 20.11).
o 支持通知字节范围锁的可用性（请参阅第18.16节中新的OPEN4_RESULT_MAY_NOTIFY_LOCK reply标志和第20.11节）。
o In NFSv4.1, LIPKEY and SPKM-3 are not required security mechanisms [32].
o 在NFSv4.1中，LIPKEY和SPKM-3不是必需的安全机制[32]。
NFSv4.1 relies on core infrastructure common to nearly every operation. This core infrastructure is described in the remainder of this section.
NFSv4.1依赖于几乎所有操作都通用的核心基础设施。这一核心基础设施将在本节的其余部分介绍。
The NFSv4.1 protocol is a Remote Procedure Call (RPC) application that uses RPC version 2 and the corresponding eXternal Data Representation (XDR) as defined in [3] and [2].
NFSv4.1协议是一个远程过程调用（RPC）应用程序，它使用RPC版本2和[3]和[2]中定义的相应外部数据表示（XDR）。
Previous NFS versions have been thought of as having a host-based authentication model, where the NFS server authenticates the NFS client, and trusts the client to authenticate all users. Actually, NFS has always depended on RPC for authentication. One of the first forms of RPC authentication, AUTH_SYS, had no strong authentication and required a host-based authentication approach. NFSv4.1 also depends on RPC for basic security services and mandates RPC support for a user-based authentication model. The user-based authentication model has user principals authenticated by a server, and in turn the server authenticated by user principals. RPC provides some basic security services that are used by NFSv4.1.
以前的NFS版本被认为具有基于主机的身份验证模型，其中NFS服务器对NFS客户端进行身份验证，并信任客户端对所有用户进行身份验证。实际上，NFS一直依赖于RPC进行身份验证。RPC身份验证的最初形式之一AUTH_SYS没有强身份验证，需要基于主机的身份验证方法。NFSv4.1还依赖RPC提供基本安全服务，并强制要求RPC支持基于用户的身份验证模型。基于用户的身份验证模型具有由服务器进行身份验证的用户主体，而服务器又由用户主体进行身份验证。RPC提供NFSv4.1使用的一些基本安全服务。
As described in Section 7.2 ("Authentication") of [3], RPC security is encapsulated in the RPC header, via a security or authentication flavor, and information specific to the specified security flavor. Every RPC header conveys information used to identify and authenticate a client and server. As discussed in Section 2.2.1.1.1, some security flavors provide additional security services.
如[3]第7.2节（“认证”）所述，RPC安全性通过安全性或认证风格以及特定于指定安全风格的信息封装在RPC标头中。每个RPC头传递用于识别和验证客户端和服务器的信息。如第2.2.1.1.1节所述，一些安全特性提供了额外的安全服务。
NFSv4.1 clients and servers MUST implement RPCSEC_GSS. (This requirement to implement is not a requirement to use.) Other flavors, such as AUTH_NONE and AUTH_SYS, MAY be implemented as well.
NFSv4.1客户端和服务器必须实现RPCSEC_GSS。（要实现的要求不是使用的要求。）也可以实现其他风格，如AUTH_NONE和AUTH_SYS。
RPCSEC_GSS [4] uses the functionality of GSS-API [7]. This allows for the use of various security mechanisms by the RPC layer without the additional implementation overhead of adding RPC security flavors.
RPCSEC_GSS[4]使用GSS-API[7]的功能。这允许RPC层使用各种安全机制，而无需添加RPC安全特性的额外实现开销。
Via the GSS-API, RPCSEC_GSS can be used to identify and authenticate users on clients to servers, and servers to users. It can also perform integrity checking on the entire RPC message, including the RPC header, and on the arguments or results. Finally, privacy, usually via encryption, is a service available with RPCSEC_GSS. Privacy is performed on the arguments and results. Note that if
通过GSS-API，RPCSEC_GSS可用于识别和验证客户端到服务器的用户，以及服务器到用户的用户。它还可以对整个RPC消息（包括RPC头）以及参数或结果执行完整性检查。最后，隐私（通常通过加密）是RPCSEC_GSS提供的一项服务。对参数和结果执行隐私保护。注意，如果
privacy is selected, integrity, authentication, and identification are enabled. If privacy is not selected, but integrity is selected, authentication and identification are enabled. If integrity and privacy are not selected, but authentication is enabled, identification is enabled. RPCSEC_GSS does not provide identification as a separate service.
选择隐私，启用完整性、身份验证和标识。如果未选择隐私，但选择了完整性，则会启用身份验证和标识。如果未选择完整性和隐私，但已启用身份验证，则将启用标识。RPCSEC_GSS不作为单独服务提供标识。
Although GSS-API has an authentication service distinct from its privacy and integrity services, GSS-API's authentication service is not used for RPCSEC_GSS's authentication service. Instead, each RPC request and response header is integrity protected with the GSS-API integrity service, and this allows RPCSEC_GSS to offer per-RPC authentication and identity. See [4] for more information.
虽然GSS-API具有与其隐私和完整性服务不同的身份验证服务，但GSS-API的身份验证服务不用于RPCSEC_GSS的身份验证服务。相反，每个RPC请求和响应头都受到GSS-API完整性服务的完整性保护，这允许RPCSEC_GSS提供每个RPC身份验证和标识。有关更多信息，请参见[4]。
NFSv4.1 client and servers MUST support RPCSEC_GSS's integrity and authentication service. NFSv4.1 servers MUST support RPCSEC_GSS's privacy service. NFSv4.1 clients SHOULD support RPCSEC_GSS's privacy service.
NFSv4.1客户端和服务器必须支持RPCSEC_GSS的完整性和身份验证服务。NFSv4.1服务器必须支持RPCSEC_GSS的隐私服务。NFSv4.1客户端应支持RPCSEC_GSS的隐私服务。
RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide security services. Therefore, NFSv4.1 clients and servers MUST support the Kerberos V5 security mechanism.
RPCSEC_GSS通过GSS-API规范了对提供安全服务的机制的访问。因此，NFSv4.1客户端和服务器必须支持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.1 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.1 clients and servers MUST be implemented on operating environments that comply with the REQUIRED cryptographic algorithms of each REQUIRED mechanism.
RPCSEC_GSS的使用需要选择机制、保护质量（QOP）和服务（身份验证、完整性、隐私）。对于强制安全机制，NFSv4.1规定使用QOP为零，由机制或机制配置将QOP零映射到适当的保护级别。每个强制机制都指定了用于实现完整性和隐私性的最小加密算法集。NFSv4.1客户端和服务器必须在符合每个所需机制的所需加密算法的操作环境中实现。
The Kerberos V5 GSS-API mechanism as described in [5] MUST be implemented with the RPCSEC_GSS services as specified in the following table:
[5]中描述的Kerberos V5 GSS-API机制必须使用下表中指定的RPCSEC_GSS服务实现：
column descriptions:
1 == number of pseudo flavor
2 == name of pseudo flavor
3 == mechanism's OID
4 == RPCSEC_GSS service
5 == NFSv4.1 clients MUST support
6 == NFSv4.1 servers MUST support
column descriptions:
1 == number of pseudo flavor
2 == name of pseudo flavor
3 == mechanism's OID
4 == RPCSEC_GSS service
5 == NFSv4.1 clients MUST support
6 == NFSv4.1 servers MUST support
1 2 3 4 5 6
------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 rpc_gss_svc_none yes yes
390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes
390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes
1 2 3 4 5 6
------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 rpc_gss_svc_none yes yes
390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes
390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes
Note that the number and name of the pseudo flavor are presented here as a mapping aid to the implementor. Because the NFSv4.1 protocol includes a method to negotiate security and it understands the GSS-API mechanism, the pseudo flavor is not needed. The pseudo flavor is needed for the NFSv3 since the security negotiation is done via the MOUNT protocol as described in [33].
请注意，伪风格的编号和名称在这里作为映射辅助工具提供给实现者。因为NFSv4.1协议包含协商安全性的方法，并且它理解GSS-API机制，所以不需要伪风格。NFSv3需要伪风格，因为安全协商是通过[33]中描述的装载协议完成的。
At the time NFSv4.1 was specified, the Advanced Encryption Standard (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Kerberos V5. In contrast, when NFSv4.0 was specified, 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.1 specification does not specify REQUIRED algorithms for Kerberos V5, and instead, the implementor is expected to track the evolution of the Kerberos V5 standard if and when stronger algorithms are specified.
在指定NFSv4.1时，带有HMAC-SHA1的高级加密标准（AES）是Kerberos V5所需的算法集。相反，当指定NFSv4.0时，Kerberos V5需要较弱的算法集，NFSv4.0规范也需要较弱的算法集，因为当时的Kerberos V5规范没有指定更强的算法。NFSv4.1规范没有为Kerberos V5指定所需的算法，相反，如果指定了更强大的算法，则实现者应该跟踪Kerberos V5标准的发展。
2.2.1.1.1.2.1.1. Security Considerations for Cryptographic Algorithms in Kerberos V5
2.2.1.1.1.2.1.1. Kerberos V5中加密算法的安全注意事项
When deploying NFSv4.1, 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.1 to ensure that security is acceptable where needed.
在部署NFSv4.1时，实现的安全性的强度取决于现有的Kerberos V5基础架构。Kerberos V5的算法不直接暴露于客户机或服务器，也不可由客户机或服务器选择，因此NFSv4.1的用户需要进行一些尽职调查，以确保在需要时可以接受安全性。
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/主机名
A significant departure from the versions of the NFS protocol before NFSv4 is the introduction of the COMPOUND procedure. For the NFSv4 protocol, in all minor versions, there are exactly two RPC procedures, NULL and COMPOUND. The COMPOUND procedure is defined as a series of individual operations and these operations perform the sorts of functions performed by traditional NFS procedures.
与NFSv4之前的NFS协议版本相比，引入了复合过程。对于NFSv4协议，在所有次要版本中，正好有两个RPC过程：NULL和component。复合过程被定义为一系列单独的操作，这些操作执行传统NFS过程执行的各种功能。
The operations combined within a COMPOUND request are evaluated in order by the server, without any atomicity guarantees. A limited set of facilities exist to pass results from one operation to another. Once an operation returns a failing result, the evaluation ends and the results of all evaluated operations are returned to the client.
组合在复合请求中的操作由服务器按顺序进行评估，而无需任何原子性保证。存在一组有限的设施，用于将结果从一个操作传递到另一个操作。一旦操作返回失败的结果，评估将结束，所有评估操作的结果将返回给客户端。
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, multi-component look up requests can be constructed by combining multiple LOOKUP operations. Those can be further combined with operations such as GETATTR, READDIR, or OPEN plus READ to do more complicated sets of operation without incurring additional latency.
通过使用复合过程，客户机能够构建简单或复杂的请求。这些复合请求允许减少逻辑文件系统操作所需的RPC数量。例如，可以通过组合多个查找操作来构造多组件查找请求。这些可以进一步与诸如GETATTR、READDIR或OPEN plus READ之类的操作相结合，以执行更复杂的操作集，而不会产生额外的延迟。
NFSv4.1 also contains a considerable set of callback operations in which the server makes an RPC directed at the client. Callback RPCs have a similar structure to that of the normal server requests. In all minor versions of the NFSv4 protocol, there are two callback RPC procedures: CB_NULL and CB_COMPOUND. The CB_COMPOUND procedure is defined in an analogous fashion to that of COMPOUND with its own set of callback operations.
NFSv4.1还包含一组相当多的回调操作，其中服务器将RPC定向到客户端。回调RPC的结构与普通服务器请求的结构相似。在NFSv4协议的所有次要版本中，都有两个回调RPC过程：CB_NULL和CB_component。CB_复合过程的定义方式与复合过程类似，它有自己的一组回调操作。
The addition of new server and callback operations within the COMPOUND and CB_COMPOUND request framework provides a means of extending the protocol in subsequent minor versions.
在复合和CB_复合请求框架中添加新的服务器和回调操作，提供了在后续次要版本中扩展协议的方法。
Except for a small number of operations needed for session creation, server requests and callback requests are performed within the context of a session. Sessions provide a client context for every request and support robust reply protection for non-idempotent requests.
除了创建会话所需的少量操作外，服务器请求和回调请求都是在会话上下文中执行的。会话为每个请求提供客户端上下文，并支持对非幂等请求的健壮回复保护。
For each operation that obtains or depends on locking state, the specific client needs to be identifiable by the server.
对于获得或依赖于锁定状态的每个操作，服务器需要识别特定的客户端。
Each distinct client instance is represented by a client ID. A client ID is a 64-bit identifier representing a specific client at a given time. The client ID is changed whenever the client re-initializes, and may change when the server re-initializes. Client IDs are used to support lock identification and crash recovery.
每个不同的客户端实例都由一个客户端ID表示。客户端ID是一个64位标识符，表示给定时间的特定客户端。客户机ID在客户机重新初始化时更改，并且在服务器重新初始化时可能会更改。客户端ID用于支持锁识别和崩溃恢复。
During steady state operation, the client ID associated with each operation is derived from the session (see Section 2.10) on which the operation is sent. A session is associated with a client ID when the session is created.
在稳态操作期间，与每个操作相关联的客户机ID来自发送操作的会话（参见第2.10节）。创建会话时，会话与客户端ID关联。
Unlike NFSv4.0, the only NFSv4.1 operations possible before a client ID is established are those needed to establish the client ID.
与NFSv4.0不同，在建立客户机ID之前，唯一可能的NFSv4.1操作是建立客户机ID所需的操作。
A sequence of an EXCHANGE_ID operation followed by a CREATE_SESSION operation using that client ID (eir_clientid as returned from EXCHANGE_ID) is required to establish and confirm the client ID on the server. Establishment of identification by a new incarnation of the client also has the effect of immediately releasing any locking state that a previous incarnation of that same client might have had on the server. Such released state would include all byte-range lock, share reservation, layout state, and -- where the server supports neither the CLAIM_DELEGATE_PREV nor CLAIM_DELEG_CUR_FH claim types -- all delegation state associated with the same client with the same identity. For discussion of delegation state recovery, see Section 10.2.1. For discussion of layout state recovery, see Section 12.7.1.
在服务器上建立和确认客户端ID时，需要先执行EXCHANGE\u ID操作，然后使用该客户端ID（从EXCHANGE\u ID返回的eir\u clientid）执行创建会话操作。通过客户机的新版本建立标识还可以立即释放该客户机的前一版本在服务器上可能具有的任何锁定状态。这种释放状态将包括所有字节范围锁、共享保留、布局状态，并且——如果服务器既不支持CLAIM_DELEGATE_PREV，也不支持CLAIM_DELEG_CUR_FH声明类型——与具有相同标识的同一客户机关联的所有委托状态。有关授权状态恢复的讨论，请参见第10.2.1节。有关布局状态恢复的讨论，请参见第12.7.1节。
Releasing such state requires that the server be able to determine that one client instance is the successor of another. Where this cannot be done, for any of a number of reasons, the locking state will remain for a time subject to lease expiration (see Section 8.3) and the new client will need to wait for such state to be removed, if it makes conflicting lock requests.
释放这种状态需要服务器能够确定一个客户端实例是另一个客户端实例的后续实例。如果由于多种原因无法做到这一点，锁定状态将保留一段时间，直至租约到期（见第8.3节），如果新客户端发出冲突的锁定请求，则需要等待该状态被删除。
Client identification is encapsulated in the following client owner data type:
客户端标识封装在以下客户端所有者数据类型中：
struct client_owner4 {
verifier4 co_verifier;
opaque co_ownerid<NFS4_OPAQUE_LIMIT>;
};
struct client_owner4 {
verifier4 co_verifier;
opaque co_ownerid<NFS4_OPAQUE_LIMIT>;
};
The first field, co_verifier, is a client incarnation verifier. The server will start the process of canceling the client's leased state if co_verifier is different than what the server has previously recorded for the identified client (as specified in the co_ownerid field).
第一个字段，co_验证器，是一个客户机化身验证器。如果co_verifier与服务器先前为已识别的客户端记录的内容不同（如co_ownerid字段中所指定），则服务器将启动取消客户端租用状态的过程。
The second field, co_ownerid, is a variable length string that uniquely defines the client so that subsequent instances of the same client bear the same co_ownerid with a different verifier.
第二个字段co_ownerid是一个可变长度的字符串，它唯一地定义了客户机，以便同一客户机的后续实例与不同的验证器具有相同的co_ownerid。
There are several considerations for how the client generates the co_ownerid string:
对于客户端如何生成co_ownerid字符串，有几个注意事项：
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 cancelled.
o 该字符串应该是唯一的，以便多个客户端不显示相同的字符串。两个客户端呈现相同字符串的后果从一个客户端出错到一个客户端的租用状态突然意外取消。
o The string should be selected so that subsequent incarnations (e.g., restarts) of the same client cause the client to present the same string. The implementor is cautioned from 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.1 server.
o 应选择该字符串，以便同一客户机的后续化身（例如，重新启动）导致该客户机呈现相同的字符串。提醒实现者不要使用要求将字符串记录在本地文件中的方法，因为这会妨碍在没有本地磁盘且所有文件访问都来自NFSv4.1服务器的环境中使用实现。
o The string should be the same for each server network address that the client accesses. This way, if a server has multiple interfaces, the client can trunk traffic over multiple network paths as described in Section 2.10.5. (Note: the precise opposite was advised in the NFSv4.0 specification [30].)
o 对于客户端访问的每个服务器网络地址，字符串应该相同。这样，如果服务器有多个接口，客户端可以通过多个网络路径中继流量，如第2.10.5节所述。（注：NFSv4.0规范[30]中建议的正好相反。）
o The algorithm for generating the string should not assume that the client's network address will not change, unless the client implementation knows it is using statically assigned network addresses. This includes changes between client incarnations and even changes while the client is still running in its current incarnation. Thus, with dynamic address assignment, if the client includes just the client's network address in the co_ownerid string, there is a real risk that after the client gives up the
o 生成字符串的算法不应假定客户端的网络地址不会更改，除非客户端实现知道它正在使用静态分配的网络地址。这包括客户端化身之间的更改，甚至在客户端仍在当前化身中运行时的更改。因此，使用动态地址分配，如果客户机在co_ownerid字符串中仅包含客户机的网络地址，则在客户机放弃该地址后，存在真正的风险
network address, another client, using a similar algorithm for generating the co_ownerid string, would generate a conflicting co_ownerid string.
网络地址，另一个客户端，使用类似的算法生成co_ownerid字符串，将生成冲突的co_ownerid字符串。
Given the above considerations, an example of a well-generated co_ownerid string is one that includes:
鉴于上述考虑，生成良好的共有ID字符串示例包括：
o If applicable, the client's statically assigned network address.
o 如果适用，客户端静态分配的网络地址。
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 Media Access Control (MAC) address (again, a one-way function should be performed).
* 媒体访问控制（MAC）地址（同样，应执行单向功能）。
* The timestamp of when the NFSv4.1 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.1).
* NFSv4.1软件首次安装到客户端时的时间戳（尽管这取决于前面提到的关于使用存储在文件中的信息的注意事项，因为该文件可能只能通过NFSv4.1访问）。
* 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.
* 真随机数。然而，由于此数字在客户端化身之间应该是相同的，因此这与使用软件安装的时间戳的问题相同。
o For a user-level NFSv4.1 client, it should contain additional information to distinguish the client from other user-level clients running on the same host, such as a process identifier or other unique sequence.
o 对于用户级NFSv4.1客户端，它应该包含其他信息，以将客户端与运行在同一主机上的其他用户级客户端区分开来，例如进程标识符或其他唯一序列。
The client ID is assigned by the server (the eir_clientid result from EXCHANGE_ID) and should be chosen so that it will not conflict with a client ID previously assigned by the server. This applies across server restarts.
客户端ID由服务器分配（eir_clientid来自EXCHANGE_ID），应选择该ID，以使其不会与服务器先前分配的客户端ID冲突。这适用于服务器重启。
In the event of a server restart, a client may find out that its current client ID is no longer valid when it receives an NFS4ERR_STALE_CLIENTID error. The precise circumstances depend on the characteristics of the sessions involved, specifically whether the session is persistent (see Section 2.10.6.5), but in each case the client will receive this error when it attempts to establish a new session with the existing client ID and receives the error NFS4ERR_STALE_CLIENTID, indicating that a new client ID needs to be obtained via EXCHANGE_ID and the new session established with that client ID.
在服务器重新启动的情况下，当客户端收到NFS4ERR_STALE_CLIENTID错误时，可能会发现其当前客户端ID不再有效。具体情况取决于所涉及会话的特征，特别是会话是否持久（见第2.10.6.5节），但在每种情况下，当客户端尝试使用现有客户端ID建立新会话并收到错误NFS4ERR_STALE_CLIENTID时，客户端都会收到此错误，指示需要通过EXCHANGE_ID和使用该客户端ID建立的新会话获取新的客户端ID。
When a session is not persistent, the client will find out that it needs to create a new session as a result of getting an NFS4ERR_BADSESSION, since the session in question was lost as part of a server restart. When the existing client ID is presented to a server as part of creating a session and that client ID is not recognized, as would happen after a server restart, the server will reject the request with the error NFS4ERR_STALE_CLIENTID.
当会话不是持久性的时，客户端将发现由于获得NFS4ERR_BADSESSION，它需要创建一个新会话，因为该会话在服务器重新启动时丢失。当现有客户端ID作为创建会话的一部分呈现给服务器，并且该客户端ID无法识别时（服务器重新启动后会发生这种情况），服务器将拒绝该请求，错误为NFS4ERR_STALE_CLIENTID。
In the case of the session being persistent, the client will re-establish communication using the existing session after the restart. This session will be associated with the existing client ID but may only be used to retransmit operations that the client previously transmitted and did not see replies to. Replies to operations that the server previously performed will come from the reply cache; otherwise, NFS4ERR_DEADSESSION will be returned. Hence, such a session is referred to as "dead". In this situation, in order to perform new operations, the client needs to establish a new session. If an attempt is made to establish this new session with the existing client ID, the server will reject the request with NFS4ERR_STALE_CLIENTID.
在会话持续的情况下，客户端将在重启后使用现有会话重新建立通信。此会话将与现有客户端ID相关联，但只能用于重新传输客户端以前传输但未看到回复的操作。对服务器先前执行的操作的回复将来自回复缓存；否则，将返回NFS4ERR_DEADSESSION。因此，这种会议被称为“死亡”。在这种情况下，为了执行新的操作，客户端需要建立一个新的会话。如果尝试使用现有客户端ID建立此新会话，服务器将使用NFS4ERR_STALE_CLIENTID拒绝请求。
When NFS4ERR_STALE_CLIENTID is received in either of these situations, the client needs to obtain a new client ID by use of the EXCHANGE_ID operation, then use that client ID as the basis of a new session, and then proceed to any other necessary recovery for the server restart case (see Section 8.4.2).
当在上述任一情况下收到NFS4ERR_STALE_CLIENTID时，客户端需要使用EXCHANGE_ID操作获取新的客户端ID，然后将该客户端ID用作新会话的基础，然后针对服务器重启情况进行任何其他必要的恢复（请参阅第8.4.2节）。
See the descriptions of EXCHANGE_ID (Section 18.35) and CREATE_SESSION (Section 18.36) for a complete specification of these operations.
有关这些操作的完整规范，请参阅EXCHANGE_ID（第18.35节）和CREATE_SESSION（第18.36节）的说明。
To facilitate upgrade from NFSv4.0 to NFSv4.1, a server may compare a value of data type client_owner4 in an EXCHANGE_ID with a value of data type nfs_client_id4 that was established using the SETCLIENTID operation of NFSv4.0. A server that does so will allow an upgraded client to avoid waiting until the lease (i.e., the lease established by the NFSv4.0 instance client) expires. This requires that the value of data type client_owner4 be constructed the same way as the value of data type nfs_client_id4. If the latter's contents included the server's network address (per the recommendations of the NFSv4.0 specification [30]), and the NFSv4.1 client does not wish to use a client ID that prevents trunking, it should send two EXCHANGE_ID operations. The first EXCHANGE_ID will have a client_owner4 equal to the nfs_client_id4. This will clear the state created by the NFSv4.0 client. The second EXCHANGE_ID will not have the server's network
为了便于从NFSv4.0升级到NFSv4.1，服务器可以将EXCHANGE_ID中的数据类型client_owner4的值与使用NFSv4.0的SETCLIENTID操作建立的数据类型nfs_client_id4的值进行比较。这样做的服务器将允许升级的客户端避免等待租约（即NFSv4.0实例客户端建立的租约）到期。这要求数据类型client_owner4的值的构造方式与数据类型nfs_client_id4的值的构造方式相同。如果后者的内容包括服务器的网络地址（根据NFSv4.0规范[30]的建议），并且NFSv4.1客户端不希望使用阻止中继的客户端ID，则应发送两个交换ID操作。第一个EXCHANGE\u ID的客户端所有者4将等于nfs\u客户端id4。这将清除NFSv4.0客户端创建的状态。第二个EXCHANGE\u ID将没有服务器的网络
address. The state created for the second EXCHANGE_ID will not have to wait for lease expiration, because there will be no state to expire.
住址为第二个EXCHANGE\u ID创建的状态不必等待租约到期，因为没有要到期的状态。
NFSv4.1 introduces a new operation called DESTROY_CLIENTID (Section 18.50), which the client SHOULD use to destroy a client ID it no longer needs. This permits graceful, bilateral release of a client ID. The operation cannot be used if there are sessions associated with the client ID, or state with an unexpired lease.
NFSv4.1引入了一个名为DESTROY_CLIENTID（第18.50节）的新操作，客户端应使用该操作销毁不再需要的客户端ID。这允许优雅、双边地释放客户端ID。如果存在与客户端ID关联的会话，或状态为未过期租约，则无法使用该操作。
If the server determines that the client holds no associated state for its client ID (associated state includes unrevoked sessions, opens, locks, delegations, layouts, and wants), the server MAY choose to unilaterally release the client ID in order to conserve resources. 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 EXCHANGE_ID/CREATE_SESSION sequence to establish a new client ID. The server ought to be very hesitant to release a client ID since the resulting work on the client to recover from such an event will be the same 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. As long as there are sessions, opens, locks, delegations, layouts, or wants, the server MUST NOT release the client ID. See Section 2.10.13.1.4 for discussion on releasing inactive sessions.
如果服务器确定客户端没有其客户端ID的关联状态（关联状态包括未撤销的会话、打开、锁定、委派、布局和需要），则服务器可以选择单方面释放客户端ID以节省资源。如果客户端在此版本后与服务器联系，服务器必须确保客户端接收到适当的错误，以便使用EXCHANGE\u ID/创建\u会话序列来建立新的客户端ID。服务器在释放客户端ID时应该非常犹豫，因为在客户端上从此类事件中恢复的结果工作将与服务器发生故障和重新启动。通常，服务器不会释放客户机ID，除非该客户机在几分钟内没有任何活动。只要存在会话、打开、锁定、委派、布局或需要，服务器就不得释放客户端ID。有关释放非活动会话的讨论，请参阅第2.10.13.1.4节。
When the server gets an EXCHANGE_ID for a client owner that currently has no state, or that has state but the lease has expired, the server MUST allow the EXCHANGE_ID and confirm the new client ID if followed by the appropriate CREATE_SESSION.
当服务器为当前无状态或有状态但租约已过期的客户端所有者获取EXCHANGE\u ID时，服务器必须允许EXCHANGE\u ID，并确认新客户端ID（如果后跟相应的CREATE\u会话）。
When the server gets an EXCHANGE_ID for a new incarnation of a client owner that currently has an old incarnation with state and an unexpired lease, the server is allowed to dispose of the state of the previous incarnation of the client owner if one of the following is true:
当服务器为当前具有状态的旧版本和未过期租约的客户端所有者的新版本获取EXCHANGE_ID时，如果满足以下条件之一，则允许服务器处置客户端所有者的前一版本的状态：
o The principal that created the client ID for the client owner is the same as the principal that is sending the EXCHANGE_ID operation. Note that if the client ID was created with SP4_MACH_CRED state protection (Section 18.35), the principal MUST be based on RPCSEC_GSS authentication, the RPCSEC_GSS service used
o 为客户端所有者创建客户端ID的主体与发送EXCHANGE\u ID操作的主体相同。请注意，如果客户端ID是使用SP4_MACH_CRED状态保护（第18.35节）创建的，则主体必须基于RPCSEC_GSS身份验证，即使用的RPCSEC_GSS服务
MUST be integrity or privacy, and the same GSS mechanism and principal MUST be used as that used when the client ID was created.
必须是完整性或隐私性，并且必须使用与创建客户端ID时相同的GSS机制和主体。
o The client ID was established with SP4_SSV protection (Section 18.35, Section 2.10.8.3) and the client sends the EXCHANGE_ID with the security flavor set to RPCSEC_GSS using the GSS SSV mechanism (Section 2.10.9).
o 客户端ID是通过SP4_SSV保护（第18.35节，第2.10.8.3节）建立的，客户端使用GSS SSV机制（第2.10.9节）向RPCSEC_GSS发送具有安全设置的EXCHANGE_ID。
o The client ID was established with SP4_SSV protection, and under the conditions described herein, the EXCHANGE_ID was sent with SP4_MACH_CRED state protection. Because the SSV might not persist across client and server restart, and because the first time a client sends EXCHANGE_ID to a server it does not have an SSV, the client MAY send the subsequent EXCHANGE_ID without an SSV RPCSEC_GSS handle. Instead, as with SP4_MACH_CRED protection, the principal MUST be based on RPCSEC_GSS authentication, the RPCSEC_GSS service used MUST be integrity or privacy, and the same GSS mechanism and principal MUST be used as that used when the client ID was created.
o 客户端ID由SP4_SSV保护建立，在本文描述的条件下，交换ID由SP4_MACH_CRED状态保护发送。由于SSV可能不会在客户端和服务器重新启动期间持续存在，并且由于客户端第一次向服务器发送EXCHANGE_ID时没有SSV，因此客户端可能会在没有SSV RPCSEC_GSS句柄的情况下发送后续EXCHANGE_ID。相反，与SP4_MACH_CRED保护一样，主体必须基于RPCSEC_GSS身份验证，使用的RPCSEC_GSS服务必须是完整的或隐私的，并且必须使用与创建客户端ID时相同的GSS机制和主体。
If none of the above situations apply, the server MUST return NFS4ERR_CLID_INUSE.
如果上述情况均不适用，服务器必须返回NFS4ERR\u CLID\u INUSE。
If the server accepts the principal and co_ownerid as matching that which created the client ID, and the co_verifier in the EXCHANGE_ID differs from the co_verifier used when the client ID was created, then after the server receives a CREATE_SESSION that confirms the client ID, the server deletes state. If the co_verifier values are the same (e.g., the client either is updating properties of the client ID (Section 18.35) or is attempting trunking (Section 2.10.5), the server MUST NOT delete state.
如果服务器接受主体和co_ownerid作为与创建客户端ID的匹配项，并且EXCHANGE_ID中的co_验证器与创建客户端ID时使用的co_验证器不同，则在服务器接收到确认客户端ID的CREATE_会话后，服务器将删除状态。如果co_验证器值相同（例如，客户端正在更新客户端ID的属性（第18.35节）或正在尝试中继（第2.10.5节），则服务器不得删除状态。
The server owner is similar to a client owner (Section 2.4), but unlike the client owner, there is no shorthand server ID. The server owner is defined in the following data type:
服务器所有者类似于客户端所有者（第2.4节），但与客户端所有者不同，没有速记服务器ID。服务器所有者在以下数据类型中定义：
struct server_owner4 {
uint64_t so_minor_id;
opaque so_major_id<NFS4_OPAQUE_LIMIT>;
};
struct server_owner4 {
uint64_t so_minor_id;
opaque so_major_id<NFS4_OPAQUE_LIMIT>;
};
The server owner is returned from EXCHANGE_ID. When the so_major_id fields are the same in two EXCHANGE_ID results, the connections that each EXCHANGE_ID were sent over can be assumed to address the same
服务器所有者从EXCHANGE\u ID返回。当两个EXCHANGE\u ID结果中的so\u MAGIR\u ID字段相同时，可以假定每个EXCHANGE\u ID发送的连接地址相同
server (as defined in Section 1.6). If the so_minor_id fields are also the same, then not only do both connections connect to the same server, but the session can be shared across both connections. The reader is cautioned that multiple servers may deliberately or accidentally claim to have the same so_major_id or so_major_id/ so_minor_id; the reader should examine Sections 2.10.5 and 18.35 in order to avoid acting on falsely matching server owner values.
服务器（定义见第1.6节）。如果so_minor_id字段也相同，则不仅两个连接都连接到同一服务器，而且会话可以在两个连接之间共享。请读者注意，多台服务器可能会故意或意外地声称具有相同的so_major_id或so_major_id/so_minor_id；读者应检查第2.10.5节和第18.35节，以避免对错误匹配的服务器所有者值采取行动。
The considerations for generating a so_major_id are similar to that for generating a co_ownerid string (see Section 2.4). The consequences of two servers generating conflicting so_major_id values are less dire than they are for co_ownerid conflicts because the client can use RPCSEC_GSS to compare the authenticity of each server (see Section 2.10.5).
生成so_主id的注意事项与生成co_所有者id字符串的注意事项类似（参见第2.4节）。由于客户端可以使用RPCSEC GSS来比较每台服务器的真实性，因此两台服务器生成冲突的so_主要_id值的后果没有共有id冲突那么严重（参见第2.10.5节）。
With the NFSv4.1 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 may have multiple points within its file system namespace that are available for use by NFS clients. These points can be considered security policy boundaries, and, in some NFS implementations, are tied to NFS export points. In turn, the NFS server may be configured such that each of these security policy boundaries may have different or multiple security mechanisms in use.
由于NFSv4.1服务器可能提供多种安全机制，客户端需要一种方法来确定或协商用于与服务器通信的机制。NFS服务器的文件系统命名空间中可能有多个点可供NFS客户端使用。这些点可以被视为安全策略边界，并且在某些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 21 for further discussion.
客户端和服务器之间的安全协商应使用安全通道进行，以消除第三方截获协商序列并迫使客户端和服务器选择低于要求或期望的安全级别的可能性。进一步讨论见第21节。
An NFS server can assign one or more "security tuples" to each security policy boundary in its namespace. Each security tuple consists of a security flavor (see Section 2.2.1.1) and, if the flavor is RPCSEC_GSS, a GSS-API mechanism Object Identifier (OID), a GSS-API quality of protection, and an RPCSEC_GSS service.
NFS服务器可以为其命名空间中的每个安全策略边界分配一个或多个“安全元组”。每个安全元组由一个安全风格（见第2.2.1.1节）和一个GSS-API机制对象标识符（OID）、一个GSS-API保护质量和一个RPCSEC_GSS服务组成。
The SECINFO and SECINFO_NO_NAME operations allow the client to determine, on a per-filehandle basis, what security tuple is to be used for server access. In general, the client will not have to use either operation except during initial communication with the server or when the client crosses security policy boundaries at the server.
SECINFO和SECINFO_NO_NAME操作允许客户端根据每个文件句柄确定用于服务器访问的安全元组。通常，客户机不必使用这两种操作，除非在与服务器的初始通信期间或客户机在服务器上跨越安全策略边界时使用。
However, the server's policies may also change at any time and force the client to negotiate a new security tuple.
但是，服务器的策略也可能随时更改，并强制客户端协商新的安全元组。
Where the use of different security tuples would affect the type of access that would be allowed if a request was sent over the same connection used for the SECINFO or SECINFO_NO_NAME operation (e.g., read-only vs. read-write) access, security tuples that allow greater access should be presented first. Where the general level of access is the same and different security flavors limit the range of principals whose privileges are recognized (e.g., allowing or disallowing root access), flavors supporting the greatest range of principals should be listed first.
如果使用不同的安全元组会影响通过用于SECINFO或SECINFO_NO_NAME操作（例如，只读与读写）访问的相同连接发送请求时允许的访问类型，则应首先显示允许更大访问的安全元组。如果访问的一般级别相同，并且不同的安全风格限制了其权限被识别的主体的范围（例如，允许或不允许根访问），则应首先列出支持最大范围主体的风格。
Based on the assumption that each NFSv4.1 client and server MUST support a minimum set of security (i.e., Kerberos V5 under RPCSEC_GSS), the NFS client will initiate file access to the server with one of the minimal security tuples. During communication with the server, the client may receive an NFS error of NFS4ERR_WRONGSEC. This error allows the server to notify the client that the security tuple currently being used contravenes the server's security policy. The client is then responsible for determining (see Section 2.6.3.1) what security tuples are available at the server and choosing one that is appropriate for the client.
基于每个NFSv4.1客户端和服务器必须支持一组最低安全性（即RPCSEC_GSS下的Kerberos V5）的假设，NFS客户端将使用一个最低安全元组启动对服务器的文件访问。在与服务器通信期间，客户端可能会收到NFS4ERR_错误秒的NFS错误。此错误允许服务器通知客户端当前使用的安全元组违反服务器的安全策略。然后，客户机负责确定（参见第2.6.3.1节）服务器上有哪些安全元组可用，并选择一个适合客户机的元组。
This section explains the mechanics of NFSv4.1 security negotiation.
本节解释NFSv4.1安全协商的机制。
The term "put filehandle operation" refers to PUTROOTFH, PUTPUBFH, PUTFH, and RESTOREFH. Each of the subsections herein describes how the server handles a subseries of operations that starts with a put filehandle operation.
术语“put filehandle操作”指PUTROOTFH、PUTPUBFH、PUTFH和RESTOREFH。本文中的每个小节都描述了服务器如何处理以put filehandle操作开始的操作子系列。
The client is saving a filehandle for a future RESTOREFH, LINK, or RENAME. SAVEFH MUST NOT return NFS4ERR_WRONGSEC. To determine whether or not the put filehandle operation returns NFS4ERR_WRONGSEC, the server implementation pretends SAVEFH is not in the series of operations and examines which of the situations described in the other subsections of Section 2.6.3.1.1 apply.
客户端正在保存文件句柄，以便将来进行恢复、链接或重命名。SAVEFH不得返回NFS4ERR_错误秒。为了确定put filehandle操作是否返回NFS4ERR_错误秒，服务器实现将假定SAVEFH不在一系列操作中，并检查第2.6.3.1.1节其他小节中描述的情况适用。
For a series of N put filehandle operations, the server MUST NOT return NFS4ERR_WRONGSEC to the first N-1 put filehandle operations. The Nth put filehandle operation is handled as if it is the first in a subseries of operations. For example, if the server received a COMPOUND request with this series of operations -- PUTFH, PUTROOTFH, LOOKUP -- then the PUTFH operation is ignored for NFS4ERR_WRONGSEC purposes, and the PUTROOTFH, LOOKUP subseries is processed as according to Section 2.6.3.1.1.3.
对于一系列N-1 put filehandle操作，服务器不得将NFS4ERR_错误返回到第一个N-1 put filehandle操作。第n个put filehandle操作的处理方式与操作子系列中的第一个操作相同。例如，如果服务器接收到包含这一系列操作的复合请求——PUTFH、PUTROOTFH、LOOKUP——那么出于NFS4ERR_错误的目的，PUTFH操作将被忽略，PUTROOTFH、LOOKUP子序列将按照第2.6.3.1.1.3节进行处理。
2.6.3.1.1.3. Put Filehandle Operation + LOOKUP (or OPEN of an Existing Name)
2.6.3.1.1.3. 放置文件句柄操作+查找（或打开现有名称）
This situation also applies to a put filehandle operation followed by a LOOKUP or an OPEN operation that specifies an existing component name.
这种情况也适用于put filehandle操作，然后是查找或指定现有组件名称的打开操作。
In this situation, the client is potentially crossing a security policy boundary, and the set of security tuples the parent directory supports may differ from those of the child. The server implementation may decide whether to impose any restrictions on security policy administration. There are at least three approaches (sec_policy_child is the tuple set of the child export, sec_policy_parent is that of the parent).
在这种情况下，客户端可能会跨越安全策略边界，并且父目录支持的安全元组集可能与子目录支持的安全元组集不同。服务器实现可以决定是否对安全策略管理施加任何限制。至少有三种方法（sec_policy_child是子导出的元组集，sec_policy_parent是父导出的元组集）。
(a) sec_policy_child <= sec_policy_parent (<= for subset). This means that the set of security tuples specified on the security policy of a child directory is always a subset of its parent directory.
(a) sec_策略_子项<=sec_策略_父项（<=子集）。这意味着在子目录的安全策略上指定的安全元组集始终是其父目录的子集。
(b) sec_policy_child ^ sec_policy_parent != {} (^ for intersection,
{} for the empty set). This means that the set of security
tuples specified on the security policy of a child directory
always has a non-empty intersection with that of the parent.
(b) sec_policy_child ^ sec_policy_parent != {} (^ for intersection,
{} for the empty set). This means that the set of security
tuples specified on the security policy of a child directory
always has a non-empty intersection with that of the parent.
(c) sec_policy_child ^ sec_policy_parent == {}. This means that the
set of security tuples specified on the security policy of a
child directory may not intersect with that of the parent. In
other words, there are no restrictions on how the system
administrator may set up these tuples.
(c) sec_policy_child ^ sec_policy_parent == {}. This means that the
set of security tuples specified on the security policy of a
child directory may not intersect with that of the parent. In
other words, there are no restrictions on how the system
administrator may set up these tuples.
In order for a server to support approaches (b) (for the case when a client chooses a flavor that is not a member of sec_policy_parent) and (c), the put filehandle operation cannot return NFS4ERR_WRONGSEC when there is a security tuple mismatch. Instead, it should be returned from the LOOKUP (or OPEN by existing component name) that follows.
为了使服务器支持方法（b）（对于客户端选择的味道不是sec_policy_parent的成员的情况）和（c），当存在安全元组不匹配时，put filehandle操作不能返回NFS4ERR_ErrorSec。相反，它应该从后面的查找（或按现有组件名称打开）返回。
Since the above guideline does not contradict approach (a), it should be followed in general. Even if approach (a) is implemented, it is possible for the security tuple used to be acceptable for the target of LOOKUP but not for the filehandles used in the put filehandle operation. The put filehandle operation could be a PUTROOTFH or PUTPUBFH, where the client cannot know the security tuples for the root or public filehandle. Or the security policy for the filehandle used by the put filehandle operation could have changed since the time the filehandle was obtained.
由于上述指南与方法（a）并不矛盾，因此一般应遵循。即使实现了方法（a），用于查找目标的安全元组也可能是可接受的，但对于put filehandle操作中使用的filehandles则可能不是。put filehandle操作可以是PUTROOTFH或PUTPUBFH，其中客户端无法知道根或公共filehandle的安全元组。或者，put filehandle操作使用的filehandle的安全策略可能自获取filehandle时起已更改。
Therefore, an NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC in response to the put filehandle operation if the operation is immediately followed by a LOOKUP or an OPEN by component name.
因此，如果put filehandle操作后紧接着查找或OPEN by组件名称，则NFSv4.1服务器不得返回NFS4ERR_ErrorSec以响应该操作。
Since SECINFO only works its way down, there is no way LOOKUPP can return NFS4ERR_WRONGSEC without SECINFO_NO_NAME. SECINFO_NO_NAME solves this issue via style SECINFO_STYLE4_PARENT, which works in the opposite direction as SECINFO. As with Section 2.6.3.1.1.3, a put filehandle operation that is followed by a LOOKUPP MUST NOT return NFS4ERR_WRONGSEC. If the server does not support SECINFO_NO_NAME, the client's only recourse is to send the put filehandle operation, LOOKUPP, GETFH sequence of operations with every security tuple it supports.
由于SECINFO只能向下运行，因此如果没有SECINFO\u no\u名称，LOOKUPP无法返回NFS4ERR\u错误sec。SECINFO_NO_NAME通过样式SECINFO_STYLE4_PARENT解决了这个问题，它与SECINFO的工作方向相反。与第2.6.3.1.1.3节一样，后跟LOOKUPP的put filehandle操作不得返回NFS4ERR_错误。如果服务器不支持SECINFO_NO_NAME，那么客户端唯一的办法就是用它支持的每个安全元组发送put filehandle操作、LOOKUPP、GETFH操作序列。
Regardless of whether SECINFO_NO_NAME is supported, an NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC in response to a put filehandle operation if the operation is immediately followed by a LOOKUPP.
无论是否支持SECINFO_NO_NAME，NFSv4.1服务器都不得返回NFS4ERR_ErrorSec以响应put filehandle操作，前提是该操作后面紧跟着LOOKUPP。
A security-sensitive client is allowed to choose a strong security tuple when querying a server to determine a file object's permitted security tuples. The security tuple chosen by the client does not have to be included in the tuple list of the security policy of either the parent directory indicated in the put filehandle operation or the child file object indicated in SECINFO (or any parent directory indicated in SECINFO_NO_NAME). Of course, the server has to be configured for whatever security tuple the client selects; otherwise, the request will fail at the RPC layer with an appropriate authentication error.
当查询服务器以确定文件对象允许的安全元组时，允许安全敏感客户端选择强安全元组。客户端选择的安全元组不必包含在put filehandle操作中指示的父目录或SECINFO中指示的子文件对象（或SECINFO\u NO\u NAME中指示的任何父目录）的安全策略元组列表中。当然，服务器必须针对客户端选择的任何安全元组进行配置；否则，请求将在RPC层失败，并出现相应的身份验证错误。
In theory, there is no connection between the security flavor used by SECINFO or SECINFO_NO_NAME and those supported by the security policy. But in practice, the client may start looking for strong flavors from those supported by the security policy, followed by those in the REQUIRED set.
理论上，SECINFO或SECINFO_no_NAME使用的安全风格与安全策略支持的安全风格之间没有任何联系。但在实践中，客户机可能会开始从安全策略支持的内容中寻找强烈的风格，然后是所需的内容集中的内容。
The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to a put filehandle operation that is immediately followed by SECINFO or SECINFO_NO_NAME. The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC from SECINFO or SECINFO_NO_NAME.
NFSv4.1服务器不得将NFS4ERR_errosec返回到紧跟SECINFO或SECINFO_NO_名称的put filehandle操作。NFSv4.1服务器不得从SECINFO或SECINFO\u NO\u名称返回NFS4errr\u errosec。
The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC.
NFSv4.1服务器不得返回NFS4ERR_错误秒。
"Anything Else" includes OPEN by filehandle.
“其他任何内容”包括按文件句柄打开。
The security policy enforcement applies to the filehandle specified in the put filehandle operation. Therefore, the put filehandle operation MUST return NFS4ERR_WRONGSEC when there is a security tuple mismatch. This avoids the complexity of adding NFS4ERR_WRONGSEC as an allowable error to every other operation.
安全策略强制应用于put filehandle操作中指定的filehandle。因此，当存在安全元组不匹配时，put filehandle操作必须返回NFS4ERR_errosec。这避免了将NFS4ERR_ErrorSec作为允许的错误添加到每个其他操作中的复杂性。
A COMPOUND containing the series put filehandle operation + SECINFO_NO_NAME (style SECINFO_STYLE4_CURRENT_FH) is an efficient way for the client to recover from NFS4ERR_WRONGSEC.
包含系列put filehandle操作+SECINFO_NO_名称（样式SECINFO_STYLE4_CURRENT_FH）的化合物是客户端从NFS4ERR_错误恢复的有效方法。
The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to any operation other than a put filehandle operation, LOOKUP, LOOKUPP, and OPEN (by component name).
NFSv4.1服务器不得将NFS4ERR_errosec返回到put filehandle操作、查找、查找和打开（按组件名称）以外的任何操作。
Suppose a client sends a COMPOUND procedure containing the series SEQUENCE, PUTFH, SECINFO_NONAME, READ, and suppose the security tuple used does not match that required for the target file. By rule (see Section 2.6.3.1.1.5), neither PUTFH nor SECINFO_NO_NAME can return NFS4ERR_WRONGSEC. By rule (see Section 2.6.3.1.1.7), READ cannot return NFS4ERR_WRONGSEC. The issue is resolved by the fact that SECINFO and SECINFO_NO_NAME consume the current filehandle (note that this is a change from NFSv4.0). This leaves no current filehandle for READ to use, and READ returns NFS4ERR_NOFILEHANDLE.
假设客户端发送一个包含序列PUTFH、SECINFO_NONAME、READ的复合过程，并假设使用的安全元组与目标文件所需的不匹配。根据规则（见第2.6.3.1.1.5节），PUTFH和SECINFO_NO_NAME都不能返回NFS4ERR_错误SEC。根据规则（见第2.6.3.1.1.7节），READ不能返回NFS4ERR_错误秒。通过SECINFO和SECINFO_NO_NAME使用当前文件句柄（请注意，这是对NFSv4.0的一个更改），问题得以解决。这不会留下当前文件句柄供READ使用，READ返回NFS4ERR_NOFILEHANDLE。
The LINK and RENAME operations use both the current and saved filehandles. Technically, the server MAY return NFS4ERR_WRONGSEC from LINK or RENAME if the security policy of the saved filehandle rejects the security flavor used in the COMPOUND request's credentials. If the server does so, then if there is no intersection
链接和重命名操作同时使用当前和保存的文件句柄。从技术上讲，如果保存的文件句柄的安全策略拒绝复合请求凭据中使用的安全特性，则服务器可能会从LINK或RENAME返回NFS4ERR_-errosec。如果服务器这样做，那么如果没有交叉点
between the security policies of saved and current filehandles, this means that it will be impossible for the client to perform the intended LINK or RENAME operation.
在已保存和当前文件句柄的安全策略之间，这意味着客户端将无法执行预期的链接或重命名操作。
For example, suppose the client sends this COMPOUND request: SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, RENAME "c" "d", where filehandles bFH and aFH refer to different directories. Suppose no common security tuple exists between the security policies of aFH and bFH. If the client sends the request using credentials acceptable to bFH's security policy but not aFH's policy, then the PUTFH aFH operation will fail with NFS4ERR_WRONGSEC. After a SECINFO_NO_NAME request, the client sends SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, RENAME "c" "d", using credentials acceptable to aFH's security policy but not bFH's policy. The server returns NFS4ERR_WRONGSEC on the RENAME operation.
例如，假设客户端发送这个复合请求：SEQUENCE、PUTFH-bFH、SAVEFH、PUTFH-aFH，重命名为“c”“d”，其中filehandles-bFH和aFH引用不同的目录。假设aFH和bFH的安全策略之间不存在公共安全元组。如果客户端使用bFH的安全策略可接受的凭据（而非aFH的策略）发送请求，则PUTFH aFH操作将因NFS4ERR_错误而失败。在SECINFO_NO_NAME请求之后，客户端使用aFH的安全策略（而非bFH的策略）可接受的凭据发送序列PUTFH bFH SAVEFH PUTFH aFH重命名为“c”“d”。服务器在重命名操作中返回NFS4ERR_错误秒。
To prevent a client from an endless sequence of a request containing LINK or RENAME, followed by a request containing SECINFO_NO_NAME or SECINFO, the server MUST detect when the security policies of the current and saved filehandles have no mutually acceptable security tuple, and MUST NOT return NFS4ERR_WRONGSEC from LINK or RENAME in that situation. Instead the server MUST do one of two things:
为了防止客户端出现包含链接或重命名的无休止的请求序列，然后是包含SECINFO_NO_NAME或SECINFO的请求，服务器必须检测当前和保存的文件句柄的安全策略是否没有相互可接受的安全元组，在这种情况下，不得从链接或重命名返回NFS4ERR_错误秒。相反，服务器必须执行以下两项操作之一：
o The server can return NFS4ERR_XDEV.
o 服务器可以返回nfs4errxdev。
o The server can allow the security policy of the current filehandle to override that of the saved filehandle, and so return NFS4_OK.
o 服务器可以允许当前文件句柄的安全策略覆盖已保存文件句柄的安全策略，因此返回NFS4\u OK。
To address the requirement of an NFS protocol that can evolve as the need arises, the NFSv4.1 protocol contains the rules and framework to allow for future minor changes or versioning.
为了满足NFS协议的需求，该协议可以随着需要而发展，NFSv4.1协议包含允许将来进行微小更改或版本控制的规则和框架。
The base assumption with respect to minor versioning is that any future accepted minor version will be documented in one or more Standards Track RFCs. Minor version 0 of the NFSv4 protocol is represented by [30], and minor version 1 is represented by this RFC. The COMPOUND and CB_COMPOUND procedures support the encoding of the minor version being requested by the client.
关于次要版本控制的基本假设是，任何未来接受的次要版本都将记录在一个或多个标准跟踪RFC中。NFSv4协议的次要版本0由[30]表示，次要版本1由该RFC表示。复合和CB_复合过程支持对客户端请求的次要版本进行编码。
The following items represent the basic rules for the development of minor versions. Note that a future minor version may modify or add to the following rules as part of the minor version definition.
以下各项代表了开发次要版本的基本规则。请注意，将来的次要版本可能会修改或添加以下规则，作为次要版本定义的一部分。
1. Procedures are not added or deleted.
1. 不会添加或删除过程。
To maintain the general RPC model, NFSv4 minor versions will not add to or delete procedures from the NFS program.
为了维护通用RPC模型，NFSv4次要版本不会在NFS程序中添加或删除过程。
2. Minor versions may add operations to the COMPOUND and CB_COMPOUND procedures.
2. 次要版本可能会将操作添加到复合程序和CB_复合程序中。
The addition of operations to the COMPOUND and CB_COMPOUND procedures does not affect the RPC model.
向复合过程和CB_复合过程添加操作不会影响RPC模型。
* Minor versions may append attributes to the bitmap4 that represents sets of attributes and to the fattr4 that represents sets of attribute values.
* 次要版本可以将属性附加到表示属性集的位图4和表示属性值集的fattr4。
This allows for the expansion of the attribute model to allow for future growth or adaptation.
这允许扩展属性模型，以允许将来的增长或适应。
* Minor version X must append any new attributes after the last documented attribute.
* 次要版本X必须在最后记录的属性之后附加任何新属性。
Since attribute results are specified as an opaque array of per-attribute, XDR-encoded results, the complexity of adding new attributes in the midst of the current definitions would be too burdensome.
由于属性结果被指定为每个属性的不透明数组，XDR编码的结果，因此在当前定义中添加新属性的复杂性太大。
3. Minor versions must not modify the structure of an existing operation's arguments or results.
3. 次要版本不得修改现有操作的参数或结果的结构。
Again, the complexity of handling multiple structure definitions for a single operation is too burdensome. New operations should be added instead of modifying existing structures for a minor version.
同样，为一个操作处理多个结构定义的复杂性过于繁重。应添加新操作，而不是修改次要版本的现有结构。
This rule does not preclude the following adaptations in a minor version:
本规则不排除次要版本中的以下改编：
* adding bits to flag fields, such as new attributes to GETATTR's bitmap4 data type, and providing corresponding variants of opaque arrays, such as a notify4 used together with such bitmaps
* 向标志字段添加位，例如GETATTR的bitmap4数据类型的新属性，并提供不透明数组的相应变体，例如与此类位图一起使用的notify4
* adding bits to existing attributes like ACLs that have flag words
* 向现有属性（如具有标志词的ACL）添加位
* extending enumerated types (including NFS4ERR_*) with new values
* 使用新值扩展枚举类型（包括NFS4ERR_*）
* adding cases to a switched union
* 向交换的并集添加案例
4. Minor versions must not modify the structure of existing attributes.
4. 次要版本不得修改现有属性的结构。
5. Minor versions must not delete operations.
5. 次要版本不得删除操作。
This prevents the potential reuse of a particular operation "slot" in a future minor version.
这防止了在将来的次要版本中可能重用特定操作“插槽”。
6. Minor versions must not delete attributes.
6. 次要版本不得删除属性。
7. Minor versions must not delete flag bits or enumeration values.
7. 次要版本不得删除标志位或枚举值。
8. Minor versions may declare an operation MUST NOT be implemented.
8. 次要版本可能声明不得执行操作。
Specifying that an operation MUST NOT be implemented is equivalent to obsoleting an operation. For the client, it means that the operation MUST NOT be sent to the server. For the server, an NFS error can be returned as opposed to "dropping" the request as an XDR decode error. This approach allows for the obsolescence of an operation while maintaining its structure so that a future minor version can reintroduce the operation.
指定一个操作不能被实现等同于淘汰一个操作。对于客户端，这意味着操作不能发送到服务器。对于服务器，可以返回NFS错误，而不是作为XDR解码错误“删除”请求。这种方法允许在保持其结构的同时淘汰操作，以便将来的次要版本可以重新引入操作。
1. Minor versions may declare that an attribute MUST NOT be implemented.
1. 次要版本可能声明不得实现属性。
2. Minor versions may declare that a flag bit or enumeration value MUST NOT be implemented.
2. 次要版本可能声明不得实现标志位或枚举值。
9. Minor versions may downgrade features from REQUIRED to RECOMMENDED, or RECOMMENDED to OPTIONAL.
9. 次要版本可能会将功能从“必需”降级为“推荐”，或从“推荐”降级为“可选”。
10. Minor versions may upgrade features from OPTIONAL to RECOMMENDED, or RECOMMENDED to REQUIRED.
10. 次要版本可以将功能从可选升级到推荐，或从推荐升级到必需。
11. A client and server that support minor version X SHOULD support minor versions zero through X-1 as well.
11. 支持次要版本X的客户端和服务器也应该支持次要版本零到X-1。
12. Except for infrastructural changes, a minor version must not introduce REQUIRED new features.
12. 除基础设施变更外，次要版本不得引入所需的新功能。
This rule allows for the introduction of new functionality and forces the use of implementation experience before designating a feature as REQUIRED. On the other hand, some classes of features are infrastructural and have broad effects. Allowing infrastructural features to be RECOMMENDED or OPTIONAL complicates implementation of the minor version.
此规则允许引入新功能，并强制在指定所需功能之前使用实现经验。另一方面，某些类别的功能是基础设施，具有广泛的影响。允许推荐或选择基础设施功能会使次要版本的实现复杂化。
13. A client MUST NOT attempt to use a stateid, filehandle, or similar returned object from the COMPOUND procedure with minor version X for another COMPOUND procedure with minor version Y, where X != Y.
13. 客户端不得尝试将次要版本为X的复合过程中的stateid、filehandle或类似返回对象用于次要版本为Y的另一个复合过程，其中X！=Y
As described in Section 2.2.1.1.1.1, NFSv4.1 relies on RPC for identification, authentication, integrity, and privacy. NFSv4.1 itself provides or enables additional security services as described in the next several subsections.
如第2.2.1.1.1.1节所述，NFSv4.1依赖RPC进行识别、认证、完整性和隐私。NFSv4.1本身提供或启用其他安全服务，如以下几个小节所述。
Authorization to access a file object via an NFSv4.1 operation is ultimately determined by the NFSv4.1 server. A client can predetermine its access to a file object via the OPEN (Section 18.16) and the ACCESS (Section 18.1) operations.
通过NFSv4.1操作访问文件对象的授权最终由NFSv4.1服务器决定。客户机可以通过OPEN（第18.16节）和access（第18.1节）操作预先确定其对文件对象的访问。
Principals with appropriate access rights can modify the authorization on a file object via the SETATTR (Section 18.30) operation. Attributes that affect access rights include mode, owner, owner_group, acl, dacl, and sacl. See Section 5.
具有适当访问权限的主体可以通过SETATTR（第18.30节）操作修改对文件对象的授权。影响访问权限的属性包括模式、所有者、所有者组、acl、dacl和sacl。见第5节。
NFSv4.1 provides auditing on a per-file object basis, via the acl and sacl attributes as described in Section 6. It is outside the scope of this specification to specify audit log formats or management policies.
NFSv4.1通过第6节所述的acl和sacl属性，以每个文件对象为基础提供审计。指定审核日志格式或管理策略超出了本规范的范围。
NFSv4.1 provides alarm control on a per-file object basis, via the acl and sacl attributes as described in Section 6. Alarms may serve as the basis for intrusion detection. It is outside the scope of this specification to specify heuristics for detecting intrusion via alarms.
NFSv4.1通过第6节所述的acl和sacl属性，以每个文件对象为基础提供报警控制。警报可以作为入侵检测的基础。指定通过报警检测入侵的启发式方法不在本规范的范围内。
NFSv4.1 works over Remote Direct Memory Access (RDMA) and non-RDMA-based transports with the following attributes:
NFSv4.1通过具有以下属性的远程直接内存访问（RDMA）和非基于RDMA的传输工作：
o The transport supports reliable delivery of data, which NFSv4.1 requires but neither NFSv4.1 nor RPC has facilities for ensuring [34].
o 传输支持可靠的数据传输，这是NFSv4.1所要求的，但NFSv4.1和RPC都没有确保数据传输的设施[34]。
o The transport delivers data in the order it was sent. Ordered delivery simplifies detection of transmit errors, and simplifies the sending of arbitrary sized requests and responses via the record marking protocol [3].
o 传输按发送顺序发送数据。有序交付简化了传输错误的检测，简化了通过记录标记协议发送任意大小的请求和响应[3]。
Where an NFSv4.1 implementation supports operation over the IP network protocol, any transport used between NFS and IP MUST be among the IETF-approved congestion control transport protocols. At the time this document was written, the only two transports that had the above attributes were TCP and the Stream Control Transmission Protocol (SCTP). To enhance the possibilities for interoperability, an NFSv4.1 implementation MUST support operation over the TCP transport protocol.
如果NFSv4.1实现支持通过IP网络协议进行操作，则NFS和IP之间使用的任何传输必须在IETF批准的拥塞控制传输协议中。在编写本文档时，只有TCP和流控制传输协议（SCTP）具有上述属性。为了增强互操作性的可能性，NFSv4.1实现必须支持TCP传输协议上的操作。
Even if NFSv4.1 is used over a non-IP network protocol, it is RECOMMENDED that the transport support congestion control.
即使NFSv4.1通过非IP网络协议使用，建议传输支持拥塞控制。
It is permissible for a connectionless transport to be used under NFSv4.1; however, reliable and in-order delivery of data combined with congestion control by the connectionless transport is REQUIRED. As a consequence, UDP by itself MUST NOT be used as an NFSv4.1 transport. NFSv4.1 assumes that a client transport address and server transport address used to send data over a transport together constitute a connection, even if the underlying transport eschews the concept of a connection.
允许根据NFSv4.1使用无连接运输工具；但是，需要通过无连接传输结合拥塞控制可靠有序地传输数据。因此，UDP本身不能用作NFSv4.1传输。NFSv4.1假定用于通过传输发送数据的客户端传输地址和服务器传输地址共同构成连接，即使底层传输避开了连接的概念。
If a connection-oriented transport (e.g., TCP) is used, the client and server SHOULD use long-lived connections for at least three reasons:
如果使用面向连接的传输（如TCP），客户端和服务器应使用长寿命连接，原因至少有三个：
1. This will prevent the weakening of the transport's congestion control mechanisms via short-lived connections.
1. 这将防止通过短命连接削弱交通的拥塞控制机制。
2. This will improve performance for the WAN environment by eliminating the need for connection setup handshakes.
2. 这将通过消除连接设置握手的需要来提高WAN环境的性能。
3. The NFSv4.1 callback model differs from NFSv4.0, and requires the client and server to maintain a client-created backchannel (see Section 2.10.3.1) for the server to use.
3. NFSv4.1回调模型不同于NFSv4.0，需要客户端和服务器维护客户端创建的后台通道（参见第2.10.3.1节），以便服务器使用。
In order to reduce congestion, if a connection-oriented transport is used, and the request is not the NULL procedure:
为了减少拥塞，如果使用了面向连接的传输，并且请求不是空过程：
o A requester MUST NOT retry a request unless the connection the request was sent over was lost before the reply was received.
o 请求者不得重试请求，除非发送请求的连接在收到答复之前丢失。
o A replier MUST NOT silently drop a request, even if the request is a retry. (The silent drop behavior of RPCSEC_GSS [4] does not apply because this behavior happens at the RPCSEC_GSS layer, a lower layer in the request processing.) Instead, the replier SHOULD return an appropriate error (see Section 2.10.6.1), or it MAY disconnect the connection.
o 即使请求是重试请求，回复者也不能静默地删除请求。（RPCSEC_GSS[4]的静默丢弃行为不适用，因为此行为发生在RPCSEC_GSS层，即请求处理的较低层）。相反，应答器应返回适当的错误（请参阅第2.10.6.1节），否则可能会断开连接。
When sending a reply, the replier MUST send the reply to the same full network address (e.g., if using an IP-based transport, the source port of the requester is part of the full network address) from which the requester sent the request. If using a connection-oriented transport, replies MUST be sent on the same connection from which the request was received.
发送回复时，回复者必须将回复发送到请求者发送请求的相同完整网络地址（例如，如果使用基于IP的传输，请求者的源端口是完整网络地址的一部分）。如果使用面向连接的传输，则必须在接收请求的同一连接上发送回复。
If a connection is dropped after the replier receives the request but before the replier sends the reply, the replier might have a pending reply. If a connection is established with the same source and destination full network address as the dropped connection, then the replier MUST NOT send the reply until the requester retries the request. The reason for this prohibition is that the requester MAY retry a request over a different connection (provided that connection is associated with the original request's session).
如果在应答器接收到请求后但在应答器发送应答之前断开连接，则应答器可能有一个挂起的应答。如果使用与断开连接相同的源和目标完整网络地址建立连接，则应答器在请求者重试请求之前不得发送应答。此禁止的原因是请求者可以通过不同的连接重试请求（前提是该连接与原始请求的会话相关联）。
When using RDMA transports, there are other reasons for not tolerating retries over the same connection:
使用RDMA传输时，不允许在同一连接上重试还有其他原因：
o RDMA transports use "credits" to enforce flow control, where a credit is a right to a peer to transmit a message. If one peer were to retransmit a request (or reply), it would consume an additional credit. If the replier retransmitted a reply, it would certainly result in an RDMA connection loss, since the requester would typically only post a single receive buffer for each request. If the requester retransmitted a request, the additional credit consumed on the server might lead to RDMA connection failure unless the client accounted for it and decreased its available credit, leading to wasted resources.
o RDMA传输使用“信用”强制流控制，信用是对等方传输消息的权利。如果一个对等方重新传输一个请求（或回复），它将消耗额外的积分。如果应答器重新传输应答，肯定会导致RDMA连接丢失，因为请求者通常只为每个请求发布一个接收缓冲区。如果请求者重新传输了一个请求，服务器上消耗的额外信用可能会导致RDMA连接失败，除非客户端对此进行了说明并减少了其可用信用，从而导致资源浪费。
o RDMA credits present a new issue to the reply cache in NFSv4.1. The reply cache may be used when a connection within a session is lost, such as after the client reconnects. Credit information is a dynamic property of the RDMA connection, and stale values must not be replayed from the cache. This implies that the reply cache contents must not be blindly used when replies are sent from it, and credit information appropriate to the channel must be refreshed by the RPC layer.
o RDMA积分为NFSv4.1中的应答缓存提供了一个新问题。当会话中的连接丢失时，例如在客户端重新连接之后，可以使用应答缓存。信用信息是RDMA连接的动态属性，不能从缓存中重放过时的值。这意味着在从应答缓存中发送应答时，不能盲目使用应答缓存内容，并且RPC层必须刷新适合于通道的信用信息。
In addition, as described in Section 2.10.6.2, while a session is active, the NFSv4.1 requester MUST NOT stop waiting for a reply.
此外，如第2.10.6.2节所述，当会话处于活动状态时，NFSv4.1请求者不得停止等待回复。
Historically, NFSv3 servers have listened over TCP port 2049. The registered port 2049 [35] for the NFS protocol should be the default configuration. NFSv4.1 clients SHOULD NOT use the RPC binding protocols as described in [36].
过去，NFSv3服务器通过TCP端口2049侦听。NFS协议的注册端口2049[35]应为默认配置。NFSv4.1客户端不应使用[36]中所述的RPC绑定协议。
NFSv4.1 clients and servers MUST support and MUST use the session feature as described in this section.
NFSv4.1客户端和服务器必须支持并使用本节所述的会话功能。
Previous versions and minor versions of NFS have suffered from the following:
NFS的早期版本和次要版本存在以下问题：
o Lack of support for Exactly Once Semantics (EOS). This includes lack of support for EOS through server failure and recovery.
o 缺少对精确一次语义（EOS）的支持。这包括通过服务器故障和恢复缺乏对EOS的支持。
o Limited callback support, including no support for sending callbacks through firewalls, and races between replies to normal requests and callbacks.
o 有限的回调支持，包括不支持通过防火墙发送回调，以及对正常请求的回复和回调之间的竞争。
o Limited trunking over multiple network paths.
o 多条网络路径上的有限中继。
o Requiring machine credentials for fully secure operation.
o 需要计算机凭据才能进行完全安全的操作。
Through the introduction of a session, NFSv4.1 addresses the above shortfalls with practical solutions:
NFSv4.1通过引入一个会话，用实用的解决方案解决了上述不足：
o EOS is enabled by a reply cache with a bounded size, making it feasible to keep the cache in persistent storage and enable EOS through server failure and recovery. One reason that previous revisions of NFS did not support EOS was because some EOS approaches often limited parallelism. As will be explained in Section 2.10.6, NFSv4.1 supports both EOS and unlimited parallelism.
o EOS由大小有限的应答缓存启用，因此可以将缓存保留在持久性存储中，并通过服务器故障和恢复启用EOS。以前的NFS版本不支持EOS的一个原因是，某些EOS方法常常限制并行性。如第2.10.6节所述，NFSv4.1支持EOS和无限并行。
o The NFSv4.1 client (defined in Section 1.6, Paragraph 2) creates transport connections and provides them to the server to use for sending callback requests, thus solving the firewall issue (Section 18.34). Races between responses from client requests and
o NFSv4.1客户端（定义见第1.6节第2段）创建传输连接，并将其提供给服务器用于发送回调请求，从而解决防火墙问题（第18.34节）。来自客户端请求的响应与来自
callbacks caused by the requests are detected via the session's sequencing properties that are a consequence of EOS (Section 2.10.6.3).
请求引起的回调通过会话的序列属性进行检测，该属性是EOS的结果（第2.10.6.3节）。
o The NFSv4.1 client can associate an arbitrary number of connections with the session, and thus provide trunking (Section 2.10.5).
o NFSv4.1客户端可以将任意数量的连接与会话相关联，从而提供中继（第2.10.5节）。
o The NFSv4.1 client and server produces a session key independent of client and server machine credentials which can be used to compute a digest for protecting critical session management operations (Section 2.10.8.3).
o NFSv4.1客户端和服务器生成独立于客户端和服务器计算机凭据的会话密钥，可用于计算摘要以保护关键会话管理操作（第2.10.8.3节）。
o The NFSv4.1 client can also create secure RPCSEC_GSS contexts for use by the session's backchannel that do not require the server to authenticate to a client machine principal (Section 2.10.8.2).
o NFSv4.1客户端还可以创建安全的RPCSEC_GSS上下文，供会话的反向通道使用，而不需要服务器向客户端计算机主体进行身份验证（第2.10.8.2节）。
A session is a dynamically created, long-lived server object created by a client and used over time from one or more transport connections. Its function is to maintain the server's state relative to the connection(s) belonging to a client instance. This state is entirely independent of the connection itself, and indeed the state exists whether or not the connection exists. A client may have one or more sessions associated with it so that client-associated state may be accessed using any of the sessions associated with that client's client ID, when connections are associated with those sessions. When no connections are associated with any of a client ID's sessions for an extended time, such objects as locks, opens, delegations, layouts, etc. are subject to expiration. The session serves as an object representing a means of access by a client to the associated client state on the server, independent of the physical means of access to that state.
会话是由客户端创建的动态创建的、长期存在的服务器对象，通过一个或多个传输连接随时间使用。它的功能是维护服务器相对于属于客户端实例的连接的状态。此状态完全独立于连接本身，并且无论连接是否存在，该状态都确实存在。客户机可以具有与其关联的一个或多个会话，以便当连接与这些会话关联时，可以使用与该客户机的客户机ID关联的任何会话来访问客户机关联状态。如果在较长时间内没有连接与任何客户端ID的会话相关联，则锁定、打开、委派、布局等对象将过期。会话用作表示客户端访问服务器上关联客户端状态的方式的对象，独立于访问该状态的物理方式。
A single client may create multiple sessions. A single session MUST NOT serve multiple clients.
一个客户端可以创建多个会话。单个会话不能服务于多个客户端。
Sessions are part of NFSv4.1 and not NFSv4.0. Normally, a major infrastructure change such as sessions would require a new major version number to an Open Network Computing (ONC) RPC program like NFS. However, because NFSv4 encapsulates its functionality in a single procedure, COMPOUND, and because COMPOUND can support an arbitrary number of operations, sessions have been added to NFSv4.1 with little difficulty. COMPOUND includes a minor version number field, and for NFSv4.1 this minor version is set to 1. When the NFSv4 server processes a COMPOUND with the minor version set to 1, it expects a different set of operations than it does for NFSv4.0.
会话是NFSv4.1的一部分，而不是NFSv4.0。通常情况下，诸如会话之类的主要基础结构更改需要开放网络计算（ONC）RPC程序（如NFS）的新主要版本号。然而，由于NFSv4将其功能封装在一个过程component中，并且component可以支持任意数量的操作，因此将会话添加到NFSv4.1并不困难。复合物包括一个次要版本号字段，对于NFSv4.1，该次要版本设置为1。当NFSv4服务器处理次要版本设置为1的化合物时，它需要一组与NFSv4.0不同的操作。
NFSv4.1 defines the SEQUENCE operation, which is required for every COMPOUND that operates over an established session, with the exception of some session administration operations, such as DESTROY_SESSION (Section 18.37).
NFSv4.1定义了序列操作，该操作是在已建立会话上运行的每个化合物所必需的，但某些会话管理操作除外，例如销毁会话（第18.37节）。
In NFSv4.1, when the SEQUENCE operation is present, it MUST be the first operation in the COMPOUND procedure. The primary purpose of SEQUENCE is to carry the session identifier. The session identifier associates all other operations in the COMPOUND procedure with a particular session. SEQUENCE also contains required information for maintaining EOS (see Section 2.10.6). Session-enabled NFSv4.1 COMPOUND requests thus have the form:
在NFSv4.1中，当序列操作存在时，它必须是复合程序中的第一个操作。SEQUENCE的主要目的是携带会话标识符。会话标识符将复合过程中的所有其他操作与特定会话相关联。序列还包含维护EOS所需的信息（见第2.10.6节）。因此，启用会话的NFSv4.1复合请求的形式如下：
+-----+--------------+-----------+------------+-----------+----
| tag | minorversion | numops |SEQUENCE op | op + args | ...
| | (== 1) | (limited) | + args | |
+-----+--------------+-----------+------------+-----------+----
+-----+--------------+-----------+------------+-----------+----
| tag | minorversion | numops |SEQUENCE op | op + args | ...
| | (== 1) | (limited) | + args | |
+-----+--------------+-----------+------------+-----------+----
and the replies have the form:
答复的形式如下：
+------------+-----+--------+-------------------------------+--//
|last status | tag | numres |status + SEQUENCE op + results | //
+------------+-----+--------+-------------------------------+--//
//-----------------------+----
// status + op + results | ...
//-----------------------+----
+------------+-----+--------+-------------------------------+--//
|last status | tag | numres |status + SEQUENCE op + results | //
+------------+-----+--------+-------------------------------+--//
//-----------------------+----
// status + op + results | ...
//-----------------------+----
A CB_COMPOUND procedure request and reply has a similar form to COMPOUND, but instead of a SEQUENCE operation, there is a CB_SEQUENCE operation. CB_COMPOUND also has an additional field called "callback_ident", which is superfluous in NFSv4.1 and MUST be ignored by the client. CB_SEQUENCE has the same information as SEQUENCE, and also includes other information needed to resolve callback races (Section 2.10.6.3).
CB_复合过程request and reply的形式与component类似，但它不是序列操作，而是CB_序列操作。CB_component还有一个名为“callback_ident”的附加字段，这在NFSv4.1中是多余的，客户端必须忽略。CB_序列具有与序列相同的信息，还包括解决回调争用所需的其他信息（第2.10.6.3节）。
Each client ID (Section 2.4) can have zero or more active sessions. A client ID and associated session are required to perform file access in NFSv4.1. Each time a session is used (whether by a client sending a request to the server or the client replying to a callback request from the server), the state leased to its associated client ID is automatically renewed.
每个客户端ID（第2.4节）可以有零个或多个活动会话。在NFSv4.1中执行文件访问需要客户端ID和相关会话。每次使用会话时（无论是客户端向服务器发送请求，还是客户端答复服务器的回调请求），都会自动续订租给其关联客户端ID的状态。
State (which can consist of share reservations, locks, delegations, and layouts (Section 1.7.4)) is tied to the client ID. Client state is not tied to any individual session. Successive state changing operations from a given state owner MAY go over different sessions, provided the session is associated with the same client ID. A callback MAY arrive over a different session than that of the request that originally acquired the state pertaining to the callback. For example, if session A is used to acquire a delegation, a request to recall the delegation MAY arrive over session B if both sessions are associated with the same client ID. Sections 2.10.8.1 and 2.10.8.2 discuss the security considerations around callbacks.
状态（可包括共享保留、锁、委托和布局（第1.7.4节））与客户端ID绑定。客户端状态不与任何单个会话绑定。来自给定状态所有者的连续状态更改操作可能会经过不同的会话，前提是会话与相同的客户端ID相关联。回调可能会通过不同的会话到达，而不是通过最初获取回调状态的请求的会话到达。例如，如果会话A用于获取委派，则如果两个会话都与相同的客户端ID关联，则调用委派的请求可能会在会话B期间到达。第2.10.8.1节和第2.10.8.2节讨论了有关回调的安全注意事项。
A channel is not a connection. A channel represents the direction ONC RPC requests are sent.
通道不是连接。通道表示ONC RPC请求的发送方向。
Each session has one or two channels: the fore channel and the backchannel. Because there are at most two channels per session, and because each channel has a distinct purpose, channels are not assigned identifiers.
每个会话有一个或两个通道：前通道和后通道。因为每个会话最多有两个通道，而且每个通道都有不同的用途，所以没有为通道分配标识符。
The fore channel is used for ordinary requests from the client to the server, and carries COMPOUND requests and responses. A session always has a fore channel.
前端通道用于从客户端到服务器的普通请求，并承载复合请求和响应。会话总是有一个前置通道。
The backchannel is used for callback requests from server to client, and carries CB_COMPOUND requests and responses. Whether or not there is a backchannel is a decision made by the client; however, many features of NFSv4.1 require a backchannel. NFSv4.1 servers MUST support backchannels.
反向通道用于从服务器到客户端的回调请求，并承载CB_复合请求和响应。是否存在反向通道由客户决定；但是，NFSv4.1的许多功能都需要反向通道。NFSv4.1服务器必须支持反向通道。
Each session has resources for each channel, including separate reply caches (see Section 2.10.6.1). Note that even the backchannel requires a reply cache (or, at least, a slot table in order to detect retries) because some callback operations are nonidempotent.
每个会话都有每个通道的资源，包括单独的应答缓存（见第2.10.6.1节）。请注意，由于某些回调操作是非幂等的，因此即使是反向通道也需要一个应答缓存（或者，至少是一个插槽表来检测重试）。
Each channel is associated with zero or more transport connections (whether of the same transport protocol or different transport protocols). A connection can be associated with one channel or both channels of a session; the client and server negotiate whether a connection will carry traffic for one channel or both channels via the CREATE_SESSION (Section 18.36) and the BIND_CONN_TO_SESSION (Section 18.34) operations. When a session is created via CREATE_SESSION, the connection that transported the CREATE_SESSION request is automatically associated with the fore channel, and
每个通道与零个或多个传输连接相关联（无论是相同的传输协议还是不同的传输协议）。连接可以与会话的一个通道或两个通道相关联；客户机和服务器通过CREATE_会话（第18.36节）和BIND_CONN_TO_会话（第18.34节）操作协商连接是为一个通道还是两个通道传输流量。当通过CREATE_会话创建会话时，传输CREATE_会话请求的连接将自动与前频道关联，并且
optionally the backchannel. If the client specifies no state protection (Section 18.35) when the session is created, then when SEQUENCE is transmitted on a different connection, the connection is automatically associated with the fore channel of the session specified in the SEQUENCE operation.
可以选择反向通道。如果创建会话时客户端未指定状态保护（第18.35节），则当在不同连接上传输序列时，该连接将自动与序列操作中指定的会话前通道相关联。
A connection's association with a session is not exclusive. A connection associated with the channel(s) of one session may be simultaneously associated with the channel(s) of other sessions including sessions associated with other client IDs.
连接与会话的关联不是独占的。与一个会话的信道相关联的连接可以同时与其他会话的信道相关联，包括与其他客户端id相关联的会话。
It is permissible for connections of multiple transport types to be associated with the same channel. For example, both TCP and RDMA connections can be associated with the fore channel. In the event an RDMA and non-RDMA connection are associated with the same channel, the maximum number of slots SHOULD be at least one more than the total number of RDMA credits (Section 2.10.6.1). This way, if all RDMA credits are used, the non-RDMA connection can have at least one outstanding request. If a server supports multiple transport types, it MUST allow a client to associate connections from each transport to a channel.
允许多个传输类型的连接与同一通道相关联。例如，TCP和RDMA连接都可以与前通道相关联。如果RDMA和非RDMA连接与同一信道相关联，则插槽的最大数量应至少比RDMA信用总数多一个（第2.10.6.1节）。这样，如果使用了所有RDMA信用，则非RDMA连接可以至少有一个未完成的请求。如果服务器支持多种传输类型，则必须允许客户端将从每个传输到通道的连接关联起来。
It is permissible for a connection of one type of transport to be associated with the fore channel, and a connection of a different type to be associated with the backchannel.
允许一种类型的运输连接与前通道相关联，另一种类型的运输连接与后通道相关联。
Servers each specify a server scope value in the form of an opaque string eir_server_scope returned as part of the results of an EXCHANGE_ID operation. The purpose of the server scope is to allow a group of servers to indicate to clients that a set of servers sharing the same server scope value has arranged to use compatible values of otherwise opaque identifiers. Thus, the identifiers generated by one server of that set may be presented to another of that same scope.
每个服务器都以不透明字符串的形式指定服务器作用域值。eir_服务器作用域作为EXCHANGE_ID操作结果的一部分返回。服务器作用域的目的是允许一组服务器向客户端指示共享相同服务器作用域值的一组服务器已安排使用其他不透明标识符的兼容值。因此，由该集合的一个服务器生成的标识符可以呈现给该相同范围的另一个服务器。
The use of such compatible values does not imply that a value generated by one server will always be accepted by another. In most cases, it will not. However, a server will not accept a value generated by another inadvertently. When it does accept it, it will be because it is recognized as valid and carrying the same meaning as on another server of the same scope.
使用此类兼容值并不意味着一台服务器生成的值总是会被另一台服务器接受。在大多数情况下，它不会。但是，服务器不会接受其他服务器无意中生成的值。当它接受它时，这将是因为它被认为是有效的，并且与同一范围的另一台服务器上的内容相同。
When servers are of the same server scope, this compatibility of values applies to the follow identifiers:
当服务器属于相同的服务器作用域时，此值的兼容性适用于以下标识符：
o Filehandle values. A filehandle value accepted by two servers of the same server scope denotes the same object. A WRITE operation sent to one server is reflected immediately in a READ sent to the other, and locks obtained on one server conflict with those requested on the other.
o 文件句柄值。同一服务器作用域的两台服务器接受的filehandle值表示同一对象。发送到一台服务器的写操作立即反映在发送到另一台服务器的读操作中，并且在一台服务器上获得的锁与在另一台服务器上请求的锁冲突。
o Session ID values. A session ID value accepted by two servers of the same server scope denotes the same session.
o 会话ID值。相同服务器作用域的两台服务器接受的会话ID值表示相同的会话。
o Client ID values. A client ID value accepted as valid by two servers of the same server scope is associated with two clients with the same client owner and verifier.
o 客户端ID值。具有相同服务器作用域的两台服务器接受为有效的客户端ID值与具有相同客户端所有者和验证器的两台客户端相关联。
o State ID values. A state ID value is recognized as valid when the corresponding client ID is recognized as valid. If the same stateid value is accepted as valid on two servers of the same scope and the client IDs on the two servers represent the same client owner and verifier, then the two stateid values designate the same set of locks and are for the same file.
o 状态ID值。当相应的客户端ID被识别为有效时，状态ID值被识别为有效。如果相同的stateid值在相同作用域的两台服务器上被接受为有效，并且两台服务器上的客户端ID表示相同的客户端所有者和验证器，则这两个stateid值指定相同的锁集，并且用于相同的文件。
o Server owner values. When the server scope values are the same, server owner value may be validly compared. In cases where the server scope values are different, server owner values are treated as different even if they contain all identical bytes.
o 服务器所有者值。当服务器作用域值相同时，可以有效地比较服务器所有者值。在服务器作用域值不同的情况下，服务器所有者值将被视为不同的值，即使它们包含所有相同的字节。
The coordination among servers required to provide such compatibility can be quite minimal, and limited to a simple partition of the ID space. The recognition of common values requires additional implementation, but this can be tailored to the specific situations in which that recognition is desired.
提供这种兼容性所需的服务器之间的协调可能非常小，并且仅限于ID空间的简单分区。公共价值的识别需要额外的实现，但这可以根据需要识别的特定情况进行调整。
Clients will have occasion to compare the server scope values of multiple servers under a number of circumstances, each of which will be discussed under the appropriate functional section:
客户将有机会在多种情况下比较多台服务器的服务器范围值，每种情况将在适当的功能部分中讨论：
o When server owner values received in response to EXCHANGE_ID operations sent to multiple network addresses are compared for the purpose of determining the validity of various forms of trunking, as described in Section 2.10.5.
o 如第2.10.5节所述，为了确定各种中继形式的有效性，比较针对发送到多个网络地址的EXCHANGE_ID操作而收到的服务器所有者值时。
o When network or server reconfiguration causes the same network address to possibly be directed to different servers, with the necessity for the client to determine when lock reclaim should be attempted, as described in Section 8.4.2.1.
o 如第8.4.2.1节所述，当网络或服务器重新配置导致相同的网络地址可能定向到不同的服务器时，客户端需要确定何时应尝试锁回收。
o When file system migration causes the transfer of responsibility for a file system between servers and the client needs to determine whether state has been transferred with the file system
o 当文件系统迁移导致服务器之间的文件系统责任转移时，客户端需要确定状态是否已随文件系统一起转移
(as described in Section 11.7.7) or whether the client needs to reclaim state on a similar basis as in the case of server restart, as described in Section 8.4.2.
（如第11.7.7节所述）或客户端是否需要在与服务器重启类似的基础上恢复状态，如第8.4.2节所述。
When two replies from EXCHANGE_ID, each from two different server network addresses, have the same server scope, there are a number of ways a client can validate that the common server scope is due to two servers cooperating in a group.
当来自EXCHANGE_ID的两个答复（每个答复来自两个不同的服务器网络地址）具有相同的服务器作用域时，客户机可以通过多种方式验证公共服务器作用域是否是由于两台服务器在一个组中协作所致。
o If both EXCHANGE_ID requests were sent with RPCSEC_GSS authentication and the server principal is the same for both targets, the equality of server scope is validated. It is RECOMMENDED that two servers intending to share the same server scope also share the same principal name.
o 如果两个EXCHANGE_ID请求均通过RPCSEC_GSS身份验证发送，并且两个目标的服务器主体相同，则验证服务器作用域的平等性。建议打算共享相同服务器作用域的两台服务器也共享相同的主体名称。
o The client may accept the appearance of the second server in the fs_locations or fs_locations_info attribute for a relevant file system. For example, if there is a migration event for a particular file system or there are locks to be reclaimed on a particular file system, the attributes for that particular file system may be used. The client sends the GETATTR request to the first server for the fs_locations or fs_locations_info attribute with RPCSEC_GSS authentication. It may need to do this in advance of the need to verify the common server scope. If the client successfully authenticates the reply to GETATTR, and the GETATTR request and reply containing the fs_locations or fs_locations_info attribute refers to the second server, then the equality of server scope is supported. A client may choose to limit the use of this form of support to information relevant to the specific file system involved (e.g. a file system being migrated).
o 对于相关文件系统，客户端可以接受第二台服务器在fs_locations或fs_locations_info属性中的外观。例如，如果特定文件系统存在迁移事件，或者特定文件系统上存在要回收的锁，则可以使用该特定文件系统的属性。客户机向第一台服务器发送GETATTR请求，请求fs_位置或具有RPCSEC_GSS身份验证的fs_位置信息属性。它可能需要在验证公共服务器作用域之前执行此操作。如果客户端成功验证了对GETATTR的回复，并且包含fs_locations或fs_locations_info属性的GETATTR请求和回复引用了第二台服务器，则支持服务器作用域相等。客户可以选择将此支持形式的使用限制为与所涉及的特定文件系统（例如，正在迁移的文件系统）相关的信息。
Trunking is the use of multiple connections between a client and server in order to increase the speed of data transfer. NFSv4.1 supports two types of trunking: session trunking and client ID trunking.
中继是在客户端和服务器之间使用多个连接以提高数据传输速度。NFSv4.1支持两种类型的中继：会话中继和客户端ID中继。
NFSv4.1 servers MUST support both forms of trunking within the context of a single server network address and MUST support both forms within the context of the set of network addresses used to access a single server. NFSv4.1 servers in a clustered configuration MAY allow network addresses for different servers to use client ID trunking.
NFSv4.1服务器必须在单个服务器网络地址的上下文中支持两种形式的中继，并且必须在用于访问单个服务器的一组网络地址的上下文中支持两种形式。群集配置中的NFSv4.1服务器可能允许不同服务器的网络地址使用客户端ID中继。
Clients may use either form of trunking as long as they do not, when trunking between different server network addresses, violate the servers' mandates as to the kinds of trunking to be allowed (see
当在不同的服务器网络地址之间进行中继时，客户端可以使用任何一种中继形式，只要它们不违反服务器关于允许的中继类型的规定（请参阅
below). With regard to callback channels, the client MUST allow the server to choose among all callback channels valid for a given client ID and MUST support trunking when the connections supporting the backchannel allow session or client ID trunking to be used for callbacks.
下）。关于回调通道，客户机必须允许服务器在所有对给定客户机ID有效的回调通道中进行选择，并且当支持反向通道的连接允许会话或客户机ID中继用于回调时，必须支持中继。
Session trunking is essentially the association of multiple connections, each with potentially different target and/or source network addresses, to the same session. When the target network addresses (server addresses) of the two connections are the same, the server MUST support such session trunking. When the target network addresses are different, the server MAY indicate such support using the data returned by the EXCHANGE_ID operation (see below).
会话中继本质上是多个连接与同一会话的关联，每个连接具有可能不同的目标和/或源网络地址。当两个连接的目标网络地址（服务器地址）相同时，服务器必须支持此类会话中继。当目标网络地址不同时，服务器可以使用EXCHANGE_ID操作返回的数据指示这种支持（见下文）。
Client ID trunking is the association of multiple sessions to the same client ID. Servers MUST support client ID trunking for two target network addresses whenever they allow session trunking for those same two network addresses. In addition, a server MAY, by presenting the same major server owner ID (Section 2.5) and server scope (Section 2.10.4), allow an additional case of client ID trunking. When two servers return the same major server owner and server scope, it means that the two servers are cooperating on locking state management, which is a prerequisite for client ID trunking.
客户端ID中继是多个会话与同一客户端ID的关联。服务器必须支持两个目标网络地址的客户端ID中继，只要它们允许对这两个相同的网络地址进行会话中继。此外，通过提供相同的主要服务器所有者ID（第2.5节）和服务器作用域（第2.10.4节），服务器可以允许额外的客户端ID中继。当两台服务器返回相同的主服务器所有者和服务器作用域时，这意味着这两台服务器在锁定状态管理方面进行合作，这是客户端ID中继的先决条件。
Distinguishing when the client is allowed to use session and client ID trunking requires understanding how the results of the EXCHANGE_ID (Section 18.35) operation identify a server. Suppose a client sends EXCHANGE_IDs over two different connections, each with a possibly different target network address, but each EXCHANGE_ID operation has the same value in the eia_clientowner field. If the same NFSv4.1 server is listening over each connection, then each EXCHANGE_ID result MUST return the same values of eir_clientid, eir_server_owner.so_major_id, and eir_server_scope. The client can then treat each connection as referring to the same server (subject to verification; see Section 2.10.5.1 later in this section), and it can use each connection to trunk requests and replies. The client's choice is whether session trunking or client ID trunking applies.
区分何时允许客户端使用会话和客户端ID中继需要了解EXCHANGE_ID（第18.35节）操作的结果如何识别服务器。假设客户端通过两个不同的连接发送EXCHANGE\u ID，每个连接的目标网络地址可能不同，但每个EXCHANGE\u ID操作在eia\u clientowner字段中具有相同的值。如果相同的NFSv4.1服务器正在侦听每个连接，则每个EXCHANGE\u ID结果必须返回相同的eir\u clientid、eir\u server\u owner.so\u major\u ID和eir\u server\u scope值。然后，客户端可以将每个连接视为指向同一服务器（有待验证；请参阅本节后面的第2.10.5.1节），并且可以使用每个连接来中继请求和回复。客户端的选择是应用会话中继还是客户端ID中继。
Session Trunking. If the eia_clientowner argument is the same in two different EXCHANGE_ID requests, and the eir_clientid, eir_server_owner.so_major_id, eir_server_owner.so_minor_id, and eir_server_scope results match in both EXCHANGE_ID results, then the client is permitted to perform session trunking. If the client has no session mapping to the tuple of eir_clientid, eir_server_owner.so_major_id, eir_server_scope, and eir_server_owner.so_minor_id, then it creates the session via a CREATE_SESSION operation over one of the connections, which
会话中继。如果eia_clientowner参数在两个不同的EXCHANGE_ID请求中相同，并且eir_clientid、eir_server_owner.so_major_ID、eir_server_owner.so_minor_ID和eir_server_scope结果在两个EXCHANGE_ID结果中匹配，则允许客户端执行会话中继。如果客户端没有到eir_clientid、eir_server_owner.so_major_id、eir_server_scope和eir_server_owner.so_minor_id元组的会话映射，则它通过一个连接上的CREATE_会话操作创建会话，该操作
associates the connection to the session. If there is a session for the tuple, the client can send BIND_CONN_TO_SESSION to associate the connection to the session.
将连接与会话相关联。如果元组有会话，客户端可以发送BIND_CONN_TO_session以将连接与会话相关联。
Of course, if the client does not desire to use session trunking, it is not required to do so. It can invoke CREATE_SESSION on the connection. This will result in client ID trunking as described below. It can also decide to drop the connection if it does not choose to use trunking.
当然，如果客户端不希望使用会话中继，则不需要这样做。它可以在连接上调用CREATE_会话。这将导致客户端ID中继，如下所述。如果不选择使用中继，它还可以决定断开连接。
Client ID Trunking. If the eia_clientowner argument is the same in two different EXCHANGE_ID requests, and the eir_clientid, eir_server_owner.so_major_id, and eir_server_scope results match in both EXCHANGE_ID results, then the client is permitted to perform client ID trunking (regardless of whether the eir_server_owner.so_minor_id results match). The client can associate each connection with different sessions, where each session is associated with the same server.
客户端ID中继。如果eia_clientowner参数在两个不同的EXCHANGE_ID请求中相同，并且eir_clientid、eir_server_owner.so_major_ID和eir_server_scope结果在两个EXCHANGE_ID结果中匹配，则允许客户端执行客户端ID中继（无论eir_server_owner.so_minor_ID结果是否匹配）。客户端可以将每个连接与不同的会话相关联，其中每个会话与同一服务器相关联。
The client completes the act of client ID trunking by invoking CREATE_SESSION on each connection, using the same client ID that was returned in eir_clientid. These invocations create two sessions and also associate each connection with its respective session. The client is free to decline to use client ID trunking by simply dropping the connection at this point.
客户机通过在每个连接上调用CREATE_会话来完成客户机ID中继的操作，使用在eir_clientid中返回的相同客户机ID。这些调用创建两个会话，并将每个连接与其各自的会话相关联。客户端可以自由地拒绝使用客户端ID中继，只需在此时断开连接即可。
When doing client ID trunking, locking state is shared across sessions associated with that same client ID. This requires the server to coordinate state across sessions.
执行客户端ID中继时，锁定状态在与同一客户端ID关联的会话之间共享。这要求服务器在会话之间协调状态。
The client should be prepared for the possibility that eir_server_owner values may be different on subsequent EXCHANGE_ID requests made to the same network address, as a result of various sorts of reconfiguration events. When this happens and the changes result in the invalidation of previously valid forms of trunking, the client should cease to use those forms, either by dropping connections or by adding sessions. For a discussion of lock reclaim as it relates to such reconfiguration events, see Section 8.4.2.1.
客户端应做好准备，以防由于各种各样的重新配置事件，对同一网络地址发出的后续EXCHANGE\u ID请求可能会导致eir\u服务器\u所有者值不同。当这种情况发生并且更改导致以前有效的中继形式无效时，客户端应该停止使用这些形式，方法是断开连接或添加会话。有关与此类重新配置事件相关的锁回收的讨论，请参见第8.4.2.1节。
When two servers over two connections claim matching or partially matching eir_server_owner, eir_server_scope, and eir_clientid values, the client does not have to trust the servers' claims. The client may verify these claims before trunking traffic in the following ways:
当两个连接上的两台服务器声明匹配或部分匹配eir_服务器_所有者、eir_服务器_作用域和eir_客户端ID值时，客户端不必信任服务器的声明。客户可通过以下方式在中继流量之前验证这些声明：
o For session trunking, clients SHOULD reliably verify if connections between different network paths are in fact associated with the same NFSv4.1 server and usable on the same session, and servers MUST allow clients to perform reliable verification. When a client ID is created, the client SHOULD specify that BIND_CONN_TO_SESSION is to be verified according to the SP4_SSV or SP4_MACH_CRED (Section 18.35) state protection options. For SP4_SSV, reliable verification depends on a shared secret (the SSV) that is established via the SET_SSV (Section 18.47) operation.
o 对于会话中继，客户端应可靠地验证不同网络路径之间的连接是否与同一NFSv4.1服务器相关联并在同一会话上可用，并且服务器必须允许客户端执行可靠的验证。创建客户端ID时，客户端应指定根据SP4\U SSV或SP4\U MACH\U CRED（第18.35节）状态保护选项验证绑定连接到会话。对于SP4_SSV，可靠验证取决于通过SET_SSV（第18.47节）操作建立的共享秘密（SSV）。
When a new connection is associated with the session (via the BIND_CONN_TO_SESSION operation, see Section 18.34), if the client specified SP4_SSV state protection for the BIND_CONN_TO_SESSION operation, the client MUST send the BIND_CONN_TO_SESSION with RPCSEC_GSS protection, using integrity or privacy, and an RPCSEC_GSS handle created with the GSS SSV mechanism (Section 2.10.9).
当新连接与会话关联时（通过BIND_CONN_TO_会话操作，请参见第18.34节），如果客户端为BIND_CONN_TO_会话操作指定了SP4_SSV状态保护，则客户端必须使用完整性或隐私发送具有RPCSEC_GSS保护的BIND_CONN_TO_会话，以及使用GSS SSV机构创建的RPCSEC_GSS手柄（第2.10.9节）。
If the client mistakenly tries to associate a connection to a session of a wrong server, the server will either reject the attempt because it is not aware of the session identifier of the BIND_CONN_TO_SESSION arguments, or it will reject the attempt because the RPCSEC_GSS authentication fails. Even if the server mistakenly or maliciously accepts the connection association attempt, the RPCSEC_GSS verifier it computes in the response will not be verified by the client, so the client will know it cannot use the connection for trunking the specified session.
如果客户端错误地尝试将连接与错误服务器的会话相关联，服务器将拒绝尝试，因为它不知道BIND_CONN_to_会话参数的会话标识符，或者它将拒绝尝试，因为RPCSEC_GSS身份验证失败。即使服务器错误地或恶意地接受连接关联尝试，客户端也不会验证它在响应中计算的RPCSEC_GSS验证器，因此客户端将知道它无法使用连接中继指定的会话。
If the client specified SP4_MACH_CRED state protection, the BIND_CONN_TO_SESSION operation will use RPCSEC_GSS integrity or privacy, using the same credential that was used when the client ID was created. Mutual authentication via RPCSEC_GSS assures the client that the connection is associated with the correct session of the correct server.
如果客户端指定了SP4_MACH_CRED状态保护，则BIND_CONN_TO_会话操作将使用RPCSEC_GSS完整性或隐私，使用创建客户端ID时使用的相同凭据。通过RPCSEC_GSS的相互身份验证可确保客户端连接与正确服务器的正确会话相关联。
o For client ID trunking, the client has at least two options for verifying that the same client ID obtained from two different EXCHANGE_ID operations came from the same server. The first option is to use RPCSEC_GSS authentication when sending each EXCHANGE_ID operation. Each time an EXCHANGE_ID is sent with RPCSEC_GSS authentication, the client notes the principal name of the GSS target. If the EXCHANGE_ID results indicate that client ID trunking is possible, and the GSS targets' principal names are the same, the servers are the same and client ID trunking is allowed.
o 对于客户端ID中继，客户端至少有两个选项用于验证从两个不同EXCHANGE_ID操作获得的相同客户端ID是否来自同一服务器。第一个选项是在发送每个EXCHANGE\u ID操作时使用RPCSEC\u GSS身份验证。每次使用RPCSEC_GSS身份验证发送EXCHANGE_ID时，客户端都会记录GSS目标的主体名称。如果EXCHANGE_ID结果表明可以进行客户端ID中继，并且GSS目标的主体名称相同，则服务器相同，并且允许进行客户端ID中继。
The second option for verification is to use SP4_SSV protection. When the client sends EXCHANGE_ID, it specifies SP4_SSV protection. The first EXCHANGE_ID the client sends always has to be confirmed by a CREATE_SESSION call. The client then sends SET_SSV. Later, the client sends EXCHANGE_ID to a second destination network address different from the one the first EXCHANGE_ID was sent to. The client checks that each EXCHANGE_ID reply has the same eir_clientid, eir_server_owner.so_major_id, and eir_server_scope. If so, the client verifies the claim by sending a CREATE_SESSION operation to the second destination address, protected with RPCSEC_GSS integrity using an RPCSEC_GSS handle returned by the second EXCHANGE_ID. If the server accepts the CREATE_SESSION request, and if the client verifies the RPCSEC_GSS verifier and integrity codes, then the client has proof the second server knows the SSV, and thus the two servers are cooperating for the purposes of specifying server scope and client ID trunking.
验证的第二个选项是使用SP4_SSV保护。当客户端发送EXCHANGE\u ID时，它指定SP4\u SSV保护。客户端发送的第一个EXCHANGE\u ID必须始终通过CREATE\u会话调用进行确认。然后，客户端发送SET_SSV。之后，客户端将EXCHANGE\u ID发送到与第一个EXCHANGE\u ID发送到的目标网络地址不同的第二个目标网络地址。客户端检查每个EXCHANGE\u ID回复是否具有相同的eir\u客户端ID、eir\u服务器\u所有者、so\u主\u ID和eir\u服务器\u作用域。如果是，则客户端将通过向第二个目标地址发送CREATE_会话操作来验证声明，该地址使用第二个EXCHANGE_ID返回的RPCSEC_GSS句柄受RPCSEC_GSS完整性保护。如果服务器接受CREATE_会话请求，并且客户端验证RPCSEC_GSS验证程序和完整性代码，然后，客户机有证据证明第二台服务器知道SSV，因此这两台服务器为了指定服务器范围和客户机ID中继而进行合作。
Via the session, NFSv4.1 offers exactly once semantics (EOS) for requests sent over a channel. EOS is supported on both the fore channel and backchannel.
通过会话，NFSv4.1为通过通道发送的请求提供了一次语义（EOS）。EOS在前通道和后通道上都受支持。
Each COMPOUND or CB_COMPOUND request that is sent with a leading SEQUENCE or CB_SEQUENCE operation MUST be executed by the receiver exactly once. This requirement holds regardless of whether the request is sent with reply caching specified (see Section 2.10.6.1.3). The requirement holds even if the requester is sending the request over a session created between a pNFS data client and pNFS data server. To understand the rationale for this requirement, divide the requests into three classifications:
与前导序列或CB_序列操作一起发送的每个复合或CB_复合请求必须由接收方执行一次。无论请求是否在指定回复缓存的情况下发送（参见第2.10.6.1.3节），此要求都适用。即使请求者通过在pNFS数据客户端和pNFS数据服务器之间创建的会话发送请求，该要求仍然有效。为了解此要求的基本原理，请将请求分为三类：
o Non-idempotent requests.
o 非幂等请求。
o Idempotent modifying requests.
o 幂等修改请求。
o Idempotent non-modifying requests.
o 幂等非修改请求。
An example of a non-idempotent request is RENAME. Obviously, if a replier executes the same RENAME request twice, and the first execution succeeds, the re-execution will fail. If the replier returns the result from the re-execution, this result is incorrect. Therefore, EOS is required for non-idempotent requests.
非幂等请求的一个例子是重命名。显然，如果应答器执行相同的重命名请求两次，并且第一次执行成功，那么重新执行将失败。如果应答器返回重新执行的结果，则此结果不正确。因此，非幂等请求需要EOS。
An example of an idempotent modifying request is a COMPOUND request containing a WRITE operation. Repeated execution of the same WRITE has the same effect as execution of that WRITE a single time. Nevertheless, enforcing EOS for WRITEs and other idempotent modifying requests is necessary to avoid data corruption.
幂等修改请求的一个示例是包含写入操作的复合请求。重复执行同一次写入与执行该次写入具有相同的效果。然而，对写入和其他幂等修改请求强制执行EOS对于避免数据损坏是必要的。
Suppose a client sends WRITE A to a noncompliant server that does not enforce EOS, and receives no response, perhaps due to a network partition. The client reconnects to the server and re-sends WRITE A. Now, the server has outstanding two instances of A. The server can be in a situation in which it executes and replies to the retry of A, while the first A is still waiting in the server's internal I/O system for some resource. Upon receiving the reply to the second attempt of WRITE A, the client believes its WRITE is done so it is free to send WRITE B, which overlaps the byte-range of A. When the original A is dispatched from the server's I/O system and executed (thus the second time A will have been written), then what has been written by B can be overwritten and thus corrupted.
假设客户机向不强制EOS的不兼容服务器发送写操作，并且没有收到响应，可能是由于网络分区。客户端重新连接到服务器并重新发送写入A。现在，服务器有两个未完成的A实例。服务器可能处于这样的情况：它执行并回复A的重试，而第一个A仍在服务器的内部I/O系统中等待某些资源。在收到对第二次尝试写入A的回复后，客户端认为其写入已完成，因此可以自由发送写入B，该写入B与A的字节范围重叠。当原始A从服务器的I/O系统调度并执行时（因此，第二次写入A），然后，B写的内容可以被覆盖，从而被破坏。
An example of an idempotent non-modifying request is a COMPOUND containing SEQUENCE, PUTFH, READLINK, and nothing else. The re-execution of such a request will not cause data corruption or produce an incorrect result. Nonetheless, to keep the implementation simple, the replier MUST enforce EOS for all requests, whether or not idempotent and non-modifying.
幂等非修改请求的一个例子是包含序列、PUTFH、READLINK等的复合词。重新执行此类请求不会导致数据损坏或产生错误结果。尽管如此，为了保持实现的简单性，应答器必须对所有请求强制执行EOS，无论请求是否为幂等和非修改请求。
Note that true and complete EOS is not possible unless the server persists the reply cache in stable storage, and unless the server is somehow implemented to never require a restart (indeed, if such a server exists, the distinction between a reply cache kept in stable storage versus one that is not is one without meaning). See Section 2.10.6.5 for a discussion of persistence in the reply cache. Regardless, even if the server does not persist the reply cache, EOS improves robustness and correctness over previous versions of NFS because the legacy duplicate request/reply caches were based on the ONC RPC transaction identifier (XID). Section 2.10.6.1 explains the shortcomings of the XID as a basis for a reply cache and describes how NFSv4.1 sessions improve upon the XID.
请注意，除非服务器将应答缓存持久化到稳定存储中，并且除非服务器以某种方式实现为不需要重新启动，否则不可能实现真正完整的EOS（事实上，如果存在这样的服务器，则保持在稳定存储中的应答缓存与不保持在稳定存储中的应答缓存之间的区别是毫无意义的）。有关回复缓存中持久性的讨论，请参见第2.10.6.5节。无论如何，即使服务器没有持久化回复缓存，EOS也比以前的NFS版本提高了健壮性和正确性，因为旧的重复请求/回复缓存基于ONC RPC事务标识符（XID）。第2.10.6.1节解释了作为应答缓存基础的XID的缺点，并描述了NFSv4.1会话如何改进XID。
The RPC layer provides a transaction ID (XID), which, while required to be unique, is not convenient for tracking requests for two reasons. First, the XID is only meaningful to the requester; it cannot be interpreted by the replier except to test for equality with previously sent requests. When consulting an RPC-based duplicate request cache, the opaqueness of the XID requires a computationally expensive look up (often via a hash that includes XID and source
RPC层提供了一个事务ID（XID），虽然要求它是唯一的，但由于两个原因，它不便于跟踪请求。首先，XID只对请求者有意义；应答器不能解释它，除非测试它是否与以前发送的请求相等。在查询基于RPC的重复请求缓存时，XID的不透明性要求进行计算代价高昂的查找（通常通过包含XID和源的哈希）
address). NFSv4.1 requests use a non-opaque slot ID, which is an index into a slot table, which is far more efficient. Second, because RPC requests can be executed by the replier in any order, there is no bound on the number of requests that may be outstanding at any time. To achieve perfect EOS, using ONC RPC would require storing all replies in the reply cache. XIDs are 32 bits; storing over four billion (2^32) replies in the reply cache is not practical. In practice, previous versions of NFS have chosen to store a fixed number of replies in the cache, and to use a least recently used (LRU) approach to replacing cache entries with new entries when the cache is full. In NFSv4.1, the number of outstanding requests is bounded by the size of the slot table, and a sequence ID per slot is used to tell the replier when it is safe to delete a cached reply.
地址）。NFSv4.1请求使用非不透明的插槽ID，这是插槽表的索引，效率更高。第二，由于RPC请求可以由应答器以任何顺序执行，因此在任何时候都可能未完成的请求的数量没有限制。为了实现完美的EOS，使用ONC RPC需要将所有回复存储在回复缓存中。XID为32位；在应答缓存中存储超过40亿（2^32）个应答是不切实际的。实际上，早期版本的NFS已选择在缓存中存储固定数量的回复，并在缓存已满时使用最近最少使用（LRU）方法将缓存项替换为新项。在NFSv4.1中，未完成请求的数量受插槽表大小的限制，每个插槽的序列ID用于告诉应答器何时可以安全地删除缓存的应答。
In the NFSv4.1 reply cache, when the requester sends a new request, it selects a slot ID in the range 0..N, where N is the replier's current maximum slot ID granted to the requester on the session over which the request is to be sent. The value of N starts out as equal to ca_maxrequests - 1 (Section 18.36), but can be adjusted by the response to SEQUENCE or CB_SEQUENCE as described later in this section. The slot ID must be unused by any of the requests that the requester has already active on the session. "Unused" here means the requester has no outstanding request for that slot ID.
在NFSv4.1应答缓存中，当请求者发送新请求时，它选择范围为0..N的插槽ID，其中N是应答者在发送请求的会话上授予请求者的当前最大插槽ID。N的值开始时等于ca_maxrequests-1（第18.36节），但可通过响应本节后面所述的序列或CB_序列进行调整。请求者在会话中已处于活动状态的任何请求都必须未使用插槽ID。这里的“未使用”表示请求者对该插槽ID没有未完成的请求。
A slot contains a sequence ID and the cached reply corresponding to the request sent with that sequence ID. The sequence ID is a 32-bit unsigned value, and is therefore in the range 0..0xFFFFFFFF (2^32 - 1). The first time a slot is used, the requester MUST specify a sequence ID of one (Section 18.36). Each time a slot is reused, the request MUST specify a sequence ID that is one greater than that of the previous request on the slot. If the previous sequence ID was 0xFFFFFFFF, then the next request for the slot MUST have the sequence ID set to zero (i.e., (2^32 - 1) + 1 mod 2^32).
插槽包含序列ID和与使用该序列ID发送的请求相对应的缓存回复。序列ID是32位无符号值，因此在0..0xFFFFFFFF（2^32-1）范围内。首次使用插槽时，请求者必须指定一个序列ID（第18.36节）。每次重用插槽时，请求必须指定一个序列ID，该序列ID比插槽上的前一个请求的序列ID大一个。如果上一个序列ID是0xFFFFFF，那么下一个插槽请求必须将序列ID设置为零（即，（2^32-1）+1 mod 2^32）。
The sequence ID accompanies the slot ID in each request. It is for the critical check at the replier: it used to efficiently determine whether a request using a certain slot ID is a retransmit or a new, never-before-seen request. It is not feasible for the requester to assert that it is retransmitting to implement this, because for any given request the requester cannot know whether the replier has seen it unless the replier actually replies. Of course, if the requester has seen the reply, the requester would not retransmit.
序列ID伴随着每个请求中的插槽ID。它用于应答器上的关键检查：它用于有效地确定使用特定插槽ID的请求是重传还是新的、以前从未见过的请求。请求者断言它正在重新传输以实现这一点是不可行的，因为对于任何给定的请求，请求者都无法知道应答者是否已经看到它，除非应答者确实进行了应答。当然，如果请求者看到了回复，那么请求者不会重新传输。
The replier compares each received request's sequence ID with the last one previously received for that slot ID, to see if the new request is:
应答器将每个接收到的请求的序列ID与该插槽ID之前接收到的最后一个序列ID进行比较，以查看新请求是否为：
o A new request, in which the sequence ID is one greater than that previously seen in the slot (accounting for sequence wraparound). The replier proceeds to execute the new request, and the replier MUST increase the slot's sequence ID by one.
o 一个新的请求，其中序列ID比之前在插槽中看到的序列ID大一个（考虑序列环绕）。应答器继续执行新请求，应答器必须将插槽的序列ID增加1。
o A retransmitted request, in which the sequence ID is equal to that currently recorded in the slot. If the original request has executed to completion, the replier returns the cached reply. See Section 2.10.6.2 for direction on how the replier deals with retries of requests that are still in progress.
o 一种重新传输的请求，其中序列ID等于时隙中当前记录的序列ID。如果原始请求已执行到完成，应答器将返回缓存的应答。请参阅第2.10.6.2节，了解应答器如何处理仍在进行的请求重试。
o A misordered retry, in which the sequence ID is less than (accounting for sequence wraparound) that previously seen in the slot. The replier MUST return NFS4ERR_SEQ_MISORDERED (as the result from SEQUENCE or CB_SEQUENCE).
o 顺序错误的重试，其中序列ID小于先前在插槽中看到的（考虑到序列环绕）。应答者必须返回NFS4ERR_SEQ_MISORDERED（作为序列或CB_序列的结果）。
o A misordered new request, in which the sequence ID is two or more than (accounting for sequence wraparound) that previously seen in the slot. Note that because the sequence ID MUST wrap around to zero once it reaches 0xFFFFFFFF, a misordered new request and a misordered retry cannot be distinguished. Thus, the replier MUST return NFS4ERR_SEQ_MISORDERED (as the result from SEQUENCE or CB_SEQUENCE).
o 顺序错误的新请求，其中序列ID比先前在插槽中看到的序列ID多两个或更多（考虑到序列环绕）。请注意，由于序列ID在到达0xFFFFFF后必须环绕为零，因此无法区分顺序错误的新请求和顺序错误的重试。因此，应答器必须返回错误排序的NFS4ERR_SEQ_（作为序列或CB_序列的结果）。
Unlike the XID, the slot ID is always within a specific range; this has two implications. The first implication is that for a given session, the replier need only cache the results of a limited number of COMPOUND requests. The second implication derives from the first, which is that unlike XID-indexed reply caches (also known as duplicate request caches - DRCs), the slot ID-based reply cache cannot be overflowed. Through use of the sequence ID to identify retransmitted requests, the replier does not need to actually cache the request itself, reducing the storage requirements of the reply cache further. These facilities make it practical to maintain all the required entries for an effective reply cache.
与XID不同，插槽ID始终在特定范围内；这有两个含义。第一个含义是，对于给定会话，应答器只需缓存有限数量的复合请求的结果。第二个含义源自第一个含义，即与XID索引回复缓存（也称为重复请求缓存-DRC）不同，基于插槽ID的回复缓存不能溢出。通过使用序列ID来识别重新传输的请求，应答器不需要实际缓存请求本身，从而进一步降低了应答缓存的存储需求。这些功能使维护有效回复缓存所需的所有条目变得切实可行。
The slot ID, sequence ID, and session ID therefore take over the traditional role of the XID and source network address in the replier's reply cache implementation. This approach is considerably more portable and completely robust -- it is not subject to the reassignment of ports as clients reconnect over IP networks. In addition, the RPC XID is not used in the reply cache, enhancing robustness of the cache in the face of any rapid reuse of XIDs by the requester. While the replier does not care about the XID for the purposes of reply cache management (but the replier MUST return the same XID that was in the request), nonetheless there are considerations for the XID in NFSv4.1 that are the same as all other
因此，插槽ID、序列ID和会话ID在应答器的应答缓存实现中接管了XID和源网络地址的传统角色。这种方法具有更大的可移植性和完全的健壮性——当客户端通过IP网络重新连接时，它不需要重新分配端口。此外，RPC XID不用于应答缓存中，从而增强了缓存在请求者快速重用XID时的健壮性。虽然应答器不关心用于应答缓存管理的XID（但应答器必须返回请求中的相同XID），但是NFSv4.1中的XID考虑事项与所有其他注意事项相同
previous versions of NFS. The RPC XID remains in each message and needs to be formulated in NFSv4.1 requests as in any other ONC RPC request. The reasons include:
NFS的早期版本。RPC XID保留在每条消息中，需要在NFSv4.1请求中制定，就像在任何其他ONC RPC请求中一样。原因包括:
o The RPC layer retains its existing semantics and implementation.
o RPC层保留其现有的语义和实现。
o The requester and replier must be able to interoperate at the RPC layer, prior to the NFSv4.1 decoding of the SEQUENCE or CB_SEQUENCE operation.
o 在NFSv4.1解码序列或CB_序列操作之前，请求者和应答者必须能够在RPC层进行互操作。
o If an operation is being used that does not start with SEQUENCE or CB_SEQUENCE (e.g., BIND_CONN_TO_SESSION), then the RPC XID is needed for correct operation to match the reply to the request.
o 如果正在使用的操作不是以序列或CB_序列开始的（例如，将_CONN_绑定到_会话），则需要RPC XID进行正确的操作，以匹配对请求的回复。
o The SEQUENCE or CB_SEQUENCE operation may generate an error. If so, the embedded slot ID, sequence ID, and session ID (if present) in the request will not be in the reply, and the requester has only the XID to match the reply to the request.
o 序列或CB_序列操作可能会产生错误。如果是这样，请求中嵌入的插槽ID、序列ID和会话ID（如果存在）将不在应答中，并且请求者只有与请求的应答相匹配的XID。
Given that well-formulated XIDs continue to be required, this begs the question: why do SEQUENCE and CB_SEQUENCE replies have a session ID, slot ID, and sequence ID? Having the session ID in the reply means that the requester does not have to use the XID to look up the session ID, which would be necessary if the connection were associated with multiple sessions. Having the slot ID and sequence ID in the reply means that the requester does not have to use the XID to look up the slot ID and sequence ID. Furthermore, since the XID is only 32 bits, it is too small to guarantee the re-association of a reply with its request [37]; having session ID, slot ID, and sequence ID in the reply allows the client to validate that the reply in fact belongs to the matched request.
考虑到仍然需要精心设计的XID，这就引出了一个问题：为什么序列和CB_序列回复有会话ID、插槽ID和序列ID？在回复中包含会话ID意味着请求者不必使用XID来查找会话ID，如果连接与多个会话相关联，这是必要的。在应答中具有时隙ID和序列ID意味着请求者不必使用XID来查找时隙ID和序列ID。此外，由于XID只有32位，因此它太小，无法保证应答与其请求的重新关联[37]；在应答中包含会话ID、插槽ID和序列ID允许客户端验证应答实际上属于匹配的请求。
The SEQUENCE (and CB_SEQUENCE) operation also carries a "highest_slotid" value, which carries additional requester slot usage information. The requester MUST always indicate the slot ID representing the outstanding request with the highest-numbered slot value. The requester should in all cases provide the most conservative value possible, although it can be increased somewhat above the actual instantaneous usage to maintain some minimum or optimal level. This provides a way for the requester to yield unused request slots back to the replier, which in turn can use the information to reallocate resources.
SEQUENCE（和CB_SEQUENCE）操作还携带“highest_slotid”值，该值携带额外的请求程序插槽使用信息。请求者必须始终使用编号最高的插槽值指示表示未完成请求的插槽ID。在所有情况下，请求者都应该提供尽可能保守的值，尽管可以将其增加到实际瞬时使用量之上，以保持最低或最佳水平。这为请求者提供了一种将未使用的请求槽返回给应答器的方法，应答器反过来可以使用该信息重新分配资源。
The replier responds with both a new target highest_slotid and an enforced highest_slotid, described as follows:
应答器用新的目标最高\u slotid和强制执行的最高\u slotid进行响应，描述如下：
o The target highest_slotid is an indication to the requester of the highest_slotid the replier wishes the requester to be using. This permits the replier to withdraw (or add) resources from a requester that has been found to not be using them, in order to more fairly share resources among a varying level of demand from other requesters. The requester must always comply with the replier's value updates, since they indicate newly established hard limits on the requester's access to session resources. However, because of request pipelining, the requester may have active requests in flight reflecting prior values; therefore, the replier must not immediately require the requester to comply.
o 目标最高\u slotid是向请求者指示回复者希望请求者使用的最高\u slotid。这允许应答者从发现未使用资源的请求者处提取（或添加）资源，以便在来自其他请求者的不同需求水平之间更公平地共享资源。请求者必须始终遵守应答者的值更新，因为它们表示对请求者访问会话资源的新建立的硬限制。然而，由于请求管道，请求者可能在飞行中有反映先前值的活动请求；因此，回复者不得立即要求请求者遵守。
o The enforced highest_slotid indicates the highest slot ID the requester is permitted to use on a subsequent SEQUENCE or CB_SEQUENCE operation. The replier's enforced highest_slotid SHOULD be no less than the highest_slotid the requester indicated in the SEQUENCE or CB_SEQUENCE arguments.
o 强制的最高插槽ID表示允许请求者在后续序列或CB_序列操作中使用的最高插槽ID。应答器的强制最高\u slotid应不小于SEQUENCE或CB_SEQUENCE参数中指示的请求者的最高\u slotid。
A requester can be intransigent with respect to lowering its highest_slotid argument to a Sequence operation, i.e. the requester continues to ignore the target highest_slotid in the response to a Sequence operation, and continues to set its highest_slotid argument to be higher than the target highest_slotid. This can be considered particularly egregious behavior when the replier knows there are no outstanding requests with slot IDs higher than its target highest_slotid. When faced with such intransigence, the replier is free to take more forceful action, and MAY reply with a new enforced highest_slotid that is less than its previous enforced highest_slotid. Thereafter, if the requester continues to send requests with a highest_slotid that is greater than the replier's new enforced highest_slotid, the server MAY return NFS4ERR_BAD_HIGH_SLOT, unless the slot ID in the request is greater than the new enforced highest_slotid and the request is a retry.
请求者在将其最高\u slotid参数降低为序列操作时可能不妥协，即请求者在对序列操作的响应中继续忽略目标最高\u slotid，并继续将其最高\u slotid参数设置为高于目标最高\u slotid。当应答器知道没有插槽ID高于其目标slotid的未完成请求时，这可以被认为是特别恶劣的行为。当面对这种不妥协时，回复者可以自由地采取更有力的行动，并且可以使用新的强制执行的最高斯洛蒂德进行回复，该最高斯洛蒂德少于其先前强制执行的最高斯洛蒂德。此后，如果请求者继续发送最高\u slotid大于应答者新强制执行的最高\u slotid的请求，则服务器可能返回NFS4ERR\u BAD\u HIGH\u SLOT，除非请求中的SLOT ID大于新强制执行的最高\u slotid并且请求是重试。
The replier SHOULD retain the slots it wants to retire until the requester sends a request with a highest_slotid less than or equal to the replier's new enforced highest_slotid.
应答器应该保留它想要退出的插槽，直到请求者发送一个最高\u slotid小于或等于应答器新强制的最高\u slotid的请求。
The requester can also be intransigent with respect to sending non-retry requests that have a slot ID that exceeds the replier's highest_slotid. Once the replier has forcibly lowered the enforced highest_slotid, the requester is only allowed to send retries on slots that exceed the replier's highest_slotid. If a request is received with a slot ID that is higher than the new enforced highest_slotid, and the sequence ID is one higher than what is in the slot's reply cache, then the server can both retire the slot and return NFS4ERR_BADSLOT (however, the server MUST NOT
对于发送的非重试请求，如果其插槽ID超过应答者的最高\u slotid，请求者也可能不妥协。一旦应答器强制降低强制的最高\u slotid，请求者只允许在超过应答器最高\u slotid的插槽上发送重试。如果接收到的请求的插槽ID高于新强制的最高\u slotid，并且序列ID高于插槽的应答缓存中的ID，则服务器可以退出插槽并返回NFS4ERR\u BADSLOT（但是，服务器不能
do one and not the other). The reason it is safe to retire the slot is because by using the next sequence ID, the requester is indicating it has received the previous reply for the slot.
做一个而不是另一个）。退出插槽是安全的原因是，通过使用下一个序列ID，请求者表示已收到插槽的上一个回复。
o The requester SHOULD use the lowest available slot when sending a new request. This way, the replier may be able to retire slot entries faster. However, where the replier is actively adjusting its granted highest_slotid, it will not be able to use only the receipt of the slot ID and highest_slotid in the request. Neither the slot ID nor the highest_slotid used in a request may reflect the replier's current idea of the requester's session limit, because the request may have been sent from the requester before the update was received. Therefore, in the downward adjustment case, the replier may have to retain a number of reply cache entries at least as large as the old value of maximum requests outstanding, until it can infer that the requester has seen a reply containing the new granted highest_slotid. The replier can infer that the requester has seen such a reply when it receives a new request with the same slot ID as the request replied to and the next higher sequence ID.
o 请求者在发送新请求时应使用最低的可用插槽。这样，应答器可以更快地退出插槽条目。但是，如果应答器正在积极调整其已授予的最高\u slotid，则它将无法在请求中仅使用插槽ID和最高\u slotid的接收。请求中使用的插槽ID或最高\u插槽ID都不能反映应答者对请求者会话限制的当前想法，因为请求可能是在收到更新之前从请求者发送的。因此，在向下调整的情况下，应答器可能必须保留至少与最大未完成请求的旧值一样大的多个应答缓存项，直到它可以推断请求者已经看到包含新授予的最高\u slotid的应答。回复者可以推断，当请求者接收到一个新请求时，该请求者已经看到了这样一个回复，该请求具有与被回复请求相同的时隙ID和下一个更高的序列ID。
When a SEQUENCE or CB_SEQUENCE operation is successfully executed, its reply MUST always be cached. Specifically, session ID, sequence ID, and slot ID MUST be cached in the reply cache. The reply from SEQUENCE also includes the highest slot ID, target highest slot ID, and status flags. Instead of caching these values, the server MAY re-compute the values from the current state of the fore channel, session, and/or client ID as appropriate. Similarly, the reply from CB_SEQUENCE includes a highest slot ID and target highest slot ID. The client MAY re-compute the values from the current state of the session as appropriate.
当序列或CB_序列操作成功执行时，必须始终缓存其回复。具体来说，会话ID、序列ID和插槽ID必须缓存在应答缓存中。来自序列的应答还包括最高插槽ID、目标最高插槽ID和状态标志。服务器可以根据前端通道、会话和/或客户端ID的当前状态重新计算值，而不是缓存这些值。类似地，来自CB_序列的应答包括最高时隙ID和目标最高时隙ID。客户端可以根据会话的当前状态酌情重新计算值。
Regardless of whether or not a replier is re-computing highest slot ID, target slot ID, and status on replies to retries, the requester MUST NOT assume that the values are being re-computed whenever it receives a reply after a retry is sent, since it has no way of knowing whether the reply it has received was sent by the replier in response to the retry or is a delayed response to the original request. Therefore, it may be the case that highest slot ID, target slot ID, or status bits may reflect the state of affairs when the request was first executed. Although acting based on such delayed information is valid, it may cause the receiver of the reply to do unneeded work. Requesters MAY choose to send additional requests to get the current state of affairs or use the state of affairs reported by subsequent requests, in preference to acting immediately on data that might be out of date.
无论应答器是否正在重新计算最高插槽ID、目标插槽ID和重试应答状态，请求者都不得假设在发送重试后收到应答时正在重新计算值，因为它无法知道它收到的回复是由回复者响应重试发送的，还是对原始请求的延迟响应。因此，可能的情况是，最高时隙ID、目标时隙ID或状态位可以反映第一次执行请求时的状态。尽管根据此类延迟信息采取行动是有效的，但这可能会导致回复接收者做不必要的工作。请求者可以选择发送其他请求以获取当前的事务状态，或者使用后续请求报告的事务状态，而不是对可能过期的数据立即采取行动。
Any time SEQUENCE or CB_SEQUENCE returns an error, the sequence ID of the slot MUST NOT change. The replier MUST NOT modify the reply cache entry for the slot whenever an error is returned from SEQUENCE or CB_SEQUENCE.
任何时间序列或CB_序列返回错误，插槽的序列ID不得更改。每当从SEQUENCE或CB_SEQUENCE返回错误时，应答器不得修改插槽的应答缓存项。
On a per-request basis, the requester can choose to direct the replier to cache the reply to all operations after the first operation (SEQUENCE or CB_SEQUENCE) via the sa_cachethis or csa_cachethis fields of the arguments to SEQUENCE or CB_SEQUENCE. The reason it would not direct the replier to cache the entire reply is that the request is composed of all idempotent operations [34]. Caching the reply may offer little benefit. If the reply is too large (see Section 2.10.6.4), it may not be cacheable anyway. Even if the reply to idempotent request is small enough to cache, unnecessarily caching the reply slows down the server and increases RPC latency.
在每个请求的基础上，请求者可以选择指示应答器在第一次操作（序列或CB_序列）之后通过序列或CB_序列的参数的sa_cachethis或csa_cachethis字段缓存对所有操作的应答。它不会指示应答器缓存整个应答的原因是请求由所有幂等运算组成[34]。缓存回复可能没有什么好处。如果回复太大（见第2.10.6.4节），它可能无法缓存。即使对幂等请求的应答小到足以缓存，不必要地缓存应答也会降低服务器速度并增加RPC延迟。
Whether or not the requester requests the reply to be cached has no effect on the slot processing. If the results of SEQUENCE or CB_SEQUENCE are NFS4_OK, then the slot's sequence ID MUST be incremented by one. If a requester does not direct the replier to cache the reply, the replier MUST do one of following:
请求者是否请求缓存回复对插槽处理没有影响。如果序列或CB_序列的结果为NFS4_OK，则插槽的序列ID必须增加1。如果请求者未指示回复者缓存回复，则回复者必须执行以下操作之一：
o The replier can cache the entire original reply. Even though sa_cachethis or csa_cachethis is FALSE, the replier is always free to cache. It may choose this approach in order to simplify implementation.
o 应答器可以缓存整个原始应答。即使sa_cachethis或csa_cachethis为FALSE，应答器始终可以自由缓存。它可以选择这种方法以简化实现。
o The replier enters into its reply cache a reply consisting of the original results to the SEQUENCE or CB_SEQUENCE operation, and with the next operation in COMPOUND or CB_COMPOUND having the error NFS4ERR_RETRY_UNCACHED_REP. Thus, if the requester later retries the request, it will get NFS4ERR_RETRY_UNCACHED_REP. If a replier receives a retried Sequence operation where the reply to the COMPOUND or CB_COMPOUND was not cached, then the replier,
o 应答器将包含序列或CB_序列操作的原始结果的应答输入到其应答缓存中，并且复合或CB_复合中的下一个操作具有错误NFS4ERR_RETRY_UNCACHED_REP。因此，如果请求者稍后重试请求，它将获得NFS4ERR_RETRY_UNCACHED_REP。如果应答器接收到重试序列操作，其中对复合或CB_复合的应答未缓存，则应答器，
* MAY return NFS4ERR_RETRY_UNCACHED_REP in reply to a Sequence operation if the Sequence operation is not the first operation (granted, a requester that does so is in violation of the NFSv4.1 protocol).
* 如果序列操作不是第一个操作，则可能会返回NFS4ERR\u RETRY\u UNCACHED\u REP以响应序列操作（已授予，这样做的请求者违反了NFSv4.1协议）。
* MUST NOT return NFS4ERR_RETRY_UNCACHED_REP in reply to a Sequence operation if the Sequence operation is the first operation.
* 如果序列操作是第一个操作，则不得返回NFS4ERR\u RETRY\u UNCACHED\u REP以响应序列操作。
o If the second operation is an illegal operation, or an operation that was legal in a previous minor version of NFSv4 and MUST NOT be supported in the current minor version (e.g., SETCLIENTID), the replier MUST NOT ever return NFS4ERR_RETRY_UNCACHED_REP. Instead the replier MUST return NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR or NFS4ERR_NOTSUPP as appropriate.
o 如果第二个操作是非法操作，或者是NFSv4先前次要版本中合法的操作，并且当前次要版本（例如SETCLIENTID）中不支持该操作，应答器不得返回NFS4ERR_RETRY_UNCACHED_REP。相反，应答器必须返回NFS4ERR_OP_非法或NFS4ERR_BADXDR或NFS4ERR_NOTSUPP（视情况而定）。
o If the second operation can result in another error status, the replier MAY return a status other than NFS4ERR_RETRY_UNCACHED_REP, provided the operation is not executed in such a way that the state of the replier is changed. Examples of such an error status include: NFS4ERR_NOTSUPP returned for an operation that is legal but not REQUIRED in the current minor versions, and thus not supported by the replier; NFS4ERR_SEQUENCE_POS; and NFS4ERR_REQ_TOO_BIG.
o 如果第二个操作可能导致另一个错误状态，则应答器可能返回NFS4ERR_RETRY_UNCACHED_REP以外的状态，前提是该操作的执行方式不会改变应答器的状态。此类错误状态的示例包括：为合法但在当前次要版本中不需要的操作返回的NFS4ERR_NOTSUPP，因此应答器不支持该操作；NFS4ERR_SEQUENCE_POS；NFS4ERR\u请求太大。
The discussion above assumes that the retried request matches the original one. Section 2.10.6.1.3.1 discusses what the replier might do, and MUST do when original and retried requests do not match. Since the replier may only cache a small amount of the information that would be required to determine whether this is a case of a false retry, the replier may send to the client any of the following responses:
上面的讨论假设重试的请求与原始请求匹配。第2.10.6.1.3.1节讨论了当原始请求和重试请求不匹配时，应答器可能会做什么，以及必须做什么。由于应答器可能只缓存确定这是否为错误重试所需的少量信息，因此应答器可能会向客户端发送以下任何响应：
o The cached reply to the original request (if the replier has cached it in its entirety and the users of the original request and retry match).
o 原始请求的缓存回复（如果回复者已将其全部缓存，并且原始请求的用户已缓存，请重试匹配）。
o A reply that consists only of the Sequence operation with the error NFS4ERR_FALSE_RETRY.
o 仅由序列操作组成的回复，错误为NFS4ERR\u FALSE\u RETRY。
o A reply consisting of the response to Sequence with the status NFS4_OK, together with the second operation as it appeared in the retried request with an error of NFS4ERR_RETRY_UNCACHED_REP or other error as described above.
o 一种应答，包括对状态为NFS4_OK的序列的响应，以及出现在重试请求中的第二个操作，错误为NFS4ERR_RETRY_UNCACHED_REP或上述其他错误。
o A reply that consists of the response to Sequence with the status NFS4_OK, together with the second operation as it appeared in the original request with an error of NFS4ERR_RETRY_UNCACHED_REP or other error as described above.
o 一种应答，包括对状态为NFS4_OK的序列的响应，以及出现在原始请求中的第二个操作，错误为NFS4ERR_RETRY_UNCACHED_REP或上述其他错误。
If a requester sent a Sequence operation with a slot ID and sequence ID that are in the reply cache but the replier detected that the retried request is not the same as the original request, including a retry that has different operations or different arguments in the operations from the original and a retry that uses a different
如果请求者发送了一个序列操作，其插槽ID和序列ID位于应答缓存中，但应答者检测到重试的请求与原始请求不同，包括在操作中使用与原始请求不同的操作或参数的重试，以及使用不同参数的重试
principal in the RPC request's credential field that translates to a different user, then this is a false retry. When the replier detects a false retry, it is permitted (but not always obligated) to return NFS4ERR_FALSE_RETRY in response to the Sequence operation when it detects a false retry.
RPC请求的凭据字段中的主体，转换为其他用户，则这是错误的重试。当应答器检测到错误重试时，允许（但并非总是有义务）在检测到错误重试时返回NFS4ERR_false_retry以响应序列操作。
Translations of particularly privileged user values to other users due to the lack of appropriately secure credentials, as configured on the replier, should be applied before determining whether the users are the same or different. If the replier determines the users are different between the original request and a retry, then the replier MUST return NFS4ERR_FALSE_RETRY.
在确定用户是否相同或不同之前，应应用由于缺少应答器上配置的适当安全凭据而将特定特权用户值转换为其他用户。如果应答器确定原始请求和重试之间的用户不同，则应答器必须返回NFS4ERR\u FALSE\u retry。
If an operation of the retry is an illegal operation, or an operation that was legal in a previous minor version of NFSv4 and MUST NOT be supported in the current minor version (e.g., SETCLIENTID), the replier MAY return NFS4ERR_FALSE_RETRY (and MUST do so if the users of the original request and retry differ). Otherwise, the replier MAY return NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR or NFS4ERR_NOTSUPP as appropriate. Note that the handling is in contrast for how the replier deals with retries requests with no cached reply. The difference is due to NFS4ERR_FALSE_RETRY being a valid error for only Sequence operations, whereas NFS4ERR_RETRY_UNCACHED_REP is a valid error for all operations except illegal operations and operations that MUST NOT be supported in the current minor version of NFSv4.
如果重试操作是非法操作，或者是在NFSv4以前的次要版本中合法的操作，并且在当前次要版本（例如SETCLIENTID）中不受支持，则应答器可能返回NFS4ERR_FALSE_retry（如果原始请求和重试的用户不同，则必须返回）。否则，应答器可能会根据需要返回NFS4ERR_OP_非法或NFS4ERR_BADXDR或NFS4ERR_NOTSUPP。请注意，处理方式与应答器处理没有缓存应答的重试请求的方式相反。区别在于NFS4ERR_FALSE_RETRY仅对序列操作有效，而NFS4ERR_RETRY_UNCACHED_REP对所有操作有效，非法操作和当前次要版本NFSv4中不支持的操作除外。
A requester MUST NOT retry a request, unless the connection it used to send the request disconnects. The requester can then reconnect and re-send the request, or it can re-send the request over a different connection that is associated with the same session.
请求者不得重试请求，除非用于发送请求的连接断开。然后，请求者可以重新连接并重新发送请求，也可以通过与同一会话关联的不同连接重新发送请求。
If the requester is a server wanting to re-send a callback operation over the backchannel of a session, the requester of course cannot reconnect because only the client can associate connections with the backchannel. The server can re-send the request over another connection that is bound to the same session's backchannel. If there is no such connection, the server MUST indicate that the session has no backchannel by setting the SEQ4_STATUS_CB_PATH_DOWN_SESSION flag bit in the response to the next SEQUENCE operation from the client. The client MUST then associate a connection with the session (or destroy the session).
如果请求者是希望通过会话的反向通道重新发送回调操作的服务器，那么请求者当然无法重新连接，因为只有客户端可以将连接与反向通道相关联。服务器可以通过绑定到同一会话的反向通道的另一个连接重新发送请求。如果没有这样的连接，服务器必须通过在对来自客户端的下一个序列操作的响应中设置SEQ4_STATUS_CB_PATH_DOWN_session flag位来指示会话没有反向通道。然后，客户端必须将连接与会话相关联（或销毁会话）。
Note that it is not fatal for a requester to retry without a disconnect between the request and retry. However, the retry does consume resources, especially with RDMA, where each request, retry or not, consumes a credit. Retries for no reason, especially retries
请注意，请求者在请求和重试之间没有断开连接的情况下重试并不是致命的。但是，重试确实会消耗资源，特别是对于RDMA，其中每个请求（无论是否重试）都会消耗一个积分。无缘无故地重试，尤指重试
sent shortly after the previous attempt, are a poor use of network bandwidth and defeat the purpose of a transport's inherent congestion control system.
在前一次尝试后不久发送的消息，是对网络带宽的不良使用，并违背了传输固有的拥塞控制系统的目的。
A requester MUST wait for a reply to a request before using the slot for another request. If it does not wait for a reply, then the requester does not know what sequence ID to use for the slot on its next request. For example, suppose a requester sends a request with sequence ID 1, and does not wait for the response. The next time it uses the slot, it sends the new request with sequence ID 2. If the replier has not seen the request with sequence ID 1, then the replier is not expecting sequence ID 2, and rejects the requester's new request with NFS4ERR_SEQ_MISORDERED (as the result from SEQUENCE or CB_SEQUENCE).
请求者必须等待对请求的答复，然后才能将插槽用于另一个请求。如果它不等待回复，那么请求者就不知道在下一个请求中为插槽使用什么序列ID。例如，假设请求者发送序列ID为1的请求，并且不等待响应。下次使用插槽时，它将发送序列ID为2的新请求。如果应答器没有看到序列ID为1的请求，则应答器不期望序列ID为2，并以NFS4ERR_SEQ_错序（由于序列或CB_序列）拒绝请求者的新请求。
RDMA fabrics do not guarantee that the memory handles (Steering Tags) within each RPC/RDMA "chunk" [8] are valid on a scope outside that of a single connection. Therefore, handles used by the direct operations become invalid after connection loss. The server must ensure that any RDMA operations that must be replayed from the reply cache use the newly provided handle(s) from the most recent request.
RDMA结构不保证每个RPC/RDMA“块”[8]中的内存句柄（转向标记）在单个连接之外的作用域上有效。因此，直接操作使用的句柄在连接丢失后将变得无效。服务器必须确保必须从应答缓存重放的任何RDMA操作都使用最近请求中新提供的句柄。
A retry might be sent while the original request is still in progress on the replier. The replier SHOULD deal with the issue by returning NFS4ERR_DELAY as the reply to SEQUENCE or CB_SEQUENCE operation, but implementations MAY return NFS4ERR_MISORDERED. Since errors from SEQUENCE and CB_SEQUENCE are never recorded in the reply cache, this approach allows the results of the execution of the original request to be properly recorded in the reply cache (assuming that the requester specified the reply to be cached).
当原始请求仍在应答器上进行时，可能会发送重试。应答器应该通过返回NFS4ERR_DELAY作为对序列的应答或CB_序列操作来处理该问题，但是实现可能会返回错误排序的NFS4ERR_。由于SEQUENCE和CB_SEQUENCE的错误从未记录在应答缓存中，因此这种方法允许原始请求的执行结果正确记录在应答缓存中（假设请求者指定要缓存的应答）。
It is possible for server callbacks to arrive at the client before the reply from related fore channel operations. For example, a client may have been granted a delegation to a file it has opened, but the reply to the OPEN (informing the client of the granting of the delegation) may be delayed in the network. If a conflicting operation arrives at the server, it will recall the delegation using the backchannel, which may be on a different transport connection, perhaps even a different network, or even a different session associated with the same client ID.
服务器回调可能在相关前端通道操作的回复之前到达客户端。例如，客户机可能已被授予对其已打开的文件的授权，但对打开文件的回复（通知客户授权）可能会在网络中延迟。如果冲突操作到达服务器，它将使用反向通道调用委派，反向通道可能位于不同的传输连接上，甚至可能位于不同的网络上，甚至可能位于与同一客户机ID关联的不同会话上。
The presence of a session between the client and server alleviates this issue. When a session is in place, each client request is uniquely identified by its { session ID, slot ID, sequence ID } triple. By the rules under which slot entries (reply cache entries) are retired, the server has knowledge whether the client has "seen"
客户端和服务器之间存在会话可以缓解此问题。当会话就位时，每个客户端请求都由其{session ID，slot ID，sequence ID}三元组唯一标识。根据插槽项（回复缓存项）失效的规则，服务器知道客户端是否“看到”
each of the server's replies. The server can therefore provide sufficient information to the client to allow it to disambiguate between an erroneous or conflicting callback race condition.
服务器的每个回复。因此，服务器可以向客户机提供足够的信息，使其能够在错误或冲突的回调竞争条件之间消除歧义。
For each client operation that might result in some sort of server callback, the server SHOULD "remember" the { session ID, slot ID, sequence ID } triple of the client request until the slot ID retirement rules allow the server to determine that the client has, in fact, seen the server's reply. Until the time the { session ID, slot ID, sequence ID } request triple can be retired, any recalls of the associated object MUST carry an array of these referring identifiers (in the CB_SEQUENCE operation's arguments), for the benefit of the client. After this time, it is not necessary for the server to provide this information in related callbacks, since it is certain that a race condition can no longer occur.
对于可能导致某种服务器回调的每个客户端操作，服务器应该“记住”客户端请求的{session ID，slot ID，sequence ID}三元组，直到slot ID失效规则允许服务器确定客户端实际上已经看到了服务器的回复。在{session ID，slot ID，sequence ID}请求三元组可以失效之前，关联对象的任何回调都必须携带这些引用标识符的数组（在CB_sequence操作的参数中），以利于客户端。在这段时间之后，服务器无需在相关回调中提供此信息，因为可以确定竞争条件不再发生。
The CB_SEQUENCE operation that begins each server callback carries a list of "referring" { session ID, slot ID, sequence ID } triples. If the client finds the request corresponding to the referring session ID, slot ID, and sequence ID to be currently outstanding (i.e., the server's reply has not been seen by the client), it can determine that the callback has raced the reply, and act accordingly. If the client does not find the request corresponding to the referring triple to be outstanding (including the case of a session ID referring to a destroyed session), then there is no race with respect to this triple. The server SHOULD limit the referring triples to requests that refer to just those that apply to the objects referred to in the CB_COMPOUND procedure.
开始每个服务器回调的CB_序列操作包含一个“引用”{session ID，slot ID，SEQUENCE ID}三元组列表。如果客户机发现与引用会话ID、插槽ID和序列ID相对应的请求当前未完成（即，客户机未看到服务器的回复），它可以确定回调已完成回复，并相应地采取行动。如果客户机未发现与引用三元组对应的请求未完成（包括会话ID引用已破坏会话的情况），则与此三元组不存在争用。服务器应将引用三元组限制为仅引用那些应用于CB_复合过程中引用的对象的请求。
The client must not simply wait forever for the expected server reply to arrive before responding to the CB_COMPOUND that won the race, because it is possible that it will be delayed indefinitely. The client should assume the likely case that the reply will arrive within the average round-trip time for COMPOUND requests to the server, and wait that period of time. If that period of time expires, it can respond to the CB_COMPOUND with NFS4ERR_DELAY. There are other scenarios under which callbacks may race replies. Among them are pNFS layout recalls as described in Section 12.5.5.2.
在响应赢得比赛的CB_化合物之前，客户端不能永远等待预期的服务器应答，因为它可能会无限期地延迟。客户机应该假设回复将在到服务器的复合请求的平均往返时间内到达，并等待该时间段。如果这段时间到期，它可以用NFS4ERR_延迟响应CB_化合物。在其他情况下，回调可能会与回复竞争。其中包括pNFS布局召回，如第12.5.5.2节所述。
Very large requests and replies may pose both buffer management issues (especially with RDMA) and reply cache issues. When the session is created (Section 18.36), for each channel (fore and back), the client and server negotiate the maximum-sized request they will send or process (ca_maxrequestsize), the maximum-sized reply they will return or process (ca_maxresponsesize), and the maximum-sized reply they will store in the reply cache (ca_maxresponsesize_cached).
非常大的请求和回复可能会带来缓冲区管理问题（尤其是RDMA）和回复缓存问题。创建会话时（第18.36节），对于每个通道（前端和后端），客户机和服务器协商它们将发送或处理的最大大小的请求（ca_maxrequestsize），它们将返回或处理的最大大小的回复（ca_maxresponsesize），以及它们将存储在回复缓存中的最大大小的回复（ca_maxresponsesize_cached）。
If a request exceeds ca_maxrequestsize, the reply will have the status NFS4ERR_REQ_TOO_BIG. A replier MAY return NFS4ERR_REQ_TOO_BIG as the status for the first operation (SEQUENCE or CB_SEQUENCE) in the request (which means that no operations in the request executed and that the state of the slot in the reply cache is unchanged), or it MAY opt to return it on a subsequent operation in the same COMPOUND or CB_COMPOUND request (which means that at least one operation did execute and that the state of the slot in the reply cache does change). The replier SHOULD set NFS4ERR_REQ_TOO_BIG on the operation that exceeds ca_maxrequestsize.
If a request exceeds ca_maxrequestsize, the reply will have the status NFS4ERR_REQ_TOO_BIG. A replier MAY return NFS4ERR_REQ_TOO_BIG as the status for the first operation (SEQUENCE or CB_SEQUENCE) in the request (which means that no operations in the request executed and that the state of the slot in the reply cache is unchanged), or it MAY opt to return it on a subsequent operation in the same COMPOUND or CB_COMPOUND request (which means that at least one operation did execute and that the state of the slot in the reply cache does change). The replier SHOULD set NFS4ERR_REQ_TOO_BIG on the operation that exceeds ca_maxrequestsize.translate error, please retry
If a reply exceeds ca_maxresponsesize, the reply will have the status NFS4ERR_REP_TOO_BIG. A replier MAY return NFS4ERR_REP_TOO_BIG as the status for the first operation (SEQUENCE or CB_SEQUENCE) in the request, or it MAY opt to return it on a subsequent operation (in the same COMPOUND or CB_COMPOUND reply). A replier MAY return NFS4ERR_REP_TOO_BIG in the reply to SEQUENCE or CB_SEQUENCE, even if the response would still exceed ca_maxresponsesize.
如果回复超过ca_maxresponsesize，则回复的状态为NFS4ERR_REP_TOO_BIG。应答器可能返回NFS4ERR_REP_太大，作为请求中第一个操作（序列或CB_序列）的状态，也可能选择在后续操作中返回它（在相同的复合或CB_复合应答中）。应答器可能会在应答序列或CB_序列中返回NFS4ERR_REP_过大，即使响应仍将超过ca_maxresponsesize。
If sa_cachethis or csa_cachethis is TRUE, then the replier MUST cache a reply except if an error is returned by the SEQUENCE or CB_SEQUENCE operation (see Section 2.10.6.1.2). If the reply exceeds ca_maxresponsesize_cached (and sa_cachethis or csa_cachethis is TRUE), then the server MUST return NFS4ERR_REP_TOO_BIG_TO_CACHE. Even if NFS4ERR_REP_TOO_BIG_TO_CACHE (or any other error for that matter) is returned on an operation other than the first operation (SEQUENCE or CB_SEQUENCE), then the reply MUST be cached if sa_cachethis or csa_cachethis is TRUE. For example, if a COMPOUND has eleven operations, including SEQUENCE, the fifth operation is a RENAME, and the tenth operation is a READ for one million bytes, the server may return NFS4ERR_REP_TOO_BIG_TO_CACHE on the tenth operation. Since the server executed several operations, especially the non-idempotent RENAME, the client's request to cache the reply needs to be honored in order for the correct operation of exactly once semantics. If the client retries the request, the server will have cached a reply that contains results for ten of the eleven requested operations, with the tenth operation having a status of NFS4ERR_REP_TOO_BIG_TO_CACHE.
如果sa_cachethis或csa_cachethis为真，则应答器必须缓存应答，除非序列或CB_序列操作返回错误（见第2.10.6.1.2节）。如果回复超过ca_maxresponsesize_cached（并且sa_cachethis或csa_cachethis为真），则服务器必须将NFS4ERR_REP_TO_BIG_返回到_CACHE。即使NFS4ERR_REP_TOO_BIG_TO_CACHE（或任何其他相关错误）在第一个操作（序列或CB_序列）以外的操作上返回，如果sa_cachethis或csa_cachethis为真，则必须缓存回复。例如，如果一个化合物有11个操作，包括序列，第五个操作是重命名，第十个操作是读取一百万字节，则服务器可能会在第十个操作中将NFS4ERR_REP_TOO_BIG_返回给_缓存。由于服务器执行了多个操作，特别是非幂等重命名，因此需要满足客户机缓存回复的请求，以便正确操作一次。如果客户端重试请求，服务器将缓存一个应答，其中包含11个请求操作中10个操作的结果，第10个操作的状态为NFS4ERR_REP_TOO_BIG_TO_CACHE。
A client needs to take care that when sending operations that change the current filehandle (except for PUTFH, PUTPUBFH, PUTROOTFH, and RESTOREFH), it not exceed the maximum reply buffer before the GETFH operation. Otherwise, the client will have to retry the operation that changed the current filehandle, in order to obtain the desired filehandle. For the OPEN operation (see Section 18.16), retry is not always available as an option. The following guidelines for the handling of filehandle-changing operations are advised:
客户端需要注意的是，在发送更改当前文件句柄的操作时（PUTFH、PUTPUBFH、PUTROOTFH和RESTOREFH除外），它不会超过GETFH操作之前的最大回复缓冲区。否则，客户端将必须重试更改当前文件句柄的操作，以获得所需的文件句柄。对于打开操作（参见第18.16节），重试并不总是作为选项可用。建议按照以下准则处理filehandle更改操作：
o Within the same COMPOUND procedure, a client SHOULD send GETFH immediately after a current filehandle-changing operation. A client MUST send GETFH after a current filehandle-changing operation that is also non-idempotent (e.g., the OPEN operation), unless the operation is RESTOREFH. RESTOREFH is an exception, because even though it is non-idempotent, the filehandle RESTOREFH produced originated from an operation that is either idempotent (e.g., PUTFH, LOOKUP), or non-idempotent (e.g., OPEN, CREATE). If the origin is non-idempotent, then because the client MUST send GETFH after the origin operation, the client can recover if RESTOREFH returns an error.
o 在同一复合过程中，客户机应该在当前文件句柄更改操作之后立即发送GETFH。除非操作是RESTOREFH，否则客户端必须在当前文件句柄更改操作之后发送GETFH，该操作也是非幂等的（例如，OPEN操作）。RESTOREFH是一个例外，因为即使它是非幂等的，生成的filehandle RESTOREFH也源于幂等（例如PUTFH、LOOKUP）或非幂等（例如OPEN、CREATE）的操作。如果origin是非幂等的，那么由于客户机必须在origin操作之后发送GETFH，因此如果RESTOREFH返回错误，客户机可以恢复。
o A server MAY return NFS4ERR_REP_TOO_BIG or NFS4ERR_REP_TOO_BIG_TO_CACHE (if sa_cachethis is TRUE) on a filehandle-changing operation if the reply would be too large on the next operation.
o 如果在下一个操作中回复太大，服务器可能会在文件句柄更改操作中返回NFS4ERR_REP_TOO_BIG或NFS4ERR_REP_TOO_BIG TO_CACHE（如果sa_CACHE这是真的）。
o A server SHOULD return NFS4ERR_REP_TOO_BIG or NFS4ERR_REP_TOO_BIG_TO_CACHE (if sa_cachethis is TRUE) on a filehandle-changing, non-idempotent operation if the reply would be too large on the next operation, especially if the operation is OPEN.
o 如果在下一个操作（尤其是在操作打开的情况下）中回复过大，则服务器应在文件句柄更改的非幂等操作上返回NFS4ERR_REP_TOO_BIG或NFS4ERR_REP_TOO_BIG TO_CACHE（如果sa_CACHE这是真的），返回NFS4ERR_REP_TOO_BIG_TO_CACHE）。
o A server MAY return NFS4ERR_UNSAFE_COMPOUND to a non-idempotent current filehandle-changing operation, if it looks at the next operation (in the same COMPOUND procedure) and finds it is not GETFH. The server SHOULD do this if it is unable to determine in advance whether the total response size would exceed ca_maxresponsesize_cached or ca_maxresponsesize.
o 如果服务器查看下一个操作（在同一复合过程中）并发现它不是GETFH，则可能会将NFS4ERR_UNSAFE_复合返回到非幂等当前文件句柄更改操作。如果服务器无法预先确定总响应大小是否会超过ca_maxresponsesize_cached或ca_maxresponsesize，则应执行此操作。
Since the reply cache is bounded, it is practical for the reply cache to persist across server restarts. The replier MUST persist the following information if it agreed to persist the session (when the session was created; see Section 18.36):
由于回复缓存是有界的，所以在服务器重新启动时，回复缓存可以保持不变。如果回复者同意保留会话，则回复者必须保留以下信息（会话创建时；参见第18.36节）：
o The session ID.
o 会话ID为。
o The slot table including the sequence ID and cached reply for each slot.
o 插槽表，包括每个插槽的序列ID和缓存回复。
The above are sufficient for a replier to provide EOS semantics for any requests that were sent and executed before the server restarted. If the replier is a client, then there is no need for it to persist any more information, unless the client will be persisting all other state across client restart, in which case, the server will never see any NFSv4.1-level protocol manifestation of a client restart. If the
以上内容足以让应答器为服务器重新启动之前发送和执行的任何请求提供EOS语义。如果应答器是一个客户端，那么它就不需要保存更多的信息，除非客户端将在客户端重新启动期间保存所有其他状态，在这种情况下，服务器将永远不会看到客户端重新启动的任何NFSv4.1级协议表现。如果
replier is a server, with just the slot table and session ID persisting, any requests the client retries after the server restart will return the results that are cached in the reply cache, and any new requests (i.e., the sequence ID is one greater than the slot's sequence ID) MUST be rejected with NFS4ERR_DEADSESSION (returned by SEQUENCE). Such a session is considered dead. A server MAY re-animate a session after a server restart so that the session will accept new requests as well as retries. To re-animate a session, the server needs to persist additional information through server restart:
replier是一台服务器，只有插槽表和会话ID保持不变，客户端在服务器重新启动后重试的任何请求都将返回缓存在reply缓存中的结果，任何新请求（即，序列ID比插槽的序列ID大一个）都必须使用NFS4ERR_DEADSESSION（按序列返回）拒绝。这样的会议被认为是死的。服务器重新启动后，服务器可能会重新设置会话的动画，以便会话将接受新请求和重试。要重新设置会话的动画，服务器需要通过服务器重新启动来保存其他信息：
o The client ID. This is a prerequisite to let the client create more sessions associated with the same client ID as the re-animated session.
o 客户端ID。这是让客户端创建与重新设置动画的会话相同的客户端ID关联的更多会话的先决条件。
o The client ID's sequence ID that is used for creating sessions (see Sections 18.35 and 18.36). This is a prerequisite to let the client create more sessions.
o 用于创建会话的客户端ID的序列ID（参见第18.35和18.36节）。这是让客户端创建更多会话的先决条件。
o The principal that created the client ID. This allows the server to authenticate the client when it sends EXCHANGE_ID.
o 创建客户端ID的主体。这允许服务器在发送EXCHANGE\u ID时对客户端进行身份验证。
o The SSV, if SP4_SSV state protection was specified when the client ID was created (see Section 18.35). This lets the client create new sessions, and associate connections with the new and existing sessions.
o 如果在创建客户端ID时指定了SP4_SSV状态保护，则为SSV（参见第18.35节）。这允许客户端创建新会话，并将连接与新会话和现有会话相关联。
o The properties of the client ID as defined in Section 18.35.
o 第18.35节中定义的客户ID属性。
A persistent reply cache places certain demands on the server. The execution of the sequence of operations (starting with SEQUENCE) and placement of its results in the persistent cache MUST be atomic. If a client retries a sequence of operations that was previously executed on the server, the only acceptable outcomes are either the original cached reply or an indication that the client ID or session has been lost (indicating a catastrophic loss of the reply cache or a session that has been deleted because the client failed to use the session for an extended period of time).
持久回复缓存会对服务器提出某些要求。操作序列（从序列开始）的执行及其结果在持久缓存中的放置必须是原子的。如果客户端重试以前在服务器上执行的一系列操作，则唯一可接受的结果是原始缓存的回复或客户端ID或会话已丢失的指示（表示回复缓存的灾难性丢失，或由于客户端在较长时间内未能使用会话而删除的会话）。
A server could fail and restart in the middle of a COMPOUND procedure that contains one or more non-idempotent or idempotent-but-modifying operations. This creates an even higher challenge for atomic execution and placement of results in the reply cache. One way to view the problem is as a single transaction consisting of each operation in the COMPOUND followed by storing the result in persistent storage, then finally a transaction commit. If there is a failure before the transaction is committed, then the server rolls
服务器可以在包含一个或多个非幂等或幂等但修改操作的复合过程的中间失败和重新启动。这给原子执行和结果在应答缓存中的放置带来了更高的挑战。查看问题的一种方法是将其视为一个事务，该事务由复合中的每个操作组成，然后将结果存储在持久性存储中，最后是一个事务提交。如果在提交事务之前出现故障，则服务器将回滚
back the transaction. If the server itself fails, then when it restarts, its recovery logic could roll back the transaction before starting the NFSv4.1 server.
支持交易。如果服务器本身出现故障，那么当它重新启动时，其恢复逻辑可以在启动NFSv4.1服务器之前回滚事务。
While the description of the implementation for atomic execution of the request and caching of the reply is beyond the scope of this document, an example implementation for NFSv2 [38] is described in [39].
虽然请求的原子执行和回复的缓存的实现的描述超出了本文档的范围，但是[39]中描述了NFSv2[38]的示例实现。
A complete discussion of the operation of RPC-based protocols over RDMA transports is in [8]. A discussion of the operation of NFSv4, including NFSv4.1, over RDMA is in [9]. Where RDMA is considered, this specification assumes the use of such a layering; it addresses only the upper-layer issues relevant to making best use of RPC/RDMA.
关于基于RPC的协议在RDMA传输上的操作的完整讨论见[8]。[9]中讨论了NFSv4（包括NFSv4.1）在RDMA上的运行。在考虑RDMA的情况下，本规范假设使用这种分层；它只解决与充分利用RPC/RDMA相关的上层问题。
RDMA requires its consumers to register memory and post buffers of a specific size and number for receive operations.
RDMA要求其使用者为接收操作注册特定大小和数量的内存和post缓冲区。
Registration of memory can be a relatively high-overhead operation, since it requires pinning of buffers, assignment of attributes (e.g., readable/writable), and initialization of hardware translation. Preregistration is desirable to reduce overhead. These registrations are specific to hardware interfaces and even to RDMA connection endpoints; therefore, negotiation of their limits is desirable to manage resources effectively.
内存注册可能是一个开销相对较高的操作，因为它需要固定缓冲区、分配属性（例如，可读/写）和初始化硬件转换。预注册可以减少开销。这些注册特定于硬件接口，甚至RDMA连接端点；因此，为了有效地管理资源，需要对其限制进行协商。
Following basic registration, these buffers must be posted by the RPC layer to handle receives. These buffers remain in use by the RPC/ NFSv4.1 implementation; the size and number of them must be known to the remote peer in order to avoid RDMA errors that would cause a fatal error on the RDMA connection.
在基本注册之后，RPC层必须发布这些缓冲区来处理接收。这些缓冲区仍由RPC/NFSv4.1实现使用；远程对等方必须知道它们的大小和数量，以避免可能导致RDMA连接上致命错误的RDMA错误。
NFSv4.1 manages slots as resources on a per-session basis (see Section 2.10), while RDMA connections manage credits on a per-connection basis. This means that in order for a peer to send data over RDMA to a remote buffer, it has to have both an NFSv4.1 slot and an RDMA credit. If multiple RDMA connections are associated with a session, then if the total number of credits across all RDMA connections associated with the session is X, and the number of slots in the session is Y, then the maximum number of outstanding requests is the lesser of X and Y.
NFSv4.1在每个会话的基础上管理插槽作为资源（参见第2.10节），而RDMA连接在每个连接的基础上管理信用。这意味着，为了让对等方通过RDMA将数据发送到远程缓冲区，它必须具有NFSv4.1插槽和RDMA信用。如果多个RDMA连接与一个会话相关联，那么如果与该会话相关联的所有RDMA连接的信用总数为X，且会话中的插槽数为Y，则未完成请求的最大数量为X和Y中的较小者。
Previous versions of NFS do not provide flow control; instead, they rely on the windowing provided by transports like TCP to throttle requests. This does not work with RDMA, which provides no operation flow control and will terminate a connection in error when limits are exceeded. Limits such as maximum number of requests outstanding are therefore negotiated when a session is created (see the ca_maxrequests field in Section 18.36). These limits then provide the maxima within which each connection associated with the session's channel(s) must remain. RDMA connections are managed within these limits as described in Section 3.3 of [8]; if there are multiple RDMA connections, then the maximum number of requests for a channel will be divided among the RDMA connections. Put a different way, the onus is on the replier to ensure that the total number of RDMA credits across all connections associated with the replier's channel does exceed the channel's maximum number of outstanding requests.
NFS的早期版本不提供流控制；相反，它们依靠TCP等传输提供的窗口来限制请求。这不适用于RDMA，RDMA不提供操作流控制，并且在超出限制时会错误地终止连接。因此，在创建会话时，将协商未完成请求的最大数量等限制（请参阅第18.36节中的“ca_maxrequests”字段）。然后，这些限制提供了与会话通道关联的每个连接必须保持的最大值。RDMA连接在[8]第3.3节所述的限制范围内进行管理；如果存在多个RDMA连接，则对通道的最大请求数将在RDMA连接之间分配。换句话说，应答器有责任确保与应答器的通道相关联的所有连接上的RDMA信用总数不超过通道的最大未完成请求数。
The limits may also be modified dynamically at the replier's choosing by manipulating certain parameters present in each NFSv4.1 reply. In addition, the CB_RECALL_SLOT callback operation (see Section 20.8) can be sent by a server to a client to return RDMA credits to the server, thereby lowering the maximum number of requests a client can have outstanding to the server.
还可以通过操纵每个NFSv4.1回复中存在的某些参数，在回复者选择时动态修改限制。此外，服务器可以将CB_RECALL_插槽回调操作（参见第20.8节）发送给客户端，以将RDMA积分返回给服务器，从而降低客户端可以向服务器发出的最大未完成请求数。
Header padding is requested by each peer at session initiation (see the ca_headerpadsize argument to CREATE_SESSION in Section 18.36), and subsequently used by the RPC RDMA layer, as described in [8]. Zero padding is permitted.
头填充由每个对等方在会话启动时请求（参见第18.36节中创建会话的ca_headerpadsize参数），随后由RPC RDMA层使用，如[8]所述。允许零填充。
Padding leverages the useful property that RDMA preserve alignment of data, even when they are placed into anonymous (untagged) buffers. If requested, client inline writes will insert appropriate pad bytes within the request header to align the data payload on the specified boundary. The client is encouraged to add sufficient padding (up to the negotiated size) so that the "data" field of the WRITE operation is aligned. Most servers can make good use of such padding, which allows them to chain receive buffers in such a way that any data carried by client requests will be placed into appropriate buffers at the server, ready for file system processing. The receiver's RPC layer encounters no overhead from skipping over pad bytes, and the RDMA layer's high performance makes the insertion and transmission of padding on the sender a significant optimization. In this way, the need for servers to perform RDMA Read to satisfy all but the largest
填充利用了RDMA保留数据对齐的有用特性，即使数据被放入匿名（未标记）缓冲区中。如果请求，客户端内联写入将在请求标头内插入适当的pad字节，以将数据有效负载与指定边界对齐。鼓励客户机添加足够的填充（直到协商的大小），以便对齐写入操作的“数据”字段。大多数服务器都可以很好地利用这种填充，这使它们能够以这样的方式链接接收缓冲区，即客户端请求携带的任何数据都将被放置到服务器上适当的缓冲区中，以便进行文件系统处理。接收方的RPC层不会因跳过pad字节而产生任何开销，RDMA层的高性能使得在发送方上插入和传输padding成为一个重要的优化。通过这种方式，服务器需要执行RDMA读取以满足除最大
client writes is obviated. An added benefit is the reduction of message round trips on the network -- a potentially good trade, where latency is present.
避免了客户端写入。另外一个好处是减少了网络上的消息往返——这是一个潜在的好交易，因为存在延迟。
The value to choose for padding is subject to a number of criteria. A primary source of variable-length data in the RPC header is the authentication information, the form of which is client-determined, possibly in response to server specification. The contents of COMPOUNDs, sizes of strings such as those passed to RENAME, etc. all go into the determination of a maximal NFSv4.1 request size and therefore minimal buffer size. The client must select its offered value carefully, so as to avoid overburdening the server, and vice versa. The benefit of an appropriate padding value is higher performance.
要为填充选择的值取决于许多条件。RPC头中可变长度数据的主要来源是身份验证信息，其形式由客户端确定，可能是响应服务器规范。化合物的内容、字符串的大小（如传递给重命名的字符串）等都将用于确定最大NFSv4.1请求大小，从而确定最小缓冲区大小。客户机必须仔细选择其提供的价值，以避免服务器负担过重，反之亦然。适当的填充值的好处是更高的性能。
Sender gather:
|RPC Request|Pad bytes|Length| -> |User data...|
\------+----------------------/ \
\ \
\ Receiver scatter: \-----------+- ...
/-----+----------------\ \ \
|RPC Request|Pad|Length| -> |FS buffer|->|FS buffer|->...
Sender gather:
|RPC Request|Pad bytes|Length| -> |User data...|
\------+----------------------/ \
\ \
\ Receiver scatter: \-----------+- ...
/-----+----------------\ \ \
|RPC Request|Pad|Length| -> |FS buffer|->|FS buffer|->...
In the above case, the server may recycle unused buffers to the next posted receive if unused by the actual received request, or may pass the now-complete buffers by reference for normal write processing. For a server that can make use of it, this removes any need for data copies of incoming data, without resorting to complicated end-to-end buffer advertisement and management. This includes most kernel-based and integrated server designs, among many others. The client may perform similar optimizations, if desired.
在上述情况下，如果实际接收到的请求未使用，服务器可以将未使用的缓冲区回收到下一次发布的接收，或者可以通过引用传递现在完成的缓冲区以进行正常的写入处理。对于可以使用它的服务器来说，这消除了对传入数据的数据副本的任何需要，而无需求助于复杂的端到端缓冲区公布和管理。这包括大多数基于内核和集成的服务器设计，以及许多其他设计。如果需要，客户端可以执行类似的优化。
Some RDMA transports (e.g., RFC 5040 [10]) permit a "streaming" (non-RDMA) phase, where ordinary traffic might flow before "stepping up" to RDMA mode, commencing RDMA traffic. Some RDMA transports start connections always in RDMA mode. NFSv4.1 allows, but does not assume, a streaming phase before RDMA mode. When a connection is associated with a session, the client and server negotiate whether the connection is used in RDMA or non-RDMA mode (see Sections 18.36 and 18.34).
一些RDMA传输（例如RFC 5040[10]）允许“流”（非RDMA）阶段，其中普通流量可能在“升级”到RDMA模式、开始RDMA流量之前流动。一些RDMA传输总是在RDMA模式下启动连接。NFSv4.1允许但不假设RDMA模式之前的流阶段。当连接与会话关联时，客户机和服务器协商连接是在RDMA模式下使用还是在非RDMA模式下使用（请参阅第18.36和18.34节）。
Via session/connection association, NFSv4.1 improves security over that provided by NFSv4.0 for the backchannel. The connection is client-initiated (see Section 18.34) and subject to the same firewall and routing checks as the fore channel. At the client's option (see Section 18.35), connection association is fully authenticated before being activated (see Section 18.34). Traffic from the server over the backchannel is authenticated exactly as the client specifies (see Section 2.10.8.2).
通过会话/连接关联，NFSv4.1改进了NFSv4.0为反向通道提供的安全性。该连接由客户端启动（见第18.34节），并接受与前通道相同的防火墙和路由检查。根据客户的选择（参见第18.35节），连接关联在激活之前经过完全验证（参见第18.34节）。来自服务器的反向通道流量完全按照客户机的指定进行身份验证（见第2.10.8.2节）。
When the NFSv4.1 client establishes the backchannel, it informs the server of the security flavors and principals to use when sending requests. If the security flavor is RPCSEC_GSS, the client expresses the principal in the form of an established RPCSEC_GSS context. The server is free to use any of the flavor/principal combinations the client offers, but it MUST NOT use unoffered combinations. This way, the client need not provide a target GSS principal for the backchannel as it did with NFSv4.0, nor does the server have to implement an RPCSEC_GSS initiator as it did with NFSv4.0 [30].
当NFSv4.1客户端建立反向通道时，它会通知服务器发送请求时要使用的安全风格和主体。如果安全风格是RPCSEC_GSS，则客户机以已建立的RPCSEC_GSS上下文的形式表示主体。服务器可以自由使用客户端提供的任何风格/主体组合，但不能使用未提供的组合。这样，客户端就不必像NFSv4.0那样为后通道提供目标GSS主体，服务器也不必像NFSv4.0那样实现RPCSEC_GSS启动器[30]。
The CREATE_SESSION (Section 18.36) and BACKCHANNEL_CTL (Section 18.33) operations allow the client to specify flavor/ principal combinations.
CREATE_SESSION（第18.36节）和BACKCHANNEL_CTL（第18.33节）操作允许客户端指定风味/主体组合。
Also note that the SP4_SSV state protection mode (see Sections 18.35 and 2.10.8.3) has the side benefit of providing SSV-derived RPCSEC_GSS contexts (Section 2.10.9).
另请注意，SP4_SSV状态保护模式（见第18.35节和第2.10.8.3节）具有提供SSV派生的RPCSEC_GSS上下文（第2.10.9节）的副作用。
As described to this point in the specification, the state model of NFSv4.1 is vulnerable to an attacker that sends a SEQUENCE operation with a forged session ID and with a slot ID that it expects the legitimate client to use next. When the legitimate client uses the slot ID with the same sequence number, the server returns the attacker's result from the reply cache, which disrupts the legitimate client and thus denies service to it. Similarly, an attacker could send a CREATE_SESSION with a forged client ID to create a new session associated with the client ID. The attacker could send requests using the new session that change locking state, such as LOCKU operations to release locks the legitimate client has acquired. Setting a security policy on the file that requires RPCSEC_GSS credentials when manipulating the file's state is one potential work
正如规范中对此所述，NFSv4.1的状态模型容易受到攻击者的攻击，攻击者使用伪造的会话ID和插槽ID发送序列操作，该插槽ID预期合法客户端下一步使用。当合法客户端使用具有相同序列号的插槽ID时，服务器会从应答缓存返回攻击者的结果，这会中断合法客户端，从而拒绝向其提供服务。类似地，攻击者可以使用伪造的客户端ID发送CREATE_会话，以创建与客户端ID关联的新会话。攻击者可以使用更改锁定状态的新会话发送请求，例如释放合法客户端获得的锁的锁定操作。在操作文件状态时，对需要RPCSEC_GSS凭据的文件设置安全策略是一项潜在的工作
around, but has the disadvantage of preventing a legitimate client from releasing state when RPCSEC_GSS is required to do so, but a GSS context cannot be obtained (possibly because the user has logged off the client).
但其缺点是，当要求RPCSEC_GSS释放状态时，阻止合法客户端释放状态，但无法获得GSS上下文（可能是因为用户已注销客户端）。
NFSv4.1 provides three options to a client for state protection, which are specified when a client creates a client ID via EXCHANGE_ID (Section 18.35).
NFSv4.1为客户端提供了三种状态保护选项，当客户端通过EXCHANGE_ID创建客户端ID时指定这三种选项（第18.35节）。
The first (SP4_NONE) is to simply waive state protection.
第一个（SP4_NONE）是简单地放弃国家保护。
The other two options (SP4_MACH_CRED and SP4_SSV) share several traits:
其他两个选项（SP4_MACH_CRED和SP4_SSV）有几个共同特点：
o An RPCSEC_GSS-based credential is used to authenticate client ID and session maintenance operations, including creating and destroying a session, associating a connection with the session, and destroying the client ID.
o 基于RPCSEC_GSS的凭据用于验证客户端ID和会话维护操作，包括创建和销毁会话、将连接与会话关联以及销毁客户端ID。
o Because RPCSEC_GSS is used to authenticate client ID and session maintenance, the attacker cannot associate a rogue connection with a legitimate session, or associate a rogue session with a legitimate client ID in order to maliciously alter the client ID's lock state via CLOSE, LOCKU, DELEGRETURN, LAYOUTRETURN, etc.
o 由于RPCSEC_GSS用于验证客户端ID和会话维护，攻击者无法将恶意连接与合法会话相关联，或将恶意会话与合法客户端ID相关联，以便通过CLOSE、LOCKU、DELEGRETURN、LAYOUTRETURN等恶意更改客户端ID的锁定状态。
o In cases where the server's security policies on a portion of its namespace require RPCSEC_GSS authentication, a client may have to use an RPCSEC_GSS credential to remove per-file state (e.g., LOCKU, CLOSE, etc.). The server may require that the principal that removes the state match certain criteria (e.g., the principal might have to be the same as the one that acquired the state). However, the client might not have an RPCSEC_GSS context for such a principal, and might not be able to create such a context (perhaps because the user has logged off). When the client establishes SP4_MACH_CRED or SP4_SSV protection, it can specify a list of operations that the server MUST allow using the machine credential (if SP4_MACH_CRED is used) or the SSV credential (if SP4_SSV is used).
o 如果服务器在其命名空间的一部分上的安全策略需要RPCSEC_GSS身份验证，则客户端可能必须使用RPCSEC_GSS凭据来删除每个文件状态（例如，锁定、关闭等）。服务器可能要求删除状态的主体符合某些条件（例如，主体可能必须与获取状态的主体相同）。但是，客户端可能没有此类主体的RPCSEC_GSS上下文，并且可能无法创建此类上下文（可能是因为用户已注销）。当客户端建立SP4_MACH_CRED或SP4_SSV保护时，它可以指定服务器必须允许使用机器凭据（如果使用SP4_MACH_CRED）或SSV凭据（如果使用SP4_SSV）的操作列表。
The SP4_MACH_CRED state protection option uses a machine credential where the principal that creates the client ID MUST also be the principal that performs client ID and session maintenance operations. The security of the machine credential state protection approach depends entirely on safe guarding the per-machine credential. Assuming a proper safeguard using the per-machine credential for operations like CREATE_SESSION, BIND_CONN_TO_SESSION,
SP4_MACH_CRED状态保护选项使用机器凭据，其中创建客户端ID的主体也必须是执行客户端ID和会话维护操作的主体。机器凭证状态保护方法的安全性完全取决于对每台机器凭证的安全保护。假设在创建会话、绑定连接到会话等操作中使用每台机器凭据进行适当的保护，
DESTROY_SESSION, and DESTROY_CLIENTID will prevent an attacker from associating a rogue connection with a session, or associating a rogue session with a client ID.
DESTROY_SESSION和DESTROY_CLIENTID将防止攻击者将恶意连接与会话关联，或将恶意会话与客户端ID关联。
There are at least three scenarios for the SP4_MACH_CRED option:
SP4马赫CRED选项至少有三种情况：
1. The system administrator configures a unique, permanent per-machine credential for one of the mandated GSS mechanisms (e.g., if Kerberos V5 is used, a "keytab" containing a principal derived from a client host name could be used).
1. 系统管理员为其中一个强制GSS机制配置一个唯一的、永久的每机器凭据（例如，如果使用Kerberos V5，则可以使用包含从客户端主机名派生的主体的“keytab”）。
2. The client is used by a single user, and so the client ID and its sessions are used by just that user. If the user's credential expires, then session and client ID maintenance cannot occur, but since the client has a single user, only that user is inconvenienced.
2. 客户端由单个用户使用，因此客户端ID及其会话仅由该用户使用。如果用户的凭据过期，则无法进行会话和客户端ID维护，但由于客户端只有一个用户，因此只会给该用户带来不便。
3. The physical client has multiple users, but the client implementation has a unique client ID for each user. This is effectively the same as the second scenario, but a disadvantage is that each user needs to be allocated at least one session each, so the approach suffers from lack of economy.
3. 物理客户端有多个用户，但客户端实现对每个用户都有一个唯一的客户端ID。这实际上与第二个场景相同，但缺点是每个用户至少需要分配一个会话，因此该方法缺乏经济性。
The SP4_SSV protection option uses the SSV (Section 1.6), via RPCSEC_GSS and the SSV GSS mechanism (Section 2.10.9), to protect state from attack. The SP4_SSV protection option is intended for the situation comprised of a client that has multiple active users and a system administrator who wants to avoid the burden of installing a permanent machine credential on each client. The SSV is established and updated on the server via SET_SSV (see Section 18.47). To prevent eavesdropping, a client SHOULD send SET_SSV via RPCSEC_GSS with the privacy service. Several aspects of the SSV make it intractable for an attacker to guess the SSV, and thus associate rogue connections with a session, and rogue sessions with a client ID:
SP4_SSV保护选项通过RPCSEC_GSS和SSV GSS机制（第2.10.9节）使用SSV（第1.6节）保护状态免受攻击。SP4_SSV保护选项适用于由具有多个活动用户的客户端和希望避免在每个客户端上安装永久机器凭据的系统管理员组成的情况。SSV通过SET_SSV在服务器上建立和更新（见第18.47节）。为了防止窃听，客户端应该通过RPCSEC_GSS和隐私服务发送SET_SSV。SSV的几个方面使得攻击者难以猜测SSV，从而将恶意连接与会话关联，将恶意会话与客户端ID关联：
o The arguments to and results of SET_SSV include digests of the old and new SSV, respectively.
o SET_SSV的参数和结果分别包括旧SSV和新SSV的摘要。
o Because the initial value of the SSV is zero, therefore known, the client that opts for SP4_SSV protection and opts to apply SP4_SSV protection to BIND_CONN_TO_SESSION and CREATE_SESSION MUST send at least one SET_SSV operation before the first BIND_CONN_TO_SESSION operation or before the second CREATE_SESSION operation on a client ID. If it does not, the SSV mechanism will not generate tokens (Section 2.10.9). A client SHOULD send SET_SSV as soon as a session is created.
o 由于SSV的初始值为零，因此已知，选择SP4_SSV保护并选择应用SP4_SSV保护以绑定_CONN_to_会话和创建_会话的客户端必须在对客户端ID执行第一次绑定_CONN_to_会话操作或第二次创建_会话操作之前发送至少一个SET_SSV操作。如果未发送，SSV机制将不会生成令牌（第2.10.9节）。创建会话后，客户端应立即发送SET_SSV。
o A SET_SSV request does not replace the SSV with the argument to SET_SSV. Instead, the current SSV on the server is logically exclusive ORed (XORed) with the argument to SET_SSV. Each time a new principal uses a client ID for the first time, the client SHOULD send a SET_SSV with that principal's RPCSEC_GSS credentials, with RPCSEC_GSS service set to RPC_GSS_SVC_PRIVACY.
o SET_SSV请求不会用SET_SSV的参数替换SSV。相反，服务器上的当前SSV在逻辑上是异或的（XORed），参数为SET_SSV。每次新主体首次使用客户端ID时，客户端应发送一个带有该主体的RPCSEC_GSS凭据的SET_SSV，并将RPCSEC_GSS服务设置为RPC_GSS_SVC_PRIVACY。
Here are the types of attacks that can be attempted by an attacker named Eve on a victim named Bob, and how SP4_SSV protection foils each attack:
以下是名为Eve的攻击者可以对名为Bob的受害者尝试的攻击类型，以及SP4_SSV保护如何挫败每次攻击：
o Suppose Eve is the first user to log into a legitimate client. Eve's use of an NFSv4.1 file system will cause the legitimate client to create a client ID with SP4_SSV protection, specifying that the BIND_CONN_TO_SESSION operation MUST use the SSV credential. Eve's use of the file system also causes an SSV to be created. The SET_SSV operation that creates the SSV will be protected by the RPCSEC_GSS context created by the legitimate client, which uses Eve's GSS principal and credentials. Eve can eavesdrop on the network while her RPCSEC_GSS context is created and the SET_SSV using her context is sent. Even if the legitimate client sends the SET_SSV with RPC_GSS_SVC_PRIVACY, because Eve knows her own credentials, she can decrypt the SSV. Eve can compute an RPCSEC_GSS credential that BIND_CONN_TO_SESSION will accept, and so associate a new connection with the legitimate session. Eve can change the slot ID and sequence state of a legitimate session, and/or the SSV state, in such a way that when Bob accesses the server via the same legitimate client, the legitimate client will be unable to use the session.
o 假设Eve是第一个登录到合法客户端的用户。Eve使用NFSv4.1文件系统将导致合法客户端创建具有SP4_SSV保护的客户端ID，并指定绑定连接到会话操作必须使用SSV凭据。Eve对文件系统的使用也会导致创建SSV。创建SSV的SET_SSV操作将受到合法客户端创建的RPCSEC_GSS上下文的保护，该上下文使用Eve的GSS主体和凭据。Eve可以在创建其RPCSEC_GSS上下文并发送使用其上下文的SET_SSV时窃听网络。即使合法客户端发送带有RPC_GSS_SVC_隐私的SET_SSV，因为Eve知道自己的凭据，她也可以解密SSV。Eve可以计算一个RPCSEC_GSS凭据，该凭据将_CONN_绑定到会话将接受的会话，从而将新连接与合法会话相关联。Eve可以更改合法会话的插槽ID和序列状态，和/或SSV状态，这样当Bob通过同一合法客户端访问服务器时，合法客户端将无法使用该会话。
The client's only recourse is to create a new client ID for Bob to use, and establish a new SSV for the client ID. The client will be unable to delete the old client ID, and will let the lease on the old client ID expire.
客户唯一的办法是创建一个新的客户ID供Bob使用，并为客户ID建立一个新的SSV。客户将无法删除旧客户ID，并将让旧客户ID的租约到期。
Once the legitimate client establishes an SSV over the new session using Bob's RPCSEC_GSS context, Eve can use the new session via the legitimate client, but she cannot disrupt Bob. Moreover, because the client SHOULD have modified the SSV due to Eve using the new session, Bob cannot get revenge on Eve by associating a rogue connection with the session.
一旦合法客户端使用Bob的RPCSEC_GSS上下文在新会话上建立SSV，Eve可以通过合法客户端使用新会话，但她不能中断Bob。此外，由于Eve使用新会话，客户端本应修改SSV，因此Bob无法通过将恶意连接与会话关联来报复Eve。
The question is how did the legitimate client detect that Eve has hijacked the old session? When the client detects that a new principal, Bob, wants to use the session, it SHOULD have sent a SET_SSV, which leads to the following sub-scenarios:
问题是合法客户是如何发现Eve劫持了旧会话的？当客户端检测到新主体Bob想要使用会话时，它应该发送一个SET_SSV，这将导致以下子场景：
* Let us suppose that from the rogue connection, Eve sent a SET_SSV with the same slot ID and sequence ID that the legitimate client later uses. The server will assume the SET_SSV sent with Bob's credentials is a retry, and return to the legitimate client the reply it sent Eve. However, unless Eve can correctly guess the SSV the legitimate client will use, the digest verification checks in the SET_SSV response will fail. That is an indication to the client that the session has apparently been hijacked.
* 让我们假设Eve从rogue连接发送了一个SET_SSV，该SET_SSV具有合法客户端稍后使用的相同插槽ID和序列ID。服务器将假定使用Bob的凭据发送的SET_SSV是重试，并将其发送的回复返回给合法客户端。但是，除非Eve能够正确猜测合法客户端将使用的SSV，否则SET_SSV响应中的摘要验证检查将失败。这向客户端表明会话显然已被劫持。
* Alternatively, Eve sent a SET_SSV with a different slot ID than the legitimate client uses for its SET_SSV. Then the digest verification of the SET_SSV sent with Bob's credentials fails on the server, and the error returned to the client makes it apparent that the session has been hijacked.
* 或者，Eve发送的SET_SSV的插槽ID与合法客户端用于其SET_SSV的插槽ID不同。然后，服务器上对使用Bob凭据发送的SET_SSV的摘要验证失败，返回给客户端的错误表明会话已被劫持。
* Alternatively, Eve sent an operation other than SET_SSV, but with the same slot ID and sequence that the legitimate client uses for its SET_SSV. The server returns to the legitimate client the response it sent Eve. The client sees that the response is not at all what it expects. The client assumes either session hijacking or a server bug, and either way destroys the old session.
* 或者，Eve发送的操作不是SET_SSV，而是合法客户端用于其SET_SSV的相同插槽ID和序列。服务器将其发送的响应返回给合法客户端。客户机发现响应根本不是它所期望的。客户端假定会话劫持或服务器错误，并以任何方式破坏旧会话。
o Eve associates a rogue connection with the session as above, and then destroys the session. Again, Bob goes to use the server from the legitimate client, which sends a SET_SSV using Bob's credentials. The client receives an error that indicates that the session does not exist. When the client tries to create a new session, this will fail because the SSV it has does not match that which the server has, and now the client knows the session was hijacked. The legitimate client establishes a new client ID.
o Eve如上所述将流氓连接与会话关联，然后销毁会话。同样，Bob使用来自合法客户端的服务器，该客户端使用Bob的凭据发送一组SSV。客户端收到一个错误，指示会话不存在。当客户端尝试创建新会话时，这将失败，因为它拥有的SSV与服务器拥有的SSV不匹配，现在客户端知道会话被劫持。合法客户端建立一个新的客户端ID。
o If Eve creates a connection before the legitimate client establishes an SSV, because the initial value of the SSV is zero and therefore known, Eve can send a SET_SSV that will pass the digest verification check. However, because the new connection has not been associated with the session, the SET_SSV is rejected for that reason.
o 如果Eve在合法客户端建立SSV之前创建连接，因为SSV的初始值为零，因此已知，Eve可以发送一个SET_SSV，该SSV将通过摘要验证检查。但是，由于新连接尚未与会话关联，因此SET_SSV将因此被拒绝。
In summary, an attacker's disruption of state when SP4_SSV protection is in use is limited to the formative period of a client ID, its first session, and the establishment of the SSV. Once a non-malicious user uses the client ID, the client quickly detects any hijack and rectifies the situation. Once a non-malicious user successfully modifies the SSV, the attacker cannot use NFSv4.1 operations to disrupt the non-malicious user.
总之，当使用SP4_SSV保护时，攻击者对状态的破坏仅限于客户端ID的形成期、其第一个会话和SSV的建立。一旦非恶意用户使用客户端ID，客户端将快速检测任何劫持并纠正情况。一旦非恶意用户成功修改SSV，攻击者就无法使用NFSv4.1操作中断非恶意用户。
Note that neither the SP4_MACH_CRED nor SP4_SSV protection approaches prevent hijacking of a transport connection that has previously been associated with a session. If the goal of a counter-threat strategy is to prevent connection hijacking, the use of IPsec is RECOMMENDED.
请注意，无论是SP4_MACH_CRED还是SP4_SSV保护方法都不能防止劫持以前与会话关联的传输连接。如果反威胁策略的目标是防止连接劫持，建议使用IPsec。
If a connection hijack occurs, the hijacker could in theory change locking state and negatively impact the service to legitimate clients. However, if the server is configured to require the use of RPCSEC_GSS with integrity or privacy on the affected file objects, and if EXCHGID4_FLAG_BIND_PRINC_STATEID capability (Section 18.35) is in force, this will thwart unauthorized attempts to change locking state.
如果发生连接劫持，理论上劫持者可能会改变锁定状态，并对合法客户端的服务产生负面影响。但是，如果服务器配置为要求在受影响的文件对象上使用具有完整性或隐私性的RPCSEC\u GSS，并且如果EXCHGID4\u FLAG\u BIND\u PRINC\u STATEID功能（第18.35节）有效，这将阻止未经授权的更改锁定状态的尝试。
The SSV provides the secret key for a GSS mechanism internal to NFSv4.1 that NFSv4.1 uses for state protection. Contexts for this mechanism are not established via the RPCSEC_GSS protocol. Instead, the contexts are automatically created when EXCHANGE_ID specifies SP4_SSV protection. The only tokens defined are the PerMsgToken (emitted by GSS_GetMIC) and the SealedMessage token (emitted by GSS_Wrap).
SSV为NFSv4.1内部的GSS机制提供密钥，NFSv4.1使用该机制进行状态保护。该机制的上下文不是通过RPCSEC_GSS协议建立的。相反，当EXCHANGE_ID指定SP4_SSV保护时，会自动创建上下文。唯一定义的令牌是PerMsgToken（由GSS_GetMIC发出）和SealedMessage令牌（由GSS_Wrap发出）。
The mechanism OID for the SSV mechanism is iso.org.dod.internet.private.enterprise.Michael Eisler.nfs.ssv_mech (1.3.6.1.4.1.28882.1.1). While the SSV mechanism does not define any initial context tokens, the OID can be used to let servers indicate that the SSV mechanism is acceptable whenever the client sends a SECINFO or SECINFO_NO_NAME operation (see Section 2.6).
SSV机制的机制OID是iso.org.dod.internet.private.enterprise.Michael Eisler.nfs.SSV_mech（1.3.6.1.4.1.28882.1.1）。虽然SSV机制未定义任何初始上下文令牌，但OID可用于让服务器在客户端发送SECINFO或SECINFO_NO_NAME操作时指示SSV机制是可接受的（请参阅第2.6节）。
The SSV mechanism defines four subkeys derived from the SSV value. Each time SET_SSV is invoked, the subkeys are recalculated by the client and server. The calculation of each of the four subkeys depends on each of the four respective ssv_subkey4 enumerated values. The calculation uses the HMAC [11] algorithm, using the current SSV as the key, the one-way hash algorithm as negotiated by EXCHANGE_ID, and the input text as represented by the XDR encoded enumeration value for that subkey of data type ssv_subkey4. If the length of the output of the HMAC algorithm exceeds the length of key of the encryption algorithm (which is also negotiated by EXCHANGE_ID), then the subkey MUST be truncated from the HMAC output, i.e., if the subkey is of N bytes long, then the first N bytes of the HMAC output MUST be used for the subkey. The specification of EXCHANGE_ID states that the length of the output of the HMAC algorithm MUST NOT be less than the length of subkey needed for the encryption algorithm (see Section 18.35).
SSV机制定义了从SSV值派生的四个子键。每次调用SET_SSV时，客户端和服务器都会重新计算子键。四个子键中每一个子键的计算取决于四个各自的ssv_子键4枚举值中的每一个。该计算使用HMAC[11]算法，使用当前SSV作为密钥，使用EXCHANGE_ID协商的单向哈希算法，并使用数据类型为SSV_subkey4的子密钥的XDR编码枚举值表示的输入文本。如果HMAC算法的输出长度超过加密算法的密钥长度（也由EXCHANGE_ID协商），则必须从HMAC输出中截断子密钥，即，如果子密钥长度为N字节，则必须将HMAC输出的前N字节用于子密钥。交换ID规范规定HMAC算法的输出长度不得小于加密算法所需的子密钥长度（见第18.35节）。
/* Input for computing subkeys */
enum ssv_subkey4 {
SSV4_SUBKEY_MIC_I2T = 1,
SSV4_SUBKEY_MIC_T2I = 2,
SSV4_SUBKEY_SEAL_I2T = 3,
SSV4_SUBKEY_SEAL_T2I = 4
};
/* Input for computing subkeys */
enum ssv_subkey4 {
SSV4_SUBKEY_MIC_I2T = 1,
SSV4_SUBKEY_MIC_T2I = 2,
SSV4_SUBKEY_SEAL_I2T = 3,
SSV4_SUBKEY_SEAL_T2I = 4
};
The subkey derived from SSV4_SUBKEY_MIC_I2T is used for calculating message integrity codes (MICs) that originate from the NFSv4.1 client, whether as part of a request over the fore channel or a response over the backchannel. The subkey derived from SSV4_SUBKEY_MIC_T2I is used for MICs originating from the NFSv4.1 server. The subkey derived from SSV4_SUBKEY_SEAL_I2T is used for encryption text originating from the NFSv4.1 client, and the subkey derived from SSV4_SUBKEY_SEAL_T2I is used for encryption text originating from the NFSv4.1 server.
从SSV4_subkey_MIC_I2T派生的子密钥用于计算源自NFSv4.1客户端的消息完整性代码（MIC），无论是作为前通道请求的一部分还是作为后通道响应的一部分。从SSV4_subkey_MIC_T2I派生的子键用于源自NFSv4.1服务器的MIC。从SSV4_subkey_SEAL_I2T派生的子密钥用于源自NFSv4.1客户端的加密文本，从SSV4_subkey_SEAL_T2I派生的子密钥用于源自NFSv4.1服务器的加密文本。
The PerMsgToken description is based on an XDR definition:
PerMsgToken描述基于XDR定义：
/* Input for computing smt_hmac */
struct ssv_mic_plain_tkn4 {
uint32_t smpt_ssv_seq;
opaque smpt_orig_plain<>;
};
/* Input for computing smt_hmac */
struct ssv_mic_plain_tkn4 {
uint32_t smpt_ssv_seq;
opaque smpt_orig_plain<>;
};
/* SSV GSS PerMsgToken token */
struct ssv_mic_tkn4 {
uint32_t smt_ssv_seq;
opaque smt_hmac<>;
};
/* SSV GSS PerMsgToken token */
struct ssv_mic_tkn4 {
uint32_t smt_ssv_seq;
opaque smt_hmac<>;
};
The field smt_hmac is an HMAC calculated by using the subkey derived from SSV4_SUBKEY_MIC_I2T or SSV4_SUBKEY_MIC_T2I as the key, the one-way hash algorithm as negotiated by EXCHANGE_ID, and the input text as represented by data of type ssv_mic_plain_tkn4. The field smpt_ssv_seq is the same as smt_ssv_seq. The field smpt_orig_plain is the "message" input passed to GSS_GetMIC() (see Section 2.3.1 of [7]). The caller of GSS_GetMIC() provides a pointer to a buffer containing the plain text. The SSV mechanism's entry point for GSS_GetMIC() encodes this into an opaque array, and the encoding will include an initial four-byte length, plus any necessary padding. Prepended to this will be the XDR encoded value of smpt_ssv_seq, thus making up an XDR encoding of a value of data type ssv_mic_plain_tkn4, which in turn is the input into the HMAC.
字段smt_hmac是通过使用从SSV4_subkey_MIC_I2T或SSV4_subkey_MIC_T2I派生的子键作为键、由交换ID协商的单向散列算法以及由ssv_MIC_plain_tkn4类型的数据表示的输入文本来计算的hmac。字段smpt_ssv_seq与smt_ssv_seq相同。字段smpt_orig_plain是传递给GSS_GetMIC（）的“消息”输入（见[7]第2.3.1节）。GSS_GetMIC（）的调用者提供指向包含纯文本的缓冲区的指针。SSV机制的GSS_GetMIC（）入口点将其编码为不透明数组，编码将包括初始的四字节长度，以及任何必要的填充。在此之前将是smpt_ssv_seq的XDR编码值，从而构成数据类型ssv_mic_plain_tkn4的值的XDR编码，该值反过来是HMAC的输入。
The token emitted by GSS_GetMIC() is XDR encoded and of XDR data type ssv_mic_tkn4. The field smt_ssv_seq comes from the SSV sequence number, which is equal to one after SET_SSV (Section 18.47) is called the first time on a client ID. Thereafter, the SSV sequence number is incremented on each SET_SSV. Thus, smt_ssv_seq represents the version of the SSV at the time GSS_GetMIC() was called. As noted in Section 18.35, the client and server can maintain multiple concurrent versions of the SSV. This allows the SSV to be changed without serializing all RPC calls that use the SSV mechanism with SET_SSV operations. Once the HMAC is calculated, it is XDR encoded into smt_hmac, which will include an initial four-byte length, and any necessary padding. Prepended to this will be the XDR encoded value of smt_ssv_seq.
GSS_GetMIC（）发出的令牌是XDR编码的，其XDR数据类型为ssv_mic_tkn4。字段smt_ssv_seq来自ssv序列号，该序列号等于在客户端ID上第一次调用SET_ssv（第18.47节）后的一个序列号。此后，ssv序列号在每个SET_ssv上递增。因此，smt_ssv_seq表示调用GSS_GetMIC（）时ssv的版本。如第18.35节所述，客户端和服务器可以维护SSV的多个并发版本。这允许在不序列化所有使用SSV机制和SET_SSV操作的RPC调用的情况下更改SSV。一旦计算出HMAC，它就被XDR编码到smt_HMAC中，其中包括初始的四字节长度和任何必要的填充。在此之前将是smt_ssv_seq的XDR编码值。
The SealedMessage description is based on an XDR definition:
Sealed消息描述基于XDR定义：
/* Input for computing ssct_encr_data and ssct_hmac */
struct ssv_seal_plain_tkn4 {
opaque sspt_confounder<>;
uint32_t sspt_ssv_seq;
opaque sspt_orig_plain<>;
opaque sspt_pad<>;
};
/* Input for computing ssct_encr_data and ssct_hmac */
struct ssv_seal_plain_tkn4 {
opaque sspt_confounder<>;
uint32_t sspt_ssv_seq;
opaque sspt_orig_plain<>;
opaque sspt_pad<>;
};
/* SSV GSS SealedMessage token */
struct ssv_seal_cipher_tkn4 {
uint32_t ssct_ssv_seq;
opaque ssct_iv<>;
opaque ssct_encr_data<>;
opaque ssct_hmac<>;
};
/* SSV GSS SealedMessage token */
struct ssv_seal_cipher_tkn4 {
uint32_t ssct_ssv_seq;
opaque ssct_iv<>;
opaque ssct_encr_data<>;
opaque ssct_hmac<>;
};
The token emitted by GSS_Wrap() is XDR encoded and of XDR data type ssv_seal_cipher_tkn4.
GSS_Wrap（）发出的令牌是XDR编码的，其XDR数据类型为ssv_seal_cipher_tkn4。
The ssct_ssv_seq field has the same meaning as smt_ssv_seq.
ssct_ssv_seq字段的含义与smt_ssv_seq相同。
The ssct_encr_data field is the result of encrypting a value of the XDR encoded data type ssv_seal_plain_tkn4. The encryption key is the subkey derived from SSV4_SUBKEY_SEAL_I2T or SSV4_SUBKEY_SEAL_T2I, and the encryption algorithm is that negotiated by EXCHANGE_ID.
ssct_encr_数据字段是加密XDR编码数据类型ssv_seal_plain_tkn4的值的结果。加密密钥是从SSV4\u subkey\u SEAL\u I2T或SSV4\u subkey\u SEAL\u T2I派生的子密钥，加密算法是由EXCHANGE\u ID协商的。
The ssct_iv field is the initialization vector (IV) for the encryption algorithm (if applicable) and is sent in clear text. The content and size of the IV MUST comply with the specification of the encryption algorithm. For example, the id-aes256-CBC algorithm MUST
ssct_iv字段是加密算法（如适用）的初始化向量（iv），以明文形式发送。IV的内容和大小必须符合加密算法的规范。例如，id-aes256-CBC算法必须
use a 16-byte initialization vector (IV), which MUST be unpredictable for each instance of a value of data type ssv_seal_plain_tkn4 that is encrypted with a particular SSV key.
使用16字节的初始化向量（IV），对于使用特定ssv密钥加密的数据类型ssv_seal_plain_tkn4的值的每个实例，该向量必须是不可预测的。
The ssct_hmac field is the result of computing an HMAC using the value of the XDR encoded data type ssv_seal_plain_tkn4 as the input text. The key is the subkey derived from SSV4_SUBKEY_MIC_I2T or SSV4_SUBKEY_MIC_T2I, and the one-way hash algorithm is that negotiated by EXCHANGE_ID.
ssct_hmac字段是使用XDR编码数据类型ssv_seal_plain_tkn4的值作为输入文本计算hmac的结果。密钥是从SSV4\u subkey\u MIC\u I2T或SSV4\u subkey\u MIC\u T2I派生的子密钥，单向散列算法是由EXCHANGE\u ID协商的。
The sspt_confounder field is a random value.
sspt_共聚焦字段是一个随机值。
The sspt_ssv_seq field is the same as ssvt_ssv_seq.
sspt_ssv_seq字段与ssvt_ssv_seq字段相同。
The field sspt_orig_plain field is the original plaintext and is the "input_message" input passed to GSS_Wrap() (see Section 2.3.3 of [7]). As with the handling of the plaintext by the SSV mechanism's GSS_GetMIC() entry point, the entry point for GSS_Wrap() expects a pointer to the plaintext, and will XDR encode an opaque array into sspt_orig_plain representing the plain text, along with the other fields of an instance of data type ssv_seal_plain_tkn4.
字段sspt_orig_plain字段是原始明文，是传递给GSS_Wrap（）的“输入消息”输入（见[7]第2.3.3节）。与SSV机制的GSS_GetMIC（）入口点对明文的处理一样，GSS_Wrap（）的入口点需要一个指向明文的指针，并将XDR编码一个不透明数组到表示明文的sspt_orig_plain，以及数据类型SSV_seal_plain_tkn4实例的其他字段中。
The sspt_pad field is present to support encryption algorithms that require inputs to be in fixed-sized blocks. The content of sspt_pad is zero filled except for the length. Beware that the XDR encoding of ssv_seal_plain_tkn4 contains three variable-length arrays, and so each array consumes four bytes for an array length, and each array that follows the length is always padded to a multiple of four bytes per the XDR standard.
sspt_pad字段用于支持需要输入固定大小块的加密算法。sspt_焊盘的内容为零填充，长度除外。请注意，ssv_seal_plain_tkn4的XDR编码包含三个可变长度数组，因此每个数组的数组长度消耗四个字节，并且根据XDR标准，长度后面的每个数组始终填充为四个字节的倍数。
For example, suppose the encryption algorithm uses 16-byte blocks, and the sspt_confounder is three bytes long, and the sspt_orig_plain field is 15 bytes long. The XDR encoding of sspt_confounder uses eight bytes (4 + 3 + 1 byte pad), the XDR encoding of sspt_ssv_seq uses four bytes, the XDR encoding of sspt_orig_plain uses 20 bytes (4 + 15 + 1 byte pad), and the smallest XDR encoding of the sspt_pad field is four bytes. This totals 36 bytes. The next multiple of 16 is 48; thus, the length field of sspt_pad needs to be set to 12 bytes, or a total encoding of 16 bytes. The total number of XDR encoded bytes is thus 8 + 4 + 20 + 16 = 48.
例如，假设加密算法使用16字节块，sspt_Confour长度为3字节，sspt_orig_plain字段长度为15字节。sspt_Confour的XDR编码使用8个字节（4+3+1字节pad），sspt_ssv_seq的XDR编码使用4个字节，sspt_orig_plain的XDR编码使用20个字节（4+15+1字节pad），sspt_pad字段的最小XDR编码为4个字节。总共36个字节。16的下一个倍数是48；因此，sspt_焊盘的长度字段需要设置为12个字节，或总编码为16个字节。因此，XDR编码字节的总数为8+4+20+16=48。
GSS_Wrap() emits a token that is an XDR encoding of a value of data type ssv_seal_cipher_tkn4. Note that regardless of whether or not the caller of GSS_Wrap() requests confidentiality, the token always has confidentiality. This is because the SSV mechanism is for RPCSEC_GSS, and RPCSEC_GSS never produces GSS_wrap() tokens without confidentiality.
GSS_Wrap（）发出一个令牌，该令牌是数据类型为ssv_seal_cipher_tkn4的值的XDR编码。请注意，无论GSS_Wrap（）的调用方是否请求机密性，令牌始终具有机密性。这是因为SSV机制是针对RPCSEC_GSS的，并且RPCSEC_GSS从不在没有保密性的情况下生成GSS_wrap（）令牌。
There is one SSV per client ID. There is a single GSS context for a client ID / SSV pair. All SSV mechanism RPCSEC_GSS handles of a client ID / SSV pair share the same GSS context. SSV GSS contexts do not expire except when the SSV is destroyed (causes would include the client ID being destroyed or a server restart). Since one purpose of context expiration is to replace keys that have been in use for "too long", hence vulnerable to compromise by brute force or accident, the client can replace the SSV key by sending periodic SET_SSV operations, which is done by cycling through different users' RPCSEC_GSS credentials. This way, the SSV is replaced without destroying the SSV's GSS contexts.
每个客户端ID有一个SSV。客户端ID/SSV对有一个GSS上下文。客户端ID/SSV对的所有SSV机制RPCSEC_GSS句柄共享相同的GSS上下文。SSV GSS上下文不会过期，除非SSV被销毁（原因包括客户端ID被销毁或服务器重新启动）。由于上下文过期的一个目的是替换已使用“太久”的密钥，因此容易受到暴力或事故的破坏，因此客户端可以通过发送定期SET_SSV操作来替换SSV密钥，这是通过循环使用不同用户的RPCSEC_GSS凭据来完成的。这样，在不破坏SSV的GSS上下文的情况下替换SSV。
SSV RPCSEC_GSS handles can be expired or deleted by the server at any time, and the EXCHANGE_ID operation can be used to create more SSV RPCSEC_GSS handles. Expiration of SSV RPCSEC_GSS handles does not imply that the SSV or its GSS context has expired.
服务器可以随时过期或删除SSV RPCSEC_GSS句柄，并且可以使用EXCHANGE_ID操作创建更多SSV RPCSEC_GSS句柄。SSV RPCSEC_GSS句柄的过期并不意味着SSV或其GSS上下文已过期。
The client MUST establish an SSV via SET_SSV before the SSV GSS context can be used to emit tokens from GSS_Wrap() and GSS_GetMIC(). If SET_SSV has not been successfully called, attempts to emit tokens MUST fail.
在SSV GSS上下文可用于从GSS_Wrap（）和GSS_GetMIC（）发出令牌之前，客户端必须通过SET_SSV建立SSV。如果未成功调用SET_SSV，则发射令牌的尝试必须失败。
The SSV mechanism does not support replay detection and sequencing in its tokens because RPCSEC_GSS does not use those features (See Section 5.2.2, "Context Creation Requests", in [4]). However, Section 2.10.10 discusses special considerations for the SSV mechanism when used with RPCSEC_GSS.
SSV机制不支持其令牌中的重播检测和排序，因为RPCSEC_GSS不使用这些功能（请参阅[4]中的第5.2.2节“上下文创建请求”）。但是，第2.10.10节讨论了与RPCSEC_GSS一起使用时SSV机制的特殊注意事项。
2.10.10. Security Considerations for RPCSEC_GSS When Using the SSV Mechanism
2.10.10. 使用SSV机制时RPCSEC_GSS的安全注意事项
When a client ID is created with SP4_SSV state protection (see Section 18.35), the client is permitted to associate multiple RPCSEC_GSS handles with the single SSV GSS context (see Section 2.10.9). Because of the way RPCSEC_GSS (both version 1 and version 2, see [4] and [12]) calculate the verifier of the reply, special care must be taken by the implementation of the NFSv4.1 client to prevent attacks by a man-in-the-middle. The verifier of an RPCSEC_GSS reply is the output of GSS_GetMIC() applied to the input value of the seq_num field of the RPCSEC_GSS credential (data type rpc_gss_cred_ver_1_t) (see Section 5.3.3.2 of [4]). If multiple RPCSEC_GSS handles share the same GSS context, then if one handle is used to send a request with the same seq_num value as another handle, an attacker could block the reply, and replace it with the verifier used for the other handle.
使用SP4_SSV状态保护创建客户端ID时（参见第18.35节），允许客户端将多个RPCSEC_GSS句柄与单个SSV GSS上下文关联（参见第2.10.9节）。由于RPCSEC_GSS（版本1和版本2，请参见[4]和[12]）计算回复验证器的方式，NFSv4.1客户端的实现必须特别小心，以防止中间人的攻击。RPCSEC_GSS回复的验证器是GSS_GetMIC（）的输出，应用于RPCSEC_GSS凭证的seq_num字段的输入值（数据类型为rpc_GSS_cred_ver_1_t）（见[4]第5.3.3.2节）。如果多个RPCSEC_GSS句柄共享相同的GSS上下文，则如果一个句柄用于发送与另一个句柄具有相同seq_num值的请求，则攻击者可以阻止回复，并将其替换为用于另一个句柄的验证器。
There are multiple ways to prevent the attack on the SSV RPCSEC_GSS verifier in the reply. The simplest is believed to be as follows.
在回复中，有多种方法可以防止对SSV RPCSEC_GSS验证器的攻击。最简单的被认为是如下。
o Each time one or more new SSV RPCSEC_GSS handles are created via EXCHANGE_ID, the client SHOULD send a SET_SSV operation to modify the SSV. By changing the SSV, the new handles will not result in the re-use of an SSV RPCSEC_GSS verifier in a reply.
o 每次通过EXCHANGE_ID创建一个或多个新SSV RPCSEC_GSS句柄时，客户端应发送一个SET_SSV操作来修改SSV。通过更改SSV，新句柄不会导致在回复中重复使用SSV RPCSEC_GSS验证器。
o When a requester decides to use N SSV RPCSEC_GSS handles, it SHOULD assign a unique and non-overlapping range of seq_nums to each SSV RPCSEC_GSS handle. The size of each range SHOULD be equal to MAXSEQ / N (see Section 5 of [4] for the definition of MAXSEQ). When an SSV RPCSEC_GSS handle reaches its maximum, it SHOULD force the replier to destroy the handle by sending a NULL RPC request with seq_num set to MAXSEQ + 1 (see Section 5.3.3.3 of [4]).
o 当请求者决定使用N个SSV RPCSEC_GSS句柄时，它应该为每个SSV RPCSEC_GSS句柄分配一个唯一且不重叠的序号范围。每个范围的大小应等于MAXSEQ/N（有关MAXSEQ的定义，请参见[4]第5节）。当SSV RPCSEC_GSS句柄达到其最大值时，它应通过发送一个将seq_num设置为MAXSEQ+1的空RPC请求（请参见[4]第5.3.3节），强制应答器销毁该句柄。
o When the requester wants to increase or decrease N, it SHOULD force the replier to destroy all N handles by sending a NULL RPC request on each handle with seq_num set to MAXSEQ + 1. If the requester is the client, it SHOULD send a SET_SSV operation before using new handles. If the requester is the server, then the client SHOULD send a SET_SSV operation when it detects that the server has forced it to destroy a backchannel's SSV RPCSEC_GSS handle. By sending a SET_SSV operation, the SSV will change, and so the attacker will be unavailable to successfully replay a previous verifier in a reply to the requester.
o 当请求者想要增加或减少N时，它应该强制应答器销毁所有N个句柄，方法是在每个句柄上发送一个NULL RPC请求，并将seq_num设置为MAXSEQ+1。如果请求者是客户机，它应该在使用新句柄之前发送SET_SSV操作。如果请求者是服务器，则当客户端检测到服务器已强制其销毁反向通道的SSV RPCSEC_GSS句柄时，应发送一个SET_SSV操作。通过发送SET_SSV操作，SSV将发生更改，因此攻击者将无法在回复请求者时成功重播以前的验证器。
Note that if the replier carefully creates the SSV RPCSEC_GSS handles, the related risk of a man-in-the-middle splicing a forged SSV RPCSEC_GSS credential with a verifier for another handle does not exist. This is because the verifier in an RPCSEC_GSS request is computed from input that includes both the RPCSEC_GSS handle and seq_num (see Section 5.3.1 of [4]). Provided the replier takes care to avoid re-using the value of an RPCSEC_GSS handle that it creates, such as by including a generation number in the handle, the man-in-the-middle will not be able to successfully replay a previous verifier in the request to a replier.
请注意，如果应答者小心创建SSV RPCSEC_GSS句柄，则中间人将伪造SSV RPCSEC_GSS凭证与另一个句柄的验证器拼接的相关风险不存在。这是因为RPCSEC_GSS请求中的验证器是根据包含RPCSEC_GSS句柄和seq_num的输入计算的（见[4]第5.3.1节）。如果应答器注意避免重复使用它创建的RPCSEC_GSS句柄的值，例如通过在句柄中包含一个生成号，则中间人将无法成功地将请求中的前一个验证器重播给应答器。
The server has the primary obligation to monitor the state of backchannel resources that the client has created for the server (RPCSEC_GSS contexts and backchannel connections). If these resources vanish, the server takes action as specified in Section 2.10.13.2.
服务器的主要职责是监视客户端为服务器创建的反向通道资源的状态（RPCSEC_GSS上下文和反向通道连接）。如果这些资源消失，服务器将按照第2.10.13.2节的规定采取行动。
The client SHOULD honor the following obligations in order to utilize the session:
客户应履行以下义务，以利用本次会议：
o Keep a necessary session from going idle on the server. A client that requires a session but nonetheless is not sending operations risks having the session be destroyed by the server. This is because sessions consume resources, and resource limitations may force the server to cull an inactive session. A server MAY consider a session to be inactive if the client has not used the session before the session inactivity timer (Section 2.10.12) has expired.
o 保持必要的会话在服务器上不空闲。需要会话但不发送操作的客户端有可能被服务器破坏会话。这是因为会话消耗资源，而资源限制可能会迫使服务器剔除非活动会话。如果客户端在会话不活动计时器（第2.1.12节）过期之前未使用会话，则服务器可以考虑会话不活动。
o Destroy the session when not needed. If a client has multiple sessions, one of which has no requests waiting for replies, and has been idle for some period of time, it SHOULD destroy the session.
o 在不需要时销毁会话。如果一个客户端有多个会话，其中一个会话没有等待答复的请求，并且已经空闲了一段时间，那么它应该销毁该会话。
o Maintain GSS contexts and RPCSEC_GSS handles for the backchannel. If the client requires the server to use the RPCSEC_GSS security flavor for callbacks, then it needs to be sure the RPCSEC_GSS handles and/or their GSS contexts that are handed to the server via BACKCHANNEL_CTL or CREATE_SESSION are unexpired.
o 维护反向通道的GSS上下文和RPCSEC_GSS句柄。如果客户端要求服务器使用RPCSEC_GSS安全风格进行回调，则需要确保RPCSEC_GSS处理和/或其通过BACKCHANNEL_CTL或CREATE_会话传递给服务器的GSS上下文未过期。
o Preserve a connection for a backchannel. The server requires a backchannel in order to gracefully recall recallable state or notify the client of certain events. Note that if the connection is not being used for the fore channel, there is no way for the client to tell if the connection is still alive (e.g., the server restarted without sending a disconnect). The onus is on the server, not the client, to determine if the backchannel's connection is alive, and to indicate in the response to a SEQUENCE operation when the last connection associated with a session's backchannel has disconnected.
o 保留反向通道的连接。服务器需要一个反向通道，以便正常地调用可重调状态或将某些事件通知客户端。请注意，如果前通道未使用该连接，则客户端无法判断该连接是否仍处于活动状态（例如，服务器在不发送断开连接的情况下重新启动）。ONU在服务器上，而不是在客户端上，以确定反向通道的连接是否处于活动状态，并在对序列操作的响应中指示与会话反向通道关联的最后一个连接何时断开。
If the client does not have a client ID, the client sends EXCHANGE_ID to establish a client ID. If it opts for SP4_MACH_CRED or SP4_SSV protection, in the spo_must_enforce list of operations, it SHOULD at minimum specify CREATE_SESSION, DESTROY_SESSION, BIND_CONN_TO_SESSION, BACKCHANNEL_CTL, and DESTROY_CLIENTID. If it opts for SP4_SSV protection, the client needs to ask for SSV-based RPCSEC_GSS handles.
如果客户端没有客户端ID，客户端将发送EXCHANGE\u ID以建立客户端ID。如果选择SP4\u MACH\u CRED或SP4\u SSV保护，则在spo\u必须\u enforce操作列表中，客户端至少应指定创建\u会话、销毁\u会话、将\u CONN\u绑定到\u会话、反向通道\u CTL和销毁\u CLIENTID。如果选择SP4_SSV保护，客户端需要请求基于SSV的RPCSEC_GSS句柄。
The client uses the client ID to send a CREATE_SESSION on a connection to the server. The results of CREATE_SESSION indicate whether or not the server will persist the session reply cache through a server that has restarted, and the client notes this for future reference.
客户端使用客户端ID在连接上向服务器发送CREATE_会话。CREATE_SESSION的结果指示服务器是否将通过已重新启动的服务器持久化会话应答缓存，并且客户端会记录这一点以供将来参考。
If the client specified SP4_SSV state protection when the client ID was created, then it SHOULD send SET_SSV in the first COMPOUND after the session is created. Each time a new principal goes to use the client ID, it SHOULD send a SET_SSV again.
如果客户端在创建客户端ID时指定了SP4_SSV状态保护，那么它应该在创建会话后在第一个复合中发送SET_SSV。每次新主体使用客户机ID时，它都应该再次发送一个SET_SSV。
If the client wants to use delegations, layouts, directory notifications, or any other state that requires a backchannel, then it needs to add a connection to the backchannel if CREATE_SESSION did not already do so. The client creates a connection, and calls BIND_CONN_TO_SESSION to associate the connection with the session and the session's backchannel. If CREATE_SESSION did not already do so, the client MUST tell the server what security is required in order for the client to accept callbacks. The client does this via BACKCHANNEL_CTL. If the client selected SP4_MACH_CRED or SP4_SSV protection when it called EXCHANGE_ID, then the client SHOULD specify that the backchannel use RPCSEC_GSS contexts for security.
如果客户端希望使用委托、布局、目录通知或任何其他需要反向通道的状态，那么如果CREATE_会话尚未添加到反向通道的连接，则需要添加到反向通道的连接。客户端创建一个连接，并调用BIND_CONN_TO_SESSION将连接与会话和会话的反向通道相关联。如果CREATE_会话尚未执行此操作，则客户端必须告诉服务器需要什么样的安全性，以便客户端接受回调。客户端通过反向通道执行此操作。如果客户端在调用EXCHANGE_ID时选择了SP4_MACH_CRED或SP4_SSV保护，则客户端应指定反向通道使用RPCSEC_GSS上下文进行安全保护。
If the client wants to use additional connections for the backchannel, then it needs to call BIND_CONN_TO_SESSION on each connection it wants to use with the session. If the client wants to use additional connections for the fore channel, then it needs to call BIND_CONN_TO_SESSION if it specified SP4_SSV or SP4_MACH_CRED state protection when the client ID was created.
如果客户机希望为反向通道使用其他连接，则需要在要与会话一起使用的每个连接上调用BIND_CONN_to_SESSION。如果客户端希望为前通道使用其他连接，则需要调用BIND_CONN_to_SESSION（如果在创建客户端ID时指定了SP4_SSV或SP4_MACH_CRED状态保护）。
At this point, the session has reached steady state.
此时，会话已达到稳定状态。
The server MAY maintain a session inactivity timer for each session. If the session inactivity timer expires, then the server MAY destroy the session. To avoid losing a session due to inactivity, the client MUST renew the session inactivity timer. The length of session inactivity timer MUST NOT be less than the lease_time attribute (Section 5.8.1.11). As with lease renewal (Section 8.3), when the server receives a SEQUENCE operation, it resets the session inactivity timer, and MUST NOT allow the timer to expire while the rest of the operations in the COMPOUND procedure's request are still executing. Once the last operation has finished, the server MUST set the session inactivity timer to expire no sooner than the sum of the current time and the value of the lease_time attribute.
服务器可以为每个会话维护会话非活动计时器。如果会话非活动计时器过期，则服务器可能会销毁会话。为了避免由于不活动而丢失会话，客户端必须续订会话不活动计时器。会话非活动计时器的长度不得小于租约时间属性（第5.8.1.11节）。与租约续订（第8.3节）一样，当服务器接收到序列操作时，它会重置会话非活动计时器，并且不得允许计时器在复合过程请求中的其余操作仍在执行时过期。完成最后一个操作后，服务器必须将会话非活动计时器设置为在当前时间和lease_time属性值之和之前过期。
The following events require client action to recover.
以下事件需要客户端操作才能恢复。
If all RPCSEC_GSS handles granted by the client to the server for callback use have expired, the client MUST establish a new handle via BACKCHANNEL_CTL. The sr_status_flags field of the SEQUENCE results indicates when callback handles are nearly expired, or fully expired (see Section 18.46.3).
如果客户端授予服务器以供回调使用的所有RPCSEC_GSS句柄已过期，则客户端必须通过BACKCHANNEL_CTL建立新句柄。序列结果的sr_status_flags字段指示回调句柄接近到期或完全到期的时间（参见第18.46.3节）。
If the client loses the last connection of the session and wants to retain the session, then it needs to create a new connection, and if, when the client ID was created, BIND_CONN_TO_SESSION was specified in the spo_must_enforce list, the client MUST use BIND_CONN_TO_SESSION to associate the connection with the session.
如果客户端丢失会话的最后一个连接并希望保留会话，则需要创建新连接，并且如果在创建客户端ID时，在spo_必须_强制列表中指定了BIND_CONN_to_session，则客户端必须使用BIND_CONN_to_session将连接与会话关联。
If there was a request outstanding at the time of connection loss, then if the client wants to continue to use the session, it MUST retry the request, as described in Section 2.10.6.2. Note that it is not necessary to retry requests over a connection with the same source network address or the same destination network address as the lost connection. As long as the session ID, slot ID, and sequence ID in the retry match that of the original request, the server will recognize the request as a retry if it executed the request prior to disconnect.
如果在连接丢失时有未完成的请求，则如果客户端希望继续使用会话，则必须重试该请求，如第2.10.6.2节所述。请注意，不必通过与丢失的连接具有相同源网络地址或相同目标网络地址的连接重试请求。只要重试中的会话ID、插槽ID和序列ID与原始请求的会话ID、插槽ID和序列ID匹配，服务器将在断开连接之前执行请求时将该请求识别为重试。
If the connection that was lost was the last one associated with the backchannel, and the client wants to retain the backchannel and/or prevent revocation of recallable state, the client needs to reconnect, and if it does, it MUST associate the connection to the session and backchannel via BIND_CONN_TO_SESSION. The server SHOULD indicate when it has no callback connection via the sr_status_flags result from SEQUENCE.
如果丢失的连接是与反向通道关联的最后一个连接，并且客户端希望保留反向通道和/或防止可撤销状态的撤销，则客户端需要重新连接，如果重新连接，则必须通过BIND_CONN_to_session将连接与会话和反向通道关联。服务器应该通过序列的sr_status_标志指示何时没有回调连接。
Via the sr_status_flags result of the SEQUENCE operation or other means, the client will learn if some or all of the RPCSEC_GSS contexts it assigned to the backchannel have been lost. If the client wants to retain the backchannel and/or not put recallable state subject to revocation, the client needs to use BACKCHANNEL_CTL to assign new contexts.
通过序列操作的sr_status_flags结果或其他方式，客户机将了解其分配给反向通道的部分或全部RPCSEC_GSS上下文是否已丢失。如果客户端希望保留反向通道和/或不将可撤销状态置于吊销状态，则客户端需要使用反向通道\u CTL来分配新上下文。
The replier might lose a record of the session. Causes include:
应答器可能会丢失会话的记录。原因包括：
o Replier failure and restart.
o 应答器故障并重新启动。
o A catastrophe that causes the reply cache to be corrupted or lost on the media on which it was stored. This applies even if the replier indicated in the CREATE_SESSION results that it would persist the cache.
o 导致应答缓存在存储介质上损坏或丢失的灾难。即使CREATE_会话中指示的应答器将持久化缓存，这也适用。
o The server purges the session of a client that has been inactive for a very extended period of time.
o 服务器将清除已停用很长时间的客户端会话。
o As a result of configuration changes among a set of clustered servers, a network address previously connected to one server becomes connected to a different server that has no knowledge of the session in question. Such a configuration change will generally only happen when the original server ceases to function for a time.
o 由于一组群集服务器之间的配置更改，以前连接到一台服务器的网络地址将连接到不知道所讨论会话的另一台服务器。这种配置更改通常仅在原始服务器停止运行一段时间后才会发生。
Loss of reply cache is equivalent to loss of session. The replier indicates loss of session to the requester by returning NFS4ERR_BADSESSION on the next operation that uses the session ID that refers to the lost session.
回复缓存的丢失相当于会话的丢失。应答器通过在使用引用丢失会话的会话ID的下一个操作上返回NFS4ERR_BADSESSION，向请求者指示会话丢失。
After an event like a server restart, the client may have lost its connections. The client assumes for the moment that the session has not been lost. It reconnects, and if it specified connection association enforcement when the session was created, it invokes BIND_CONN_TO_SESSION using the session ID. Otherwise, it invokes SEQUENCE. If BIND_CONN_TO_SESSION or SEQUENCE returns NFS4ERR_BADSESSION, the client knows the session is not available to it when communicating with that network address. If the connection survives session loss, then the next SEQUENCE operation the client sends over the connection will get back NFS4ERR_BADSESSION. The client again knows the session was lost.
在服务器重启等事件之后，客户端可能已失去连接。客户端暂时假定会话没有丢失。它会重新连接，如果它在创建会话时指定了连接关联强制，它会使用会话ID调用BIND_CONN_TO_会话。否则，它会调用SEQUENCE。如果BIND_CONN_TO_SESSION或SEQUENCE返回NFS4ERR_BADSESSION，则客户端在与该网络地址通信时知道该会话不可用。如果连接在会话丢失后仍然存在，那么客户端通过连接发送的下一个序列操作将返回NFS4ERR_BADSESSION。客户端再次知道会话已丢失。
Here is one suggested algorithm for the client when it gets NFS4ERR_BADSESSION. It is not obligatory in that, if a client does not want to take advantage of such features as trunking, it may omit parts of it. However, it is a useful example that draws attention to various possible recovery issues:
下面是一个建议的算法，用于客户端获取NFS4ERR_BADSESSION时使用。这不是强制性的，因为如果客户机不想利用中继等功能，它可能会省略其中的一部分。但是，这是一个有用的示例，它提请注意各种可能的恢复问题：
1. If the client has other connections to other server network addresses associated with the same session, attempt a COMPOUND with a single operation, SEQUENCE, on each of the other connections.
1. 如果客户端与与同一会话关联的其他服务器网络地址有其他连接，请在每个其他连接上尝试使用单一操作SEQUENCE进行复合。
2. If the attempts succeed, the session is still alive, and this is a strong indicator that the server's network address has moved. The client might send an EXCHANGE_ID on the connection that returned NFS4ERR_BADSESSION to see if there are opportunities for client ID trunking (i.e., the same client ID and so_major are returned). The client might use DNS to see if the moved network address was replaced with another, so that the performance and availability benefits of session trunking can continue.
2. 如果尝试成功，则会话仍处于活动状态，这是服务器网络地址已移动的有力指示器。客户端可能会在返回NFS4ERR_BADSESSION的连接上发送EXCHANGE_ID，以查看是否有机会进行客户端ID中继（即，返回相同的客户端ID和so_major）。客户端可能会使用DNS来查看移动的网络地址是否被另一个网络地址替换，以便会话中继的性能和可用性优势能够继续。
3. If the SEQUENCE requests fail with NFS4ERR_BADSESSION, then the session no longer exists on any of the server network addresses for which the client has connections associated with that session ID. It is possible the session is still alive and available on other network addresses. The client sends an EXCHANGE_ID on all the connections to see if the server owner is still listening on those network addresses. If the same server owner is returned but a new client ID is returned, this is a strong indicator of a server restart. If both the same server owner and same client ID are returned, then this is a strong indication that the server did delete the session, and the client will need to send a CREATE_SESSION if it has no other sessions for that client ID. If a different server owner is returned, the client can use DNS to find other network addresses. If it does not, or if DNS does not find any other addresses for the server, then the client will be unable to provide NFSv4.1 service, and fatal errors should be returned to processes that were using the server. If the client is using a "mount" paradigm, unmounting the server is advised.
3. 如果序列请求因NFS4ERR_BADSESSION而失败，则该会话将不再存在于客户端与该会话ID关联的任何服务器网络地址上。该会话可能仍处于活动状态，并且在其他网络地址上可用。客户端在所有连接上发送一个EXCHANGE_ID，以查看服务器所有者是否仍在侦听这些网络地址。如果返回了相同的服务器所有者，但返回了新的客户机ID，则这是服务器重新启动的强烈指示。如果返回了相同的服务器所有者和相同的客户端ID，则这强烈表明服务器确实删除了会话，并且如果客户端ID没有其他会话，则客户端需要发送创建会话。如果返回了不同的服务器所有者，则客户端可以使用DNS查找其他网络地址。如果没有，或者DNS没有找到服务器的任何其他地址，则客户端将无法提供NFSv4.1服务，并且应将致命错误返回到使用服务器的进程。如果客户机使用的是“装载”范例，则建议卸载服务器。
4. If the client knows of no other connections associated with the session ID and server network addresses that are, or have been, associated with the session ID, then the client can use DNS to find other network addresses. If it does not, or if DNS does not find any other addresses for the server, then the client will be unable to provide NFSv4.1 service, and fatal errors should be returned to processes that were using the server. If the client is using a "mount" paradigm, unmounting the server is advised.
4. 如果客户端不知道与会话ID关联的其他连接以及与会话ID关联的或已经关联的服务器网络地址，则客户端可以使用DNS查找其他网络地址。如果没有，或者DNS没有找到服务器的任何其他地址，则客户端将无法提供NFSv4.1服务，并且应将致命错误返回到使用服务器的进程。如果客户机使用的是“装载”范例，则建议卸载服务器。
If there is a reconfiguration event that results in the same network address being assigned to servers where the eir_server_scope value is different, it cannot be guaranteed that a session ID generated by the first will be recognized as invalid by the first. Therefore, in managing server reconfigurations among servers with different server scope values, it is necessary to make sure that all clients have disconnected from the first server before effecting the reconfiguration. Nonetheless, clients should not assume that servers will always adhere to this requirement; clients MUST be prepared to deal with unexpected effects of server reconfigurations. Even where a session ID is inappropriately recognized as valid, it is likely
如果重新配置事件导致将相同的网络地址分配给eir_server_作用域值不同的服务器，则无法保证第一个服务器生成的会话ID将被第一个服务器识别为无效。因此，在管理具有不同服务器作用域值的服务器之间的服务器重新配置时，必须确保所有客户端在进行重新配置之前已断开与第一台服务器的连接。尽管如此，客户机不应该认为服务器将始终遵守此要求；客户端必须准备好处理服务器重新配置的意外影响。即使会话ID被不适当地识别为有效，也很可能
either that the connection will not be recognized as valid or that a sequence value for a slot will not be correct. Therefore, when a client receives results indicating such unexpected errors, the use of EXCHANGE_ID to determine the current server configuration is RECOMMENDED.
连接将无法识别为有效连接，或者插槽的序列值将不正确。因此，当客户端收到指示此类意外错误的结果时，建议使用EXCHANGE_ID确定当前服务器配置。
A variation on the above is that after a server's network address moves, there is no NFSv4.1 server listening, e.g., no listener on port 2049. In this example, one of the following occur: the NFSv4 server returns NFS4ERR_MINOR_VERS_MISMATCH, the NFS server returns a PROG_MISMATCH error, the RPC listener on 2049 returns PROG_UNVAIL, or attempts to reconnect to the network address timeout. These SHOULD be treated as equivalent to SEQUENCE returning NFS4ERR_BADSESSION for these purposes.
上面的一个变体是，在服务器的网络地址移动后，没有NFSv4.1服务器侦听，例如，端口2049上没有侦听器。在此示例中，会发生以下情况之一：NFSv4服务器返回NFS4ERR_MINOR_VERS_MISMATCH，NFS服务器返回PROG_MISMATCH错误，2049上的RPC侦听器返回PROG_UNVAIL，或尝试重新连接到网络地址超时。出于这些目的，应将其视为等同于序列返回NFS4ERR_BADSESSION。
When the client detects session loss, it needs to call CREATE_SESSION to recover. Any non-idempotent operations that were in progress might have been performed on the server at the time of session loss. The client has no general way to recover from this.
当客户端检测到会话丢失时，需要调用CREATE_session进行恢复。任何正在进行的非幂等操作都可能在会话丢失时在服务器上执行。客户端没有从中恢复的常规方法。
Note that loss of session does not imply loss of byte-range lock, open, delegation, or layout state because locks, opens, delegations, and layouts are tied to the client ID and depend on the client ID, not the session. Nor does loss of byte-range lock, open, delegation, or layout state imply loss of session state, because the session depends on the client ID; loss of client ID however does imply loss of session, byte-range lock, open, delegation, and layout state. See Section 8.4.2. A session can survive a server restart, but lock recovery may still be needed.
请注意，丢失会话并不意味着丢失字节范围锁定、打开、委派或布局状态，因为锁定、打开、委派和布局与客户端ID有关，并且取决于客户端ID，而不是会话。字节范围锁定、打开、委派或布局状态的丢失也不意味着会话状态的丢失，因为会话取决于客户端ID；然而，丢失客户端ID并不意味着丢失会话、字节范围锁、打开、委托和布局状态。见第8.4.2节。会话可以在服务器重新启动后继续运行，但仍可能需要锁恢复。
It is possible that CREATE_SESSION will fail with NFS4ERR_STALE_CLIENTID (e.g., the server restarts and does not preserve client ID state). If so, the client needs to call EXCHANGE_ID, followed by CREATE_SESSION.
CREATE_会话可能会因NFS4ERR_STALE_CLIENTID而失败（例如，服务器重新启动，不保留客户端ID状态）。如果是这样，客户端需要调用EXCHANGE\u ID，然后调用CREATE\u会话。
The following events require server action to recover.
以下事件需要服务器操作才能恢复。
As described in Section 18.35, a restarted client sends EXCHANGE_ID in such a way that it causes the server to delete any sessions it had.
如第18.35节所述，重新启动的客户端发送EXCHANGE_ID的方式会导致服务器删除其拥有的任何会话。
If a client crashes and never comes back, it will never send EXCHANGE_ID with its old client owner. Thus, the server has session state that will never be used again. After an extended period of time, and if the server has resource constraints, it MAY destroy the old session as well as locking state.
如果客户机崩溃并且再也没有回来，它将永远不会向其旧客户机所有者发送EXCHANGE\u ID。因此，服务器的会话状态将不再使用。经过一段较长的时间后，如果服务器有资源限制，它可能会破坏旧会话以及锁定状态。
To the server, the extended network partition may be no different from a client crash with no restart (see Section 2.10.13.2.2). Unless the server can discern that there is a network partition, it is free to treat the situation as if the client has crashed permanently.
对于服务器而言，扩展网络分区可能与无需重新启动的客户端崩溃无异（请参阅第2.10.13.2.2节）。除非服务器能够识别出存在网络分区，否则它可以自由地将这种情况视为客户端永久崩溃。
If there were callback requests outstanding at the time of a connection loss, then the server MUST retry the requests, as described in Section 2.10.6.2. Note that it is not necessary to retry requests over a connection with the same source network address or the same destination network address as the lost connection. As long as the session ID, slot ID, and sequence ID in the retry match that of the original request, the callback target will recognize the request as a retry even if it did see the request prior to disconnect.
如果在连接丢失时有未完成的回调请求，则服务器必须重试这些请求，如第2.10.6.2节所述。请注意，不必通过与丢失的连接具有相同源网络地址或相同目标网络地址的连接重试请求。只要重试中的会话ID、插槽ID和序列ID与原始请求的会话ID、插槽ID和序列ID匹配，回调目标就会将该请求识别为重试，即使它在断开连接之前确实看到了该请求。
If the connection lost is the last one associated with the backchannel, then the server MUST indicate that in the sr_status_flags field of every SEQUENCE reply until the backchannel is re-established. There are two situations, each of which uses different status flags: no connectivity for the session's backchannel and no connectivity for any session backchannel of the client. See Section 18.46 for a description of the appropriate flags in sr_status_flags.
如果连接丢失是与反向通道关联的最后一个连接，则服务器必须在每个序列应答的sr_status_flags字段中指示，直到反向通道重新建立。有两种情况，每种情况都使用不同的状态标志：会话的反向通道没有连接，客户端的任何会话反向通道都没有连接。有关sr_状态_标志中相应标志的说明，请参见第18.46节。
The server SHOULD monitor when the number of RPCSEC_GSS handles assigned to the backchannel reaches one, and when that one handle is near expiry (i.e., between one and two periods of lease time), and indicate so in the sr_status_flags field of all SEQUENCE replies. The server MUST indicate when all of the backchannel's assigned RPCSEC_GSS handles have expired via the sr_status_flags field of all SEQUENCE replies.
服务器应监控分配给反向通道的RPCSEC_GSS句柄数何时达到一个，以及该句柄何时接近到期（即，在一到两个租赁时间段之间），并在所有序列应答的sr_status_flags字段中指示。服务器必须通过所有序列应答的sr_status_flags字段指示所有分配的反向通道RPCSEC_GSS句柄何时过期。
A client and server can potentially be a non-pNFS implementation, a metadata server implementation, a data server implementation, or two or three types of implementations. The EXCHGID4_FLAG_USE_NON_PNFS, EXCHGID4_FLAG_USE_PNFS_MDS, and EXCHGID4_FLAG_USE_PNFS_DS flags (not mutually exclusive) are passed in the EXCHANGE_ID arguments and results to allow the client to indicate how it wants to use sessions created under the client ID, and to allow the server to indicate how it will allow the sessions to be used. See Section 13.1 for pNFS sessions considerations.
客户机和服务器可能是非pNFS实现、元数据服务器实现、数据服务器实现或两种或三种类型的实现。EXCHGID4_标志_USE_NON_PNFS、EXCHGID4_标志_USE_PNFS_MDS和EXCHGID4_标志_USE_PNFS_DS标志（不互斥）在EXCHANGE_ID参数和结果中传递，以允许客户端指示如何使用在客户端ID下创建的会话，并允许服务器指示如何使用会话。有关pNFS会话注意事项，请参见第13.1节。
The syntax and semantics to describe the data types of the NFSv4.1 protocol are defined in the XDR RFC 4506 [2] and RPC RFC 5531 [3] documents. The next sections build upon the XDR data types to define constants, types, and structures specific to this protocol. The full list of XDR data types is in [13].
XDR RFC 4506[2]和RPC RFC 5531[3]文档中定义了用于描述NFSv4.1协议数据类型的语法和语义。下一节将基于XDR数据类型来定义特定于此协议的常量、类型和结构。XDR数据类型的完整列表见[13]。
const NFS4_FHSIZE = 128;
const NFS4_VERIFIER_SIZE = 8;
const NFS4_OPAQUE_LIMIT = 1024;
const NFS4_SESSIONID_SIZE = 16;
const NFS4_FHSIZE = 128;
const NFS4_VERIFIER_SIZE = 8;
const NFS4_OPAQUE_LIMIT = 1024;
const NFS4_SESSIONID_SIZE = 16;
const NFS4_INT64_MAX = 0x7fffffffffffffff;
const NFS4_UINT64_MAX = 0xffffffffffffffff;
const NFS4_INT32_MAX = 0x7fffffff;
const NFS4_UINT32_MAX = 0xffffffff;
const NFS4_INT64_MAX = 0x7fffffffffffffff;
const NFS4_UINT64_MAX = 0xffffffffffffffff;
const NFS4_INT32_MAX = 0x7fffffff;
const NFS4_UINT32_MAX = 0xffffffff;
const NFS4_MAXFILELEN = 0xffffffffffffffff;
const NFS4_MAXFILEOFF = 0xfffffffffffffffe;
const NFS4_MAXFILELEN = 0xffffffffffffffff;
const NFS4_MAXFILEOFF = 0xfffffffffffffffe;
Except where noted, all these constants are defined in bytes.
除非另有说明，所有这些常量都是以字节定义的。
o NFS4_FHSIZE is the maximum size of a filehandle.
o NFS4_FHSIZE是文件句柄的最大大小。
o NFS4_VERIFIER_SIZE is the fixed size of a verifier.
o NFS4\u验证器\u大小是验证器的固定大小。
o NFS4_OPAQUE_LIMIT is the maximum size of certain opaque information.
o NFS4_不透明限制是某些不透明信息的最大大小。
o NFS4_SESSIONID_SIZE is the fixed size of a session identifier.
o NFS4_SESSIONID_SIZE是会话标识符的固定大小。
o NFS4_INT64_MAX is the maximum value of a signed 64-bit integer.
o NFS4_INT64_MAX是有符号64位整数的最大值。
o NFS4_UINT64_MAX is the maximum value of an unsigned 64-bit integer.
o NFS4_UINT64_MAX是无符号64位整数的最大值。
o NFS4_INT32_MAX is the maximum value of a signed 32-bit integer.
o NFS4_INT32_MAX是有符号32位整数的最大值。
o NFS4_UINT32_MAX is the maximum value of an unsigned 32-bit integer.
o NFS4_UINT32_MAX是无符号32位整数的最大值。
o NFS4_MAXFILELEN is the maximum length of a regular file.
o NFS4_MAXFILELEN是常规文件的最大长度。
o NFS4_MAXFILEOFF is the maximum offset into a regular file.
o NFS4_MAXFILEOFF是常规文件的最大偏移量。
These are the base NFSv4.1 data types.
这些是基本的NFSv4.1数据类型。
+---------------+---------------------------------------------------+
| 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; |
| | The length of a byte-range within a file. |
| 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. |
| offset4 | typedef uint64_t offset4; |
| | Various offset designations (READ, WRITE, LOCK, |
| | COMMIT). |
+---------------+---------------------------------------------------+
| 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; |
| | The length of a byte-range within a file. |
| 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. |
| 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 [7] for details. |
| sequenceid4 | typedef uint32_t sequenceid4; |
| | Sequence number used for various session |
| | operations (EXCHANGE_ID, CREATE_SESSION, |
| | SEQUENCE, CB_SEQUENCE). |
| seqid4 | typedef uint32_t seqid4; |
| | Sequence identifier used for locking. |
| sessionid4 | typedef opaque sessionid4[NFS4_SESSIONID_SIZE]; |
| | Session identifier. |
| slotid4 | typedef uint32_t slotid4; |
| | Sequencing artifact for various session |
| | operations (SEQUENCE, CB_SEQUENCE). |
| utf8string | typedef opaque utf8string<>; |
| | UTF-8 encoding for strings. |
| utf8str_cis | typedef utf8string utf8str_cis; |
| | Case-insensitive UTF-8 string. |
| utf8str_cs | typedef utf8string utf8str_cs; |
| | Case-sensitive UTF-8 string. |
| utf8str_mixed | typedef utf8string utf8str_mixed; |
| | UTF-8 strings with a case-sensitive prefix and a |
| | case-insensitive suffix. |
| component4 | typedef utf8str_cs component4; |
| | Represents pathname components. |
| linktext4 | typedef utf8str_cs linktext4; |
| | Symbolic link contents ("symbolic link" is |
| | defined in an Open Group [14] standard). |
| pathname4 | typedef component4 pathname4<>; |
| | Represents pathname for fs_locations. |
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; |
| | Verifier used for various operations (COMMIT, |
| | CREATE, EXCHANGE_ID, OPEN, READDIR, WRITE) |
| | NFS4_VERIFIER_SIZE is defined as 8. |
+---------------+---------------------------------------------------+
| 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 [7] for details. |
| sequenceid4 | typedef uint32_t sequenceid4; |
| | Sequence number used for various session |
| | operations (EXCHANGE_ID, CREATE_SESSION, |
| | SEQUENCE, CB_SEQUENCE). |
| seqid4 | typedef uint32_t seqid4; |
| | Sequence identifier used for locking. |
| sessionid4 | typedef opaque sessionid4[NFS4_SESSIONID_SIZE]; |
| | Session identifier. |
| slotid4 | typedef uint32_t slotid4; |
| | Sequencing artifact for various session |
| | operations (SEQUENCE, CB_SEQUENCE). |
| utf8string | typedef opaque utf8string<>; |
| | UTF-8 encoding for strings. |
| utf8str_cis | typedef utf8string utf8str_cis; |
| | Case-insensitive UTF-8 string. |
| utf8str_cs | typedef utf8string utf8str_cs; |
| | Case-sensitive UTF-8 string. |
| utf8str_mixed | typedef utf8string utf8str_mixed; |
| | UTF-8 strings with a case-sensitive prefix and a |
| | case-insensitive suffix. |
| component4 | typedef utf8str_cs component4; |
| | Represents pathname components. |
| linktext4 | typedef utf8str_cs linktext4; |
| | Symbolic link contents ("symbolic link" is |
| | defined in an Open Group [14] standard). |
| pathname4 | typedef component4 pathname4<>; |
| | Represents pathname for fs_locations. |
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; |
| | Verifier used for various operations (COMMIT, |
| | CREATE, EXCHANGE_ID, OPEN, READDIR, WRITE) |
| | NFS4_VERIFIER_SIZE is defined as 8. |
+---------------+---------------------------------------------------+
End of Base Data Types
基本数据类型结束
Table 1
表1
struct nfstime4 {
int64_t seconds;
uint32_t nseconds;
};
struct nfstime4 {
int64_t seconds;
uint32_t nseconds;
};
The nfstime4 data type gives the number of seconds and nanoseconds since midnight or zero hour January 1, 1970 Coordinated Universal Time (UTC). Values greater than zero for the seconds field denote dates after the zero hour January 1, 1970. Values less than zero for the seconds field denote dates before the zero 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 zero hour January 1, 1970, the seconds field would have a value of negative one (-1) and the nseconds field would have a value of one-half second (500000000). Values greater than 999,999,999 for nseconds are invalid.
nfstime4数据类型给出自1970年1月1日协调世界时（UTC）午夜或零小时以来的秒数和纳秒数。秒字段大于零的值表示1970年1月1日零小时之后的日期。秒字段小于零的值表示1970年1月1日零小时之前的日期。在这两种情况下，N秒字段将添加到秒字段中，作为最终时间表示。例如，如果要表示的时间是1970年1月1日零时之前的半秒，则秒字段的值为负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 time_how4 and settime4 data types are used for setting timestamps in file object attributes. If set_it is SET_TO_SERVER_TIME4, then the server uses its local representation of time for the time value.
time_how4和settime4数据类型用于在文件对象属性中设置时间戳。如果将其设置为服务器时间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 the device numbers 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;
};
struct change_policy4 {
uint64_t cp_major;
uint64_t cp_minor;
};
struct change_policy4 {
uint64_t cp_major;
uint64_t cp_minor;
};
The change_policy4 data type is used for the change_policy RECOMMENDED attribute. It provides change sequencing indication analogous to the change attribute. To enable the server to present a value valid across server re-initialization without requiring persistent storage, two 64-bit quantities are used, allowing one to be a server instance ID and the second to be incremented non-persistently, within a given server instance.
change_policy4数据类型用于change_policy RECOMMENDED属性。它提供类似于更改属性的更改顺序指示。为了使服务器能够在不需要持久存储的情况下在服务器重新初始化期间提供有效的值，使用了两个64位量，允许一个是服务器实例ID，另一个在给定的服务器实例中非持久地递增。
struct fattr4 {
bitmap4 attrmask;
attrlist4 attr_vals;
};
struct fattr4 {
bitmap4 attrmask;
attrlist4 attr_vals;
};
The fattr4 data type 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 data type is used with the CREATE, LINK, OPEN, 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.
此数据类型与创建、链接、打开、删除和重命名操作一起使用，以让客户端知道目标文件系统对象所在目录的更改属性的值。
struct netaddr4 {
/* see struct rpcb in RFC 1833 */
string na_r_netid<>; /* network id */
string na_r_addr<>; /* universal address */
};
struct netaddr4 {
/* see struct rpcb in RFC 1833 */
string na_r_netid<>; /* network id */
string na_r_addr<>; /* universal address */
};
The netaddr4 data type is used to identify network transport endpoints. The r_netid and r_addr fields respectively contain a netid and uaddr. The netid and uaddr concepts are defined in [15]. The netid and uaddr formats for TCP over IPv4 and TCP over IPv6 are defined in [15], specifically Tables 2 and 3 and Sections 5.2.3.3 and 5.2.3.4.
NetAddress4数据类型用于标识网络传输端点。r_netid和r_addr字段分别包含netid和uaddr。netid和uaddr概念定义见[15]。[15]中定义了IPv4上TCP和IPv6上TCP的netid和uaddr格式，特别是表2和表3以及第5.2.3.3和5.2.3.4节。
struct state_owner4 {
clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>;
};
struct state_owner4 {
clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>;
};
typedef state_owner4 open_owner4;
typedef state_owner4 lock_owner4;
typedef state_owner4 open_owner4;
typedef state_owner4 lock_owner4;
The state_owner4 data type is the base type for the open_owner4 (Section 3.3.10.1) and lock_owner4 (Section 3.3.10.2).
state_owner4数据类型是open_owner4（第3.3.10.1节）和lock_owner4（第3.3.10.2节）的基本类型。
This data type is used to identify the owner of OPEN state.
此数据类型用于标识打开状态的所有者。
This structure is used to identify the owner of byte-range 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 data type 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[12];
};
struct stateid4 {
uint32_t seqid;
opaque other[12];
};
This data type is used for the various state sharing mechanisms between the client and server. The client never modifies a value of data type stateid. The starting value of the "seqid" field is undefined. The server is required to increment the "seqid" field by one 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”字段的起始值未定义。服务器需要在stateid的每次转换中将“seqid”字段增加1。这一点很重要，因为客户端将检查OPEN StateID中的seqid，以确定服务器完成的打开处理顺序。
enum layouttype4 {
LAYOUT4_NFSV4_1_FILES = 0x1,
LAYOUT4_OSD2_OBJECTS = 0x2,
LAYOUT4_BLOCK_VOLUME = 0x3
};
enum layouttype4 {
LAYOUT4_NFSV4_1_FILES = 0x1,
LAYOUT4_OSD2_OBJECTS = 0x2,
LAYOUT4_BLOCK_VOLUME = 0x3
};
This data type indicates what type of layout is being used. The file server advertises the layout types it supports through the fs_layout_type file system attribute (Section 5.12.1). A client asks for layouts of a particular type in LAYOUTGET, and processes those layouts in its layout-type-specific logic.
此数据类型指示正在使用的布局类型。文件服务器通过fs_layout_type文件系统属性（第5.12.1节）公布其支持的布局类型。客户机在LAYOUTGET中请求特定类型的布局，并在其布局类型特定的逻辑中处理这些布局。
The layouttype4 data type is 32 bits in length. The range represented by the layout type is split into three parts. Type 0x0 is reserved. Types within the range 0x00000001-0x7FFFFFFF are globally unique and are assigned according to the description in Section 22.4; they are maintained by IANA. Types within the range 0x80000000-0xFFFFFFFF are site specific and for private use only.
layouttype4数据类型的长度为32位。布局类型表示的范围分为三部分。类型0x0是保留的。0x00000001-0x7FFFFFFF范围内的类型是全局唯一的，并根据第22.4节中的描述进行分配；它们由IANA维护。0x8000000-0xFFFFFF范围内的类型是特定于站点的，仅供私人使用。
The LAYOUT4_NFSV4_1_FILES enumeration specifies that the NFSv4.1 file layout type, as defined in Section 13, is to be used. The LAYOUT4_OSD2_OBJECTS enumeration specifies that the object layout, as defined in [40], is to be used. Similarly, the LAYOUT4_BLOCK_VOLUME enumeration specifies that the block/volume layout, as defined in [41], is to be used.
LAYOUT4_NFSV4_1_文件枚举指定使用第13节中定义的NFSV4.1文件布局类型。LAYOUT4_OSD2_对象枚举指定要使用[40]中定义的对象布局。类似地，LAYOUT4\u BLOCK\u VOLUME枚举指定使用[41]中定义的块/卷布局。
const NFS4_DEVICEID4_SIZE = 16;
常数NFS4_设备4_尺寸=16；
typedef opaque deviceid4[NFS4_DEVICEID4_SIZE];
typedef不透明设备4[NFS4_设备4_尺寸]；
Layout information includes device IDs that specify a storage device through a compact handle. Addressing and type information is obtained with the GETDEVICEINFO operation. Device IDs are not guaranteed to be valid across metadata server restarts. A device ID is unique per client ID and layout type. See Section 12.2.10 for more details.
布局信息包括通过紧凑句柄指定存储设备的设备ID。通过GETDEVICEINFO操作获得寻址和类型信息。不能保证设备ID在元数据服务器重新启动时有效。每个客户端ID和布局类型的设备ID都是唯一的。详见第12.2.10节。
struct device_addr4 {
layouttype4 da_layout_type;
opaque da_addr_body<>;
};
struct device_addr4 {
layouttype4 da_layout_type;
opaque da_addr_body<>;
};
The device address is used to set up a communication channel with the storage device. Different layout types will require different data types to define how they communicate with storage devices. The opaque da_addr_body field is interpreted based on the specified da_layout_type field.
设备地址用于设置与存储设备的通信通道。不同的布局类型将需要不同的数据类型来定义它们与存储设备的通信方式。不透明的da_addr_body字段将基于指定的da_layout_type字段进行解释。
This document defines the device address for the NFSv4.1 file layout (see Section 13.3), which identifies a storage device by network IP address and port number. This is sufficient for the clients to communicate with the NFSv4.1 storage devices, and may be sufficient for other layout types as well. Device types for object-based storage devices and block storage devices (e.g., Small Computer System Interface (SCSI) volume labels) are defined by their respective layout specifications.
本文档定义了NFSv4.1文件布局的设备地址（见第13.3节），该文件通过网络IP地址和端口号标识存储设备。这对于客户端与NFSv4.1存储设备进行通信已经足够了，对于其他布局类型也可能足够了。基于对象的存储设备和块存储设备（例如小型计算机系统接口（SCSI）卷标签）的设备类型由其各自的布局规范定义。
struct layout_content4 {
layouttype4 loc_type;
opaque loc_body<>;
};
struct layout_content4 {
layouttype4 loc_type;
opaque loc_body<>;
};
The loc_body field is interpreted based on the layout type (loc_type). This document defines the loc_body for the NFSv4.1 file layout type; see Section 13.3 for its definition.
loc_主体字段根据布局类型（loc_类型）进行解释。本文件定义了NFSv4.1文件布局类型的loc_主体；其定义见第13.3节。
struct layout4 {
offset4 lo_offset;
length4 lo_length;
layoutiomode4 lo_iomode;
layout_content4 lo_content;
};
struct layout4 {
offset4 lo_offset;
length4 lo_length;
layoutiomode4 lo_iomode;
layout_content4 lo_content;
};
The layout4 data type defines a layout for a file. The layout type specific data is opaque within lo_content. Since layouts are sub-dividable, the offset and length together with the file's filehandle, the client ID, iomode, and layout type identify the layout.
layout4数据类型定义文件的布局。布局类型特定的数据在lo_内容中不透明。由于布局是可分的，因此偏移量和长度以及文件的文件句柄、客户端ID、iomode和布局类型将标识布局。
struct layoutupdate4 {
layouttype4 lou_type;
opaque lou_body<>;
};
struct layoutupdate4 {
layouttype4 lou_type;
opaque lou_body<>;
};
The layoutupdate4 data type is used by the client to return updated layout information to the metadata server via the LAYOUTCOMMIT (Section 18.42) operation. This data type provides a channel to pass layout type specific information (in field lou_body) back to the metadata server. For example, for the block/volume layout type, this could include the list of reserved blocks that were written. The contents of the opaque lou_body argument are determined by the layout
客户端使用layoutupdate4数据类型通过LAYOUTCOMMIT（第18.42节）操作将更新的布局信息返回给元数据服务器。此数据类型提供了一个将布局类型特定信息（在字段lou_body中）传递回元数据服务器的通道。例如，对于块/卷布局类型，这可能包括已写入的保留块的列表。不透明lou_body参数的内容由布局决定
type. The NFSv4.1 file-based layout does not use this data type; if lou_type is LAYOUT4_NFSV4_1_FILES, the lou_body field MUST have a zero length.
类型基于NFSv4.1文件的布局不使用此数据类型；如果lou_类型为LAYOUT4_NFSV4_1_文件，则lou_正文字段的长度必须为零。
struct layouthint4 {
layouttype4 loh_type;
opaque loh_body<>;
};
struct layouthint4 {
layouttype4 loh_type;
opaque loh_body<>;
};
The layouthint4 data type is used by the client to pass in a hint about the type of layout it would like created for a particular file. It is the data type specified by the layout_hint attribute described in Section 5.12.4. The metadata server may ignore the hint or may selectively ignore fields within the hint. This hint should be provided at create time as part of the initial attributes within OPEN. The loh_body field is specific to the type of layout (loh_type). The NFSv4.1 file-based layout uses the nfsv4_1_file_layouthint4 data type as defined in Section 13.3.
layouthint4数据类型由客户机用于传递有关它希望为特定文件创建的布局类型的提示。第5.12.4节中描述的布局提示属性指定的数据类型。元数据服务器可以忽略提示，也可以选择性地忽略提示中的字段。这个提示应该在创建时作为OPEN中初始属性的一部分提供。loh_body字段特定于布局类型（loh_类型）。基于NFSv4.1文件的布局使用第13.3节中定义的NFSv4_1_文件_LayoutInt4数据类型。
enum layoutiomode4 {
LAYOUTIOMODE4_READ = 1,
LAYOUTIOMODE4_RW = 2,
LAYOUTIOMODE4_ANY = 3
};
enum layoutiomode4 {
LAYOUTIOMODE4_READ = 1,
LAYOUTIOMODE4_RW = 2,
LAYOUTIOMODE4_ANY = 3
};
The iomode specifies whether the client intends to just read or both read and write the data represented by the layout. While the LAYOUTIOMODE4_ANY iomode MUST NOT be used in the arguments to the LAYOUTGET operation, it MAY be used in the arguments to the LAYOUTRETURN and CB_LAYOUTRECALL operations. The LAYOUTIOMODE4_ANY iomode specifies that layouts pertaining to both LAYOUTIOMODE4_READ and LAYOUTIOMODE4_RW iomodes are being returned or recalled, respectively. The metadata server's use of the iomode may depend on the layout type being used. The storage devices MAY validate I/O accesses against the iomode and reject invalid accesses.
iomode指定客户端是只读取还是同时读取和写入布局所表示的数据。虽然LAYOUTIOMODE4_ANY iomode不能用于LAYOUTGET操作的参数中，但它可以用于LAYOUTRETURN和CB_LAYOUTRECALL操作的参数中。LAYOUTIOMODE4_ANY iomode指定分别返回或调用与LAYOUTIOMODE4_READ和LAYOUTIOMODE4_RW iomode相关的布局。元数据服务器对iomode的使用可能取决于所使用的布局类型。存储设备可以根据iomode验证I/O访问，并拒绝无效访问。
struct nfs_impl_id4 {
utf8str_cis nii_domain;
utf8str_cs nii_name;
nfstime4 nii_date;
};
struct nfs_impl_id4 {
utf8str_cis nii_domain;
utf8str_cs nii_name;
nfstime4 nii_date;
};
This data type is used to identify client and server implementation details. The nii_domain field is the DNS domain name with which the implementor is associated. The nii_name field is the product name of the implementation and is completely free form. It is RECOMMENDED that the nii_name be used to distinguish machine architecture, machine platforms, revisions, versions, and patch levels. The nii_date field is the timestamp of when the software instance was published or built.
此数据类型用于标识客户端和服务器实现详细信息。nii_域字段是与实现者关联的DNS域名。nii_名称字段是实现的产品名称，是完全自由的形式。建议使用nii_名称来区分机器体系结构、机器平台、版本、版本和修补程序级别。nii_日期字段是发布或构建软件实例的时间戳。
struct threshold_item4 {
layouttype4 thi_layout_type;
bitmap4 thi_hintset;
opaque thi_hintlist<>;
};
struct threshold_item4 {
layouttype4 thi_layout_type;
bitmap4 thi_hintset;
opaque thi_hintlist<>;
};
This data type contains a list of hints specific to a layout type for helping the client determine when it should send I/O directly through the metadata server versus the storage devices. The data type consists of the layout type (thi_layout_type), a bitmap (thi_hintset) describing the set of hints supported by the server (they may differ based on the layout type), and a list of hints (thi_hintlist) whose content is determined by the hintset bitmap. See the mdsthreshold attribute for more details.
此数据类型包含特定于布局类型的提示列表，用于帮助客户端确定何时应直接通过元数据服务器而不是存储设备发送I/O。数据类型包括布局类型（thi_layout_类型）、描述服务器支持的提示集的位图（thi_hintset）（它们可能因布局类型而异）和提示列表（thi_hintlist），其内容由hintset位图确定。有关详细信息，请参见mdsthreshold属性。
The thi_hintset field is a bitmap of the following values:
thi_hintset字段是具有以下值的位图：
+-------------------------+---+---------+---------------------------+
| name | # | Data | Description |
| | | Type | |
+-------------------------+---+---------+---------------------------+
| threshold4_read_size | 0 | length4 | If a file's length is |
| | | | less than the value of |
| | | | threshold4_read_size, |
| | | | then it is RECOMMENDED |
| | | | that the client read from |
| | | | the file via the MDS and |
| | | | not a storage device. |
| threshold4_write_size | 1 | length4 | If a file's length is |
| | | | less than the value of |
| | | | threshold4_write_size, |
| | | | then it is RECOMMENDED |
| | | | that the client write to |
| | | | the file via the MDS and |
| | | | not a storage device. |
| threshold4_read_iosize | 2 | length4 | For read I/O sizes below |
| | | | this threshold, it is |
| | | | RECOMMENDED to read data |
| | | | through the MDS. |
| threshold4_write_iosize | 3 | length4 | For write I/O sizes below |
| | | | this threshold, it is |
| | | | RECOMMENDED to write data |
| | | | through the MDS. |
+-------------------------+---+---------+---------------------------+
+-------------------------+---+---------+---------------------------+
| name | # | Data | Description |
| | | Type | |
+-------------------------+---+---------+---------------------------+
| threshold4_read_size | 0 | length4 | If a file's length is |
| | | | less than the value of |
| | | | threshold4_read_size, |
| | | | then it is RECOMMENDED |
| | | | that the client read from |
| | | | the file via the MDS and |
| | | | not a storage device. |
| threshold4_write_size | 1 | length4 | If a file's length is |
| | | | less than the value of |
| | | | threshold4_write_size, |
| | | | then it is RECOMMENDED |
| | | | that the client write to |
| | | | the file via the MDS and |
| | | | not a storage device. |
| threshold4_read_iosize | 2 | length4 | For read I/O sizes below |
| | | | this threshold, it is |
| | | | RECOMMENDED to read data |
| | | | through the MDS. |
| threshold4_write_iosize | 3 | length4 | For write I/O sizes below |
| | | | this threshold, it is |
| | | | RECOMMENDED to write data |
| | | | through the MDS. |
+-------------------------+---+---------+---------------------------+
struct mdsthreshold4 {
threshold_item4 mth_hints<>;
};
struct mdsthreshold4 {
threshold_item4 mth_hints<>;
};
This data type holds an array of elements of data type threshold_item4, each of which is valid for a particular layout type. An array is necessary because a server can support multiple layout types for a single file.
此数据类型保存数据类型threshold_item4的元素数组，每个元素对特定布局类型有效。阵列是必需的，因为服务器可以为单个文件支持多种布局类型。
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 NFSv3 protocol (RFC 1813 [31]), 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, which can then be used by the NFS protocols.
NFS协议的操作是根据一个或多个文件句柄定义的。因此，客户端需要一个文件句柄来启动与服务器的通信。对于NFSv3协议（RFC1813[31]），存在一个辅助协议来获取第一个文件句柄。装载协议（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 RFC 2054 [42] and RFC 2055 [43]. With the use of the public filehandle in combination with the LOOKUP operation in the NFSv3 protocol, it has been demonstrated that the MOUNT protocol is unnecessary for viable interaction between NFS client and server.
MOUNT协议在安全性和通过防火墙使用方面存在缺陷。这是在RFC 2054[42]和RFC 2055[43]中引入公共文件句柄的原因之一。通过将公共文件句柄与NFSv3协议中的查找操作结合使用，已经证明对于NFS客户端和服务器之间的可行交互来说，装载协议是不必要的。
Therefore, the NFSv4.1 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.1协议不会使用辅助协议将基于字符串的路径名转换为文件句柄。两个特殊的文件句柄将用作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 NFSv3 protocol, there was one type of filehandle with a single set of semantics. This type of filehandle is termed "persistent" in NFSv4.1. The semantics of a persistent filehandle remain the same as before. A new type of filehandle introduced in NFSv4.1 is the "volatile" filehandle, which attempts to accommodate certain server environments.
在NFSv3协议中，有一种文件句柄类型，只有一组语义。这种类型的文件句柄在NFSv4.1中称为“持久”。持久化文件句柄的语义与以前相同。NFSv4.1中引入的一种新型文件句柄是“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 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.
引入volatile filehandle类型是为了解决使持久化filehandle的正确实现不可行的服务器功能或实现问题。某些服务器环境不提供可用于构造持久化文件句柄的文件系统级不变量。底层服务器文件系统可能不提供不变量，或者服务器的文件系统编程接口可能不提供对所需不变量的访问。易失性文件句柄可以简化服务器功能的实现，如分层存储管理或文件系统重组或迁移。但是，易失性文件句柄增加了客户端的实现负担。
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. Servers SHOULD try to maintain a one-to-one correspondence between filehandles and files, but this is not required. 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 filehandles denote the same object and in such cases, avoid making invalid assumptions that 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
例如，如果在服务器上遍历两个不同的路径名时终止于同一文件系统对象，则服务器应为每个路径返回相同的filehandle。这个可以
occur if a hard link (see [6]) is used to create two file names 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 pathnames' traversals.
如果使用硬链接（请参见[6]）创建两个引用相同基础文件对象和关联数据的文件名，则会发生此错误。例如，如果路径/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 the object. If the server restarts, 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.
持久化文件句柄定义为在其引用的文件系统对象的生存期内具有固定值。一旦服务器为文件系统对象创建了filehandle，服务器就必须在对象的生存期内为该对象接受相同的filehandle。如果服务器重新启动，NFS服务器必须使用与服务器上一次实例化相同的filehandle值。类似地，如果文件系统被迁移，新的NFS服务器必须与旧的NFS服务器使用相同的文件句柄。
The persistent filehandle will be 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 the file system in whole has been destroyed or 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_NO_EXPIRE_WITH_OPEN).
FH4\u VOLATILE\u任何文件句柄可能随时过期，除非明确排除（即FH4\u NO\u expire\u与\u OPEN）。
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\u VOLATILE\u ANY时，才能设置FH4\u NOEXPIRE\u WITH\u OPEN。如果设置了该位，则FH4_VOLATILE_ANY的含义有资格排除文件句柄打开时的任何过期。
FH4_VOL_MIGRATION The filehandle will expire as a result of a file system transition (migration or replication), in those cases in which the continuity of filehandle use is not specified by handle class information within the fs_locations_info attribute. When this bit is set, clients without access to fs_locations_info information should assume that filehandles will expire on file system transitions.
FH4_VOL_迁移文件句柄将因文件系统转换（迁移或复制）而过期，在这种情况下，文件句柄使用的连续性不是由fs_locations_info属性中的句柄类信息指定的。设置此位后，无法访问fs\u位置\u信息的客户端应假定文件句柄将在文件系统转换时过期。
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_VOL_ANY is set, FH4_VOL_RENAME is redundant.
FH4_VOL_RENAME文件句柄将在重命名期间过期。这包括请求客户端的重命名或任何其他客户端的重命名。如果设置了FH4_VOL_ANY，则FH4_VOL_RENAME是冗余的。
Servers that provide volatile filehandles that can expire while open require special care as regards handling of RENAMEs and REMOVEs. This situation can arise if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set, if FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN is not set, or if a non-read-only file system has a transition target in a different handle class. In these cases, the server 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, in order to make sure that reclaims of files where filehandles may have expired do not do a reclaim for the wrong file.
提供易失性文件句柄（打开时可能过期）的服务器需要特别注意重命名和删除的处理。如果设置了FH4_VOL_MIGRATION或FH4_VOL_RENAME，如果设置了FH4_VOLATILE_ANY且未设置FH4_NOEXPIRE_WITH_OPEN，或者如果非只读文件系统在不同的句柄类中具有转换目标，则会出现这种情况。在这些情况下，服务器应拒绝重命名或删除会影响导致打开文件的任何组件的打开文件的重命名或删除。此外，服务器应在宽限期内拒绝所有重命名或删除请求，以确保回收文件句柄可能已过期的文件时不会回收错误的文件。
Volatile filehandles are especially suitable for implementation of the pseudo file systems used to bridge exports. See Section 7.5 for a discussion of this.
Volatile文件句柄特别适合于用于桥接导出的伪文件系统的实现。有关这方面的讨论，请参见第7.5节。
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 restarts, 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 procedure to construct a series 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 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.1 protocol, the client is able to query what attributes the server supports and construct requests with only those supported attributes (or a subset thereof).
为了满足可扩展性和与非UNIX平台增强的互操作性的要求，需要以灵活的方式处理属性。NFSv3 fattr3结构包含一个固定的属性列表，并非所有客户端和服务器都能够支持或关心这些属性。fattr3结构不能随着新需求的出现而扩展，也无法表示不支持。使用NFSv4.1协议，客户机能够查询服务器支持哪些属性，并仅使用这些支持的属性（或其子集）构造请求。
To this end, attributes are divided into three groups: REQUIRED, RECOMMENDED, and named. Both REQUIRED and RECOMMENDED attributes are supported in the NFSv4.1 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 2.7 for further discussion.
为此，属性分为三组：必需、推荐和命名。NFSv4.1协议通过特定和定义良好的编码支持必需和推荐属性，并通过数字标识。通过在GETATTR请求中发送的位向量中设置位来请求它们；服务器响应包含一个位向量，用于列出响应中返回的属性。通过发布分配新属性编号值并定义属性编码的标准跟踪RFC，可以将新的必需或推荐属性作为新次要版本的一部分添加到NFSv4协议中。进一步讨论见第2.7节。
Named attributes are accessed by the new 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 implementors 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 but, 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 MUST be supported by every NFSv4.1 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 may be impaired or limited in some ways. A client may ask for any of these attributes to be returned by setting a bit in the GETATTR request, and the server MUST return their value.
为了确保最低水平的互操作性，每个NFSv4.1客户端和服务器都必须支持这些功能。服务器必须存储并返回这些属性，客户机必须能够使用限制于这些属性的属性集运行。仅使用所需的属性，某些客户端功能可能会在某些方面受到损害或限制。客户机可以通过在GETATTR请求中设置一个位来请求返回这些属性中的任何一个，服务器必须返回它们的值。
These attributes are understood well enough to warrant support in the NFSv4.1 protocol. However, they may not be supported on all clients and servers. A client may ask for any of these attributes to be 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 should be either an accurate time or should not be
对这些属性的理解足以保证NFSv4.1协议中的支持。但是，并非所有客户端和服务器都支持它们。客户机可以通过在GETATTR请求中设置一个位来请求返回这些属性中的任何一个，但必须处理服务器不返回这些属性的情况。客户端可能要求服务器支持的属性集，但不应要求服务器不支持的属性集。服务器应该能够容忍对不受支持的属性的请求，并且不返回它们，而不是将请求视为错误。预计服务器将支持其能够轻松支持的所有属性，并且只支持在其操作环境中难以支持的属性。只要服务器不必向客户端“撒谎”，就应该提供属性。例如，文件修改时间应该是准确的时间，或者不应该是准确的时间
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.
由服务器支持。有时，这对客户机来说很困难，但客户机可以更好地决定是否以及如何制作或构造属性，或者是否不使用属性。
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 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.
NFSv4协议中的直接编码不支持这些属性，但可以通过字符串名称而不是数字来访问这些属性，并对应于与文件系统对象一起存储的未解释的字节流。可以使用OPENATTR操作访问这些属性的名称空间。OPENATTR操作返回虚拟“命名属性目录”的文件句柄，可以使用在更典型的目录上工作的操作来进一步阅读和修改名称空间。具体而言，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 and the named attribute directory might be the target of delegations (in the case of the named attribute directory, these will be directory delegations). However, since granting delegations is at the server's discretion, a server need not support delegations on named attributes or the named attribute directory.
命名属性和命名属性目录可能是委派的目标（对于命名属性目录，这些将是目录委派）。但是，由于授权是由服务器自行决定的，因此服务器不需要支持对命名属性或命名属性目录的授权。
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.1, 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.1中，命名属性目录的结构以多种方式受到限制，以防止开发不可互操作的实现，其中一些服务器支持命名属性的完全通用层次目录结构，而另一些服务器支持有限但适当的命名属性结构。在这样的环境中，客户端或应用程序可能会依赖于不可移植的扩展。这些限制包括：
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 NFS4ERR_WRONG_TYPE.
o 如果在命名属性目录或命名属性上执行OPENATTR，则服务器必须返回NFS4ERR\u错误类型。
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 22.1 for further discussion.
属性名称不受本文件或其他IETF标准跟踪文件的控制。进一步讨论见第22.1节。
Each of the REQUIRED and RECOMMENDED attributes can be classified in one of three categories: per server (i.e., the value of the attribute will be the same for all file objects that share the same server owner; see Section 2.5 for a definition of server owner), per file system (i.e., the value of the attribute will be the same for some or all file objects that share the same fsid attribute (Section 5.8.1.9) and server owner), or per file system object. Note that it is possible that some per file system attributes may vary within the file system, depending on the value of the "homogeneous" (Section 5.8.2.16) attribute. 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.
每个必需的和推荐的属性可以分为三类：每个服务器（即，共享同一服务器所有者的所有文件对象的属性值都相同；有关服务器所有者的定义，请参见第2.5节）、每个文件系统（即，对于共享相同fsid属性（第5.8.1.9节）和服务器所有者的某些或所有文件对象，该属性的值将是相同的），或者对于每个文件系统对象，该属性的值将是相同的。请注意，根据“同构”（第5.8.2.16节）的值，每个文件系统中的某些属性可能会有所不同属性。请注意，属性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, suppattr_exclcreat, 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, time_delta, change_policy, fs_status, fs_layout_type, fs_locations_info, fs_charset_cap
受支持的属性、支持属性、exclcreat、fh过期类型、链接支持、符号链接支持、唯一句柄、aclsupport、cansettime、大小写不敏感、保留大小写、chown限制、文件可用、文件可用、文件总数、fs位置、同构、最大文件大小、最大名称、最大读取、最大写入、无特鲁NC、空间可用、空间可用、空间总数、时间增量、，更改策略、fs状态、fs布局类型、fs位置信息、fs字符集上限
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, mounted_on_fileid, dir_notif_delay, dirent_notif_delay, dacl, sacl, layout_type, layout_hint, layout_blksize, layout_alignment, mdsthreshold, retention_get, retention_set, retentevt_get, retentevt_set, retention_hold, mode_set_masked
类型、更改、大小、命名属性、fsid、rdattr错误、文件句柄、acl、存档、文件ID、隐藏、maxlink、mimetype、模式、numlinks、所有者、所有者组、rawdev、使用的空间、系统、时间访问、时间备份、时间创建、时间元数据、时间修改、在文件ID上挂载、dir-notif-delay、dirent-notif-delay、dacl、sacl、布局类型、布局提示、，布局blksize、布局对齐、mdsthreshold、保留设置、保留设置、保留设置、保留设置、保留设置、保留保持、模式设置屏蔽
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 attributes, 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 2. The meaning of the columns of the table are:
表2中显示了所需属性的列表。表中各列的含义如下：
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 [13], the latter is likely authoritative, but should be resolved with Errata to this document and/or [13]. See [44] for the Errata process.
o Id：分配给属性的编号。如果分配的编号与[13]之间存在冲突，后者可能具有权威性，但应使用本文件和/或[13]的勘误表予以解决。有关勘误表过程，请参见[44]。
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 | uint64_t | 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 | enum | R | Section 5.8.1.12 |
| filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 |
| suppattr_exclcreat | 75 | bitmap4 | R | Section 5.8.1.14 |
+--------------------+----+------------+-----+------------------+
+--------------------+----+------------+-----+------------------+
| 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 | uint64_t | 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 | enum | R | Section 5.8.1.12 |
| filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 |
| suppattr_exclcreat | 75 | bitmap4 | R | Section 5.8.1.14 |
+--------------------+----+------------+-----+------------------+
Table 2
表2
The RECOMMENDED attributes are defined in Table 3. The meanings of the column headers are the same as Table 2; see Section 5.6 for the meanings.
表3中定义了推荐的属性。列标题的含义与表2相同；含义见第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 |
| change_policy | 60 | chg_policy4 | R | Section 5.8.2.5 |
| chown_restricted | 18 | bool | R | Section 5.8.2.6 |
| dacl | 58 | nfsacl41 | R W | Section 6.2.2 |
| dir_notif_delay | 56 | nfstime4 | R | Section 5.11.1 |
| dirent_notif_delay | 57 | nfstime4 | R | Section 5.11.2 |
| fileid | 20 | uint64_t | R | Section 5.8.2.7 |
| files_avail | 21 | uint64_t | R | Section 5.8.2.8 |
| files_free | 22 | uint64_t | R | Section 5.8.2.9 |
| files_total | 23 | uint64_t | R | Section 5.8.2.10 |
| fs_charset_cap | 76 | uint32_t | R | Section 5.8.2.11 |
| fs_layout_type | 62 | layouttype4<> | R | Section 5.12.1 |
| fs_locations | 24 | fs_locations | R | Section 5.8.2.12 |
| fs_locations_info | 67 | * | R | Section 5.8.2.13 |
| fs_status | 61 | fs4_status | R | Section 5.8.2.14 |
| hidden | 25 | bool | R W | Section 5.8.2.15 |
| homogeneous | 26 | bool | R | Section 5.8.2.16 |
| layout_alignment | 66 | uint32_t | R | Section 5.12.2 |
| layout_blksize | 65 | uint32_t | R | Section 5.12.3 |
| layout_hint | 63 | layouthint4 | W | Section 5.12.4 |
| layout_type | 64 | layouttype4<> | R | Section 5.12.5 |
| maxfilesize | 27 | uint64_t | R | Section 5.8.2.17 |
| maxlink | 28 | uint32_t | R | Section 5.8.2.18 |
| maxname | 29 | uint32_t | R | Section 5.8.2.19 |
| maxread | 30 | uint64_t | R | Section 5.8.2.20 |
| maxwrite | 31 | uint64_t | R | Section 5.8.2.21 |
| mdsthreshold | 68 | mdsthreshold4 | R | Section 5.12.6 |
| mimetype | 32 | utf8str_cs | R W | Section 5.8.2.22 |
| mode | 33 | mode4 | R W | Section 6.2.4 |
| mode_set_masked | 74 | mode_masked4 | W | Section 6.2.5 |
| mounted_on_fileid | 55 | uint64_t | R | Section 5.8.2.23 |
| no_trunc | 34 | bool | R | Section 5.8.2.24 |
| numlinks | 35 | uint32_t | R | Section 5.8.2.25 |
| owner | 36 | utf8str_mixed | R W | Section 5.8.2.26 |
| owner_group | 37 | utf8str_mixed | R W | Section 5.8.2.27 |
| quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.28 |
| quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.29 |
| quota_used | 40 | uint64_t | R | Section 5.8.2.30 |
| rawdev | 41 | specdata4 | R | Section 5.8.2.31 |
| retentevt_get | 71 | retention_get4 | R | Section 5.13.3 |
+--------------------+----+----------------+-----+------------------+
| 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 |
| change_policy | 60 | chg_policy4 | R | Section 5.8.2.5 |
| chown_restricted | 18 | bool | R | Section 5.8.2.6 |
| dacl | 58 | nfsacl41 | R W | Section 6.2.2 |
| dir_notif_delay | 56 | nfstime4 | R | Section 5.11.1 |
| dirent_notif_delay | 57 | nfstime4 | R | Section 5.11.2 |
| fileid | 20 | uint64_t | R | Section 5.8.2.7 |
| files_avail | 21 | uint64_t | R | Section 5.8.2.8 |
| files_free | 22 | uint64_t | R | Section 5.8.2.9 |
| files_total | 23 | uint64_t | R | Section 5.8.2.10 |
| fs_charset_cap | 76 | uint32_t | R | Section 5.8.2.11 |
| fs_layout_type | 62 | layouttype4<> | R | Section 5.12.1 |
| fs_locations | 24 | fs_locations | R | Section 5.8.2.12 |
| fs_locations_info | 67 | * | R | Section 5.8.2.13 |
| fs_status | 61 | fs4_status | R | Section 5.8.2.14 |
| hidden | 25 | bool | R W | Section 5.8.2.15 |
| homogeneous | 26 | bool | R | Section 5.8.2.16 |
| layout_alignment | 66 | uint32_t | R | Section 5.12.2 |
| layout_blksize | 65 | uint32_t | R | Section 5.12.3 |
| layout_hint | 63 | layouthint4 | W | Section 5.12.4 |
| layout_type | 64 | layouttype4<> | R | Section 5.12.5 |
| maxfilesize | 27 | uint64_t | R | Section 5.8.2.17 |
| maxlink | 28 | uint32_t | R | Section 5.8.2.18 |
| maxname | 29 | uint32_t | R | Section 5.8.2.19 |
| maxread | 30 | uint64_t | R | Section 5.8.2.20 |
| maxwrite | 31 | uint64_t | R | Section 5.8.2.21 |
| mdsthreshold | 68 | mdsthreshold4 | R | Section 5.12.6 |
| mimetype | 32 | utf8str_cs | R W | Section 5.8.2.22 |
| mode | 33 | mode4 | R W | Section 6.2.4 |
| mode_set_masked | 74 | mode_masked4 | W | Section 6.2.5 |
| mounted_on_fileid | 55 | uint64_t | R | Section 5.8.2.23 |
| no_trunc | 34 | bool | R | Section 5.8.2.24 |
| numlinks | 35 | uint32_t | R | Section 5.8.2.25 |
| owner | 36 | utf8str_mixed | R W | Section 5.8.2.26 |
| owner_group | 37 | utf8str_mixed | R W | Section 5.8.2.27 |
| quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.28 |
| quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.29 |
| quota_used | 40 | uint64_t | R | Section 5.8.2.30 |
| rawdev | 41 | specdata4 | R | Section 5.8.2.31 |
| retentevt_get | 71 | retention_get4 | R | Section 5.13.3 |
| retentevt_set | 72 | retention_set4 | W | Section 5.13.4 |
| retention_get | 69 | retention_get4 | R | Section 5.13.1 |
| retention_hold | 73 | uint64_t | R W | Section 5.13.5 |
| retention_set | 70 | retention_set4 | W | Section 5.13.2 |
| sacl | 59 | nfsacl41 | R W | Section 6.2.3 |
| space_avail | 42 | uint64_t | R | Section 5.8.2.32 |
| space_free | 43 | uint64_t | R | Section 5.8.2.33 |
| space_total | 44 | uint64_t | R | Section 5.8.2.34 |
| space_used | 45 | uint64_t | R | Section 5.8.2.35 |
| system | 46 | bool | R W | Section 5.8.2.36 |
| time_access | 47 | nfstime4 | R | Section 5.8.2.37 |
| time_access_set | 48 | settime4 | W | Section 5.8.2.38 |
| time_backup | 49 | nfstime4 | R W | Section 5.8.2.39 |
| time_create | 50 | nfstime4 | R W | Section 5.8.2.40 |
| time_delta | 51 | nfstime4 | R | Section 5.8.2.41 |
| time_metadata | 52 | nfstime4 | R | Section 5.8.2.42 |
| time_modify | 53 | nfstime4 | R | Section 5.8.2.43 |
| time_modify_set | 54 | settime4 | W | Section 5.8.2.44 |
+--------------------+----+----------------+-----+------------------+
| retentevt_set | 72 | retention_set4 | W | Section 5.13.4 |
| retention_get | 69 | retention_get4 | R | Section 5.13.1 |
| retention_hold | 73 | uint64_t | R W | Section 5.13.5 |
| retention_set | 70 | retention_set4 | W | Section 5.13.2 |
| sacl | 59 | nfsacl41 | R W | Section 6.2.3 |
| space_avail | 42 | uint64_t | R | Section 5.8.2.32 |
| space_free | 43 | uint64_t | R | Section 5.8.2.33 |
| space_total | 44 | uint64_t | R | Section 5.8.2.34 |
| space_used | 45 | uint64_t | R | Section 5.8.2.35 |
| system | 46 | bool | R W | Section 5.8.2.36 |
| time_access | 47 | nfstime4 | R | Section 5.8.2.37 |
| time_access_set | 48 | settime4 | W | Section 5.8.2.38 |
| time_backup | 49 | nfstime4 | R W | Section 5.8.2.39 |
| time_create | 50 | nfstime4 | R W | Section 5.8.2.40 |
| time_delta | 51 | nfstime4 | R | Section 5.8.2.41 |
| time_metadata | 52 | nfstime4 | R | Section 5.8.2.42 |
| time_modify | 53 | nfstime4 | R | Section 5.8.2.43 |
| time_modify_set | 54 | settime4 | W | Section 5.8.2.44 |
+--------------------+----+----------------+-----+------------------+
Table 3
表3
* fs_locations_info4
* 财政司司长(地点)资讯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 phrases "is an ordinary file" and "is a regular file" mean that the object's type attribute is NF4REG or NF4NAMEDATTR.
o 短语“是普通文件”和“是常规文件”表示对象的type属性是NF4REG或NF4NAMEDATTR。
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, 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 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 bit vector that would set all REQUIRED and RECOMMENDED attributes that are supported by the EXCLUSIVE4_1 method of file creation via the OPEN operation. The scope of this attribute applies to all objects with a matching fsid.
位向量，用于设置通过OPEN操作创建文件的EXCLUSIVE4_1方法所支持的所有必需和推荐属性。此属性的范围适用于具有匹配fsid的所有对象。
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 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 file name comparisons on this file system are case insensitive.
如果此文件系统上的文件名比较不区分大小写，则为TRUE。
TRUE, if file name case on this file system is preserved.
如果保留此文件系统上的文件名大小写，则为TRUE。
A value created by the server that the client can use to determine if some server policy related to the current file system has been subject to change. If the value remains the same, then the client can be sure that the values of the attributes related to fs location and the fss_type field of the fs_status attribute have not changed. On the other hand, a change in this value does necessarily imply a change in policy. It is up to the client to interrogate the server to determine if some policy relevant to it has changed. See Section 3.3.6 for details.
由服务器创建的值，客户端可使用该值确定与当前文件系统相关的某些服务器策略是否已更改。如果该值保持不变，则客户端可以确保与fs location相关的属性值和fs_status属性的fss_类型字段没有更改。另一方面，该值的变化必然意味着政策的变化。由客户机询问服务器，以确定与服务器相关的某些策略是否已更改。详见第3.3.6节。
This attribute MUST change when the value returned by the fs_locations or fs_locations_info attribute changes, when a file system goes from read-only to writable or vice versa, or when the allowable set of security flavors for the file system or any part thereof is changed.
当fs_locations或fs_locations_info属性返回的值更改时，当文件系统从只读变为可写时，或者当文件系统或其任何部分的允许安全样式集更改时，此属性必须更改。
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, in Windows 2000, the "Take Ownership" privilege).
如果为TRUE，则如果调用者不是特权用户（例如，UNIX操作环境中的“root”或Windows 2000中的“获取所有权”特权），服务器将拒绝任何更改与文件关联的所有者或组的请求。
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.
包含此对象的文件系统上的文件插槽总数。
Character set capabilities for this file system. See Section 14.4.
此文件系统的字符集功能。见第14.4节。
Locations where this file system may be found. If the server returns NFS4ERR_MOVED as an error, this attribute MUST be supported. See Section 11.9 for more details.
可以找到此文件系统的位置。如果服务器返回NFS4ERR_MOVED作为错误，则必须支持此属性。详见第11.9节。
Full function file system location. See Section 11.10 for more details.
全功能文件系统位置。详见第11.10节。
Generic file system type information. See Section 11.11 for more details.
通用文件系统类型信息。详见第11.11节。
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.
如果此对象的文件系统是同构的，则为TRUE；i、 例如，文件系统中的所有对象（服务器上具有相同fsid的所有对象）都具有每个文件系统属性的公共值。
Maximum supported file size for the file system of this object.
此对象的文件系统支持的最大文件大小。
Maximum number of links for this object.
此对象的最大链接数。
Maximum file name 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 body 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 like readdir(), 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() 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（）之类的API读取装载点的父目录时，返回的结果是目录项，每个目录项都有一个组件名和一个文件ID。装载点目录项的fileid将不同于stat（）系统调用返回的fileid。stat（）系统调用返回装载的文件系统的根的fileid，而readdir（）返回在装载点上装载任何文件系统之前stat（）将返回的fileid。
Unlike NFSv3, NFSv4.1 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.1允许客户端的查找请求跨其他文件系统。只要LOOKUP的filehandle参数具有与LOOKUP返回的filehandle不同的fsid属性，客户端就会检测文件系统交叉。一个基于UNIX的客户端将考虑这是一个“挂载点交叉”。UNIX有一个遗留方案，允许进程确定其当前工作目录。这依赖于装载点的父级的readdir（）和装载点的stat（），如前所述返回fileid。mounted_on_fileid属性对应于readdir（）将返回的fileid，如前所述。
While the NFSv4.1 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.1客户端可以简单地创建一个与mounted_on_fileid提供的内容相对应的fileid（如果服务器不支持mounted_on_fileid，则客户端别无选择），但存在这样的风险，即客户端将生成一个与已分配给文件系统中另一个对象的文件id冲突的文件id。相反，如果服务器可以提供挂载的\u on_文件ID，则可以消除此区域中客户端操作问题的可能性。
If the server detects that there is no mounted point at the target file object, then the value for mounted_on_fileid that it returns is the same as that of the fileid attribute.
如果服务器检测到目标文件对象上没有挂载点，那么它返回的\u fileid上挂载的\u的值与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 file name 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 is a rule 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".
请注意，可能存在许多不同但重叠的文件或目录集，为这些文件或目录保留配额使用值，例如，“具有给定所有者的所有文件”、“具有给定组所有者的所有文件”等。在提供配额使用属性的内容时，服务器可以自由选择这些文件或目录集中的任何一个，但应该以可重复的方式这样做。规则可以按文件系统配置，也可以是“选择配额最小的集合”。
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, the 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.
分配给此对象的文件系统字节数。
This attribute is TRUE if this file is a "system" file with respect to the Windows operating environment.
如果此文件是相对于Windows操作环境的“系统”文件，则此属性为TRUE。
The time_access attribute 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 [16], [17], [18]. Of course, setting the corresponding time_access_set attribute is another way to modify the time_access attribute.
time_access属性表示通过发送到服务器的读取操作上次访问对象的时间。什么是“访问”的概念取决于服务器的操作环境和/或服务器的文件系统语义。例如，对于遵循可移植操作系统接口（POSIX）语义的服务器，time_访问将仅由READ和READDIR操作更新，而不是任何修改对象内容的操作[16]、[17]、[18]。当然，设置相应的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" or "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 within the "acl" attribute) are represented in terms of a UTF-8 string. To avoid a representation that is tied to a particular underlying implementation at the client or server, the use of the UTF-8 string has been chosen. Note that Section 6.1 of RFC 2624 [45] provides additional rationale. It is expected that the client and server will have their own local representation of owner and owner_group that is used for local storage or presentation to the end user. Therefore, it is expected that when these attributes are transferred between the client and server, the local representation is translated to a syntax of the form "user@dns_domain". This will allow for a client and server that do not use the same local representation the ability to translate to a common syntax that can be interpreted by both.
推荐的属性“owner”和“owner_group”（以及“acl”属性中的用户和组）用UTF-8字符串表示。为了避免在客户端或服务器上绑定到特定底层实现的表示，选择使用UTF-8字符串。请注意，RFC 2624[45]第6.1节提供了额外的理由。预期客户端和服务器将拥有自己的本地所有者和所有者组表示，用于本地存储或向最终用户演示。因此，当这些属性在客户机和服务器之间传输时，本地表示将被转换为以下形式的语法：user@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 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.
用于解释所有者和组字符串的转换未指定为协议的一部分。这允许采用各种解决方案。例如，可以参考将数字标识符映射到本地的本地翻译表user@dns_domain语法。名称服务也可用于完成翻译。服务器可以提供更一般的服务，不受任何特定翻译的限制（只翻译有限的一组可能字符串）通过将所有者和所有者组属性存储在本地存储中而不进行任何转换，或者可以通过存储没有转换的属性的整个字符串来扩充转换方法，同时对有转换的情况使用本地表示。
Servers that do not provide support for all possible values of the owner and owner_group attributes 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, owner_group, or acl attributes. When a server does accept an owner or owner_group value as valid on a SETATTR (and similarly for the owner and group strings in an acl), it is promising to return that same string when a corresponding GETATTR is done. 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 ownership has occurred.
当显示没有翻译的字符串时，不支持所有者和所有者组属性的所有可能值的服务器应返回一个错误（NFS4ERR\u BADOWNER），作为要为所有者、所有者组或acl属性的SETATTR设置的值。当服务器确实接受在SETATTR上有效的owner或owner\u group值（对于acl中的owner和group字符串也是如此）时，它承诺在完成相应的GETATTR时返回相同的字符串。配置更改（包括从字符串映射到本地表示的更改）和构造错误的名称转换（那些包含别名的转换）可能会使这一承诺无法兑现。服务器应该做出适当的努力，避免在所有权没有发生实际变化的情况下，这些属性的值发生变化。
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. 服务器应接受至少一个域的一组用户作为有效用户。服务器可能会将其他域视为没有有效的翻译。当服务器能够接受多个域或所有域的用户时，会提供更一般的服务，但会受到安全约束。
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 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.
如果客户机或服务器没有可用的转换，则将构造属性值，而不使用“@”。因此，如果owner或owner_group属性中没有@，则表示发送方没有可用的翻译，并且该属性的接收方不应使用该字符串作为将其转换为自身内部格式的基础。即使无法转换属性值，它仍然可能有用。对于客户端，属性字符串可用于本地显示所有权。
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 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. A server is not obligated to accept such a string, but may return an NFS4ERR_BADOWNER instead. To avoid this mechanism being used to subvert user and group translation, so that a client might pass all of the owners and groups in numeric form, a 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 name@domain string and not the special form for compatibility.
NFSv3通过32位无符号用户标识符和组标识符来标识用户和组，为了与NFSv3提供更大程度的兼容性，选择提供此类支持的客户端和服务器可以对由十进制数值组成的所有者和组字符串（不带前导零）进行特殊解释。接收方可以将这样的用户或组字符串视为表示将由具有相应数值的NFSv3 uid或gid表示的相同用户。服务器没有义务接受这样的字符串，但可以返回NFS4ERR_BADOWNER。为了避免使用此机制来破坏用户和组转换，以便客户端可以以数字形式传递所有所有者和组，当存在以这种方式指定的用户或所有者的有效转换时，服务器应返回NFS4ERR_BADOWNER错误。在这种情况下，客户必须使用适当的name@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. Users and implementations of NFSv4.1 SHOULD NOT use "nobody" to designate a real user whose access is not anonymous.
所有者字符串“nobody”可用于指定匿名用户，该用户将与安全主体创建的文件关联，该文件无法通过正常方式映射到所有者属性。NFSv4.1的用户和实现不应使用“nobody”来指定访问权限不是匿名的真实用户。
With respect to the case_insensitive and case_preserving attributes, each UCS-4 character (which UTF-8 encodes) can be mapped according to Appendix B.2 of RFC 3454 [19]. For general character handling and internationalization issues, see Section 14.
关于不区分大小写和保留大小写属性，每个UCS-4字符（UTF-8编码）可以根据RFC 3454[19]的附录B.2进行映射。有关一般字符处理和国际化问题，请参见第14节。
As described in Section 18.39, the client can request a minimum delay for notifications of changes to attributes, but the server is free to ignore what the client requests. The client can determine in advance what notification delays the server will accept by sending a GETATTR operation for either or both of two directory notification attributes. When the client calls the GET_DIR_DELEGATION operation and asks for attribute change notifications, it should request notification delays that are no less than the values in the server-provided attributes.
如第18.39节所述，客户端可以请求属性更改通知的最小延迟，但服务器可以自由忽略客户端请求的内容。客户端可以通过为两个目录通知属性中的一个或两个属性发送GETATTR操作，预先确定服务器将接受的通知延迟。当客户端调用GET_DIR_委派操作并请求属性更改通知时，它应该请求不小于服务器提供的属性中的值的通知延迟。
The dir_notif_delay attribute is the minimum number of seconds the server will delay before notifying the client of a change to the directory's attributes.
dir_notif_delay属性是服务器在通知客户端目录属性的更改之前延迟的最小秒数。
The dirent_notif_delay attribute is the minimum number of seconds the server will delay before notifying the client of a change to a file object that has an entry in the directory.
dirent_notif_delay属性是服务器在通知客户端对目录中包含条目的文件对象所做的更改之前延迟的最短秒数。
The fs_layout_type attribute (see Section 3.3.13) applies to a file system and indicates what layout types are supported by the file system. When the client encounters a new fsid, the client SHOULD obtain the value for the fs_layout_type attribute associated with the new file system. This attribute is used by the client to determine if the layout types supported by the server match any of the client's supported layout types.
fs_layout_type属性（参见第3.3.13节）适用于文件系统，并指示文件系统支持哪些布局类型。当客户端遇到新的fsid时，客户端应获取与新文件系统关联的fs_layout_type属性的值。客户端使用此属性确定服务器支持的布局类型是否与客户端支持的任何布局类型匹配。
When a client holds layouts on files of a file system, the layout_alignment attribute indicates the preferred alignment for I/O to files on that file system. Where possible, the client should send READ and WRITE operations with offsets that are whole multiples of the layout_alignment attribute.
当客户端在文件系统的文件上保存布局时，“布局对齐”属性表示I/O与该文件系统上文件的首选对齐方式。在可能的情况下，客户端应发送带有偏移量的读写操作，偏移量是布局对齐属性的整数倍。
When a client holds layouts on files of a file system, the layout_blksize attribute indicates the preferred block size for I/O to files on that file system. Where possible, the client should send READ operations with a count argument that is a whole multiple of layout_blksize, and WRITE operations with a data argument of size that is a whole multiple of layout_blksize.
当客户端在文件系统的文件上保存布局时，layout_blksize属性表示该文件系统上文件的I/O首选块大小。在可能的情况下，客户端应发送读取操作和写入操作，读取操作的count参数是layout_blksize的整数倍，写入操作的data参数是layout_blksize的整数倍。
The layout_hint attribute (see Section 3.3.19) may be set on newly created files to influence the metadata server's choice for the file's layout. If possible, this attribute is one of those set in the initial attributes within the OPEN operation. The metadata server may choose to ignore this attribute. The layout_hint attribute is a subset of the layout structure returned by LAYOUTGET. For example, instead of specifying particular devices, this would be used to suggest the stripe width of a file. The server implementation determines which fields within the layout will be used.
布局提示属性（见第3.3.19节）可设置在新创建的文件上，以影响元数据服务器对文件布局的选择。如果可能，此属性是打开操作中初始属性中设置的属性之一。元数据服务器可以选择忽略此属性。layout_hint属性是LAYOUTGET返回的布局结构的子集。例如，这将用于建议文件的条带宽度，而不是指定特定的设备。服务器实现决定将使用布局中的哪些字段。
This attribute lists the layout type(s) available for a file. The value returned by the server is for informational purposes only. The client will use the LAYOUTGET operation to obtain the information needed in order to perform I/O, for example, the specific device information for the file and its layout.
此属性列出文件可用的布局类型。服务器返回的值仅供参考。客户端将使用LAYOUTGET操作获取执行I/O所需的信息，例如，文件及其布局的特定设备信息。
This attribute is a server-provided hint used to communicate to the client when it is more efficient to send READ and WRITE operations to the metadata server or the data server. The two types of thresholds described are file size thresholds and I/O size thresholds. If a file's size is smaller than the file size threshold, data accesses SHOULD be sent to the metadata server. If an I/O request has a length that is below the I/O size threshold, the I/O SHOULD be sent to the metadata server. Each threshold type is specified separately for read and write.
此属性是服务器提供的提示，用于在向元数据服务器或数据服务器发送读写操作更有效时与客户端通信。描述的两种阈值类型是文件大小阈值和I/O大小阈值。如果文件大小小于文件大小阈值，则应将数据访问发送到元数据服务器。如果I/O请求的长度低于I/O大小阈值，则应将I/O发送到元数据服务器。每个阈值类型都分别指定用于读取和写入。
The server MAY provide both types of thresholds for a file. If both file size and I/O size are provided, the client SHOULD reach or exceed both thresholds before sending its read or write requests to the data server. Alternatively, if only one of the specified thresholds is reached or exceeded, the I/O requests are sent to the metadata server.
服务器可以为文件提供两种类型的阈值。如果同时提供了文件大小和I/O大小，则客户端在向数据服务器发送读或写请求之前应达到或超过这两个阈值。或者，如果仅达到或超过一个指定的阈值，则向元数据服务器发送I/O请求。
For each threshold type, a value of zero indicates no READ or WRITE should be sent to the metadata server, while a value of all ones indicates that all READs or WRITEs should be sent to the metadata server.
对于每个阈值类型，值为零表示不应向元数据服务器发送读取或写入，而值为all表示应向元数据服务器发送所有读取或写入。
The attribute is available on a per-filehandle basis. If the current filehandle refers to a non-pNFS file or directory, the metadata server should return an attribute that is representative of the filehandle's file system. It is suggested that this attribute is queried as part of the OPEN operation. Due to dynamic system changes, the client should not assume that the attribute will remain constant for any specific time period; thus, it should be periodically refreshed.
该属性在每个文件句柄的基础上可用。如果当前文件句柄引用非pNFS文件或目录，则元数据服务器应返回代表文件句柄文件系统的属性。建议将此属性作为打开操作的一部分进行查询。由于系统动态变化，客户不应假设属性在任何特定时间段内保持不变；因此，它应该定期刷新。
Retention is a concept whereby a file object can be placed in an immutable, undeletable, unrenamable state for a fixed or infinite duration of time. Once in this "retained" state, the file cannot be moved out of the state until the duration of retention has been reached.
保留是一个概念，在此概念中，文件对象可以在固定或无限的时间内处于不可变、不可删除、不可更改的状态。一旦处于此“保留”状态，在达到保留期限之前，无法将文件移出该状态。
When retention is enabled, retention MUST extend to the data of the file, and the name of file. The server MAY extend retention to any other property of the file, including any subset of REQUIRED, RECOMMENDED, and named attributes, with the exceptions noted in this section.
启用保留后，保留必须扩展到文件的数据和文件名。服务器可以将保留扩展到文件的任何其他属性，包括必需、推荐和命名属性的任何子集，但本节中指出的例外情况除外。
Servers MAY support or not support retention on any file object type.
服务器可能支持或不支持对任何文件对象类型的保留。
The five retention attributes are explained in the next subsections.
下面的小节将解释这五个保留属性。
If retention is enabled for the associated file, this attribute's value represents the retention begin time of the file object. This attribute's value is only readable with the GETATTR operation and MUST NOT be modified by the SETATTR operation (Section 5.5). The value of the attribute consists of:
如果为关联文件启用了保留，则此属性的值表示文件对象的保留开始时间。此属性的值只能通过GETATTR操作读取，并且不能通过SETATTR操作修改（第5.5节）。该属性的值包括：
const RET4_DURATION_INFINITE = 0xffffffffffffffff;
struct retention_get4 {
uint64_t rg_duration;
nfstime4 rg_begin_time<1>;
};
const RET4_DURATION_INFINITE = 0xffffffffffffffff;
struct retention_get4 {
uint64_t rg_duration;
nfstime4 rg_begin_time<1>;
};
The field rg_duration is the duration in seconds indicating how long the file will be retained once retention is enabled. The field rg_begin_time is an array of up to one absolute time value. If the array is zero length, no beginning retention time has been established, and retention is not enabled. If rg_duration is equal to RET4_DURATION_INFINITE, the file, once retention is enabled, will be retained for an infinite duration.
字段rg_duration是以秒为单位的持续时间，指示启用保留后文件将保留多长时间。字段rg_begin_time是一个最多包含一个绝对时间值的数组。如果阵列长度为零，则未建立起始保留时间，并且未启用保留。如果rg_duration等于RET4_duration_INFINITE，则启用保留后，该文件将保留无限期。
If (as soon as) rg_duration is zero, then rg_begin_time will be of zero length, and again, retention is not (no longer) enabled.
如果（一旦）rg_持续时间为零，则rg_开始时间的长度为零，并且再次说明，未（不再）启用保留。
This attribute is used to set the retention duration and optionally enable retention for the associated file object. This attribute is only modifiable via the SETATTR operation and MUST NOT be retrieved by the GETATTR operation (Section 5.5). This attribute corresponds to retention_get. The value of the attribute consists of:
此属性用于设置保留期限，并可选地启用关联文件对象的保留。此属性只能通过SETATTR操作进行修改，不能通过GETATTR操作进行检索（第5.5节）。此属性对应于保留时间。该属性的值包括：
struct retention_set4 {
bool rs_enable;
uint64_t rs_duration<1>;
};
struct retention_set4 {
bool rs_enable;
uint64_t rs_duration<1>;
};
If the client sets rs_enable to TRUE, then it is enabling retention on the file object with the begin time of retention starting from the server's current time and date. The duration of the retention can also be provided if the rs_duration array is of length one. The duration is the time in seconds from the begin time of retention, and if set to RET4_DURATION_INFINITE, the file is to be retained forever. If retention is enabled, with no duration specified in either this SETATTR or a previous SETATTR, the duration defaults to zero seconds. The server MAY restrict the enabling of retention or the duration of retention on the basis of the ACE4_WRITE_RETENTION ACL permission.
如果客户端将rs_enable设置为TRUE，则它将启用文件对象上的保留，保留开始时间从服务器的当前时间和日期开始。如果rs_duration数组的长度为1，则还可以提供保留的持续时间。持续时间是从开始保留时间算起的时间（秒），如果设置为RET4_duration_INFINITE，则文件将永久保留。如果启用了保留，并且在此SETATTR或以前的SETATTR中未指定持续时间，则持续时间默认为零秒。服务器可以根据ACE4_WRITE_retention ACL权限限制保留的启用或保留的持续时间。
The enabling of retention MUST NOT prevent the enabling of event-based retention or the modification of the retention_hold attribute.
启用保留不得阻止启用基于事件的保留或修改保留保留保留属性。
The following rules apply to both the retention_set and retentevt_set attributes.
以下规则适用于retention_集和retentevt_集属性。
o As long as retention is not enabled, the client is permitted to decrease the duration.
o 只要未启用保留，就允许客户端缩短持续时间。
o The duration can always be set to an equal or higher value, even if retention is enabled. Note that once retention is enabled, the actual duration (as returned by the retention_get or retentevt_get attributes; see Section 5.13.1 or Section 5.13.3) is constantly counting down to zero (one unit per second), unless the duration was set to RET4_DURATION_INFINITE. Thus, it will not be possible for the client to precisely extend the duration on a file that has retention enabled.
o 持续时间始终可以设置为相等或更高的值，即使启用了保留。请注意，启用保留后，实际持续时间（由retention_get或retentevt_get属性返回；请参阅第5.13.1节或第5.13.3节）将持续倒计时到零（每秒一个单位），除非持续时间设置为RET4_duration_INFINITE。因此，客户机不可能精确地延长启用了保留的文件的持续时间。
o While retention is enabled, attempts to disable retention or decrease the retention's duration MUST fail with the error NFS4ERR_INVAL.
o 启用保留时，禁用保留或缩短保留时间的尝试必须失败，错误为NFS4ERR_INVAL。
o If the principal attempting to change retention_set or retentevt_set does not have ACE4_WRITE_RETENTION permissions, the attempt MUST fail with NFS4ERR_ACCESS.
o 如果试图更改保留集或retentevt集的主体没有ACE4写入保留权限，则必须使用NFS4ERR\u访问权限失败。
Gets the event-based retention duration, and if enabled, the event-based retention begin time of the file object. This attribute is like retention_get, but refers to event-based retention. The event that triggers event-based retention is not defined by the NFSv4.1 specification.
获取基于事件的保留持续时间，如果启用，则获取文件对象的基于事件的保留开始时间。此属性类似于retention_get，但指基于事件的保留。NFSv4.1规范未定义触发基于事件的保留的事件。
Sets the event-based retention duration, and optionally enables event-based retention on the file object. This attribute corresponds to retentevt_get and is like retention_set, but refers to event-based retention. When event-based retention is set, the file MUST be retained even if non-event-based retention has been set, and the duration of non-event-based retention has been reached. Conversely, when non-event-based retention has been set, the file MUST be retained even if event-based retention has been set, and the duration of event-based retention has been reached. The server MAY restrict the enabling of event-based retention or the duration of event-based retention on the basis of the ACE4_WRITE_RETENTION ACL permission. The enabling of event-based retention MUST NOT prevent the enabling of non-event-based retention or the modification of the retention_hold attribute.
设置基于事件的保留期限，并可以选择对文件对象启用基于事件的保留。此属性对应于retentevt_get，类似于retention_set，但指基于事件的保留。设置基于事件的保留时，即使已设置非基于事件的保留，并且已达到非基于事件的保留期限，也必须保留文件。相反，如果已设置非基于事件的保留，则即使已设置基于事件的保留，并且已达到基于事件的保留期限，也必须保留文件。服务器可以基于ACE4_WRITE_retention ACL权限限制基于事件的保留的启用或基于事件的保留的持续时间。启用基于事件的保留不得阻止启用非基于事件的保留或修改保留保留保留属性。
Gets or sets administrative retention holds, one hold per bit position.
获取或设置管理保留挂起，每位位置一个挂起。
This attribute allows one to 64 administrative holds, one hold per bit on the attribute. If retention_hold is not zero, then the file MUST NOT be deleted, renamed, or modified, even if the duration on enabled event or non-event-based retention has been reached. The server MAY restrict the modification of retention_hold on the basis of the ACE4_WRITE_RETENTION_HOLD ACL permission. The enabling of administration retention holds does not prevent the enabling of event-based or non-event-based retention.
此属性允许一到64个管理保留，属性上每一位一个保留。如果保留时间不为零，则不得删除、重命名或修改文件，即使已达到启用事件或非基于事件的保留的持续时间。服务器可以基于ACE4\u写入\u保留\u保留ACL权限限制对保留\u保留的修改。启用管理保留保留不会阻止启用基于事件或非基于事件的保留。
If the principal attempting to change retention_hold does not have ACE4_WRITE_RETENTION_HOLD permissions, the attempt MUST fail with NFS4ERR_ACCESS.
如果尝试更改保留\u保持的主体没有ACE4\u写入\u保留\u保持权限，则必须通过NFS4ERR\u访问失败。
Access Control Lists (ACLs) are file attributes that specify fine-grained access control. This section covers the "acl", "dacl", "sacl", "aclsupport", "mode", and "mode_set_masked" file attributes and their interactions. Note that file attributes may apply to any file system object.
访问控制列表（ACL）是指定细粒度访问控制的文件属性。本节介绍“acl”、“dacl”、“sacl”、“aclsupport”、“mode”和“mode\u set\u masked”文件属性及其交互。请注意，文件属性可以应用于任何文件系统对象。
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 OPEN operations for OPEN4_SHARE_ACCESS_READ or OPEN4_SHARE_ACCESS_WRITE by any principal fail, regardless of a previously existing or inherited ACL.
* 仅设置mode属性应提供合理的安全性。例如，将模式设置为000应该足以确保任何主体对OPEN4_SHARE_ACCESS_READ或OPEN4_SHARE_ACCESS_WRITE的未来打开操作失败，而不考虑以前存在或继承的ACL。
o NFSv4.1 may introduce different semantics relating to the mode and ACL attributes, but it does not render invalid any previously existing implementations. Additionally, this section provides clarifications based on previous implementations and discussions around them.
o NFSv4.1可能会引入与模式和ACL属性相关的不同语义，但它不会使任何以前存在的实现无效。此外，本节还基于以前的实现和讨论提供了说明。
o On servers that support both the mode and the acl or dacl attributes, the server must keep the two consistent with each other. The value of the mode attribute (with the exception of the three high-order bits described in Section 6.2.4) must be determined entirely by the value of the ACL, so that use of the mode is never required for anything other than setting the three high-order bits. See Section 6.4.1 for exact requirements.
o 在同时支持模式和acl或dacl属性的服务器上，服务器必须使两者保持一致。模式属性的值（第6.2.4节中所述的三个高阶位除外）必须完全由ACL的值确定，因此除了设置三个高阶位外，任何事情都不需要使用模式。具体要求见第6.4.1节。
o When a mode attribute is set on an object, the ACL attributes may need to be modified in order to not conflict with the new mode. In such cases, it is desirable that the ACL keep as much information as possible. This includes information about inheritance, AUDIT and ALARM ACEs, and permissions granted and denied that do not conflict with the new mode.
o 在对象上设置模式属性时，可能需要修改ACL属性以避免与新模式冲突。在这种情况下，希望ACL保留尽可能多的信息。这包括有关继承、审核和报警ACE的信息，以及授予和拒绝的与新模式不冲突的权限。
The NFSv4.1 ACL attribute contains an array of Access Control Entries (ACEs) that are associated with the file system object. Although the client can set and get 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.1 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 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.
为了确定请求是否成功，服务器按顺序处理每个nfsace4条目。仅考虑具有与请求者匹配的“谁”的ACE。处理每个ACE，直到请求者访问的所有位都被允许。一旦一个位（见下文）被一个允许访问的ACE允许，它就不再被考虑在以后的ACE处理中。如果在请求者的访问仍然具有与ACE的“访问掩码”相同的未允许位的情况下遇到访问被拒绝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.
与ALLOW和DENY ACE类型不同，ALARM和AUDIT ACE类型不影响请求者的访问，而是作为请求者访问尝试的结果触发事件。因此，只有在处理“允许”和“拒绝”ACE之后，才会处理审核和报警ACE。
The NFSv4.1 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
NFSv4.1 ACL模型非常丰富。某些服务器平台可能提供超越UNIX样式模式属性的访问控制功能，但这并不像NFS ACL模型那样丰富。所以
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.1 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 be rejected.)
为了使用户能够利用这一更有限的功能，服务器可以通过其acl模型和NFSv4.1 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.1 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 SMB (Server Message Block). 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.1访问的强制执行可能不同于但不弱于本地访问的强制执行，并且两者都可能不同于通过其他协议（如SMB（服务器消息块））进行访问的强制执行。因此，即使不是所有的模块都能支持ACL，服务器接受ACL也是很有用的。
The guiding principle with regard to NFSv4 access is that the server must not accept ACLs that appear to make access to the file more restrictive than it really is.
关于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;
Only the ALLOWED and DENIED bits may be used in the dacl attribute, and only the AUDIT and ALARM bits may be used in the sacl attribute. All four are permitted in the acl attribute.
dacl属性中只能使用允许位和拒绝位，sacl属性中只能使用审核位和报警位。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 an alarm |
| | | (in a |
| | | system-dependent |
| | | way) 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 an alarm |
| | | (in a |
| | | system-dependent |
| | | way) 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拒绝该请求。
Support for any of the ACL attributes is optional (albeit RECOMMENDED). However, a server that supports either of the new ACL attributes (dacl or sacl) MUST allow use of the new ACL attributes to access all of the ACE types that it supports. In other words, if such a server supports ALLOW or DENY ACEs, then it MUST support the dacl attribute, and if it supports AUDIT or ALARM ACEs, then it MUST support the sacl attribute.
对任何ACL属性的支持都是可选的（尽管建议如此）。但是，支持新ACL属性（dacl或sacl）的服务器必须允许使用新ACL属性访问其支持的所有ACE类型。换句话说，如果这样的服务器支持允许或拒绝ACE，那么它必须支持dacl属性，如果它支持审计或报警ACE，那么它必须支持sacl属性。
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_WRITE_RETENTION = 0x00000200;
const ACE4_WRITE_RETENTION_HOLD = 0x00000400;
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_WRITE_RETENTION = 0x00000200;
const ACE4_WRITE_RETENTION_HOLD = 0x00000400;
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
请注意，某些掩码具有重合的值，例如，ACE4_读取_数据和ACE4_列表_目录。掩码条目ACE4_LIST_目录、ACE4_ADD_文件和ACE4_ADD_子目录是
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_附加_数据用于非目录对象。
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 allowed.
当仅允许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 attribute 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
阅读
OPEN
打开
REMOVE
去除
RENAME
改名
LINK
链接
CREATE
创造
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 allowed. 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
查找
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 ACE4_DELETE and ACE4_DELETE_CHILD interact.
删除目录中的文件或目录的权限。有关ACE4_DELETE和ACE4_DELETE_子交互的信息，请参见第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 that 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,
设置时间属性\u访问\u设置，时间\u备份，
time_create, time_modify_set, mimetype, hidden, system
创建时间、修改时间、复制类型、隐藏、系统
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_WRITE_RETENTION
ACE4_写入_保留
Operation(s) affected:
受影响的行动：
SETATTR of retention_set, retentevt_set.
保留集的设置属性，保留集。
Discussion:
讨论：
Permission to modify the durations of event and non-event-based retention. Also permission to enable event and non-event-based retention. A server MAY behave such that setting ACE4_WRITE_ATTRIBUTES allows ACE4_WRITE_RETENTION.
修改基于事件和非基于事件的保留期限的权限。还有启用基于事件和非基于事件的保留的权限。服务器的行为可能会使设置ACE4_WRITE_属性允许ACE4_WRITE_保留。
ACE4_WRITE_RETENTION_HOLD
ACE4_写入_保留_保持
Operation(s) affected:
受影响的行动：
SETATTR of retention_hold.
设置保留的属性。
Discussion:
讨论：
Permission to modify the administration retention holds. A server MAY map ACE4_WRITE_ATTRIBUTES to ACE_WRITE_RETENTION_HOLD.
修改管理保留的权限保留。服务器可以将ACE4_WRITE_属性映射到ACE_WRITE_RETENTION_HOLD。
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, dacl, or sacl
获取acl、dacl或sacl的属性
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.1 server on behalf of the client.
将文件对象用作进程间通信的同步原语的权限。NFSv4.1服务器不代表客户端强制或解释此权限。
Typically, the ACE4_SYNCHRONIZE permission is only meaningful on local file systems, i.e., file systems not accessed via NFSv4.1. The reason that the permission bit exists is that some operating environments, such as Windows, use ACE4_SYNCHRONIZE.
通常，ACE4_SYNCHRONIZE权限仅在本地文件系统上有意义，即未通过NFSv4.1访问的文件系统。权限位存在的原因是某些操作环境（如Windows）使用ACE4\u同步。
For example, if a client copies a file that has ACE4_SYNCHRONIZE set from a local file system to an NFSv4.1 server, and then later copies the file from the NFSv4.1 server
例如，如果客户端将设置了ACE4_SYNCHRONIZE的文件从本地文件系统复制到NFSv4.1服务器，然后再从NFSv4.1服务器复制该文件
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.1 server has the means to set the ACE4_SYNCHRONIZE bit. The second copy will not have the permission set unless the NFSv4.1 server has the means to retrieve the ACE4_SYNCHRONIZE bit.
对于本地文件系统，如果在原始文件中设置了ACE4_SYNCHRONIZE，则客户端可能希望在第二个副本中设置它。除非NFSv4.1服务器具有设置ACE4_同步位的方法，否则第一个副本将不会设置权限。除非NFSv4.1服务器具有检索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 [20]. 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_写入_数据（修改现有内容的能力）；两个掩码都将绑定到一个“写入”权限[20]。当这样的服务器将属性返回给客户机时，它将显示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 one 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_INHERITED_ACE = 0x00000080;
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_INHERITED_ACE = 0x00000080;
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 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.
例如，假设客户机尝试使用ACE4\u文件\u继承\u ACE集设置ACE，但不使用ACE4\u目录\u继承\u ACE。如果服务器不支持任何形式的ACL继承，则服务器应使用NFS4ERR_ATTRNOTSUPP拒绝请求。如果服务器支持应用于文件和目录的单个“继承ACE”标志，则服务器可能会拒绝该请求（即，要求客户端同时设置文件和目录继承标志）。服务器也可以接受请求并静默地打开ACE4\u目录\u继承\u ACE标志。
ACE4_FILE_INHERIT_ACE Any non-directory file in any sub-directory 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_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_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 ACE4_FILE_INHERIT_ACE and ACE4_DIRECTORY_INHERIT_ACE flags.
ACE4_INHERIT_ONLY_ACE可放置在目录上，但不适用于该目录；具有此位集的允许和拒绝ACE不会影响对目录的访问，并且具有此位集的审核和报警ACE不会触发日志或报警事件。此类ACE仅在应用于（清除此位）由ACE4_文件_继承_ACE和ACE4_目录_继承_ACE标志指定的新创建的文件和目录后生效。
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.
如果ACE上存在此标志，但既不存在ACE4_目录_继承_ACE，也不存在ACE4_文件_继承_ACE，则尝试设置此类属性的操作应失败，并出现NFS4ERR_ATTRNOTSUPP。
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 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 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.
ACE4_失败访问_ACE_标志ACE4_成功访问_ACE_标志（成功）和ACE4_失败访问_ACE_标志（失败）位只能在ACE4_系统审计_ACE_类型（审计）和ACE4_系统报警_ACE类型（报警）ACE类型上设置。如果在处理文件的ACL期间，服务器遇到与尝试打开的主体匹配的审核或报警ACE，则服务器会注意到该事实以及审核或报警ACE中遇到的成功和失败标志（如果有）。服务器完成ACL处理后，会记录操作是成功还是失败。如果操作成功，并且为匹配的审核或报警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节中概述的特殊标识符之一。
ACE4_INHERITED_ACE Indicates that this ACE is inherited from a parent directory. A server that supports automatic inheritance will place this flag on any ACEs inherited from the parent directory when creating a new object. Client applications will use this to perform automatic inheritance. Clients and servers MUST clear this bit in the acl attribute; it may only be used in the dacl and sacl attributes.
ACE4_INHERITED_ACE表示此ACE从父目录继承。当创建新对象时，支持自动继承的服务器将在从父目录继承的任何ACE上放置此标志。客户端应用程序将使用它来执行自动继承。客户端和服务器必须清除acl属性中的该位；它只能在dacl和sacl属性中使用。
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的“谁”字段是一个标识符，用于指定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 understands 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 4
表4
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 dacl attribute is like the acl attribute, but dacl allows just ALLOW and DENY ACEs. The dacl attribute supports automatic inheritance (see Section 6.4.3.2).
dacl属性类似于acl属性，但dacl只允许允许和拒绝ACE。dacl属性支持自动继承（参见第6.4.3.2节）。
The sacl attribute is like the acl attribute, but sacl allows just AUDIT and ALARM ACEs. The sacl attribute supports automatic inheritance (see Section 6.4.3.2).
sacl属性与acl属性类似，但sacl只允许审核和报警ACE。sacl属性支持自动继承（参见第6.4.3.2节）。
The NFSv4.1 mode attribute is based on the UNIX mode bits. The following bits are defined:
NFSv4.1模式属性基于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_ROTH = 0x004; /* read permission: other */
const MODE4_WOTH = 0x002; /* write permission: other */
const MODE4_XOTH = 0x001; /* execute permission: other */
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 */
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 a 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 mode_set_masked attribute is a write-only attribute that allows individual bits in the mode attribute to be set or reset, without changing others. It allows, for example, the bits MODE4_SUID, MODE4_SGID, and MODE4_SVTX to be modified while leaving unmodified any of the nine low-order mode bits devoted to permissions.
mode_set_masked属性是一个只写属性，允许设置或重置mode属性中的各个位，而不更改其他位。例如，它允许修改位MODE4_SUID、MODE4_SGID和MODE4_SVTX，同时保留用于权限的九个低阶模式位中未修改的任何一个。
In such instances that the nine low-order bits are left unmodified, then neither the acl nor the dacl attribute should be automatically modified as discussed in Section 6.4.1.
在九个低阶位未被修改的情况下，acl和dacl属性都不应自动修改，如第6.4.1节所述。
The mode_set_masked attribute consists of two words, each in the form of a mode4. The first consists of the value to be applied to the current mode value and the second is a mask. Only bits set to one in the mask word are changed (set or reset) in the file's mode. All other bits in the mode remain unchanged. Bits in the first word that correspond to bits that are zero in the mask are ignored, except that undefined bits are checked for validity and can result in NFS4ERR_INVAL as described below.
mode_set_masked属性由两个单词组成，每个单词的形式为mode4。第一个由应用于当前模式值的值组成，第二个是掩码。在文件模式下，仅更改（设置或重置）掩码字中设置为1的位。模式中的所有其他位保持不变。忽略第一个字中对应于掩码中零位的位，除非检查未定义位的有效性，并可能导致NFS4ERR_INVAL，如下所述。
The mode_set_masked attribute is only valid in a SETATTR operation. If it is used in a CREATE or OPEN operation, the server MUST return NFS4ERR_INVAL.
mode_set_masked属性仅在SETATTR操作中有效。如果在创建或打开操作中使用，服务器必须返回NFS4ERR_INVAL。
Bits not defined as valid in the mode attribute are not valid in either word of the mode_set_masked attribute. The server MUST return NFS4ERR_INVAL if any such bits are set to one in a SETATTR. If the mode and mode_set_masked attributes are both specified in the same SETATTR, the server MUST also return NFS4ERR_INVAL.
在mode属性中未定义为有效的位在mode_set_masked属性的任何一个字中都无效。如果SETATTR中的任何此类位设置为1，服务器必须返回NFS4ERR_INVAL。如果mode和mode_set_masked属性都在同一SETATTR中指定，则服务器还必须返回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 might 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 access 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 the 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_read_数据并允许用户执行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不允许的方式读取或写入数据或元数据。
o A retention attribute might also block access otherwise allowed by ACLs (see Section 5.13).
o 保留属性还可能阻止ACL允许的访问（请参阅第5.13节）。
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 enforce it. In general, but especially in these situations, the client needs to do its part in the enforcement of access as defined by the ACL. To do this, the client MAY send the appropriate ACCESS operation prior
客户机必须知道对象的ACL将定义特定访问权限的情况，即使服务器不会强制执行该访问权限。一般来说，但特别是在这些情况下，客户机需要按照ACL的定义在访问的实施中发挥作用。要做到这一点，客户机可以在访问之前发送适当的访问操作
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 doesn't enforce, see Section 6.3.1.1.
为用户或应用程序的请求提供服务，以确定是否应授予用户或应用程序所请求的访问权限。有关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, respectively, the user, group, and other, 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@". This way, the client can see if semantically equivalent access permissions exist whether the client asks for the owner, owner_group, and mode attributes or for just the ACL.
同时支持mode和ACL的服务器必须注意将MODE4_*USR、MODE4_*GRP和MODE4_*OTH位与具有各自who字段“所有者”、“组”和“所有人”的ACE同步。通过这种方式，客户机可以查看是否存在语义等价的访问权限，无论客户机是请求所有者、所有者组和模式属性，还是仅请求ACL。
In this section, much is made of the methods in Section 6.3.2. Many requirements refer to this section. 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 (1003.1e draft 17), rather than by actual permissions on owner, group, and other.
本节主要介绍第6.3.2节中的方法。许多要求涉及本节。但是请注意，这些方法具有用“应该”指定的行为。这是有意的，以避免使根据撤销的POSIX ACL草案（1003.1e草案17）计算模式的现有实现无效，而不是通过所有者、组和其他用户的实际权限。
In the case where a server supports the sacl or dacl attribute, in addition to the acl attribute, the server MUST fail a request to set the acl attribute simultaneously with a dacl or sacl attribute. The error to be given is NFS4ERR_ATTRNOTSUPP.
在服务器支持sacl或dacl属性的情况下，除了acl属性外，服务器还必须使设置acl属性和dacl或sacl属性的请求失败。要给出的错误是NFS4ERR_ATTRNOTSUPP。
When any of the nine low-order mode bits are subject to change, either because the mode attribute was set or because the mode_set_masked attribute was set and the mask included one or more bits from the nine low-order mode bits, and no ACL attribute is explicitly set, the acl and dacl attributes 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和dacl属性必须根据这些位的更新值进行修改。即使低阶位的值在模式设置后与之前相同，也必须发生这种情况。
Note that any AUDIT or ALARM ACEs (hence any ACEs in the sacl attribute) are unaffected by changes to the mode.
请注意，任何审核或报警ACE（因此sacl属性中的任何ACE）不受模式更改的影响。
In cases in which the permissions bits are subject to change, the acl and dacl attributes MUST be modified such that the mode computed via the method 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 attribute change. The ACL attributes SHOULD also be modified such that:
在权限位可能发生更改的情况下，必须修改acl和dacl属性，以便通过第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 type 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 and dacl, 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和dacl来满足该要求，而使用表示模式且仅表示模式的acl。这是允许的，但服务器最好在不违反上述要求的情况下保留尽可能多的ACL。丢弃ACL实际上使使用mode属性创建的文件无法继承ACL（请参阅第6.4.3节）。
When setting the acl or dacl and not setting the mode or mode_set_masked attributes, 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 in Section 6.3.2. The three high-order bits of the mode (MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged.
当设置acl或dacl而不设置mode或mode_set_masked属性时，需要从acl派生模式的权限位。在这种情况下，ACL属性应按给定值设置。必须修改模式属性的九个低阶位（MODE4_R*、MODE4_W*、MODE4_X*），以匹配第6.3.2节中方法的结果。模式的三个高阶位（MODE4_SUID、MODE4_SGID、MODE4_SVTX）应保持不变。
When setting both the mode (includes use of either the mode attribute or the mode_set_masked attribute) and the acl or dacl attributes in the same operation, the attributes MUST be applied in this order: mode (or mode_set_masked), 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或dacl属性时，必须按以下顺序应用属性：模式（或模式设置屏蔽），然后是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 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属性，它可以使用父目录上的ACL属性来计算新创建对象的初始ACL属性。这将在本节中称为继承的ACL。将基于父目录ACL中ACE的一个或多个ACE添加到继承的ACL的行为在本节中称为继承ACE。
Implementors should standardize what the behavior of CREATE and OPEN must be depending on the presence or absence of the mode and ACL attributes.
实现者应该根据mode和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 (note that EXCLUSIVE4_1 is a better choice of createmode4, since it does permit initial attributes). 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的开放操作，则不应发生继承（请注意，EXCLUSIVE4_1是createmode4的更好选择，因为它允许初始属性）。相反，服务器应该设置权限以拒绝对新创建的对象的所有访问。预期适当的客户端将在后续的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 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, dacl, or sacl attributes are implementation defined. If either the dacl or sacl attribute is supported, then the ACL4_DEFAULTED flag SHOULD be set on the newly created attributes.
在其他情况下，应该进行继承，并且不会对ACL进行任何修改。如果支持模式属性，则必须按照第6.3.2节中的计算，清除MODE4_SUID、MODE4_SGID和MODE4_SVTX位。如果父目录上不存在可继承的ACE，则创建acl、dacl或sacl属性的规则由实现定义。如果支持dacl或sacl属性，则应在新创建的属性上设置ACL4_默认标志。
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, that is, 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. (In the case of a dacl or sacl attribute, both of those ACEs SHOULD also have the ACE4_INHERITED_ACE flag set.)
创建新目录时，服务器可以将任何既可继承又有效的继承ACE（换句话说，既没有ACE4_INHERIT_ONLY_ACE，也没有ACE4_NO_PROPAGATE_INHERIT_ACE集）拆分为两个ACE，一个没有继承标志，另一个有ACE4_INHERIT_ONLY_ACE集。（对于dacl或sacl属性，这两个ACE还应设置ACE4_继承_ACE标志。）
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。
The acl attribute consists only of an array of ACEs, but the sacl (Section 6.2.3) and dacl (Section 6.2.2) attributes also include an additional flag field.
acl属性仅由ACE数组组成，但sacl（第6.2.3节）和dacl（第6.2.2节）属性还包括一个附加的标志字段。
struct nfsacl41 {
aclflag4 na41_flag;
nfsace4 na41_aces<>;
};
struct nfsacl41 {
aclflag4 na41_flag;
nfsace4 na41_aces<>;
};
The flag field applies to the entire sacl or dacl; three flag values are defined:
标志字段适用于整个sacl或dacl；定义了三个标志值：
const ACL4_AUTO_INHERIT = 0x00000001;
const ACL4_PROTECTED = 0x00000002;
const ACL4_DEFAULTED = 0x00000004;
const ACL4_AUTO_INHERIT = 0x00000001;
const ACL4_PROTECTED = 0x00000002;
const ACL4_DEFAULTED = 0x00000004;
and all other bits must be cleared. The ACE4_INHERITED_ACE flag may be set in the ACEs of the sacl or dacl (whereas it must always be cleared in the acl).
所有其他位都必须清除。ACE4_继承的_ACE标志可以在sacl或dacl的ACE中设置（但必须始终在acl中清除）。
Together these features allow a server to support automatic inheritance, which we now explain in more detail.
这些特性一起允许服务器支持自动继承，我们现在将更详细地解释这一点。
Inheritable ACEs are normally inherited by child objects only at the time that the child objects are created; later modifications to inheritable ACEs do not result in modifications to inherited ACEs on descendants.
可继承的ACE通常仅在创建子对象时由子对象继承；以后对可继承ACE的修改不会导致对后代上继承的ACE的修改。
However, the dacl and sacl provide an OPTIONAL mechanism that allows a client application to propagate changes to inheritable ACEs to an entire directory hierarchy.
但是，dacl和sacl提供了一种可选机制，允许客户端应用程序将对可继承ACE的更改传播到整个目录层次结构。
A server that supports this performs inheritance at object creation time in the normal way, and SHOULD set the ACE4_INHERITED_ACE flag on any inherited ACEs as they are added to the new object.
支持此功能的服务器在对象创建时以正常方式执行继承，并应在将任何继承的ACE添加到新对象时在其上设置ACE4_INHERITED_ACE标志。
A client application such as an ACL editor may then propagate changes to inheritable ACEs on a directory by recursively traversing that directory's descendants and modifying each ACL encountered to remove any ACEs with the ACE4_INHERITED_ACE flag and to replace them by the new inheritable ACEs (also with the ACE4_INHERITED_ACE flag set). It uses the existing ACE inheritance flags in the obvious way to decide
然后，客户端应用程序（如ACL编辑器）可以通过递归遍历目录的子体并修改遇到的每个ACL来将更改传播到目录上的可继承ACE，以删除带有ACE4_继承的_ACE标志的任何ACE，并将其替换为新的可继承ACE（也带有ACE4_继承的_ACE标志集）。它以显而易见的方式使用现有ACE继承标志来决定
which ACEs to propagate. (Note that it may encounter further inheritable ACEs when descending the directory hierarchy and that those will also need to be taken into account when propagating inheritable ACEs to further descendants.)
它可以传播。（请注意，在降低目录层次结构时，它可能会遇到更多可继承的ACE，并且在将可继承的ACE传播到更多后代时，也需要考虑这些ACE。）
The reach of this propagation may be limited in two ways: first, automatic inheritance is not performed from any directory ACL that has the ACL4_AUTO_INHERIT flag cleared; and second, automatic inheritance stops wherever an ACL with the ACL4_PROTECTED flag is set, preventing modification of that ACL and also (if the ACL is set on a directory) of the ACL on any of the object's descendants.
此传播的范围可能受到两种方式的限制：首先，不会从清除了ACL4\u AUTO\u INHERIT标志的任何目录ACL执行自动继承；第二，只要设置了具有ACL4_PROTECTED标志的ACL，自动继承就会停止，从而防止修改该ACL以及（如果ACL设置在目录上）对象的任何子体上的ACL。
This propagation is performed independently for the sacl and the dacl attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may be independently set for the sacl and the dacl, and propagation of one type of acl may continue down a hierarchy even where propagation of the other acl has stopped.
该传播针对sacl和dacl属性独立执行；因此，可以为sacl和dacl独立地设置ACL4_AUTO_INHERIT和ACL4_PROTECTED标志，并且一种类型的acl的传播可以沿着层次结构继续下去，即使在另一acl的传播已经停止的情况下。
New objects should be created with a dacl and a sacl that both have the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to the same value as that on, respectively, the sacl or dacl of the parent object.
应使用dacl和sacl创建新对象，这两个dacl都清除了ACL4_受保护标志，并且ACL4_自动_继承标志分别设置为与父对象的sacl或dacl相同的值。
Both the dacl and sacl attributes are RECOMMENDED, and a server may support one without supporting the other.
建议同时使用dacl和sacl属性，并且服务器可能支持其中一个而不支持另一个。
A server that supports both the old acl attribute and one or both of the new dacl or sacl attributes must do so in such a way as to keep all three attributes consistent with each other. Thus, the ACEs reported in the acl attribute should be the union of the ACEs reported in the dacl and sacl attributes, except that the ACE4_INHERITED_ACE flag must be cleared from the ACEs in the acl. And of course a client that queries only the acl will be unable to determine the values of the sacl or dacl flag fields.
同时支持旧acl属性和一个或两个新dacl或sacl属性的服务器必须这样做，以保持所有三个属性彼此一致。因此，acl属性中报告的ACE应该是dacl和sacl属性中报告的ACE的并集，但ACE4_继承的_ACE标志必须从acl中的ACE中清除。当然，只查询acl的客户端将无法确定sacl或dacl标志字段的值。
When a client performs a SETATTR for the acl attribute, the server SHOULD set the ACL4_PROTECTED flag to true on both the sacl and the dacl. By using the acl attribute, as opposed to the dacl or sacl attributes, the client signals that it may not understand automatic inheritance, and thus cannot be trusted to set an ACL for which automatic inheritance would make sense.
当客户端对acl属性执行SETATTR时，服务器应在sacl和dacl上将ACL4\u PROTECTED标志设置为true。通过使用acl属性，而不是dacl或sacl属性，客户机发出信号，表明它可能不理解自动继承，因此无法信任它设置自动继承有意义的acl。
When a client application queries an ACL, modifies it, and sets it again, it should leave any ACEs marked with ACE4_INHERITED_ACE unchanged, in their original order, at the end of the ACL. If the application is unable to do this, it should set the ACL4_PROTECTED
当客户机应用程序查询、修改并再次设置ACL时，它应在ACL末尾保留标记为ACE4_继承_ACE的所有ACE，并保持其原始顺序不变。如果应用程序无法执行此操作，则应将ACL4\u设置为受保护
flag. This behavior is not enforced by servers, but violations of this rule may lead to unexpected results when applications perform automatic inheritance.
旗帜服务器不强制执行此行为，但当应用程序执行自动继承时，违反此规则可能会导致意外结果。
If a server also supports the mode attribute, it SHOULD set the mode in such a way that leaves inherited ACEs unchanged, in their original order, at the end of the ACL. If it is unable to do so, it SHOULD set the ACL4_PROTECTED flag on the file's dacl.
如果服务器还支持mode属性，则应设置模式，使继承的ACE在ACL末尾保持原始顺序不变。如果无法执行此操作，则应在文件的dacl上设置ACL4_PROTECTED标志。
Finally, in the case where the request that creates a new file or directory does not also set permissions for that file or directory, and there are also no ACEs to inherit from the parent's directory, then the server's choice of ACL for the new object is implementation-dependent. In this case, the server SHOULD set the ACL4_DEFAULTED flag on the ACL it chooses for the new object. An application performing automatic inheritance takes the ACL4_DEFAULTED flag as a sign that the ACL should be completely replaced by one generated using the automatic inheritance rules.
最后，如果创建新文件或目录的请求没有为该文件或目录设置权限，并且也没有要从父目录继承的ACE，那么服务器为新对象选择ACL取决于实现。在这种情况下，服务器应该在为新对象选择的ACL上设置ACL4_默认标志。执行自动继承的应用程序将ACL4_default标志作为一个标志，表明ACL应完全替换为使用自动继承规则生成的ACL。
This section describes the NFSv4 single-server namespace. Single-server namespaces may be presented directly to clients, or they may be used as a basis to form larger multi-server namespaces (e.g., site-wide or organization-wide) to be presented to clients, as described in Section 11.
本节介绍NFSv4单服务器命名空间。如第11节所述，单服务器名称空间可以直接呈现给客户端，也可以用作形成更大的多服务器名称空间（例如，站点范围或组织范围）的基础，以呈现给客户端。
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 sent a string that identified the export name within the namespace and the server returned the root filehandle for that export. The MOUNT protocol also provided an EXPORTS procedure that enumerated the server's exports.
在UNIX服务器上，命名空间描述根目录或“/”下的路径名可访问的所有文件。在Windows服务器上，名称空间由磁盘上以映射的磁盘字母命名的所有文件组成。NFS服务器管理员很少使整个服务器的文件系统命名空间可供NFS客户端使用。更常见的情况是，命名空间的某些部分通过“导出”功能提供。在以前版本的NFS协议中，每次导出的根文件句柄都是通过MOUNT协议获得的；客户端发送了一个字符串，该字符串标识命名空间中的导出名称，服务器返回该导出的根文件句柄。装载协议还提供了一个导出过程，该过程枚举服务器的导出。
The NFSv4.1 protocol provides a root filehandle that clients can use to obtain filehandles for the exports of a particular server, via a series of LOOKUP operations within a COMPOUND, to traverse a path. A common user experience is to use a graphical user interface (perhaps
NFSv4.1协议提供了一个根文件句柄，客户机可以使用该根文件句柄，通过一系列复合内的查找操作来获取特定服务器导出的文件句柄，从而遍历路径。常见的用户体验是使用图形用户界面（可能是
a file "Open" dialog window) to find a file via progressive browsing 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 NFSv3 protocol. In NFSv3, 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.
NFSv3协议不支持这种浏览方式。在NFSv3中，客户端希望所有查找操作都保留在单个服务器文件系统中。例如，设备属性不会更改。这将防止客户端采用跨越导出的命名空间路径。
In the case of 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 directories that might be constructed similarly to an NFSv4.1 "pseudo file system" (see Section 7.3) 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.
对于NFSv3，客户机上的自动挂载程序可以使用挂载协议的导出过程获取服务器名称空间的快照。如果它理解服务器的路径名语法，就可以在客户端上创建服务器名称空间的映像。服务器未导出的命名空间部分由目录填充，这些目录的构造可能类似于NFSv4.1“伪文件系统”（参见第7.3节），允许用户从一个装入的文件系统浏览到另一个装入的文件系统。这种在客户端上表示服务器名称空间的方法有一个缺点：它是静态的。如果服务器管理员添加了一个新的导出，客户端将不知道它。
NFSv4.1 servers avoid this namespace inconsistency by presenting all the exports for a given server within the framework of a single namespace for that server. An NFSv4.1 client uses LOOKUP and READDIR operations to browse seamlessly from one export to another.
NFSv4.1服务器通过在给定服务器的单个名称空间框架内呈现该服务器的所有导出来避免这种名称空间不一致。NFSv4.1客户端使用查找和READDIR操作从一个导出无缝浏览到另一个导出。
Where there are portions of the server namespace that are not exported, clients require some way of traversing those portions to reach actual exported file systems. A technique that servers may use to provide for this is to bridge the unexported portion of the namespace 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.
当服务器名称空间的某些部分未导出时，客户端需要以某种方式遍历这些部分以到达实际导出的文件系统。服务器可以使用的一种技术是通过“伪文件系统”桥接名称空间的未报告部分，该系统只提供导出目录的视图。伪文件系统具有唯一的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 is considered a separate entity and therefore MUST have its own fsid, unique among all the fsids for that server.
每个伪文件系统都被视为一个单独的实体，因此必须有自己的fsid，在该服务器的所有fsid中是唯一的。
Certain operating environments are sometimes described as having "multiple roots". In such environments, individual file systems are commonly represented by disk or volume 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.
某些操作环境有时被描述为具有“多根”。在这种环境中，单个文件系统通常由磁盘或卷名表示。这些平台的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 series of LOOKUP operations) when receiving an error of NFS4ERR_FHEXPIRED.
服务器伪文件系统的本质是，它是服务器上可用的文件系统的逻辑表示。因此，伪文件系统最有可能在服务器第一次实例化时动态构建。预计伪文件系统可能没有可用于构造持久化文件句柄的磁盘上副本。尽管服务器最好为伪文件系统提供持久的文件句柄，但NFS客户机应该认为伪文件系统文件句柄是易变的。这可以通过检查相关文件句柄的“fh\u expire\u type”属性来确认。如果文件句柄是易失性的，则NFS客户端必须准备在接收到NFS4ERR_错误时恢复文件句柄值（例如，通过一系列查找操作）。
Because it is quite likely that servers will implement pseudo file systems using volatile filehandles, clients need to be prepared for them, rather than assuming that all filehandles will be persistent.
因为服务器很可能会使用易失性文件句柄实现伪文件系统，所以客户端需要为它们做好准备，而不是假设所有文件句柄都是持久的。
If the server's root file system is exported, one might conclude that a pseudo file system is unneeded. This is not necessarily so. Assume the following file systems on a server:
如果导出服务器的根文件系统，可能会得出不需要伪文件系统的结论。事实未必如此。假设服务器上有以下文件系统：
/ fs1 (exported)
/a fs2 (not exported)
/a/b fs3 (exported)
/ fs1 (exported)
/a fs2 (not exported)
/a/b fs3 (exported)
Because fs2 is not exported, fs3 cannot be reached with simple LOOKUPs. The server must bridge the gap with a pseudo file system.
由于fs2未导出，因此无法通过简单的查找访问fs3。服务器必须使用伪文件系统来弥补这一差距。
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:
此服务器的伪文件系统的构造如下所示：
/ (place holder/not exported)
/a/b (file system 1)
/a/b/c/d (file system 2)
/ (place holder/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 root 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 and SECINFO_NONAME, 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和SECINFO_NONAME来更改所使用的安全机制，因此在确定允许使用的安全机制后，服务器不应基于客户端使用的安全机制呈现不同的命名空间视图。相反，如果试图使用不适当的安全机制访问数据，它应该提供一致的视图并返回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:
如果出于安全考虑，需要隐藏特定文件系统的存在，而不是其中的所有数据，则服务器可以将服务器命名空间中共享资源的安全策略应用于资源祖先的组件。例如：
/ (place holder/not exported)
/a/b (file system 1)
/a/b/MySecretProject (file system 2)
/ (place holder/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 the 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.
如果担心网络上数据的安全性，客户端应使用强大的安全机制访问伪文件系统，以防止中间人攻击。
Integrating locking into the NFS protocol necessarily causes it to be stateful. With the inclusion of such features as share reservations, file and directory delegations, recallable layouts, and support for mandatory byte-range locking, the protocol becomes substantially more dependent on proper management of state than the traditional combination of NFS and NLM (Network Lock Manager) [46]. These features include expanded locking facilities, which provide some measure of inter-client exclusion, but the state also offers features not readily providable using a stateless model. There are three components to making this state manageable:
将锁定集成到NFS协议中必然会导致它是有状态的。由于包含了共享保留、文件和目录委派、可重新调用的布局以及对强制字节范围锁定的支持等功能，与NFS和NLM（网络锁管理器）的传统组合相比，协议实质上更加依赖于正确的状态管理[46]。这些特性包括扩展的锁定功能，这些功能提供了某种程度的客户端间排除，但该州也提供了使用无状态模型不容易提供的特性。要使此状态易于管理，有三个组件：
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开始。
A client must establish a client ID (see Section 2.4) and then one or more sessionids (see Section 2.10) before performing any operations to open, byte-range lock, delegate, or obtain a layout for a file object. Each session ID is associated with a specific client ID, and thus serves as a shorthand reference to an NFSv4.1 client.
在执行任何打开、字节范围锁定、委托或获取文件对象布局的操作之前，客户端必须先建立客户端ID（请参见第2.4节），然后建立一个或多个SessionID（请参见第2.10节）。每个会话ID都与特定的客户端ID相关联，因此用作NFSv4.1客户端的速记引用。
For some types of locking interactions, the client will represent some number of internal locking entities called "owners", which normally correspond to processes internal to the client. For other types of locking-related objects, such as delegations and layouts, no such intermediate entities are provided for, and the locking-related objects are considered to be transferred directly between the server and a unitary client.
对于某些类型的锁定交互，客户机将表示一些称为“所有者”的内部锁定实体，这些实体通常对应于客户机内部的流程。对于其他类型的锁定相关对象，例如委托和布局，不提供此类中间实体，并且锁定相关对象被认为是在服务器和单一客户端之间直接传输的。
When the server grants a lock of any type (including opens, byte-range locks, delegations, and layouts), 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 and layouts 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
当服务器授予任何类型的锁（包括打开、字节范围锁、委派和布局）时，它将使用唯一的stateid进行响应，该stateid表示同一文件、同一类型和共享相同所有权特征的一组锁（通常是单个锁）。因此，由不同的打开所有者打开的同一个文件都有一个标识stateid。类似地，特定锁所有者拥有的文件上的每一组字节范围锁都有自己的标识stateid。委托和布局还具有关联的stateID，可以通过它们进行引用。stateid用作一个锁或一组锁的简写引用，并且给定stateid，服务器可以确定关联的状态所有者或状态所有者
(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关联的文件句柄。
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 8.3 for a discussion of the lease.
与给定客户机ID关联的所有StateID都与一个公共租约关联，该租约表示这些StateID及其表示的要由服务器维护的对象的声明。有关租赁的讨论，请参见第8.3节。
The server may assign stateids independently for different clients. A stateid with the same bit pattern for one client may designate an entirely different set of locks for a different client. The stateid is always interpreted with respect to the client ID associated with the current session. Stateids apply to all sessions associated with the given client ID, and the client may use a stateid obtained from one session on another session associated with the same client ID.
服务器可以为不同的客户端独立分配StateID。一个客户端具有相同位模式的stateid可能会为不同的客户端指定一组完全不同的锁。stateid始终根据与当前会话关联的客户端ID进行解释。stateid应用于与给定客户机ID关联的所有会话，并且客户机可以在与相同客户机ID关联的另一个会话上使用从一个会话获得的stateid。
With the exception of special stateids (see Section 8.2.3), each stateid represents locking objects of one of a set of types defined by the NFSv4.1 protocol. Note that in all these cases, where we speak of guarantee, it is understood there are situations such as a client restart, or lock revocation, that allow the guarantee to be voided.
除特殊stateid（见第8.2.3节）外，每个stateid表示NFSv4.1协议定义的一组类型之一的锁定对象。请注意，在所有这些情况下，当我们谈到担保时，可以理解存在允许担保无效的情况，例如客户端重新启动或锁撤销。
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 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 modify a particular file, until the delegation is returned. In NFSv4.1, file delegations may be obtained on both regular and non-regular files.
o StateID可以表示文件委托，这是服务器向客户机提供的可重新调用的保证，在委托返回之前，其他客户机不会引用或修改特定文件。在NFSv4.1中，可以在常规文件和非常规文件上获得文件授权。
A stateid represents a single delegation held by a client for a particular filehandle.
stateid表示客户端为特定文件句柄持有的单个委托。
o Stateids may represent directory delegations, which are recallable guarantees by the server to the client that other clients will not modify the directory, until the delegation is returned.
o StateID可以表示目录委托，这是服务器向客户机提供的可重新调用的保证，在委托返回之前，其他客户机不会修改目录。
A stateid represents a single delegation held by a client for a particular directory filehandle.
stateid表示客户端为特定目录文件句柄持有的单个委托。
o Stateids may represent layouts, which are recallable guarantees by the server to the client that particular files may be accessed via an alternate data access protocol at specific locations. Such access is limited to particular sets of byte-ranges and may proceed until those byte-ranges are reduced or the layout is returned.
o StateID可以表示布局，这是服务器向客户机提供的可重新调用的保证，即特定文件可以在特定位置通过备用数据访问协议访问。这种访问仅限于特定的字节范围集，并且可以继续进行，直到减少这些字节范围或返回布局。
A stateid represents the set of all layouts held by a particular client for a particular filehandle with a given layout type. The seqid is updated as the layouts of that set of byte-ranges change, via layout stateid changing operations such as LAYOUTGET and LAYOUTRETURN.
stateid表示特定客户端为具有给定布局类型的特定文件句柄保留的所有布局的集合。通过LAYOUTGET和LAYOUTRETURN等layout stateid更改操作，当该组字节范围的布局更改时，会更新seqid。
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 8.2.3), a particular value of the "other" field denotes a set of locks of the same type (for example, byte-range locks, opens, delegations, or layouts), 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, either by 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（见第8.2.3节）外，“其他”字段的特定值表示一组相同类型的锁（例如，字节范围锁、打开、委托或布局），用于特定文件或目录，并共享相同的所有权特征。seqid指定此类锁集合的特定实例，并递增以指示此类锁集合中的更改，通过从集合中添加或删除锁、更改其应用的字节范围或升级或降级一个或多个锁的类型。
When such a set of locks is first created, the server returns a stateid with seqid value of one. On subsequent operations that modify the set of locks, the server is required to increment the "seqid" field by one whenever it returns a stateid for the same state-owner/file/type combination and there is 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. This pattern continues until the seqid is incremented past NFS4_UINT32_MAX, and one (not zero) is the next seqid value.
当第一次创建这样一组锁时，服务器返回一个seqid值为1的stateid。在修改锁集的后续操作中，每当服务器返回同一状态所有者/文件/类型组合的stateid并且实际指定的锁集发生一些更改时，服务器都需要将“seqid”字段增加1。在这种情况下，服务器将返回一个stateid，其中包含一个“other”字段，与之前用于该状态所有者/文件/类型组合的字段相同，并包含一个递增的“seqid”字段。此模式将持续，直到seqid的增量超过NFS4_UINT32_MAX，并且一（不是零）是下一个seqid值。
The purpose of the incrementing of the seqid is to allow the server to communicate to the client the order in which operations that modified locking state associated with a stateid have been processed and to make it possible for the client to send requests that are conditional on the set of locks not having changed since the stateid in question was returned.
增加seqid的目的是允许服务器向客户机传达处理与stateid相关联的修改锁定状态的操作的顺序，并使客户机能够发送请求，该请求以自相关stateid之后未更改的锁集为条件他回来了。
Except for layout stateids (Section 12.5.3), when a client sends a stateid to the server, it has two choices with regard to the seqid sent. It may set the seqid to zero to indicate to the server that it wishes the most up-to-date seqid for that stateid's "other" field to be used. This would be the common choice in the case of a stateid sent with a READ or WRITE operation. It also may set a non-zero value, in which case the server checks if that seqid is the correct one. In that case, the server is required to return NFS4ERR_OLD_STATEID if the seqid is lower than the most current value and NFS4ERR_BAD_STATEID if the seqid is greater than the most current value. This would be the common choice in the case of stateids sent with a CLOSE or OPEN_DOWNGRADE. Because OPENs may be sent in parallel for the same owner, a client might close a file without knowing that an OPEN upgrade had been done by the server, changing the lock in question. If CLOSE were sent with a zero seqid, the OPEN upgrade would be cancelled before the client even received an indication that an upgrade had happened.
除了布局stateid（第12.5.3节），当客户机向服务器发送stateid时，对于发送的seqid，它有两个选择。它可以将seqid设置为零，以向服务器表明它希望使用该stateid的“其他”字段的最新seqid。在通过读或写操作发送stateid的情况下，这是常见的选择。它还可以设置一个非零值，在这种情况下，服务器会检查seqid是否正确。在这种情况下，如果seqid小于最新值，服务器需要返回NFS4ERR_OLD_STATEID；如果seqid大于最新值，服务器需要返回NFS4ERR_BAD_STATEID。这是发送带有关闭或打开降级的StateID时的常见选择。由于同一所有者的打开可以并行发送，因此客户端可能会在不知道服务器已完成打开的升级的情况下关闭文件，从而更改有问题的锁。如果CLOSE发送时带有零seqid，则在客户端收到升级发生的指示之前，OPEN升级将被取消。
When a stateid is sent by the server to the client as part of a callback operation, it is not subject to checking for a current seqid and returning NFS4ERR_OLD_STATEID. This is because the client is not in a position to know the most up-to-date seqid and thus cannot verify it. Unless specially noted, the seqid value for a stateid sent by the server to the client as part of a callback is required to be zero with NFS4ERR_BAD_STATEID returned if it is not.
当服务器将stateid作为回调操作的一部分发送到客户端时，它不需要检查当前seqid并返回NFS4ERR_OLD_stateid。这是因为客户无法知道最新的seqid，因此无法对其进行验证。除非特别说明，否则服务器作为回调的一部分发送到客户端的stateid的seqid值必须为零，如果不是，则返回NFS4ERR_BAD_stateid。
In making comparisons between seqids, both by the client in determining the order of operations and by the server in determining whether the NFS4ERR_OLD_STATEID is to be returned, the possibility of the seqid being swapped around past the NFS4_UINT32_MAX value needs to be taken into account. When two seqid values are being compared, the total count of slots for all sessions associated with the current client is used to do this. When one seqid value is less than this total slot count and another seqid value is greater than NFS4_UINT32_MAX minus the total slot count, the former is to be treated as lower than the latter, despite the fact that it is numerically greater.
在通过客户端确定操作顺序和服务器确定是否返回NFS4ERR_OLD_STATEID对seqid进行比较时，需要考虑seqid交换超过NFS4_UINT32_MAX值的可能性。比较两个seqid值时，将使用与当前客户端关联的所有会话的插槽总数来执行此操作。当一个seqid值小于该总时隙计数，而另一个seqid值大于NFS4_UINT32_MAX减去总时隙计数时，前者将被视为低于后者，尽管其数值较大。
Stateid values whose "other" field is either all zeros or all ones are reserved. They may 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值被保留。它们可能不由服务器分配，但具有协议定义的特殊含义。具体含义取决于“其他”字段是全零还是全一以及“seqid”字段的具体值。
The following combinations of "other" and "seqid" are defined in NFSv4.1:
NFSv4.1中定义了以下“其他”和“seqid”的组合：
o 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. This stateid MUST NOT be used on operations to data servers (Section 13.6).
o 当“other”和“seqid”均为零时，stateid被视为特殊的匿名stateid，可在读、写和SETATTR请求中使用，以指示不存在与请求相关的任何打开状态。当使用匿名stateid值且现有open拒绝请求的访问形式时，将拒绝对请求的访问。此stateid不得用于数据服务器的操作（第13.6节）。
o 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 operations. This stateid MUST NOT be used on operations to data servers.
o 当“other”和“seqid”都是1时，stateid是一个特殊的读取旁路stateid。在WRITE或SETATTR中使用此值时，它将被视为匿名值。在读取中使用时，服务器可能会授予访问权限，即使通常会拒绝对读取操作的访问。此stateid不能用于数据服务器的操作。
o When "other" is zero and "seqid" is one, the stateid represents the current stateid, which is whatever value is the last stateid returned by an operation within the COMPOUND. In the case of an OPEN, the stateid returned for the open file and not the delegation is used. The stateid passed to the operation in place of the special value has its "seqid" value set to zero, except when the current stateid is used by the operation CLOSE or OPEN_DOWNGRADE. If there is no operation in the COMPOUND that has returned a stateid value, the server MUST return the error NFS4ERR_BAD_STATEID. As illustrated in Figure 6, if the value of a current stateid is a special stateid and the stateid of an operation's arguments has "other" set to zero and "seqid" set to one, then the server MUST return the error NFS4ERR_BAD_STATEID.
o 当“other”为零且“seqid”为一时，stateid表示当前stateid，即复合内操作返回的最后一个stateid的值。在打开的情况下，将使用为打开的文件返回的stateid，而不是委托。传递给操作以代替特殊值的stateid的“seqid”值设置为零，除非操作关闭或打开降级使用当前stateid。如果化合物中没有返回stateid值的操作，服务器必须返回错误NFS4ERR\u BAD\u stateid。如图6所示，如果当前stateid的值是一个特殊的stateid，并且操作参数的stateid的“other”设置为零，“seqid”设置为一，那么服务器必须返回错误NFS4ERR_BAD_stateid。
o When "other" is zero and "seqid" is NFS4_UINT32_MAX, the stateid represents a reserved stateid value defined to be invalid. When this stateid is used, the server MUST return the error NFS4ERR_BAD_STATEID.
o 当“other”为零且“seqid”为NFS4_UINT32_MAX时，stateid表示定义为无效的保留stateid值。使用此stateid时，服务器必须返回错误NFS4ERR\u BAD\u stateid。
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. In the case of a special stateid designating the current stateid, the current stateid value substituted for the special stateid is associated with a particular client ID and filehandle, and so, if it is used where the current filehandle does not match that associated with the current stateid, the operation to which the stateid is passed will return NFS4ERR_BAD_STATEID.
与其他StateID不同，特殊StateID与单个客户端ID或文件句柄不关联，可以与所有有效的客户端ID和文件句柄一起使用。对于指定当前stateid的特殊stateid，替换特殊stateid的当前stateid值与特定客户端ID和文件句柄相关联，因此，如果在当前文件句柄与当前stateid不匹配的情况下使用该值，向其传递stateid的操作将返回NFS4ERR\u BAD\u stateid。
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 until the client frees it by using FREE_STATEID. 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, unless the client frees the stateids via the FREE_STATEID operation.
stateid必须保持有效，直到客户端重新启动或服务器重新启动，或者直到客户端通过关闭或删除返回与stateid关联的所有锁。如果锁因吊销而丢失，只要客户端ID有效，stateid将保持该已吊销状态的有效指定，直到客户端使用FREE_stateid将其释放。与字节范围锁关联的StateID是一个例外。即使LOCKU释放了所有剩余的锁，它们仍然有效，只要与它们关联的打开文件保持打开状态，除非客户端通过FREE_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 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, directory delegation, layout).
o stateid类型的指示（打开、字节范围锁定、文件委派、目录委派、布局）。
o the last "seqid" value returned corresponding to the current "other" value.
o 返回的最后一个“seqid”值与当前的“other”值相对应。
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 8.2.3 for a discussion of special stateids.)
有了这些信息，可以验证传入的stateid，并在必要时返回相应的错误。特殊和非特殊stateID分别处理。（有关特殊状态ID的讨论，请参见第8.2.3节。）
Note that stateids are implicitly qualified by the current client ID, as derived from the client ID associated with the current session. Note, however, that the semantics of the session will prevent stateids associated with a previous client or server instance from being analyzed by this procedure.
请注意，stateID由当前客户机ID隐式限定，该ID派生自与当前会话关联的客户机ID。但是，请注意，会话的语义将阻止此过程分析与以前的客户机或服务器实例关联的StateID。
If server restart has resulted in an invalid client ID or a session ID that is invalid, SEQUENCE will return an error and the operation that takes a stateid as an argument will never be processed.
如果服务器重新启动导致客户端ID无效或会话ID无效，SEQUENCE将返回错误，并且将永远不会处理以stateid为参数的操作。
If there has been a server restart where there is a persistent session and all leased state has been lost, then the session in question will, although valid, be marked as dead, and any operation not satisfied by means of the reply cache will receive the error NFS4ERR_DEADSESSION, and thus not be processed as indicated below.
如果在存在持久会话且所有租用状态均已丢失的情况下重新启动服务器，则所讨论的会话虽然有效，但将被标记为死会话，并且通过应答缓存未满足的任何操作将收到错误NFS4ERR_DEADSESSION，因此不会按如下所示进行处理。
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 special stateid is one designating the current stateid and there is a current stateid, then the current stateid is substituted for the special stateid and the checks appropriate to non-special stateids are performed.
o 如果特殊stateid是指定当前stateid的ID，并且存在当前stateid，则当前stateid将替换为特殊stateid，并执行适用于非特殊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.
当测试stateid时，“other”字段既不是全零也不是全1，可以使用以下过程验证传入的stateid并在必要时返回适当的错误，假设“other”字段将被划分为表索引和条目生成。
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 client ID in the table entry does not match the client ID associated with the current session, return NFS4ERR_BAD_STATEID.
o 如果表项中的客户端ID与当前会话关联的客户端ID不匹配，则返回NFS4ERR\u BAD\u STATEID。
o If the stateid represents revoked state, then return NFS4ERR_EXPIRED, NFS4ERR_ADMIN_REVOKED, or NFS4ERR_DELEG_REVOKED, as appropriate.
o 如果stateid表示吊销状态，则根据需要返回NFS4ERR_EXPIRED、NFS4ERR_ADMIN_reversed或NFS4ERR_DELEG_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, as would be reported by the TEST_STATEID operation, but be 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通常是有效的，如TEST_stateid操作所报告的，但对于特定操作无效，例如，当一个不代表字节范围锁的stateid被传递给非from_open LOCK或LOCKU时，或者当传递不代表打开的stateid以关闭或打开降级时。在这种情况下，服务器必须返回NFS4ERR_BAD_STATEID。
o If the "seqid" field is not zero and it is greater than the current sequence value corresponding to the current "other" field, return NFS4ERR_BAD_STATEID.
o 如果“seqid”字段不为零且大于当前“other”字段对应的当前序列值，则返回NFS4ERR_BAD_STATEID。
o If the "seqid" field is not zero and it is less than the current sequence value corresponding to the current "other" field, return NFS4ERR_OLD_STATEID.
o 如果“seqid”字段不为零且小于当前“other”字段对应的当前序列值，则返回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, e.g., open modes and byte-ranges.
o 否则，stateid是有效的，并且表条目应该包含关于stateid类型的任何附加信息以及与特定类型的stateid关联的信息，例如关联的锁集，例如打开所有者和锁所有者信息，以及关于特定锁的信息，例如打开模式和字节范围。
Clients performing 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. Note that the rules are slightly different in the case of I/O to data servers when file layouts are being used (see Section 13.9.1).
以下规则按优先级降低的顺序应用，用于管理适当stateid的选择。在遵循这些规则时，客户端只考虑通过实际操作响应或回调实际接收到通知的锁。请注意，当使用文件布局时，数据服务器的I/O规则略有不同（见第13.9.1节）。
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 open file in question SHOULD be used.
o 如果没有字节范围锁定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发送的。
Because each operation is associated with a session ID and from that the clientid can be determined, operations do not need to include a stateid for the server to be able to determine whether they should cause a delegation to be recalled or are to be treated as done within the scope of the delegation.
由于每个操作都与会话ID相关联，并且可以根据会话ID确定clientid，因此操作不需要包括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。
Each client/server pair, as represented by a client ID, has a single lease. The purpose of the lease is to allow the client to indicate to the server, in a low-overhead way, that it is active, and thus that the server is to retain the client's locks. This arrangement allows the server to remove stale locking-related objects that are held by a client that has crashed or is otherwise unreachable, once the relevant lease expires. This in turn allows other clients to obtain conflicting locks without being delayed indefinitely by inactive or unreachable clients. It is not a mechanism for cache consistency and lease renewals may not be denied if the lease interval has not expired.
每个客户机/服务器对（由客户机ID表示）都有一个租约。租约的目的是允许客户端以低开销的方式向服务器指示它处于活动状态，从而服务器将保留客户端的锁。这种安排允许服务器在相关租约到期后删除已崩溃或无法访问的客户端持有的过时锁定相关对象。这反过来又允许其他客户端获得冲突锁，而不会被非活动或无法访问的客户端无限期延迟。它不是缓存一致性的机制，如果租约间隔未过期，则租约续订可能不会被拒绝。
Since each session is associated with a specific client (identified by the client's client ID), any operation sent on that session is an indication that the associated client is reachable. When a request is sent for a given session, successful execution of a SEQUENCE operation (or successful retrieval of the result of SEQUENCE from the reply cache) on an unexpired lease will result in the lease being implicitly renewed, for the standard renewal period (equal to the lease_time attribute).
由于每个会话都与特定的客户端（由客户端的客户端ID标识）关联，因此在该会话上发送的任何操作都表示关联的客户端是可访问的。当为给定会话发送请求时，在未过期租约上成功执行序列操作（或从应答缓存中成功检索序列结果）将导致在标准续订期（等于租约时间属性）内隐式续订租约。
If the client ID's lease has not expired when the server receives a SEQUENCE operation, then the server MUST renew the lease. If the client ID's lease has expired when the server receives a SEQUENCE operation, the server MAY renew the lease; this depends on whether any state was revoked as a result of the client's failure to renew the lease before expiration.
如果服务器收到序列操作时客户端ID的租约尚未到期，则服务器必须续订租约。当服务器接收到序列操作时，如果客户端ID的租约已到期，则服务器可以续订租约；这取决于是否有任何状态因客户未能在租约到期前续订而被撤销。
Absent other activity that would renew the lease, a COMPOUND consisting of a single SEQUENCE operation will suffice. The client should also take communication-related delays into account and take steps to ensure that the renewal messages actually reach the server in good time. For example:
如果没有其他可以续租的活动，一个由单一序列操作组成的化合物就足够了。客户端还应考虑与通信相关的延迟，并采取措施确保续订消息实际及时到达服务器。例如：
o When trunking is in effect, the client should consider sending multiple requests on different connections, in order to ensure that renewal occurs, even in the event of blockage in the path used for one of those connections.
o 当集群生效时，客户端应该考虑在不同的连接上发送多个请求，以确保更新发生，即使在这些连接中使用的路径中阻塞的情况下。
o Transport retransmission delays might become so large as to approach or exceed the length of the lease period. This may be particularly likely when the server is unresponsive due to a restart; see Section 8.4.2.1. If the client implementation is not careful, transport retransmission delays can result in the client failing to detect a server restart before the grace period ends. The scenario is that the client is using a transport with exponential backoff, such that the maximum retransmission timeout exceeds both the grace period and the lease_time attribute. A network partition causes the client's connection's retransmission interval to back off, and even after the partition heals, the next transport-level retransmission is sent after the server has restarted and its grace period ends.
o 传输重新传输延迟可能变得如此之大，以至于接近或超过租赁期的长度。当服务器因重新启动而无响应时，这种情况尤其可能发生；见第8.4.2.1节。如果客户端实现不小心，传输重新传输延迟可能导致客户端无法在宽限期结束前检测到服务器重新启动。该场景是，客户端正在使用具有指数退避的传输，因此最大重新传输超时超过宽限期和lease_time属性。网络分区会导致客户端连接的重新传输间隔缩短，即使在分区恢复后，下一次传输级别的重新传输也会在服务器重新启动且宽限期结束后发送。
The client MUST either recover from the ensuing NFS4ERR_NO_GRACE errors or it MUST ensure that, despite transport-level retransmission intervals that exceed the lease_time, a SEQUENCE operation is sent that renews the lease before expiration. The client can achieve this by associating a new connection with the session, and sending a SEQUENCE operation on it. However, if the attempt to establish a new connection is delayed for some reason (e.g., exponential backoff of the connection establishment packets), the client will have to abort the connection establishment attempt before the lease expires, and attempt to reconnect.
客户端必须从随后出现的NFS4ERR_NO_GRACE错误中恢复，或者必须确保，尽管传输级别的重新传输间隔超过了租约时间，但仍会发送一个序列操作，在租约到期之前续订租约。客户机可以通过将新连接与会话关联，并在会话上发送序列操作来实现这一点。但是，如果由于某种原因（例如，连接建立数据包的指数退避）延迟了建立新连接的尝试，则客户端必须在租约到期之前中止建立连接的尝试，并尝试重新连接。
If the server renews the lease upon receiving a SEQUENCE operation, the server MUST NOT allow the lease to expire while the rest of the operations in the COMPOUND procedure's request are still executing.
如果服务器在收到序列操作后续订租约，则在复合过程请求中的其余操作仍在执行时，服务器不得允许租约过期。
Once the last operation has finished, and the response to COMPOUND has been sent, the server MUST set the lease to expire no sooner than the sum of current time and the value of the lease_time attribute.
完成最后一个操作并发送对component的响应后，服务器必须将租约设置为在当前时间和lease_time属性的值之和之前到期。
A client ID's lease can expire when it has been at least the lease interval (lease_time) since the last lease-renewing SEQUENCE operation was sent on any of the client ID's sessions and there are no active COMPOUND operations on any such sessions.
如果客户端ID的租约在任何客户端ID的会话上发送上次租约续订序列操作后至少达到租约间隔（租约时间），并且在任何此类会话上没有活动的复合操作，则客户端ID的租约可能会过期。
Because the SEQUENCE operation is the basic mechanism to renew a lease, and because it must be done at least once for each lease period, it is the natural mechanism whereby the server will inform the client of changes in the lease status that the client needs to be informed of. The client should inspect the status flags (sr_status_flags) returned by sequence and take the appropriate action (see Section 18.46.3 for details).
由于顺序操作是续订租约的基本机制，而且每个租约期必须至少执行一次，因此它是服务器通知客户端需要通知的租约状态更改的自然机制。客户应检查按顺序返回的状态标志（sr_status_flags），并采取适当的措施（详见第18.46.3节）。
o The status bits SEQ4_STATUS_CB_PATH_DOWN and SEQ4_STATUS_CB_PATH_DOWN_SESSION indicate problems with the backchannel that the client may need to address in order to receive callback requests.
o 状态位SEQ4_status_CB_PATH_DOWN和SEQ4_status_CB_PATH_DOWN_SESSION表示客户端可能需要解决的后通道问题，以便接收回调请求。
o The status bits SEQ4_STATUS_CB_GSS_CONTEXTS_EXPIRING and SEQ4_STATUS_CB_GSS_CONTEXTS_EXPIRED indicate problems with GSS contexts or RPCSEC_GSS handles for the backchannel that the client might have to address in order to allow callback requests to be sent.
o 状态位SEQ4_status_CB_GSS_CONTEXTS_EXPIRING和SEQ4_status_CB_GSS_CONTEXTS_EXPIRED表示客户端为了允许发送回调请求而可能必须处理的反向通道的GSS CONTEXTS或RPCSEC_GSS句柄存在问题。
o The status bits SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED, SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED, SEQ4_STATUS_ADMIN_STATE_REVOKED, and SEQ4_STATUS_RECALLABLE_STATE_REVOKED notify the client of lock revocation events. When these bits are set, the client should use TEST_STATEID to find what stateids have been revoked and use FREE_STATEID to acknowledge loss of the associated state.
o 状态位SEQ4_status_EXPIRED_ALL_STATE_reversed、SEQ4_EXPIRED_SOME_STATE_reversed、SEQ4_status_ADMIN_STATE_reversed和SEQ4_status_RECALLABLE_STATE_reversed通知客户端锁撤销事件。设置这些位后，客户端应使用TEST_STATEID查找已撤销的STATEID，并使用FREE_STATEID确认关联状态的丢失。
o The status bit SEQ4_STATUS_LEASE_MOVE indicates that responsibility for lease renewal has been transferred to one or more new servers.
o 状态位SEQ4_status_LEASE_MOVE表示租约续订的责任已转移到一个或多个新服务器。
o The status bit SEQ4_STATUS_RESTART_RECLAIM_NEEDED indicates that due to server restart the client must reclaim locking state.
o 状态位SEQ4_status_RESTART_reclain_NEEDED表示由于服务器重新启动，客户端必须恢复锁定状态。
o The status bit SEQ4_STATUS_BACKCHANNEL_FAULT indicates that the server has encountered an unrecoverable fault with the backchannel (e.g., it has lost track of a sequence ID for a slot in the backchannel).
o 状态位SEQ4_status_BACKCHANNEL_FAULT表示服务器遇到了无法恢复的反向通道故障（例如，它丢失了反向通道中插槽的序列ID）。
A critical 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. 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. Any that reach the server before the server can safely determine that the client has recovered enough locking state to be sure that such operations can be safely processed must be rejected. This will happen because either:
崩溃恢复中的一个关键要求是，客户端和服务器都知道另一方何时出现故障。此外，要求客户端在服务器重新启动时看到一致的数据视图。在客户端或网络缓冲区内排队的所有读写操作必须等待，直到客户端成功恢复保护读写操作的锁。必须拒绝在服务器能够安全地确定客户端已恢复足够的锁定状态以确保可以安全地处理此类操作之前到达服务器的任何操作。这将发生，因为：
o The state presented is no longer valid since it is associated with a now invalid client ID. In this case, the client will receive either an NFS4ERR_BADSESSION or NFS4ERR_DEADSESSION error, and any attempt to attach a new session to that invalid client ID will result in an NFS4ERR_STALE_CLIENTID error.
o 显示的状态不再有效，因为它与现在无效的客户端ID关联。在这种情况下，客户端将收到NFS4ERR_BADSESSION或NFS4ERR_DEADSESSION错误，任何尝试将新会话附加到该无效客户端ID的行为都将导致NFS4ERR_STALE_CLIENTID错误。
o Subsequent recovery of locks may make execution of the operation inappropriate (NFS4ERR_GRACE).
o 锁的后续恢复可能会导致操作执行不当（NFS4ERR_）。
In the event that a client fails, the server may release the client's locks when the associated lease has expired. Conflicting locks from another client may only be granted after this lease expiration. As discussed in Section 8.3, when a client has not failed and re-establishes its lease before expiration occurs, requests for conflicting locks will not be granted.
如果客户端出现故障，服务器可能会在相关租约到期时释放客户端的锁。来自其他客户端的冲突锁只能在此租约到期后授予。如第8.3节所述，当客户机未发生故障并在到期前重新建立其租约时，将不允许对冲突锁的请求。
To minimize client delay upon restart, lock requests are associated with an instance of the client by a client-supplied verifier. This verifier i