[要約] RFC 8435は、pNFSの柔軟なファイルレイアウトに関する規格であり、分散ファイルシステムのパフォーマンスと拡張性を向上させることを目的としています。
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
Parallel 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.
Parallel NFS（pNFS）では、ファイルのメタデータ（メタデータサーバー上）とデータ（ストレージデバイス上）を分離できます。このドキュメントでは、柔軟なファイルレイアウトタイプをpNFSの拡張として定義し、メタデータサーバーとの限られた程度の対話のみを必要とし、既存のプロトコルを使用するストレージデバイスを使用できるようにします。ファイルの複製を提供するために、クライアント側のミラーリングも追加されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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].
Parallel NFS（pNFS）では、メタデータサーバーは、ファイルデータの場所を説明するレイアウトタイプの構造を返します。ストレージシステムによって異なるレイアウトタイプと、ストレージデバイスにデータを配置する方法があります。このドキュメントでは、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 +ストレージデバイスの間にバックエンド制御プロトコルを実装する場合があります。実装では、独自のメカニズムを定義することも、Standards Trackドキュメントで制御プロトコルを定義することもできます。制御プロトコルの要件は、[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に基づいています。メタデータサーバーとストレージデバイス間で渡されるステートIDの知識は提供されません。代わりに、ストレージデバイスは、メタデータサーバーがデータファイルシステムへの完全なアクセス権を持ち、メタデータサーバーが合成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.
レイアウト：クライアントがストレージデバイス上のファイルデータにアクセスするために使用する情報。この情報には、プロトコルの仕様（レイアウトタイプ）と使用するストレージデバイスのIDが含まれます。
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.
レイアウト状態ID：レイアウトタイプとファイルを記述する特定のレイアウトに対してサーバーによって提供されるレイアウト状態を一意に定義する、サーバーによって返される128ビットの数量（[RFC5661]のセクション12..5.2を参照）。さらに、[RFC5661]のセクション12..5.3では、レイアウトのステートIDと他のステートIDタイプの処理の違いについて説明しています。
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.
ミラー：レイアウトセグメントのコピー。ミラーの1つのコピーを更新する場合は、すべてのコピーを更新する必要があることに注意してください。
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.
resize：READに使用されるデータ転送バッファーのサイズ。
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.
密結合：制御プロトコルが制御通信専用に設計されたものである配置。これは、特定のメタデータサーバーに特別に適合した独自のプロトコルか、Standards Trackドキュメントに基づくプロトコルのいずれかです。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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）セキュリティとLAYOUTCOMMITの両方の管理
(2) a global stateid model and management of these stateids.
（2）グローバルステートIDモデルおよびこれらのステートIDの管理。
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のバージョンのみであり、グローバルな状態IDモデルを提供したり、クライアントがレイアウトを不適切に使用したりすることを防止できません。その環境でクライアントを使用できるようにするために、このドキュメントでは、セキュリティ、状態、およびロックの管理方法を指定します。
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を参照）を受信すると、pNFSのセマンティクスが確実に尊重されるようにします（[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.
メタデータサーバーがファイルへの変更についてストレージデバイスにクエリを開始する前に、データファイルが安定していることを確認するのはクライアントの責任です。ストレージデバイスへの書き込みの結果、stable_howがFILE_SYNCと等しくなかった場合、メタデータサーバーへのLAYOUTCOMMITの前に、書き込まれたストレージデバイスへのCOMMITを実行する必要があります。クライアントがストレージデバイスへのCOMMITを実行していない場合、LAYOUTCOMMITはストレージデバイスへの最後のWRITE操作に同期されない可能性があることに注意してください。
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_userおよびffds_groupを参照）、クライアントには、データファイルへのアクセスに必要なリモートプロシージャコール（RPC）[RFC5531]資格情報で使用されるユーザーとグループが提供されます。クライアントのフェンシングは、メタデータサーバーがストレージデバイス上のデータファイルの合成uidやgidの所有者を変更して、未解決のRPC資格情報を暗黙的に取り消すことによって実現されます。目的のアクセスに対して誤った資格情報を提示しているクライアントは、NFS4ERR_ACCESSエラーを受け取ります。
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.
メタデータサーバーのルート（スーパーユーザー）のみがストレージデバイスにアクセスできるようにし、データファイルを保持するすべてのディレクトリの所有者をルートユーザーに設定するために、ストレージデバイスのファイルシステムに一般的なアクセス制御方法を実装することをお勧めします。このアプローチは、アクセス制御を実施し、協調型クライアントを隔離するための実用的なモデルを提供しますが、悪意のあるクライアントから保護することはできません。したがって、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を参照）の実装では、ストレージデバイスの対応する状態IDを無効にすることにより、特定のクライアントが特定のファイルにアクセスできないようにする方法が必要です。このようなシナリオでは、クライアントに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」フィールドで使用可能なそのようなIDの範囲を制限する場合があります[RFC4519]。管理者は、アクセスを許可するために決して使用されない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_userおよびffds_groupとしてクライアントに送り返され、クライアントは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が少なくとも1つ利用可能になることに注意してください。
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セキュリティモデルでは、0の合成uidとgidを回避する必要があります。これらは通常、ストレージデバイス上のファイルへのスーパーアクセスを許可するか、匿名IDにマップされます。最初のケースでは、データファイルがフェンスされている場合でも、クライアントはファイルにアクセスできる可能性があります。 2番目のケースでは、複数の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 12月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
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
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.
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書き込みアクセスを許可するために、RPCを1066：1067の資格情報を持つストレージデバイスに送信します。 Garbo読み取りアクセスを許可するために、RPCを資格情報1067：1067でストレージデバイスに送信します。レイアウトの取得時に付与される合成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.
権限チェックの強制をクライアントにプッシュすると、セキュリティが低下するように見える場合がありますが、変更がサーバーに送信される前に、クライアントが権限を強制する必要がある場合があります。キャッシュされた書き込みでは、クライアントは常に、ファイルを変更しているユーザーを追跡し、複数のユーザーからのリクエストを1つのリクエストにまとめないようにする責任があります。
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 EXCHGID4_FLAG_USE_PNFS_DSフラグをEXCHANGE_IDに設定して返さないNFSv4.1 +ストレージデバイスは、疎結合として扱われることを示しています。ロックの観点からは、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 EXCHGID4_FLAG_USE_PNFS_DSフラグをEXCHANGE_IDに設定して自身を識別するNFSv4.1 +ストレージデバイスは、密結合される可能性があります。彼らは、[RFC5661]で説明されているように、バックエンド制御プロトコルを使用してグローバルステートIDモデルを実装します。
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.
ロック関連の操作が要求されると、それらは主に適切な状態IDを生成するメタデータサーバーによって処理されます。 NFSv4バージョンがデータアクセスプロトコルとして使用される場合、メタデータサーバーは、ストレージデバイスのステートID関連の要求を行う場合があります。ただし、そうする必要はなく、結果の状態IDはメタデータサーバーとストレージデバイスだけが認識します。
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 OPENは、メタデータサーバーによって処理されます。 Stateidはメタデータサーバーによって選択され、メタデータサーバーへのクライアントの接続を表すクライアントIDに関連付けられます。メタデータサーバーは、開かれるファイルを見つけるためにストレージデバイスと対話する必要がある場合がありますが、ストレージデバイスでロック関連の機能を使用する必要はありません。
OPEN_DOWNGRADE and CLOSE only require local execution on the metadata server.
OPEN_DOWNGRADEとCLOSEは、メタデータサーバーでのローカル実行のみを必要とします。
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 アドバイザリのバイト範囲ロックは、メタデータサーバーにローカルに実装できます。 OPENの場合と同様に、バイト範囲ロックに関連付けられた状態IDは、メタデータサーバーによって割り当てられ、メタデータサーバーでのみ使用されます。
o Delegations are assigned by the metadata server that initiates recalls when conflicting OPENs are processed. No storage device involvement is required.
o 委任は、競合するOPENが処理されると再呼び出しを開始するメタデータサーバーによって割り当てられます。ストレージデバイスの関与は必要ありません。
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は匿名の状態IDを使用して行われますが、クライアントは、openownerに関連付けられた有効な状態IDがあることを確認する必要があります。
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プロトコル経由である場合でも、ストレージデバイスにクライアントリースがなく、リースの有効期限が切れる見込みはありません。クライアントはメタデータサーバーにリースを持ちます。リースの有効期限を処理する際、メタデータサーバーはフェンシングを使用して、取り消されたという事実を知らないクライアントが取り消された状態IDに依存しないようにする必要があります。
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.
ロック関連の操作が要求されると、それらは主に適切な状態IDを生成するメタデータサーバーによって処理されます。これらの状態IDは、制御プロトコル機能を使用してストレージデバイスに通知する必要があります。詳細については、このドキュメントでは説明しません。
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 OPENは主にメタデータサーバーで処理されます。 Stateidはメタデータサーバーによって選択され、メタデータサーバーへのクライアントの接続を表すクライアントIDに関連付けられます。メタデータサーバーは、開かれるファイルを特定し、メタデータサーバーが選択した状態IDと、それが表すクライアントおよびopenownerとの間の関連付けをストレージデバイスに認識させるために、ストレージデバイスと対話する必要があります。
OPEN_DOWNGRADE and CLOSE are executed initially on the metadata server, but the state change made must be propagated to the storage device.
OPEN_DOWNGRADEとCLOSEは最初にメタデータサーバーで実行されますが、行われた状態変更はストレージデバイスに伝達する必要があります。
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 アドバイザリのバイト範囲ロックは、メタデータサーバーにローカルに実装できます。 OPENの場合と同様に、バイト範囲ロックに関連付けられた状態IDはメタデータサーバーによって割り当てられ、メタデータサーバーで使用できます。 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 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.
oメタデータサーバーとストレージデバイスの両方が適切にサポートされている場合、必須のバイト範囲ロックをサポートできます。勧告的バイト範囲ロックの場合と同様に、これらはメタデータサーバーによって割り当てられ、メタデータサーバーで使用できます。ストレージデバイスで強制的なロックの強制を有効にするには、メタデータサーバーは、メタデータサーバーが選択した状態IDとクライアント、openowner、およびロック（つまり、lockowner、byte-range、およびそれが表すロックタイプ）。 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 委任は、競合するOPENが処理されると再呼び出しを開始するメタデータサーバーによって割り当てられます。 I / O操作では委任状態IDを提示できるため、メタデータサーバーには、（1）メタデータサーバーが選択した状態IDと、それが表すファイルハンドルおよび委任タイプとの間の関連付けをストレージデバイスに認識させる機能が必要です。（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.
クライアントはストレージデバイスで有効なステートIDを所有して使用するため、ストレージデバイスにクライアントリースがあり、リースの有効期限が切れる可能性があります。ストレージデバイスの最善のアプローチは、これらのロックを礼儀として保持することです。ただし、そうでない場合、制御プロトコル機能は、メタデータサーバーとストレージデバイスの間でロック状態を同期する手段を提供する必要があります。
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.
また、クライアントはメタデータサーバーにリースがあり、有効期限が切れます。リースの有効期限を処理する際、メタデータサーバーは制御プロトコル機能を使用して、ストレージデバイス上の取り消された状態IDを無効にすることが期待されます。クライアントが応答しない場合、メタデータサーバーはフェンシングを使用して、取り消された状態IDがストレージデバイスによって操作されるのを防ぐ必要があります。
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 reader can feed this document into the following shell script to produce the machine-readable XDR description of the flexible file layout type:
このドキュメントには、フレキシブルファイルレイアウトタイプの外部データ表現（XDR）[RFC4506]の説明が含まれています。 XDRの説明は、読者がコンパイル可能なフォームに簡単に抽出できるように、このドキュメントに埋め込まれています。読者はこのドキュメントを次のシェルスクリプトにフィードして、柔軟なファイルレイアウトタイプの機械可読なXDR記述を生成できます。
<CODE BEGINS>
<コード開始>
#!/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_files_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ファイルのヘッダーは次のとおりです。センチネルシーケンスを含む後続の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]のタイプに依存することに注意してください。これには、offset4、length4などの4で終わるnfsタイプと、uint32_tやuint64_tなどのより一般的なタイプの両方が含まれます。
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の説明を抽出するために使用されるスクリプトはどちらも、「Trust Legal Provisions（TLP）」[LEGAL]のセクション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.
/// *
/// * - 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.
ff_device_addr4データ構造は、正常なGETDEVICEINFO操作によって、device_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_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_netaddrsフィールドは、ストレージデバイスを見つけるために使用されます。サーバーは、1つまたは複数のデバイスネットワークアドレスを保持するリストに設定する必要があります。
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_versionおよびffdv_minorversionは、ストレージデバイスへのアクセスに使用されるNFSプロトコルを表します。このレイアウト仕様は、ffdv_versions 3および4のセマンティクスを定義します。ffdv_versionが3の場合、サーバーはffdv_minorversionを0に設定し、ffdv_tightly_coupledをfalseに設定する必要があります。次に、クライアントはNFSv3プロトコル[RFC1813]を使用してストレージデバイスにアクセスする必要があります。 ffdv_versionが4の場合、サーバーはffdv_minorversionをNFSv4マイナーバージョン番号の1つに設定する必要があり、クライアントは指定されたマイナーバージョンで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_version、ffdv_minorversion、およびffdv_tightly_coupledの構成された組み合わせのいずれも使用できないと判断する場合がありますが、メタデータサーバーからデバイスリストを取得するとき、どのデバイスであるかをメタデータサーバーに示す方法はありません。バージョンに互換性がありません。ただし、クライアントがメタデータサーバーからレイアウトを取得するまで待機する場合、その時点で問題のストレージデバイスを明確に識別できます（セクション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_tightly_coupledは、メタデータサーバーがストレージデバイスと密結合されているかどうかをクライアントに通知します。データプロトコルが少なくともNFSv4.1であっても、疎結合が有効である場合があることに注意してください。 ffdv_tightly_coupledが設定されていない場合、クライアントは、LAYOUTCOMMITをメタデータサーバーに送信する前に、ファイルのストレージデバイスへの書き込みをコミットする必要があります。つまり、クライアントは、stable_how == FILE_SYNCを使用してWRITEを発行するか、またはstable_how！= FILE_SYNCを使用してWRITEの後にCOMMITを発行することによって、クライアントが安定したストレージに書き込みをコミットする必要があります（[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_netaddrsには1つ以上のストレージデバイスネットワークアドレスの配列が含まれています。この配列（データ型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 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.
クライアントは、ストレージデバイス要求を送信する宛先として、任意のネットワークアドレスを自由に使用できます。一部のネットワークアドレスが他よりもデータへの望ましいパスではない場合、メタデータサーバーはffda_netaddrsにそれらのネットワークアドレスを含めないでください。フェイルオーバーを提供するためにあまり望ましくないネットワークアドレスが存在する場合、アドレスを提供するための推奨される方法は、代替のデバイスIDからデバイスアドレスへのマッピングまたは代替のデバイスIDでそれらを提供することです。クライアントがffda_netaddrsで使用可能なすべてのアドレスを使用してストレージデバイスからの応答を見つけられない場合、クライアントはGETDEVICEINFOを送信して、既存のデバイスIDからデバイスアドレスへのマッピングを置き換えようとする必要があります（SHOULD）。メタデータサーバーがffda_netaddrsで表されるすべてのネットワークパスが利用できないことを検出した場合、メタデータサーバーはCB_NOTIFY_DEVICEIDを送信して（変更されたデバイスIDのデバイスID通知が必要であることをクライアントが示している場合）、デバイスIDからデバイスアドレスを変更する必要があります利用可能なアドレスへのマッピング。デバイスID自体が置き換えられる場合、メタデータサーバーはすべてのレイアウトをデバイスIDで再呼び出しして、LAYOUTGETおよびGETDEVICEINFOを介してクライアントに新しいレイアウトとデバイスIDマッピングを強制的に取得させる必要があります（SHOULD）。
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_netaddrsに2つのネットワークアドレスが表示される場合、それらは同じストレージデバイスを指定します。ストレージデバイスがNFSv4.1以降のマイナーバージョンを介してアクセスされる場合、2つのストレージデバイスアドレスは、[RFC5661]で定義されているクライアントIDまたはセッショントランキング（後者は推奨）の実装をサポートします。 2つのストレージデバイスアドレスは、同じサーバー所有者またはサーバー所有者のメジャーIDを共有します。 2つのストレージデバイスアドレスが、トランキングが使用されている同じストレージデバイスを指定する必要はありません。たとえば、データは読み取り専用で、データは正確なレプリカで構成されている場合があります。
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
};
struct layout_content4 {
layouttype4 loc_type;
opaque loc_body<>;
};
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_FILESに関連する構造を定義します。 [RFC5661]は、loc_body構造を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;
/// 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_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;
/// };
///
<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_layout配列で返される各layout4要素（[RFC5661]のセクション18.43.2を参照）は、レイアウトセグメントを記述しています。したがって、各ff_layout4はレイアウトセグメントも記述します。ファイルが複数のレイアウトセグメントから連結されている可能性があります。各レイアウトセグメントは、異なるストライピングパラメータを表す場合があります。
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_data_serversの要素の数によって各ミラー内に与えられます。ストライプの数が1の場合、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_hintフィールドは、サーバーがファイルのLAYOUTSTATSをレポートする頻度をクライアントにヒントを提供します。時間は秒単位です。
+-----------+
| |
| |
| 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は、データファイルを保持するストレージデバイスのデバイスIDを提供します。
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_fh_versは、特定のストレージデバイスで使用可能なNFSバージョンと一致するデータファイルのファイルハンドルの配列です。 ffda_versionsと同じ数の要素がffds_fh_versになければなりません。配列の各要素は、デバイスに提供されるffdv_version、ffdv_minorversion、およびffdv_tightly_coupledの特定の組み合わせに対応しています。この配列により、バージョン、マイナーバージョン、および結合強度のさまざまな組み合わせに対してさまざまなファイルハンドルを持つサーバー実装が可能になります。クライアントとストレージデバイス間のバージョン管理の問題を処理する方法については、セクション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
疎結合モデル：状態IDは匿名の状態IDでなければなりません
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が必要になる場合があります。このドキュメントで説明されているプロトコルのバージョンの疎結合実装が確立されているため、このような潜在的な問題はここでは扱われていません。同じ基本ファイルに複数の状態IDを提供することが重要になった場合、これらの問題に対処する将来のレイアウトタイプを定義することが可能です。
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_userおよびffds_groupは、クライアントがデータファイルにアクセスするためにストレージデバイスに提示するRPC資格情報で使用される合成ユーザーおよびグループを提供します。密結合ストレージデバイスの場合、ストレージデバイスのユーザーとグループはメタデータサーバーと同じになります。つまり、ffdv_tightly_coupled（セクション4.1を参照）が設定されている場合、クライアントはffds_userとffds_groupの両方を無視する必要があります。
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_userとffds_groupの両方に許可される値は、それぞれownerおよびowner_groupとして指定されています。 NFSv3互換性のために、先行ゼロのない10進数の数値で構成されるユーザーおよびグループ文字列は、そのようなサポートを提供することを選択したクライアントおよびサーバーによって特別な解釈を与えられることができます。受信者は、そのようなユーザーまたはグループ文字列を、対応する数値を持つ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_efficiencyは、各ミラーの有効性に関するメタデータサーバーの評価を示します。これはレイアウトごとであり、デバイスごとではなく、認識された負荷、メタデータサーバーへの可用性などによってメトリックが変化する可能性があることに注意してください。値が大きいほど、ユーティリティが高く認識されていることを示します。クライアントがアクセスに最適なミラーを選択する方法については、セクション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_flagsは、ストレージデバイスの多少の緊密な結合から生じる可能性のある特定の条件をメタデータサーバーがクライアントに通知できるようにするビットマップです。
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のレイアウトでREAD要求を送信してはならないことを示すように設定できます。代わりに、メタデータサーバーからiomode LAYOUTIOMODE4_READのレイアウトを要求する必要があります。
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：クライアントがミラーの1つのみを更新する必要があることを示すように設定できます（セクション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]は、クライアントがNFS4ERR_LAYOUTTRYLATER、NFS4ERR_LAYOUTUNAVAILABLE、NFS4ERR_DELAYのいずれかのエラーを返すLAYOUTGETをどのように進めるかについてのガイダンスをほとんど提供していません。このドキュメントのコンテキスト内：
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_DELAY：レイアウトを許可できない問題があります。クライアントがすでに適切なレイアウトを持っている場合、ストレージデバイスへの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_FLAGS_NO_IO_THRU_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]).
フレキシブルファイルレイアウトでは、LAYOUTCOMMITのloca_layoutupdate引数内でlou_bodyを使用しません。 lou_typeがLAYOUT4_FLEX_FILESの場合、lou_bodyフィールドの長さがゼロでなければなりません（[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を参照）。これに対するいくつかの根拠は、同じファイルハンドルを共有するか、同じストレージデバイス上のファイルの複数の読み取り専用コピーを可能にするクラスター化サーバーです。柔軟なファイルレイアウトタイプでは、ファイルハンドルの配列がありますが、それらは使用されているマルチパスに依存しません。メタデータサーバーが同じストレージデバイス上の同じファイルの複数の読み取り専用コピーを提供する場合は、それぞれが異なるff_device_addr4を持つ複数のミラーリングされたインスタンスを提供する必要があります。その後、クライアントは、ffds_fh_versのそれぞれが異なるため、現在のレイアウトセグメントで利用可能なファイルのコピーが複数あることを確認できます。
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.
メタデータサーバーがffda_versions配列をff_device_addr4（セクション4.1を参照）で提供する場合、クライアントは、ffdv_version、ffdv_minorversion、およびffdv_tightly_coupledの指定された組み合わせのいずれかでストレージデバイスにアクセスできるかどうかを判断できます。ただし、GETDEVICEINFOのエラー報告の制限により（[RFC5661]のセクション18.40を参照）、クライアントは、提供されているffdv_versionおよび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_VERS_MISMATCHです。不一致がメジャーバージョン（たとえば、クライアントはNFSv3を使用でき、NFSv4は使用できない）かマイナーバージョン（たとえば、クライアントはNFSv4.1を使用できるがNFSv4.2は使用できない）であるかは関係ありません。エラーは、指定されたすべての組み合わせに対してffdv_versionおよび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_data_serversの要素数
S: number of bytes in a stripe S = W * ffl_stripe_unit
S：ストライプのバイト数S = W * ffl_stripe_unit
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_FILESレイアウトタイプを使用する場合、クライアントはff_ioerr4構造体を使用して、LAYOUTRETURN時にサーバーに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 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を送信して、元のI / O操作を再試行する必要がありますメタデータサーバーへの通常のNFSv4.1 +読み取りまたは書き込み操作による/ Oクライアントは、新しいレイアウトの取得を試み、まずストレージデバイスを使用してI / O操作を再試行し、エラーが続く場合はメタデータサーバー経由でのみI / O操作を再試行する必要があります（SHOULD）。
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).
柔軟なファイルレイアウトタイプには、レイアウトセグメントによって制約されたファイルデータをミラーリングするためのシンプルなモデルがあります。ミラーの各コピーがストレージデバイスに同じように格納されているという前提はありません。たとえば、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.
ミラーリングされたレイアウトセグメントの更新は、クライアント側のミラーリングを介して行われます。このアプローチでは、クライアントは、レイアウトを介して通知されるレイアウトセグメントのすべてのコピーに対して確実に変更を加える責任があります。レイアウトセグメントがストレージデバイスに再シルバー化されている場合、そのミラーリングされたコピーはレイアウトに含まれません。したがって、メタデータサーバーは、クライアントにレイアウトで提示されるまで、そのコピーを更新する必要があります。 FF_FLAGS_WRITE_ONE_MIRRORがffl_flagsに設定されている場合、クライアントはミラーの1つを更新するだけで済みます（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_efficiencyメンバーを介してストレージデバイスに到着した後、各ミラーがどれほど高速であると予想するかをクライアントに通知する場合があります。その値を計算するアルゴリズムはメタデータサーバーの実装に委ねられていますが、その計算に寄与する可能性のある要因には、ストレージデバイスの速度、デバイスで使用可能な物理メモリ、オペレーティングシステムのバージョン、現在の負荷などがあります。
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.
ただし、その計算に含まれるべきではないのは、クライアントとストレージデバイス間の認識されたネットワーク距離です。クライアントは、2つの間の利用可能な異なるネットワークインターフェイスを介したストレージデバイスとの過去のやり取りに基づいてその決定を行うのに適しています。つまり、メタデータサーバーは、指定されたサブネット上に存在しないため、クライアントとストレージデバイス間の一時的な停止について知らない可能性があります。
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_flagsのFF_FLAGS_WRITE_ONE_MIRRORフラグが設定されている場合、クライアントはレイアウトセグメントのコピーの1つを更新するだけで済みます。この場合、ストレージデバイスは、ミラーのいずれかが更新されたときに、ミラーのすべてのコピーが更新されることを確認する必要があります。ミラーの1つを更新するときにストレージデバイスがエラーを受け取った場合、元のWRITEにエラーがあったことをクライアントに通知する必要があります。次に、クライアントはメタデータサーバーに通知する必要があります（セクション8.2.3を参照）。 COMMITに関するクライアントの責任は、セクション8.2.4で説明されています。クライアントは、いずれかのミラーを選択することができ、セクション8.1で説明されているようにffds_efficiencyを使用してこの選択を行うことができます。
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_flagsのFF_FLAGS_WRITE_ONE_MIRRORフラグが設定されていない場合、クライアントは、レイアウトで指定されているレイアウトセグメントのすべてのミラーコピーを更新する必要があります。操作全体を失敗させるには、単一の失敗した更新で十分です。 1つを除いてすべてが正常に更新され、最後のコピーがエラーを提供する場合、クライアントはメタデータサーバーにエラーを通知する必要があります。クライアントは、LAYOUTRETURNまたはLAYOUTERRORのいずれかを使用して、そのストレージデバイスへの更新が失敗したことをメタデータサーバーに通知できます。クライアントがミラーを順次更新している場合は、最初に発生したエラーで停止し、それをメタデータサーバーに報告する必要があります（SHOULD）。クライアントがミラーを並行して更新している場合、更新中に発生したすべてのエラーを報告できるように、すべてのストレージデバイスが応答するまで待機する必要があります（SHOULD）。
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.
クライアントがメタデータサーバーに書き込みエラーを報告すると、メタデータサーバーは、レイアウトからエラーのあるミラーを削除するかどうか、ミラーが一時的なエラーから回復したかどうかなどを判断します。クライアントが新しいレイアウトの場合、メタデータサーバーはレイアウトの内容によって決定を通知します。クライアントは、以前のレイアウトのコンテンツが新しいレイアウトのコンテンツと一致すると想定してはなりません（MUST NOT）。すべてのミラーにコミットされなかった更新がある場合は、それらの更新をすべてのミラーに再送信する必要があります。
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_FLAGS_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.
不安定な書き込みが行われる対応するケースでは、受信ノードはそのような義務はありませんが、更新を非同期で伝播することを選択する場合があります。ただし、COMMITが応答されると、すべてのレプリカは実行された書き込みを反映する必要があり、このデータはすべてのレプリカの安定したストレージにコミットされている必要があります。
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 書き込みがサーバーにフラッシュされるとき（たとえば、open-to-openセマンティクスを実装するため）、COMMITをクライアントが実行して、特定のレプリカの読み取りに関係なく、書き込まれた最新のデータを確実に利用できるようにする必要があります。
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_file4は、レイアウトタイプ固有の情報をサーバーに伝えるために、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;
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;
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;
};
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_layout_typeレイアウトタイプがLAYOUT4_FLEX_FILESで、lr_returntypeがLAYOUTRETURN4_FILEの場合、lrf_body不透明値はff_layoutreturn4で定義されます（9.3項を参照）。これにより、クライアントは、I / Oエラー情報またはレイアウト使用統計をメタデータサーバーに報告できます。データ構造はNFSv4.2で導入された概念に基づいて構築されていますが、効果的な識別共用体（lora_layout_typeとff_layoutreturn4の組み合わせ）により、NFSv4.1メタデータサーバーがデータを利用できるようになります。
<CODE BEGINS>
<コード開始>
/// 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]がdevice_error4を次のように定義していることを思い出してください：
<CODE BEGINS>
<コード開始>
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_errorsは、操作とエラーのタイプを表します。 device_error4の使用については、[RFC7862]のセクション15.6で説明されています。
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エラーをクライアントに報告する場合でも、クライアントはこれらをde_statusとして適切なNFSv4ステータスコードにマッピングする責任があります。同様に、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;
/// };
///
<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.
<CODE ENDS>オペレーションカウントと転送されたバイトの両方がff_io_latency4に保持されます。 ff_layoutupdate4（セクション9.2.2を参照）に見られるように、READおよびWRITE操作は別々に集約されます。 READ操作は、ff_io_latency4 ffl_readに使用されます。書き込み操作とCOMMIT操作の両方がff_io_latency4 ffl_writeに使用されます。 "Requested"カウンターはクライアントが何をしようとしているかを追跡し、 "completed"カウンターは何が行われたかを追跡します。クライアントが、報告された期間の要求された結果と一致する完了した結果のみを報告する必要はありません。
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日午前0時またはゼロ時からの秒数およびナノ秒数として定義されています。 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は累積的であることに注意してください。つまり、操作が送信されるたびにリセットされるわけではありません。同じファイルとレイアウトステートIDに対する2つの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;
/// };
///
<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.
<CODE ENDS> ffl_addrは、クライアントがストレージデバイスで接続されているネットワークアドレスを区別します。マルチパスの場合、ffl_fhandleは、どの読み取り専用コピーが選択されたかを示します。 ffl_readおよびffl_writeは、それぞれREADおよびWRITE操作のレイテンシを伝えます。 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;
/// };
///
<CODE ENDS>
<コード終了>
[RFC7862] defines io_info4 as:
[RFC7862]はio_info4を次のように定義しています：
<CODE BEGINS>
<コード開始>
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統計を報告する「ホット」バイト範囲を識別してもよい（MAY）。 「ホット」と見なされるものの定義や構成メカニズム、および報告されるバイト範囲のサイズは、このドキュメントの範囲外です。クライアントの実装では、適切なデフォルト値と、これらのパラメーターを制御するオプションのランタイム管理インターフェースを提供することをお勧めします。たとえば、クライアントは、デフォルトのバイト範囲の解像度を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_offsetおよびffis_lengthは、範囲の開始オフセットと範囲の長さ（バイト単位）を表します。 ffis_read.ii_count、ffis_read.ii_bytes、ffis_write.ii_count、およびffis_write.ii_bytesは、連続したREADおよびWRITE 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<>;
/// };
///
<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操作が失敗した場合、fflr_ioerr_report <>を使用して、これらのエラーをff_ioerr4型の要素の配列としてメタデータサーバーに報告します。配列の各要素は、ffie_errors.de_deviceidで識別されるデータファイルで発生したエラーを表します。エラーが報告されない場合、fflr_ioerr_report <>配列のサイズはゼロに設定されます。クライアントは、fflr_iostats_report <>を使用して、I / O統計のリストをff_iostats4タイプの要素の配列として報告することもできます（MAY）。配列の各要素は、特定のバイト範囲の統計を表します。バイト範囲はばらばらであることが保証されておらず、繰り返しまたは交差する場合があります。
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を使用してメタデータサーバーと通信する場合、LAYOUTRETURNがメタデータサーバーにエラー情報を送信するのを待つのではなく（セクション9.1を参照）、LAYOUTERRORを使用して（[RFC7862]のセクション15.6を参照）その情報を伝えます。フレキシブルファイルレイアウトタイプの場合、これは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を使用してメタデータサーバーと通信している場合、LAYOUTRETURNがI / O統計をメタデータサーバーに送信するのを待つ代わりに（セクション9.2を参照）、LAYOUTSTATSを使用できます（[RFC7862]のセクション15.7を参照） ）その情報を伝達する。フレキシブルファイルレイアウトタイプの場合、これはLAYOUTSTATS4args.lsa_layoutupdateがffis_layoutupdateと同じ内容でオーバーロードされることを意味します。
The layouthint4 type is defined in the [RFC5661] as follows:
layouthint4タイプは、[RFC5661]で次のように定義されています。
<CODE BEGINS>
<コード開始>
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.
クライアントは、layouthint4構造体を使用して、特定のファイル用に作成するレイアウトのタイプに関するヒントを渡します。 loh_typeレイアウトタイプがLAYOUT4_FLEX_FILESの場合、loh_body不透明値はff_layouthint4タイプによって定義されます。
<CODE BEGINS>
<コード開始>
/// 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;
/// };
///
<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 Recallable Object Types Registry」の許可されるタイプを定義しています。
<CODE BEGINS>
<コード開始>
/// 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;
};
<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
/// };
///
<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_layouts_to_keep柔軟なファイルレイアウトを維持して返す必要があります（SHOULD）。
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 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.1 +のセキュリティプロパティを維持するには、pNFSシステムのコンポーネントの組み合わせが必要です。 pNFS機能は、NFSv4.1 +ファイルシステムプロトコルを、制御プロトコルとデータプロトコルの2つの部分に分割します。このドキュメントの制御プロトコルはNFSであるため、セキュリティプロパティは使用されているNFSのバージョンと同等です。柔軟なファイルレイアウトにより、データプロトコルがメタデータとデータパスにさらに分割されます。メタデータパスのセキュリティプロパティは、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_READまたはLAYOUTIOMODE4_RW）のレイアウトを取得する必要があり、サーバーはこれらの資格情報のアクセス許可とACLを確認します。クライアントが要求されたiomodeを許可されていない場合は、NFS4ERR_ACCESSを返す可能性があります。LAYOUTGET操作が成功すると、クライアントはレイアウトの一部として、要求されたiomodeに対応する指定されたデータファイルへのI / Oアクセスを許可する資格情報のセットを受け取ります。クライアントがローカルユーザーに代わってI / O操作を実行すると、 NFSv4データ委任を持つのと同様に、メタデータサーバーにそれぞれOPENおよびACCESS呼び出しを発行して、ユーザーを認証および承認する必要があります。
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.
レイアウトでのファイルハンドル、合成uid、gidの組み合わせは、メタデータサーバーがデータサーバーへのアクセス制御を実施する方法です。クライアントは、ファイルオブジェクトのファイルハンドルにのみアクセスでき、ディレクトリオブジェクトにはアクセスできません。したがって、レイアウト内のファイルハンドルを指定すると、親ディレクトリのファイルハンドルを推測することはできません。さらに、データファイルの権限では特定の合成uidの読み取り/書き込み権限と合成gidの読み取り権限しか許可されないため、1つのファイルの合成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 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操作を実行します。メタデータサーバーは、ファイルのアクセス許可またはACLを変更する要求を受け取ると、そのファイルのすべてのレイアウトを再呼び出しし（SHOULD）、次に、構成するすべてのデータファイルで以前に配布された資格情報を暗黙的に無効にすることにより、それぞれのファイルの未解決のレイアウトを保持しているクライアントを隔離する必要があります問題のファイル。これは、新しい権限やACLにコミットする前に行う必要があります。新しいレイアウトを要求することにより、クライアントは変更されたアクセス制御メタデータに対してアクセスを再承認します。この場合のレイアウトの呼び出しは、クライアントが隔離された後にクライアントが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 Generic Security Serviceアプリケーションプログラムインターフェイス（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_FLEX_FILES。表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 Recallable Object Types Registry」も導入しました。このドキュメントでは、RCA4_TYPE_MASK_FF_LAYOUT_MINおよびRCA4_TYPE_MASK_FF_LAYOUT_MAXの新しい再呼び出し可能なオブジェクトを定義します（表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 | | |
+------------------------------+-------+--------+-----+-------------+
Table 2: Recallable Object Type Assignments
表2：呼び出し可能なオブジェクトタイプの割り当て
[LEGAL] IETF Trust, "Trust Legal Provisions (TLP)", <https://trustee.ietf.org/trust-legal-provisions.html>.
[法的] IETF Trust、「Trust Legal Provisions（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、「The Kerberos Version 5 Generic Security Service Application Program Interface（GSS-API）Mechanism：Version 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] Eisler、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：Remote Procedure Call Protocol Specification Version 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。、and D. Noveck、Ed。、 "Network File System（NFS）Version 4 Minor Version 1 Protocol"、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。、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、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]ヘインズ、T。、エド。およびD. Noveck、編、「ネットワークファイルシステム（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、「Remote Procedure Call（RPC）Security Version 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。、「Network File System（NFS）Version 4 Minor Version 2 Protocol」、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。、「Requirements for Parallel NFS（pNFS）Layout Types」、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。、編、「Lightweight Directory Access Protocol（LDAP）：Schema for User Applications」、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.
次の個人は、このドキュメントの初期ドラフトバージョンに雑多なコメントを提供しました：マットW.ベンジャミン、アダムエマーソン、J。ブルースフィールズ、およびレフソロモノフ。
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.
次の個人は、このドキュメントの最終ドラフトバージョンにさまざまなコメントを提供しました：Anand Ganesh、Robert Wipfel、Gobikrishnan Sundharraj、Trond Myklebust、Rick Macklem、および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
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、CA 94022アメリカ合衆国
Email: loghyr@gmail.com