Internet Engineering Task Force (IETF) D. Noveck, Ed.
Request for Comments: 7931 HPE
Updates: 7530 P. Shivam
Category: Standards Track C. Lever
ISSN: 2070-1721 B. Baker
ORACLE
July 2016
Internet Engineering Task Force (IETF) D. Noveck, Ed.
Request for Comments: 7931 HPE
Updates: 7530 P. Shivam
Category: Standards Track C. Lever
ISSN: 2070-1721 B. Baker
ORACLE
July 2016
NFSv4.0 Migration: Specification Update
NFSv4.0迁移：规范更新
Abstract
摘要
The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0. This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC 7530.
NFSv4的迁移功能允许将单个文件系统的责任从一台服务器转移到另一台服务器，而不会中断客户端。最近的实现经验表明，NFSv4.0中此功能的现有规范存在问题。本文件确定了问题区域，并提供了修订后的规范文本，以更新RFC 7530中的NFSv4.0规范。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7931.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7931.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Data Type Definitions . . . . . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Client Identity Definition . . . . . . . . . . . . . . . . . 7
5.1. Differences from Replaced Sections . . . . . . . . . . . 7
5.2. Client Identity Data Items . . . . . . . . . . . . . . . 8
5.2.1. Client Identity Structure . . . . . . . . . . . . . . 9
5.2.2. Client Identity Shorthand . . . . . . . . . . . . . . 11
5.3. Server Release of Client ID . . . . . . . . . . . . . . . 13
5.4. Client ID String Approaches . . . . . . . . . . . . . . . 14
5.5. Non-uniform Client ID String Approach . . . . . . . . . . 16
5.6. Uniform Client ID String Approach . . . . . . . . . . . . 16
5.7. Mixing Client ID String Approaches . . . . . . . . . . . 18
5.8. Trunking Determination when Using Uniform Client ID
Strings . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.9. Client ID String Construction Details . . . . . . . . . . 26
6. Locking and Multi-Server Namespace . . . . . . . . . . . . . 28
6.1. Lock State and File System Transitions . . . . . . . . . 28
6.1.1. Migration and State . . . . . . . . . . . . . . . . . 29
6.1.1.1. Migration and Client IDs . . . . . . . . . . . . 31
6.1.1.2. Migration and State Owner Information . . . . . . 32
6.1.2. Replication and State . . . . . . . . . . . . . . . . 36
6.1.3. Notification of Migrated Lease . . . . . . . . . . . 36
6.1.4. Migration and the lease_time Attribute . . . . . . . 39
7. Server Implementation Considerations . . . . . . . . . . . . 39
7.1. Relation of Locking State Transfer to Other Aspects of
File System Motion . . . . . . . . . . . . . . . . . . . 39
7.2. Preventing Locking State Modification during Transfer . . 41
8. Additional Changes . . . . . . . . . . . . . . . . . . . . . 44
8.1. Summary of Additional Changes from Previous Documents . . 45
8.2. NFS4ERR_CLID_INUSE Definition . . . . . . . . . . . . . . 45
8.3. NFS4ERR_DELAY Return from RELEASE_LOCKOWNER . . . . . . . 45
8.4. Operation 35: SETCLIENTID -- Negotiate Client ID . . . . 46
8.5. Security Considerations for Inter-server Information
Transfer . . . . . . . . . . . . . . . . . . . . . . . . 51
8.6. Security Considerations Revision . . . . . . . . . . . . 51
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1. Normative References . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . 52
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Data Type Definitions . . . . . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Client Identity Definition . . . . . . . . . . . . . . . . . 7
5.1. Differences from Replaced Sections . . . . . . . . . . . 7
5.2. Client Identity Data Items . . . . . . . . . . . . . . . 8
5.2.1. Client Identity Structure . . . . . . . . . . . . . . 9
5.2.2. Client Identity Shorthand . . . . . . . . . . . . . . 11
5.3. Server Release of Client ID . . . . . . . . . . . . . . . 13
5.4. Client ID String Approaches . . . . . . . . . . . . . . . 14
5.5. Non-uniform Client ID String Approach . . . . . . . . . . 16
5.6. Uniform Client ID String Approach . . . . . . . . . . . . 16
5.7. Mixing Client ID String Approaches . . . . . . . . . . . 18
5.8. Trunking Determination when Using Uniform Client ID
Strings . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.9. Client ID String Construction Details . . . . . . . . . . 26
6. Locking and Multi-Server Namespace . . . . . . . . . . . . . 28
6.1. Lock State and File System Transitions . . . . . . . . . 28
6.1.1. Migration and State . . . . . . . . . . . . . . . . . 29
6.1.1.1. Migration and Client IDs . . . . . . . . . . . . 31
6.1.1.2. Migration and State Owner Information . . . . . . 32
6.1.2. Replication and State . . . . . . . . . . . . . . . . 36
6.1.3. Notification of Migrated Lease . . . . . . . . . . . 36
6.1.4. Migration and the lease_time Attribute . . . . . . . 39
7. Server Implementation Considerations . . . . . . . . . . . . 39
7.1. Relation of Locking State Transfer to Other Aspects of
File System Motion . . . . . . . . . . . . . . . . . . . 39
7.2. Preventing Locking State Modification during Transfer . . 41
8. Additional Changes . . . . . . . . . . . . . . . . . . . . . 44
8.1. Summary of Additional Changes from Previous Documents . . 45
8.2. NFS4ERR_CLID_INUSE Definition . . . . . . . . . . . . . . 45
8.3. NFS4ERR_DELAY Return from RELEASE_LOCKOWNER . . . . . . . 45
8.4. Operation 35: SETCLIENTID -- Negotiate Client ID . . . . 46
8.5. Security Considerations for Inter-server Information
Transfer . . . . . . . . . . . . . . . . . . . . . . . . 51
8.6. Security Considerations Revision . . . . . . . . . . . . 51
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1. Normative References . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . 52
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
This Standards Track document corrects the existing definitive specification of the NFSv4.0 protocol described in [RFC7530]. Given this fact, one should take the current document into account when learning about NFSv4.0, particularly if one is concerned with issues that relate to:
本标准跟踪文件修正了[RFC7530]中描述的NFSv4.0协议的现有最终规范。鉴于这一事实，在学习NFSv4.0时，应将当前文档考虑在内，尤其是在涉及以下问题时：
o File system migration, particularly when it involves transparent state migration.
o 文件系统迁移，特别是涉及透明状态迁移时。
o The construction and interpretation of the nfs_client_id4 structure and particularly the requirements on the id string within it, referred to below as a "client ID string".
o nfs_client_id4结构的构造和解释，特别是其中的id字符串要求，以下称为“客户端id字符串”。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following definitions are included to provide an appropriate context for the reader. This section is derived from Section 1.5 of [RFC7530] but has been adapted to the needs of this document.
包含以下定义是为了为读者提供适当的上下文。本节源自[RFC7530]第1.5节，但已根据本文件的需要进行了修改。
Boot Instance Id: A boot instance id is an identifier, such as a boot time, allowing two different instances of the same client to be reliably distinguished. A boot instance id is opaque to the server and is often used as the verifier field in the nfs_client_id4 structure, which identifies the client to the server.
引导实例Id：引导实例Id是一个标识符，例如引导时间，允许可靠地区分同一客户机的两个不同实例。引导实例id对服务器是不透明的，通常用作nfs_client_id4结构中的验证器字段，该结构将客户端标识给服务器。
Client: A client is an entity that accesses the NFS server's resources. The client may be an application that contains the logic to access the NFS server directly. The client may also be the traditional operating system client that provides remote file system services for a set of applications.
客户端：客户端是访问NFS服务器资源的实体。客户端可能是包含直接访问NFS服务器的逻辑的应用程序。客户端也可以是为一组应用程序提供远程文件系统服务的传统操作系统客户端。
With reference to byte-range locking, the client is also the entity that maintains a set of locks on behalf of one or more applications. This client is responsible for crash or failure recovery for those locks it manages.
关于字节范围锁定，客户机也是代表一个或多个应用程序维护一组锁的实体。此客户端负责其管理的锁的崩溃或故障恢复。
Note that multiple clients may share the same transport and connection, and multiple clients may exist on the same network node.
请注意，多个客户端可能共享相同的传输和连接，并且多个客户端可能存在于同一网络节点上。
Client ID: A client ID is a 64-bit quantity (in the form of a clientid4) used as a unique, shorthand reference to a particular client instance, identified by a client-supplied verifier (in the form of a boot instance id) and client ID string. The server is responsible for supplying the client ID.
客户机ID：客户机ID是一个64位的数量（以Client4的形式），用作对特定客户机实例的唯一、速记引用，由客户机提供的验证器（以启动实例ID的形式）和客户机ID字符串标识。服务器负责提供客户端ID。
File System: A file system is the collection of objects on a server that share the same fsid attribute (see Section 5.8.1.9 of [RFC7530]).
文件系统：文件系统是服务器上共享相同fsid属性的对象的集合（参见[RFC7530]第5.8.1.9节）。
Grace Period: A grace period is an interval of time during which the server will only grant locking requests to reclaim existing locks but not those that create new locks. This gives clients an opportunity to re-establish locking state in response to a potentially disruptive event. The grace period may be general to help deal with server reboot, or it may be specific to a file system to deal with file system migration when transparent state migration is not provided.
宽限期：宽限期是一段时间间隔，在此期间，服务器将只授予锁定请求以回收现有锁，而不授予创建新锁的锁定请求。这使客户端有机会重新建立锁定状态，以响应潜在的破坏性事件。宽限期可以是帮助处理服务器重新启动的一般宽限期，也可以是特定于文件系统的宽限期，以便在未提供透明状态迁移时处理文件系统迁移。
Lease: A lease is an interval of time defined by the server for which the client is irrevocably granted a lock. At the end of a lease period, the lock may be revoked if the lease has not been extended. The lock must be revoked if a conflicting lock has been granted after the lease interval.
租约：租约是由服务器定义的一段时间间隔，对于该时间间隔，客户端被不可撤销地授予锁。在租赁期结束时，如果租赁期未延长，则可撤销锁定。如果在租约间隔后授予了冲突的锁，则必须撤销该锁。
All leases granted by a server have the same fixed duration. Note that the fixed interval duration was chosen to alleviate the expense a server would have in maintaining state about variable-length leases across server failures.
服务器授予的所有租约具有相同的固定期限。请注意，选择固定间隔持续时间是为了减轻服务器在维护跨服务器故障的可变长度租约状态时的开销。
Lock: The term "lock" is used to refer to record (byte-range) locks as well as share reservations unless specifically stated otherwise.
锁定：除非另有特别说明，否则术语“锁定”用于指记录（字节范围）锁定以及共享保留。
Lock-Owner: Each byte-range lock is associated with a specific lock-owner and an open-owner. The lock-owner consists of a client ID and an opaque owner string. The client presents this to the server to establish the ownership of the byte-range lock as needed.
锁所有者：每个字节范围锁都与特定的锁所有者和打开的所有者相关联。锁所有者由客户端ID和不透明所有者字符串组成。客户机根据需要将其呈现给服务器，以建立字节范围锁的所有权。
Open-Owner: Each open file is associated with a specific open-owner, which consists of a client ID and an opaque owner string. The client presents this to the server to establish the ownership of the open as needed.
打开所有者：每个打开的文件都与特定的打开所有者关联，该所有者由客户端ID和不透明的所有者字符串组成。客户机将此信息呈现给服务器，以根据需要确定开放式数据库的所有权。
Server: A server is an entity responsible for coordinating client access to a set of file systems.
服务器：服务器是负责协调客户端对一组文件系统的访问的实体。
Stateid: A stateid is a 128-bit quantity returned by a server that uniquely identifies the open and locking states provided by the server for a specific open-owner or lock-owner/open-owner pair for a specific file and type of lock.
Stateid：Stateid是服务器返回的128位数量，它唯一标识服务器为特定打开所有者或特定文件和锁类型的锁所有者/打开所有者对提供的打开和锁定状态。
Trunking: A situation in which multiple physical addresses are connected to the same logical server.
中继：多个物理地址连接到同一逻辑服务器的情况。
Verifier: A verifier is a quantity, in the form of a verifier4, that allows one party to an interaction to be aware of a reinitialization or other significant change to the state of the other party. In [RFC7530], this term most often designates the verifier field of an nfs_client_id4, in which a boot instance id is placed to allow the server to determine when there has been a client reboot, making it necessary to eliminate locking state associated with the previous instance of the same client.
验证者：验证者是一个数量，以验证者4的形式，允许交互的一方意识到另一方状态的重新初始化或其他重大变化。在[RFC7530]中，该术语通常指定nfs_客户端_id4的验证器字段，其中放置了引导实例id，以允许服务器确定何时发生了客户端重新启动，从而有必要消除与同一客户端的前一个实例相关联的锁定状态。
This section contains a table that shows where data types referred to in this document are defined.
本节包含一个表，该表显示了本文档中引用的数据类型的定义位置。
+-----------------+--------------------------------+
| Item | Section |
+-----------------+--------------------------------+
| cb_client4 | Section 2.2.11 in [RFC7530] |
| clientaddr4 | Section 2.2.10 in [RFC7530] |
| clientid4 | Section 2.1 in [RFC7530] |
| lock_owner4 | Section 2.2.14 in [RFC7530] |
| nfs_client_id4 | Section 5.2.1 (this document) |
| open_owner4 | Section 2.2.13 in [RFC7530] |
| verifier4 | Section 2.1 in [RFC7530] |
+-----------------+--------------------------------+
+-----------------+--------------------------------+
| Item | Section |
+-----------------+--------------------------------+
| cb_client4 | Section 2.2.11 in [RFC7530] |
| clientaddr4 | Section 2.2.10 in [RFC7530] |
| clientid4 | Section 2.1 in [RFC7530] |
| lock_owner4 | Section 2.2.14 in [RFC7530] |
| nfs_client_id4 | Section 5.2.1 (this document) |
| open_owner4 | Section 2.2.13 in [RFC7530] |
| verifier4 | Section 2.1 in [RFC7530] |
+-----------------+--------------------------------+
Implementation experience with transparent state migration has exposed a number of problems with the then existing specifications of this feature in [RFC7530] and predecessors. The symptoms were:
透明状态迁移的实施经验暴露了[RFC7530]和以前版本中该特性的现有规范存在的许多问题。病征包括:
o After migration of a file system, a reboot of the associated client was not appropriately dealt with, in that the state associated with the rebooting client was not promptly freed.
o 文件系统迁移后，关联客户端的重新启动未得到适当处理，因为与重新启动的客户端关联的状态未立即释放。
o Situations can arise whereby a given server has multiple leases with the same nfs_client_id4 (consisting of id and verifier fields), when the protocol clearly assumes there can be only one.
o 当协议明确假设只能有一个租约时，可能会出现这样的情况：给定服务器具有多个具有相同nfs_client_id4（由id和验证器字段组成）的租约。
o Excessive client implementation complexity since clients have to deal with situations in which a single client can wind up with its locking state with a given server divided among multiple leases each with its own clientid4.
o 客户机实现过于复杂，因为客户机必须处理这样的情况，即单个客户机可能会以其锁定状态结束，而给定的服务器被划分为多个租约，每个租约都有自己的客户端4。
An analysis of these symptoms leads to the conclusion that existing specifications have erred. They assume that locking state, including both state ids and clientid4s, should be transferred as part of transparent state migration. The troubling symptoms arise from the failure to describe how migrating state is to be integrated with existing client definition structures on the destination server.
对这些症状的分析得出结论，现有规范存在错误。它们假定锁定状态（包括状态ID和client4）应作为透明状态迁移的一部分进行传输。令人不安的症状源于未能描述迁移状态如何与目标服务器上的现有客户机定义结构集成。
The need for the server to appropriately merge stateids associated with a common client boot instance encounters a difficult problem. The issue is that the common client practice with regard to the presentation of unique strings specifying client identity makes it essentially impossible for the client to determine whether or not two stateids, originally generated on different servers, are referable to the same client. This practice is allowed and endorsed by the existing NFSv4.0 specification [RFC7530].
服务器需要适当地合并与公共客户机启动实例关联的StateID，这遇到了一个难题。问题在于，关于指定客户机标识的唯一字符串的表示的常见客户机实践使得客户机基本上无法确定最初在不同服务器上生成的两个StateID是否可引用到同一客户机。现有NFSv4.0规范[RFC7530]允许并认可这种做法。
However, upon the prototyping of clients implementing an alternative approach, it has been found that there exist servers that do not work well with these new clients. It appears that current circumstances, in which a particular client implementation pattern had been adopted universally, have resulted in some servers not being able to interoperate against alternate client implementation patterns. As a result, we have a situation that requires careful attention to untangling compatibility issues.
但是，在对实现替代方法的客户机进行原型设计后，发现存在与这些新客户机不兼容的服务器。目前普遍采用特定的客户机实现模式的情况似乎导致一些服务器无法与其他客户机实现模式进行互操作。因此，我们遇到了一个需要仔细注意解决兼容性问题的情况。
This document updates the existing NFSv4.0 specification [RFC7530] as follows:
本文件对现有NFSv4.0规范[RFC7530]进行如下更新：
o It makes clear that NFSv4.0 supports multiple approaches to the construction of client ID strings, including those formerly endorsed by existing NFSV4.0 specifications and those currently being widely deployed.
o 它清楚地表明，NFSv4.0支持构建客户端ID字符串的多种方法，包括以前由现有NFSv4.0规范认可的方法和目前正在广泛部署的方法。
o It explains how clients can effectively use client ID strings that are presented to multiple servers.
o 它解释了客户端如何有效地使用呈现给多个服务器的客户端ID字符串。
o It addresses the potential compatibility issues that might arise for clients adopting a previously non-favored client ID string construction approach including the existence of servers that have problems with the new approach.
o 它解决了采用以前不受欢迎的客户端ID字符串构造方法的客户端可能出现的潜在兼容性问题，包括存在与新方法有问题的服务器。
o It gives some guidance regarding the factors that might govern clients' choice of a client ID string construction approach and recommends that clients construct client ID strings in a manner that supports lease merger if they intend to support transparent state migration.
o 它提供了一些关于可能影响客户机选择客户机ID字符串构造方法的因素的指导，并建议客户机以支持租赁合并的方式构造客户机ID字符串（如果他们打算支持透明状态迁移）。
o It specifies how state is to be transparently migrated, including defining how state that arrives at a new server as part of migration is to be merged into existing leases for clients connected to the target server.
o 它指定如何透明地迁移状态，包括定义作为迁移的一部分到达新服务器的状态如何合并到连接到目标服务器的客户端的现有租约中。
o It makes further clarifications and corrections to address cases where the specification text does not take proper account of the issues raised by state migration or where it has been found that the existing text is insufficiently clear. This includes a revised definition of the SETCLIENTID operation in Section 8.4, which replaces Section 16.33 in [RFC7530].
o 它进一步澄清和更正了规范文本没有适当考虑到国家迁移引起的问题或发现现有文本不够清晰的情况。这包括第8.4节中对SETCLIENTID操作的修订定义，该定义取代了[RFC7530]中的第16.33节。
For a more complete explanation of the choices made in addressing these issues, see [INFO-MIGR].
有关解决这些问题时所做选择的更完整解释，请参见[INFO-MIGR]。
This section is a replacement for Sections 9.1.1 and 9.1.2 in [RFC7530]. The replaced sections are named "Client ID" and "Server Release of Client ID", respectively.
本节取代了[RFC7530]中的第9.1.1节和第9.1.2节。被替换的部分分别命名为“客户端ID”和“客户端ID的服务器版本”。
It supersedes the replaced sections.
它取代了被替换的部分。
Because of the need for greater attention to and careful description of this area, this section is much larger than the sections it replaces. The principal changes/additions made by this section are:
由于需要对这一领域给予更多的关注和仔细的描述，本节比其取代的章节要大得多。本节所作的主要变更/增补包括：
o It corrects inconsistencies regarding the possible role or non-role of the client IP address in construction of client ID strings.
o 它纠正了在构造客户端ID字符串时客户端IP地址的可能角色或非角色的不一致性。
o It clearly addresses the need to maintain a non-volatile record across reboots of client ID strings or any changeable values that are used in their construction.
o 它清楚地解决了在重新启动客户端ID字符串或在其构造中使用的任何可变值时维护非易失性记录的需要。
o It provides a more complete description of circumstances leading to clientid4 invalidity and the appropriate recovery actions.
o 它更完整地描述了导致客户4无效的情况以及适当的恢复行动。
o It presents, as valid alternatives, two approaches to client ID string construction (named "uniform" and "non-uniform") and gives some implementation guidance to help implementers choose one or the other of these.
o 作为有效的替代方案，它提供了两种客户端ID字符串构造方法（命名为“统一”和“非统一”），并提供了一些实现指导，以帮助实现者选择其中一种。
o It adds a discussion of issues involved for clients in interacting with servers whose behavior is not consistent with use of uniform client ID strings.
o 它增加了对客户端与服务器交互时涉及的问题的讨论，这些服务器的行为与统一客户端ID字符串的使用不一致。
o It adds a description of how server behavior might be used by the client to determine when multiple server IP addresses correspond to the same server.
o 它添加了一个描述，说明客户端如何使用服务器行为来确定多个服务器IP地址何时对应于同一个服务器。
The NFSv4 protocol contains a number of protocol entities to identify clients and client-based entities for locking-related purposes:
NFSv4协议包含许多协议实体，用于识别客户端和基于客户端的实体，以用于锁定相关目的：
o The nfs_client_id4 structure, which uniquely identifies a specific client boot instance. That identification is presented to the server by doing a SETCLIENTID operation. The SETCLIENTID operation is described in Section 8.4, which modifies a description in Section 16.33 of [RFC7530].
o nfs_client_id4结构，它唯一标识特定的客户端启动实例。通过执行SETCLIENTID操作将该标识呈现给服务器。SETCLIENTID操作在第8.4节中有描述，该节修改了[RFC7530]第16.33节中的描述。
o The clientid4, which is returned by the server upon completion of a successful SETCLIENTID operation. This id is used by the client to identify itself when doing subsequent locking-related operations. A clientid4 is associated with a particular lease whereby a client instance holds state on a server instance and may become invalid due to client reboot, server reboot, or other circumstances.
o client4，在成功完成SETCLIENTID操作后由服务器返回。客户端在执行后续锁定相关操作时使用此id来标识自身。client4与特定租约相关联，其中客户端实例保持服务器实例上的状态，并且可能由于客户端重新启动、服务器重新启动或其他情况而变得无效。
o Opaque arrays, which are used together with the clientid4 to designate within-client entities (e.g., processes) as the owners of opens (open-owners) and owners of byte-range locks (lock-owners).
o 不透明数组，与client4一起使用，用于在客户端实体（例如进程）内指定为打开的所有者（打开的所有者）和字节范围锁的所有者（锁所有者）。
The basis of the client identification infrastructure is encapsulated in the following data structure, which also appears in Section 9.1.1 of [RFC7530]:
客户识别基础设施的基础封装在以下数据结构中，也出现在[RFC7530]的第9.1.1节中：
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
The nfs_client_id4 structure uniquely defines a particular client boot instance as follows:
nfs_client_id4结构唯一地定义了特定的客户端启动实例，如下所示：
o The id field is a variable-length string that uniquely identifies a specific client. Although it is described here as a string and is often referred to as a "client string", it should be understood that the protocol defines this as opaque data. In particular, those receiving such an id should not assume that it will be in the UTF-8 encoding. Servers MUST NOT reject an nfs_client_id4 simply because the id string does not follow the rules of UTF-8 encoding.
o id字段是唯一标识特定客户端的可变长度字符串。尽管在这里它被描述为一个字符串，并且通常被称为“客户机字符串”，但应该理解的是，协议将其定义为不透明数据。特别是，那些接收这样一个id的人不应该假设它将采用UTF-8编码。服务器不能仅仅因为id字符串不符合UTF-8编码规则就拒绝nfs_客户端_id4。
The encoding and decoding processes for this field (e.g., use of network byte order) need to result in the same internal representation whatever the endianness of the originating and receiving machines.
该字段的编码和解码过程（例如，网络字节顺序的使用）需要产生相同的内部表示，无论始发和接收机器的端序如何。
o The verifier field contains a client boot instance identifier that is used by the server to detect client reboots. Only if the boot instance is different from that which the server has previously recorded in connection with the client (as identified by the id field) does the server cancel the client's leased state. This cancellation occurs once it receives confirmation of the new nfs_clientd4 via SETCLIENTID_CONFIRM. The SETCLIENTID_CONFIRM operation is described in Section 16.34 of [RFC7530].
o verifier字段包含服务器用于检测客户端重新启动的客户端启动实例标识符。只有当引导实例不同于服务器先前记录的与客户机相关的实例（由id字段标识）时，服务器才会取消客户机的已租用状态。一旦通过SETCLIENTID\u CONFIRM收到新nfs\u客户端4的确认，就会发生此取消。[RFC7530]第16.34节描述了SETCLIENTID_确认操作。
In order to prevent the possibility of malicious destruction of the locking state associated with a client, the server MUST NOT cancel a client's leased state if the principal that established the state for a given id string is not the same as the principal issuing the SETCLIENTID.
为了防止恶意破坏与客户端关联的锁定状态的可能性，如果为给定id字符串建立状态的主体与发出SETCLIENTID的主体不同，则服务器不得取消客户端的租用状态。
There are several considerations for how the client generates the id string:
对于客户端如何生成id字符串，有几个注意事项：
o The string should be unique so that multiple clients do not present the same string. The consequences of two clients presenting the same string range from one client getting an error to one client having its leased state abruptly and unexpectedly canceled.
o 该字符串应该是唯一的，以便多个客户端不显示相同的字符串。两个客户端呈现相同字符串的后果从一个客户端出错到一个客户端的租用状态突然意外取消。
o The string should be selected so that subsequent incarnations (e.g., reboots) of the same client cause the client to present the same string. The implementer is cautioned against an approach that requires the string to be recorded in a local file because this precludes the use of the implementation in an environment where there is no local disk and all file access is from an NFSv4 server.
o 应选择该字符串，以便同一客户端的后续化身（例如，重新启动）导致客户端呈现相同的字符串。提醒实现者不要使用要求将字符串记录在本地文件中的方法，因为这会妨碍在没有本地磁盘且所有文件访问都来自NFSv4服务器的环境中使用实现。
o The string MAY be different for each server network address that the client accesses rather than common to all server network addresses.
o 对于客户端访问的每个服务器网络地址，该字符串可能不同，而不是所有服务器网络地址共用的字符串。
The considerations that might influence a client to use different strings for different network server addresses are explained in Section 5.4.
第5.4节解释了可能影响客户端对不同网络服务器地址使用不同字符串的注意事项。
o The algorithm for generating the string should not assume that the clients' network addresses will remain the same for any set period of time. Even while the client is still running in its current incarnation, changes might occur between client incarnations.
o 生成字符串的算法不应假定客户端的网络地址在任何设定的时间段内保持不变。即使客户端仍在其当前版本中运行，在客户端版本之间也可能发生更改。
Changes to the client ID string due to network address changes would result in successive SETCLIENTID operations for the same client appearing as from different clients, interfering with the use of the nfs_client_id4 verifier field to cancel state associated with previous boot instances of the same client.
由于网络地址更改而更改客户机ID字符串将导致同一客户机的连续SETCLIENTID操作显示为来自不同客户机，从而干扰使用nfs_client_id4验证程序字段取消与同一客户机以前启动实例关联的状态。
The difficulty is more severe if the client address is the only client-based information in the client ID string. In such a case, there is a real risk that after the client gives up the network address, another client, using the same algorithm, would generate a conflicting id string. This would be likely to cause an inappropriate loss of locking state. See Section 5.9 for detailed guidance regarding client ID string construction.
如果客户机地址是客户机ID字符串中唯一基于客户机的信息，则难度更大。在这种情况下，存在一个真正的风险，即在客户端放弃网络地址后，另一个客户端使用相同的算法将生成一个冲突的id字符串。这可能会导致不适当的锁定状态丢失。有关客户ID字符串构造的详细指南，请参见第5.9节。
Once a SETCLIENTID and SETCLIENTID_CONFIRM sequence has successfully completed, the client uses the shorthand client identifier, of type clientid4, instead of the longer and less compact nfs_client_id4 structure. This shorthand client identifier (a client ID) is assigned by the server and should be chosen so that it will not conflict with a client ID previously assigned by the same server and, to the degree practicable, by other servers as well. This applies across server restarts or reboots.
成功完成SETCLIENTID和SETCLIENTID_确认序列后，客户端将使用ClientD4类型的速记客户端标识符，而不是较长且不太紧凑的nfs_client_id4结构。此速记客户机标识符（客户机ID）由服务器分配，并且应进行选择，以使其不会与以前由同一服务器分配的客户机ID冲突，并且在可行的程度上，也不会与其他服务器分配的客户机ID冲突。这适用于服务器重新启动或重新启动。
Establishment of the client ID by a new incarnation of the client also has the effect of immediately breaking any leased state that a previous incarnation of the client might have had on the server, as opposed to forcing the new client incarnation to wait for the leases to expire. Breaking the lease state amounts to the server removing all locks, share reservations, and delegation states not requested using the CLAIM_DELEGATE_PREV claim type associated with a client having the same identity. For a discussion of delegation state recovery, see Section 10.2.1 of [RFC7530].
通过客户机的新化身建立客户机ID还具有立即中断客户机的前一化身可能在服务器上具有的任何租赁状态的效果，而不是强制新客户机化身等待租赁到期。破坏租约状态相当于服务器使用与具有相同标识的客户端关联的CLAIM_DELEGATE_PREV CLAIM类型删除所有未请求的锁、共享保留和委派状态。有关委派状态恢复的讨论，请参见[RFC7530]第10.2.1节。
Note that the SETCLIENTID and SETCLIENTID_CONFIRM operations have a secondary purpose of establishing the information the server needs to make callbacks to the client for the purpose of supporting delegations. The client is able to change this information via SETCLIENTID and SETCLIENTID_CONFIRM within the same incarnation of the client without causing removal of the client's leased state.
请注意，SETCLIENTID和SETCLIENTID_确认操作的第二个目的是建立服务器回调客户端以支持委托所需的信息。客户端可以通过SETCLIENTID和SETCLIENTID_CONFIRM在客户端的同一化身内更改此信息，而不会导致删除客户端的租用状态。
Distinct servers MAY assign clientid4s independently, and they will generally do so. Therefore, a client has to be prepared to deal with multiple instances of the same clientid4 value received on distinct IP addresses, denoting separate entities. When trunking of server IP addresses is not a consideration, a client should keep track of <IP-address, clientid4> pairs, so that each pair is distinct. For a discussion of how to address the issue in the face of possible trunking of server IP addresses, see Section 5.4.
不同的服务器可以独立地分配client4，并且通常会这样做。因此，客户机必须准备好处理在不同IP地址上接收到的相同Client4值的多个实例，表示不同的实体。当不考虑服务器IP地址的中继时，客户端应跟踪<IP地址，client4>对，以便每对都是不同的。有关如何解决可能的服务器IP地址中继问题的讨论，请参阅第5.4节。
Owners of opens and owners of byte-range locks are separate entities and remain separate even if the same opaque arrays are used to designate owners of each. The protocol distinguishes between open-owners (represented by open_owner4 structures) and lock-owners (represented by lock_owner4 structures).
opens的所有者和byte range锁的所有者是独立的实体，即使使用相同的不透明数组指定每个锁的所有者，它们仍然保持独立。该协议区分开放所有者（由open_owner4结构表示）和锁所有者（由lock_owner4结构表示）。
Both sorts of owners consist of a clientid4 and an opaque owner string. For each client, there is a set of distinct owner values used with that client which constitutes the set of known owners of that type, for the given client.
这两种所有者都由client4和不透明的所有者字符串组成。对于每个客户机，都有一组与该客户机一起使用的不同所有者值，这些值构成了给定客户机的该类型的已知所有者集。
Each open is associated with a specific open-owner while each byte-range lock is associated with a lock-owner and an open-owner, the latter being the open-owner associated with the open file under which the LOCK operation was done.
每个打开与特定的打开所有者关联，而每个字节范围锁与一个锁所有者和一个打开所有者关联，后者是与执行锁定操作的打开文件关联的打开所有者。
When a clientid4 is presented to a server and that clientid4 is not valid, the server will reject the request with an error that depends on the reason for clientid4 invalidity. The error NFS4ERR_ADMIN_REVOKED is returned when the invalidation is the result of administrative action. When the clientid4 is unrecognizable, the error NFS4ERR_STALE_CLIENTID or NFS4ERR_EXPIRED may be returned. An unrecognizable clientid4 can occur for a number of reasons:
当向服务器显示Client4且该Client4无效时，服务器将拒绝该请求，并根据Client4无效的原因发出错误。当无效是管理操作的结果时，返回错误NFS4ERR_ADMIN_reversed。当client4无法识别时，可能会返回错误NFS4ERR_STALE_CLIENTID或NFS4ERR_EXPIRED。出现无法识别的客户端4的原因有很多：
o A server reboot causing loss of the server's knowledge of the client. (Always returns NFS4ERR_STALE_CLIENTID.)
o 服务器重新启动导致服务器丢失对客户端的了解。（始终返回NFS4ERR\u STALE\u CLIENTID。）
o Client error sending an incorrect clientid4 or a valid clientid4 to the wrong server. (May return either error.)
o 将错误的Client4或有效的Client4发送到错误的服务器时发生客户端错误。（可能返回任意一个错误。）
o Loss of lease state due to lease expiration. (Always returns NFS4ERR_EXPIRED.)
o 由于租赁到期而丧失租赁状态。（始终返回NFS4ERR_过期。）
o Client or server error causing the server to believe that the client has rebooted (i.e., receiving a SETCLIENTID with an nfs_client_id4 that has a matching id string and a non-matching boot instance id as the verifier). (May return either error.)
o 客户端或服务器错误，导致服务器认为客户端已重新启动（即，接收到一个SETCLIENTID，其中nfs_Client_id4具有匹配的id字符串和非匹配的启动实例id作为验证器）。（可能返回任意一个错误。）
o Migration of all state under the associated lease causes its non-existence to be recognized on the source server. (Always returns NFS4ERR_STALE_CLIENTID.)
o 迁移关联租约下的所有状态会导致在源服务器上识别其不存在。（始终返回NFS4ERR\u STALE\u CLIENTID。）
o Merger of state under the associated lease with another lease under a different client ID causes the clientid4 serving as the source of the merge to cease being recognized on its server. (Always returns NFS4ERR_STALE_CLIENTID.)
o 关联租约下的状态与不同客户端ID下的另一租约的合并将导致作为合并源的客户端4在其服务器上停止被识别。（始终返回NFS4ERR\u STALE\u CLIENTID。）
In the event of a server reboot, loss of lease state due to lease expiration, or administrative revocation of a clientid4, the client must obtain a new clientid4 by use of the SETCLIENTID operation and then proceed to any other necessary recovery for the server reboot case (see Section 9.6.2 in [RFC7530]). In cases of server or client error resulting in a clientid4 becoming unusable, use of SETCLIENTID to establish a new lease is desirable as well.
如果服务器重新启动、租约到期导致租约状态丢失或Client4被行政撤销，客户端必须使用SETCLIENTID操作获得新的Client4，然后继续进行服务器重新启动情况下的任何其他必要恢复（请参阅[RFC7530]中的第9.6.2节）。如果服务器或客户机错误导致Client4变得不可用，也需要使用SETCLIENTID建立新租约。
In cases in which loss of server knowledge of a clientid4 is the result of migration, different recovery procedures are required. See Section 6.1.1 for details. Note that in cases in which there is any uncertainty about which sort of handling is applicable, the
如果迁移导致客户端4的服务器知识丢失，则需要不同的恢复过程。详见第6.1.1节。请注意，在不确定哪种处理方式适用的情况下
distinguishing characteristic is that in reboot-like cases, the clientid4 and all associated stateids cease to exist while in migration-related cases, the clientid4 ceases to exist while the stateids are still valid.
区别在于，在类似重新启动的情况下，Client4和所有关联的StateID不再存在，而在与迁移相关的情况下，Client4不再存在，而StateID仍然有效。
The client must also employ the SETCLIENTID operation when it receives an NFS4ERR_STALE_STATEID error using a stateid derived from its current clientid4, since this indicates a situation, such as a server reboot that has invalidated the existing clientid4 and associated stateids (see Section 9.1.5 in [RFC7530] for details).
当客户端使用从其当前Client4派生的STATEID接收到NFS4ERR_STALE_STATEID错误时，还必须使用SETCLIENTID操作，因为这表示一种情况，例如服务器重新启动使现有Client4和相关STATEID无效（有关详细信息，请参阅[RFC7530]中的第9.1.5节）。
See the detailed descriptions of SETCLIENTID (in Section 8.4) and SETCLIENTID_CONFIRM (in Section 16.34 of [RFC7530]) for a complete specification of these operations.
有关这些操作的完整规范，请参见SETCLIENTID（第8.4节）和SETCLIENTID_CONFIRM（第16.34节[RFC7530]）的详细说明。
If the server determines that the client holds no associated state for its clientid4, the server may choose to release that clientid4. The server may make this choice for an inactive client so that resources are not consumed by those intermittently active clients. If the client contacts the server after this release, the server must ensure the client receives the appropriate error so that it will use the SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new identity. It should be clear that the server must be very hesitant to release a client ID since the resulting work on the client to recover from such an event will be the same burden as if the server had failed and restarted. Typically, a server would not release a client ID unless there had been no activity from that client for many minutes.
如果服务器确定客户端没有其Client4的关联状态，则服务器可以选择释放该Client4。服务器可以对非活动客户端进行此选择，以便资源不会被那些间歇性活动的客户端消耗。如果客户机在此版本后联系服务器，服务器必须确保客户机收到适当的错误，以便使用SETCLIENTID/SETCLIENTID_确认序列来建立新标识。应该清楚的是，服务器在释放客户机ID时一定会非常犹豫，因为在客户机上从此类事件中恢复的结果工作将与服务器发生故障并重新启动时的负担相同。通常，服务器不会释放客户机ID，除非该客户机在几分钟内没有任何活动。
Note that if the id string in a SETCLIENTID request is properly constructed, and if the client takes care to use the same principal for each successive use of SETCLIENTID, then, barring an active denial-of-service attack, NFS4ERR_CLID_INUSE should never be returned.
请注意，如果SETCLIENTID请求中的id字符串构造正确，并且如果客户端注意在每次连续使用SETCLIENTID时使用相同的主体，则除非发生主动拒绝服务攻击，否则不应返回NFS4ERR_CLID_INUSE。
However, client bugs, server bugs, or perhaps a deliberate change of the principal owner of the id string (such as may occur in the case in which a client changes security flavors, and under the new flavor, there is no mapping to the previous owner) will in rare cases result in NFS4ERR_CLID_INUSE.
但是，客户端错误、服务器错误或故意更改id字符串的主要所有者（例如，在客户端更改安全样式的情况下可能会发生这种情况，并且在新样式下，没有映射到以前的所有者）在极少数情况下会导致NFS4ERR_CLID_使用。
In situations in which there is an apparent change of principal, when the server gets a SETCLIENTID specifying a client ID string for which the server has a clientid4 that currently has no state, or for which it has state, but where the lease has expired, the server MUST allow the SETCLIENTID rather than returning NFS4ERR_CLID_INUSE. The server
在主体发生明显变化的情况下，当服务器获取一个SETCLIENTID，该SETCLIENTID指定了一个客户端ID字符串，对于该字符串，服务器有一个当前没有状态的Client4，或者它有状态，但租约已过期，服务器必须允许SETCLIENTID，而不是返回NFS4ERR_CLID_INUSE。服务器
MUST then confirm the new client ID if followed by the appropriate SETCLIENTID_CONFIRM.
然后必须确认新的客户端ID（如果后跟相应的SETCLIENTID_confirm）。
One particular aspect of the construction of the nfs_client_id4 string has proved recurrently troublesome. The client has a choice of:
nfs_客户机_id4字符串构造的一个特殊方面被证明是反复出现的麻烦。客户可以选择：
o Presenting the same id string to multiple server addresses. This is referred to as the "uniform client ID string approach" and is discussed in Section 5.6.
o 向多个服务器地址显示相同的id字符串。这被称为“统一客户端ID字符串方法”，并在第5.6节中讨论。
o Presenting different id strings to multiple server addresses. This is referred to as the "non-uniform client ID string approach" and is discussed in Section 5.5.
o 向多个服务器地址显示不同的id字符串。这被称为“非统一客户端ID字符串方法”，并在第5.5节中讨论。
Note that implementation considerations, including compatibility with existing servers, may make it desirable for a client to use both approaches, based on configuration information, such as mount options. This issue will be discussed in Section 5.7.
请注意，基于配置信息（如装载选项），包括与现有服务器的兼容性在内的实现考虑因素可能会使客户机希望使用这两种方法。该问题将在第5.7节中讨论。
Construction of the client ID string has arisen as a difficult issue because of the way in which the NFS protocols have evolved. It is useful to consider two points in that evolution.
由于NFS协议的发展方式，客户机ID字符串的构造已成为一个难题。在进化过程中考虑两点是有用的。
o NFSv3 as a stateless protocol had no need to identify the state shared by a particular client-server pair (see [RFC1813]). Thus, there was no need to consider the question of whether a set of requests come from the same client or whether two server IP addresses are connected to the same server. As the environment was one in which the user supplied the target server IP address as part of incorporating the remote file system in the client's file namespace, there was no occasion to take note of server trunking. Within a stateless protocol, the situation was symmetrical. The client has no server identity information, and the server has no client identity information.
o NFSv3作为一种无状态协议，不需要识别特定客户机-服务器对共享的状态（参见[RFC1813]）。因此，不需要考虑一组请求是否来自同一客户机或两个服务器IP地址是否连接到同一服务器的问题。由于环境是用户提供目标服务器IP地址作为将远程文件系统合并到客户端文件命名空间的一部分，因此没有必要注意服务器中继。在无状态协议中，情况是对称的。客户端没有服务器标识信息，服务器没有客户端标识信息。
o NFSv4.1 is a stateful protocol with full support for client and server identity determination (see [RFC5661]). This enables the server to be aware when two requests come from the same client (they are on sessions sharing a clientid4) and the client to be aware when two server IP addresses are connected to the same server. Section 2.10.5.1 of [RFC5661] explains how the client is able to assure itself that the connections are to the same logical server.
o NFSv4.1是一个有状态协议，完全支持客户端和服务器身份确定（请参见[RFC5661]）。这使服务器能够在两个请求来自同一客户机（它们在共享一个客户机4的会话上）时感知，并使客户机能够在两个服务器IP地址连接到同一服务器时感知。[RFC5661]的第2.10.5.1节解释了客户端如何确保连接到同一逻辑服务器。
NFSv4.0 is unfortunately halfway between these two. It introduced new requirements such as the need to identify specific clients and client instances without addressing server identity issues. The two client ID string approaches have arisen in attempts to deal with the changing requirements of the protocol as implementation has proceeded, and features that were not very substantial in early implementations of NFSv4.0 became more substantial as implementation proceeded.
不幸的是，NFSv4.0介于两者之间。它引入了新的需求，例如需要在不解决服务器身份问题的情况下识别特定的客户机和客户机实例。这两种客户机ID字符串方法是为了在实现过程中处理协议不断变化的需求而出现的，而在NFSv4.0的早期实现中不太重要的功能随着实现的进行变得更加重要。
o In the absence of any implementation of features related to fs_locations (replication, referral, and migration), the situation is very similar to that of NFSv3 (see Section 8.1 and the subsections within Section 8.4 of [RFC7530] for discussion of these features). In this case, locking state has been added, but there is no need for concern about the provision of accurate client and server identity determination. This is the situation that gave rise to the non-uniform client ID string approach.
o 在没有任何与fs_位置相关的功能实现（复制、引用和迁移）的情况下，情况与NFSv3非常相似（有关这些功能的讨论，请参见第8.1节和[RFC7530]第8.4节中的小节）。在这种情况下，添加了锁定状态，但不需要担心提供准确的客户机和服务器身份确定。这就是导致非统一客户端ID字符串方法的情况。
o In the presence of replication and referrals, the client may have occasion to take advantage of knowledge of server trunking information. Even more important, transparent state migration, by transferring state among servers, causes difficulties for the non-uniform client ID string approach, in that the two different client ID strings sent to different IP addresses may wind up being processed by the same logical server, adding confusion.
o 在存在复制和引用的情况下，客户机可能有机会利用服务器集群信息的知识。更重要的是，透明的状态迁移通过在服务器之间传输状态，给非统一的客户机ID字符串方法带来了困难，因为发送到不同IP地址的两个不同的客户机ID字符串可能最终被同一逻辑服务器处理，增加了混乱。
o A further consideration is that client implementations typically provide NFSv4.1 by augmenting their existing NFSv4.0 implementation, not by providing two separate implementations. Thus, the more NFSv4.0 and NFSv4.1 can work alike, the less complex the clients are. This is a key reason why those implementing NFSv4.0 clients might prefer using the uniform client string model, even if they have chosen not to provide fs_locations-related features in their NFSv4.0 client.
o 进一步考虑的是，客户端实现通常通过扩展其现有的NFSv4.0实现来提供NFSv4.1，而不是通过提供两个单独的实现。因此，NFSv4.0和NFSv4.1的工作方式越相似，客户端就越不复杂。这是实现NFSv4.0客户端的人可能更喜欢使用统一客户端字符串模型的一个关键原因，即使他们选择不在NFSv4.0客户端中提供与fs_位置相关的功能。
Both approaches have to deal with the asymmetry in client and server identity information between client and server. Each seeks to make the client's and the server's views match. In the process, each encounters some combination of inelegant protocol features and/or implementation difficulties. The choice of which to use is up to the client implementer, and the sections below try to give some useful guidance.
这两种方法都必须处理客户端和服务器之间的客户端和服务器身份信息不对称问题。每种方法都试图使客户端和服务器的视图匹配。在这个过程中，每个协议都会遇到一些不雅的协议特性和/或实现困难的组合。使用哪种方法取决于客户机实现者，下面的部分试图提供一些有用的指导。
The non-uniform client ID string approach is an attempt to handle these matters in NFSv4.0 client implementations in as NFSv3-like a way as possible.
非统一的客户机ID字符串方法是在NFSv4.0客户机实现中以尽可能类似NFSv3的方式处理这些问题的一种尝试。
For a client using the non-uniform approach, all internal recording of clientid4 values is to include, whether explicitly or implicitly, the server IP address so that one always has an <IP-address, clientid4> pair. Two such pairs from different servers are always distinct even when the clientid4 values are the same, as they may occasionally be. In this approach, such equality is always treated as simple happenstance.
对于使用非统一方法的客户机，Client4值的所有内部记录都应包括（无论是显式还是隐式）服务器IP地址，以便始终具有<IP地址，Client4>对。来自不同服务器的两个这样的对始终是不同的，即使ClientI4值相同（有时可能是相同的）。在这种方法中，这种平等总是被视为简单的偶然事件。
Making the client ID string different on different server IP addresses results in a situation in which a server has no way of tying together information from the same client, when the client accesses multiple server IP addresses. As a result, it will treat a single client as multiple clients with separate leases for each server network address. Since there is no way in the protocol for the client to determine if two network addresses are connected to the same server, the resulting lack of knowledge is symmetrical and can result in simpler client implementations in which there is a single clientid4/lease per server network address.
当客户端访问多个服务器IP地址时，使不同服务器IP地址上的客户端ID字符串不同会导致服务器无法将来自同一客户端的信息绑定在一起。因此，它将单个客户端视为多个客户端，每个服务器网络地址都有单独的租约。由于在协议中客户端无法确定两个网络地址是否连接到同一台服务器，因此导致的知识缺失是对称的，并且可能导致更简单的客户端实现，其中每个服务器有一个client4/lease网络地址。
Support for migration, particularly with transparent state migration, is more complex in the case of non-uniform client ID strings. For example, migration of a lease can result in multiple leases for the same client accessing the same server addresses, vitiating many of the advantages of this approach. Therefore, client implementations that support migration with transparent state migration are likely to experience difficulties using the non-uniform client ID string approach and should not do so, except where it is necessary for compatibility with existing server implementations (for details of arranging use of multiple client ID string approaches, see Section 5.7).
对迁移的支持，特别是对透明状态迁移的支持，在非统一客户端ID字符串的情况下更为复杂。例如，一个租约的迁移可能导致同一客户机访问同一服务器地址的多个租约，从而削弱了这种方法的许多优点。因此，支持透明状态迁移的客户机实现在使用非统一的客户机ID字符串方法时可能会遇到困难，因此不应该这样做，除非需要与现有服务器实现兼容（有关安排使用多个客户端ID字符串方法的详细信息，请参阅第5.7节）。
When the client ID string is kept uniform, the server has the basis to have a single clientid4/lease for each distinct client. The problem that has to be addressed is the lack of explicit server identity information, which was made available in NFSv4.1.
当客户机ID字符串保持一致时，服务器可以为每个不同的客户机提供一个client4/lease。必须解决的问题是缺少明确的服务器标识信息，这在NFSv4.1中是可用的。
When the same client ID string is given to multiple IP addresses, the client can determine whether two IP addresses correspond to a single server, based on the server's behavior. This is the inverse of the strategy adopted for the non-uniform approach in which different
当向多个IP地址提供相同的客户端ID字符串时，客户端可以根据服务器的行为确定两个IP地址是否对应于单个服务器。这与非统一方法所采用的策略相反，其中
server IP addresses are told about different clients, simply to prevent a server from manifesting behavior that is inconsistent with there being a single server for each IP address, in line with the traditions of NFS. So, to compare:
服务器IP地址被告知不同的客户端，只是为了防止服务器表现出与每个IP地址都有一个服务器不一致的行为，这与NFS的传统一致。因此，比较一下：
o In the non-uniform approach, servers are told about different clients because, if the server were to use accurate client identity information, two IP addresses on the same server would behave as if they were talking to the same client, which might prove disconcerting to a client not expecting such behavior.
o 在非统一方法中，服务器被告知不同的客户端，因为如果服务器使用准确的客户端身份信息，同一服务器上的两个IP地址的行为将如同它们在与同一个客户端通信一样，这可能会使没有预期到这种行为的客户端感到不安。
o In the uniform approach, the servers are told about there being a single client, which is, after all, the truth. Then, when the server uses this information, two IP addresses on the same server will behave as if they are talking to the same client, and this difference in behavior allows the client to infer the server IP address trunking configuration, even though NFSv4.0 does not explicitly provide this information.
o 在统一的方法中，服务器被告知存在一个客户机，这毕竟是事实。然后，当服务器使用此信息时，同一服务器上的两个IP地址的行为就好像它们在与同一客户机通话一样，这种行为差异允许客户机推断服务器IP地址中继配置，即使NFSv4.0没有明确提供此信息。
The approach given in the section below shows one example of how this might be done.
下面一节中给出的方法展示了如何实现这一点的一个示例。
The uniform client ID string approach makes it necessary to exercise more care in the definition of the boot instance id sent as the verifier field in an nfs_client_id4:
统一客户端ID字符串方法使得在定义作为nfs_client_id4中的验证器字段发送的引导实例ID时需要更加小心：
o In [RFC7530], the client is told to change the verifier field value when reboot occurs, but there is no explicit statement as to the converse, so that any requirement to keep the verifier field constant unless rebooting is only present by implication.
o 在[RFC7530]中，客户机被告知在重新启动时更改验证器字段值，但没有关于相反的明确声明，因此任何保持验证器字段恒定的要求，除非重新启动仅暗示存在。
o Many existing clients change the boot instance id every time they destroy and recreate the data structure that tracks an <IP-address, clientid4> pair. This might happen if the last mount of a particular server is removed, and then a fresh mount is created. Also, note that this might result in each <IP-address, clientid4> pair having its own boot instance id that is independent of the others.
o 许多现有客户端在每次销毁和重新创建跟踪<IP地址，client4>对的数据结构时都会更改引导实例id。如果删除特定服务器的最后一次装载，然后创建新的装载，则可能会发生这种情况。另外，请注意，这可能会导致每个<IP地址，client4>对都有自己的启动实例id，该id独立于其他启动实例id。
o Within the uniform client ID string approach, an nfs_client_id4 designates a globally known client instance, so that the verifier field should change if and only if a new client instance is created, typically as a result of a reboot.
o 在统一客户机ID字符串方法中，nfs_客户机_id4指定一个全局已知的客户机实例，因此当且仅当创建了新的客户机实例（通常是由于重新启动）时，验证器字段才会更改。
Clients using the uniform client ID string approach are therefore well advised to use a verifier established only once for each reboot, typically at reboot time.
因此，建议使用统一客户端ID字符串方法的客户端在每次重新启动时使用仅建立一次的验证器，通常是在重新启动时。
The following are advantages for the implementation of using the uniform client ID string approach:
以下是使用统一客户端ID字符串方法实现的优势：
o Clients can take advantage of server trunking (and clustering with single-server-equivalent semantics) to increase bandwidth or reliability.
o 客户机可以利用服务器集群（以及具有单服务器等效语义的集群）来增加带宽或可靠性。
o There are advantages in state management so that, for example, one never has a delegation under one clientid4 revoked because of a reference to the same file from the same client under a different clientid4.
o 状态管理有很多优点，例如，一个客户机4下的委托不会因为引用了不同客户机4下同一客户机的同一文件而被撤销。
o The uniform client ID string approach allows the server to do any necessary automatic lease merger in connection with transparent state migration, without requiring any client involvement. This consideration is of sufficient weight to cause us to recommend use of the uniform client ID string approach for clients supporting transparent state migration.
o 统一客户端ID字符串方法允许服务器在透明状态迁移中执行任何必要的自动租赁合并，而无需任何客户端参与。考虑到这一点，我们建议对支持透明状态迁移的客户端使用统一客户端ID字符串方法。
The following implementation considerations might cause issues for client implementations.
以下实现注意事项可能会导致客户端实现出现问题。
o This approach is considerably different from the non-uniform approach, which most client implementations have been following. Until substantial implementation experience is obtained with this approach, reluctance to embrace something so new is to be expected.
o 这种方法与大多数客户机实现都遵循的非统一方法有很大不同。在使用这种方法获得大量的实施经验之前，不愿意接受如此新的东西是意料之中的。
o Mapping between server network addresses and leases is more complicated in that it is no longer a one-to-one mapping.
o 服务器网络地址和租约之间的映射更加复杂，因为它不再是一对一的映射。
Another set of relevant considerations relate to privacy concerns, which users of the client might have in that use of the uniform client ID string approach would enable multiple servers acting in concert to determine when multiple requests received at different times derive from the same NFSv4.0 client. For example, this might enable determination that multiple distinct user identities in fact are likely to correspond to requests made by the same person, even when those requests are directed to different servers.
另一组相关注意事项涉及隐私问题，客户机的用户在使用统一客户机ID字符串方法时可能会有隐私问题，这将使多个服务器协同工作，以确定在不同时间收到的多个请求何时来自同一NFSv4.0客户机。例如，这可以确定多个不同的用户身份实际上可能对应于同一个人发出的请求，即使这些请求被定向到不同的服务器。
How to balance these considerations depends on implementation goals.
如何平衡这些考虑因素取决于实施目标。
As noted above, a client that needs to use the uniform client ID string approach (e.g., to support migration) may also need to support existing servers with implementations that do not work properly in this case.
如上所述，需要使用统一客户机ID字符串方法（例如，支持迁移）的客户机可能还需要支持现有服务器，这些服务器的实现在这种情况下不能正常工作。
Some examples of such server issues include:
此类服务器问题的一些示例包括：
o Some existing NFSv4.0 server implementations of IP address failover depend on clients' use of a non-uniform client ID string approach. In particular, when a server supports both its own IP address and one failed over from a partner server, it may have separate sets of state applicable to the two IP addresses, owned by different servers but residing on a single one.
o IP地址故障切换的一些现有NFSv4.0服务器实现依赖于客户端使用非统一的客户端ID字符串方法。特别是，当服务器同时支持其自己的IP地址和一个从伙伴服务器故障转移的IP地址时，它可能具有适用于两个IP地址的单独状态集，这两个IP地址由不同的服务器拥有，但驻留在单个服务器上。
In this situation, some servers have relied on clients' use of the non-uniform client ID string approach, as suggested but not mandated by [RFC7530], to keep these sets of state separate, and they will have problems handling clients using the uniform client ID string approach, in that such clients will see changes in trunking relationships whenever server failover and giveback occur.
在这种情况下，一些服务器依赖于客户机使用非统一客户机ID字符串方法（如[RFC7530]所建议但未强制要求的）来保持这些状态集的独立性，并且它们在使用统一客户机ID字符串方法处理客户机时会遇到问题，在这种情况下，每当发生服务器故障切换和回馈时，这些客户机将看到中继关系的变化。
o Some existing servers incorrectly return NFS4ERR_CLID_INUSE simply because there already exists a clientid4 for the same client, established using a different IP address. This causes difficulty for a multihomed client using the uniform client ID string approach.
o 某些现有服务器错误地返回NFS4ERR_CLID_INUSE，原因很简单，因为已经存在使用不同IP地址建立的同一客户端的客户端4。这给使用统一客户端ID字符串方法的多宿主客户端带来了困难。
Although this behavior is not correct, such servers still exist, and this specification should give clients guidance about dealing with the situation, as well as making the correct behavior clear.
尽管这种行为不正确，但此类服务器仍然存在，并且本规范应该为客户机提供有关处理这种情况的指导，并明确正确的行为。
In order to support use of these sorts of servers, the client can use different client ID string approaches for different mounts, in order to assure that:
为了支持使用这些类型的服务器，客户机可以对不同的装载使用不同的客户机ID字符串方法，以确保：
o The uniform client ID string approach is used when accessing servers that may return NFS4ERR_MOVED and when the client wishes to enable transparent state migration.
o 当访问可能返回NFS4ERR_MOVED的服务器时，以及当客户端希望启用透明状态迁移时，使用统一客户端ID字符串方法。
o The non-uniform client ID string approach is used when accessing servers whose implementations make them incompatible with the uniform client ID string approach.
o 非统一客户端ID字符串方法用于访问服务器，这些服务器的实现使它们与统一客户端ID字符串方法不兼容。
Since the client cannot easily determine which of the above are true, implementations are likely to rely on user-specified mount options to select the appropriate approach to use, in cases in which a client supports simultaneous use of multiple approaches. Choice of a default to use in such cases is up to the client implementation.
由于客户机无法轻松确定上述哪种方法是正确的，因此在客户机支持同时使用多种方法的情况下，实现可能依赖于用户指定的装载选项来选择要使用的适当方法。在这种情况下使用默认值的选择取决于客户端实现。
In the case in which the same server has multiple mounts, and both approaches are specified for the same server, the client could have multiple clientid4s corresponding to the same server, one for each approach, and would then have to keep these separate.
如果同一服务器有多个装载，并且为同一服务器指定了两种方法，则客户端可能有多个对应于同一服务器的Client4，每种方法一个，然后必须将它们分开。
This section provides an example of how trunking determination could be done by a client following the uniform client ID string approach (whether this is used for all mounts or not). Clients need not follow this procedure, but implementers should make sure that the issues dealt with by this procedure are all properly addressed.
本节提供了一个示例，说明客户机如何按照统一客户机ID字符串方法进行中继确定（无论是否用于所有装载）。客户不需要遵循此过程，但是实现者应该确保此过程处理的问题都得到了正确的解决。
It is best to clarify here the various possible purposes of trunking determination and the corresponding requirements as to server behavior. The following points should be noted:
这里最好澄清中继确定的各种可能目的以及与服务器行为相关的相应要求。应注意以下几点：
o The primary purpose of the trunking determination algorithm is to make sure that, if the server treats client requests on two IP addresses as part of the same client, the client will not be surprised and encounter disconcerting server behavior, as mentioned in Section 5.6. Such behavior could occur if the client were unaware that all of its client requests for the two IP addresses were being handled as part of a single client talking to a single server.
o 中继确定算法的主要目的是确保，如第5.6节所述，如果服务器将两个IP地址上的客户端请求视为同一客户端的一部分，则客户端不会感到意外，也不会遇到令人不安的服务器行为。如果客户机不知道其对两个IP地址的所有客户机请求都作为与单个服务器通信的单个客户机的一部分进行处理，则可能会发生这种行为。
o A second purpose is to be able to use knowledge of trunking relationships for better performance, etc.
o 第二个目的是能够利用集群关系的知识获得更好的性能等。
o If a server were to give out distinct clientid4s in response to receiving the same nfs_client_id4 on different network addresses, and acted as if these were separate clients, the primary purpose of trunking determination would be met, as long as the server did not treat them as part of the same client. In this case, the server would be acting, with regard to that client, as if it were two distinct servers. This would interfere with the secondary purpose of trunking determination, but there is nothing the client can do about that.
o 如果服务器在不同的网络地址上接收相同的nfs_client_id4时发出不同的client4，并将其视为独立的客户端，则只要服务器不将它们视为同一客户端的一部分，就可以满足中继确定的主要目的。在本例中，服务器将针对该客户机进行操作，就好像它是两个不同的服务器一样。这将干扰中继确定的第二个目的，但客户端对此无能为力。
o Suppose a server were to give such a client two different clientid4s but act as if they were one. That is the only way that the server could behave in a way that would defeat the primary purpose of the trunking determination algorithm.
o 假设一个服务器给这样一个客户机两个不同的客户机4，但其行为就好像它们是一个一样。这是服务器的唯一行为方式，可能会破坏中继确定算法的主要目的。
Servers MUST NOT behave that way.
服务器不能这样做。
For a client using the uniform approach, clientid4 values are treated as important information in determining server trunking patterns.
对于使用统一方法的客户机，ClientI4值被视为确定服务器中继模式的重要信息。
For two different IP addresses to return the same clientid4 value is a necessary, though not a sufficient condition for them to be considered as connected to the same server. As a result, when two different IP addresses return the same clientid4, the client needs to determine, using the procedure given below or otherwise, whether the IP addresses are connected to the same server. For such clients, all internal recording of clientid4 values needs to include, whether explicitly or implicitly, identification of the server from which the clientid4 was received so that one always has a (server, clientid4) pair. Two such pairs from different servers are always considered distinct even when the clientid4 values are the same, as they may occasionally be.
对于两个不同的IP地址，返回相同的Client4值是必要的，但不是将它们视为连接到同一服务器的充分条件。因此，当两个不同的IP地址返回相同的Client4时，客户机需要使用下面给出的过程或其他方法确定IP地址是否连接到同一服务器。对于此类客户机，所有Client4值的内部记录都需要包括（无论是显式还是隐式）从中接收Client4的服务器的标识，以便始终具有（服务器，Client4）对。来自不同服务器的两个这样的对始终被认为是不同的，即使Client4值相同，有时也会如此。
In order to make this approach work, the client must have certain information accessible for each nfs_client_id4 used by the uniform approach (only one in general). The client needs to maintain a list of all server IP addresses, together with the associated clientid4 values, SETCLIENTID principals, and authentication flavors. As a part of the associated data structures, there should be the ability to mark a server IP structure as having the same server as another and to mark an IP address as currently unresolved. One way to do this is to allow each such entry to point to another with the pointer value being one of:
为了使这种方法能够工作，客户机必须为统一方法使用的每个nfs_客户机_id4（通常只有一个）提供某些可访问的信息。客户端需要维护所有服务器IP地址的列表，以及关联的Client4值、SETCLIENTID主体和身份验证样式。作为关联数据结构的一部分，应该能够将服务器IP结构标记为与另一个服务器具有相同的服务器，并将IP地址标记为当前未解析。一种方法是允许每个这样的条目指向另一个条目，指针值为：
o A pointer to another entry for an IP address associated with the same server, where that IP address is the first one referenced to access that server.
o 指向与同一服务器关联的IP地址的另一项的指针，其中该IP地址是访问该服务器时引用的第一个IP地址。
o A pointer to the current entry if there is no earlier IP address associated with the same server, i.e., where the current IP address is the first one referenced to access that server. The text below refers to such an IP address as the lead IP address for a given server.
o 如果没有与同一服务器关联的早期IP地址，即当前IP地址是访问该服务器引用的第一个IP地址，则指向当前条目的指针。下面的文本将此类IP地址称为给定服务器的lead IP地址。
o The value NULL if the address's server identity is currently unresolved.
o 如果地址的服务器标识当前未解析，则该值为NULL。
In order to keep the above information current, in the interests of the most effective trunking determination, RENEWs should be periodically done on each server. However, even if this is not done, the primary purpose of the trunking determination algorithm, to prevent confusion due to trunking hidden from the client, will be achieved.
为了使上述信息保持最新，为了最有效地确定中继，应定期在每台服务器上进行更新。但是，即使不这样做，也可以实现中继确定算法的主要目的，以防止由于对客户端隐藏中继而造成混淆。
Given this apparatus, when a SETCLIENTID is done and a clientid4 returned, the data structure can be searched for a matching clientid4 and if such is found, further processing can be done to determine whether the clientid4 match is accidental, or the result of trunking.
给定该设备，当完成SETCLIENTID并且返回client4时，可以在数据结构中搜索匹配的client4，并且如果找到匹配的client4，则可以进行进一步处理以确定client4匹配是偶然的还是中继的结果。
In this algorithm, when SETCLIENTID is done initially, it will use the common nfs_client_id4 and specify the current target IP address as callback.cb_location within the callback parameters. We call the clientid4 and SETCLIENTID verifier returned by this operation XC and XV, respectively.
在该算法中，最初完成SETCLIENTID时，它将使用公共nfs_客户端_id4，并在回调参数中指定当前目标IP地址为callback.cb_位置。我们分别调用这个操作返回的client4和SETCLIENTID验证器XC和XV。
This choice of callback parameters is provisional and reflects the client's preferences in the event that the IP address is not trunked with other IP addresses. The algorithm is constructed so that only the appropriate callback parameters, reflecting observed trunking patterns, are actually confirmed.
此回调参数的选择是临时的，反映了在IP地址未与其他IP地址集群时客户端的首选项。构造该算法的目的是为了实际确认反映观察到的中继模式的适当回调参数。
Note that when the client has done previous SETCLIENTIDs to any IP addresses, with more than one principal or authentication flavor, one has the possibility of receiving NFS4ERR_CLID_INUSE, since it is not yet known which of the connections with existing IP addresses might be trunked with the current one. In the event that the SETCLIENTID fails with NFS4ERR_CLID_INUSE, one must try all other combinations of principals and authentication flavors currently in use, and eventually one will be correct and not return NFS4ERR_CLID_INUSE.
请注意，当客户端使用多个主体或身份验证风格对任何IP地址执行以前的setClientID时，就有可能接收NFS4ERR_CLID_INUSE，因为还不知道哪些具有现有IP地址的连接可能与当前IP地址进行中继。如果SETCLIENTID在使用NFS4ERR_CLID_INUSE时失败，则必须尝试当前使用的主体和身份验证风格的所有其他组合，最终一个组合将是正确的，并且不会返回NFS4ERR_CLID_INUSE。
Note that at this point, no SETCLIENTID_CONFIRM has yet been done. This is because the SETCLIENTID just done has either established a new clientid4 on a previously unknown server or changed the callback parameters on a clientid4 associated with some already known server. Given it is undesirable to confirm something that should not happen, what is to be done next depends on information about existing clientid4s.
请注意，此时尚未执行SETCLIENTID_确认。这是因为刚刚完成的SETCLIENTID要么在以前未知的服务器上建立了新的Client4，要么在与某些已知服务器关联的Client4上更改了回调参数。鉴于不希望确认不应该发生的事情，接下来要做什么取决于现有客户的信息4。
o If no matching clientid4 is found, the IP address X and clientid4 XC are added to the list and considered as having no existing known IP addresses trunked with it. The IP address is marked as a lead IP address for a new server. A SETCLIENTID_CONFIRM is done using XC and XV.
o 如果未找到匹配的Client4，则IP地址X和Client4 XC将添加到列表中，并被视为没有与之集群的现有已知IP地址。IP地址被标记为新服务器的lead IP地址。使用XC和XV完成SETCLIENTID_确认。
o If a matching clientid4 is found that is marked unresolved, processing on the new IP address is suspended. In order to simplify processing, there can only be one unresolved IP address for any given clientid4.
o 如果找到标记为未解析的匹配Client4，则暂停对新IP地址的处理。为了简化处理，对于任何给定的客户端4，只能有一个未解析的IP地址。
o If one or more matching clientid4s are found, none of which are marked unresolved, the new IP address X is entered and marked unresolved. A SETCLIENTID_CONFIRM is done to X using XC and XV.
o 如果找到一个或多个匹配的client4，其中没有一个标记为未解析，则输入新的IP地址X并标记为未解析。使用XC和XV对X进行SETCLIENTID_确认。
When, as a result of encountering the last of the three cases shown above, an unresolved IP address exists, further processing is required. After applying the steps below to each of the lead IP addresses with a matching clientid4, the address will have been
当遇到上述三种情况中的最后一种情况时，存在未解析的IP地址，需要进一步处理。将以下步骤应用于具有匹配客户端4的每个lead IP地址后，该地址将被删除
resolved: It may have been determined to be part of an already known server as a new IP address to be added to an existing set of IP addresses for that server. Otherwise, it will be recognized as a new server. At the point at which this determination is made, the unresolved indication is cleared and any suspended SETCLIENTID processing is restarted.
已解决：它可能已被确定为已知服务器的一部分，作为要添加到该服务器的现有IP地址集的新IP地址。否则，它将被识别为新服务器。在进行此确定时，将清除未解析指示，并重新启动任何挂起的SETCLIENTID处理。
For each lead IP address IPn with a clientid4 matching XC, the following steps are done. Because the Remote Procedure Call (RPC) to do a SETCLIENTID could take considerable time, it is desirable for the client to perform these operations in parallel. Note that because the clientid4 is a 64-bit value, the number of such IP addresses that would need to be tested is expected to be quite small, even when the client is interacting with many NFSv4.0 servers. Thus, while parallel processing is desirable, it is not necessary.
对于具有与XC匹配的Client4的每个lead IP地址IPn，执行以下步骤。由于执行SETCLIENTID的远程过程调用（RPC）可能需要相当长的时间，因此客户端需要并行执行这些操作。请注意，由于client4是64位值，因此需要测试的此类IP地址的数量预计将非常少，即使客户端与许多NFSv4.0服务器交互时也是如此。因此，虽然需要并行处理，但没有必要。
o If the principal for IPn does not match that for X, the IP address is skipped, since it is impossible for IPn and X to be trunked in these circumstances. If the principal does match but the authentication flavor does not, the authentication flavor already used should be used for address X as well. This will avoid any possibility that NFS4ERR_CLID_INUSE will be returned for the SETCLIENTID and SETCLIENTID_CONFIRM to be done below, as long as the server(s) at IP addresses IPn and X is correctly implemented.
o 如果IPn的主体与X的主体不匹配，则跳过IP地址，因为在这些情况下IPn和X不可能进行集群。如果主体不匹配，但身份验证风格不匹配，那么已经使用的身份验证风格也应该用于地址X。只要IP地址IPn和X处的服务器正确实现，这将避免为下面执行的SETCLIENTID和SETCLIENTID确认返回NFS4ERR_CLID_INUSE的任何可能性。
o A SETCLIENTID is done to update the callback parameters to reflect the possibility that X will be marked as associated with the server whose lead IP address is IPn. The specific callback parameters chosen, in terms of cb_client4 and callback_ident, are up to the client and should reflect its preferences as to callback handling for the common clientid4, in the event that X and IPn are trunked together. When a SETCLIENTID is done on IP address IPn, a setclientid_confirm value (in the form of a verifier4) is returned, which will be referred to as SCn.
o SETCLIENTID用于更新回调参数，以反映X将被标记为与主IP地址为IPn的服务器关联的可能性。根据cb_client4和callback_ident选择的特定回调参数由客户端决定，并应反映其在X和IPn集群在一起时对公共client4回调处理的偏好。在IP地址IPn上执行SETCLIENTID时，将返回一个SETCLIENTID_确认值（以验证器4的形式），该值称为SCn。
Note that the NFSv4.0 specification requires the server to make sure that such verifiers are very unlikely to be regenerated. Given that it is already highly unlikely that the clientid4 XC is duplicated by distinct servers, the probability that SCn is duplicated as well has to be considered vanishingly small. Note also that the callback update procedure can be repeated multiple times to reduce the probability of further spurious matches.
注意，NFSv4.0规范要求服务器确保不太可能重新生成此类验证器。考虑到不同的服务器复制Client4 XC的可能性已经很小，SCn被复制的可能性也必须被认为是非常小的。还要注意，回调更新过程可以重复多次，以减少进一步虚假匹配的可能性。
o The setclientid_confirm value SCn is saved for later use in confirming the SETCLIENTID done to IPn.
o 保存setclientid_确认值SCn，以便以后在确认setclientid是否完成IPn时使用。
Once the SCn values are gathered up by the procedure above, they are each tested by being used as the verifier for a SETCLIENTID_CONFIRM operation directed to the original IP address X, whose trunking relationships are to be determined. These RPC operations may be done in parallel.
一旦通过上述程序收集到SCn值，它们将被用作指向原始IP地址X的SETCLIENTID_CONFIRM操作的验证器进行测试，其中继关系有待确定。这些RPC操作可以并行完成。
There are a number of things that should be noted at this point.
在这一点上有许多事情需要注意。
o The SETCLIENTID operations done on the various IPn addresses in the procedure above will never be confirmed by SETCLIENTID_CONFIRM operations directed to the various IPn addresses. If these callback updates are to be confirmed, they will be confirmed by SETCLIENTID_CONFIRM operations directed at the original IP address X, which can only happen if SCn was generated by an IPn that was trunked with X, allowing the SETCLIENTID to be successfully confirmed and allowing us to infer the existence of that trunking relationship.
o 在上述过程中对各种IPn地址执行的SETCLIENTID操作将永远不会被定向到各种IPn地址的SETCLIENTID_确认操作确认。如果要确认这些回调更新，它们将由针对原始IP地址X的SETCLIENTID_确认操作进行确认，这只有在SCn由与X进行中继的IPn生成时才会发生，从而允许成功确认SETCLIENTID，并允许我们推断中继关系的存在。
o The number of successful SETCLIENTID_CONFIRM operations done should never be more than one. If both SCn and SCm are accepted by X, then it indicates that both IPn and IPm are trunked with X, but that is only possible if IPn and IPm are trunked together. Since these two addresses were earlier recognized as not trunked together, this should be impossible, if the servers in question are implemented correctly.
o 成功完成的SETCLIENTID_CONFIRM操作数不得超过一个。如果X同时接受SCn和SCm，则表明IPn和IPm都使用X进行集群，但只有在IPn和IPm集群在一起时才可能。由于这两个地址在早期被识别为未聚合在一起，如果所讨论的服务器实现正确，这应该是不可能的。
Further processing depends on the success or failure of the various SETCLIENTD_CONFIRM operations done in the step above.
进一步处理取决于上述步骤中完成的各种SETCLIENTD_确认操作的成功与否。
o If the setclientid_confirm value generated by a particular IPn is accepted on X, then X and IPn are recognized as connected to the same server, and the entry for X is marked as associated with IPn.
o 如果特定IPn生成的setclientid_确认值在X上被接受，则X和IPn被识别为连接到同一服务器，并且X的条目被标记为与IPn关联。
o If none of the confirm operations are accepted, then X is recognized as a distinct server. Its callback parameters will remain as the ones established by the original SETCLIENTID.
o 如果不接受任何确认操作，则将X识别为不同的服务器。它的回调参数将保留为原始SETCLIENTID所建立的参数。
In either of the cases, the entry is considered resolved and processing can be restarted for IP addresses whose clientid4 matched XC but whose resolution had been deferred.
在这两种情况下，条目都被视为已解析，并且对于其client4与XC匹配但其解析已被延迟的IP地址，可以重新启动处理。
The procedure described above must be performed so as to exclude the possibility that multiple SETCLIENTIDs done to different server IP addresses and returning the same clientid4 might "race" in such a fashion that there is no explicit determination of whether they correspond to the same server. The following possibilities for serialization are all valid, and implementers may choose among them
必须执行上述过程，以排除对不同服务器IP地址执行多个SetClientID并返回相同Client4的可能性，因为它们可能“竞争”，无法明确确定它们是否对应于同一服务器。以下序列化的可能性都是有效的，实现者可以从中进行选择
based on a tradeoff between performance and complexity. They are listed in order of increasing parallelism:
基于性能和复杂性之间的权衡。它们按增加并行性的顺序列出：
o An NFSv4.0 client might serialize all instances of SETCLIENTID/ SETCLIENTID_CONFIRM processing, either directly or by serializing mount operations involving use of NFSv4.0. While doing so will prevent the races mentioned above, this degree of serialization can cause performance issues when there is a high volume of mount operations.
o NFSv4.0客户端可以直接或通过序列化涉及使用NFSv4.0的装载操作来序列化SETCLIENTID/SETCLIENTID_确认处理的所有实例。虽然这样做将防止上述竞争，但当装载操作量很大时，这种序列化程度可能会导致性能问题。
o One might instead serialize the period of processing that begins when the clientid4 received from the server is processed and ends when all trunking determination for that server is completed. This prevents the races mentioned above, without adding to delay except when trunking determination is common.
o 相反，可以序列化处理周期，该周期从处理从服务器接收的client4开始，到完成该服务器的所有中继确定时结束。这可以防止上面提到的竞争，而不会增加延迟，除非中继确定是常见的。
o One might avoid much of the serialization implied above, by allowing trunking determination for distinct clientid4 values to happen in parallel, with serialization of trunking determination happening independently for each distinct clientid4 value.
o 通过允许并行地对不同的Client4值进行中继确定，而对每个不同的Client4值分别进行中继确定的序列化，可以避免上面暗示的大部分序列化。
The procedure above has made no explicit mention of the possibility that server reboot can occur at any time. To address this possibility, the client should make sure the following steps are taken:
上面的过程没有明确提到服务器随时可能重新启动的可能性。为了解决这种可能性，客户应确保采取以下步骤：
o When a SETCLIENTID_CONFIRM is rejected by a given IPn, the client should be aware of the possibility that the rejection is due to XC (rather than XV) being invalid. This situation can be addressed by doing a RENEW specifying XC directed to the IP address X. If that operation succeeds, then the rejection is to be acted on normally since either XV is invalid on IPn or XC has become invalid on IPn while it is valid on X, showing that IPn and X are not trunked. If, on the other hand, XC is not valid on X, then the trunking detection process should be restarted once a new client ID is established on X.
o 当给定IPn拒绝SETCLIENTID_确认时，客户应意识到拒绝的可能性是由于XC（而不是XV）无效。这种情况可以通过执行RENEW来解决，该RENEW指定XC指向IP地址X。如果该操作成功，则拒绝将正常进行，因为XV在IPn上无效，或者XC在IPn上无效，而在X上有效，这表明IPn和X没有集群。另一方面，如果XC在X上无效，则在X上建立新的客户端ID后，应重新启动中继检测过程。
o In the event of a reboot detected on any server-lead IP, the set of IP addresses associated with the server should not change, and state should be re-established for the lease as a whole, using all available connected server IP addresses. It is prudent to verify connectivity by doing a RENEW using the new clientid4 on each such server address before using it, however.
o 如果在任何服务器引导IP上检测到重新启动，则与服务器关联的IP地址集不应更改，并且应使用所有可用连接的服务器IP地址重新建立整个租约的状态。不过，谨慎的做法是，在使用之前，在每个这样的服务器地址上使用新的client4进行续订，以验证连接。
Another situation not discussed explicitly above is the possibility that a SETCLIENTID done to one of the IPn addresses might take so long that it is necessary to time out the operation, to prevent unacceptably delaying the MOUNT operation. One simple possibility is
上面没有明确讨论的另一种情况是，对其中一个IPn地址执行SETCLIENTID可能需要很长时间，因此有必要暂停操作，以防止不可接受地延迟装载操作。一个简单的可能性是
to simply fail the MOUNT at this point. Because the average number of IP addresses that might have to be tested is quite small, this will not greatly increase the probability of MOUNT failure. Other possible approaches are:
在这一点上使挂载失败。因为可能需要测试的IP地址的平均数量非常小，这不会大大增加装载失败的概率。其他可能的办法包括：
o If the IPn has sufficient state in existence, the existing stateids and sequence values might be validated by being used on IP address X. In the event of success, X and IPn should be considered trunked together.
o 如果IPn存在足够的状态，则可以通过在IP地址X上使用现有的StateID和序列值来验证。如果成功，则应将X和IPn视为集群。
What constitutes "sufficient" state in this context is an implementation decision that is affected by the implementer's willingness to fail the MOUNT in an uncertain case and the strength of the state verification procedure implemented.
在这种情况下，构成“充分”状态的是一项实施决策，该决策受实施者在不确定情况下不通过装载的意愿以及实施的状态验证程序的强度的影响。
o If IPn has no locking state in existence, X could be recorded as a lead IP address on a provisional basis, subject to trunking being tested again, once IPn starts becoming responsive. To avoid confusion between IPn and X, and the need to merge distinct state corpora for X and IPn at a later point, this retest of trunking should occur after RENEWs on IPn are responded to and before establishing any new state for either IPn as a separate server or for IPn considered as a server address trunked with X.
o 如果IPn不存在锁定状态，一旦IPn开始响应，X可以临时记录为lead IP地址，但中继将再次测试。为了避免IPn和X之间的混淆，以及在以后需要合并X和IPn的不同状态语料库，应在响应IPn上的续订之后，以及在将IPn作为单独服务器或IPn作为与X中继的服务器地址建立任何新状态之前，重新测试中继。
o The client locking-related code could be made more tolerant of what would otherwise be considered anomalous results due to an unrecognized trunking relationship. The client could use the appearance of behavior explainable by a previously unknown trunking relationship as the cue to consider the addresses as trunked.
o 与客户端锁定相关的代码可以更加容忍由于无法识别的中继关系而导致的异常结果。客户端可以使用由先前未知的中继关系解释的行为的外观作为将地址视为集群的线索。
This choice has a lot of complexity associated with it, and it is likely that few implementations will use it. When the set of locking state on IPn is small (e.g., a single stateid) but not empty, most client implementations are likely to either fail the MOUNT or implement a more stringent verification procedure using the existing stateid on IPn as a basis to generate further state as raw material for the trunking verification process.
这种选择有很多与之相关的复杂性，可能很少有实现会使用它。当IPn上的锁定状态集很小（例如，单个stateid）但不为空时，大多数客户端实现可能会导致装载失败，或者使用IPn上现有的stateid作为基础来实现更严格的验证过程，以生成进一步的状态作为中继验证过程的原材料。
This section gives more detailed guidance on client ID string construction. The guidance in this section will cover cases in which either the uniform or the non-uniform approach to the client ID string is used.
本节提供有关客户端ID字符串构造的更详细指导。本节中的指南将涵盖对客户端ID字符串使用统一或非统一方法的情况。
Note that among the items suggested for inclusion, there are many that may conceivably change. In order for the client ID string to remain valid in such circumstances, the client SHOULD either:
请注意，在建议纳入的项目中，有许多可能发生变化。为了使客户端ID字符串在这种情况下保持有效，客户端应：
o Use a saved copy of such value rather than the changeable value itself, or
o 使用该值的保存副本，而不是可变值本身，或
o Save the constructed client ID string rather than constructing it anew at SETCLIENTID time, based on unchangeable parameters and saved copies of changeable data items.
o 根据不可更改的参数和保存的可更改数据项副本，保存构造的客户端ID字符串，而不是在SETCLIENTID时间重新构造它。
A file is not always a valid choice to store such information, given the existence of diskless clients. In such situations, whatever facilities exist for a client to store configuration information such as boot arguments should be used.
考虑到无盘客户机的存在，文件并不总是存储此类信息的有效选择。在这种情况下，应该使用客户机存储配置信息（如引导参数）的任何设施。
Given the considerations listed in Section 5.2.1, an id string would be one that includes as its basis:
考虑到第5.2.1节中列出的注意事项，id字符串应包括以下内容作为其基础：
o An identifier uniquely associated with the node on which the client is running.
o 与运行客户端的节点唯一关联的标识符。
o For a user-level NFSv4.0 client, it should contain additional information to distinguish the client from a kernel-based client and from other user-level clients running on the same node, such as a universally unique identifier (UUID).
o 对于用户级NFSv4.0客户端，它应该包含其他信息，以便将客户端与基于内核的客户端以及运行在同一节点上的其他用户级客户端区分开来，例如通用唯一标识符（UUID）。
o Where the non-uniform approach is to be used, the IP address of the server.
o 如果使用非统一方法，则为服务器的IP地址。
o Additional information that tends to be unique, such as one or more of:
o 倾向于唯一的附加信息，例如一个或多个：
* The timestamp of when the NFSv4 software was first installed on the client (though this is subject to the previously mentioned caution about using information that is stored in a file, because the file might only be accessible over NFSv4).
* NFSv4软件首次安装到客户端时的时间戳（尽管这取决于前面提到的关于使用存储在文件中的信息的注意事项，因为该文件可能只能通过NFSv4访问）。
* A true random number, generally established once and saved.
* 一个真正的随机数，通常建立一次并保存。
With regard to the identifier associated with the node on which the client is running, the following possibilities are likely candidates.
关于与运行客户端的节点相关联的标识符，以下可能性可能是候选的。
o The client machine's serial number.
o 客户端计算机的序列号。
o The client's IP address. Note that this SHOULD be treated as a changeable value.
o 客户端的IP地址。请注意，这应视为一个可变值。
o A Media Access Control (MAC) address. Note that this also should be considered a changeable value because of the possibility of configuration changes.
o 媒体访问控制（MAC）地址。请注意，由于可能发生配置更改，这也应被视为一个可变值。
Privacy concerns may be an issue if some of the items above (e.g., machine serial number and MAC address) are used. When it is necessary to use such items to ensure uniqueness, application of a one-way hash function is desirable. When the non-uniform approach is used, that hash function should be applied to all of the components chosen as a unit rather than to particular individual elements.
如果使用上述某些项目（例如，机器序列号和MAC地址），可能会引起隐私问题。当需要使用这些项以确保唯一性时，需要应用单向散列函数。当使用非统一方法时，该散列函数应应用于作为一个单元选择的所有组件，而不是特定的单个元素。
This section contains a replacement for Section 9.14 of [RFC7530], "Migration, Replication, and State".
本节替换了[RFC7530]第9.14节“迁移、复制和状态”。
The replacement is in Section 6.1 and supersedes the replaced section.
替换内容见第6.1节，并取代替换部分。
The changes made can be briefly summarized as follows:
所做的更改可简要总结如下：
o Adding text to address the case of stateid conflict on migration.
o 添加文本以解决迁移时stateid冲突的情况。
o Specifying that when leases are moved, as a result of file system migration, they are to be merged with leases on the destination server that are connected to the same client.
o 指定由于文件系统迁移而移动租约时，这些租约将与连接到同一客户端的目标服务器上的租约合并。
o Adding text that deals with the case of a clientid4 being changed on state transfer as a result of conflict with an existing clientid4.
o 添加文本，处理由于与现有Client4冲突而在状态转移时更改Client4的情况。
o Adding a section describing how information associated with open-owners and lock-owners is to be managed with regard to migration.
o 添加一节，描述如何在迁移方面管理与开放所有者和锁所有者关联的信息。
o The description of handling of the NFS4ERR_LEASE_MOVED has been rewritten for greater clarity.
o 为了更加清晰，对NFS4ERR_LEASE_MOVED处理的描述已经重写。
File systems may transition to a different server in several circumstances:
在几种情况下，文件系统可能会转换到不同的服务器：
o Responsibility for handling a given file system is transferred to a new server via migration.
o 处理给定文件系统的责任通过迁移转移到新服务器。
o A client may choose to use an alternate server (e.g., in response to server unresponsiveness) in the context of file system replication.
o 客户端可以在文件系统复制的上下文中选择使用备用服务器（例如，响应服务器无响应）。
In such cases, the appropriate handling of state shared between the client and server (i.e., locks, leases, stateids, and client IDs) is as described below. The handling differs between migration and replication.
在这种情况下，客户端和服务器之间共享的状态（即锁、租约、stateID和客户端ID）的适当处理如下所述。迁移和复制的处理方式不同。
If a server replica or a server immigrating a file system agrees to, or is expected to, accept opaque values from the client that originated from another server, then it is a wise implementation practice for the servers to encode the "opaque" values in network byte order (i.e., in a big-endian format). When doing so, servers acting as replicas or immigrating file systems will be able to parse values like stateids, directory cookies, filehandles, etc., even if their native byte order is different from that of other servers cooperating in the replication and migration of the file system.
如果服务器副本或迁移文件系统的服务器同意或预期接受来自另一台服务器的客户端的不透明值，则服务器以网络字节顺序（即，以big-endian格式）对“不透明”值进行编码是明智的实现做法。执行此操作时，充当副本或迁移文件系统的服务器将能够解析stateID、目录cookie、文件句柄等值，即使其本机字节顺序与在文件系统复制和迁移过程中协作的其他服务器的本机字节顺序不同。
In the case of migration, the servers involved in the migration of a file system should transfer all server state associated with the migrating file system from source to the destination server. If state is transferred, this MUST be done in a way that is transparent to the client. This state transfer will ease the client's transition when a file system migration occurs. If the servers are successful in transferring all state, the client will continue to use stateids assigned by the original server. Therefore, the new server must recognize these stateids as valid and treat them as representing the same locks as they did on the source server.
在迁移的情况下，参与文件系统迁移的服务器应将与迁移文件系统关联的所有服务器状态从源服务器传输到目标服务器。如果传输状态，则必须以对客户端透明的方式进行。当发生文件系统迁移时，此状态传输将简化客户端的转换。如果服务器成功传输所有状态，客户端将继续使用原始服务器分配的StateID。因此，新服务器必须将这些stateID识别为有效，并将它们视为与源服务器上的锁相同的锁。
In this context, the phrase "the same locks" means that:
在此上下文中，“相同的锁”表示：
o They are associated with the same file.
o 它们与同一文件相关联。
o They represent the same types of locks, whether opens, delegations, advisory byte-range locks, or mandatory byte-range locks.
o 它们表示相同类型的锁，无论是打开锁、委派锁、建议字节范围锁还是强制字节范围锁。
o They have the same lock particulars, including such things as access modes, deny modes, and byte ranges.
o 它们具有相同的锁细节，包括访问模式、拒绝模式和字节范围。
o They are associated with the same owner string(s).
o 它们与相同的所有者字符串相关联。
If transferring stateids from server to server would result in a conflict for an existing stateid for the destination server with the existing client, transparent state migration MUST NOT happen for that client. Servers participating in using transparent state migration should coordinate their stateid assignment policies to make this situation unlikely or impossible. The means by which this might be done, like all of the inter-server interactions for migration, are
如果将stateid从服务器传输到服务器会导致目标服务器的现有stateid与现有客户端发生冲突，则该客户端不得进行透明状态迁移。参与使用透明状态迁移的服务器应协调其stateid分配策略，以避免出现这种情况。与迁移的所有服务器间交互一样，实现这一点的方法是
not specified by the NFS version 4.0 protocol (neither in [RFC7530] nor this update).
未由NFS版本4.0协议指定（在[RFC7530]或本更新中均未指定）。
A client may determine the disposition of migrated state by using a stateid associated with the migrated state on the new server.
客户端可以通过使用与新服务器上的迁移状态关联的stateid来确定迁移状态的处置。
o If the stateid is not valid and an error NFS4ERR_BAD_STATEID is received, either transparent state migration has not occurred or the state was purged due to a mismatch in the verifier (i.e., the boot instance id).
o 如果stateid无效，并且收到错误NFS4ERR_BAD_stateid，则可能是由于未发生透明状态迁移，或者是由于验证器（即启动实例id）不匹配而清除了状态。
o If the stateid is valid, transparent state migration has occurred.
o 如果stateid有效，则已发生透明状态迁移。
Since responsibility for an entire file system is transferred with a migration event, there is no possibility that conflicts will arise on the destination server as a result of the transfer of locks.
由于整个文件系统的责任是通过迁移事件转移的，因此不可能由于锁的转移而在目标服务器上产生冲突。
The servers may choose not to transfer the state information upon migration. However, this choice is discouraged, except where specific issues such as stateid conflicts make it necessary. When a server implements migration and it does not transfer state information, it MUST provide a file-system-specific grace period, to allow clients to reclaim locks associated with files in the migrated file system. If it did not do so, clients would have to re-obtain locks, with no assurance that a conflicting lock was not granted after the file system was migrated and before the lock was re-obtained.
服务器可以选择在迁移时不传输状态信息。但是，不鼓励这种选择，除非特定问题（如stateid冲突）需要这样做。当服务器执行迁移而不传输状态信息时，它必须提供特定于文件系统的宽限期，以允许客户端回收与迁移的文件系统中的文件相关联的锁。如果不这样做，客户端将不得不重新获取锁，而不能保证在迁移文件系统之后和重新获取锁之前不会授予冲突的锁。
In the case of migration without state transfer, when the client presents state information from the original server (e.g., in a RENEW operation or a READ operation of zero length), the client must be prepared to receive either NFS4ERR_STALE_CLIENTID or NFS4ERR_BAD_STATEID from the new server. The client should then recover its state information as it normally would in response to a server failure. The new server must take care to allow for the recovery of state information as it would in the event of server restart.
在没有状态传输的迁移情况下，当客户端从原始服务器（例如，在续订操作或零长度读取操作中）显示状态信息时，客户端必须准备从新服务器接收NFS4ERR_STALE_CLIENTID或NFS4ERR_BAD_STATEID。然后，客户机应恢复其状态信息，这与正常情况下响应服务器故障时一样。新服务器必须注意恢复状态信息，就像服务器重新启动时一样。
In those situations in which state has not been transferred, as shown by a return of NFS4ERR_BAD_STATEID, the client may attempt to reclaim locks in order to take advantage of cases in which the destination server has set up a file-system-specific grace period in support of the migration.
在未传输状态的那些情况下，如返回NFS4ERR_BAD_STATEID所示，客户端可能会尝试回收锁，以便利用目标服务器已设置文件系统特定宽限期以支持迁移的情况。
The handling of clientid4 values is similar to that for stateids. However, there are some differences that derive from the fact that a clientid4 is an object that spans multiple file systems while a stateid is inherently limited to a single file system.
clientid4值的处理与StateID的处理类似。但是，由于client4是一个跨越多个文件系统的对象，而stateid本质上仅限于单个文件系统，因此存在一些差异。
The clientid4 and nfs_client_id4 information (id string and boot instance id) will be transferred with the rest of the state information, and the destination server should use that information to determine appropriate clientid4 handling. Although the destination server may make state stored under an existing lease available under the clientid4 used on the source server, the client should not assume that this is always so. In particular,
Client4和nfs_client_id4信息（id字符串和启动实例id）将与其余状态信息一起传输，目标服务器应使用该信息来确定适当的Client4处理。尽管目标服务器可能会使存储在现有租约下的状态在源服务器上使用的client4下可用，但客户端不应假定总是这样。特别地，
o If there is an existing lease with an nfs_client_id4 that matches a migrated lease (same id string and verifier), the server SHOULD merge the two, making the union of the sets of stateids available under the clientid4 for the existing lease. As part of the lease merger, the expiration time of the lease will reflect renewal done within either of the ancestor leases (and so will reflect the latest of the renewals).
o 如果存在与迁移的租约（相同的id字符串和验证器）匹配的nfs_客户端_id4的现有租约，则服务器应将两者合并，使现有租约的clientid4下的StateID集的联合可用。作为租赁合并的一部分，租赁的到期时间将反映在任一祖先租赁内进行的续约（因此将反映最新的续约）。
o If there is an existing lease with an nfs_client_id4 that partially matches a migrated lease (same id string and a different (boot) verifier), the server MUST eliminate one of the two, possibly invalidating one of the ancestor clientid4s. Since boot instance ids are not ordered, the later lease renewal time will prevail.
o 如果存在一个nfs_client_id4的现有租约部分匹配迁移的租约（相同的id字符串和不同的（启动）验证器），则服务器必须消除这两个租约中的一个，可能使一个祖先Client4无效。由于启动实例ID未排序，因此以较晚的租约续订时间为准。
o If the destination server already has the transferred clientid4 in use for another purpose, it is free to substitute a different clientid4 and associate that with the transferred nfs_client_id4.
o 如果目标服务器已将传输的Client4用于其他目的，则可以随意替换其他Client4，并将其与传输的nfs_客户端_id4关联。
When leases are not merged, the transfer of state should result in creation of a confirmed client record with empty callback information but matching the {v, x, c} with v and x derived from the transferred client information and c chosen by the destination server. For a description of this notation, see Section 8.4.5
当租约未合并时，状态转移应导致创建一个确认的客户端记录，其中包含空回调信息，但将{v，x，c}与从转移的客户端信息派生的v和x以及目标服务器选择的c相匹配。有关此符号的说明，请参见第8.4.5节
In such cases, the client SHOULD re-establish new callback information with the new server as soon as possible, according to sequences described in sections "Operation 35: SETCLIENTID -- Negotiate Client ID" and "Operation 36: SETCLIENTID_CONFIRM -- Confirm Client ID". This ensures that server operations are not delayed due to an inability to recall delegations and prevents the
在这种情况下，客户机应根据“操作35:SETCLIENTID——协商客户机ID”和“操作36:SETCLIENTID_确认——确认客户机ID”部分中描述的顺序，尽快与新服务器重新建立新的回调信息。这可确保服务器操作不会因无法调用委派而延迟，并防止
unwanted revocation of existing delegations. The client can determine the new clientid4 (the value c) from the response to SETCLIENTID.
不必要地撤销现有授权。客户端可以从对SETCLIENTID的响应中确定新的Client4（值c）。
The client can use its own information about leases with the destination server to see if lease merger should have happened. When there is any ambiguity, the client MAY use the above procedure to set the proper callback information and find out, as part of the process, the correct value of its clientid4 with respect to the server in question.
客户机可以使用自己关于与目标服务器的租约的信息来查看是否应该发生租约合并。当存在任何歧义时，客户端可以使用上述过程来设置适当的回调信息，并作为过程的一部分，找出其client4相对于所述服务器的正确值。
In addition to stateids, the locks they represent, and client identity information, servers also need to transfer information related to the current status of open-owners and lock-owners.
除了stateID、它们所表示的锁以及客户端标识信息之外，服务器还需要传输与开放所有者和锁所有者的当前状态相关的信息。
This information includes:
这些信息包括：
o The sequence number of the last operation associated with the particular owner.
o 与特定所有者关联的最后一个操作的序列号。
o Sufficient information regarding the results of the last operation to allow reissued operations to be correctly responded to.
o 有关上次操作结果的足够信息，以允许正确响应重新发布的操作。
When individual open-owners and lock-owners have only been used in connection with a particular file system, the server SHOULD transfer this information together with the lock state. The owner ceases to exist on the source server and is reconstituted on the destination server. This will happen in the case of clients that have been written to isolate each owner to a specific file system, but it may happen for other clients as well.
当单个打开所有者和锁所有者仅用于特定文件系统时，服务器应将此信息与锁状态一起传输。所有者在源服务器上不再存在，并在目标服务器上重新配置。在编写客户机以将每个所有者隔离到特定文件系统的情况下会发生这种情况，但在其他客户机上也可能发生这种情况。
Note that when servers take this approach for all owners whose state is limited to the particular file system being migrated, doing so will not cause difficulties for clients not adhering to an approach in which owners are isolated to particular file systems. As long as the client recognizes the loss of transferred state, the protocol allows the owner in question to disappear, and the client may have to deal with an owner confirmation request that would not have occurred in the absence of the migration.
请注意，当服务器对其状态仅限于要迁移的特定文件系统的所有所有者采取此方法时，这样做不会给不遵守所有者与特定文件系统隔离的方法的客户端带来困难。只要客户端识别到传输状态的丢失，协议就允许相关所有者消失，并且客户端可能必须处理在没有迁移的情况下不会发生的所有者确认请求。
When migration occurs and the source server discovers an owner whose state includes the migrated file system but other file systems as well, it cannot transfer the associated owner state. Instead, the
当发生迁移并且源服务器发现其状态包括已迁移文件系统但也包括其他文件系统的所有者时，它无法传输关联的所有者状态。相反
existing owner state stays in place, but propagation of owner state is done as specified below:
现有所有者状态保持不变，但所有者状态的传播按以下规定进行：
o When the current seqid for an owner represents an operation associated with the file system being migrated, owner status SHOULD be propagated to the destination file system.
o 当所有者的当前seqid表示与要迁移的文件系统关联的操作时，所有者状态应传播到目标文件系统。
o When the current seqid for an owner does not represent an operation associated with the file system being migrated, owner status MAY be propagated to the destination file system.
o 当所有者的当前seqid不表示与要迁移的文件系统关联的操作时，所有者状态可能会传播到目标文件系统。
o When the owner in question has never been used for an operation involving the migrated file system, the owner information SHOULD NOT be propagated to the destination file system.
o 当相关所有者从未用于涉及迁移文件系统的操作时，不应将所有者信息传播到目标文件系统。
Note that a server may obey all of the conditions above without the overhead of keeping track of a set of file systems that any particular owner has been associated with. Consider a situation in which the source server has decided to keep lock-related state associated with a file system fixed, preparatory to propagating it to the destination file system. If a client is free to create new locks associated with existing owners on other file systems, the owner information may be propagated to the destination file system, even though, at the time the file system migration is recognized by the client to have occurred, the last operation associated with the owner may not be associated with the migrating file system.
请注意，服务器可以遵守上述所有条件，而不需要跟踪任何特定所有者关联的一组文件系统。考虑源服务器已决定保持与文件系统相关联的锁定相关状态的情况，准备将其传播到目标文件系统。如果客户端可以自由创建与其他文件系统上现有所有者关联的新锁，则所有者信息可能会传播到目标文件系统，即使在客户端识别文件系统迁移已发生时，与所有者关联的最后一个操作可能与迁移文件系统无关。
When a source server propagates owner-related state associated with owners that span multiple file systems, it will propagate the owner sequence value to the destination server, while retaining it on the source server, as long as there exists state associated with the owner. When owner information is propagated in this way, source and destination servers start with the same owner sequence value that is then updated independently, as the client makes owner-related requests to the servers. Note that each server will have some period in which the associated sequence value for an owner is identical to the one transferred as part of migration. At those times, when a server receives a request with a matching owner sequence value, it MUST NOT respond with the associated stored response if the associated file system is not, when the reissued request is received, part of the set of file systems handled by that server.
当源服务器传播与跨多个文件系统的所有者关联的与所有者相关的状态时，只要存在与所有者关联的状态，它就会将所有者序列值传播到目标服务器，同时将其保留在源服务器上。当以这种方式传播所有者信息时，源服务器和目标服务器从相同的所有者序列值开始，然后独立更新，因为客户端向服务器发出与所有者相关的请求。请注意，每个服务器都有一段时间，在此期间，所有者的关联序列值与作为迁移一部分传输的序列值相同。在这些情况下，当服务器接收到具有匹配的所有者序列值的请求时，如果相关文件系统在接收到重新发布的请求时不是该服务器处理的文件系统集的一部分，则该服务器不得使用相关联的存储响应进行响应。
One sort of case may require more complex handling. When multiple file systems are migrated, in sequence, to a specific destination server, an owner may be migrated to a destination server, on which it was already present, leading to the issue of how the resident owner information and that being newly migrated are to be reconciled.
一种情况可能需要更复杂的处理。当按顺序将多个文件系统迁移到特定的目标服务器时，所有者可能会被迁移到目标服务器（该服务器上已存在所有者），从而导致如何协调常驻所有者信息和新迁移的所有者信息的问题。
If file system migration encounters a situation where owner information needs to be merged, it MAY decline to transfer such state, even if it chooses to handle other cases in which locks for a given owner are spread among multiple file systems.
如果文件系统迁移遇到需要合并所有者信息的情况，它可能会拒绝传输这种状态，即使它选择处理给定所有者的锁分布在多个文件系统中的其他情况。
As a way of understanding the situations that need to be addressed when owner information needs to be merged, consider the following scenario:
作为理解所有者信息需要合并时需要解决的情况的一种方式，考虑下面的场景：
o There is client C and two servers, X and Y. There are two clientid4s designating C, which are referred to as CX and CY.
o 有客户端C和两个服务器X和Y。有两个客户端4指定C，称为CX和CY。
o Initially, server X supports file systems F1, F2, F3, and F4. These will be migrated, one at a time, to server Y.
o 最初，服务器X支持文件系统F1、F2、F3和F4。这些将一次一个迁移到服务器Y。
o While these migrations are proceeding, the client makes locking requests for file systems F1 through F4 on behalf of owner O (either a lock-owner or an open-owner), with each request going to X or Y depending on where the relevant file system is being supported at the time the request is made.
o 在这些迁移过程中，客户端代表所有者O（锁所有者或开放所有者）对文件系统F1到F4发出锁定请求，每个请求都会转到X或Y，具体取决于发出请求时支持相关文件系统的位置。
o Once the first migration event occurs, client C will maintain two instances for owner O, one for each server.
o 一旦发生第一个迁移事件，客户端C将为所有者O维护两个实例，每个服务器一个。
o It is always possible that C may make a request of server X relating to owner O, and before receiving a response, it finds the target file system has moved to Y and needs to reissue the request to server Y.
o C总是可能向服务器X发出与所有者O相关的请求，并且在收到响应之前，它发现目标文件系统已移动到Y，需要重新向服务器Y发出请求。
o At the same time, C may make a request of server Y relating to owner O, and this too may encounter a lost-response situation.
o 同时，C可能向服务器Y发出与所有者O相关的请求，这也可能遇到响应丢失的情况。
As a result of such merger situations, the server will need to provide support for dealing with retransmission of owner-sequenced requests that diverge from the typical model in which there is support for retransmission of replies only for a request whose sequence value exactly matches the last one sent. In some situations, there may be two requests, each of which had the last sequence when it was issued. As a result of migration and owner merger, one of those will no longer be the last by sequence.
作为这种合并情况的结果，服务器将需要提供支持，以处理与典型模型不同的所有者顺序请求的重新传输，在典型模型中，仅支持序列值与最后发送的请求完全匹配的回复的重新传输。在某些情况下，可能有两个请求，每个请求在发出时都有最后一个序列。由于迁移和所有者合并，其中一个将不再是最后一个。
When servers do support such merger of owner information on the destination server, the following rules are to be adhered to:
当服务器支持在目标服务器上合并所有者信息时，应遵守以下规则：
o When an owner sequence value is propagated to a destination server where it already exists, the resulting sequence value is to be the greater of the one present on the destination server and the one being propagated as part of migration.
o 将所有者序列值传播到已存在的目标服务器时，生成的序列值将是目标服务器上存在的序列值和作为迁移的一部分传播的序列值中的较大值。
o In the event that an owner sequence value on a server represents a request applying to a file system currently present on the server, it is not to be rendered invalid simply because that sequence value is changed as a result of owner information propagation as part of file system migration. Instead, it is retained until it can be deduced that the client in question has received the reply.
o 如果服务器上的所有者序列值表示应用于服务器上当前存在的文件系统的请求，则不能仅仅因为作为文件系统迁移一部分的所有者信息传播的结果更改了该序列值而使其无效。相反，它会被保留，直到可以推断相关客户已收到回复为止。
As a result of the operation of these rules, there are three ways in which there can be more reply data than what is typically present, i.e., data for a single request per owner whose sequence is the last one received, where the next sequence to be used is one beyond that.
由于这些规则的操作，有三种方式可以有比通常存在的更多的回复数据，即，每个所有者的单个请求的数据，其序列是最后接收到的序列，其中要使用的下一个序列是该序列之外的序列。
o When the owner sequence value for a migrating file system is greater than the corresponding value on the destination server, the last request for the owner in effect at the destination server needs to be retained, even though it is no longer one less than the next sequence to be received.
o 当迁移文件系统的所有者序列值大于目标服务器上的相应值时，需要保留在目标服务器上对所有者有效的最后一个请求，即使它不再比要接收的下一个序列少一个。
o When the owner sequence value for a migrating file system is less than the corresponding value on the destination server, the sequence number for last request for the owner in effect on the migrating file system needs to be retained, even though it is no longer than one less the next sequence to be received.
o 当迁移文件系统的所有者序列值小于目标服务器上的相应值时，需要保留在迁移文件系统上有效的所有者最后一次请求的序列号，即使该序列号不比要接收的下一个序列少一个。
o When the owner sequence value for a migrating file system is equal to the corresponding value on the destination server, one has two different "last" requests that both must be retained. The next sequence value to be used is one beyond the sequence value shared by these two requests.
o 当迁移文件系统的所有者序列值等于目标服务器上的相应值时，其中一个具有两个不同的“last”请求，必须保留这两个请求。下一个要使用的序列值超出了这两个请求共享的序列值。
Here are some guidelines as to when servers can drop such additional reply data, which is created as part of owner information migration.
以下是服务器何时可以删除作为所有者信息迁移一部分创建的附加回复数据的一些指导原则。
o The server SHOULD NOT drop this information simply because it receives a new sequence value for the owner in question, since that request may have been issued before the client was aware of the migration event.
o 服务器不应该仅仅因为接收到相关所有者的新序列值而删除此信息，因为该请求可能是在客户端意识到迁移事件之前发出的。
o The server SHOULD drop this information if it receives a new sequence value for the owner in question, and the request relates to the same file system.
o 如果服务器收到相关所有者的新序列值，并且请求与同一文件系统相关，则应删除此信息。
o The server SHOULD drop the part of this information that relates to non-migrated file systems if it receives a new sequence value for the owner in question, and the request relates to a non-migrated file system.
o 如果服务器收到相关所有者的新序列值，并且请求与未迁移的文件系统相关，则服务器应删除此信息中与未迁移的文件系统相关的部分。
o The server MAY drop this information when it receives a new sequence value for the owner in question for a considerable period of time (more than one or two lease periods) after the migration occurs.
o 当服务器在迁移发生后相当长的一段时间（超过一个或两个租赁期）内收到相关所有者的新序列值时，可能会删除此信息。
Since client switch-over in the case of replication is not under server control, the handling of state is different. In this case, leases, stateids, and client IDs do not have validity across a transition from one server to another. The client must re-establish its locks on the new server. This can be compared to the re-establishment of locks by means of reclaim-type requests after a server reboot. The difference is that the server has no provision to distinguish requests reclaiming locks from those obtaining new locks or to defer the latter. Thus, a client re-establishing a lock on the new server (by means of a LOCK or OPEN request) may have the requests denied due to a conflicting lock. Since replication is intended for read-only use of file systems, such denial of locks should not pose large difficulties in practice. When an attempt to re-establish a lock on a new server is denied, the client should treat the situation as if its original lock had been revoked.
由于复制情况下的客户端切换不受服务器控制，因此状态的处理是不同的。在这种情况下，租约、StateID和客户端ID在从一台服务器到另一台服务器的转换过程中不具有有效性。客户端必须在新服务器上重新建立其锁。这可以与服务器重新启动后通过回收类型请求重新建立锁进行比较。不同之处在于，服务器没有规定区分请求回收锁和请求获得新锁或延迟后者。因此，在新服务器上重新建立锁的客户端（通过锁或打开请求）可能由于锁冲突而拒绝请求。由于复制旨在以只读方式使用文件系统，因此这种拒绝锁定在实践中不会造成很大困难。当在新服务器上重新建立锁的尝试被拒绝时，客户端应将此情况视为其原始锁已被撤销。
A file system can be migrated to another server while a client that has state related to that file system is not actively submitting requests to it. In this case, the migration is reported to the client during lease renewal. Lease renewal can occur either explicitly via a RENEW operation or implicitly when the client performs a lease-renewing operation on another file system on that server.
当具有与文件系统相关状态的客户端未主动向其提交请求时，可以将文件系统迁移到另一台服务器。在这种情况下，迁移将在租约续订期间报告给客户端。租约续订可以通过续订操作显式进行，也可以在客户端对该服务器上的另一个文件系统执行租约续订操作时隐式进行。
In order for the client to schedule renewal of leases that may have been relocated to the new server, the client must find out about lease relocation before those leases expire. Similarly, when migration occurs but there has not been transparent state migration, the client needs to find out about the change soon enough to be able to reclaim the lock within the destination server's grace period. To accomplish this, all operations that implicitly renew leases for a client (such as OPEN, CLOSE, READ, WRITE, RENEW, LOCK, and others) will return the error NFS4ERR_LEASE_MOVED if responsibility for any of the leases to be renewed has been transferred to a new server. Note that when the transfer of responsibility leaves remaining state for that lease on the source server, the lease is renewed just as it would have been in the NFS4ERR_OK case, despite returning the error. The transfer of responsibility happens when the server receives a GETATTR(fs_locations) from the client for each file system for which
为了让客户端计划可能已重新定位到新服务器的租约的续订，客户端必须在这些租约到期之前了解租约重新定位。类似地，当发生迁移但尚未进行透明状态迁移时，客户端需要尽快了解更改，以便能够在目标服务器的宽限期内收回锁。为此，如果要续订的任何租约的责任已转移到新服务器，则隐式续订客户端租约的所有操作（如打开、关闭、读取、写入、续订、锁定和其他）将返回错误NFS4ERR_LEASE_MOVED。请注意，当责任转移离开源服务器上该租约的剩余状态时，尽管返回了错误，租约仍会像在NFS4ERR_OK情况下一样续订。当服务器从客户端接收到每个文件系统的GETATTR（fs_位置）时，就会发生责任转移
a lease has been moved to a new server. Normally, it does this after receiving an NFS4ERR_MOVED for an access to the file system, but the server is not required to verify that this happens in order to terminate the return of NFS4ERR_LEASE_MOVED. By convention, the compounds containing GETATTR(fs_locations) SHOULD include an appended RENEW operation to permit the server to identify the client getting the information.
租约已移动到新服务器。通常，它会在接收到为访问文件系统而移动的NFS4ERR_后执行此操作，但服务器不需要验证是否发生了这种情况，以终止NFS4ERR_LEASE_MOVED的返回。按照惯例，包含GETATTR（fs_位置）的复合词应该包括附加的续订操作，以允许服务器识别获取信息的客户端。
Note that the NFS4ERR_LEASE_MOVED error is required only when responsibility for at least one stateid has been affected. In the case of a null lease, where the only associated state is a clientid4, an NFS4ERR_LEASE_MOVED error SHOULD NOT be generated.
注意，只有当至少一个stateid的责任受到影响时，才需要NFS4ERR_LEASE_MOVED错误。对于空租约，其中唯一关联的状态是Client4，不应生成NFS4ERR_lease_MOVED错误。
Upon receiving the NFS4ERR_LEASE_MOVED error, a client that supports file system migration MUST perform the necessary GETATTR operation for each of the file systems containing state that have been migrated, so it gives the server evidence that it is aware of the migration of the file system. Once the client has done this for all migrated file systems on which the client holds state, the server MUST resume normal handling of stateful requests from that client.
在接收到NFS4ERR_LEASE_MOVED错误后，支持文件系统迁移的客户端必须对包含已迁移状态的每个文件系统执行必要的GETATTR操作，以便向服务器提供证据，证明它知道文件系统的迁移。一旦客户机对客户机持有状态的所有已迁移文件系统执行此操作，服务器必须恢复对来自该客户机的有状态请求的正常处理。
One way in which clients can do this efficiently in the presence of large numbers of file systems is described below. This approach divides the process into two phases: one devoted to finding the migrated file systems, and the second devoted to doing the necessary GETATTRs.
下面描述了客户机在存在大量文件系统的情况下有效地执行此操作的一种方法。这种方法将过程分为两个阶段：一个阶段用于查找迁移的文件系统，另一个阶段用于执行必要的getAttr。
The client can find the migrated file systems by building and issuing one or more COMPOUND requests, each consisting of a set of PUTFH/ GETFH pairs, each pair using a filehandle in one of the file systems in question. All such COMPOUND requests can be done in parallel. The successful completion of such a request indicates that none of the file systems interrogated have been migrated while termination with NFS4ERR_MOVED indicates that the file system getting the error has migrated while those interrogated before it in the same COMPOUND have not. Those whose interrogation follows the error remain in an uncertain state and can be interrogated by restarting the requests from after the point at which NFS4ERR_MOVED was returned or by issuing a new set of COMPOUND requests for the file systems that remain in an uncertain state.
客户机可以通过构建和发出一个或多个复合请求来查找迁移的文件系统，每个复合请求由一组PUTFH/GETFH对组成，每对都使用一个文件系统中的文件句柄。所有此类复合请求都可以并行完成。成功完成此类请求表示未迁移任何被查询的文件系统，而使用NFS4ERR_MOVED终止表示获得错误的文件系统已迁移，而在同一化合物中在其之前被查询的文件系统尚未迁移。在错误之后进行查询的人仍处于不确定状态，可以通过在返回NFS4ERR_移动的点之后重新启动请求，或通过对仍处于不确定状态的文件系统发出一组新的复合请求来进行查询。
Once the migrated file systems have been found, all that is needed is for the client to give evidence to the server that it is aware of the migrated status of file systems found by this process, by interrogating the fs_locations attribute for a filehandle within each of the migrated file systems. The client can do this by building and issuing one or more COMPOUND requests, each of which consists of a set of PUTFH operations, each followed by a GETATTR of the
找到迁移的文件系统后，客户端只需通过查询每个迁移的文件系统中的文件句柄的fs_locations属性，向服务器提供证据，证明它知道此过程中找到的文件系统的迁移状态。客户机可以通过构建和发出一个或多个复合请求来实现这一点，每个复合请求由一组PUTFH操作组成，每个操作后面都有
fs_locations attribute. A RENEW is necessary to enable the operations to be associated with the lease returning NFS4ERR_LEASE_MOVED. Once the client has done this for all migrated file systems on which the client holds state, the server will resume normal handling of stateful requests from that client.
fs_位置属性。需要续订，以使操作与租约返回NFS4ERR_lease_MOVED关联。一旦客户机对客户机持有状态的所有迁移文件系统执行此操作，服务器将恢复对来自该客户机的有状态请求的正常处理。
In order to support legacy clients that do not handle the NFS4ERR_LEASE_MOVED error correctly, the server SHOULD time out after a wait of at least two lease periods, at which time it will resume normal handling of stateful requests from all clients. If a client attempts to access the migrated files, the server MUST reply with NFS4ERR_MOVED. In this situation, it is likely that the client would find its lease expired, although a server may use "courtesy" locks (as described in Section 9.6.3.1 of [RFC7530]) to mitigate the issue.
为了支持未正确处理NFS4ERR_LEASE_MOVED错误的旧客户端，服务器应在至少两个租用期等待后超时，此时将恢复正常处理来自所有客户端的有状态请求。如果客户端试图访问迁移的文件，服务器必须使用NFS4ERR_MOVED进行回复。在这种情况下，客户可能会发现其租约到期，尽管服务器可能会使用“礼貌”锁（如[RFC7530]第9.6.3.1节所述）来缓解问题。
When the client receives an NFS4ERR_MOVED error, the client can follow the normal process to obtain the destination server information (through the fs_locations attribute) and perform renewal of those leases on the new server. If the server has not had state transferred to it transparently, the client will receive either NFS4ERR_STALE_CLIENTID or NFS4ERR_STALE_STATEID from the new server, as described above. The client can then recover state information as it does in the event of server failure.
当客户端接收到NFS4ERR_MOVED错误时，客户端可以按照正常过程获取目标服务器信息（通过fs_locations属性），并在新服务器上执行这些租约的续订。如果服务器尚未将状态透明地传输给它，则客户端将从新服务器接收NFS4ERR_STALE_CLIENTID或NFS4ERR_STALE_STATEID，如上所述。然后，客户端可以像在服务器发生故障时一样恢复状态信息。
Aside from recovering from a migration, there are other reasons a client may wish to retrieve fs_locations information from a server. When a server becomes unresponsive, for example, a client may use cached fs_locations data to discover an alternate server hosting the same file system data. A client may periodically request fs_locations data from a server in order to keep its cache of fs_locations data fresh.
除了从迁移中恢复外，客户机可能希望从服务器检索fs_位置信息还有其他原因。例如，当服务器无响应时，客户端可能会使用缓存的fs_位置数据来发现托管相同文件系统数据的备用服务器。客户端可以定期从服务器请求fs_位置数据，以保持其fs_位置数据缓存的新鲜度。
Since a GETATTR(fs_locations) operation would be used for refreshing cached fs_locations data, a server could mistake such a request as indicating recognition of an NFS4ERR_LEASE_MOVED condition. Therefore, a compound that is not intended to signal that a client has recognized a migrated lease SHOULD be prefixed with a guard operation that fails with NFS4ERR_MOVED if the filehandle being queried is no longer present on the server. The guard can be as simple as a GETFH operation.
由于GETATTR（fs_locations）操作将用于刷新缓存的fs_locations数据，服务器可能会将此类请求误认为表示识别NFS4ERR_LEASE_移动条件。因此，如果要查询的文件句柄在服务器上不再存在，则不打算表示客户端已识别迁移的租约的复合词应以保护操作作为前缀，该操作会因NFS4ERR_移动而失败。防护装置可以像GETFH操作一样简单。
Though unlikely, it is possible that the target of such a compound could be migrated in the time after the guard operation is executed on the server but before the GETATTR(fs_locations) operation is encountered. When a client issues a GETATTR(fs_locations) operation as part of a compound not intended to signal recognition of a migrated lease, it SHOULD be prepared to process fs_locations data in the reply that shows the current location of the file system is gone.
虽然不太可能，但在服务器上执行guard操作之后，但在遇到GETATTR（fs_locations）操作之前，可能会迁移此类化合物的目标。当客户机发出GETATTR（fs_locations）操作作为化合物的一部分时，不打算发出识别迁移租约的信号，它应该准备处理回复中显示文件系统当前位置已消失的fs_locations数据。
In order that the client may appropriately manage its leases in the case of migration, the destination server must establish proper values for the lease_time attribute.
为了在迁移的情况下客户端可以适当地管理其租约，目标服务器必须为租约时间属性建立适当的值。
When state is transferred transparently, that state should include the correct value of the lease_time attribute. The lease_time attribute on the destination server must never be less than that on the source since this would result in premature expiration of leases granted by the source server. Upon migration in which state is transferred transparently, the client is under no obligation to refetch the lease_time attribute and may continue to use the value previously fetched (on the source server).
当状态以透明方式传输时，该状态应包含lease_time属性的正确值。目标服务器上的租约时间属性不得小于源服务器上的租约时间属性，因为这将导致源服务器授予的租约提前到期。在以透明方式传输状态的迁移时，客户端没有义务重新蚀刻lease_time属性，并且可以继续使用以前获取的值（在源服务器上）。
In the case in which lease merger occurs as part of state transfer, the lease_time attribute of the destination lease remains in effect. The client can simply renew that lease with its existing lease_time attribute. State in the source lease is renewed at the time of transfer so that it cannot expire, as long as the destination lease is appropriately renewed.
在租赁合并作为状态转移的一部分发生的情况下，目标租赁的“租赁时间”属性仍然有效。客户机只需使用其现有的lease_time属性续订该租约即可。源租约中的状态在传输时续订，因此只要目标租约已适当续订，它就不会过期。
If state has not been transferred transparently (i.e., the client needs to reclaim or re-obtain its locks), the client should fetch the value of lease_time on the new (i.e., destination) server, and use it for subsequent locking requests. However, the server must respect a grace period at least as long as the lease_time on the source server, in order to ensure that clients have ample time to reclaim their locks before potentially conflicting non-reclaimed locks are granted. The means by which the new server obtains the value of lease_time on the old server is left to the server implementations. It is not specified by the NFS version 4.0 protocol.
如果状态未被透明传输（即，客户端需要回收或重新获取其锁），则客户端应获取新（即，目标）服务器上的租约时间值，并将其用于后续锁定请求。但是，服务器必须遵守至少与源服务器上的租约时间一样长的宽限期，以确保在授予潜在冲突的未回收锁之前，客户端有足够的时间回收其锁。新服务器获取旧服务器上的租赁时间值的方法留给服务器实现。NFS版本4.0协议没有指定它。
This section provides suggestions to help server implementers deal with issues involved in the transparent transfer of file-system-related data between servers. Servers are not obliged to follow these suggestions but should be sure that their approach to the issues handle all the potential problems addressed below.
本节提供了一些建议，以帮助服务器实现者处理服务器之间与文件系统相关的数据的透明传输所涉及的问题。服务器没有义务遵循这些建议，但应确保其解决问题的方法能够处理以下所有潜在问题。
7.1. Relation of Locking State Transfer to Other Aspects of File System Motion
7.1. 锁定状态传输与文件系统运动其他方面的关系
In many cases, state transfer will be part of a larger function wherein the contents of a file system are transferred from server to server. Although specifics will vary with the implementation, the relation between the transfer of persistent file data and metadata
在许多情况下，状态传输将是更大功能的一部分，其中文件系统的内容从一个服务器传输到另一个服务器。尽管具体细节因实现而异，但持久文件数据和元数据的传输之间的关系
and the transfer of state will typically be described by one of the cases below.
并且状态的转移通常将通过以下情况之一来描述。
o In some implementations, access to the on-disk contents of a file system can be transferred from server to server by making the storage devices on which the file system resides physically accessible from multiple servers, and transferring the right and responsibility for handling that file system from server to server.
o 在某些实现中，通过使文件系统所在的存储设备可以从多台服务器物理访问，并将处理该文件系统的权利和责任从服务器转移到服务器，可以将对文件系统的磁盘内容的访问从服务器转移到服务器。
In such implementations, the transfer of locking state happens on its own, as described in Section 7.2. The transfer of physical access to the file system happens after the locking state is transferred and before any subsequent access to the file system. In cases where such transfer is not instantaneous, there will be a period in which all operations on the file system are held off, either by having the operations themselves return NFS4ERR_DELAY or, where this is not allowed, by using the techniques described below in Section 7.2.
在这样的实现中，锁定状态的转移自行发生，如第7.2节所述。对文件系统的物理访问的传输发生在锁定状态传输之后，并且在对文件系统的任何后续访问之前。如果这种传输不是即时的，则会有一段时间，通过让操作本身返回NFS4ERR_DELAY，或者在不允许的情况下，使用下面第7.2节中描述的技术，文件系统上的所有操作都会被延迟。
o In other implementations, file system data and metadata must be copied from the server where they have existed to the destination server. Because of the typical amounts of data involved, it is generally not practical to hold off access to the file system while this transfer is going on. Normal access to the file system, including modifying operations, will generally happen while the transfer is going on.
o 在其他实现中，文件系统数据和元数据必须从它们存在的服务器复制到目标服务器。由于涉及的数据量非常大，因此在传输过程中暂停对文件系统的访问通常是不切实际的。对文件系统的正常访问（包括修改操作）通常会在传输过程中发生。
Eventually, the file system copying process will complete. At this point, there will be two valid copies of the file system, one on each of the source and destination servers. Servers may maintain that state of affairs by making sure that each modification to file system data is done on both the source and destination servers.
最终，文件系统复制过程将完成。此时，文件系统将有两个有效副本，一个在源服务器上，另一个在目标服务器上。服务器可以通过确保对文件系统数据的每次修改都在源服务器和目标服务器上完成来保持这种状态。
Although the transfer of locking state can begin before the above state of affairs is reached, servers will often wait until it is arrived at to begin transfer of locking state. Once the transfer of locking state is completed, as described in the section below, clients may be notified of the migration event and access the destination file system on the destination server.
虽然锁定状态的传输可以在达到上述状态之前开始，但服务器通常会等到锁定状态到达后才开始传输。锁定状态的传输完成后（如以下部分所述），客户端可能会收到迁移事件的通知，并访问目标服务器上的目标文件系统。
o Another case in which file system data and metadata must be copied from server to server involves a variant of the pattern above. In cases in which a single file system moves between or among a small set of servers, it will transition to a server on which a previous instantiation of that same file system existed before. In such cases, it is often more efficient to update the previous file
o 文件系统数据和元数据必须从一台服务器复制到另一台服务器的另一种情况涉及上述模式的变体。如果单个文件系统在一小部分服务器之间移动，它将转换到以前存在相同文件系统的实例的服务器。在这种情况下，更新以前的文件通常更有效
system instance to reflect changes made while the active file system was residing elsewhere rather than copying the file system data anew.
系统实例，以反映活动文件系统驻留在其他位置时所做的更改，而不是重新复制文件系统数据。
In such cases, the copying of file system data and metadata is replaced by a process that validates each visible file system object, copying new objects and updating those that have changed since the file system was last present on the destination server. Although this process is generally shorter than a complete copy, it is generally long enough that it is not practical to hold off access to the file system while this update is going on.
在这种情况下，文件系统数据和元数据的复制被一个过程所取代，该过程验证每个可见的文件系统对象，复制新对象并更新自文件系统上次出现在目标服务器上以来已更改的对象。虽然此过程通常比完整的副本短，但通常足够长，因此在进行此更新时阻止对文件系统的访问是不切实际的。
Eventually, the file system updating process will complete. At this point, there will be two valid copies of the file system, one on each of the source and destination servers. Servers may maintain that state of affairs just as is done in the previous case. Similarly, the transfer of locking state, once it is complete, allows the clients to be notified of the migration event and access the destination file system on the destination server.
最终，文件系统更新过程将完成。此时，文件系统将有两个有效副本，一个在源服务器上，另一个在目标服务器上。服务器可能会像在前一种情况下一样保持这种状态。类似地，锁定状态的传输一旦完成，就允许将迁移事件通知客户端并访问目标服务器上的目标文件系统。
When transferring locking state from the source to a destination server, there will be occasions when the source server will need to prevent operations that modify the state being transferred. For example, if the locking state at time T is sent to the destination server, any state change that occurs on the source server after that time but before the file system transfer is made effective will mean that the state on the destination server will differ from that on the source server, which matches what the client would expect to see.
将锁定状态从源服务器传输到目标服务器时，有时源服务器需要阻止修改正在传输的状态的操作。例如，如果将时间T处的锁定状态发送到目标服务器，则在该时间之后但在文件系统传输生效之前，源服务器上发生的任何状态更改都将意味着目标服务器上的状态将与源服务器上的状态不同，这与客户机期望看到的状态相匹配。
In general, a server can prevent some set of server-maintained data from changing by returning NFS4ERR_DELAY on operations that attempt to change that data. In the case of locking state for NFSv4.0, there are two specific issues that might interfere:
通常，服务器可以通过在尝试更改某组服务器维护的数据的操作上返回NFS4ERR_延迟来防止该组数据更改。对于NFSv4.0的锁定状态，有两个特定问题可能会产生干扰：
o Returning NFS4ERR_DELAY will not prevent state from changing in that owner-based sequence values will still change, even though NFS4ERR_DELAY is returned. For example, OPEN and LOCK will change state (in the form of owner seqid values) even when they return NFS4ERR_DELAY.
o 返回NFS4ERR_DELAY不会阻止状态更改，因为基于所有者的序列值仍然会更改，即使返回了NFS4ERR_DELAY。例如，“打开”和“锁定”即使返回NFS4ERR_延迟，也会更改状态（以所有者seqid值的形式）。
o Some operations that modify locking state are not allowed to return NFS4ERR_DELAY (i.e., OPEN_CONFIRM, RELEASE_LOCKOWNER, and RENEW).
o 某些修改锁定状态的操作不允许返回NFS4ERR_延迟（即打开确认、释放锁定所有者和续订）。
Note that the first problem and most instances of the second can be addressed by returning NFS4ERR_DELAY on the operations that establish a filehandle within the target as one of the filehandles associated with the request, i.e., as either the current or saved filehandle. This would require returning NFS4ERR_DELAY under the following circumstances:
请注意，第一个问题和第二个问题的大多数实例可以通过在操作上返回NFS4ERR_DELAY来解决，该操作将在目标中建立一个文件句柄作为与请求关联的文件句柄之一，即作为当前或保存的文件句柄。在以下情况下，这需要返回NFS4ERR_延迟：
o On a PUTFH that specifies a filehandle within the target file system.
o 在PUTFH上指定目标文件系统中的文件句柄。
o On a LOOKUP or LOOKUPP that crosses into the target file system.
o 在交叉到目标文件系统的查找或查找上。
As a result of doing this, OPEN_CONFIRM is dealt with, leaving only RELEASE_LOCKOWNER and RENEW still to be dealt with.
这样做的结果是，处理OPEN_CONFIRM，只剩下RELEASE_LOCKOWNER和RENEW有待处理。
Note that if the server establishes and maintains a situation in which no request has, as either the current or saved filehandle, a filehandle within the target file system, no special handling of SAVEFH or RESTOREFH is required. Thus, the fact that these operations cannot return NFS4ERR_DELAY is not a problem since neither will establish a filehandle in the target file system as the current filehandle.
请注意，如果服务器建立并维护这样一种情况，即目标文件系统中没有任何请求（作为当前或保存的文件句柄）具有文件句柄，则不需要对SAVEFH或RESTOREFH进行特殊处理。因此，这些操作不能返回NFS4ERR_DELAY这一事实不是问题，因为它们都不会在目标文件系统中建立一个filehandle作为当前filehandle。
If the server is to establish the situation described above, it may have to take special note of long-running requests that started before state migration. Part of any solution to this issue will involve distinguishing two separate points in time at which handling for the target file system will change. Let us distinguish:
如果服务器要建立上述情况，可能需要特别注意在状态迁移之前启动的长时间运行的请求。此问题的任何解决方案的一部分都将涉及区分两个独立的时间点，在这两个时间点上，目标文件系统的处理方式将发生变化。让我们区分：
o A time T after which the previously mentioned operations will return NFS4ERR_DELAY.
o 时间T，在此时间T之后，前面提到的操作将返回NFS4ERR_延迟。
o A later time T' at which the server can consider file system locking state fixed, making it possible for it to be sent to the destination server.
o 稍后的时间t，服务器可以考虑文件系统锁定状态，使其能够被发送到目的地服务器。
For a server to decide on T', it must ensure that requests started before T cannot change target file system locking state, given that all those started after T are dealt with by returning NFS4ERR_DELAY upon setting filehandles within the target file system. Among the ways of doing this are:
对于决定T'的服务器，它必须确保在T'之前启动的请求不能更改目标文件系统锁定状态，因为在目标文件系统内设置文件句柄时，所有在T'之后启动的请求都会通过返回NFS4ERR_DELAY来处理。实现这一目标的方法包括：
o Keeping track of the earliest request started that is still in execution (for example, by keeping a list of active requests ordered by request start time). Requests that started before and are still in progress at time T may potentially affect the locking state; once the starting time of the earliest-started active request is later than T, the starting time of the first such
o 跟踪仍在执行中的最早启动的请求（例如，通过按请求开始时间排列活动请求列表）。在时间T之前启动且仍在进行的请求可能会影响锁定状态；一旦最早启动的活动请求的开始时间晚于T，则为第一个此类请求的开始时间
request can be chosen as T' by the server since any request in progress after T' started after time T. Accordingly, it would not have been allowed to change locking state for the migrating file system and would have returned NFS4ERR_DELAY had it tried to make a change.
服务器可以将请求选择为T'，因为T'之后正在进行的任何请求都是在时间T之后启动的。因此，不允许更改迁移文件系统的锁定状态，如果尝试进行更改，则会返回NFS4ERR_DELAY。
o Keeping track of the count of requests started before time T that have a filehandle within the target file system as either the current or saved filehandle. The server can then define T' to be the first time after T at which the count is zero.
o 跟踪在时间T之前启动的请求计数，这些请求在目标文件系统中具有作为当前或保存的文件句柄的文件句柄。然后，服务器可以将T'定义为T之后计数为零的第一次。
The set of operations that change locking state include two that cannot be dealt with by the above approach, because they are not specific to a particular file system and do not use a current filehandle as an implicit parameter.
更改锁定状态的操作集包括两个以上方法无法处理的操作，因为它们不是特定于特定文件系统的，并且不使用当前filehandle作为隐式参数。
o RENEW can be dealt with by applying the renewal to state for non-transitioning file systems. The effect of renewal for the transitioning file system can be ignored, as long as the servers make sure that the lease on the destination server has an expiration time that is no earlier than the latest renewal done on the source server. This can be easily accomplished by making the lease expiration on the destination server equal to the time in which the state transfer was completed plus the lease period.
o 对于非转换文件系统，可以通过将续订应用于状态来处理续订。只要服务器确保目标服务器上的租约的到期时间不早于源服务器上执行的最新续订，则可以忽略续订对转换文件系统的影响。这可以通过使目标服务器上的租约到期时间等于状态传输完成的时间加上租约期限来轻松实现。
o RELEASE_LOCKOWNER can be handled by propagating the fact of the lock-owner deletion (e.g., by using an RPC) to the destination server. Such a propagation RPC can be done as part of the operation, or the existence of the deletion can be recorded locally and propagation of owner deletions to the destination server done as a batch later. In either case, the actual deletions on the destination server have to be delayed until all of the other state information has been transferred.
o 释放锁所有者可以通过将锁所有者删除的事实传播到目标服务器（例如，通过使用RPC）来处理。这样的传播RPC可以作为操作的一部分进行，或者可以在本地记录删除的存在，并在以后将所有者删除作为批处理传播到目标服务器。在任何一种情况下，都必须延迟目标服务器上的实际删除，直到传输了所有其他状态信息。
Alternatively, RELEASE_LOCKOWNER can be dealt with by returning NFS4ERR_DELAY. In order to avoid compatibility issues for clients not prepared to accept NFS4ERR_DELAY in response to RELEASE_LOCKOWNER, care must be exercised. (See Section 8.3 for details.)
或者，释放锁所有者可以通过返回NFS4ERR\u延迟来处理。为了避免不准备接受NFS4ERR_延迟以响应RELEASE_LOCKOWNER的客户端出现兼容性问题，必须小心谨慎。（详见第8.3节。）
The approach outlined above, wherein NFS4ERR_DELAY is returned based primarily on the use of current and saved filehandles in the file system, prevents all reference to the transitioning file system rather than limiting the delayed operations to those that change locking state on the transitioning file system. Because of this, servers may choose to limit the time during which this broad approach is used by adopting a layered approach to the issue.
上面概述的方法，其中NFS4ERR_DELAY主要基于文件系统中当前和保存的文件句柄的使用返回，防止所有对转换文件系统的引用，而不是将延迟操作限制为那些更改转换文件系统上锁定状态的操作。因此，服务器可能会选择通过采用分层方法来限制使用这种广泛方法的时间。
o During the preparatory phase, operations that change, create, or destroy locks or modify the valid set of stateids will return NFS4ERR_DELAY. During this phase, owner-associated seqids may change, and the identity of the file system associated with the last request for a given owner may change as well. Also, RELEASE_LOCKOWNER operations may be processed without returning NFS4ERR_DELAY as long as the fact of the lock-owner deletion is recorded locally for later transmission.
o 在准备阶段，更改、创建或销毁锁或修改有效StateID集的操作将返回NFS4ERR_DELAY。在此阶段，与所有者相关联的seqid可能会更改，与给定所有者的最后一个请求相关联的文件系统的标识也可能会更改。此外，只要在本地记录锁所有者删除的事实以便稍后传输，就可以在不返回NFS4ERR\u延迟的情况下处理释放锁所有者操作。
o During the restrictive phase, operations that change locking state for the file system in transition are prevented by returning NFS4ERR_DELAY on any attempt to make a filehandle within that file system either the current or saved filehandle for a request. RELEASE_LOCKOWNER operations may return NFS4ERR_DELAY, but if they are processed, the lock-owner deletion needs to be communicated immediately to the destination server.
o 在限制阶段，如果试图将文件系统中的文件句柄设置为请求的当前文件句柄或保存的文件句柄，将返回NFS4ERR_DELAY，从而阻止更改转换中文件系统锁定状态的操作。RELEASE_LOCKOWNER操作可能返回NFS4ERR_延迟，但如果处理了这些操作，则需要立即将锁所有者删除通知目标服务器。
A possible sequence would be the following.
可能的顺序如下。
o The server enters the preparatory phase for the transitioning file system.
o 服务器进入转换文件系统的准备阶段。
o At this point, locking state, including stateids, locks, and owner strings, is transferred to the destination server. The seqids associated with owners are either not transferred or transferred on a provisional basis, subject to later change.
o 此时，锁定状态（包括stateID、锁和所有者字符串）被传输到目标服务器。与所有者相关的SEQID不是转让，就是临时转让，以后可能会发生变化。
o After the above has been transferred, the server may enter the restrictive phase for the file system.
o 传输上述内容后，服务器可能会进入文件系统的限制阶段。
o At this point, the updated seqid values may be sent to the destination server.
o 此时，更新后的seqid值可以发送到目标服务器。
Reporting regarding pending owner deletions (as a result of RELEASE_LOCKOWNER operations) can be communicated at the same time.
关于未决所有者删除的报告（由于释放锁定所有者操作）可同时传达。
o Once it is known that all of this information has been transferred to the destination server, and there are no pending RELEASE_LOCKOWNER notifications outstanding, the source server may treat the file system transition as having occurred and return NFS4ERR_MOVED when an attempt is made to access it.
o 一旦知道所有这些信息都已传输到目标服务器，并且没有未决的RELEASE_LOCKOWNER通知，源服务器可能会将文件系统转换视为已发生，并在尝试访问它时返回NFS4ERR_MOVED。
This section contains a number of items that relate to the changes in the section above, but which, for one reason or another, exist in different portions of the specification to be updated.
本节包含许多与上述章节中的变更相关的项目，但由于某种原因，这些项目存在于待更新规范的不同部分中。
Summarized here are all the remaining changes, not included in the two main sections.
此处总结了所有剩余的更改，但未包含在两个主要部分中。
o New definition of the error NFS4ERR_CLID_INUSE, appearing in Section 8.2. This replaces the definition in Section 13.1.10.1 in [RFC7530].
o 错误NFS4ERR_CLID_INUSE的新定义，见第8.2节。这取代了[RFC7530]第13.1.10.1节中的定义。
o A revision of the error definitions section to allow RELEASE_LOCKOWNER to return NFS4ERR_DELAY, with appropriate constraints to assure interoperability with clients not expecting this error to be returned. These changes are discussed in Section 8.2 and modify the error tables in Sections 13.2 and 13.4 in [RFC7530].
o 错误定义部分的修订版，允许RELEASE_LOCKOWNER返回NFS4ERR_DELAY，并带有适当的约束，以确保与不希望返回此错误的客户端的互操作性。第8.2节讨论了这些变更，并修改了[RFC7530]第13.2节和第13.4节中的误差表。
o A revised description of SETCLIENTID, appearing in Section 8.4. This brings the description into sync with the rest of the specification regarding NFS4ERR_CLID_INUSE. The revised description replaces the one in Section 16.33 of [RFC7530].
o SETCLIENTID的修订说明，见第8.4节。这使得该描述与关于NFS4ERR_CLID_INUSE的规范的其余部分保持同步。修订后的说明取代了[RFC7530]第16.33节中的说明。
o Some security-related changes appear in Sections 8.5 and 8.6. The Security Considerations section of this document (Section 9) describes the effect on the corresponding section (Section 19) in [RFC7530].
o 第8.5节和第8.6节中出现了一些与安全相关的更改。本文件的安全注意事项部分（第9节）描述了对[RFC7530]中相应部分（第19节）的影响。
The definition of this error is now as follows:
该错误的定义如下：
The SETCLIENTID operation has found that the id string within the specified nfs_client_id4 was previously presented with a different principal and that client instance currently holds an active lease. A server MAY return this error if the same principal is used, but a change in authentication flavor gives good reason to reject the new SETCLIENTID operation as not bona fide.
SETCLIENTID操作发现指定的nfs_client_id4中的id字符串以前使用不同的主体呈现，并且该客户端实例当前持有活动租约。如果使用了相同的主体，服务器可能会返回此错误，但是身份验证风格的更改为拒绝新的SETCLIENTID操作提供了很好的理由，因为该操作不是真实的。
The existing error tables should be considered modified to allow NFS4ERR_DELAY to be returned by RELEASE_LOCKOWNER. However, the scope of this addition is limited and is not to be considered as making this error return generally acceptable.
应考虑修改现有错误表，以允许RELEASE_LOCKOWNER返回NFS4ERR_延迟。但是，此添加的范围是有限的，不被视为使此错误返回普遍可接受。
It needs to be made clear that servers may not return this error to clients not prepared to support file system migration. Such clients may be following the error specifications in [RFC7530] and so might not expect NFS4ERR_DELAY to be returned on RELEASE_LOCKOWNER.
需要明确的是，服务器可能不会将此错误返回给不准备支持文件系统迁移的客户端。此类客户端可能遵循[RFC7530]中的错误规范，因此可能不希望在发布时返回NFS4ERR_延迟。
The following constraint applies to this additional error return, as if it were a note appearing together with the newly allowed error code:
以下约束适用于此附加错误返回，就好像它是与新允许的错误代码一起出现的注释一样：
In order to make server state fixed for a file system being migrated, a server MAY return NFS4ERR_DELAY in response to a RELEASE_LOCKOWNER that will affect locking state being propagated to a destination server. The source server MUST NOT do so unless it is likely that it will later return NFS4ERR_MOVED for the file system in question.
为了固定要迁移的文件系统的服务器状态，服务器可能会返回NFS4ERR_延迟，以响应将影响传播到目标服务器的锁定状态的RELEASE_LOCKOWNER。源服务器不能这样做，除非它以后可能会返回有关文件系统的NFS4ERR_MOVED。
In the context of lock-owner release, the set of file systems, such that server state being made fixed can result in NFS4ERR_DELAY, must include the file system on which the operation associated with the current lock-owner seqid was performed.
在锁所有者释放的上下文中，文件系统集必须包括在其上执行与当前锁所有者seqid相关联的操作的文件系统，这样服务器状态被修复可能会导致NFS4ERR_延迟。
In addition, this set may include other file systems on which an operation associated with an earlier seqid for the current lock-owner seqid was performed, since servers will have to deal with the issue of an owner being used in succession for multiple file systems.
此外，该集合可能包括在其上执行与当前锁所有者seqid的早期seqid相关联的操作的其他文件系统，因为服务器将必须处理所有者连续用于多个文件系统的问题。
Thus, if a client is prepared to receive NFS4ERR_MOVED after creating state associated with a given file system, it also needs to be prepared to receive NFS4ERR_DELAY in response to RELEASE_LOCKOWNER, if it has used that owner in connection with a file on that file system.
因此，如果客户机准备接收在创建与给定文件系统关联的状态后移动的NFS4ERR_，那么它还需要准备接收NFS4ERR_延迟，以响应释放锁定所有者，如果它已将该所有者与该文件系统上的文件联用。
client, callback, callback_ident -> clientid, setclientid_confirm
客户端，回调，回调识别->客户端ID，设置客户端ID\u确认
struct SETCLIENTID4args {
nfs_client_id4 client;
cb_client4 callback;
uint32_t callback_ident;
};
struct SETCLIENTID4args {
nfs_client_id4 client;
cb_client4 callback;
uint32_t callback_ident;
};
struct SETCLIENTID4resok {
clientid4 clientid;
verifier4 setclientid_confirm;
};
struct SETCLIENTID4resok {
clientid4 clientid;
verifier4 setclientid_confirm;
};
union SETCLIENTID4res switch (nfsstat4 status) {
case NFS4_OK:
SETCLIENTID4resok resok4;
case NFS4ERR_CLID_INUSE:
clientaddr4 client_using;
default:
void;
};
union SETCLIENTID4res switch (nfsstat4 status) {
case NFS4_OK:
SETCLIENTID4resok resok4;
case NFS4ERR_CLID_INUSE:
clientaddr4 client_using;
default:
void;
};
The client uses the SETCLIENTID operation to notify the server of its intention to use a particular client identifier, callback, and callback_ident for subsequent requests that entail creating lock, share reservation, and delegation state on the server. Upon successful completion, the server will return a shorthand client ID that, if confirmed via a separate step, will be used in subsequent file locking and file open requests. Confirmation of the client ID must be done via the SETCLIENTID_CONFIRM operation to return the client ID and setclientid_confirm values, as verifiers, to the server. The reason why two verifiers are necessary is that it is possible to use SETCLIENTID and SETCLIENTID_CONFIRM to modify the callback and callback_ident information but not the shorthand client ID. In that event, the setclientid_confirm value is effectively the only verifier.
客户端使用SETCLIENTID操作通知服务器，它打算为后续请求使用特定的客户端标识符、回调和回调标识，这些请求需要在服务器上创建锁、共享保留和委派状态。成功完成后，服务器将返回一个速记客户端ID，如果通过单独的步骤确认，该ID将用于后续的文件锁定和文件打开请求。必须通过SETCLIENTID_确认操作确认客户端ID，以将客户端ID和SETCLIENTID_确认值作为验证器返回到服务器。之所以需要两个验证器，是因为可以使用SETCLIENTID和SETCLIENTID_确认来修改回调和回调标识信息，但不能修改速记客户端ID。在这种情况下，SETCLIENTID_确认值实际上是唯一的验证器。
The callback information provided in this operation will be used if the client is provided an open delegation at a future point. Therefore, the client must correctly reflect the program and port numbers for the callback program at the time SETCLIENTID is used.
如果在将来某个时间点向客户端提供了开放委托，则将使用此操作中提供的回调信息。因此，在使用SETCLIENTID时，客户端必须正确反映回调程序的程序和端口号。
The callback_ident value is used by the server on the callback. The client can leverage the callback_ident to eliminate the need for more than one callback RPC program number, while still being able to determine which server is initiating the callback.
服务器在回调上使用回调_ident值。客户端可以利用回调标识消除对多个回调RPC程序号的需要，同时仍然能够确定哪个服务器正在启动回调。
To specify the implementation of SETCLIENTID, the following notations are used.
要指定SETCLIENTID的实现，请使用以下符号。
Let:
让我们：
x be the value of the client.id subfield of the SETCLIENTID4args structure.
x是SetClientIDArgs结构的client.id子字段的值。
v be the value of the client.verifier subfield of the SETCLIENTID4args structure.
v是SetClientIDArgs结构的client.verifier子字段的值。
c be the value of the client ID field returned in the SETCLIENTID4resok structure.
c是SetClientIDResok结构中返回的客户端ID字段的值。
k represent the value combination of the callback and callback_ident fields of the SETCLIENTID4args structure.
k表示SetClientIDArgs结构的回调和回调标识字段的值组合。
s be the setclientid_confirm value returned in the SETCLIENTID4resok structure.
s是setclientid\u确认值，该值在SetClientD4Resok结构中返回。
{ v, x, c, k, s } be a quintuple for a client record. A client record is confirmed if there has been a SETCLIENTID_CONFIRM operation to confirm it. Otherwise, it is unconfirmed. An unconfirmed record is established by a SETCLIENTID call.
{v，x，c，k，s}对于客户端记录来说是五元组。如果已通过SETCLIENTID_确认操作对客户端记录进行确认，则会确认客户端记录。否则，这是未确认的。通过SETCLIENTID调用建立未确认的记录。
Since SETCLIENTID is a non-idempotent operation, our treatment assumes use of a duplicate request cache (DRC). For a discussion of the DRC, see Section 9.1.7 of [RFC7530].
由于SETCLIENTID是一个非幂等操作，我们的处理假设使用重复请求缓存（DRC）。有关DRC的讨论，请参见[RFC7530]第9.1.7节。
When the server gets a SETCLIENTID { v, x, k } request, it first does a number of preliminary checks as listed below before proceeding to the main part of SETCLIENTID processing.
当服务器收到SETCLIENTID{v，x，k}请求时，它首先执行以下列出的一些初步检查，然后再继续进行SETCLIENTID处理的主要部分。
o It first looks up the request in the DRC. If there is a hit, it returns the result cached in the DRC. The server does NOT remove client state (locks, shares, delegations) nor does it modify any recorded callback and callback_ident information for client { x }. The server now proceeds to the main part of SETCLIENTID.
o 它首先在DRC中查找请求。如果有命中，它将返回缓存在DRC中的结果。服务器不会删除客户端状态（锁、共享、委派），也不会修改客户端{x}的任何记录的回调和回调标识信息。服务器现在转到SETCLIENTID的主要部分。
o Otherwise (i.e., in the case of any DRC miss), the server takes the client ID string x and searches for confirmed client records for x that the server may have recorded from previous SETCLIENTID calls. If there are no such records, or if all such records have
o 否则（即，在任何DRC未命中的情况下），服务器将获取客户端ID字符串x，并搜索服务器可能已从以前的SETCLIENTID调用中记录的x的已确认客户端记录。如果没有此类记录，或者如果所有此类记录
a recorded principal that matches that of the current request's principal, then the preparatory phase proceeds as follows.
一个与当前请求的主体匹配的记录主体，然后准备阶段如下进行。
* If there is a confirmed client record with a matching client ID string and a non-matching principal, the server checks the current state of the associated lease. If there is no associated state for the lease, or the lease has expired, the server proceeds to the main part of SETCLIENTID.
* 如果存在具有匹配客户端ID字符串和不匹配主体的已确认客户端记录，则服务器将检查关联租约的当前状态。如果租约没有关联状态，或者租约已过期，则服务器将转到SETCLIENTID的主要部分。
* Otherwise, the server is being asked to do a SETCLIENTID for a client by a non-matching principal while there is active state. In this case, the server rejects the SETCLIENTID request returning an NFS4ERR_CLID_INUSE error, since use of a single client with multiple principals is not allowed. Note that even though the previously used clientaddr4 is returned with this error, the use of the same id string with multiple clientaddr4s is not prohibited, while its use with multiple principals is prohibited.
* 否则，当存在活动状态时，非匹配主体会要求服务器为客户端执行SETCLIENTID。在这种情况下，服务器拒绝返回NFS4ERR_CLID_INUSE错误的SETCLIENTID请求，因为不允许使用具有多个主体的单个客户端。请注意，即使先前使用的ClientAddress4返回此错误，也不禁止将同一id字符串与多个ClientAddress4一起使用，而禁止将其与多个主体一起使用。
If the SETCLIENTID has not been dealt with by DRC processing, and has not been rejected with an NFS4ERR_CLID_INUSE error, then the main part of SETCLIENTID processing proceeds, as described below.
如果DRC处理尚未处理SETCLIENTID，且未因NFS4ERR_CLID_INUSE错误而拒绝该SETCLIENTID，则SETCLIENTID处理的主要部分将继续进行，如下所述。
o The server checks if it has recorded a confirmed record for { v, x, c, l, s }, where l may or may not equal k. If so, and since the id verifier v of the request matches that which is confirmed and recorded, the server treats this as a probable callback information update and records an unconfirmed { v, x, c, k, t } and leaves the confirmed { v, x, c, l, s } in place, such that t != s. It does not matter if k equals l or not. Any pre-existing unconfirmed { v, x, c, *, * } is removed.
o 服务器检查它是否记录了{v，x，c，l，s}的确认记录，其中l可能等于或不等于k。如果是，并且由于请求的id验证器v与确认和记录的id验证器v匹配，服务器将此视为可能的回调信息更新，并记录未确认的{v，x，c，k，t}，并将确认的{v，x，c，l，s}保留在适当的位置，使得t！=sk是否等于l并不重要。任何预先存在的未确认{v，x，c，*，*}将被删除。
The server returns { c, t }. It is indeed returning the old clientid4 value c, because the client apparently only wants to update callback value k to value l. It's possible this request is one from the Byzantine router that has stale callback information, but this is not a problem. The callback information update is only confirmed if followed up by a SETCLIENTID_CONFIRM { c, t }.
服务器返回{c，t}。它确实返回了旧的client4值c，因为客户端显然只想将回调值k更新为值l。这个请求可能来自拜占庭路由器，它有过时的回调信息，但这不是问题。回调信息更新仅在随后是SETCLIENTID_CONFIRM{c，t}时确认。
The server awaits confirmation of k via SETCLIENTID_CONFIRM { c, t }.
服务器通过SETCLIENTID_CONFIRM{c，t}等待k的确认。
The server does NOT remove client (lock/share/delegation) state for x.
服务器未删除x的客户端（锁定/共享/委派）状态。
o The server has previously recorded a confirmed { u, x, c, l, s } record such that v != u, l may or may not equal k, and has not recorded any unconfirmed { *, x, *, *, * } record for x. The server records an unconfirmed { v, x, d, k, t } (d != c, t != s).
o 服务器以前记录了一个已确认的{u，x，c，l，s}记录，因此v！=u、 l可能等于或不等于k，并且没有记录x的任何未经确认的{*，x，*，*，*}记录。服务器记录一个未确认的{v，x，d，k，t}（d！=c，t！=s）。
The server returns { d, t }.
服务器返回{d，t}。
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM { d, t }.
服务器等待通过SETCLIENTID_CONFIRM{d，t}确认{d，k}。
The server does NOT remove client (lock/share/delegation) state for x.
服务器未删除x的客户端（锁定/共享/委派）状态。
o The server has previously recorded a confirmed { u, x, c, l, s } record such that v != u, l may or may not equal k, and recorded an unconfirmed { w, x, d, m, t } record such that c != d, t != s, m may or may not equal k, m may or may not equal l, and k may or may not equal l. Whether w == v or w != v makes no difference. The server simply removes the unconfirmed { w, x, d, m, t } record and replaces it with an unconfirmed { v, x, e, k, r } record, such that e != d, e != c, r != t, r != s.
o 服务器以前记录了一个已确认的{u，x，c，l，s}记录，因此v！=u、 l可以等于k，也可以不等于k，并且记录了一个未确认的{w，x，d，m，t}记录，使得c！=d、 t！=s、 m可以等于或不等于k，m可以等于或不等于l，k可以等于或不等于l。无论w==v还是w！=v没有区别。服务器只是删除未确认的{w，x，d，m，t}记录，并将其替换为未确认的{v，x，e，k，r}记录，这样e！=d、 e！=c、 r！=t、 r！=s
The server returns { e, r }.
服务器返回{e，r}。
The server awaits confirmation of { e, k } via SETCLIENTID_CONFIRM { e, r }.
服务器等待通过SETCLIENTID_CONFIRM{e，r}确认{e，k}。
The server does NOT remove client (lock/share/delegation) state for x.
服务器未删除x的客户端（锁定/共享/委派）状态。
o The server has no confirmed { *, x, *, *, * } for x. It may or may not have recorded an unconfirmed { u, x, c, l, s }, where l may or may not equal k, and u may or may not equal v. Any unconfirmed record { u, x, c, l, * }, regardless whether u == v or l == k, is replaced with an unconfirmed record { v, x, d, k, t } where d != c, t != s.
o 服务器没有确认x的{*，x，*，*，*，*}。它可能记录了也可能没有记录了一个未确认的{u，x，c，l，s}，其中l可能等于或不等于k，u可能等于或不等于v。任何未确认的记录{u，x，c，l，*}，无论u==v还是l==k，都将替换为未确认的记录{v，x，d，k，t}，其中d！=c、 t！=s
The server returns { d, t }.
服务器返回{d，t}。
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM { d, t }. The server does NOT remove client (lock/share/ delegation) state for x.
服务器等待通过SETCLIENTID_CONFIRM{d，t}确认{d，k}。服务器未删除x的客户端（锁定/共享/委派）状态。
The server generates the clientid and setclientid_confirm values and must take care to ensure that these values are extremely unlikely to ever be regenerated.
服务器生成clientid和setclientid_确认值，并且必须注意确保这些值不太可能重新生成。
Although the means by which the source and destination server communicate is not specified by NFSv4.0, the following security-related considerations for inter-server communication should be noted.
尽管NFSv4.0未指定源服务器和目标服务器通信的方式，但应注意以下服务器间通信的安全相关注意事项。
o Communication between source and destination servers needs to be carried out in a secure manner, with protection against deliberate modification of data in transit provided by using either a private network or a security mechanism that ensures integrity. In many cases, privacy will also be required, requiring a strengthened security mechanism if a private network is not used.
o 源服务器和目标服务器之间的通信需要以安全的方式进行，通过使用专用网络或确保完整性的安全机制，防止传输中的数据被蓄意修改。在许多情况下，还需要隐私，如果不使用私有网络，则需要加强安全机制。
o Effective implementation of the file system migration function requires that a trust relationship exist between source and destination servers. The details of that trust relationship depend on the specifics of the inter-server transfer protocol, which is outside the scope of this specification.
o 文件系统迁移功能的有效实现要求源服务器和目标服务器之间存在信任关系。该信任关系的详细信息取决于服务器间传输协议的细节，该协议不在本规范的范围内。
o The source server may communicate to the destination server security-related information in order to allow it to more rigorously validate clients' identity. For example, the destination server might reject a SETCLIENTID done with a different principal or with a different IP address than was done previously by the client on the source server. However, the destination server MUST NOT use this information to allow any operation to be performed by the client that would not be allowed otherwise.
o 源服务器可以与目标服务器通信安全相关信息，以便允许其更严格地验证客户端的身份。例如，目标服务器可能会拒绝使用与源服务器上的客户端以前使用不同的主体或IP地址执行的SETCLIENTID。但是，目标服务器不得使用此信息来允许客户端执行其他情况下不允许的任何操作。
The penultimate paragraph of Section 19 of [RFC7530] should be revised to read as follows:
[RFC7530]第19节倒数第二段应修改如下：
Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are responsible for the release of client state, it is imperative that the principal used for these operations be checked against and match the previous use of these operations. In addition, use of integrity protection is desirable on the SETCLIENTID operation, to prevent an attack whereby a change in the boot instance id (verifier) forces an undesired loss of client state. See Section 5 for further discussion.
由于SETCLIENTID/SETCLIENTID_CONFIRM操作负责释放客户端状态，因此必须对照这些操作的先前使用情况检查并匹配用于这些操作的主体。此外，希望在SETCLIENTID操作上使用完整性保护，以防止通过更改引导实例id（验证器）强制不希望的客户端状态丢失的攻击。进一步讨论见第5节。
The security considerations of [RFC7530] remain appropriate with the exception of the modification to the penultimate paragraph specified in Section 8.6 of this document and the addition of the material in Section 8.5.
[RFC7530]的安全考虑因素仍然适用，但本文件第8.6节规定的倒数第二段的修改和第8.5节中的材料添加除外。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.和D.Noveck，Ed.，“网络文件系统（NFS）第4版协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<http://www.rfc-editor.org/info/rfc7530>.
[INFO-MIGR] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, "NFSv4 migration: Implementation experience and spec issues to resolve", Work in Progress, draft-ietf-nfsv4- migration-issues-09, February 2016.
[INFO-MIGR]Noveck，D.，Ed.，Shivam，P.，Lever，C.，和B.Baker，“NFSv4迁移：需要解决的实施经验和规范问题”，在建工程，草案-ietf-NFSv4-迁移问题-09，2016年2月。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, DOI 10.17487/RFC1813, June 1995, <http://www.rfc-editor.org/info/rfc1813>.
[RFC1813]Callaghan，B.，Pawlowski，B.，和P.Staubach，“NFS版本3协议规范”，RFC 1813，DOI 10.17487/RFC1813，1995年6月<http://www.rfc-editor.org/info/rfc1813>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <http://www.rfc-editor.org/info/rfc5661>.
[RFC5661]Shepler，S.，Ed.，Eisler，M.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1协议”，RFC 5661，DOI 10.17487/RFC5661，2010年1月<http://www.rfc-editor.org/info/rfc5661>.
Acknowledgements
致谢
The editor and authors of this document gratefully acknowledge the contributions of Trond Myklebust of Primary Data and Robert Thurlow of Oracle. We also thank Tom Haynes of Primary Data and Spencer Shepler of Microsoft for their guidance and suggestions.
本文档的编辑和作者非常感谢Primary Data的Trond Myklebast和Oracle的Robert Thurlow的贡献。我们还感谢Primary Data的汤姆·海恩斯（Tom Haynes）和微软的斯宾塞·谢普勒（Spencer Shepler）提供的指导和建议。
Special thanks go to members of the Oracle Solaris NFS team, especially Rick Mesta and James Wahlig, for their work implementing an NFSv4.0 migration prototype and identifying many of the issues addressed here.
特别感谢Oracle Solaris NFS团队的成员，特别是Rick Mesta和James Wahlig，感谢他们在实现NFSv4.0迁移原型和确定此处解决的许多问题方面所做的工作。
Authors' Addresses
作者地址
David Noveck (editor) Hewlett Packard Enterprise 165 Dascomb Road Andover, MA 01810 United States of America
David Noveck（编辑）美国马萨诸塞州安多佛达斯库姆路165号惠普企业，邮编01810
Phone: +1 978 474 2011
Email: davenoveck@gmail.com
Phone: +1 978 474 2011
Email: davenoveck@gmail.com
Piyush Shivam Oracle Corporation 5300 Riata Park Ct. Austin, TX 78727 United States of America
皮尤斯希瓦姆甲骨文公司，邮编：5300里亚塔公园Ct。德克萨斯州奥斯汀78727美利坚合众国
Phone: +1 512 401 1019
Email: piyush.shivam@oracle.com
Phone: +1 512 401 1019
Email: piyush.shivam@oracle.com
Charles Lever Oracle Corporation 1015 Granger Avenue Ann Arbor, MI 48104 United States of America
美国密歇根州安阿伯格兰杰大道1015号查尔斯·利弗甲骨文公司，邮编：48104
Phone: +1 734 274 2396
Email: chuck.lever@oracle.com
Phone: +1 734 274 2396
Email: chuck.lever@oracle.com
Bill Baker Oracle Corporation 5300 Riata Park Ct. Austin, TX 78727 United States of America
比尔·贝克甲骨文公司，邮编：5300，里亚塔公园，密苏里州。德克萨斯州奥斯汀78727美利坚合众国
Phone: +1 512 401 1081
Email: bill.baker@oracle.com
Phone: +1 512 401 1081
Email: bill.baker@oracle.com