Internet Engineering Task Force (IETF) B. Halevy
Request for Comments: 8435
Category: Standards Track T. Haynes
ISSN: 2070-1721 Hammerspace
August 2018
Internet Engineering Task Force (IETF) B. Halevy
Request for Comments: 8435
Category: Standards Track T. Haynes
ISSN: 2070-1721 Hammerspace
August 2018
Parallel NFS (pNFS) Flexible File Layout
并行NFS（pNFS）灵活的文件布局
Abstract
摘要
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files.
并行NFS（pNFS）允许文件的元数据（在元数据服务器上）和数据（在存储设备上）分离。灵活的文件布局类型在本文档中定义为pNFS的扩展，允许使用只需要与元数据服务器进行有限程度交互并使用现有协议的存储设备。还添加了客户端镜像以提供文件复制。
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 https://www.rfc-editor.org/info/rfc8435.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8435.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Definitions ................................................4
1.2. Requirements Language ......................................6
2. Coupling of Storage Devices .....................................6
2.1. LAYOUTCOMMIT ...............................................7
2.2. Fencing Clients from the Storage Device ....................7
2.2.1. Implementation Notes for Synthetic uids/gids ........8
2.2.2. Example of Using Synthetic uids/gids ................9
2.3. State and Locking Models ..................................10
2.3.1. Loosely Coupled Locking Model ......................11
2.3.2. Tightly Coupled Locking Model ......................12
3. XDR Description of the Flexible File Layout Type ...............13
3.1. Code Components Licensing Notice ..........................14
4. Device Addressing and Discovery ................................16
4.1. ff_device_addr4 ...........................................16
4.2. Storage Device Multipathing ...............................17
5. Flexible File Layout Type ......................................18
5.1. ff_layout4 ................................................19
5.1.1. Error Codes from LAYOUTGET .........................23
5.1.2. Client Interactions with FF_FLAGS_NO_IO_THRU_MDS ...23
5.2. LAYOUTCOMMIT ..............................................24
5.3. Interactions between Devices and Layouts ..................24
5.4. Handling Version Errors ...................................24
6. Striping via Sparse Mapping ....................................25
7. Recovering from Client I/O Errors ..............................25
8. Mirroring ......................................................26
8.1. Selecting a Mirror ........................................26
8.2. Writing to Mirrors ........................................27
8.2.1. Single Storage Device Updates Mirrors ..............27
8.2.2. Client Updates All Mirrors .........................27
8.2.3. Handling Write Errors ..............................28
8.2.4. Handling Write COMMITs .............................28
8.3. Metadata Server Resilvering of the File ...................29
9. Flexible File Layout Type Return ...............................29
9.1. I/O Error Reporting .......................................30
9.1.1. ff_ioerr4 ..........................................30
9.2. Layout Usage Statistics ...................................31
9.2.1. ff_io_latency4 .....................................31
9.2.2. ff_layoutupdate4 ...................................32
9.2.3. ff_iostats4 ........................................33
9.3. ff_layoutreturn4 ..........................................34
10. Flexible File Layout Type LAYOUTERROR .........................35
11. Flexible File Layout Type LAYOUTSTATS .........................35
12. Flexible File Layout Type Creation Hint .......................35
12.1. ff_layouthint4 ...........................................35
13. Recalling a Layout ............................................36
1. Introduction ....................................................3
1.1. Definitions ................................................4
1.2. Requirements Language ......................................6
2. Coupling of Storage Devices .....................................6
2.1. LAYOUTCOMMIT ...............................................7
2.2. Fencing Clients from the Storage Device ....................7
2.2.1. Implementation Notes for Synthetic uids/gids ........8
2.2.2. Example of Using Synthetic uids/gids ................9
2.3. State and Locking Models ..................................10
2.3.1. Loosely Coupled Locking Model ......................11
2.3.2. Tightly Coupled Locking Model ......................12
3. XDR Description of the Flexible File Layout Type ...............13
3.1. Code Components Licensing Notice ..........................14
4. Device Addressing and Discovery ................................16
4.1. ff_device_addr4 ...........................................16
4.2. Storage Device Multipathing ...............................17
5. Flexible File Layout Type ......................................18
5.1. ff_layout4 ................................................19
5.1.1. Error Codes from LAYOUTGET .........................23
5.1.2. Client Interactions with FF_FLAGS_NO_IO_THRU_MDS ...23
5.2. LAYOUTCOMMIT ..............................................24
5.3. Interactions between Devices and Layouts ..................24
5.4. Handling Version Errors ...................................24
6. Striping via Sparse Mapping ....................................25
7. Recovering from Client I/O Errors ..............................25
8. Mirroring ......................................................26
8.1. Selecting a Mirror ........................................26
8.2. Writing to Mirrors ........................................27
8.2.1. Single Storage Device Updates Mirrors ..............27
8.2.2. Client Updates All Mirrors .........................27
8.2.3. Handling Write Errors ..............................28
8.2.4. Handling Write COMMITs .............................28
8.3. Metadata Server Resilvering of the File ...................29
9. Flexible File Layout Type Return ...............................29
9.1. I/O Error Reporting .......................................30
9.1.1. ff_ioerr4 ..........................................30
9.2. Layout Usage Statistics ...................................31
9.2.1. ff_io_latency4 .....................................31
9.2.2. ff_layoutupdate4 ...................................32
9.2.3. ff_iostats4 ........................................33
9.3. ff_layoutreturn4 ..........................................34
10. Flexible File Layout Type LAYOUTERROR .........................35
11. Flexible File Layout Type LAYOUTSTATS .........................35
12. Flexible File Layout Type Creation Hint .......................35
12.1. ff_layouthint4 ...........................................35
13. Recalling a Layout ............................................36
13.1. CB_RECALL_ANY ............................................36
14. Client Fencing ................................................37
15. Security Considerations .......................................37
15.1. RPCSEC_GSS and Security Services .........................39
15.1.1. Loosely Coupled ...................................39
15.1.2. Tightly Coupled ...................................39
16. IANA Considerations ...........................................39
17. References ....................................................40
17.1. Normative References .....................................40
17.2. Informative References ...................................41
Acknowledgments ...................................................42
Authors' Addresses ................................................42
13.1. CB_RECALL_ANY ............................................36
14. Client Fencing ................................................37
15. Security Considerations .......................................37
15.1. RPCSEC_GSS and Security Services .........................39
15.1.1. Loosely Coupled ...................................39
15.1.2. Tightly Coupled ...................................39
16. IANA Considerations ...........................................39
17. References ....................................................40
17.1. Normative References .....................................40
17.2. Informative References ...................................41
Acknowledgments ...................................................42
Authors' Addresses ................................................42
In Parallel NFS (pNFS), the metadata server returns layout type structures that describe where file data is located. There are different layout types for different storage systems and methods of arranging data on storage devices. This document defines the flexible file layout type used with file-based data servers that are accessed using the NFS protocols: NFSv3 [RFC1813], NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and NFSv4.2 [RFC7862].
在并行NFS（pNFS）中，元数据服务器返回描述文件数据所在位置的布局类型结构。对于不同的存储系统和在存储设备上排列数据的方法，有不同的布局类型。本文档定义了使用NFS协议访问的基于文件的数据服务器使用的灵活文件布局类型：NFSv3[RFC1813]、NFSv4.0[RFC7530]、NFSv4.1[RFC5661]和NFSv4.2[RFC7862]。
To provide a global state model equivalent to that of the files layout type, a back-end control protocol might be implemented between the metadata server and NFSv4.1+ storage devices. An implementation can either define its own proprietary mechanism or it could define a control protocol in a Standards Track document. The requirements for a control protocol are specified in [RFC5661] and clarified in [RFC8434].
为了提供与文件布局类型等效的全局状态模型，可以在元数据服务器和NFSv4.1+存储设备之间实现后端控制协议。实现可以定义自己的专有机制，也可以在标准跟踪文档中定义控制协议。控制协议的要求在[RFC5661]中规定，并在[RFC8434]中阐明。
The control protocol described in this document is based on NFS. It does not provide for knowledge of stateids to be passed between the metadata server and the storage devices. Instead, the storage devices are configured such that the metadata server has full access rights to the data file system and then the metadata server uses synthetic ids to control client access to individual files.
本文档中描述的控制协议基于NFS。它不提供元数据服务器和存储设备之间要传递的stateID的知识。相反，存储设备的配置使元数据服务器具有对数据文件系统的完全访问权限，然后元数据服务器使用合成ID控制客户端对单个文件的访问。
In traditional mirroring of data, the server is responsible for replicating, validating, and repairing copies of the data file. With client-side mirroring, the metadata server provides a layout that presents the available mirrors to the client. The client then picks a mirror to read from and ensures that all writes go to all mirrors. The client only considers the write transaction to have succeeded if all mirrors are successfully updated. In case of error, the client can use the LAYOUTERROR operation to inform the metadata server, which is then responsible for the repairing of the mirrored copies of the file.
在传统的数据镜像中，服务器负责复制、验证和修复数据文件的副本。通过客户端镜像，元数据服务器提供了向客户端显示可用镜像的布局。然后，客户端选择一个镜像进行读取，并确保所有写入都转到所有镜像。只有在成功更新所有镜像的情况下，客户端才会认为写入事务已成功。如果出现错误，客户端可以使用LAYOUTERROR操作通知元数据服务器，然后元数据服务器负责修复文件的镜像副本。
control communication requirements: the specification for information on layouts, stateids, file metadata, and file data that must be communicated between the metadata server and the storage devices. There is a separate set of requirements for each layout type.
控制通信要求：有关布局、状态ID、文件元数据和必须在元数据服务器和存储设备之间通信的文件数据的信息的规范。每种布局类型都有一套单独的要求。
control protocol: the particular mechanism that an implementation of a layout type would use to meet the control communication requirement for that layout type. This need not be a protocol as normally understood. In some cases, the same protocol may be used as a control protocol and storage protocol.
控制协议：布局类型的实现用于满足该布局类型的控制通信要求的特定机制。这不需要是通常理解的协议。在某些情况下，相同的协议可用作控制协议和存储协议。
client-side mirroring: a feature in which the client, not the server, is responsible for updating all of the mirrored copies of a layout segment.
客户端镜像：客户端而不是服务器负责更新布局段的所有镜像副本的功能。
(file) data: that part of the file system object that contains the data to be read or written. It is the contents of the object rather than the attributes of the object.
（文件）数据：文件系统对象中包含要读取或写入的数据的部分。它是对象的内容，而不是对象的属性。
data server (DS): a pNFS server that provides the file's data when the file system object is accessed over a file-based protocol.
数据服务器（DS）：通过基于文件的协议访问文件系统对象时提供文件数据的pNFS服务器。
fencing: the process by which the metadata server prevents the storage devices from processing I/O from a specific client to a specific file.
防护：元数据服务器阻止存储设备处理从特定客户端到特定文件的I/O的过程。
file layout type: a layout type in which the storage devices are accessed via the NFS protocol (see Section 13 of [RFC5661]).
文件布局类型：通过NFS协议访问存储设备的布局类型（参见[RFC5661]第13节）。
gid: the group id, a numeric value that identifies to which group a file belongs.
gid：组id，一个数字值，用于标识文件所属的组。
layout: the information a client uses to access file data on a storage device. This information includes specification of the protocol (layout type) and the identity of the storage devices to be used.
布局：客户端用于访问存储设备上的文件数据的信息。此信息包括协议规范（布局类型）和要使用的存储设备的标识。
layout iomode: a grant of either read-only or read/write I/O to the client.
布局iomode：向客户端授予只读或读/写I/O。
layout segment: a sub-division of a layout. That sub-division might be by the layout iomode (see Sections 3.3.20 and 12.2.9 of [RFC5661]), a striping pattern (see Section 13.3 of [RFC5661]), or requested byte range.
布局段：布局的子分区。该子划分可能由布局iomode（见[RFC5661]第3.3.20节和第12.2.9节）、条带模式（见[RFC5661]第13.3节）或请求的字节范围决定。
layout stateid: a 128-bit quantity returned by a server that uniquely defines the layout state provided by the server for a specific layout that describes a layout type and file (see Section 12.5.2 of [RFC5661]). Further, Section 12.5.3 of [RFC5661] describes differences in handling between layout stateids and other stateid types.
layout stateid：服务器返回的128位数量，它唯一地定义了服务器为描述布局类型和文件的特定布局提供的布局状态（参见[RFC5661]第12.5.2节）。此外，[RFC5661]第12.5.3节描述了布局stateid和其他stateid类型之间的处理差异。
layout type: a specification of both the storage protocol used to access the data and the aggregation scheme used to lay out the file data on the underlying storage devices.
布局类型：用于访问数据的存储协议和用于在底层存储设备上布局文件数据的聚合方案的规范。
loose coupling: when the control protocol is a storage protocol.
松耦合：当控制协议是存储协议时。
(file) metadata: the part of the file system object that contains various descriptive data relevant to the file object, as opposed to the file data itself. This could include the time of last modification, access time, EOF position, etc.
（文件）元数据：文件系统对象的一部分，它包含与文件对象相关的各种描述性数据，而不是文件数据本身。这可能包括上次修改的时间、访问时间、EOF位置等。
metadata server (MDS): the pNFS server that provides metadata information for a file system object. It is also responsible for generating, recalling, and revoking layouts for file system objects, for performing directory operations, and for performing I/O operations to regular files when the clients direct these to the metadata server itself.
元数据服务器（MDS）：为文件系统对象提供元数据信息的pNFS服务器。它还负责生成、调用和撤销文件系统对象的布局，执行目录操作，以及在客户端将常规文件定向到元数据服务器本身时对常规文件执行I/O操作。
mirror: a copy of a layout segment. Note that if one copy of the mirror is updated, then all copies must be updated.
镜像：布局段的副本。请注意，如果更新了镜像的一个副本，则必须更新所有副本。
recalling a layout: a graceful recall, via a callback, of a specific layout by the metadata server to the client. Graceful here means that the client would have the opportunity to flush any WRITEs, etc., before returning the layout to the metadata server.
调用布局：通过回调，元数据服务器向客户端优雅地调用特定布局。这里的优雅意味着，在将布局返回到元数据服务器之前，客户端将有机会刷新任何写入操作等。
revoking a layout: an invalidation of a specific layout by the metadata server. Once revocation occurs, the metadata server will not accept as valid any reference to the revoked layout, and a storage device will not accept any client access based on the layout.
撤销布局：元数据服务器对特定布局的失效。一旦发生撤销，元数据服务器将不接受对已撤销布局的任何引用作为有效引用，并且存储设备将不接受基于该布局的任何客户端访问。
resilvering: the act of rebuilding a mirrored copy of a layout segment from a known good copy of the layout segment. Note that this can also be done to create a new mirrored copy of the layout segment.
调整大小：从已知良好的布局段副本重建布局段镜像副本的行为。请注意，这也可以用于创建布局段的新镜像副本。
rsize: the data transfer buffer size used for READs.
rsize：用于读取的数据传输缓冲区大小。
stateid: a 128-bit quantity returned by a server that uniquely defines the set of locking-related state provided by the server. Stateids may designate state related to open files, byte-range locks, delegations, or layouts.
stateid：服务器返回的128位数量，它唯一地定义了服务器提供的锁定相关状态集。StateID可以指定与打开的文件、字节范围锁、委托或布局相关的状态。
storage device: the target to which clients may direct I/O requests when they hold an appropriate layout. See Section 2.1 of [RFC8434] for further discussion of the difference between a data server and a storage device.
存储设备：当客户端持有适当的布局时，可以将I/O请求定向到的目标。有关数据服务器和存储设备之间区别的进一步讨论，请参见[RFC8434]的第2.1节。
storage protocol: the protocol used by clients to do I/O operations to the storage device. Each layout type specifies the set of storage protocols.
存储协议：客户端用于对存储设备执行I/O操作的协议。每种布局类型指定一组存储协议。
tight coupling: an arrangement in which the control protocol is one designed specifically for control communication. It may be either a proprietary protocol adapted specifically to a particular metadata server or a protocol based on a Standards Track document.
紧密耦合：一种安排，其中控制协议是专门为控制通信设计的协议。它可以是专门适用于特定元数据服务器的专有协议，也可以是基于标准跟踪文档的协议。
uid: the user id, a numeric value that identifies which user owns a file.
uid：用户id，一个标识文件所有者的数值。
wsize: the data transfer buffer size used for WRITEs.
wsize：用于写入的数据传输缓冲区大小。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
A server implementation may choose either a loosely coupled model or a tightly coupled model between the metadata server and the storage devices. [RFC8434] describes the general problems facing pNFS implementations. This document details how the new flexible file layout type addresses these issues. To implement the tightly coupled model, a control protocol has to be defined. As the flexible file layout imposes no special requirements on the client, the control protocol will need to provide:
服务器实现可以在元数据服务器和存储设备之间选择松耦合模型或紧耦合模型。[RFC8434]描述了pNFS实现面临的一般问题。本文档详细介绍了新的灵活文件布局类型如何解决这些问题。为了实现紧耦合模型，必须定义一个控制协议。由于灵活的文件布局对客户无特殊要求，控制协议需要提供：
(1) management of both security and LAYOUTCOMMITs and
(1) 安全和布局提交的管理，以及
(2) a global stateid model and management of these stateids.
(2) 全局stateid模型和这些stateid的管理。
When implementing the loosely coupled model, the only control protocol will be a version of NFS, with no ability to provide a global stateid model or to prevent clients from using layouts inappropriately. To enable client use in that environment, this document will specify how security, state, and locking are to be managed.
在实现松耦合模型时，唯一的控制协议将是NFS版本，无法提供全局stateid模型或防止客户端不适当地使用布局。为了使客户端能够在该环境中使用，本文档将指定如何管理安全性、状态和锁定。
Regardless of the coupling model, the metadata server has the responsibility, upon receiving a LAYOUTCOMMIT (see Section 18.42 of [RFC5661]) to ensure that the semantics of pNFS are respected (see Section 3.1 of [RFC8434]). These do include a requirement that data written to a data storage device be stable before the occurrence of the LAYOUTCOMMIT.
无论耦合模型如何，元数据服务器都有责任在收到LAYOUTCOMMIT（参见[RFC5661]第18.42节）时确保PNF的语义得到尊重（参见[RFC8434]第3.1节）。这些要求包括写入数据存储设备的数据在LAYOUTCOMMIT发生之前保持稳定。
It is the responsibility of the client to make sure the data file is stable before the metadata server begins to query the storage devices about the changes to the file. If any WRITE to a storage device did not result with stable_how equal to FILE_SYNC, a LAYOUTCOMMIT to the metadata server MUST be preceded by a COMMIT to the storage devices written to. Note that if the client has not done a COMMIT to the storage device, then the LAYOUTCOMMIT might not be synchronized to the last WRITE operation to the storage device.
在元数据服务器开始向存储设备查询文件更改之前，客户机负责确保数据文件稳定。如果对存储设备的任何写入未导致稳定的_how等于文件_SYNC，则对元数据服务器的LAYOUTCOMMIT之前必须对写入的存储设备进行提交。请注意，如果客户端尚未对存储设备执行提交，则LAYOUTCOMMIT可能不会同步到对存储设备的最后一次写入操作。
With loosely coupled storage devices, the metadata server uses synthetic uids (user ids) and gids (group ids) for the data file, where the uid owner of the data file is allowed read/write access and the gid owner is allowed read-only access. As part of the layout (see ffds_user and ffds_group in Section 5.1), the client is provided with the user and group to be used in the Remote Procedure Call (RPC) [RFC5531] credentials needed to access the data file. Fencing off of clients is achieved by the metadata server changing the synthetic uid and/or gid owners of the data file on the storage device to implicitly revoke the outstanding RPC credentials. A client presenting the wrong credential for the desired access will get an NFS4ERR_ACCESS error.
对于松散耦合的存储设备，元数据服务器对数据文件使用合成uid（用户ID）和gid（组ID），其中数据文件的uid所有者允许读/写访问，gid所有者允许只读访问。作为布局的一部分（参见第5.1节中的ffds_用户和ffds_组），向客户端提供访问数据文件所需的远程过程调用（RPC）[RFC5531]凭据中使用的用户和组。通过元数据服务器更改存储设备上数据文件的合成uid和/或gid所有者以隐式撤销未完成的RPC凭据，可以实现对客户端的隔离。为所需访问提供错误凭据的客户端将出现NFS4ERR_访问错误。
With this loosely coupled model, the metadata server is not able to fence off a single client; it is forced to fence off all clients. However, as the other clients react to the fencing, returning their layouts and trying to get new ones, the metadata server can hand out a new uid and gid to allow access.
使用这种松散耦合的模型，元数据服务器无法隔离单个客户机；它被迫将所有客户拒之门外。但是，当其他客户端对隔离做出反应，返回它们的布局并尝试获取新布局时，元数据服务器可以发出新的uid和gid以允许访问。
It is RECOMMENDED to implement common access control methods at the storage device file system to allow only the metadata server root (super user) access to the storage device and to set the owner of all directories holding data files to the root user. This approach provides a practical model to enforce access control and fence off cooperative clients, but it cannot protect against malicious clients; hence, it provides a level of security equivalent to AUTH_SYS. It is RECOMMENDED that the communication between the metadata server and storage device be secure from eavesdroppers and man-in-the-middle protocol tampering. The security measure could be physical security (e.g., the servers are co-located in a physically secure area), encrypted communications, or some other technique.
建议在存储设备文件系统上实施常见的访问控制方法，以仅允许元数据服务器root（超级用户）访问存储设备，并将保存数据文件的所有目录的所有者设置为root用户。这种方法提供了一种实用的模型来实施访问控制和隔离协作客户端，但它不能防止恶意客户端；因此，它提供了相当于AUTH_SYS的安全级别。建议元数据服务器和存储设备之间的通信应安全，防止窃听者和中间人协议篡改。安全措施可以是物理安全（例如，服务器位于物理安全区域内）、加密通信或某些其他技术。
With tightly coupled storage devices, the metadata server sets the user and group owners, mode bits, and Access Control List (ACL) of the data file to be the same as the metadata file. And the client must authenticate with the storage device and go through the same authorization process it would go through via the metadata server. In the case of tight coupling, fencing is the responsibility of the control protocol and is not described in detail in this document. However, implementations of the tightly coupled locking model (see Section 2.3) will need a way to prevent access by certain clients to specific files by invalidating the corresponding stateids on the storage device. In such a scenario, the client will be given an error of NFS4ERR_BAD_STATEID.
对于紧密耦合的存储设备，元数据服务器将数据文件的用户和组所有者、模式位和访问控制列表（ACL）设置为与元数据文件相同。客户端必须与存储设备进行身份验证，并通过与元数据服务器相同的授权过程。在紧密耦合的情况下，围栏是控制协议的责任，本文件中没有详细描述。但是，紧耦合锁定模型的实现（请参见第2.3节）需要一种方法，通过使存储设备上相应的stateID无效来防止某些客户端访问特定文件。在这种情况下，客户端将收到一个错误NFS4ERR_BAD_STATEID。
The client need not know the model used between the metadata server and the storage device. It need only react consistently to any errors in interacting with the storage device. It should both return the layout and error to the metadata server and ask for a new layout. At that point, the metadata server can either hand out a new layout, hand out no layout (forcing the I/O through it), or deny the client further access to the file.
客户机不需要知道元数据服务器和存储设备之间使用的模型。它只需要在与存储设备交互时对任何错误做出一致的反应。它应该将布局和错误返回给元数据服务器，并请求新布局。此时，元数据服务器可以分发新布局、不分发布局（强制I/O通过布局），也可以拒绝客户机进一步访问该文件。
The selection method for the synthetic uids and gids to be used for fencing in loosely coupled storage devices is strictly an implementation issue. That is, an administrator might restrict a range of such ids available to the Lightweight Directory Access Protocol (LDAP) 'uid' field [RFC4519]. The administrator might also be able to choose an id that would never be used to grant access. Then, when the metadata server had a request to access a file, a SETATTR would be sent to the storage device to set the owner and group of the data file. The user and group might be selected in a round-robin fashion from the range of available ids.
在松散耦合存储设备中用于围栏的合成UID和GID的选择方法严格来说是一个实现问题。也就是说，管理员可能会限制轻量级目录访问协议（LDAP）“uid”字段[RFC4519]可用的此类ID的范围。管理员还可以选择一个永远不会用于授予访问权限的id。然后，当元数据服务器请求访问文件时，将向存储设备发送SETATTR以设置数据文件的所有者和组。可以从可用ID范围内以循环方式选择用户和组。
Those ids would be sent back as ffds_user and ffds_group to the client, who would present them as the RPC credentials to the storage device. When the client is done accessing the file and the metadata server knows that no other client is accessing the file, it can reset the owner and group to restrict access to the data file.
这些ID将作为ffds_用户和ffds_组发送回客户端，客户端将它们作为RPC凭据呈现给存储设备。当客户端访问完文件并且元数据服务器知道没有其他客户端访问该文件时，它可以重置所有者和组以限制对数据文件的访问。
When the metadata server wants to fence off a client, it changes the synthetic uid and/or gid to the restricted ids. Note that using a restricted id ensures that there is a change of owner and at least one id available that never gets allowed access.
当元数据服务器想要隔离客户端时，它会将合成uid和/或gid更改为受限ID。请注意，使用受限id可确保所有者发生变化，并且至少有一个id是不允许访问的。
Under an AUTH_SYS security model, synthetic uids and gids of 0 SHOULD be avoided. These typically either grant super access to files on a storage device or are mapped to an anonymous id. In the first case, even if the data file is fenced, the client might still be able to access the file. In the second case, multiple ids might be mapped to the anonymous ids.
在AUTH_SYS安全模型下，应避免合成UID和GID为0。它们通常授予对存储设备上文件的超级访问权限，或者映射到匿名id。在第一种情况下，即使数据文件被隔离，客户端也可能仍然能够访问该文件。在第二种情况下，多个ID可能映射到匿名ID。
The user loghyr creates a file "ompha.c" on the metadata server, which then creates a corresponding data file on the storage device.
用户loghyr在元数据服务器上创建一个文件“ompha.c”，然后元数据服务器在存储设备上创建一个相应的数据文件。
The metadata server entry may look like:
元数据服务器条目可能如下所示：
-rw-r--r-- 1 loghyr staff 1697 Dec 4 11:31 ompha.c
-rw-r--r--1 loghyr员工1697 Dec 4 11:31 ompha.c
On the storage device, the file may be assigned some unpredictable synthetic uid/gid to deny access:
在存储设备上，可能会为文件分配一些不可预测的合成uid/gid以拒绝访问：
-rw-r----- 1 19452 28418 1697 Dec 4 11:31 data_ompha.c
-rw-r----- 1 19452 28418 1697 Dec 4 11:31 data_ompha.c
When the file is opened on a client and accessed, the user will try to get a layout for the data file. Since the layout knows nothing about the user (and does not care), it does not matter whether the user loghyr or garbo opens the file. The client has to present an uid of 19452 to get write permission. If it presents any other value for the uid, then it must give a gid of 28418 to get read access.
在客户端上打开并访问文件时，用户将尝试获取数据文件的布局。因为布局对用户一无所知（也不关心），所以用户loghyr或garbo打开文件并不重要。客户端必须提供19452的uid才能获得写入权限。如果它为uid提供任何其他值，那么它必须提供28418的gid才能获得读取访问权。
Further, if the metadata server decides to fence the file, it should change the uid and/or gid such that these values neither match earlier values for that file nor match a predictable change based on an earlier fencing.
此外，如果元数据服务器决定隔离文件，它应该更改uid和/或gid，使这些值既不匹配该文件的早期值，也不匹配基于早期隔离的可预测更改。
-rw-r----- 1 19453 28419 1697 Dec 4 11:31 data_ompha.c
-rw-r----- 1 19453 28419 1697 Dec 4 11:31 data_ompha.c
The set of synthetic gids on the storage device should be selected such that there is no mapping in any of the name services used by the storage device, i.e., each group should have no members.
选择存储设备上的合成GID集时，应确保存储设备使用的任何名称服务中都没有映射，即每个组都不应有成员。
If the layout segment has an iomode of LAYOUTIOMODE4_READ, then the metadata server should return a synthetic uid that is not set on the storage device. Only the synthetic gid would be valid.
如果布局段的iomode为LAYOUTIOMODE4_READ，则元数据服务器应返回未在存储设备上设置的合成uid。只有合成gid才有效。
The client is thus solely responsible for enforcing file permissions in a loosely coupled model. To allow loghyr write access, it will send an RPC to the storage device with a credential of 1066:1067. To allow garbo read access, it will send an RPC to the storage device with a credential of 1067:1067. The value of the uid does not matter as long as it is not the synthetic uid granted when getting the layout.
因此，客户机完全负责在松散耦合模型中强制执行文件权限。要允许loghyr写访问，它将使用凭证1066:1067向存储设备发送RPC。要允许garbo读取访问，它将使用凭证1067:1067向存储设备发送RPC。uid的值并不重要，只要它不是获得布局时授予的合成uid。
While pushing the enforcement of permission checking onto the client may seem to weaken security, the client may already be responsible for enforcing permissions before modifications are sent to a server. With cached writes, the client is always responsible for tracking who is modifying a file and making sure to not coalesce requests from multiple users into one request.
将权限检查的强制执行推到客户端可能会削弱安全性，但客户端可能已经负责在将修改发送到服务器之前强制执行权限。对于缓存写入，客户端始终负责跟踪修改文件的用户，并确保不会将多个用户的请求合并到一个请求中。
An implementation can always be deployed as a loosely coupled model. There is, however, no way for a storage device to indicate over an NFS protocol that it can definitively participate in a tightly coupled model:
实现始终可以作为松散耦合的模型进行部署。但是，存储设备无法通过NFS协议表明它可以最终参与紧耦合模型：
o Storage devices implementing the NFSv3 and NFSv4.0 protocols are always treated as loosely coupled.
o 实现NFSv3和NFSv4.0协议的存储设备始终被视为松耦合。
o NFSv4.1+ storage devices that do not return the EXCHGID4_FLAG_USE_PNFS_DS flag set to EXCHANGE_ID are indicating that they are to be treated as loosely coupled. From the locking viewpoint, they are treated in the same way as NFSv4.0 storage devices.
o NFSv4.1+未将EXCHGID4\u标志\u USE\u PNFS\u DS标志集返回到EXCHANGE\u ID的存储设备表示它们将被视为松散耦合。从锁定的角度来看，它们的处理方式与NFSv4.0存储设备相同。
o NFSv4.1+ storage devices that do identify themselves with the EXCHGID4_FLAG_USE_PNFS_DS flag set to EXCHANGE_ID can potentially be tightly coupled. They would use a back-end control protocol to implement the global stateid model as described in [RFC5661].
o NFSv4.1+使用EXCHGID4\u标志\u使用\u PNFS\u DS标志集来标识自己的存储设备可能会紧密耦合。他们将使用后端控制协议来实现[RFC5661]中描述的全局stateid模型。
A storage device would have to be either discovered or advertised over the control protocol to enable a tightly coupled model.
必须通过控制协议发现或公布存储设备，以启用紧密耦合模型。
When locking-related operations are requested, they are primarily dealt with by the metadata server, which generates the appropriate stateids. When an NFSv4 version is used as the data access protocol, the metadata server may make stateid-related requests of the storage devices. However, it is not required to do so, and the resulting stateids are known only to the metadata server and the storage device.
当请求与锁定相关的操作时，它们主要由元数据服务器处理，元数据服务器生成适当的stateID。当NFSv4版本用作数据访问协议时，元数据服务器可能会对存储设备发出与stateid相关的请求。但是，不需要这样做，并且生成的stateID只有元数据服务器和存储设备知道。
Given this basic structure, locking-related operations are handled as follows:
鉴于此基本结构，锁定相关操作的处理如下：
o OPENs are dealt with by the metadata server. Stateids are selected by the metadata server and associated with the client ID describing the client's connection to the metadata server. The metadata server may need to interact with the storage device to locate the file to be opened, but no locking-related functionality need be used on the storage device.
o 打开由元数据服务器处理。StateID由元数据服务器选择，并与描述客户端与元数据服务器连接的客户端ID相关联。元数据服务器可能需要与存储设备交互以定位要打开的文件，但不需要在存储设备上使用与锁定相关的功能。
OPEN_DOWNGRADE and CLOSE only require local execution on the metadata server.
打开降级和关闭只需要在元数据服务器上本地执行。
o Advisory byte-range locks can be implemented locally on the metadata server. As in the case of OPENs, the stateids associated with byte-range locks are assigned by the metadata server and only used on the metadata server.
o 建议字节范围锁可以在元数据服务器上本地实现。与打开的情况一样，与字节范围锁关联的stateID由元数据服务器分配，并且仅在元数据服务器上使用。
o Delegations are assigned by the metadata server that initiates recalls when conflicting OPENs are processed. No storage device involvement is required.
o 委托由元数据服务器分配，元数据服务器在处理冲突打开时启动回调。不需要涉及存储设备。
o TEST_STATEID and FREE_STATEID are processed locally on the metadata server, without storage device involvement.
o TEST_STATEID和FREE_STATEID在元数据服务器上本地处理，不涉及存储设备。
All I/O operations to the storage device are done using the anonymous stateid. Thus, the storage device has no information about the openowner and lockowner responsible for issuing a particular I/O operation. As a result:
存储设备的所有I/O操作都使用匿名stateid完成。因此，存储设备没有关于负责发出特定I/O操作的openowner和lockowner的信息。因此：
o Mandatory byte-range locking cannot be supported because the storage device has no way of distinguishing I/O done on behalf of the lock owner from those done by others.
o 无法支持强制字节范围锁定，因为存储设备无法区分代表锁所有者执行的I/O和其他人执行的I/O。
o Enforcement of share reservations is the responsibility of the client. Even though I/O is done using the anonymous stateid, the client must ensure that it has a valid stateid associated with the openowner.
o 执行股份保留是客户的责任。即使I/O是使用匿名stateid完成的，客户端也必须确保它具有与openowner关联的有效stateid。
In the event that a stateid is revoked, the metadata server is responsible for preventing client access, since it has no way of being sure that the client is aware that the stateid in question has been revoked.
在stateid被撤销的情况下，元数据服务器负责阻止客户端访问，因为它无法确保客户端知道相关stateid已被撤销。
As the client never receives a stateid generated by a storage device, there is no client lease on the storage device and no prospect of lease expiration, even when access is via NFSv4 protocols. Clients will have leases on the metadata server. In dealing with lease expiration, the metadata server may need to use fencing to prevent revoked stateids from being relied upon by a client unaware of the fact that they have been revoked.
由于客户端从未收到存储设备生成的stateid，因此存储设备上没有客户端租约，租约也不会到期，即使通过NFSv4协议进行访问也是如此。客户端将在元数据服务器上拥有租约。在处理租约到期时，元数据服务器可能需要使用围栏来防止被撤销的stateID被不知道它们已被撤销的客户机依赖。
When locking-related operations are requested, they are primarily dealt with by the metadata server, which generates the appropriate stateids. These stateids must be made known to the storage device using control protocol facilities, the details of which are not discussed in this document.
当请求与锁定相关的操作时，它们主要由元数据服务器处理，元数据服务器生成适当的stateID。必须使用控制协议设施将这些StateID告知存储设备，本文档中不讨论这些设施的详细信息。
Given this basic structure, locking-related operations are handled as follows:
鉴于此基本结构，锁定相关操作的处理如下：
o OPENs are dealt with primarily on the metadata server. Stateids are selected by the metadata server and associated with the client ID describing the client's connection to the metadata server. The metadata server needs to interact with the storage device to locate the file to be opened and to make the storage device aware of the association between the metadata-server-chosen stateid and the client and openowner that it represents.
o 打开主要在元数据服务器上处理。StateID由元数据服务器选择，并与描述客户端与元数据服务器连接的客户端ID相关联。元数据服务器需要与存储设备交互，以定位要打开的文件，并使存储设备知道元数据服务器选择的stateid与其代表的客户端和openowner之间的关联。
OPEN_DOWNGRADE and CLOSE are executed initially on the metadata server, but the state change made must be propagated to the storage device.
打开降级和关闭最初在元数据服务器上执行，但所做的状态更改必须传播到存储设备。
o Advisory byte-range locks can be implemented locally on the metadata server. As in the case of OPENs, the stateids associated with byte-range locks are assigned by the metadata server and are available for use on the metadata server. Because I/O operations are allowed to present lock stateids, the metadata server needs the ability to make the storage device aware of the association between the metadata-server-chosen stateid and the corresponding open stateid it is associated with.
o 建议字节范围锁可以在元数据服务器上本地实现。与打开的情况一样，与字节范围锁关联的stateID由元数据服务器分配，并可在元数据服务器上使用。由于允许I/O操作显示锁定状态ID，因此元数据服务器需要能够使存储设备知道元数据服务器选择的状态ID与其关联的相应打开状态ID之间的关联。
o Mandatory byte-range locks can be supported when both the metadata server and the storage devices have the appropriate support. As in the case of advisory byte-range locks, these are assigned by
o 如果元数据服务器和存储设备都具有相应的支持，则可以支持强制字节范围锁。与建议字节范围锁一样，这些锁由
the metadata server and are available for use on the metadata server. To enable mandatory lock enforcement on the storage device, the metadata server needs the ability to make the storage device aware of the association between the metadata-server-chosen stateid and the client, openowner, and lock (i.e., lockowner, byte-range, and lock-type) that it represents. Because I/O operations are allowed to present lock stateids, this information needs to be propagated to all storage devices to which I/O might be directed rather than only to storage device that contain the locked region.
元数据服务器和可在元数据服务器上使用。为了在存储设备上启用强制锁，元数据服务器需要能够使存储设备知道元数据服务器选择的stateid与其表示的客户端、openowner和锁（即lockowner、字节范围和锁类型）之间的关联。由于允许I/O操作显示锁定状态ID，因此需要将此信息传播到I/O可能指向的所有存储设备，而不仅仅是包含锁定区域的存储设备。
o Delegations are assigned by the metadata server that initiates recalls when conflicting OPENs are processed. Because I/O operations are allowed to present delegation stateids, the metadata server requires the ability (1) to make the storage device aware of the association between the metadata-server-chosen stateid and the filehandle and delegation type it represents and (2) to break such an association.
o 委托由元数据服务器分配，元数据服务器在处理冲突打开时启动回调。由于允许I/O操作显示委派stateid，因此元数据服务器需要具备以下能力：（1）使存储设备知道元数据服务器选择的stateid与其表示的文件句柄和委派类型之间的关联；（2）断开这种关联。
o TEST_STATEID is processed locally on the metadata server, without storage device involvement.
o TEST_STATEID在元数据服务器上本地处理，不涉及存储设备。
o FREE_STATEID is processed on the metadata server, but the metadata server requires the ability to propagate the request to the corresponding storage devices.
o FREE_STATEID在元数据服务器上处理，但元数据服务器需要能够将请求传播到相应的存储设备。
Because the client will possess and use stateids valid on the storage device, there will be a client lease on the storage device, and the possibility of lease expiration does exist. The best approach for the storage device is to retain these locks as a courtesy. However, if it does not do so, control protocol facilities need to provide the means to synchronize lock state between the metadata server and storage device.
由于客户端将拥有并使用存储设备上有效的StateID，因此存储设备上将存在客户端租约，并且租约到期的可能性确实存在。存储设备的最佳方法是保留这些锁，以示礼貌。但是，如果不这样做，则控制协议设施需要提供在元数据服务器和存储设备之间同步锁定状态的方法。
Clients will also have leases on the metadata server that are subject to expiration. In dealing with lease expiration, the metadata server would be expected to use control protocol facilities enabling it to invalidate revoked stateids on the storage device. In the event the client is not responsive, the metadata server may need to use fencing to prevent revoked stateids from being acted upon by the storage device.
客户端还将在元数据服务器上拥有到期的租约。在处理租约到期时，元数据服务器应使用控制协议设施，使其能够使存储设备上已撤销的StateID无效。如果客户端没有响应，元数据服务器可能需要使用围栏来防止存储设备对已撤销的StateID进行操作。
This document contains the External Data Representation (XDR) [RFC4506] description of the flexible file layout type. The XDR description is embedded in this document in a way that makes it simple for the reader to extract into a ready-to-compile form. The
本文档包含灵活文件布局类型的外部数据表示（XDR）[RFC4506]说明。XDR描述以某种方式嵌入到本文档中，使读者能够轻松地将其提取到准备编译的表单中。这个
reader can feed this document into the following shell script to produce the machine-readable XDR description of the flexible file layout type:
读者可以将此文档输入以下shell脚本，以生成灵活文件布局类型的机器可读XDR描述：
<CODE BEGINS>
<代码开始>
#!/bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
#!/bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
<CODE ENDS>
<代码结束>
That is, if the above script is stored in a file called "extract.sh" and this document is in a file called "spec.txt", then the reader can do:
也就是说，如果上述脚本存储在一个名为“extract.sh”的文件中，而此文档存储在一个名为“spec.txt”的文件中，则读者可以执行以下操作：
sh extract.sh < spec.txt > flex_files_prot.x
sh extract.sh<spec.txt>flex\u文件\u prot.x
The effect of the script is to remove leading white space from each line, plus a sentinel sequence of "///".
脚本的作用是删除每行的前导空格，以及“//”的哨兵序列。
The embedded XDR file header follows. Subsequent XDR descriptions with the sentinel sequence are embedded throughout the document.
下面是嵌入式XDR文件头。带有sentinel序列的后续XDR描述嵌入到整个文档中。
Note that the XDR code contained in this document depends on types from the NFSv4.1 nfs4_prot.x file [RFC5662]. This includes both nfs types that end with a 4, such as offset4, length4, etc., as well as more generic types such as uint32_t and uint64_t.
请注意，本文档中包含的XDR代码取决于NFSv4.1 nfs4_prot.x文件[RFC5662]中的类型。这包括以4结尾的nfs类型，如offset4、length4等，以及更通用的类型，如uint32和uint64。
Both the XDR description and the scripts used for extracting the XDR description are Code Components as described in Section 4 of "Trust Legal Provisions (TLP)" [LEGAL]. These Code Components are licensed according to the terms of that document.
XDR描述和用于提取XDR描述的脚本都是代码组件，如“信托法律条款（TLP）”[法律]第4节所述。这些代码组件根据该文档的条款获得许可。
<CODE BEGINS>
<代码开始>
/// /*
/// * Copyright (c) 2018 IETF Trust and the persons identified
/// * as authors of the code. All rights reserved.
/// *
/// * Redistribution and use in source and binary forms, with
/// * or without modification, are permitted provided that the
/// * following conditions are met:
/// *
/// * - Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// /*
/// * Copyright (c) 2018 IETF Trust and the persons identified
/// * as authors of the code. All rights reserved.
/// *
/// * Redistribution and use in source and binary forms, with
/// * or without modification, are permitted provided that the
/// * following conditions are met:
/// *
/// * - Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * - Redistributions in binary form must reproduce the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer in the documentation and/or other
/// * materials provided with the distribution.
/// *
/// * - Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to endorse or promote products derived from this
/// * software without specific prior written permission.
/// *
/// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// *
/// * This code was derived from RFC 8435.
/// * Please reproduce this note if possible.
/// */
///
/// /*
/// * flex_files_prot.x
/// */
///
/// /*
/// * The following include statements are for example only.
/// * The actual XDR definition files are generated separately
/// * and independently and are likely to have a different name.
/// * %#include <nfsv42.x>
/// * %#include <rpc_prot.x>
/// */
///
/// *
/// * - Redistributions in binary form must reproduce the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer in the documentation and/or other
/// * materials provided with the distribution.
/// *
/// * - Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to endorse or promote products derived from this
/// * software without specific prior written permission.
/// *
/// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// *
/// * This code was derived from RFC 8435.
/// * Please reproduce this note if possible.
/// */
///
/// /*
/// * flex_files_prot.x
/// */
///
/// /*
/// * The following include statements are for example only.
/// * The actual XDR definition files are generated separately
/// * and independently and are likely to have a different name.
/// * %#include <nfsv42.x>
/// * %#include <rpc_prot.x>
/// */
///
<CODE ENDS>
<代码结束>
Data operations to a storage device require the client to know the network address of the storage device. The NFSv4.1+ GETDEVICEINFO operation (Section 18.40 of [RFC5661]) is used by the client to retrieve that information.
对存储设备的数据操作要求客户端知道存储设备的网络地址。客户端使用NFSv4.1+GETDEVICEINFO操作（RFC5661的第18.40节）检索该信息。
The ff_device_addr4 data structure is returned by the server as the layout-type-specific opaque field da_addr_body in the device_addr4 structure by a successful GETDEVICEINFO operation.
通过成功的GETDEVICEINFO操作，服务器将ff_device_addr4数据结构作为设备_addr4结构中布局类型特定的不透明字段da_addr_body返回。
<CODE BEGINS>
<代码开始>
/// struct ff_device_versions4 {
/// uint32_t ffdv_version;
/// uint32_t ffdv_minorversion;
/// uint32_t ffdv_rsize;
/// uint32_t ffdv_wsize;
/// bool ffdv_tightly_coupled;
/// };
///
/// struct ff_device_versions4 {
/// uint32_t ffdv_version;
/// uint32_t ffdv_minorversion;
/// uint32_t ffdv_rsize;
/// uint32_t ffdv_wsize;
/// bool ffdv_tightly_coupled;
/// };
///
/// struct ff_device_addr4 {
/// multipath_list4 ffda_netaddrs;
/// ff_device_versions4 ffda_versions<>;
/// };
///
/// struct ff_device_addr4 {
/// multipath_list4 ffda_netaddrs;
/// ff_device_versions4 ffda_versions<>;
/// };
///
<CODE ENDS>
<代码结束>
The ffda_netaddrs field is used to locate the storage device. It MUST be set by the server to a list holding one or more of the device network addresses.
ffda_NetAddress字段用于定位存储设备。服务器必须将其设置为包含一个或多个设备网络地址的列表。
The ffda_versions array allows the metadata server to present choices as to NFS version, minor version, and coupling strength to the client. The ffdv_version and ffdv_minorversion represent the NFS protocol to be used to access the storage device. This layout specification defines the semantics for ffdv_versions 3 and 4. If ffdv_version equals 3, then the server MUST set ffdv_minorversion to 0 and ffdv_tightly_coupled to false. The client MUST then access the storage device using the NFSv3 protocol [RFC1813]. If ffdv_version equals 4, then the server MUST set ffdv_minorversion to one of the NFSv4 minor version numbers, and the client MUST access the storage device using NFSv4 with the specified minor version.
ffda_versions数组允许元数据服务器提供NFS版本、次要版本以及与客户端的耦合强度的选择。ffdv_版本和ffdv_minorversion表示用于访问存储设备的NFS协议。本布局规范定义了ffdv_版本3和4的语义。如果ffdv_version等于3，则服务器必须将ffdv_minorversion设置为0，并将ffdv_紧密耦合设置为false。然后，客户端必须使用NFSv3协议[RFC1813]访问存储设备。如果ffdv_版本等于4，则服务器必须将ffdv_minorversion设置为NFSv4次要版本号之一，并且客户端必须使用具有指定次要版本的NFSv4访问存储设备。
Note that while the client might determine that it cannot use any of the configured combinations of ffdv_version, ffdv_minorversion, and ffdv_tightly_coupled, when it gets the device list from the metadata server, there is no way to indicate to the metadata server as to which device it is version incompatible. However, if the client waits until it retrieves the layout from the metadata server, it can at that time clearly identify the storage device in question (see Section 5.4).
请注意，虽然客户端可能会确定它无法使用ffdv_版本、ffdv_minorversion和ffdv_紧密耦合的任何配置组合，但当它从元数据服务器获取设备列表时，无法向元数据服务器指示它与哪个设备版本不兼容。但是，如果客户机等待从元数据服务器检索布局，则此时它可以清楚地识别所涉及的存储设备（请参阅第5.4节）。
The ffdv_rsize and ffdv_wsize are used to communicate the maximum rsize and wsize supported by the storage device. As the storage device can have a different rsize or wsize than the metadata server, the ffdv_rsize and ffdv_wsize allow the metadata server to communicate that information on behalf of the storage device.
ffdv_rsize和ffdv_wsize用于传输存储设备支持的最大rsize和wsize。由于存储设备可以具有与元数据服务器不同的rsize或wsize，因此ffdv_rsize和ffdv_wsize允许元数据服务器代表存储设备传输该信息。
ffdv_tightly_coupled informs the client as to whether or not the metadata server is tightly coupled with the storage devices. Note that even if the data protocol is at least NFSv4.1, it may still be the case that there is loose coupling in effect. If ffdv_tightly_coupled is not set, then the client MUST commit writes to the storage devices for the file before sending a LAYOUTCOMMIT to the metadata server. That is, the writes MUST be committed by the client to stable storage via issuing WRITEs with stable_how == FILE_SYNC or by issuing a COMMIT after WRITEs with stable_how != FILE_SYNC (see Section 3.3.7 of [RFC1813]).
ffdv_紧密耦合通知客户端元数据服务器是否与存储设备紧密耦合。注意，即使数据协议至少是NFSv4.1，也可能存在松耦合的情况。如果未设置ffdv_紧密耦合，则客户端必须在向元数据服务器发送LAYOUTCOMMIT之前向文件的存储设备提交写操作。也就是说，客户机必须通过使用stable_how==FILE_SYNC发出写操作，或在使用stable_how！发出写操作后提交，将写操作提交到稳定存储文件同步（见[RFC1813]第3.3.7节）。
The flexible file layout type supports multipathing to multiple storage device addresses. Storage-device-level multipathing is used for bandwidth scaling via trunking and for higher availability of use in the event of a storage device failure. Multipathing allows the client to switch to another storage device address that may be that of another storage device that is exporting the same data stripe unit, without having to contact the metadata server for a new layout.
灵活的文件布局类型支持多路径到多个存储设备地址。存储设备级多路径用于通过中继扩展带宽，以及在存储设备发生故障时提高使用可用性。多路径允许客户端切换到另一个存储设备地址，该地址可能是导出相同数据条带单元的另一个存储设备的地址，而无需联系元数据服务器以获取新布局。
To support storage device multipathing, ffda_netaddrs contains an array of one or more storage device network addresses. This array (data type multipath_list4) represents a list of storage devices (each identified by a network address), with the possibility that some storage device will appear in the list multiple times.
为了支持存储设备多路径，ffda_NetAddress包含一个或多个存储设备网络地址的阵列。此数组（数据类型multipath_list4）表示存储设备的列表（每个存储设备由网络地址标识），某些存储设备可能会多次出现在列表中。
The client is free to use any of the network addresses as a destination to send storage device requests. If some network addresses are less desirable paths to the data than others, then the metadata server SHOULD NOT include those network addresses in ffda_netaddrs. If less desirable network addresses exist to provide failover, the RECOMMENDED method to offer the addresses is to provide
客户端可以自由使用任何网络地址作为发送存储设备请求的目的地。如果某些网络地址与其他地址相比不是理想的数据路径，则元数据服务器不应在ffda_NetAddress中包含这些网络地址。如果存在不太理想的网络地址来提供故障切换，建议提供地址的方法是提供
them in a replacement device-ID-to-device-address mapping or a replacement device ID. When a client finds no response from the storage device using all addresses available in ffda_netaddrs, it SHOULD send a GETDEVICEINFO to attempt to replace the existing device-ID-to-device-address mappings. If the metadata server detects that all network paths represented by ffda_netaddrs are unavailable, the metadata server SHOULD send a CB_NOTIFY_DEVICEID (if the client has indicated it wants device ID notifications for changed device IDs) to change the device-ID-to-device-address mappings to the available addresses. If the device ID itself will be replaced, the metadata server SHOULD recall all layouts with the device ID and thus force the client to get new layouts and device ID mappings via LAYOUTGET and GETDEVICEINFO.
它们位于替换设备ID到设备地址映射或替换设备ID中。当客户端使用ffda_NetAddress中的所有可用地址发现存储设备没有响应时，应发送GETDEVICEINFO以尝试替换现有设备ID到设备地址映射。如果元数据服务器检测到由ffda_NetAddress表示的所有网络路径都不可用，元数据服务器应发送CB_NOTIFY_DEVICEID（如果客户端表示希望设备ID通知更改的设备ID），以将设备ID到设备地址的映射更改为可用地址。如果设备ID本身将被替换，元数据服务器应调用具有设备ID的所有布局，从而强制客户端通过LAYOUTGET和GETDEVICEINFO获取新布局和设备ID映射。
Generally, if two network addresses appear in ffda_netaddrs, they will designate the same storage device. When the storage device is accessed over NFSv4.1 or a higher minor version, the two storage device addresses will support the implementation of client ID or session trunking (the latter is RECOMMENDED) as defined in [RFC5661]. The two storage device addresses will share the same server owner or major ID of the server owner. It is not always necessary for the two storage device addresses to designate the same storage device with trunking being used. For example, the data could be read-only, and the data consist of exact replicas.
通常，如果ffda_NetAddress中出现两个网络地址，则它们将指定相同的存储设备。当通过NFSv4.1或更高的次要版本访问存储设备时，这两个存储设备地址将支持实现[RFC5661]中定义的客户端ID或会话中继（建议使用后者）。这两个存储设备地址将共享相同的服务器所有者或服务器所有者的主ID。并不总是需要两个存储设备地址指定使用中继的同一存储设备。例如，数据可以是只读的，并且数据由精确的副本组成。
The original layouttype4 introduced in [RFC5662] is modified to be:
[RFC5662]中引入的原始layouttype4修改为：
<CODE BEGINS>
<代码开始>
enum layouttype4 {
LAYOUT4_NFSV4_1_FILES = 1,
LAYOUT4_OSD2_OBJECTS = 2,
LAYOUT4_BLOCK_VOLUME = 3,
LAYOUT4_FLEX_FILES = 4
};
enum layouttype4 {
LAYOUT4_NFSV4_1_FILES = 1,
LAYOUT4_OSD2_OBJECTS = 2,
LAYOUT4_BLOCK_VOLUME = 3,
LAYOUT4_FLEX_FILES = 4
};
struct layout_content4 {
layouttype4 loc_type;
opaque loc_body<>;
};
struct layout_content4 {
layouttype4 loc_type;
opaque loc_body<>;
};
struct layout4 {
offset4 lo_offset;
length4 lo_length;
layoutiomode4 lo_iomode;
layout_content4 lo_content;
};
struct layout4 {
offset4 lo_offset;
length4 lo_length;
layoutiomode4 lo_iomode;
layout_content4 lo_content;
};
<CODE ENDS>
<代码结束>
This document defines structures associated with the layouttype4 value LAYOUT4_FLEX_FILES. [RFC5661] specifies the loc_body structure as an XDR type "opaque". The opaque layout is uninterpreted by the generic pNFS client layers but is interpreted by the flexible file layout type implementation. This section defines the structure of this otherwise opaque value, ff_layout4.
本文档定义了与layouttype4值LAYOUT4_FLEX_文件关联的结构。[RFC5661]将loc_主体结构指定为XDR类型“不透明”。一般pNFS客户机层并不理解不透明布局，但它由灵活的文件布局类型实现来解释。本节定义了本不透明值ff_layout4的结构。
<CODE BEGINS>
<代码开始>
/// const FF_FLAGS_NO_LAYOUTCOMMIT = 0x00000001;
/// const FF_FLAGS_NO_IO_THRU_MDS = 0x00000002;
/// const FF_FLAGS_NO_READ_IO = 0x00000004;
/// const FF_FLAGS_WRITE_ONE_MIRROR = 0x00000008;
/// const FF_FLAGS_NO_LAYOUTCOMMIT = 0x00000001;
/// const FF_FLAGS_NO_IO_THRU_MDS = 0x00000002;
/// const FF_FLAGS_NO_READ_IO = 0x00000004;
/// const FF_FLAGS_WRITE_ONE_MIRROR = 0x00000008;
/// typedef uint32_t ff_flags4;
///
/// typedef uint32_t ff_flags4;
///
/// struct ff_data_server4 {
/// deviceid4 ffds_deviceid;
/// uint32_t ffds_efficiency;
/// stateid4 ffds_stateid;
/// nfs_fh4 ffds_fh_vers<>;
/// fattr4_owner ffds_user;
/// fattr4_owner_group ffds_group;
/// };
///
/// struct ff_data_server4 {
/// deviceid4 ffds_deviceid;
/// uint32_t ffds_efficiency;
/// stateid4 ffds_stateid;
/// nfs_fh4 ffds_fh_vers<>;
/// fattr4_owner ffds_user;
/// fattr4_owner_group ffds_group;
/// };
///
/// struct ff_mirror4 {
/// ff_data_server4 ffm_data_servers<>;
/// };
///
/// struct ff_mirror4 {
/// ff_data_server4 ffm_data_servers<>;
/// };
///
/// struct ff_layout4 {
/// length4 ffl_stripe_unit;
/// ff_mirror4 ffl_mirrors<>;
/// ff_flags4 ffl_flags;
/// uint32_t ffl_stats_collect_hint;
/// struct ff_layout4 {
/// length4 ffl_stripe_unit;
/// ff_mirror4 ffl_mirrors<>;
/// ff_flags4 ffl_flags;
/// uint32_t ffl_stats_collect_hint;
/// };
///
/// };
///
<CODE ENDS>
<代码结束>
The ff_layout4 structure specifies a layout in that portion of the data file described in the current layout segment. It is either a single instance or a set of mirrored copies of that portion of the data file. When mirroring is in effect, it protects against loss of data in layout segments.
ff_layout4结构在当前布局段中描述的数据文件部分中指定布局。它是数据文件该部分的单个实例或一组镜像副本。镜像生效时，可防止布局段中的数据丢失。
While not explicitly shown in the above XDR, each layout4 element returned in the logr_layout array of LAYOUTGET4res (see Section 18.43.2 of [RFC5661]) describes a layout segment. Hence, each ff_layout4 also describes a layout segment. It is possible that the file is concatenated from more than one layout segment. Each layout segment MAY represent different striping parameters.
虽然在上述XDR中没有明确显示，但LAYOUTGET4res的logr_布局数组中返回的每个layout4元素（参见[RFC5661]第18.43.2节）描述了一个布局段。因此，每个ff_布局4还描述了一个布局段。文件可能由多个布局段连接而成。每个布局段可以表示不同的条带参数。
The ffl_stripe_unit field is the stripe unit size in use for the current layout segment. The number of stripes is given inside each mirror by the number of elements in ffm_data_servers. If the number of stripes is one, then the value for ffl_stripe_unit MUST default to zero. The only supported mapping scheme is sparse and is detailed in Section 6. Note that there is an assumption here that both the stripe unit size and the number of stripes are the same across all mirrors.
ffl_stripe_unit字段是当前布局段使用的条带单元大小。每个镜像内的条纹数由ffm_数据_服务器中的元素数给出。如果条纹数为一，则ffl_stripe_unit的值必须默认为零。唯一受支持的映射方案是稀疏映射，详见第6节。请注意，此处假设所有镜像的条纹单元大小和条纹数都相同。
The ffl_mirrors field is the array of mirrored storage devices that provide the storage for the current stripe; see Figure 1.
ffl_mirrors字段是为当前条带提供存储的镜像存储设备阵列；参见图1。
The ffl_stats_collect_hint field provides a hint to the client on how often the server wants it to report LAYOUTSTATS for a file. The time is in seconds.
ffl_stats_collect_提示字段向客户机提供提示，说明服务器希望它报告文件的LAYOUTSTATS的频率。时间以秒为单位。
+-----------+
| |
| |
| File |
| |
| |
+-----+-----+
|
+------------+------------+
| |
+----+-----+ +-----+----+
| Mirror 1 | | Mirror 2 |
+----+-----+ +-----+----+
| |
+-----------+ +-----------+
|+-----------+ |+-----------+
||+-----------+ ||+-----------+
+|| Storage | +|| Storage |
+| Devices | +| Devices |
+-----------+ +-----------+
+-----------+
| |
| |
| File |
| |
| |
+-----+-----+
|
+------------+------------+
| |
+----+-----+ +-----+----+
| Mirror 1 | | Mirror 2 |
+----+-----+ +-----+----+
| |
+-----------+ +-----------+
|+-----------+ |+-----------+
||+-----------+ ||+-----------+
+|| Storage | +|| Storage |
+| Devices | +| Devices |
+-----------+ +-----------+
Figure 1
图1
The ffs_mirrors field represents an array of state information for each mirrored copy of the current layout segment. Each element is described by a ff_mirror4 type.
ffs_mirrors字段表示当前布局段的每个镜像副本的状态信息数组。每个元素由ff_mirror4类型描述。
ffds_deviceid provides the deviceid of the storage device holding the data file.
ffds_deviceid提供保存数据文件的存储设备的deviceid。
ffds_fh_vers is an array of filehandles of the data file matching the available NFS versions on the given storage device. There MUST be exactly as many elements in ffds_fh_vers as there are in ffda_versions. Each element of the array corresponds to a particular combination of ffdv_version, ffdv_minorversion, and ffdv_tightly_coupled provided for the device. The array allows for server implementations that have different filehandles for different combinations of version, minor version, and coupling strength. See Section 5.4 for how to handle versioning issues between the client and storage devices.
ffds\u fh\u vers是数据文件的文件句柄数组，与给定存储设备上的可用NFS版本相匹配。ffds版本中的元素数量必须与ffda版本中的元素数量完全相同。阵列的每个元素对应于为设备提供的ffdv_版本、ffdv_minorversion和ffdv_紧密耦合的特定组合。该阵列允许针对不同版本、次要版本和耦合强度的组合使用不同文件句柄的服务器实现。有关如何处理客户端和存储设备之间的版本控制问题，请参见第5.4节。
For tight coupling, ffds_stateid provides the stateid to be used by the client to access the file. For loose coupling and an NFSv4 storage device, the client will have to use an anonymous stateid to perform I/O on the storage device. With no control protocol, the metadata server stateid cannot be used to provide a global stateid model. Thus, the server MUST set the ffds_stateid to be the anonymous stateid.
对于紧密耦合，ffds_stateid提供客户端用于访问文件的stateid。对于松耦合和NFSv4存储设备，客户端必须使用匿名stateid在存储设备上执行I/O。由于没有控制协议，元数据服务器stateid不能用于提供全局stateid模型。因此，服务器必须将ffds_stateid设置为匿名stateid。
This specification of the ffds_stateid restricts both models for NFSv4.x storage protocols:
ffds_stateid的此规范限制了NFSv4.x存储协议的两种型号：
loosely coupled model: the stateid has to be an anonymous stateid
松散耦合模型：stateid必须是匿名stateid
tightly coupled model: the stateid has to be a global stateid
紧密耦合模型：stateid必须是全局stateid
A number of issues stem from a mismatch between the fact that ffds_stateid is defined as a single item while ffds_fh_vers is defined as an array. It is possible for each open file on the storage device to require its own open stateid. Because there are established loosely coupled implementations of the version of the protocol described in this document, such potential issues have not been addressed here. It is possible for future layout types to be defined that address these issues, should it become important to provide multiple stateids for the same underlying file.
许多问题源于ffds_stateid定义为单个项而ffds_fh_vers定义为数组这一事实之间的不匹配。存储设备上的每个打开的文件都可能需要自己的打开状态ID。由于本文档中描述的协议版本已经建立了松散耦合的实现，因此这些潜在问题在这里没有得到解决。如果为同一基础文件提供多个stateID变得很重要，则可以定义解决这些问题的未来布局类型。
For loosely coupled storage devices, ffds_user and ffds_group provide the synthetic user and group to be used in the RPC credentials that the client presents to the storage device to access the data files. For tightly coupled storage devices, the user and group on the storage device will be the same as on the metadata server; that is, if ffdv_tightly_coupled (see Section 4.1) is set, then the client MUST ignore both ffds_user and ffds_group.
对于松散耦合的存储设备，ffds_用户和ffds_组提供了将在RPC凭据中使用的合成用户和组，客户端提供给存储设备以访问数据文件。对于紧密耦合的存储设备，存储设备上的用户和组将与元数据服务器上的用户和组相同；也就是说，如果设置了ffdv_紧耦合（参见第4.1节），则客户端必须同时忽略ffds_用户和ffds_组。
The allowed values for both ffds_user and ffds_group are specified as owner and owner_group, respectively, in Section 5.9 of [RFC5661]. For NFSv3 compatibility, user and group strings that consist of decimal numeric values with no leading zeros can be given a special interpretation by clients and servers that choose to provide such support. The receiver may treat such a user or group string as representing the same user as would be represented by an NFSv3 uid or gid having the corresponding numeric value. Note that if using Kerberos for security, the expectation is that these values will be a name@domain string.
[RFC5661]第5.9节中，ffds_用户和ffds_组的允许值分别指定为所有者和所有者_组。对于NFSv3兼容性，选择提供此类支持的客户端和服务器可以对由十进制数值组成且不带前导零的用户和组字符串进行特殊解释。接收方可以将这样的用户或组字符串视为表示将由具有相应数值的NFSv3 uid或gid表示的相同用户。请注意，如果使用Kerberos进行安全性保护，则期望这些值是name@domain一串
ffds_efficiency describes the metadata server's evaluation as to the effectiveness of each mirror. Note that this is per layout and not per device as the metric may change due to perceived load, availability to the metadata server, etc. Higher values denote higher perceived utility. The way the client can select the best mirror to access is discussed in Section 8.1.
ffds_效率描述元数据服务器对每个镜像的有效性的评估。请注意，这是每个布局，而不是每个设备，因为度量可能会因感知负载、元数据服务器的可用性等而改变。值越高表示感知效用越高。第8.1节讨论了客户端选择要访问的最佳镜像的方式。
ffl_flags is a bitmap that allows the metadata server to inform the client of particular conditions that may result from more or less tight coupling of the storage devices.
ffl_标志是一种位图，允许元数据服务器通知客户端存储设备或多或少紧密耦合可能导致的特定情况。
FF_FLAGS_NO_LAYOUTCOMMIT: can be set to indicate that the client is not required to send LAYOUTCOMMIT to the metadata server.
FF_FLAGS_NO_LAYOUTCOMMIT：可以设置为指示客户端不需要向元数据服务器发送LAYOUTCOMMIT。
FF_FLAGS_NO_IO_THRU_MDS: can be set to indicate that the client should not send I/O operations to the metadata server. That is, even if the client could determine that there was a network disconnect to a storage device, the client should not try to proxy the I/O through the metadata server.
FF_FLAGS_NO_IO_THRU_MDS:可设置为指示客户端不应向元数据服务器发送I/O操作。也就是说，即使客户端可以确定存在与存储设备的网络断开连接，客户端也不应尝试通过元数据服务器代理I/O。
FF_FLAGS_NO_READ_IO: can be set to indicate that the client should not send READ requests with the layouts of iomode LAYOUTIOMODE4_RW. Instead, it should request a layout of iomode LAYOUTIOMODE4_READ from the metadata server.
FF_FLAGS_NO_READ_IO:可设置为指示客户端不应发送iomode LAYOUTIOMODE4_RW布局的读取请求。相反，它应该请求从元数据服务器读取iomode LAYOUTIOMODE4_的布局。
FF_FLAGS_WRITE_ONE_MIRROR: can be set to indicate that the client only needs to update one of the mirrors (see Section 8.2).
FF_FLAGS_WRITE_ONE_MIRROR：可以设置为指示客户端只需要更新其中一个镜像（请参阅第8.2节）。
[RFC5661] provides little guidance as to how the client is to proceed with a LAYOUTGET that returns an error of either NFS4ERR_LAYOUTTRYLATER, NFS4ERR_LAYOUTUNAVAILABLE, and NFS4ERR_DELAY. Within the context of this document:
[RFC5661]对客户端如何继续执行LAYOUTGET提供了很少的指导，该LAYOUTGET返回NFS4ERR_LayouttyLater、NFS4ERR_LayoutAvailable和NFS4ERR_DELAY的错误。在本文件中：
NFS4ERR_LAYOUTUNAVAILABLE: there is no layout available and the I/O is to go to the metadata server. Note that it is possible to have had a layout before a recall and not after.
NFS4ERR_LAYOUTUNAVAILABLE：没有可用的布局，I/O将转到元数据服务器。请注意，可能在召回之前而不是之后有一个布局。
NFS4ERR_LAYOUTTRYLATER: there is some issue preventing the layout from being granted. If the client already has an appropriate layout, it should continue with I/O to the storage devices.
NFS4ERR_LAYOUTTRYLATER：有一些问题阻止授予布局。如果客户机已具有适当的布局，则应继续对存储设备进行I/O。
NFS4ERR_DELAY: there is some issue preventing the layout from being granted. If the client already has an appropriate layout, it should not continue with I/O to the storage devices.
NFS4ERR_延迟：存在一些问题，无法授予布局。如果客户端已具有适当的布局，则不应继续对存储设备进行I/O。
Even if the metadata server provides the FF_FLAGS_NO_IO_THRU_MDS flag, the client can still perform I/O to the metadata server. The flag functions as a hint. The flag indicates to the client that the metadata server prefers to separate the metadata I/O from the data I/ O, most likely for performance reasons.
即使元数据服务器提供FF_标志\u否\u IO_至\u MDS标志，客户端仍可以对元数据服务器执行I/O。该标志用作提示。该标志向客户端指示元数据服务器倾向于将元数据I/O与数据I/O分开，很可能是出于性能原因。
The flexible file layout does not use lou_body inside the loca_layoutupdate argument to LAYOUTCOMMIT. If lou_type is LAYOUT4_FLEX_FILES, the lou_body field MUST have a zero length (see Section 18.42.1 of [RFC5661]).
灵活的文件布局不会在loca_layoutupdate参数中使用lou_body来执行LAYOUTCOMMIT。如果lou_类型为LAYOUT4_FLEX_文件，则lou_正文字段的长度必须为零（请参见[RFC5661]第18.42.1节）。
In [RFC5661], the file layout type is defined such that the relationship between multipathing and filehandles can result in either 0, 1, or N filehandles (see Section 13.3). Some rationales for this are clustered servers that share the same filehandle or allow for multiple read-only copies of the file on the same storage device. In the flexible file layout type, while there is an array of filehandles, they are independent of the multipathing being used. If the metadata server wants to provide multiple read-only copies of the same file on the same storage device, then it should provide multiple mirrored instances, each with a different ff_device_addr4. The client can then determine that, since the each of the ffds_fh_vers are different, there are multiple copies of the file for the current layout segment available.
在[RFC5661]中，文件布局类型的定义使得多路径和文件句柄之间的关系可以产生0、1或N个文件句柄（参见第13.3节）。这方面的一些基本原理是群集服务器共享相同的文件句柄，或允许在同一存储设备上创建文件的多个只读副本。在flexible file layout类型中，虽然有一个文件句柄数组，但它们独立于正在使用的多路径。如果元数据服务器希望在同一存储设备上提供同一文件的多个只读副本，那么它应该提供多个镜像实例，每个实例都具有不同的ff_device_addr4。然后，客户机可以确定，由于每个ffds\u fh\u版本不同，因此当前布局段有多个文件副本可用。
When the metadata server provides the ffda_versions array in the ff_device_addr4 (see Section 4.1), the client is able to determine whether or not it can access a storage device with any of the supplied combinations of ffdv_version, ffdv_minorversion, and ffdv_tightly_coupled. However, due to the limitations of reporting errors in GETDEVICEINFO (see Section 18.40 in [RFC5661]), the client is not able to specify which specific device it cannot communicate with over one of the provided ffdv_version and ffdv_minorversion combinations. Using ff_ioerr4 (see Section 9.1.1) inside either the LAYOUTRETURN (see Section 18.44 of [RFC5661]) or the LAYOUTERROR (see Section 15.6 of [RFC7862] and Section 10 of this document), the client can isolate the problematic storage device.
当元数据服务器在ff_设备_addr4（参见第4.1节）中提供ffda_版本阵列时，客户机能够确定它是否可以使用所提供的ffdv_版本、ffdv_minorversion和ffdv_紧密耦合的任意组合来访问存储设备。但是，由于GETDEVICEINFO中报告错误的限制（请参见[RFC5661]中的第18.40节），客户端无法指定无法通过提供的ffdv_版本和ffdv_minorversion组合之一与哪个特定设备通信。使用LAYOUTRETURN（参见[RFC5661]第18.44节）或LAYOUTERROR（参见[RFC7862]第15.6节和本文档第10节）内部的ff_ioerr4（参见第9.1.1节），客户机可以隔离有问题的存储设备。
The error code to return for LAYOUTRETURN and/or LAYOUTERROR is NFS4ERR_MINOR_VERS_MISMATCH. It does not matter whether the mismatch is a major version (e.g., client can use NFSv3 but not NFSv4) or minor version (e.g., client can use NFSv4.1 but not NFSv4.2), the error indicates that for all the supplied combinations for ffdv_version and ffdv_minorversion, the client cannot communicate with the storage device. The client can retry the GETDEVICEINFO to see if the metadata server can provide a different combination, or it can fall back to doing the I/O through the metadata server.
要为LAYOUTRETURN和/或LAYOUTERROR返回的错误代码是NFS4ERR_MINOR_overs_不匹配。无论不匹配是主版本（例如，客户端可以使用NFSv3，但不使用NFSv4）还是次版本（例如，客户端可以使用NFSv4.1，但不使用NFSv4.2），错误都表明，对于提供的ffdv_版本和ffdv_minorversion的所有组合，客户端无法与存储设备通信。客户端可以重试GETDEVICEINFO，以查看元数据服务器是否可以提供不同的组合，或者它可以退回到通过元数据服务器执行I/O。
While other layout types support both dense and sparse mapping of logical offsets to physical offsets within a file (see, for example, Section 13.4 of [RFC5661]), the flexible file layout type only supports a sparse mapping.
虽然其他布局类型支持文件内逻辑偏移到物理偏移的密集和稀疏映射（例如，请参见[RFC5661]第13.4节），但灵活的文件布局类型仅支持稀疏映射。
With sparse mappings, the logical offset within a file (L) is also the physical offset on the storage device. As detailed in Section 13.4.4 of [RFC5661], this results in holes across each storage device that does not contain the current stripe index.
对于稀疏映射，文件（L）中的逻辑偏移量也是存储设备上的物理偏移量。如[RFC5661]第13.4.4节所述，这会导致每个存储设备上出现不包含当前条带索引的孔。
L: logical offset within the file
L：文件中的逻辑偏移量
W: stripe width W = number of elements in ffm_data_servers
W：条带宽度W=ffm_数据_服务器中的元素数
S: number of bytes in a stripe S = W * ffl_stripe_unit
S：条带中的字节数S=W*ffl\u条带单元
N: stripe number N = L / S
N：条纹编号N=L/S
The pNFS client may encounter errors when directly accessing the storage devices. However, it is the responsibility of the metadata server to recover from the I/O errors. When the LAYOUT4_FLEX_FILES layout type is used, the client MUST report the I/O errors to the server at LAYOUTRETURN time using the ff_ioerr4 structure (see Section 9.1.1).
pNFS客户端在直接访问存储设备时可能会遇到错误。但是，元数据服务器负责从I/O错误中恢复。当使用LAYOUT4_FLEX_文件布局类型时，客户端必须在LAYOUTRETURN时使用ff_ioerr4结构向服务器报告I/O错误（参见第9.1.1节）。
The metadata server analyzes the error and determines the required recovery operations such as recovering media failures or reconstructing missing data files.
元数据服务器分析错误并确定所需的恢复操作，如恢复媒体故障或重建丢失的数据文件。
The metadata server MUST recall any outstanding layouts to allow it exclusive write access to the stripes being recovered and to prevent other clients from hitting the same error condition. In these cases, the server MUST complete recovery before handing out any new layouts to the affected byte ranges.
元数据服务器必须调用任何未完成的布局，以允许其对正在恢复的条带进行独占写入访问，并防止其他客户端遇到相同的错误情况。在这些情况下，服务器必须在向受影响的字节范围分发任何新布局之前完成恢复。
Although the client implementation has the option to propagate a corresponding error to the application that initiated the I/O operation and drop any unwritten data, the client should attempt to retry the original I/O operation by either requesting a new layout or sending the I/O via regular NFSv4.1+ READ or WRITE operations to the metadata server. The client SHOULD attempt to retrieve a new layout
尽管客户端实现可以选择将相应的错误传播到启动I/O操作的应用程序，并删除任何未写入的数据，客户端应通过请求新布局或通过常规NFSv4.1+读取或写入操作向元数据服务器发送I/O，尝试重试原始I/O操作。客户端应尝试检索新布局
and retry the I/O operation using the storage device first and only retry the I/O operation via the metadata server if the error persists.
并首先使用存储设备重试I/O操作，如果错误仍然存在，则仅通过元数据服务器重试I/O操作。
The flexible file layout type has a simple model in place for the mirroring of the file data constrained by a layout segment. There is no assumption that each copy of the mirror is stored identically on the storage devices. For example, one device might employ compression or deduplication on the data. However, the over-the-wire transfer of the file contents MUST appear identical. Note, this is a constraint of the selected XDR representation in which each mirrored copy of the layout segment has the same striping pattern (see Figure 1).
灵活的文件布局类型有一个简单的模型，用于镜像受布局段约束的文件数据。不假设镜像的每个副本都以相同的方式存储在存储设备上。例如，一台设备可能会对数据进行压缩或重复数据消除。但是，文件内容的在线传输必须看起来相同。注意，这是所选XDR表示的一个约束，其中布局段的每个镜像副本都具有相同的条带模式（请参见图1）。
The metadata server is responsible for determining the number of mirrored copies and the location of each mirror. While the client may provide a hint to how many copies it wants (see Section 12), the metadata server can ignore that hint; in any event, the client has no means to dictate either the storage device (which also means the coupling and/or protocol levels to access the layout segments) or the location of said storage device.
元数据服务器负责确定镜像副本的数量和每个镜像的位置。虽然客户机可能会提供一个关于它需要多少拷贝的提示（参见第12节），但元数据服务器可以忽略该提示；在任何情况下，客户机都无法指定存储设备（这也意味着访问布局段的耦合和/或协议级别）或所述存储设备的位置。
The updating of mirrored layout segments is done via client-side mirroring. With this approach, the client is responsible for making sure modifications are made on all copies of the layout segments it is informed of via the layout. If a layout segment is being resilvered to a storage device, that mirrored copy will not be in the layout. Thus, the metadata server MUST update that copy until the client is presented it in a layout. If the FF_FLAGS_WRITE_ONE_MIRROR is set in ffl_flags, the client need only update one of the mirrors (see Section 8.2). If the client is writing to the layout segments via the metadata server, then the metadata server MUST update all copies of the mirror. As seen in Section 8.3, during the resilvering, the layout is recalled, and the client has to make modifications via the metadata server.
镜像布局段的更新通过客户端镜像完成。通过这种方法，客户负责确保通过布局通知的布局段的所有副本都进行了修改。如果布局段被重新调整到存储设备，则镜像副本将不在布局中。因此，元数据服务器必须更新该副本，直到客户端将其呈现在布局中。如果在ffl_标志中设置了FF_标志、写入_一个_镜像，则客户端只需更新其中一个镜像（请参阅第8.2节）。如果客户端正在通过元数据服务器写入布局段，则元数据服务器必须更新镜像的所有副本。如第8.3节所示，在重定大小期间，将调用布局，客户端必须通过元数据服务器进行修改。
When the metadata server grants a layout to a client, it MAY let the client know how fast it expects each mirror to be once the request arrives at the storage devices via the ffds_efficiency member. While the algorithms to calculate that value are left to the metadata server implementations, factors that could contribute to that calculation include speed of the storage device, physical memory available to the device, operating system version, current load, etc.
当元数据服务器向客户机授予布局时，它可以让客户机知道，一旦请求通过ffds_成员到达存储设备，它期望每个镜像的速度有多快。虽然计算该值的算法留给元数据服务器实现，但可能导致该计算的因素包括存储设备的速度、设备可用的物理内存、操作系统版本、当前负载等。
However, what should not be involved in that calculation is a perceived network distance between the client and the storage device. The client is better situated for making that determination based on past interaction with the storage device over the different available network interfaces between the two; that is, the metadata server might not know about a transient outage between the client and storage device because it has no presence on the given subnet.
但是，该计算中不应涉及的是客户机和存储设备之间的感知网络距离。客户机更适合基于过去通过存储设备之间的不同可用网络接口与存储设备的交互来进行确定；也就是说，元数据服务器可能不知道客户端和存储设备之间的暂时中断，因为它在给定子网中不存在。
As such, it is the client that decides which mirror to access for reading the file. The requirements for writing to mirrored layout segments are presented below.
因此，客户端决定访问哪个镜像以读取文件。写入镜像布局段的要求如下所示。
If the FF_FLAGS_WRITE_ONE_MIRROR flag in ffl_flags is set, the client only needs to update one of the copies of the layout segment. For this case, the storage device MUST ensure that all copies of the mirror are updated when any one of the mirrors is updated. If the storage device gets an error when updating one of the mirrors, then it MUST inform the client that the original WRITE had an error. The client then MUST inform the metadata server (see Section 8.2.3). The client's responsibility with respect to COMMIT is explained in Section 8.2.4. The client may choose any one of the mirrors and may use ffds_efficiency as described in Section 8.1 when making this choice.
如果设置了ffl_标志中的FF_标志\u写入\u一个\u镜像标志，则客户端只需更新布局段的一个副本。在这种情况下，存储设备必须确保在更新任何一个镜像时更新镜像的所有副本。如果存储设备在更新其中一个镜像时出错，则必须通知客户端原始写入有错误。然后，客户端必须通知元数据服务器（参见第8.2.3节）。第8.2.4节解释了客户的承诺责任。客户可选择任何一个镜像，并可在做出此选择时使用第8.1节中所述的ffds_效率。
If the FF_FLAGS_WRITE_ONE_MIRROR flag in ffl_flags is not set, the client is responsible for updating all mirrored copies of the layout segments that it is given in the layout. A single failed update is sufficient to fail the entire operation. If all but one copy is updated successfully and the last one provides an error, then the client needs to inform the metadata server about the error. The client can use either LAYOUTRETURN or LAYOUTERROR to inform the metadata server that the update failed to that storage device. If the client is updating the mirrors serially, then it SHOULD stop at the first error encountered and report that to the metadata server. If the client is updating the mirrors in parallel, then it SHOULD wait until all storage devices respond so that it can report all errors encountered during the update.
如果未设置ffl_标志中的FF_标志\u写入\u一个\u镜像标志，则客户端负责更新布局中给定的布局段的所有镜像副本。一次失败的更新足以使整个操作失败。如果成功更新了除一个副本以外的所有副本，并且最后一个副本提供了错误，则客户端需要将错误通知元数据服务器。客户端可以使用LAYOUTRETURN或LAYOUTERROR通知元数据服务器该存储设备的更新失败。如果客户端正在串行更新镜像，那么它应该在遇到第一个错误时停止，并向元数据服务器报告该错误。如果客户端正在并行更新镜像，则应等待所有存储设备响应，以便报告更新过程中遇到的所有错误。
When the client reports a write error to the metadata server, the metadata server is responsible for determining if it wants to remove the errant mirror from the layout, if the mirror has recovered from some transient error, etc. When the client tries to get a new layout, the metadata server informs it of the decision by the contents of the layout. The client MUST NOT assume that the contents of the previous layout will match those of the new one. If it has updates that were not committed to all mirrors, then it MUST resend those updates to all mirrors.
当客户端向元数据服务器报告写入错误时，元数据服务器负责确定是否要从布局中删除错误镜像，镜像是否已从某个暂时错误中恢复，等等。当客户端尝试获取新布局时，元数据服务器通过布局的内容通知它该决定。客户机不得假设先前布局的内容与新布局的内容相匹配。如果它有未提交到所有镜像的更新，则必须将这些更新重新发送到所有镜像。
There is no provision in the protocol for the metadata server to directly determine that the client has or has not recovered from an error. For example, if a storage device was network partitioned from the client and the client reported the error to the metadata server, then the network partition would be repaired, and all of the copies would be successfully updated. There is no mechanism for the client to report that fact, and the metadata server is forced to repair the file across the mirror.
协议中没有规定元数据服务器可以直接确定客户端是否已从错误中恢复。例如，如果存储设备是从客户端进行网络分区的，并且客户端向元数据服务器报告了错误，则网络分区将被修复，并且所有副本都将成功更新。客户端没有报告该事实的机制，元数据服务器被迫跨镜像修复文件。
If the client supports NFSv4.2, it can use LAYOUTERROR and LAYOUTRETURN to provide hints to the metadata server about the recovery efforts. A LAYOUTERROR on a file is for a non-fatal error. A subsequent LAYOUTRETURN without a ff_ioerr4 indicates that the client successfully replayed the I/O to all mirrors. Any LAYOUTRETURN with a ff_ioerr4 is an error that the metadata server needs to repair. The client MUST be prepared for the LAYOUTERROR to trigger a CB_LAYOUTRECALL if the metadata server determines it needs to start repairing the file.
如果客户端支持NFSv4.2，则可以使用LAYOUTERROR和LAYOUTRETURN向元数据服务器提供有关恢复工作的提示。文件上的LAYOUTERROR用于非致命错误。没有ff_ioerr4的后续LAYOUTRETURN表示客户端成功地将I/O重播到所有镜像。任何带有ff_ioerr4的LAYOUTRETURN都是元数据服务器需要修复的错误。如果元数据服务器确定需要开始修复文件，则客户端必须准备好让LAYOUTERROR触发CB_LAYOUTRECALL。
When stable writes are done to the metadata server or to a single replica (if allowed by the use of FF_FLAGS_WRITE_ONE_MIRROR), it is the responsibility of the receiving node to propagate the written data stably, before replying to the client.
当对元数据服务器或单个副本进行稳定写入时（如果通过使用FF_标志_WRITE_ONE_MIRROR允许），接收节点有责任在响应客户端之前稳定地传播写入的数据。
In the corresponding cases in which unstable writes are done, the receiving node does not have any such obligation, although it may choose to asynchronously propagate the updates. However, once a COMMIT is replied to, all replicas must reflect the writes that have been done, and this data must have been committed to stable storage on all replicas.
在执行不稳定写入的相应情况下，接收节点没有任何此类义务，尽管它可以选择异步传播更新。但是，一旦回复提交，所有副本都必须反映已完成的写入操作，并且这些数据必须已提交到所有副本上的稳定存储中。
In order to avoid situations in which stale data is read from replicas to which writes have not been propagated:
为了避免从写入尚未传播到的副本读取过时数据的情况：
o A client that has outstanding unstable writes made to single node (metadata server or storage device) MUST do all reads from that same node.
o 对单个节点（元数据服务器或存储设备）进行了未完成的不稳定写入的客户端必须从该节点执行所有读取。
o When writes are flushed to the server (for example, to implement close-to-open semantics), a COMMIT must be done by the client to ensure that up-to-date written data will be available irrespective of the particular replica read.
o 当写入刷新到服务器时（例如，为了实现从关闭到打开的语义），客户机必须进行提交，以确保无论读取何种特定副本，都可以使用最新的写入数据。
The metadata server may elect to create a new mirror of the layout segments at any time. This might be to resilver a copy on a storage device that was down for servicing, to provide a copy of the layout segments on storage with different storage performance characteristics, etc. As the client will not be aware of the new mirror and the metadata server will not be aware of updates that the client is making to the layout segments, the metadata server MUST recall the writable layout segment(s) that it is resilvering. If the client issues a LAYOUTGET for a writable layout segment that is in the process of being resilvered, then the metadata server can deny that request with an NFS4ERR_LAYOUTUNAVAILABLE. The client would then have to perform the I/O through the metadata server.
元数据服务器可以随时选择创建布局段的新镜像。这可能是在停止服务的存储设备上调整副本的大小，以提供具有不同存储性能特征的存储上布局段的副本等。因为客户端不会知道新镜像，元数据服务器也不会知道客户端正在对布局段进行的更新，元数据服务器必须调用其正在调整大小的可写布局段。如果客户端为正在调整大小的可写布局段发出LAYOUTGET，则元数据服务器可以使用NFS4ERR_LAYOUTUNAVAILABLE拒绝该请求。然后，客户机必须通过元数据服务器执行I/O。
layoutreturn_file4 is used in the LAYOUTRETURN operation to convey layout-type-specific information to the server. It is defined in Section 18.44.1 of [RFC5661] as follows:
layoutreturn_文件4在layoutreturn操作中用于将布局类型特定的信息传送到服务器。[RFC5661]第18.44.1节对其定义如下：
<CODE BEGINS>
<代码开始>
/* Constants used for LAYOUTRETURN and CB_LAYOUTRECALL */
const LAYOUT4_RET_REC_FILE = 1;
const LAYOUT4_RET_REC_FSID = 2;
const LAYOUT4_RET_REC_ALL = 3;
/* Constants used for LAYOUTRETURN and CB_LAYOUTRECALL */
const LAYOUT4_RET_REC_FILE = 1;
const LAYOUT4_RET_REC_FSID = 2;
const LAYOUT4_RET_REC_ALL = 3;
enum layoutreturn_type4 {
LAYOUTRETURN4_FILE = LAYOUT4_RET_REC_FILE,
LAYOUTRETURN4_FSID = LAYOUT4_RET_REC_FSID,
LAYOUTRETURN4_ALL = LAYOUT4_RET_REC_ALL
};
enum layoutreturn_type4 {
LAYOUTRETURN4_FILE = LAYOUT4_RET_REC_FILE,
LAYOUTRETURN4_FSID = LAYOUT4_RET_REC_FSID,
LAYOUTRETURN4_ALL = LAYOUT4_RET_REC_ALL
};
struct layoutreturn_file4 {
offset4 lrf_offset;
struct layoutreturn_file4 {
offset4 lrf_offset;
length4 lrf_length;
stateid4 lrf_stateid;
/* layouttype4 specific data */
opaque lrf_body<>;
};
length4 lrf_length;
stateid4 lrf_stateid;
/* layouttype4 specific data */
opaque lrf_body<>;
};
union layoutreturn4 switch(layoutreturn_type4 lr_returntype) {
case LAYOUTRETURN4_FILE:
layoutreturn_file4 lr_layout;
default:
void;
};
union layoutreturn4 switch(layoutreturn_type4 lr_returntype) {
case LAYOUTRETURN4_FILE:
layoutreturn_file4 lr_layout;
default:
void;
};
struct LAYOUTRETURN4args {
/* CURRENT_FH: file */
bool lora_reclaim;
layouttype4 lora_layout_type;
layoutiomode4 lora_iomode;
layoutreturn4 lora_layoutreturn;
};
struct LAYOUTRETURN4args {
/* CURRENT_FH: file */
bool lora_reclaim;
layouttype4 lora_layout_type;
layoutiomode4 lora_iomode;
layoutreturn4 lora_layoutreturn;
};
<CODE ENDS>
<代码结束>
If the lora_layout_type layout type is LAYOUT4_FLEX_FILES and the lr_returntype is LAYOUTRETURN4_FILE, then the lrf_body opaque value is defined by ff_layoutreturn4 (see Section 9.3). This allows the client to report I/O error information or layout usage statistics back to the metadata server as defined below. Note that while the data structures are built on concepts introduced in NFSv4.2, the effective discriminated union (lora_layout_type combined with ff_layoutreturn4) allows for an NFSv4.1 metadata server to utilize the data.
如果lora_布局类型布局类型为LAYOUT4_FLEX_文件，lr_返回类型为LAYOUTRETURN4_文件，则lrf_主体不透明值由ff_LAYOUTRETURN4定义（参见第9.3节）。这允许客户端向元数据服务器报告I/O错误信息或布局使用统计信息，如下所述。请注意，虽然数据结构是基于NFSv4.2中引入的概念构建的，但有效的区分联合（lora_layout_类型与ff_layoutreturn4相结合）允许NFSv4.1元数据服务器利用数据。
<CODE BEGINS>
<代码开始>
/// struct ff_ioerr4 {
/// offset4 ffie_offset;
/// length4 ffie_length;
/// stateid4 ffie_stateid;
/// device_error4 ffie_errors<>;
/// };
///
/// struct ff_ioerr4 {
/// offset4 ffie_offset;
/// length4 ffie_length;
/// stateid4 ffie_stateid;
/// device_error4 ffie_errors<>;
/// };
///
<CODE ENDS>
<代码结束>
Recall that [RFC7862] defines device_error4 as:
回想一下，[RFC7862]将设备错误4定义为：
<CODE BEGINS>
<代码开始>
struct device_error4 {
deviceid4 de_deviceid;
nfsstat4 de_status;
nfs_opnum4 de_opnum;
};
struct device_error4 {
deviceid4 de_deviceid;
nfsstat4 de_status;
nfs_opnum4 de_opnum;
};
<CODE ENDS>
<代码结束>
The ff_ioerr4 structure is used to return error indications for data files that generated errors during data transfers. These are hints to the metadata server that there are problems with that file. For each error, ffie_errors.de_deviceid, ffie_offset, and ffie_length represent the storage device and byte range within the file in which the error occurred; ffie_errors represents the operation and type of error. The use of device_error4 is described in Section 15.6 of [RFC7862].
ff_ioerr4结构用于为在数据传输期间生成错误的数据文件返回错误指示。这些提示提示元数据服务器该文件存在问题。对于每个错误，ffie_errors.de_deviceid、ffie_offset和ffie_length表示发生错误的文件中的存储设备和字节范围；ffie_错误表示错误的操作和类型。[RFC7862]第15.6节描述了设备4的使用。
Even though the storage device might be accessed via NFSv3 and reports back NFSv3 errors to the client, the client is responsible for mapping these to appropriate NFSv4 status codes as de_status. Likewise, the NFSv3 operations need to be mapped to equivalent NFSv4 operations.
即使存储设备可能通过NFSv3访问并向客户端报告NFSv3错误，客户端仍负责将这些错误映射到适当的NFSv4状态代码，作为de_状态。同样，NFSv3操作需要映射到等效的NFSv4操作。
<CODE BEGINS>
<代码开始>
/// struct ff_io_latency4 {
/// uint64_t ffil_ops_requested;
/// uint64_t ffil_bytes_requested;
/// uint64_t ffil_ops_completed;
/// uint64_t ffil_bytes_completed;
/// uint64_t ffil_bytes_not_delivered;
/// nfstime4 ffil_total_busy_time;
/// nfstime4 ffil_aggregate_completion_time;
/// };
///
/// struct ff_io_latency4 {
/// uint64_t ffil_ops_requested;
/// uint64_t ffil_bytes_requested;
/// uint64_t ffil_ops_completed;
/// uint64_t ffil_bytes_completed;
/// uint64_t ffil_bytes_not_delivered;
/// nfstime4 ffil_total_busy_time;
/// nfstime4 ffil_aggregate_completion_time;
/// };
///
<CODE ENDS>
<代码结束>
Both operation counts and bytes transferred are kept in the ff_io_latency4. As seen in ff_layoutupdate4 (see Section 9.2.2), READ and WRITE operations are aggregated separately. READ operations are used for the ff_io_latency4 ffl_read. Both WRITE and COMMIT operations are used for the ff_io_latency4 ffl_write. "Requested" counters track what the client is attempting to do, and "completed" counters track what was done. There is no requirement that the client only report completed results that have matching requested results from the reported period.
操作计数和传输的字节都保存在ff_io_latency4中。如ff_layoutupdate4（见第9.2.2节）所示，读写操作分别聚合。读取操作用于ff_io_latency4 ffl_读取。写入和提交操作都用于ff_io_latency4 ffl_写入。“请求”计数器跟踪客户端正在尝试执行的操作，“完成”计数器跟踪已执行的操作。不要求客户仅报告具有与报告期间请求的结果相匹配的已完成结果。
ffil_bytes_not_delivered is used to track the aggregate number of bytes requested but not fulfilled due to error conditions. ffil_total_busy_time is the aggregate time spent with outstanding RPC calls. ffil_aggregate_completion_time is the sum of all round-trip times for completed RPC calls.
ffil_bytes_not_delivered用于跟踪请求但由于错误条件而未满足的字节总数。ffil_total_busy_time是未完成RPC调用花费的总时间。ffil_aggregate_completion_time是已完成RPC调用的所有往返时间之和。
In Section 3.3.1 of [RFC5661], the nfstime4 is defined as the number of seconds and nanoseconds since midnight or zero hour January 1, 1970 Coordinated Universal Time (UTC). The use of nfstime4 in ff_io_latency4 is to store time since the start of the first I/O from the client after receiving the layout. In other words, these are to be decoded as duration and not as a date and time.
在[RFC5661]的第3.3.1节中，nfstime4被定义为自1970年1月1日协调世界时（UTC）午夜或零时起的秒数和纳秒数。在ff_io_latency4中使用nfstime4是为了存储自接收到布局后从客户端开始第一次I/O以来的时间。换句话说，这些将被解码为持续时间，而不是日期和时间。
Note that LAYOUTSTATS are cumulative, i.e., not reset each time the operation is sent. If two LAYOUTSTATS operations for the same file and layout stateid originate from the same NFS client and are processed at the same time by the metadata server, then the one containing the larger values contains the most recent time series data.
请注意，LAYOUTSTATS是累积的，即，不会在每次发送操作时重置。如果针对同一文件和布局stateid的两个LAYOUTSTATS操作源自同一NFS客户端，并且由元数据服务器同时处理，则包含较大值的操作包含最新的时间序列数据。
<CODE BEGINS>
<代码开始>
/// struct ff_layoutupdate4 {
/// netaddr4 ffl_addr;
/// nfs_fh4 ffl_fhandle;
/// ff_io_latency4 ffl_read;
/// ff_io_latency4 ffl_write;
/// nfstime4 ffl_duration;
/// bool ffl_local;
/// };
///
/// struct ff_layoutupdate4 {
/// netaddr4 ffl_addr;
/// nfs_fh4 ffl_fhandle;
/// ff_io_latency4 ffl_read;
/// ff_io_latency4 ffl_write;
/// nfstime4 ffl_duration;
/// bool ffl_local;
/// };
///
<CODE ENDS>
<代码结束>
ffl_addr differentiates which network address the client is connected to on the storage device. In the case of multipathing, ffl_fhandle indicates which read-only copy was selected. ffl_read and ffl_write convey the latencies for both READ and WRITE operations, respectively. ffl_duration is used to indicate the time period over which the statistics were collected. If true, ffl_local indicates that the I/O was serviced by the client's cache. This flag allows the client to inform the metadata server about "hot" access to a file it would not normally be allowed to report on.
ffl_addr区分客户端在存储设备上连接到的网络地址。在多路径的情况下，ffl_fhandle指示选择了哪个只读副本。ffl_读取和ffl_写入分别传递读取和写入操作的延迟。ffl_duration用于表示收集统计数据的时间段。如果为true，则ffl_local表示该I/O由客户端缓存提供服务。此标志允许客户端通知元数据服务器对通常不允许报告的文件的“热”访问。
<CODE BEGINS>
<代码开始>
/// struct ff_iostats4 {
/// offset4 ffis_offset;
/// length4 ffis_length;
/// stateid4 ffis_stateid;
/// io_info4 ffis_read;
/// io_info4 ffis_write;
/// deviceid4 ffis_deviceid;
/// ff_layoutupdate4 ffis_layoutupdate;
/// };
///
/// struct ff_iostats4 {
/// offset4 ffis_offset;
/// length4 ffis_length;
/// stateid4 ffis_stateid;
/// io_info4 ffis_read;
/// io_info4 ffis_write;
/// deviceid4 ffis_deviceid;
/// ff_layoutupdate4 ffis_layoutupdate;
/// };
///
<CODE ENDS>
<代码结束>
[RFC7862] defines io_info4 as:
[RFC7862]将io_info4定义为：
<CODE BEGINS>
<代码开始>
struct io_info4 {
uint64_t ii_count;
uint64_t ii_bytes;
};
struct io_info4 {
uint64_t ii_count;
uint64_t ii_bytes;
};
<CODE ENDS>
<代码结束>
With pNFS, data transfers are performed directly between the pNFS client and the storage devices. Therefore, the metadata server has no direct knowledge of the I/O operations being done and thus cannot create on its own statistical information about client I/O to optimize the data storage location. ff_iostats4 MAY be used by the client to report I/O statistics back to the metadata server upon returning the layout.
使用pNFS，数据传输直接在pNFS客户端和存储设备之间执行。因此，元数据服务器无法直接了解正在执行的I/O操作，因此无法自行创建有关客户端I/O的统计信息来优化数据存储位置。客户端可以使用ff_iostats4在返回布局时向元数据服务器报告I/O统计信息。
Since it is not feasible for the client to report every I/O that used the layout, the client MAY identify "hot" byte ranges for which to report I/O statistics. The definition and/or configuration mechanism of what is considered "hot" and the size of the reported byte range are out of the scope of this document. For client implementation, providing reasonable default values and an optional run-time management interface to control these parameters is suggested. For example, a client can define the default byte-range resolution to be 1 MB in size and the thresholds for reporting to be 1 MB/second or 10 I/O operations per second.
由于客户机无法报告使用布局的每个I/O，因此客户机可能会识别要报告I/O统计信息的“热”字节范围。被认为是“热”的内容的定义和/或配置机制以及报告字节范围的大小超出了本文档的范围。对于客户端实现，建议提供合理的默认值和可选的运行时管理界面来控制这些参数。例如，客户机可以将默认字节范围分辨率定义为1 MB大小，将报告阈值定义为1 MB/秒或10次I/O操作/秒。
For each byte range, ffis_offset and ffis_length represent the starting offset of the range and the range length in bytes. ffis_read.ii_count, ffis_read.ii_bytes, ffis_write.ii_count, and ffis_write.ii_bytes represent the number of contiguous READ and WRITE I/Os and the respective aggregate number of bytes transferred within the reported byte range.
对于每个字节范围，ffis_偏移量和ffis_长度表示范围的起始偏移量和范围长度（以字节为单位）。ffis_read.ii_count、ffis_read.ii_bytes、ffis_write.ii_count和ffis_write.ii_bytes表示连续读写I/O的数量以及在报告的字节范围内传输的相应字节总数。
The combination of ffis_deviceid and ffl_addr uniquely identifies both the storage path and the network route to it. Finally, ffl_fhandle allows the metadata server to differentiate between multiple read-only copies of the file on the same storage device.
ffis_deviceid和ffl_addr的组合可唯一标识存储路径和到该路径的网络路由。最后，ffl_fhandle允许元数据服务器区分同一存储设备上文件的多个只读副本。
<CODE BEGINS>
<代码开始>
/// struct ff_layoutreturn4 {
/// ff_ioerr4 fflr_ioerr_report<>;
/// ff_iostats4 fflr_iostats_report<>;
/// };
///
/// struct ff_layoutreturn4 {
/// ff_ioerr4 fflr_ioerr_report<>;
/// ff_iostats4 fflr_iostats_report<>;
/// };
///
<CODE ENDS>
<代码结束>
When data file I/O operations fail, fflr_ioerr_report<> is used to report these errors to the metadata server as an array of elements of type ff_ioerr4. Each element in the array represents an error that occurred on the data file identified by ffie_errors.de_deviceid. If no errors are to be reported, the size of the fflr_ioerr_report<> array is set to zero. The client MAY also use fflr_iostats_report<> to report a list of I/O statistics as an array of elements of type ff_iostats4. Each element in the array represents statistics for a particular byte range. Byte ranges are not guaranteed to be disjoint and MAY repeat or intersect.
当数据文件I/O操作失败时，使用FFR_ioerr_report<>将这些错误作为ff_ioerr4类型的元素数组报告给元数据服务器。数组中的每个元素表示在由ffie_errors.de_deviceid标识的数据文件上发生的错误。如果不报告任何错误，则fflr_ioerr_报告<>数组的大小设置为零。客户端还可以使用fflr_iostats_report<>将I/O统计信息列表报告为ff_iostats4类型的元素数组。数组中的每个元素表示特定字节范围的统计信息。字节范围不能保证不相交，可能重复或相交。
If the client is using NFSv4.2 to communicate with the metadata server, then instead of waiting for a LAYOUTRETURN to send error information to the metadata server (see Section 9.1), it MAY use LAYOUTERROR (see Section 15.6 of [RFC7862]) to communicate that information. For the flexible file layout type, this means that LAYOUTERROR4args is treated the same as ff_ioerr4.
如果客户机使用NFSv4.2与元数据服务器通信，那么它可以使用LAYOUTERROR（参见[RFC7862]第15.6节）来通信该信息，而不是等待LAYOUTRETURN向元数据服务器发送错误信息（参见第9.1节）。对于灵活的文件布局类型，这意味着LAYOUTERROR4args与ff_ioerr4的处理方式相同。
If the client is using NFSv4.2 to communicate with the metadata server, then instead of waiting for a LAYOUTRETURN to send I/O statistics to the metadata server (see Section 9.2), it MAY use LAYOUTSTATS (see Section 15.7 of [RFC7862]) to communicate that information. For the flexible file layout type, this means that LAYOUTSTATS4args.lsa_layoutupdate is overloaded with the same contents as in ffis_layoutupdate.
如果客户端使用NFSv4.2与元数据服务器通信，那么它可以使用LAYOUTSTATS（参见[RFC7862]第15.7节）来通信该信息，而不是等待LAYOUTRETURN向元数据服务器发送I/O统计信息（参见第9.2节）。对于灵活的文件布局类型，这意味着LAYOUTSTATS4args.lsa_layoutupdate重载的内容与ffis_layoutupdate中的内容相同。
The layouthint4 type is defined in the [RFC5661] as follows:
[RFC5661]中定义了LayoutInt4类型，如下所示：
<CODE BEGINS>
<代码开始>
struct layouthint4 {
layouttype4 loh_type;
opaque loh_body<>;
};
struct layouthint4 {
layouttype4 loh_type;
opaque loh_body<>;
};
<CODE ENDS>
<代码结束>
The layouthint4 structure is used by the client to pass a hint about the type of layout it would like created for a particular file. If the loh_type layout type is LAYOUT4_FLEX_FILES, then the loh_body opaque value is defined by the ff_layouthint4 type.
客户端使用LayoutInt4结构传递有关它希望为特定文件创建的布局类型的提示。如果loh_类型布局类型为LAYOUT4_FLEX_文件，则loh_主体不透明值由ff_LayoutInt4类型定义。
<CODE BEGINS>
<代码开始>
/// union ff_mirrors_hint switch (bool ffmc_valid) {
/// case TRUE:
/// uint32_t ffmc_mirrors;
/// case FALSE:
/// void;
/// };
///
/// union ff_mirrors_hint switch (bool ffmc_valid) {
/// case TRUE:
/// uint32_t ffmc_mirrors;
/// case FALSE:
/// void;
/// };
///
/// struct ff_layouthint4 {
/// ff_mirrors_hint fflh_mirrors_hint;
/// };
///
/// struct ff_layouthint4 {
/// ff_mirrors_hint fflh_mirrors_hint;
/// };
///
<CODE ENDS>
<代码结束>
This type conveys hints for the desired data map. All parameters are optional so the client can give values for only the parameter it cares about.
此类型传递所需数据映射的提示。所有参数都是可选的，因此客户端只能为其关心的参数提供值。
While Section 12.5.5 of [RFC5661] discusses reasons independent of layout type for recalling a layout, the flexible file layout type metadata server should recall outstanding layouts in the following cases:
[RFC5661]第12.5.5节讨论了独立于版面类型的召回版面的原因，但灵活文件版面类型元数据服务器应在以下情况下召回未完成的版面：
o When the file's security policy changes, i.e., ACLs or permission mode bits are set.
o 当文件的安全策略更改时，即设置ACL或权限模式位。
o When the file's layout changes, rendering outstanding layouts invalid.
o 当文件的布局更改时，渲染未完成的布局无效。
o When existing layouts are inconsistent with the need to enforce locking constraints.
o 当现有布局与强制锁定约束的需要不一致时。
o When existing layouts are inconsistent with the requirements regarding resilvering as described in Section 8.3.
o 当现有布局与第8.3节中所述的重定位要求不一致时。
The metadata server can use the CB_RECALL_ANY callback operation to notify the client to return some or all of its layouts. Section 22.3 of [RFC5661] defines the allowed types of the "NFSv4 Recallable Object Types Registry".
元数据服务器可以使用CB_RECALL_ANY回调操作通知客户端返回其部分或全部布局。[RFC5661]第22.3节定义了“NFSv4可重调对象类型注册表”的允许类型。
<CODE BEGINS>
<代码开始>
/// const RCA4_TYPE_MASK_FF_LAYOUT_MIN = 16;
/// const RCA4_TYPE_MASK_FF_LAYOUT_MAX = 17;
///
/// const RCA4_TYPE_MASK_FF_LAYOUT_MIN = 16;
/// const RCA4_TYPE_MASK_FF_LAYOUT_MAX = 17;
///
struct CB_RECALL_ANY4args {
uint32_t craa_layouts_to_keep;
bitmap4 craa_type_mask;
};
struct CB_RECALL_ANY4args {
uint32_t craa_layouts_to_keep;
bitmap4 craa_type_mask;
};
<CODE ENDS>
<代码结束>
Typically, CB_RECALL_ANY will be used to recall client state when the server needs to reclaim resources. The craa_type_mask bitmap specifies the type of resources that are recalled, and the craa_layouts_to_keep value specifies how many of the recalled flexible file layouts the client is allowed to keep. The mask flags for the flexible file layout type are defined as follows:
通常，当服务器需要回收资源时，CB_RECALL_ANY将用于调用客户端状态。craa_type_mask位图指定调用的资源类型，craa_layouts_to_keep值指定允许客户端保留多少调用的灵活文件布局。灵活文件布局类型的掩码标志定义如下：
<CODE BEGINS>
<代码开始>
/// enum ff_cb_recall_any_mask {
/// PNFS_FF_RCA4_TYPE_MASK_READ = 16,
/// PNFS_FF_RCA4_TYPE_MASK_RW = 17
/// };
///
/// enum ff_cb_recall_any_mask {
/// PNFS_FF_RCA4_TYPE_MASK_READ = 16,
/// PNFS_FF_RCA4_TYPE_MASK_RW = 17
/// };
///
<CODE ENDS>
<代码结束>
The flags represent the iomode of the recalled layouts. In response, the client SHOULD return layouts of the recalled iomode that it needs the least, keeping at most craa_layouts_to_keep flexible file layouts.
这些标志表示调用布局的iomode。作为响应，客户机应该返回它所需要的最少的iomode布局，保持最多craa_布局，以保持灵活的文件布局。
The PNFS_FF_RCA4_TYPE_MASK_READ flag notifies the client to return layouts of iomode LAYOUTIOMODE4_READ. Similarly, the PNFS_FF_RCA4_TYPE_MASK_RW flag notifies the client to return layouts of iomode LAYOUTIOMODE4_RW. When both mask flags are set, the client is notified to return layouts of either iomode.
PNFS_FF_RCA4_TYPE_MASK_READ标志通知客户端返回iomode LAYOUTIOMODE4_READ的布局。类似地，PNFS_FF_RCA4_TYPE_MASK_RW标志通知客户机返回iomode LAYOUTIOMODE4_RW的布局。设置两个掩码标志后，将通知客户端返回任一iomode的布局。
In cases where clients are uncommunicative and their lease has expired or when clients fail to return recalled layouts within a lease period, the server MAY revoke client layouts and reassign these resources to other clients (see Section 12.5.5 of [RFC5661]). To avoid data corruption, the metadata server MUST fence off the revoked clients from the respective data files as described in Section 2.2.
如果客户端无法通信且其租约已到期，或者客户端未能在租约期内返回调用的布局，则服务器可撤销客户端布局并将这些资源重新分配给其他客户端（参见[RFC5661]第12.5.5节）。为了避免数据损坏，元数据服务器必须按照第2.2节所述，将已撤销的客户端与相应的数据文件隔离开来。
The combination of components in a pNFS system is required to preserve the security properties of NFSv4.1+ with respect to an entity accessing data via a client. The pNFS feature partitions the NFSv4.1+ file system protocol into two parts: the control protocol and the data protocol. As the control protocol in this document is NFS, the security properties are equivalent to the version of NFS being used. The flexible file layout further divides the data
pNFS系统中的组件组合需要保留NFSv4.1+关于通过客户端访问数据的实体的安全属性。pNFS特性将NFSv4.1+文件系统协议分为两部分：控制协议和数据协议。由于本文档中的控制协议是NFS，因此安全属性等同于所使用的NFS版本。灵活的文件布局进一步划分了数据
protocol into metadata and data paths. The security properties of the metadata path are equivalent to those of NFSv4.1x (see Sections 1.7.1 and 2.2.1 of [RFC5661]). And the security properties of the data path are equivalent to those of the version of NFS used to access the storage device, with the provision that the metadata server is responsible for authenticating client access to the data file. The metadata server provides appropriate credentials to the client to access data files on the storage device. It is also responsible for revoking access for a client to the storage device.
将协议转换为元数据和数据路径。元数据路径的安全属性等同于NFSv4.1x的安全属性（参见[RFC5661]第1.7.1节和第2.2.1节）。数据路径的安全属性等同于用于访问存储设备的NFS版本的安全属性，前提是元数据服务器负责验证客户端对数据文件的访问。元数据服务器向客户端提供适当的凭据以访问存储设备上的数据文件。它还负责撤消客户端对存储设备的访问。
The metadata server enforces the file access control policy at LAYOUTGET time. The client should use RPC authorization credentials for getting the layout for the requested iomode ((LAYOUTIOMODE4_READ or LAYOUTIOMODE4_RW), and the server verifies the permissions and ACL for these credentials, possibly returning NFS4ERR_ACCESS if the client is not allowed the requested iomode. If the LAYOUTGET operation succeeds, the client receives, as part of the layout, a set of credentials allowing it I/O access to the specified data files corresponding to the requested iomode. When the client acts on I/O operations on behalf of its local users, it MUST authenticate and authorize the user by issuing respective OPEN and ACCESS calls to the metadata server, similar to having NFSv4 data delegations.
元数据服务器在LAYOUTGET时强制执行文件访问控制策略。客户端应使用RPC授权凭据获取所请求iomode的布局（（LAYOUTIOMODE4\u READ或LAYOUTIOMODE4\u RW），服务器验证这些凭据的权限和ACL，如果不允许客户端访问请求的iomode，则可能返回NFS4ERR_访问权限。如果LAYOUTGET操作成功，客户端将收到一组凭据，作为布局的一部分，允许其对与请求的iomode对应的指定数据文件进行I/O访问。当客户端代表其本地用户执行I/O操作时，它必须通过向元数据服务器发出相应的打开和访问调用来对用户进行身份验证和授权，这类似于NFSv4数据委托。
The combination of filehandle, synthetic uid, and gid in the layout is the way that the metadata server enforces access control to the data server. The client only has access to filehandles of file objects and not directory objects. Thus, given a filehandle in a layout, it is not possible to guess the parent directory filehandle. Further, as the data file permissions only allow the given synthetic uid read/write permission and the given synthetic gid read permission, knowing the synthetic ids of one file does not necessarily allow access to any other data file on the storage device.
布局中filehandle、合成uid和gid的组合是元数据服务器对数据服务器实施访问控制的方式。客户端只能访问文件对象的文件句柄，不能访问目录对象。因此，给定布局中的文件句柄，不可能猜测父目录文件句柄。此外，由于数据文件权限仅允许给定的合成uid读/写权限和给定的合成gid读权限，因此知道一个文件的合成id不一定允许访问存储设备上的任何其他数据文件。
The metadata server can also deny access at any time by fencing the data file, which means changing the synthetic ids. In turn, that forces the client to return its current layout and get a new layout if it wants to continue I/O to the data file.
元数据服务器还可以通过保护数据文件随时拒绝访问，这意味着更改合成ID。反过来，如果客户端希望继续对数据文件进行I/O操作，则会强制客户端返回其当前布局并获取新布局。
If access is allowed, the client uses the corresponding (read-only or read/write) credentials to perform the I/O operations at the data file's storage devices. When the metadata server receives a request to change a file's permissions or ACL, it SHOULD recall all layouts for that file and then MUST fence off any clients still holding outstanding layouts for the respective files by implicitly invalidating the previously distributed credential on all data file comprising the file in question. It is REQUIRED that this be done before committing to the new permissions and/or ACL. By requesting
如果允许访问，客户端将使用相应的（只读或读/写）凭据在数据文件的存储设备上执行I/O操作。当元数据服务器接收到更改文件权限或ACL的请求时，它应该调用该文件的所有布局，然后必须通过隐式地使包含所述文件的所有数据文件上先前分发的凭据无效，从而隔离仍保留相应文件未完成布局的任何客户端。要求在提交到新权限和/或ACL之前完成此操作。请求
new layouts, the clients will reauthorize access against the modified access control metadata. Recalling the layouts in this case is intended to prevent clients from getting an error on I/Os done after the client was fenced off.
在新布局中，客户端将根据修改后的访问控制元数据重新授权访问。在这种情况下，调用布局是为了防止客户机在被隔离后在I/O上出错。
Because of the special use of principals within the loosely coupled model, the issues are different depending on the coupling model.
由于在松散耦合模型中对主体的特殊使用，因此问题因耦合模型而异。
RPCSEC_GSS version 3 (RPCSEC_GSSv3) [RFC7861] contains facilities that would allow it to be used to authorize the client to the storage device on behalf of the metadata server. Doing so would require that each of the metadata server, storage device, and client would need to implement RPCSEC_GSSv3 using an RPC-application-defined structured privilege assertion in a manner described in Section 4.9.1 of [RFC7862]. The specifics necessary to do so are not described in this document. This is principally because any such specification would require extensive implementation work on a wide range of storage devices, which would be unlikely to result in a widely usable specification for a considerable time.
RPCSEC_GSS版本3（RPCSEC_GSSv3）[RFC7861]包含的功能允许它用于代表元数据服务器向存储设备授权客户端。这样做需要每个元数据服务器、存储设备和客户机都需要以[RFC7862]第4.9.1节所述的方式，使用RPC应用程序定义的结构化特权断言实现RPCSEC_GSSv3。本文档中未描述执行此操作所需的详细信息。这主要是因为任何此类规范都需要在广泛的存储设备上进行广泛的实施工作，这在相当长的一段时间内不太可能产生广泛可用的规范。
As a result, the layout type described in this document will not provide support for use of RPCSEC_GSS together with the loosely coupled model. However, future layout types could be specified, which would allow such support, either through the use of RPCSEC_GSSv3 or in other ways.
因此，本文档中描述的布局类型不支持将RPCSEC_GSS与松耦合模型一起使用。但是，可以通过使用RPCSEC_GSSv3或以其他方式指定允许此类支持的未来布局类型。
With tight coupling, the principal used to access the metadata file is exactly the same as used to access the data file. The storage device can use the control protocol to validate any RPC credentials. As a result, there are no security issues related to using RPCSEC_GSS with a tightly coupled system. For example, if Kerberos V5 Generic Security Service Application Program Interface (GSS-API) [RFC4121] is used as the security mechanism, then the storage device could use a control protocol to validate the RPC credentials to the metadata server.
通过紧密耦合，用于访问元数据文件的主体与用于访问数据文件的主体完全相同。存储设备可以使用控制协议验证任何RPC凭据。因此，在紧密耦合的系统中使用RPCSEC_GSS不存在任何安全问题。例如，如果Kerberos V5通用安全服务应用程序接口（GSS-API）[RFC4121]用作安全机制，则存储设备可以使用控制协议来验证元数据服务器的RPC凭据。
[RFC5661] introduced the "pNFS Layout Types Registry"; new layout type numbers in this registry need to be assigned by IANA. This document defines the protocol associated with an existing layout type number: LAYOUT4_FLEX_FILES. See Table 1.
[RFC5661]引入了“pNFS布局类型注册表”；此注册表中的新布局类型编号需要由IANA分配。本文档定义了与现有布局类型编号：LAYOUT4\u FLEX\u文件关联的协议。见表1。
+--------------------+------------+----------+-----+----------------+
| Layout Type Name | Value | RFC | How | Minor Versions |
+--------------------+------------+----------+-----+----------------+
| LAYOUT4_FLEX_FILES | 0x00000004 | RFC 8435 | L | 1 |
+--------------------+------------+----------+-----+----------------+
+--------------------+------------+----------+-----+----------------+
| Layout Type Name | Value | RFC | How | Minor Versions |
+--------------------+------------+----------+-----+----------------+
| LAYOUT4_FLEX_FILES | 0x00000004 | RFC 8435 | L | 1 |
+--------------------+------------+----------+-----+----------------+
Table 1: Layout Type Assignments
表1：布局类型指定
[RFC5661] also introduced the "NFSv4 Recallable Object Types Registry". This document defines new recallable objects for RCA4_TYPE_MASK_FF_LAYOUT_MIN and RCA4_TYPE_MASK_FF_LAYOUT_MAX (see Table 2).
[RFC5661]还引入了“NFSv4可重调对象类型注册表”。本文件定义了RCA4_类型_掩码_FF_布局_最小值和RCA4_类型_掩码_FF_布局_最大值的新可重调对象（见表2）。
+------------------------------+-------+--------+-----+-------------+
| Recallable Object Type Name | Value | RFC | How | Minor |
| | | | | Versions |
+------------------------------+-------+--------+-----+-------------+
| RCA4_TYPE_MASK_FF_LAYOUT_MIN | 16 | RFC | L | 1 |
| | | 8435 | | |
| RCA4_TYPE_MASK_FF_LAYOUT_MAX | 17 | RFC | L | 1 |
| | | 8435 | | |
+------------------------------+-------+--------+-----+-------------+
+------------------------------+-------+--------+-----+-------------+
| Recallable Object Type Name | Value | RFC | How | Minor |
| | | | | Versions |
+------------------------------+-------+--------+-----+-------------+
| RCA4_TYPE_MASK_FF_LAYOUT_MIN | 16 | RFC | L | 1 |
| | | 8435 | | |
| RCA4_TYPE_MASK_FF_LAYOUT_MAX | 17 | RFC | L | 1 |
| | | 8435 | | |
+------------------------------+-------+--------+-----+-------------+
Table 2: Recallable Object Type Assignments
表2：可重调对象类型指定
[LEGAL] IETF Trust, "Trust Legal Provisions (TLP)", <https://trustee.ietf.org/trust-legal-provisions.html>.
[法律]IETF信托，“信托法律条款（TLP）”<https://trustee.ietf.org/trust-legal-provisions.html>.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, DOI 10.17487/RFC1813, June 1995, <https://www.rfc-editor.org/info/rfc1813>.
[RFC1813]Callaghan，B.，Pawlowski，B.，和P.Staubach，“NFS版本3协议规范”，RFC 1813，DOI 10.17487/RFC1813，1995年6月<https://www.rfc-editor.org/info/rfc1813>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, DOI 10.17487/RFC4121, July 2005, <https://www.rfc-editor.org/info/rfc4121>.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 4121，DOI 10.17487/RFC4121，2005年7月<https://www.rfc-editor.org/info/rfc4121>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 2006, <https://www.rfc-editor.org/info/rfc4506>.
[RFC4506]艾斯勒，M.，编辑，“XDR：外部数据表示标准”，STD 67，RFC 4506，DOI 10.17487/RFC4506，2006年5月<https://www.rfc-editor.org/info/rfc4506>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, <https://www.rfc-editor.org/info/rfc5531>.
[RFC5531]Thurlow，R.，“RPC：远程过程调用协议规范版本2”，RFC 5531，DOI 10.17487/RFC5531，2009年5月<https://www.rfc-editor.org/info/rfc5531>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc5661>.
[RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", RFC 5662, DOI 10.17487/RFC5662, January 2010, <https://www.rfc-editor.org/info/rfc5662>.
[RFC5662]Shepler，S.，Ed.，Eisler，M.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1外部数据表示标准（XDR）说明”，RFC 5662，DOI 10.17487/RFC5662，2010年1月<https://www.rfc-editor.org/info/rfc5662>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.和D.Noveck，Ed.，“网络文件系统（NFS）第4版协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<https://www.rfc-editor.org/info/rfc7530>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", RFC 7861, DOI 10.17487/RFC7861, November 2016, <https://www.rfc-editor.org/info/rfc7861>.
[RFC7861]Adamson，A.和N.Williams，“远程过程调用（RPC）安全版本3”，RFC 7861，DOI 10.17487/RFC7861，2016年11月<https://www.rfc-editor.org/info/rfc7861>.
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[RFC7862]Haynes，T.，“网络文件系统（NFS）版本4次要版本2协议”，RFC 7862，DOI 10.17487/RFC7862，2016年11月<https://www.rfc-editor.org/info/rfc7862>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8434] Haynes, T., "Requirements for Parallel NFS (pNFS) Layout Types", RFC 8434, DOI 10.17487/RFC8434, August 2018, <https://www.rfc-editor.org/info/rfc8434>.
[RFC8434]Haynes，T，“并行NFS（pNFS）布局类型的要求”，RFC 8434，DOI 10.17487/RFC8434，2018年8月<https://www.rfc-editor.org/info/rfc8434>.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, DOI 10.17487/RFC4519, June 2006, <https://www.rfc-editor.org/info/rfc4519>.
[RFC4519]Sciberras，A.，Ed.，“轻量级目录访问协议（LDAP）：用户应用程序模式”，RFC 4519，DOI 10.17487/RFC4519，2006年6月<https://www.rfc-editor.org/info/rfc4519>.
Acknowledgments
致谢
The following individuals provided miscellaneous comments to early draft versions of this document: Matt W. Benjamin, Adam Emerson, J. Bruce Fields, and Lev Solomonov.
以下个人对本文件的早期草案版本提供了杂项评论：Matt W.Benjamin、Adam Emerson、J.Bruce Fields和Lev Solomonov。
The following individuals provided miscellaneous comments to the final draft versions of this document: Anand Ganesh, Robert Wipfel, Gobikrishnan Sundharraj, Trond Myklebust, Rick Macklem, and Jim Sermersheim.
以下个人对本文件的最终草案版本提供了杂项评论：阿南德·甘尼什、罗伯特·维普费尔、戈比克里希南·桑达拉伊、特隆·米克勒布斯特、里克·麦克莱姆和吉姆·塞尔默谢姆。
Idan Kedar caught a nasty bug in the interaction of client-side mirroring and the minor versioning of devices.
Idan Kedar在客户端镜像的交互和设备的小版本控制中发现了一个严重的错误。
Dave Noveck provided comprehensive reviews of the document during the working group last calls. He also rewrote Section 2.3.
Dave Noveck在工作组最后一次电话会议期间对该文件进行了全面审查。他还重写了第2.3节。
Olga Kornievskaia made a convincing case against the use of a credential versus a principal in the fencing approach. Andy Adamson and Benjamin Kaduk helped to sharpen the focus.
Olga Kornievskaia提出了一个令人信服的理由，反对在击剑法中使用凭证对抗校长。安迪·亚当森（Andy Adamson）和本杰明·卡杜克（Benjamin Kaduk）帮助聚焦。
Benjamin Kaduk and Olga Kornievskaia also helped provide concrete scenarios for loosely coupled security mechanisms. In the end, Olga proved that as defined, the loosely coupled model would not work with RPCSEC_GSS.
Benjamin Kaduk和Olga Kornievskaia还帮助提供了松耦合安全机制的具体场景。最后，Olga证明，按照定义，松散耦合模型无法与RPCSEC_GSS一起工作。
Tigran Mkrtchyan provided the use case for not allowing the client to proxy the I/O through the data server.
Tigran Mkrtchyan提供了不允许客户端通过数据服务器代理I/O的用例。
Rick Macklem provided the use case for only writing to a single mirror.
Rick Macklem提供了只向单个镜像写入的用例。
Authors' Addresses
作者地址
Benny Halevy
本尼·哈维
Email: bhalevy@gmail.com
Email: bhalevy@gmail.com
Thomas Haynes Hammerspace 4300 El Camino Real Ste 105 Los Altos, CA 94022 United States of America
Thomas Haynes Hammerspace 4300 El Camino Real Ste 105 Los Altos，加利福尼亚州，美利坚合众国94022
Email: loghyr@gmail.com
Email: loghyr@gmail.com