[要約] RFC 8434は、Parallel NFS（pNFS）のレイアウトタイプに関する要件を定義しています。その目的は、高速で効率的なファイル共有を実現するために、pNFSのレイアウトタイプの設計と実装に関するガイドラインを提供することです。
Internet Engineering Task Force (IETF) T. Haynes
Request for Comments: 8434 Hammerspace
Updates: 5661 August 2018
Category: Standards Track
ISSN: 2070-1721
Requirements for Parallel NFS (pNFS) Layout Types
Parallel NFS（pNFS）レイアウトタイプの要件
Abstract
概要
This document defines the requirements that individual Parallel NFS (pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661.
このドキュメントでは、RFC 5661で定義されているように、pNFSフレームワーク内で機能するために個々のParallel NFS（pNFS）レイアウトタイプが満たす必要がある要件を定義しています。特にpNFSファイルレイアウトを対象としています。 2つの要件のセットを明確に区別できないことは、新しいレイアウトタイプを指定して評価する人にとって厄介でした。この点で、このドキュメントはRFC 5661を更新します。
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/rfc8434.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8434で入手できます。
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 ....................................................2
2. Definitions .....................................................3
2.1. Use of the Terms "Data Server" and "Storage Device" ........5
2.2. Requirements Language ......................................6
3. The Control Protocol ............................................6
3.1. Control Protocol Requirements ..............................8
3.2. Previously Undocumented Protocol Requirements ..............9
3.3. Editorial Requirements ....................................10
4. Specifications of Original Layout Types ........................11
4.1. File Layout Type ..........................................11
4.2. Block Layout Type .........................................12
4.3. Object Layout Type ........................................13
5. Summary ........................................................14
6. Security Considerations ........................................15
7. IANA Considerations ............................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................16
Acknowledgments ...................................................17
Author's Address ..................................................17
The concept of "layout type" has a central role in the definition and implementation of Parallel NFS (pNFS) (see [RFC5661]). Clients and servers implementing different layout types behave differently in many ways while conforming to the overall pNFS framework defined in [RFC5661] and this document. Layout types may differ as to:
「レイアウトタイプ」の概念は、Parallel NFS（pNFS）の定義と実装において中心的な役割を果たします（[RFC5661]を参照）。異なるレイアウトタイプを実装するクライアントとサーバーは、[RFC5661]とこのドキュメントで定義されている全体的なpNFSフレームワークに準拠しながら、多くの点で異なる動作をします。レイアウトタイプは次の点で異なる場合があります。
o The method used to do I/O operations directed to data storage devices.
o データストレージデバイスへのI / O操作を実行するために使用される方法。
o The requirements for communication between the metadata server (MDS) and the storage devices.
o メタデータサーバー（MDS）とストレージデバイス間の通信の要件。
o The means used to ensure that I/O requests are only processed when the client holds an appropriate layout.
o クライアントが適切なレイアウトを保持している場合にのみI / O要求が処理されるようにするために使用される手段。
o The format and interpretation of nominally opaque data fields in pNFS-related NFSv4.x data structures.
o pNFS関連のNFSv4.xデータ構造における名目上不透明なデータフィールドの形式と解釈。
Each layout type will define the needed details for its usage in the specification for that layout type; layout type specifications are always Standards Track RFCs. Except for the file layout type defined in Section 13 of [RFC5661], existing layout types are defined in their own Standards Track documents, and it is anticipated that new layout types will be defined in similar documents.
各レイアウトタイプは、そのレイアウトタイプの仕様での使用に必要な詳細を定義します。レイアウトタイプの仕様は、常にStandards Track RFCです。 [RFC5661]のセクション13で定義されているファイルレイアウトタイプを除き、既存のレイアウトタイプは独自のStandard Trackドキュメントで定義されており、同様のドキュメントで新しいレイアウトタイプが定義されることが予想されます。
The file layout type was defined in the Network File System (NFS) version 4.1 protocol specification [RFC5661]. The block layout type was defined in [RFC5663], and the object layout type was defined in [RFC5664]. Subsequently, the Small Computer System Interface (SCSI) layout type was defined in [RFC8154].
ファイルレイアウトタイプは、ネットワークファイルシステム（NFS）バージョン4.1プロトコル仕様[RFC5661]で定義されています。ブロックレイアウトタイプは[RFC5663]で定義され、オブジェクトレイアウトタイプは[RFC5664]で定義されました。その後、Small Computer System Interface（SCSI）レイアウトタイプが[RFC8154]で定義されました。
Some implementers have interpreted the text in Sections 12 ("Parallel NFS (pNFS)") and 13 ("NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type") of [RFC5661] as applying only to the file layout type. Because Section 13 was not covered in a separate Standards Track document such as those for both the block and object layout types, there was some confusion as to the responsibilities of both the metadata server and the data servers (DSs) that were laid out in Section 12.
一部の実装者は、[RFC5661]のセクション12（「Parallel NFS（pNFS）」）および13（「pNFSのストレージプロトコルとしてのNFSv4.1：File Layout Type」）のテキストを、ファイルレイアウトタイプにのみ適用すると解釈しました。 。セクション13は、ブロックレイアウトタイプとオブジェクトレイアウトタイプの両方のドキュメントなど、個別のスタンダードトラックドキュメントでカバーされていなかったため、セクションに配置されたメタデータサーバーとデータサーバー（DS）の両方の責任に関して混乱がありました12。
As a consequence, authors of new specifications (see [RFC8435] and [Lustre]) may struggle to meet the requirements to be a pNFS layout type. This document gathers the requirements from all of the original Standards Track documents regarding layout type and then specifies the requirements placed on all layout types independent of the particular type chosen.
結果として、新しい仕様の作成者（[RFC8435]および[Lustre]を参照）は、pNFSレイアウトタイプになるための要件を満たすのに苦労する可能性があります。このドキュメントは、レイアウトタイプに関するすべてのオリジナルのスタンダードトラックドキュメントから要件を収集し、選択された特定のタイプとは関係なく、すべてのレイアウトタイプに適用される要件を指定します。
control communication requirement: 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 both a control protocol and storage protocol.
制御プロトコル：レイアウトタイプの実装がそのレイアウトタイプの制御通信要件を満たすために使用する特定のメカニズム。これは、通常理解されているプロトコルである必要はありません。場合によっては、同じプロトコルを制御プロトコルとストレージプロトコルの両方として使用できます。
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操作を行うために使用するプロトコル。各レイアウトタイプは、ストレージプロトコルのセットを指定します。
loose coupling: when the control protocol is a storage protocol.
疎結合：制御プロトコルがストレージプロトコルの場合。
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ドキュメントに基づくプロトコルのいずれかです。
(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. Note that this usage differs from that in [RFC5661], which applies the term in some cases even when other sorts of protocols are being used. Depending on the layout, there might be one or more data servers over which the data is striped. While the metadata server is strictly accessed over the NFSv4.1 protocol, the data server could be accessed via any file access protocol that meets the pNFS requirements.
データサーバー（DS）：ファイルベースのプロトコルを介してファイルシステムオブジェクトにアクセスしたときにファイルのデータを提供するpNFSサーバー。この使用法は、他の種類のプロトコルが使用されている場合でも一部のケースでこの用語を適用する[RFC5661]の使用法とは異なることに注意してください。レイアウトによっては、データがストライプ化される1つ以上のデータサーバーが存在する場合があります。メタデータサーバーはNFSv4.1プロトコルを介して厳密にアクセスされますが、データサーバーはpNFS要件を満たす任意のファイルアクセスプロトコルを介してアクセスできます。
See Section 2.1 for a comparison of this term and "storage device".
この用語と「ストレージデバイス」の比較については、セクション2.1を参照してください。
storage device: the target to which clients may direct I/O requests when they hold an appropriate layout. Note that each data server is a storage device but that some storage device are not data servers. See Section 2.1 for further discussion.
ストレージデバイス：クライアントが適切なレイアウトを保持している場合にクライアントがI / O要求を送信できるターゲット。各データサーバーはストレージデバイスですが、一部のストレージデバイスはデータサーバーではないことに注意してください。詳細については、セクション2.1を参照してください。
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を処理できないようにするプロセス。
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が含まれます。
The bulk of the contents of the layout are defined in [RFC5661] as nominally opaque, but individual layout types are responsible for specifying the format of the layout data.
レイアウトのコンテンツの大部分は、名目上不透明であると[RFC5661]で定義されていますが、個々のレイアウトタイプは、レイアウトデータのフォーマットを指定する責任があります。
layout iomode: a grant of either read-only or read/write I/O to the client.
レイアウトiomode：クライアントへの読み取り専用または読み取り/書き込みI / Oの許可。
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.
レイアウトタイプ：データへのアクセスに使用されるストレージプロトコルと、基になるストレージデバイスにファイルデータをレイアウトするために使用される集約方式の両方の仕様。
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.
レイアウトの取り消し：メタデータサーバーによる特定のレイアウトの無効化。失効が発生すると、メタデータサーバーは失効したレイアウトへの参照を有効として受け入れず、ストレージデバイスはレイアウトに基づくクライアントアクセスを受け入れません。
(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操作を実行する役割もあります。
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は、開いているファイル、バイト範囲ロック、委任、またはレイアウトに関連する状態を指定できます。
In [RFC5661], the terms "data server" and "storage device" are used somewhat inconsistently:
[RFC5661]では、「データサーバー」と「ストレージデバイス」という用語の使用に一貫性がありません。
o In Section 12, where pNFS in general is discussed, the term "storage device" is used.
o セクション12では、pNFS全般について説明しますが、「ストレージデバイス」という用語を使用します。
o In Section 13, where the file layout type is discussed, the term "data server" is used.
o セクション13では、ファイルレイアウトタイプについて説明し、「データサーバー」という用語を使用しています。
o In other sections, the term "data server" is used, even in contexts where the storage access type is not NFSv4.1 or any other file access protocol.
o 他のセクションでは、ストレージアクセスタイプがNFSv4.1またはその他のファイルアクセスプロトコルではないコンテキストでも、「データサーバー」という用語が使用されます。
As this document deals with pNFS in general, it uses the more generic term "storage device" in preference to "data server". The term "data server" is used only in contexts in which a file server is used as a storage device. Note that every data server is a storage device, but storage devices that use protocols that are not file access protocols (such as NFS) are not data servers.
このドキュメントでは一般にpNFSを扱っているため、「データサーバー」よりも「ストレージデバイス」というより一般的な用語を使用しています。 「データサーバー」という用語は、ファイルサーバーがストレージデバイスとして使用される状況でのみ使用されます。すべてのデータサーバーはストレージデバイスですが、ファイルアクセスプロトコルではないプロトコル（NFSなど）を使用するストレージデバイスはデータサーバーではないことに注意してください。
Since a given storage device may support multiple layout types, a given device can potentially act as a data server for some set of storage protocols while simultaneously acting as a storage device for others.
特定のストレージデバイスが複数のレイアウトタイプをサポートする場合があるため、特定のデバイスは、ストレージプロトコルのセットのデータサーバーとして機能すると同時に、他のデバイスのストレージデバイスとしても機能する可能性があります。
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]で説明されているように解釈されます。
This document differs from most Standards Track documents in that it specifies requirements for those defining future layout types rather than defining the requirements for implementations directly. This document makes clear whether:
このドキュメントは、実装の要件を直接定義するのではなく、将来のレイアウトタイプを定義するものの要件を指定するという点で、ほとんどのStandards Trackドキュメントとは異なります。このドキュメントでは、次のことを明らかにしています。
(1) any particular requirement applies to implementations.
（1）特定の要件が実装に適用されます。
(2) any particular requirement applies to those defining layout types.
（2）特定の要件は、レイアウトタイプを定義するものに適用されます。
(3) the requirement is a general requirement that implementations need to conform to, with the specific means left to layout type definitions type to specify.
（3）要件は、実装が準拠する必要のある一般的な要件であり、特定の手段は、レイアウトタイプ定義タイプの指定に任されています。
A layout type has to meet the requirements that apply to the interaction between the metadata server and the storage device such that they present to the client a consistent view of stored data and locking state (Section 12.2.6 of [RFC5661]). Particular implementations may satisfy these requirements in any manner they choose, and the mechanism chosen need not be described as a protocol. Specifications defining layout types need to clearly show how implementations can meet the requirements discussed below, especially with respect to those that have security implications. In addition, such specifications may find it necessary to impose requirements on implementations of the layout type to ensure appropriate interoperability.
レイアウトタイプは、メタデータサーバーとストレージデバイス間の相互作用に適用される要件を満たし、保存されたデータとロック状態の一貫したビューをクライアントに提供する必要があります（[RFC5661]のセクション12.2.6）。特定の実装は、これらの要件を選択した任意の方法で満たすことができ、選択したメカニズムをプロトコルとして説明する必要はありません。レイアウトタイプを定義する仕様では、特にセキュリティに影響する要件に関して、実装が以下で説明する要件を満たす方法を明確に示す必要があります。さらに、このような仕様では、適切な相互運用性を確保するために、レイアウトタイプの実装に要件を課す必要がある場合があります。
In some cases, there may be no control protocol other than the storage protocol. This is often described as using a "loosely coupled" model. In such cases, the assumption is that the metadata server, storage devices, and client may be changed independently and that the implementation requirements in the layout type specification need to ensure this degree of interoperability. This model is used in the block and object layout type specification.
場合によっては、ストレージプロトコル以外の制御プロトコルがないことがあります。これは、「疎結合」モデルを使用すると説明されることがよくあります。そのような場合、メタデータサーバー、ストレージデバイス、およびクライアントは個別に変更される可能性があり、レイアウトタイプ仕様の実装要件はこの程度の相互運用性を確保する必要があると想定されます。このモデルは、ブロックおよびオブジェクトのレイアウトタイプの仕様で使用されます。
In other cases, it is assumed that there will be a purpose-built control protocol that may be different for different implementations of the metadata server and data server. The assumption here is that the metadata server and data servers are designed and implemented as a unit and interoperability needs to be assured between clients and metadata-data server pairs, developed independently. This is the model used for the file layout.
他の場合では、メタデータサーバーとデータサーバーの実装によって異なる可能性のある専用の制御プロトコルがあると想定されます。ここでの前提は、メタデータサーバーとデータサーバーが1つのユニットとして設計および実装されており、独立して開発されたクライアントとメタデータデータサーバーのペアの間で相互運用性を保証する必要があることです。これは、ファイルレイアウトに使用されるモデルです。
Another possibility is for the definition of a control protocol to be specified in a Standards Track document. There are two subcases to consider:
もう1つの可能性は、Standards Trackドキュメントで指定される制御プロトコルの定義です。考慮すべき2つのサブケースがあります。
o A new layout type includes a definition of a particular control protocol whose use is obligatory for metadata servers and storage devices implementing the layout type. In this case, the interoperability model is similar to the first case above, and the defining document should assure interoperability among metadata servers, storage devices, and clients developed independently.
o 新しいレイアウトタイプには、特定の制御プロトコルの定義が含まれており、その使用は、レイアウトタイプを実装するメタデータサーバーおよびストレージデバイスに必須です。この場合、相互運用性モデルは上記の最初のケースと同様であり、定義するドキュメントは、メタデータサーバー、ストレージデバイス、および独立して開発されたクライアント間の相互運用性を保証する必要があります。
o A control protocol is defined in a Standards Track document that meets the control protocol requirements for one of the existing layout types. In this case, the new document's job is to assure interoperability between metadata servers and storage devices developed separately. The existing definition document for the selected layout type retains the function of assuring interoperability between clients and a given collection of metadata servers and storage devices. In this context, implementations that implement the new protocol are treated in the same way as those that use an internal control protocol or a functional equivalent.
o 制御プロトコルは、既存のレイアウトタイプのいずれかの制御プロトコル要件を満たすStandards Trackドキュメントで定義されています。この場合、新しいドキュメントの役割は、個別に開発されたメタデータサーバーとストレージデバイス間の相互運用性を保証することです。選択したレイアウトタイプの既存の定義ドキュメントは、クライアントとメタデータサーバーおよびストレージデバイスの特定のコレクションとの間の相互運用性を保証する機能を保持しています。このコンテキストでは、新しいプロトコルを実装する実装は、内部制御プロトコルまたは同等の機能を使用する実装と同じように扱われます。
An example of this last case is the SCSI layout type [RFC8154], which extends the block layout type. The block layout type had a requirement for fencing of clients but did not present a way for the control protocol (in this case, the SCSI storage protocol) to fence the client. The SCSI layout type remedies that in [RFC8154] and, in effect, has a tightly coupled model.
この最後のケースの例は、ブロックレイアウトタイプを拡張するSCSIレイアウトタイプ[RFC8154]です。ブロックレイアウトタイプにはクライアントのフェンシングが必要でしたが、制御プロトコル（この場合はSCSIストレージプロトコル）がクライアントをフェンスする方法がありませんでした。 SCSIレイアウトタイプは、[RFC8154]で修正され、事実上、密結合モデルを備えています。
The requirements of interactions between the metadata server and the storage devices are:
メタデータサーバーとストレージデバイス間の相互作用の要件は次のとおりです。
(1) The metadata server MUST be able to service the client's I/O requests if the client decides to make such requests to the metadata server instead of to the storage device. The metadata server must be able to retrieve the data from the constituent storage devices and present it back to the client. A corollary to this is that even though the metadata server has successfully given the client a layout, the client MAY still send I/O requests to the metadata server.
（1）クライアントがストレージデバイスではなくメタデータサーバーにそのような要求を行うことを決定した場合、メタデータサーバーはクライアントのI / O要求を処理できる必要があります。メタデータサーバーは、構成要素のストレージデバイスからデータを取得して、クライアントに提示できる必要があります。これの当然の結果は、メタデータサーバーがクライアントにレイアウトを正常に与えたとしても、クライアントはI / O要求をメタデータサーバーに送信してもよい（MAY）ことです。
(2) The metadata server MUST be able to restrict access to a file on the storage devices when it revokes a layout. The metadata server typically would revoke a layout whenever a client fails to respond to a recall or a client's lease is expired due to non-renewal. It might also revoke the layout as a means of enforcing a change in locking state or access permissions that the storage device cannot directly enforce.
（2）メタデータサーバーは、レイアウトを取り消すときに、ストレージデバイス上のファイルへのアクセスを制限できる必要があります。メタデータサーバーは通常、クライアントがリコールに応答できない場合、または更新されていないためにクライアントのリースが期限切れになる場合は常にレイアウトを取り消します。また、ストレージデバイスが直接適用できないロック状態またはアクセス許可の変更を強制する手段として、レイアウトを取り消す場合もあります。
Effective revocation may require client cooperation in using a particular stateid (file layout) or principal (e.g., flexible file layout) when performing I/O.
効果的な取り消しには、I / Oの実行時に特定の状態ID（ファイルレイアウト）またはプリンシパル（柔軟なファイルレイアウトなど）を使用する際にクライアントの協力が必要になる場合があります。
In contrast, there is no requirement to restrict access to a file on the storage devices when a layout is recalled. It is only after the metadata server determines that the client is not gracefully returning the layout and starts the revocation that this requirement is enforced.
対照的に、レイアウトが呼び出されたときにストレージデバイス上のファイルへのアクセスを制限する必要はありません。この要件が適用されるのは、メタデータサーバーが、クライアントがレイアウトを適切に返しておらず、失効を開始していないと判断した場合のみです。
(3) A pNFS implementation MUST NOT allow the violation of NFSv4.1's access controls: Access Control Lists (ACLs) and file open modes. Section 12.9 of [RFC5661] specifically lays this burden on the combination of clients, storage devices, and the metadata server. However, the specification of the individual layout type might create requirements as to how this is to be done. This may include a possible requirement for the metadata server to update the storage device so that it can enforce security.
（3）pNFS実装は、NFSv4.1のアクセス制御（アクセス制御リスト（ACL）およびファイルオープンモード）の違反を許可してはなりません（MUST NOT）。 [RFC5661]のセクション12.9は、この負担をクライアント、ストレージデバイス、メタデータサーバーの組み合わせに具体的に課しています。ただし、個々のレイアウトタイプを指定すると、これがどのように行われるかに関する要件が作成される場合があります。これには、メタデータサーバーがセキュリティを強化できるようにストレージデバイスを更新するための要件が含まれる場合があります。
The file layout requires the storage device to enforce access whereas the flexible file layout requires both the storage device and the client to enforce security.
ファイルレイアウトにはアクセスを強制するストレージデバイスが必要ですが、柔軟なファイルレイアウトにはセキュリティを強制するストレージデバイスとクライアントの両方が必要です。
(4) Interactions between locking and I/O operations MUST obey existing semantic restrictions. In particular, if an I/O operation would be invalid when directed at the metadata server, it is not to be allowed when performed on the storage device.
（4）ロック操作とI / O操作の間の相互作用は、既存のセマンティック制限に従う必要があります。特に、メタデータサーバーに指示されたときにI / O操作が無効になる場合、ストレージデバイスで実行されたときに許可されません。
For the block and SCSI layouts, as the storage device is not able to reject the I/O operation, the client is responsible for enforcing this requirement.
ブロックレイアウトとSCSIレイアウトの場合、ストレージデバイスはI / O操作を拒否できないため、この要件を強制するのはクライアントの責任です。
(5) Any disagreement between the metadata server and the data server as to the value of attributes such as modify time, the change attribute, and the EOF position MUST be of limited duration with clear means of resolution of any discrepancies being provided. Note the following:
（5）変更時間、変更属性、EOF位置などの属性の値に関するメタデータサーバーとデータサーバーの間の不一致は、提供されている矛盾を解決する明確な手段を備え、期間が限定されている必要があります。次の点に注意してください。
(a) Discrepancies need not be resolved unless any client has accessed the file in question via the metadata server, typically by performing a GETATTR.
（a）通常はGETATTRを実行して、メタデータサーバー経由で問題のファイルにクライアントがアクセスしていない限り、不一致を解決する必要はありません。
(b) A particular storage device might be striped, and as such, its local view of the EOF position does not match the global EOF position.
（b）特定のストレージデバイスがストライプ化されている可能性があるため、EOF位置のローカルビューがグローバルEOF位置と一致しません。
(c) Both clock skew and network delay can lead to the metadata server and the storage device having different values of the time attributes. As long as those differences can be accounted for in what is presented to the client in a GETATTR, then no violation results.
（c）クロックスキューとネットワーク遅延の両方により、メタデータサーバーとストレージデバイスの時間属性の値が異なる可能性があります。 GETATTRでクライアントに提示されるものでこれらの違いを説明できる限り、違反は発生しません。
(d) A LAYOUTCOMMIT requires that changes in attributes resulting from operations on the storage device need to be reflected in the metadata server by the completion of the operation.
（d）LAYOUTCOMMITでは、ストレージデバイスでの操作に起因する属性の変更を、操作の完了までにメタデータサーバーに反映する必要があります。
These requirements may be satisfied in different ways by different layout types. As an example, while the file layout type uses the stateid to fence off the client, there is no requirement that other layout types use this stateid approach.
これらの要件は、レイアウトの種類によって異なる方法で満たされる場合があります。例として、ファイルレイアウトタイプはstateidを使用してクライアントを隔離しますが、他のレイアウトタイプがこのstateidアプローチを使用する必要はありません。
Each new Standards Track document for a layout type MUST address how the client, metadata server, and storage devices are to interact to meet these requirements.
レイアウトタイプの新しいStandards Trackドキュメントはそれぞれ、これらの要件を満たすためにクライアント、メタデータサーバー、およびストレージデバイスがどのように相互作用するかに対処する必要があります。
While not explicitly stated as requirements in Section 12 of [RFC5661], the existing layout types do have more requirements that they need to enforce.
[RFC5661]のセクション12で要件として明示的に述べられていませんが、既存のレイアウトタイプには、適用する必要があるより多くの要件があります。
The client has these obligations when making I/O requests to the storage devices:
ストレージデバイスにI / O要求を行う場合、クライアントには次の義務があります。
(1) Clients MUST NOT perform I/O to the storage device if they do not have layouts for the files in question.
（1）クライアントは、問題のファイルのレイアウトがない場合、ストレージデバイスへのI / Oを実行してはなりません。
(2) Clients MUST NOT perform I/O operations outside of the specified ranges in the layout segment.
（2）クライアントは、レイアウトセグメントで指定された範囲外のI / O操作を実行してはなりません。
(3) Clients MUST NOT perform I/O operations that would be inconsistent with the iomode specified in the layout segments it holds.
（3）クライアントは、保持するレイアウトセグメントで指定されたiomodeと矛盾するI / O操作を実行してはなりません（MUST NOT）。
Under the file layout type, the storage devices are able to reject any request made not conforming to these requirements. This may not be possible for other known layout types, which puts the burden of enforcing such violations solely on the client. For these layout types:
ファイルレイアウトタイプでは、ストレージデバイスはこれらの要件に準拠していない要求を拒否できます。これは、他の既知のレイアウトタイプでは不可能であり、そのような違反をクライアントにのみ適用するという負担がかかります。これらのレイアウトタイプの場合：
(1) The metadata server MAY use fencing operations to the storage devices to enforce layout revocation against the client.
（1）メタデータサーバーは、ストレージデバイスへのフェンシング操作を使用して、クライアントに対してレイアウトの取り消しを実施できます（MAY）。
(2) The metadata server MUST allow the clients to perform data I/O against it, even if it has already granted the client a layout. A layout type might discourage such I/O, but it cannot forbid it.
（2）メタデータサーバーは、すでにクライアントにレイアウトを許可している場合でも、クライアントがデータI / Oを実行できるようにする必要があります。レイアウトタイプはそのようなI / Oを思いとどまらせるかもしれませんが、それを禁止することはできません。
(3) The metadata server MUST be able to do storage allocation, whether that is to create, delete, extend, or truncate files.
（3）メタデータサーバーは、ファイルの作成、削除、拡張、または切り捨てのいずれであっても、ストレージの割り当てを実行できる必要があります。
The means to address these requirements will vary with the layout type. A control protocol will be used to effect these; the control protocol could be a purpose-built one, one identical to the storage protocol, or a new Standards Track control protocol.
これらの要件に対処する方法は、レイアウトタイプによって異なります。これらに影響を与えるために制御プロトコルが使用されます。制御プロトコルは、専用のもの、ストレージプロトコルと同じもの、または新しいStandards Track制御プロトコルにすることができます。
This section discusses how the protocol requirements discussed above need to be addressed in documents specifying a new layout type. Depending on the interoperability model for the layout type in question, this may involve the imposition of layout-type-specific requirements that ensure appropriate interoperability of pNFS components that are developed separately.
このセクションでは、新しいレイアウトタイプを指定するドキュメントで、上記のプロトコル要件に対処する方法について説明します。問題のレイアウトタイプの相互運用性モデルによっては、これには、個別に開発されるpNFSコンポーネントの適切な相互運用性を保証するレイアウトタイプ固有の要件が課せられる場合があります。
The specification of the layout type needs to make clear how the client, metadata server, and storage device act together to meet the protocol requirements discussed previously. If the document does not impose implementation requirements sufficient to ensure that these semantic requirements are met, it is not appropriate for publication as an RFC from the IETF stream.
レイアウトタイプの仕様では、クライアント、メタデータサーバー、およびストレージデバイスが連携して、前述のプロトコル要件を満たす方法を明確にする必要があります。ドキュメントがこれらのセマンティック要件が満たされることを保証するのに十分な実装要件を課していない場合、IETFストリームからのRFCとしての公開には適していません。
Some examples include:
いくつかの例は次のとおりです。
o If the metadata server does not have a means to invalidate a stateid issued to the storage device to keep a particular client from accessing a specific file, then the layout type specification has to document how the metadata server is going to fence the client from access to the file on that storage device.
o メタデータサーバーに、特定のクライアントが特定のファイルにアクセスできないようにするためにストレージデバイスに発行された状態IDを無効にする手段がない場合、レイアウトタイプの仕様は、メタデータサーバーがクライアントにアクセスできないようにする方法を文書化する必要があります。そのストレージデバイス上のファイル。
o If the metadata server implements mandatory byte-range locking when accessed directly by the client, then the layout type specification must require that this also be done when data is read or written using the designated storage protocol.
o メタデータサーバーがクライアントから直接アクセスされたときに必須のバイト範囲ロックを実装する場合、レイアウトタイプの仕様では、指定されたストレージプロトコルを使用してデータの読み取りまたは書き込みを行うときにもこれを行う必要があります。
This section discusses how the original layout types interact with Section 12 of [RFC5661], which enumerates the requirements of pNFS layout type specifications. It is not normative with regards to the file layout type presented in Section 13 of [RFC5661], the block layout type [RFC5663], and the object layout type [RFC5664]. These are discussed here only to illuminate the updates Section 3 of this document makes to Section 12 of [RFC5661].
このセクションでは、元のレイアウトタイプが[RFC5661]のセクション12とどのように相互作用するかについて説明します。これには、pNFSレイアウトタイプ仕様の要件が列挙されています。 [RFC5661]のセクション13に示されているファイルレイアウトタイプ、ブロックレイアウトタイプ[RFC5663]、およびオブジェクトレイアウトタイプ[RFC5664]に関する規定ではありません。これらは、このドキュメントのセクション3が[RFC5661]のセクション12に対して行った更新を明らかにするためだけに、ここで説明されています。
Because the storage protocol is a subset of NFSv4.1, the semantics of the file layout type comes closest to the semantics of NFSv4.1 in the absence of pNFS. In particular, the stateid and principal used for I/O MUST have the same effect and be subject to the same validation on a data server as it would have if the I/O were being performed on the metadata server itself. The same set of validations are applied whether or not pNFS is in effect.
ストレージプロトコルはNFSv4.1のサブセットであるため、pNFSがない場合、ファイルレイアウトタイプのセマンティクスはNFSv4.1のセマンティクスに最も近くなります。特に、I / Oに使用される状態IDとプリンシパルは、I / Oがメタデータサーバー自体で実行された場合と同じ効果を持ち、データサーバーで同じ検証を受ける必要があります。 pNFSが有効かどうかに関係なく、同じ検証セットが適用されます。
While for most implementations, the storage devices can do the following validations that are each presented as a "SHOULD" and not a "MUST" in [RFC5661]:
ほとんどの実装では、ストレージデバイスは、[RFC5661]で「必須」ではなく「必須」として提示される次の検証を実行できます。
(1) client holds a valid layout,
（1）クライアントが有効なレイアウトを保持している、
(2) client I/O matches the layout iomode, and
（2）クライアントI / Oがレイアウトiomodeと一致している。
(3) client does not go out of the byte ranges, Actually, the first point is presented in [RFC5661] as both:
（3）クライアントはバイト範囲を出ません。実際、最初のポイントは両方として[RFC5661]に示されています：
"MUST": in Section 13.6
「必須」：セクション13.6
As described in Section 12.5.1, a client MUST NOT send an I/O to a data server for which it does not hold a valid layout; the data server MUST reject such an I/O.
12.5.1項で説明したように、クライアントは、有効なレイアウトを保持していないデータサーバーにI / Oを送信してはなりません（MUST NOT）。データサーバーは、そのようなI / Oを拒否する必要があります。
"SHOULD": in Section 13.8
"SHOULD"：セクション13.8
The iomode need not be checked by the data servers when clients perform I/O. However, the data servers SHOULD still validate that the client holds a valid layout and return an error if the client does not.
クライアントがI / Oを実行するときに、データサーバーがiomodeをチェックする必要はありません。ただし、データサーバーは、クライアントが有効なレイアウトを保持していることを検証し、クライアントが保持していない場合はエラーを返す必要があります（SHOULD）。
It should be noted that it is just these layout-specific checks that are optional, not the normal file access semantics. The storage devices MUST make all of the required access checks on each READ or WRITE I/O as determined by the NFSv4.1 protocol. If the metadata server would deny a READ or WRITE operation on a file due to its ACL, mode attribute, open access mode, open deny mode, mandatory byte-range locking state, or any other attributes and state, the storage device MUST also deny the READ or WRITE operation. Also, while the NFSv4.1 protocol does not mandate export access checks based on the client's IP address, if the metadata server implements such a policy, then that counts as such state as outlined above.
オプションであるのは、これらのレイアウト固有のチェックであり、通常のファイルアクセスセマンティクスではないことに注意してください。ストレージデバイスは、NFSv4.1プロトコルによって決定されるように、各READまたはWRITE I / Oで必要なすべてのアクセスチェックを行う必要があります。メタデータサーバーが、ACL、モード属性、オープンアクセスモード、オープン拒否モード、必須のバイト範囲ロック状態、またはその他の属性と状態のために、ファイルの読み取りまたは書き込み操作を拒否する場合、ストレージデバイスも拒否する必要があります。 READまたはWRITE操作。また、NFSv4.1プロトコルはクライアントのIPアドレスに基づくエクスポートアクセスチェックを義務付けていませんが、メタデータサーバーがそのようなポリシーを実装している場合は、上記で概説したような状態としてカウントされます。
The data filehandle provided by the PUTFH operation to the data server provides sufficient context to enable the data server to ensure that the client has a valid layout for the I/O being performed for the subsequent READ or WRITE operation in the compound.
PUTFH操作によってデータサーバーに提供されるデータファイルハンドルは、データサーバーがコンパウンドの後続のREADまたはWRITE操作で実行されるI / Oの有効なレイアウトを確保できるようにするために十分なコンテキストを提供します。
Finally, the data server can check the stateid presented in the READ or WRITE operation to see if that stateid has been rejected by the metadata server; if so, the data server will cause the I/O to be fenced. Whilst it might just be the open owner or lock owner on that client being fenced, the client should take the NFS4ERR_BAD_STATEID error code to mean it has been fenced from the file and contact the metadata server.
最後に、データサーバーは、READまたはWRITE操作で提示された状態IDをチェックして、その状態IDがメタデータサーバーによって拒否されたかどうかを確認できます。その場合、データサーバーはI / Oを隔離します。フェンスされているクライアントのオープンオーナーまたはロックオーナーである可能性がありますが、クライアントはNFS4ERR_BAD_STATEIDエラーコードを取得して、ファイルからフェンスされていることを示し、メタデータサーバーに連絡する必要があります。
With the block layout type, the storage devices are generally not able to enforce file-based security. Typically, storage area network (SAN) disk arrays and SAN protocols provide coarse-grained access control mechanisms (e.g., Logical Unit Number (LUN) mapping and/or masking), with a target granularity of disks rather than individual blocks and a source granularity of individual hosts rather than of users or owners. Access to block storage is logically at a lower layer of the I/O stack than NFSv4. Since NFSv4 security is not directly applicable to protocols that access such storage directly, Section 2.1 of [RFC5663] specifies that:
ブロックレイアウトタイプでは、ストレージデバイスは通常、ファイルベースのセキュリティを適用できません。通常、ストレージエリアネットワーク（SAN）ディスクアレイとSANプロトコルは、個々のブロックとソースの細分性ではなく、ディスクのターゲット細分性を備えた、大まかなアクセス制御メカニズム（論理ユニット番号（LUN）マッピングやマスキングなど）を提供します。ユーザーや所有者ではなく、個々のホストの。ブロックストレージへのアクセスは、論理的には、NFSv4よりもI / Oスタックの下位層にあります。 NFSv4セキュリティは、このようなストレージに直接アクセスするプロトコルには直接適用できないため、[RFC5663]のセクション2.1は次のように規定しています。
in environments where pNFS clients cannot be trusted to enforce such policies, pNFS block layout types SHOULD NOT be used.
そのようなポリシーを実施するためにpNFSクライアントを信頼できない環境では、pNFSブロックレイアウトタイプを使用しないでください。
Due to these granularity issues, the security burden has been shifted from the storage devices to the client. Those deploying implementations of this layout type need to be sure that the client implementation can be trusted. This is not a new sort of requirement in the context of SAN protocols. In such environments, the client is expected to provide block-based protection.
これらの細分性の問題により、セキュリティの負担はストレージデバイスからクライアントに移されました。このレイアウトタイプの配置実装では、クライアント実装が信頼できることを確認する必要があります。これは、SANプロトコルのコンテキストにおける新しい種類の要件ではありません。このような環境では、クライアントはブロックベースの保護を提供することが期待されています。
This shift of the burden also extends to locks and layouts. The storage devices are not able to enforce any of these, and the burden is pushed to the client to make the appropriate checks before sending I/O to the storage devices. For example, the server may use a layout iomode only allowing reading to enforce a mandatory read-only lock. In such cases, the client has to support that use by not sending WRITEs to the storage devices. The fundamental issue here is that the storage device is treated by this layout type in the same fashion as a local disk device. Once the client has access to the storage device, it is able to perform both READ and WRITE I/O to the entire storage device. The byte ranges in the layout, any locks, the layout iomode, etc., can only be enforced by the client. Therefore, the client is required to provide that enforcement.
この負担のシフトは、ロックとレイアウトにも適用されます。ストレージデバイスはこれらを強制することができず、ストレージデバイスにI / Oを送信する前に、適切なチェックを行うためにクライアントに負担がかかります。たとえば、サーバーはレイアウトiomodeのみを使用して、読み取りのみを許可し、必須の読み取り専用ロックを適用することができます。このような場合、クライアントはストレージデバイスにWRITEを送信しないことでその使用をサポートする必要があります。ここでの基本的な問題は、ストレージデバイスがローカルディスクデバイスと同じ方法でこのレイアウトタイプによって処理されることです。クライアントがストレージデバイスにアクセスすると、ストレージデバイス全体に対して読み取りと書き込みの両方のI / Oを実行できます。レイアウト、ロック、レイアウトiomodeなどのバイト範囲は、クライアントのみが適用できます。したがって、クライアントはその強制を提供する必要があります。
In the context of fencing off of the client upon revocation of a layout, these limitations come into play again, i.e., the granularity of the fencing can only be at the level of the host and logical unit. Thus, if one of a client's layouts is revoked by the server, it will effectively revoke all of the client's layouts for files located on the storage units comprising the logical volume. This may extend to the client's layouts for files in other file systems. Clients need to be prepared for such revocations and reacquire layouts as needed.
レイアウトの取り消し時にクライアントからフェンシングを行う場合、これらの制限が再び有効になります。つまり、フェンシングの細分性は、ホストと論理ユニットのレベルでのみ可能です。したがって、クライアントのレイアウトの1つがサーバーによって取り消されると、論理ボリュームを構成するストレージユニットにあるファイルのクライアントのレイアウトのすべてが事実上取り消されます。これは、他のファイルシステムのファイルのクライアントのレイアウトにまで及ぶ可能性があります。クライアントは、このような失効に備えて、必要に応じてレイアウトを再取得する必要があります。
With the object layout type, security checks occur during the allocation of the layout. The client will typically ask for layouts covering all of the file and may do so for either READ or READ/WRITE. This enables it to do subsequent I/O operations without the need to obtain layouts for specific byte ranges. At that time, the metadata server should verify permissions against the layout iomode, the file mode bits or ACLs, etc. As the client may be acting for multiple 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.
オブジェクトレイアウトタイプでは、レイアウトの割り当て中にセキュリティチェックが行われます。クライアントは通常、すべてのファイルをカバーするレイアウトを要求し、READまたはREAD / WRITEのいずれかを要求します。これにより、特定のバイト範囲のレイアウトを取得する必要なく、後続のI / O操作を実行できます。そのとき、メタデータサーバーは、レイアウトiomode、ファイルモードビットまたはACLなどに対する権限を確認する必要があります。クライアントは複数のローカルユーザーに対して機能している可能性があるため、それぞれにOPENおよびACCESS呼び出しを発行してユーザーを認証および承認する必要がありますメタデータサーバー。NFSv4データ委任と同様です。
Upon successful authorization, the client receives within the layout a set of object capabilities allowing it I/O access to the specified objects corresponding to the requested iomode. These capabilities are used to enforce access control and locking semantics at the storage devices. Whenever one of the following occurs on the metadata server, then the metadata server MUST change the capability version attribute on all objects comprising the file in order to invalidate any outstanding capabilities before committing to one of these changes:
承認が成功すると、クライアントはレイアウト内でオブジェクト機能のセットを受け取り、要求されたiomodeに対応する指定されたオブジェクトへのI / Oアクセスを許可します。これらの機能は、ストレージデバイスでアクセス制御とロックセマンティクスを適用するために使用されます。メタデータサーバーで次のいずれかが発生すると、メタデータサーバーはファイルを構成するすべてのオブジェクトの機能バージョン属性を変更して、未処理の機能を無効にしてから、これらの変更のいずれかをコミットする必要があります。
o the permissions on the object change,
o オブジェクトの権限の変更、
o a conflicting mandatory byte-range lock is granted, or
o 競合する必須バイト範囲ロックが許可されている、または
o a layout is revoked and reassigned to another client.
o レイアウトが取り消され、別のクライアントに再割り当てされます。
When the metadata server wishes to fence off a client to a particular object, then it can use the above approach to invalidate the capability attribute on the given object. The client can be informed via the storage device that the capability has been rejected and is allowed to fetch a refreshed set of capabilities, i.e., reacquire the layout.
メタデータサーバーがクライアントを特定のオブジェクトに隔離する場合、上記のアプローチを使用して、指定されたオブジェクトの機能属性を無効にすることができます。クライアントは、ストレージデバイスを介して機能が拒否されたことを通知され、更新された機能のセットをフェッチする、つまりレイアウトを再取得することができます。
In the three original layout types, the burden of enforcing the security of NFSv4.1 can fall to either the storage devices (files), the client (blocks), or the metadata server (objects). Such choices are conditioned by the native capabilities of the storage devices -- if a control protocol can be implemented, then the burden can be shifted primarily to the storage devices.
元の3つのレイアウトタイプでは、NFSv4.1のセキュリティを適用する負担は、ストレージデバイス（ファイル）、クライアント（ブロック）、またはメタデータサーバー（オブジェクト）のいずれかになります。このような選択は、ストレージデバイスのネイティブ機能によって条件付けられます。制御プロトコルを実装できる場合、主にストレージデバイスに負担を移すことができます。
In the context of this document, we treat the control protocol as a set of requirements. As new layout types are published, the defining documents MUST address:
このドキュメントのコンテキストでは、制御プロトコルを一連の要件として扱います。新しいレイアウトタイプが公開されると、定義ドキュメントは以下に対処する必要があります。
(1) The fencing of clients after a layout is revoked.
（1）レイアウトが取り消された後のクライアントのフェンシング。
(2) The security implications of the native capabilities of the storage devices with respect to the requirements of the NFSv4.1 security model.
（2）NFSv4.1セキュリティモデルの要件に関するストレージデバイスのネイティブ機能のセキュリティへの影響。
In addition, these defining documents need to make clear how other semantic requirements of NFSv4.1 (e.g., locking) are met in the context of the proposed layout type.
さらに、これらの定義ドキュメントは、提案されたレイアウトタイプのコンテキストで、NFSv4.1の他のセマンティック要件（ロックなど）がどのように満たされるかを明確にする必要があります。
This section does not deal directly with security considerations for existing or new layout types. Instead, it provides a general framework for understating security-related issues within the pNFS framework. Specific security considerations will be addressed in the Security Considerations sections of documents specifying layout types. For example, in Section 3 of [RFC5663], the lack of finer-than-physical disk access control necessitates that the client is delegated the responsibility to enforce the access provided to them in the layout extent that they were granted by the metadata server.
このセクションでは、既存のレイアウトタイプまたは新しいレイアウトタイプのセキュリティに関する考慮事項を直接扱いません。代わりに、pNFSフレームワーク内でセキュリティ関連の問題を過小評価するための一般的なフレームワークを提供します。特定のセキュリティに関する考慮事項については、レイアウトタイプを指定するドキュメントの「セキュリティに関する考慮事項」セクションで説明します。たとえば、[RFC5663]のセクション3では、物理ディスクよりも細かいディスクアクセス制御がないため、クライアントに、メタデータサーバーから付与されたレイアウト範囲で提供されるアクセスを実施する責任を委任する必要があります。
The layout type specification must ensure that only data access consistent with the NFSV4.1 security model is allowed. It may do this directly, by providing that appropriate checks be performed at the time each access is performed. It may do it indirectly by allowing the client or the storage device to be responsible for making the appropriate checks. In the latter case, I/O access rights are reflected in layouts, and the layout type must provide a way to prevent inappropriate access due to permissions changes between the time a layout is granted and the time the access is performed.
レイアウトタイプの仕様では、NFSV4.1セキュリティモデルと整合性のあるデータアクセスのみが許可されるようにする必要があります。これは、各アクセスが実行されるときに適切なチェックが実行されることを提供することにより、これを直接行うことができます。クライアントまたはストレージデバイスが適切なチェックを行う責任を負うことにより、間接的にそれを行う場合があります。後者の場合、I / Oアクセス権はレイアウトに反映されます。レイアウトタイプは、レイアウトが許可されてからアクセスが実行されるまでの間に権限が変更されるため、不適切なアクセスを防ぐ方法を提供する必要があります。
The metadata server MUST be able to fence off a client's access to the data file on a storage device. When it revokes the layout, the client's access MUST be terminated at the storage devices. The client has a subsequent opportunity to reacquire the layout and perform the security check in the context of the newly current access permissions.
メタデータサーバーは、ストレージデバイス上のデータファイルへのクライアントのアクセスを隔離できる必要があります。レイアウトを取り消す場合、クライアントのアクセスはストレージデバイスで終了する必要があります。クライアントは、レイアウトを再取得し、新たに現在のアクセス許可のコンテキストでセキュリティチェックを実行する機会があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[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>。
[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>。
[RFC5663] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS (pNFS) Block/Volume Layout", RFC 5663, DOI 10.17487/RFC5663, January 2010, <https://www.rfc-editor.org/info/rfc5663>.
[RFC5663] Black、D.、Fridella、S.、J。Glasgow、「Parallel NFS（pNFS）Block / Volume Layout」、RFC 5663、DOI 10.17487 / RFC5663、2010年1月、<https：//www.rfc- editor.org/info/rfc5663>。
[RFC5664] Halevy, B., Welch, B., and J. Zelenka, "Object-Based Parallel NFS (pNFS) Operations", RFC 5664, DOI 10.17487/RFC5664, January 2010, <https://www.rfc-editor.org/info/rfc5664>.
[RFC5664] Halevy、B.、Welch、B。、およびJ. Zelenka、「Object-Based Parallel NFS（pNFS）Operations」、RFC 5664、DOI 10.17487 / RFC5664、2010年1月、<https：//www.rfc- editor.org/info/rfc5664>。
[RFC8154] Hellwig, C., "Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout", RFC 8154, DOI 10.17487/RFC8154, May 2017, <https://www.rfc-editor.org/info/rfc8154>.
[RFC8154] Hellwig、C。、「Parallel NFS（pNFS）Small Computer System Interface（SCSI）Layout」、RFC 8154、DOI 10.17487 / RFC8154、May 2017、<https://www.rfc-editor.org/info/ rfc8154>。
[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>。
[Lustre] Faibish, S., Cote, D., and P. Tao, "Parallel NFS (pNFS) Lustre Layout Operations", Work in Progress, draft-faibish-nfsv4-pnfs-lustre-layout-07, May 2014.
[ルスター]ファイビッシュ、S。、コート、D.、P。タオ、「Parallel NFS（pNFS）Luster Layout Operations」、Work in Progress、draft-faibish-nfsv4-pnfs-lustre-layout-07、2014年5月。
[RFC8435] Halevy, B. and T. Haynes, "Parallel NFS (pNFS) Flexible File Layout", RFC 8435, DOI 10.17487/RFC8435, August 2018, <https://www.rfc-editor.org/info/rfc8435>.
[RFC8435] Halevy、B。およびT. Haynes、「Parallel NFS（pNFS）Flexible File Layout」、RFC 8435、DOI 10.17487 / RFC8435、2018年8月、<https://www.rfc-editor.org/info/rfc8435 >。
Acknowledgments
謝辞
Dave Noveck provided an early review that sharpened the clarity of the definitions. He also provided a more comprehensive review of the document.
Dave Noveckは、定義の明確さを明確にする早期レビューを提供しました。彼はまた、ドキュメントのより包括的なレビューを提供しました。
Both Chuck Lever and Christoph Helwig provided insightful comments during the working group last call.
チャックレバーとクリストフヘルウィグの両方が、ワーキンググループの前回の電話中に洞察に満ちたコメントを提供しました。
Author's Address
著者のアドレス
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