pNFS

RFC8881

RFC 8881: Network File System (NFS) Version 4 Minor Version 1 Protocol

12. Parallel NFS (pNFS)

• pNFSはNFSv4.1のオプション機能であり、クライアントがファイルデータを含むストレージデバイスに直接アクセスできるようにすることで、ファイルアクセス性能を大幅に向上させることを目的としています。
• pNFSモデルでは、クライアント、サーバー、ストレージデバイスがファイルアクセスの管理責任を負います。
• pNFSは、バイト範囲とストレージ位置情報を含む「レイアウト」と呼ばれるプロトコルオブジェクトを管理するオプションの操作として提供されます。

12.2. pNFS Definitions

• NFSv4.1のpNFS機能は、ファイルシステムプロトコルの処理をメタデータ処理とデータ処理の2つの部分に分離し、データは複数のストレージサーバーにストライプ化されます。
• メタデータサーバーはpNFS機能をサポートするNFSv4.1サーバーであり、メタデータの機能（非レギュラーファイルの内容を含む）を実装します。
• ストレージデバイスはレギュラーファイルのデータを保存し、メタデータ管理はメタデータサーバーに委ねられます。

12.2.5. Storage Protocol

• ストレージプロトコルは、クライアントがストレージデバイスからデータを直接保存および取得するために使用される方法です。
• pNFS機能は、NFSv4.1自体、iSCSIなどのブロック/ボリュームプロトコル、およびOSDなどのオブジェクトプロトコルを含む、さまざまなストレージプロトコルの定義と使用を可能にするように構成されています。
• pNFSサーバーは、pNFS機能でアクセス可能なすべてのファイルに対して通常のNFSv4.1アクセスをサポートする必要があり、これによりNFSv4.1クライアントとサーバー間の相互運用性が維持されます。

12.2.6. Control Protocol

• コントロールプロトコルは、メタデータサーバーとストレージデバイスの間で、エクスポートされたファイルシステムによって使用されますが、NFSv4.1プロトコルの範囲外です。
• コントロールプロトコルは、ストレージの割り当てと解放、クライアントアクセス制御に必要な状態の管理などのアクティビティを制御するために使用されます。
• コントロールプロトコルは、変更時間、変更属性、EOF位置などの属性を維持するための要件がありますが、特定のコントロールプロトコルはNFSv4.1によって必須とされていません。

12.2.7. Layout Types

• レイアウトは、ファイルのデータがデータを保持するストレージデバイスにどのようにマッピングされるかを記述し、レイアウトタイプ（例：ブロック/ボリューム、オブジェクト、ファイル）に属します。
• メタデータサーバーは、少なくとも1つのレイアウトタイプをサポートする必要があり、プライベートサブ範囲のレイアウトタイプ名前空間も定義されています。
• サーバーが応答で異なるレイアウトタイプを送信した場合、クライアントは応答を無視し、サーバーがエラー応答を返したかのように動作すべきです。

12.2.8. Layout

• レイアウトは、1つ以上のストレージデバイス上でのファイルのデータ構成を定義し、<クライアントID, ファイルハンドル, レイアウトタイプ, iomode, 範囲>のタプルによって正確に識別されます。
• 2つのレイアウトが重複するには、同じレイアウトタイプ、同じファイルハンドル、および同じiomodeである必要があり、内容が異なる場合にレイアウトは競合します。
• iomodeが異なるレイアウトは競合せず、同じクライアントによって同じバイト範囲に対して保持されることが許容されます。

12.2.9. Layout Iomode

• レイアウトiomodeは、クライアントがREAD操作のみ、またはREADとWRITE操作の混合を実行する意図をメタデータサーバーに示します。
• LAYOUTIOMODE4_ANY iomodeはLAYOUTRETURNおよびCB_LAYOUTRECALLでのみ使用でき、両方のiomode（READおよびRW）に関連するレイアウトが返却またはリコールされることを指定します。
• レイアウトiomodeの使用は、OPEN共有モードまたはバイト範囲LOCK操作と競合せず、これらはpNFSレイアウトレベルとは論理的に分離されています。

12.2.10. Device IDs

• デバイスIDはストレージデバイスのグループを識別し、そのスコープは<クライアントID, レイアウトタイプ>のペアです。
• GETDEVICEINFO操作は、デバイスIDをレイアウトタイプとデバイスIDに従って完全なアドレス情報（すべてのデバイスアドレスを含む）にマッピングするために使用されます。
• サーバーはデバイスIDを参照するレイアウトがない場合、いつでもデバイスIDを削除できますが、一度削除されたデバイスIDは同じレイアウトタイプとクライアントIDに対して再利用してはなりません。

12.3. pNFS Operations

• pNFSサーバーに必要なフォアチャンネル操作には、GETDEVICEINFO（デバイスIDとストレージデバイスアドレスのマッピングを返す）、GETDEVICELIST（ファイルシステムのすべてのデバイスIDを取得）、LAYOUTGET（ファイルレイアウトを取得）、LAYOUTCOMMIT（ストレージデバイスに書き込まれたデータのコミットを通知）、およびLAYOUTRETURN（レイアウトを返却）があります。
• バックチャンネルpNFS操作には、CB_LAYOUTRECALL（レイアウトのリコール）、CB_RECALL_ANY（リコール可能なオブジェクトの返却を要求）、CB_RECALLABLE_OBJ_AVAIL（リコール可能なオブジェクトの利用可能を通知）、およびCB_NOTIFY_DEVICEID（デバイスIDの変更を通知）があります。
• pNFSはオプション機能ですが、実装される場合、一部の操作はpNFSに準拠するために必須です。

12.5. Layout Semantics

• レイアウトはクライアントに適切なストレージプロトコルでストレージデバイスのデータにアクセスする能力を付与し、競合するレイアウトが要求されたり、レイアウトがカプセル化する状態が無効になったりするとリコールされます。
• クライアントはレイアウトを保持している場合、ストレージデバイスにアクセスする前にOPEN、LOCK、およびACCESS操作を通じてすべてのユーザーアクセス権を取得するというNFSv4.1の要件は変更されません。
• pNFS機能が存在する場合、強制的なバイト範囲ロックはpNFSがない場合と同様に動作する必要があり、ストレージデバイスは強制的なバイト範囲ロックを施行できる必要があります。

12.5.2. Getting a Layout

• クライアントはLAYOUTGET操作でレイアウトを取得し、サーバーがサポートしクライアントが使用する準備ができている適切なレイアウトタイプを選択します。
• レイアウトを取得するために、クライアントはまずOPEN操作でファイルを開いている必要があり、成功したLAYOUTGET結果にはレイアウトstateidが含まれます。
• クライアントはファイル作成時にlayout_hint属性を設定することで、好ましいレイアウトタイプとアグリゲーションスキームについてサーバーにヒントを提供できます。

12.5.3. Layout Stateid

• レイアウトstateidは、他のすべてのstateidと同様に、「seqid」と「other」フィールドで構成され、「seqid」は初期値が1で、レイアウトstateidを使用するNFSv4.1操作ではゼロになりません。
• サーバーは、後続のLAYOUTGETおよびLAYOUTRETURN応答、およびCB_LAYOUTRECALLリクエストで、「seqid」の値を1ずつインクリメントします。
• クライアントは、「seqid」値を使用してLAYOUTGETおよびLAYOUTRETURN操作の応答を適切にソートし、LAYOUTGETとCB_LAYOUTRECALL間の競合状態を防ぎます。

12.5.4. Committing a Layout

• LAYOUTCOMMIT操作は、変更されたレイアウトをメタデータサーバーにコミットし、クライアントとメタデータサーバーおよびそのストレージデバイス間の再同期を行い、他のクライアントに潜在的な変更を利用可能にするために必要です。
• LAYOUTCOMMITのスコープは使用中のストレージプロトコルに依存し、メタデータサーバー上の更新された状態はクライアントの最後の操作の時点の状態を反映するだけで済みます。
• クライアントはLAYOUTCOMMIT操作を送信するためにレイアウトを保持している必要があります。

12.5.4.1. LAYOUTCOMMIT and change/time_modify

• LAYOUTCOMMIT操作が処理されると、change属性とtime_modify属性がサーバーによって更新される可能性があります。
• LAYOUTCOMMIT時に、クライアントはtime_modifyの推奨値をサーバーに提供することができますが、サーバーは提供された値を使用する前に整合性チェックを行うべきです。
• サーバーが変更属性とtime_modify属性の更新を監視できる場合、LAYOUTCOMMIT処理でchange属性を更新する必要はありません。

12.5.4.2. LAYOUTCOMMIT and size

• LAYOUTCOMMIT操作がクライアントによって使用されると、ファイルのサイズが更新される可能性があり、引数には最後に書き込まれたオフセット（loca_last_write_offset）が含まれます。
• メタデータサーバーは、クライアントが提供した最後の書き込みオフセットを使用してファイルサイズを更新するか、他の情報源からファイルサイズを決定するためにそれを無視することができます。
• LAYOUTCOMMITの結果には新しいサイズ値が含まれ、ファイルサイズが更新された場合、メタデータサーバーは新しいサイズを返信する必要があります。

12.5.4.3. LAYOUTCOMMIT and layoutupdate

• LAYOUTCOMMIT引数には、データタイプlayoutupdate4のloca_layoutupdateフィールドが含まれており、レイアウトタイプ固有の構造体です。
• この構造体は、LAYOUTCOMMIT時にクライアントからメタデータサーバーへ任意のレイアウトタイプ固有の情報を渡すために使用できます。
• loca_layoutupdateの内容はLAYOUTCOMMITに対して不透明であり、レイアウトタイプ仕様によって定義されます。

12.5.5. Recalling a Layout

• レイアウトは、ファイルのリコールCB_LAYOUTRECALLコールバック操作によってリコールされ、LAYOUTRETURNによって返却されます。
• CB_LAYOUTRECALL操作は、バイト範囲、ファイルシステムID（FSID）、またはクライアントIDに関連付けられたレイアウトをリコールできます。
• レイアウトが返却されると、クライアントは返却されたレイアウトが表すファイル、バイト範囲、およびiomodeに対してストレージデバイスにI/Oを送信してはなりません。

12.5.5.1. Layout Recall Callback Robustness

• サーバーは、クライアントに許可していないレイアウト範囲に対してコールバックを送信でき、クライアントは保持していない範囲を返却することが有用です。
• pNFSクライアントは、リコールによって指定された全範囲を構成するレイアウトを常に返却する必要があり、単一の操作で返却される必要はありません。
• レイアウトが返却される際、クライアントはレイアウトに関与するストレージデバイスへの未処理のI/Oリクエストを持っていてはなりません。

12.5.5.2. Sequencing of Layout Operations

• pNFSは、レイアウト操作の正しいシーケンスを提供するために、レイアウトstateidの「seqid」を使用します。
• クライアントは、未処理のLAYOUTGETまたはLAYOUTRETURN操作が1つ以上あることを示唆するCB_LAYOUTRECALLを処理してはなりません。
• LAYOUTGETおよびLAYOUTRETURN操作の応答の「seqid」フィールドを通じて、クライアントは並行して実行された操作がサーバーによって処理された順序を決定できます。

12.5.5.2.1. Layout Recall and Return Sequencing

• クライアントは、未処理のLAYOUTGETまたはLAYOUTRETURN操作の応答をすべて処理するまで、CB_LAYOUTRECALLの処理を待機する必要があります。
• クライアントは、同じファイルに対して複数の並行LAYOUTGET操作、複数の並行LAYOUTRETURN操作、またはその両方の混合を送信することが許可されています。
• クライアントがLAYOUTGETを送信し、応答を受け取る前に、同じファイルに対して重複する範囲のCB_LAYOUTRECALLを受け取った場合、レイアウトstateidの「seqid」を介してサーバーがどちらを先に処理したかを区別できます。

12.5.5.2.1.3. Server Considerations

• メタデータサーバーの視点から競合を考慮すると、CB_LAYOUTRECALL後にLAYOUTRETURN(s)が到着する前に重複するLAYOUTGETを受け取った場合、サーバーはLAYOUTGETの「seqid」に基づいて3つのケースで異なるエラー（NFS4ERR_RECALLCONFLICTまたはNFS4ERR_RETURNCONFLICT）を返します。
• クライアントがCB_LAYOUTRECALLを処理した後、LAYOUTGETの「seqid」がCB_LAYOUTRECALLの「seqid」と等しいかそれ以上で、サーバーがLAYOUTRETURNを受け取っていない場合、サーバーはNFS4ERR_RECALLCONFLICTを返します。
• LAYOUTGET操作の引数のレイアウトstateidの「seqid」がCB_LAYOUTRECALLの「seqid」よりも1小さい場合、サーバーはNFS4ERR_RECALLCONFLICTをクライアントに返します。

12.5.5.2.1.4. Wraparound and Validation of Seqid

• レイアウトstateidの処理ルールは、他のstateidと異なり、「seqid」値がゼロにならず、CB_LAYOUTRECALL操作でstateidの「seqid」値が変更されます。
• サーバーは、並列処理の範囲VALID_SEQID_RANGE内にあることを確認するために「seqid」を検証し、範囲外であればNFS4ERR_OLD_STATEIDエラーを返します。
• 「seqid」値が0xFFFFFFFFの場合、次の有効な値は0x00000001になります。

12.5.5.2.1.5. Bulk Recall and Return

• pNFSは、特定のfsidまたはクライアントIDに属するすべてのレイアウトを一括でリコールおよび返却することをサポートしており、seqidを介した競合検出は不可能です。
• サーバーは、別のリコールが進行中または保留中に一括リコールを開始してはならず、クライアントは進行中または保留中の操作がある場合NFS4ERR_DELAYを返します。
• LAYOUTRETURN4_ALLが送信されると、クライアントIDに付与されたすべてのレイアウトstateidが解放され、クライアントはそれらを再度使用してはなりません。

12.5.6. Revoking Layouts

• Parallel NFSでは、サーバーはリコールに応答しない、またはリースを時間内に更新できないクライアントからレイアウトを取り消すことができます。
• レイアウトタイプによっては、サーバーはレイアウトを取り消し、クライアントのデータサーバーへのI/Oに関して特定のアクションを取る場合があります。

12.5.7. Metadata Server Write Propagation

• メタデータサーバーを介して非同期に書き込まれたデータは、ストレージデバイスに遅延して伝播される可能性があり、コミットが完了するまで新しいデータが表示される保証はありません。
• 同期WRITEまたはCOMMIT（非同期に書き込まれたデータの場合）の完了時に、メタデータサーバーはストレージデバイスが新しいデータを渡し、データが安定したストレージに書き込まれたことを保証する必要があります。
• サーバーがこれらの制約を遵守できない方法でストレージを実装している場合、サーバーは関連するWRITE操作に応答する前にレイアウトをリコールする必要があります。

12.6. pNFS Mechanics

• pNFSクライアントは、新しいFSIDに遭遇すると、fs_layout_type属性のためにGETATTRをNFSv4.1サーバーに送信し、pNFSの可能性を判断します。
• クライアントは、pNFSが有効なファイルシステムでファイルを作成する場合、OPEN操作とオプションのlayout_hint属性を使用し、GETATTRを同じCOMPOUNDで組み合わせてレイアウトタイプを決定することが推奨されます。
• クライアントは、LAYOUTGET操作でレイアウトを取得し、デバイスIDとデータ構成の説明を受け取り、GETDEVICEINFOでデバイスアドレスを解決してからI/Oリクエストをストレージデバイスに送信します。

12.7. Recovery

• pNFSプロトコルの分散性のためにリカバリは複雑であり、レイアウトのクラッシュリカバリはNFSv4.1基本プロトコルのデリゲーションのクラッシュリカバリに類似しています。

12.7.1. Recovery from Client Restart

• クライアントが再起動すると、以前所有していたレイアウトに関するすべての情報を失い、サーバーはリース期間の満了または新しいクライアントIDの交換を通じてリソースを回収できます。
• クライアントによって書き込まれたが、成功したLAYOUTCOMMITでカバーされていないデータは未定義の状態となり、クライアントの責任でLAYOUTCOMMITを使用して安定性を達成する必要があります。

12.7.2. Dealing with Lease Expiration on the Client

• クライアントは、リースが期限切れになったと信じる場合、SEQUENCE操作をメタデータサーバーに送信してリースを検証するまでストレージデバイスにI/Oを送信してはなりません。
• SEQUENCE操作が成功し、SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKEDなどが設定されている場合、クライアントは現在保持しているレイアウトを使用してはなりません。
• メタデータサーバーからSEQ4_STATUS_RESTART_RECLAIM_NEEDEDが設定されている場合、クライアントはセクション12.7.4に記載されている方法で回復する必要があります。

12.7.3. Dealing with Loss of Layout State on the Metadata Server

• メタデータサーバーが再起動していないが、pNFSクライアントのレイアウトが破棄され、I/Oがストレージデバイスに到着した場合、サーバーとストレージデバイスはクライアントをフェンス（I/O操作の実行を防止）することで解決する必要があります。
• フェンシングの詳細はレイアウトタイプに固有です。

12.7.4. Recovery from Metadata Server Restart

• メタデータサーバーが再起動したことを検出すると、pNFSクライアントはレイアウトの使用を停止し、以前受け取ったデバイスIDとデバイスアドレスのマッピングを削除する必要があります。
• クライアントがメモリ内に変更された未書き込みのデータを持っている場合、サーバーの猶予期間後にLAYOUTGETを介してレイアウトを取得するか、WRITE操作を介してデータをメタデータサーバーに書き込むことができます。
• クライアントがメモリ内にデータのコピーを持っておらず、メタデータサーバーがまだ猶予期間にある場合の唯一のリカバリオプションは、LAYOUTCOMMITをreclaimモードで送信することです。

12.7.5. Operations during Metadata Server Grace Period

• メタデータサーバーは、WRITEやLAYOUTGETなどの一部の操作を猶予期間中に許可する場合がありますが、最も単純で正しいアプローチは、非reclaimのpNFSリクエストとWRITE操作をNFS4ERR_GRACEエラーで拒否することです。
• LAYOUTGETの場合、メタデータサーバーは、そのリクエストの処理が差し迫ったLAYOUTCOMMIT reclaimリクエストと競合しないことを確実に判断する必要があります。

12.7.6. Storage Device Recovery

• ストレージデバイスのリカバリは、ほとんど使用中のレイアウトタイプに依存しますが、クライアントは修正された未コミットデータを別のパスを通じて書き直すことを試みることが最善の解決策です。
• クライアントは、WRITE4argsのstableフィールドをFILE_SYNC4に設定して、データを直ちにメタデータサーバーにWRITEすべきです。

12.8. Metadata and Storage Device Roles

• 同じ物理ハードウェアがメタデータサーバーとストレージデバイスの両方を実装している場合、そのハードウェアエンティティは2つの異なる役割を実行していると理解される必要があります。
• ストレージデバイスがNFSv4.1をストレージプロトコルとして使用する場合（ファイルベースのレイアウト）、または使用しない場合でも、クライアントとサーバーにとって、リクエストがどちらの役割に向けられているかは明確です。

12.9. Security Considerations for pNFS

• pNFSはファイルシステムのメタデータとデータを分離し、両方へのアクセスを提供しますが、メタデータへのアクセスには既存のNFSv4.1のセキュリティメカニズムがすべて適用されます。
• pNFSシステム内のコンポーネントは、NFSv4.1のセキュリティプロパティを維持し、ACLとファイルオープンモードを尊重するようにする必要があります。
• クライアントのみのアクセスチェックが不十分な場合、そのようなレイアウトタイプは使用すべきではありません。

13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type

• このセクションでは、pNFS用のNFSv4.1ファイルベースレイアウトのセマンティクスとフォーマットについて説明し、LAYOUT4_NFSV4_1_FILESレイアウトタイプを使用します。
• LAYOUT4_NFSV4_1_FILESタイプは、複数のNFSv4.1データサーバーにデータをストライプ化することを定義します。

13.1. Client ID and Session Considerations

• サーバーはEXCHANGE_IDの結果に基づいて、メタデータサーバー（MDS）、データサーバー（DS）、または非メタデータサーバー（NON-PNFS）の役割を果たすことができます。
• サーバーは、EXCHANGE_IDの結果で、MDSとDS、DSとNON-PNFSなど、1つまたは2つの役割を持つことができます。
• pNFSメタデータクライアントがNFSv4.1データサーバーを参照するレイアウトを取得する場合、クライアントはEXCHANGE_IDをデータサーバーに送信してクライアントIDを取得する必要があります。

13.1.1. Sessions Considerations for Data Servers

• EXCHANGE_IDの結果がEXCHGID4_FLAG_USE_PNFS_DSのみを返すデータサーバーを参照するレイアウトをクライアントが受け取る場合、クライアントはメタデータサーバーのlease_time属性がデータサーバーに適用されると仮定してもよいです。
• データサーバーは、I/Oを提供しているすべてのメタデータサーバーのlease_time属性の最大値を、確立されたすべてのクライアントIDとセッションのリース間隔として使用する必要があります。

13.2. File Layout Definitions

• ユニット（Unit）は、データサーバーに書き込まれる固定サイズのデータ量です。
• ストライプ（Stripe）は、パターンが繰り返される前に、一連のデータサーバー全体にパターンで分散されるデータのセットです。
• ストライプ幅はバイト単位のストライプのサイズであり、ストライプ数×ストライプユニットのサイズに等しいです。

13.3. File Layout Data Types

• NFSv4.1レイアウトタイプには、nfsv4_1_file_layouthint4、nfsv4_1_file_layout_ds_addr4、およびnfsv4_1_file_layout4があり、SETATTR操作はlayout_hint属性をサポートしています。
• nfsv4_1_file_layout_ds_addr4データタイプはデバイスアドレスを表し、データサーバーのアドレスリストとストライプインデックスの配列で構成されています。
• nfsv4_1_file_layout4データタイプはレイアウトを表し、デバイスID、nfl_util、nfl_first_stripe_index、nfl_pattern_offset、およびnfl_fh_listで構成されています。

13.4. Interpreting the File Layout

• クライアントの論理ファイルオフセットに対応するストライプユニット番号（SUi）は、相対オフセットをストライプユニットサイズで割って求められます。

13.4.2. Interpreting the File Layout Using Sparse Packing

• スパースパッキングを使用する場合、SUiを書き込むためのファイルハンドルとデータサーバーネットワークアドレスのセットを決定するアルゴリズムは、ストライプインデックスとnfl_first_stripe_indexを使用して計算されます。
• nfl_fh_listの要素数が0、1、またはnflda_multipath_ds_listと同じ数のいずれかである場合に応じて、ファイルハンドルの選択が異なります。

13.4.3. Interpreting the File Layout Using Dense Packing

• デンスパッキングを使用する場合、SUiを書き込むためのファイルハンドルは、nfl_fh_listの要素数がストライプ数と同じである場合にのみ、nfl_fh_list[j]から決定されます。
• デンスパッキングでは、同じデータサーバーリストを参照するストライプユニットごとに異なるファイルハンドルを使用する必要があります。

13.4.4. Sparse and Dense Stripe Unit Packing

• nfl_util4データタイプ内のNFL4_UFLG_DENSEフラグは、データサーバー上のデータファイル内でデータがどのようにパックされるかを指定します（スパースまたはデンス）。
• スパースパッキング（NFL4_UFLG_DENSEがゼロ）では、データサーバーファイルはスパースになり、クライアントが穴に対してI/Oを試行するとNFS4ERR_PNFS_IO_HOLEエラーが返されなければなりません。
• デンスパッキング（NFL4_UFLG_DENSEが1）では、データサーバーファイルに穴がなく、データファイル内のバイトオフセットを決定するために異なる計算式が使用されます。

13.5. Data Server Multipathing

• NFSv4.1ファイルレイアウトは、複数のデータサーバーアドレスへのマルチパスをサポートし、帯域幅スケーリングと可用性の向上に使用されます。
• クライアントは、nflda_multipath_ds_listの任意のネットワークアドレスをデータサーバーリクエストの送信先として自由に使用できます。
• クライアントは、デバイスID-デバイスアドレスマッピングを置き換えるためにGETDEVICEINFOを送信することが推奨され、MDSはCB_NOTIFY_DEVICEIDを使用して変更を通知することができます。

13.6. Operations Sent to NFSv4.1 Data Servers

• NFSv4.1データサーバーにアクセスするクライアントは、NULLプロシージャと、定義された操作の2つの制限されたサブセットからのみ取られる操作を含むCOMPOUNDプロシージャのみを送信する必要があります。
• 1つ目のサブセットはデータサーバーハウスキーピング操作（例：CREATE_SESSION、EXCHANGE_ID）、2つ目のサブセットはデータサーバーI/O操作（COMMIT、READ、WRITE、PUTFH）で構成されています。
• データサーバーI/O操作は、レイアウトで指定されたカレントファイルハンドルで使用する必要があり、有効なレイアウトを保持していないI/Oはデータサーバーによって拒否されなければなりません。

13.7. COMMIT through Metadata Server

• ファイルレイアウトは、COMMIT操作をデータサーバーまたはメタデータサーバーのどちらに送信するかを示すNFL4_UFLG_COMMIT_THRU_MDSフラグを提供します。
• フラグがFALSEの場合、COMMITは対応するWRITE操作が送信されたデータサーバーに送信する必要があり、TRUEの場合、COMMITはメタデータサーバーに送信する必要があります。
• NFL4_UFLG_COMMIT_THRU_MDSがTRUEの場合、データサーバーは共通のwriteverf verifierをWRITE応答で返す必要があり、メタデータサーバーのCOMMIT実装も同じwriteverfを返さなければなりません。

13.8. The Layout Iomode

• NFSv4.1ファイルベースレイアウトの場合、メタデータサーバーはレイアウトiomodeを使用する必要はありませんが、クライアントは読み取りまたは書き込みの意図に基づいてiomodeを設定すべきです。
• クライアントはデフォルトでLAYOUTIOMODE4_RWのiomodeを使用する場合があります。

13.9. Metadata and Data Server State Coordination

• クライアントがデータサーバーにI/Oを送信する場合に使用されるstateidは、LAYOUTGETによって返されたりCB_LAYOUTRECALLによって送信されたレイアウトstateidであってはなりません。
• I/Oに使用されるstateidは、メタデータサーバー上のI/Oと同じ効果を持ち、同じ検証の対象となる必要があり、stateidはメタデータサーバーとデータサーバーの両方でグローバルに有効である必要があります。

13.9.2. Data Server State Propagation

• メタデータサーバーはバイト範囲ロックやオープンモードの状態変更、ACLを処理するため、データサーバーがI/Oアクセスを検証できるように、これらの状態変更をデータサーバーに伝播するように注意する必要があります。

13.9.2.1. Lock State Propagation

• pNFSサーバーが強制的なバイト範囲ロックをサポートする場合、ファイル上の任意の強制的なバイト範囲ロックは、それを確立するリクエストが呼び出し元に返される前にデータサーバーで有効にする必要があります。
• 助言的なバイト範囲ロックの状態は、I/Oアクセスチェックに使用されないため、データサーバーに伝播する必要はありません。

13.9.2.2. Open and Deny Mode Validation

• アクセスが縮小されたり、拒否モードがより制限的になったりする場合、データサーバーはメタデータサーバーで拒否されるI/Oを防止する必要があります。
• アクセスが拡張された場合、データサーバーは以前の緩和を考慮して、リクエストがオープンまたは拒否の問題で拒否されないようにする必要があります。

13.9.2.3. File Attributes

• SETATTR操作はサイズなどメタデータサーバーとデータサーバーの両方で可視な状態を変更する能力があるため、データサーバー間で結果の状態が一貫していることを保証するように注意する必要があります。
• ACLの変更によるアクセス権の変更は、READおよびWRITE I/O呼び出しのデータサーバーでの施行のために伝播される必要があり、より制限的になる変更は同期的に伝播されなければなりません。

13.10. Data Server Component File Size

• データサーバー上のコンポーネントデータファイルがEOFを超えて成長した場合、クライアントはREAD応答がEOFを示したり、要求されたバイト数より少ないバイト数を含んだりする場合、それをファイルの穴として解釈し、NFSクライアントはデータにゼロを代入する必要があります。
• クライアントがLAYOUTCOMMITをCLOSE時に実行することで、ファイルのサイズと変更属性が更新され、その後の他のクライアントからのアクセスで適切なサイズが返されます。

13.11. Layout Revocation and Fencing

• LAYOUT4_NFSV4_1_FILESレイアウトタイプは、正確なクライアントリースタイマーに依存することなく、リース期限切れ後にデータサーバーへのすべてのI/Oが実行されるのを防止できます（フェンシング）。
• レイアウトが取り消された場合、pNFSサーバーはクライアントが影響を受けるファイルに対するすべてのデータサーバーへのI/Oの送信を防止する必要があります。
• フェンシングは、PUTFH操作によって提供されるデータファイルハンドルとREADまたはWRITE操作のstateidをチェックすることで機能し、無効な場合はNFS4ERR_PNFS_NO_LAYOUTでI/Oが拒否されます。

13.12. Security Considerations for the File Layout Type

• NFSv4.1ファイルレイアウトタイプは、セクション12.9で概説されているセキュリティの考慮事項を遵守しなければならず、NFSv4.1データサーバーは各READまたはWRITE I/Oで必要なアクセスチェックを行う必要があります。
• LAYOUT4_NFSV4_1_FILESレイアウトタイプを使用する場合、認証、完全性、プライバシーのための方法はメタデータサーバーで使用されるものと同じです。
• NFSv4.1がpNFSとNFSv4.1ファイルレイアウトをサポートする場合、実装はメタデータサーバーとデータサーバーの両方でSECINFO_NO_NAME操作をサポートしなければなりません。

RFC8435

Enscript Output
要旨

• Parallel NFS (pNFS)は、ファイルからメタデータ（メタデータサーバー上）とデータ（ストレージデバイス上）を分離することを可能にします。
• この文書で定義されるフレキシブルファイルレイアウトタイプは、メタデータサーバーとの限定的なやり取りのみを必要とし、既存のプロトコルを使用するストレージデバイスの使用を可能にするpNFSの拡張です。
• クライアント側ミラーリングも、ファイルのレプリケーションを提供するために追加されています。

1. はじめに

• Parallel NFS (pNFS)において、メタデータサーバーはファイルデータがどこに配置されているかを記述するレイアウトタイプ構造を返します。
• この文書は、NFSプロトコル（NFSv3、NFSv4.0、NFSv4.1、NFSv4.2）を使用してアクセスされるファイルベースのデータサーバーで使用されるフレキシブルファイルレイアウトタイプを定義します。
• クライアント側ミラーリングでは、メタデータサーバーが利用可能なミラーをクライアントに提示するレイアウトを提供し、クライアントがすべての書き込みがすべてのミラーに送信されることを保証します。

1.1. 定義

• クライアント側ミラーリングとは、レイアウトセグメントのすべてのミラー化されたコピーの更新をサーバーではなくクライアントが担当する機能です。
• データサーバー (DS) は、ファイルベースのプロトコルでファイルシステムオブジェクトにアクセスされたときにファイルのデータを提供するpNFSサーバーです。
• フェンシングとは、メタデータサーバーがストレージデバイスに対して特定のクライアントからの特定のファイルへのI/O処理を防ぐプロセスです。

1.2. 要件の言語

• キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、すべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] に記載されている通りに解釈されます。

2. ストレージデバイスの結合

• サーバー実装は、メタデータサーバーとストレージデバイスの間で疎結合モデル（loosely coupled model）または密結合モデル（tightly coupled model）のいずれかを選択できます。
• 密結合モデルを実装するには、(1) セキュリティとLAYOUTCOMMITの管理、および (2) グローバルなstateidモデルとそのstateidの管理を提供する制御プロトコルを定義する必要があります。
• 疎結合モデルを実装する場合、セキュリティ、状態、およびロックの管理方法が指定されます。

2.1. LAYOUTCOMMIT

• 結合モデルに関係なく、メタデータサーバーはLAYOUTCOMMITを受信した際、pNFSのセマンティクスが遵守されるようにする責任があります。
• クライアントは、メタデータサーバーがファイルへの変更についてストレージデバイスに問い合わせを開始する前に、データファイルが安定していることを確認する責任があります。
• ストレージデバイスへの書き込みがFILE_SYNCと等しいstable_howで完了しなかった場合、メタデータサーバーへのLAYOUTCOMMITの前に、書き込みが行われたストレージデバイスへのCOMMITが必要です。

2.2. ストレージデバイスからのクライアントのフェンシング

• 疎結合ストレージデバイスでは、メタデータサーバーはデータファイルに合成uid（ユーザーID）とgid（グループID）を使用し、データファイルのuid所有者には読み取り/書き込みアクセスが許可され、gid所有者には読み取り専用アクセスが許可されます。
• クライアントのフェンシングは、メタデータサーバーがストレージデバイス上のデータファイルの合成uidおよび/またはgid所有者を変更し、未処理のRPC認証情報を暗黙的に取り消すことによって実現されます。
• 密結合ストレージデバイスの場合、メタデータサーバーはデータファイルのユーザーおよびグループ所有者、モードビット、およびACLをメタデータファイルと同じに設定し、クライアントはストレージデバイスで認証し、同じ承認プロセスを経る必要があります。

2.2.1. 合成uid/gidの実装上の注意

• 疎結合ストレージデバイスでのフェンシングに使用する合成uidとgidの選択方法は、厳密には実装の問題です。
• クライアントがファイルへのアクセスを完了し、他のクライアントがファイルにアクセスしていないことがメタデータサーバーによって認識された場合、所有者とグループをリセットしてデータファイルへのアクセスを制限できます。
• AUTH_SYSセキュリティモデルでは、合成uidおよびgidの0は避けるべきです。

2.2.2. 合成uid/gidの使用例

• ユーザーloghyrがメタデータサーバー上にファイル「ompha.c」を作成すると、対応するデータファイルがストレージデバイス上に作成されます。
• クライアントは書き込み権限を得るために19452のuidを提示する必要があり、それ以外のuidを提示する場合は読み取りアクセスを得るために28418のgidを提示する必要があります。
• メタデータサーバーがクライアントをフェンスすることを決定した場合、合成uidおよび/またはgidを制限されたIDに変更する必要があります。

2.3. 状態とロックモデル

• 実装は常に疎結合モデルとして展開できますが、ストレージデバイスがNFSプロトコルを介して密結合モデルに確実に参加できることを示す方法はありません。
• NFSv4.1+ストレージデバイスでEXCHGID4_FLAG_USE_PNFS_DSフラグを設定してEXCHANGE_IDを識別しない場合、疎結合として扱われることを示します。
• EXCHGID4_FLAG_USE_PNFS_DSフラグを設定して自身を識別するNFSv4.1+ストレージデバイスは、潜在的に密結合である可能性があり、バックエンド制御プロトコルを使用してグローバルstateidモデルを実装します。

2.3.1. 疎結合ロックモデル

• ロック関連の操作が要求された場合、主にメタデータサーバーによって処理され、適切なstateidが生成されます。
• すべてのI/O操作は匿名stateidを使用してストレージデバイスに対して実行されるため、ストレージデバイスは特定のI/O操作を発行したopenownerやlockownerに関する情報を持っていません。
• stateidが取り消された場合、メタデータサーバーはクライアントが取り消されたstateidを認識していない可能性があるため、クライアントアクセスを防止する責任があります。

2.3.2. 密結合ロックモデル

• ロック関連の操作が要求された場合、主にメタデータサーバーによって処理され、適切なstateidが生成され、これらのstateidは制御プロトコル機能を使用してストレージデバイスに通知される必要があります。
• I/O操作がロックstateidを提示できるため、メタデータサーバーは、メタデータサーバーが選択したstateidと、それに関連付けられた対応するオープンstateidとの関連付けをストレージデバイスに認識させる能力が必要です。
• クライアントはストレージデバイスで有効なstateidを所有し使用するため、ストレージデバイス上にクライアントリースが存在し、リース期限切れの可能性が存在します。

3. フレキシブルファイルレイアウトタイプのXDR記述

• この文書には、フレキシブルファイルレイアウトタイプのExternal Data Representation (XDR) [RFC4506] 記述が含まれており、読み取りコンパイル可能な形式で抽出できるように埋め込まれています。
• 埋め込まれたXDRファイルヘッダーには、NFSv4.1のnfs4_prot.xファイル [RFC5662] の型に依存するコードが含まれています。

3.1. コードコンポーネントライセンス通知

• XDR記述とXDR記述の抽出に使用されるスクリプトの両方は、「Trust Legal Provisions (TLP)」 [LEGAL] のセクション4に記載されているコードコンポーネントです。
• これらのコードコンポーネントは、その文書の条件に従ってライセンスされています。

4. デバイスアドレッシングと検出

• ストレージデバイスへのデータ操作には、クライアントがストレージデバイスのネットワークアドレスを知っている必要があります。
• NFSv4.1+のGETDEVICEINFO操作がクライアントによって使用され、その情報が取得されます。

4.1. ff_device_addr4

• ff_device_addr4データ構造は、成功したGETDEVICEINFO操作によってdevice_addr4構造内のレイアウトタイプ固有のopaqueフィールドda_addr_bodyとしてサーバーから返されます。
• ffda_versions配列は、NFSバージョン、マイナーバージョン、および結合強度に関する選択肢をクライアントに提示することを可能にします。
• ffdv_tightly_coupledが設定されていない場合、クライアントはメタデータサーバーにLAYOUTCOMMITを送信する前に、ファイルに対する書き込みをストレージデバイスにコミットしなければなりません。

4.2. ストレージデバイスマルチパス

• フレキシブルファイルレイアウトタイプは、複数のストレージデバイスアドレスへのマルチパスをサポートしています。
• ストレージデバイスマルチパスをサポートするために、ffda_netaddrsには1つ以上のストレージデバイスネットワークアドレスの配列が含まれています。
• クライアントがffda_netaddrsで利用可能なすべてのアドレスを使用してもストレージデバイスからの応答がない場合、既存のdevice-ID-to-device-addressマッピングを置き換えようとするためにGETDEVICEINFOを送信すべきです。

5. フレキシブルファイルレイアウトタイプ

• この文書は、layouttype4の値LAYOUT4_FLEX_FILESに関連付けられた構造を定義します。
• ff_layout4構造は、現在のレイアウトセグメントで記述されたデータファイルの部分におけるレイアウトを指定します。

5.1. ff_layout4

• ff_layout4構造は、現在のレイアウトセグメントで記述されたデータファイルの部分におけるレイアウトを指定します。
• ffl_stripe_unitフィールドは、現在のレイアウトセグメントで使用されているストライプ単位サイズです。
• ffl_mirrorsフィールドは、現在のストライプのストレージを提供するミラー化されたストレージデバイスの配列です。

5.1.1. LAYOUTGETからのエラーコード

• NFS4ERR_LAYOUTUNAVAILABLEは、利用可能なレイアウトがなく、I/Oがメタデータサーバーに行くべきであることを示します。
• NFS4ERR_LAYOUTTRYLATERは、レイアウトが付与されるのを妨げている何らかの問題があることを示し、クライアントがすでに適切なレイアウトを持っている場合、ストレージデバイスへのI/Oを続行すべきです。
• NFS4ERR_DELAYは、レイアウトが付与されるのを妨げている何らかの問題があることを示し、クライアントがすでに適切なレイアウトを持っている場合、ストレージデバイスへのI/Oを続行すべきではありません。

5.1.2. FF_FLAGS_NO_IO_THRU_MDSとのクライアントのやり取り

• メタデータサーバーがFF_FLAGS_NO_IO_THRU_MDSフラグを提供している場合でも、クライアントはメタデータサーバーへのI/Oを実行できます。
• このフラグはヒントとして機能し、メタデータサーバーがパフォーマンス上の理由でメタデータI/OとデータI/Oを分離することを好むことをクライアントに示します。

5.2. LAYOUTCOMMIT

• フレキシブルファイルレイアウトは、LAYOUTCOMMITへのloca_layoutupdate引数内のlou_bodyを使用しません。
• lou_typeがLAYOUT4_FLEX_FILESの場合、lou_bodyフィールドは長さがゼロでなければなりません。

5.3. デバイスとレイアウト間の相互作用

• フレキシブルファイルレイアウトタイプでは、ファイルハンドルの配列が存在しますが、それらは使用されているマルチパスとは独立しています。
• メタデータサーバーが同じストレージデバイス上の同じファイルの複数の読み取り専用コピーを提供したい場合、異なるff_device_addr4を持つ複数のミラー化されたインスタンスを提供すべきです。

5.4. バージョンエラーの処理

• メタデータサーバーがff_device_addr4内のffda_versions配列を提供する場合、クライアントは提供されたffdv_versionとffdv_minorversionの組み合わせのいずれかでストレージデバイスにアクセスできるかどうかを判断できます。
• LAYOUTRETURNおよび/またはLAYOUTERRORで返すエラーコードはNFS4ERR_MINOR_VERS_MISMATCHであり、これは提供されたすべてのバージョンとマイナーバージョンの組み合わせに対してクライアントがストレージデバイスと通信できないことを示します。
• クライアントは、異なる組み合わせが提供されるかどうかを確認するためにGETDEVICEINFOを再試行するか、I/Oをメタデータサーバー経由で実行することにフォールバックできます。

6. スパースマッピングによるストライピング

• 他のレイアウトタイプが論理オフセットからファイル内の物理オフセットへの密なマッピングと疎なマッピングの両方をサポートしているのに対し、フレキシブルファイルレイアウトタイプは疎なマッピングのみをサポートします。
• 疎なマッピングでは、ファイル内の論理オフセット（L）はストレージデバイス上の物理オフセットでもあります。

7. クライアントI/Oエラーからの回復

• pNFSクライアントは、ストレージデバイスに直接アクセスするときにエラーに遭遇する可能性がありますが、I/Oエラーから回復するのはメタデータサーバーの責任です。
• LAYOUT4_FLEX_FILESレイアウトタイプが使用される場合、クライアントはLAYOUTRETURN時にff_ioerr4構造を使用してI/Oエラーをサーバーに報告しなければなりません。
• メタデータサーバーはエラーを分析し、メディア障害の回復や欠落したデータファイルの再構築などの必要な回復操作を決定しなければなりません。

8. ミラーリング

• フレキシブルファイルレイアウトタイプには、レイアウトセグメントによって制約されるファイルデータのミラーリングのための単純なモデルがあります。
• ミラー化されたレイアウトセグメントの更新は、クライアント側ミラーリングを介して行われ、クライアントはレイアウトを通じて知らされたレイアウトセグメントのすべてのコピーに変更が加えられることを確認する責任があります。
• FF_FLAGS_WRITE_ONE_MIRRORがffl_flagsに設定されている場合、クライアントはミラーの1つだけを更新すればよいです。

8.1. ミラーの選択

• メタデータサーバーがクライアントにレイアウトを付与するとき、ffds_efficiencyメンバーを介して、各ミラーがストレージデバイスに要求が到着した後にどれだけ高速であると予想されるかをクライアントに知らせることができます。
• クライアントは、ファイルを読むためにアクセスするミラーを決定するのはクライアントです。

8.2. ミラーへの書き込み

• FF_FLAGS_WRITE_ONE_MIRRORフラグがffl_flagsに設定されている場合、クライアントはレイアウトセグメントのコピーの1つだけを更新すればよく、ストレージデバイスはミラーのいずれかが更新されたときにすべてのミラーのコピーが更新されることを保証しなければなりません。
• FF_FLAGS_WRITE_ONE_MIRRORフラグが設定されていない場合、クライアントはレイアウトで与えられたレイアウトセグメントのすべてのミラー化されたコピーを更新する責任があります。

8.2.3. 書き込みエラーの処理

• クライアントが書き込みエラーをメタデータサーバーに報告する場合、メタデータサーバーは、エラーのあるミラーをレイアウトから削除するか、ミラーが一時的なエラーから回復したかどうかなどを決定する責任があります。
• クライアントがNFSv4.2をサポートしている場合、LAYOUTERRORとLAYOUTRETURNを使用して、回復の取り組みに関するヒントをメタデータサーバーに提供できます。

8.2.4. 書き込みCOMMITの処理

• 安定した書き込みがメタデータサーバーまたは単一のレプリカ（FF_FLAGS_WRITE_ONE_MIRRORの使用が許可されている場合）に行われる場合、受信ノードは、クライアントに応答する前に、書き込まれたデータが安定して伝播されるようにする責任があります。
• 不安定な書き込みが行われる対応するケースでは、受信ノードにはそのような義務はありませんが、非同期で更新を伝播することを選択する場合があります。
• 書き込みが行われたレプリカから古いデータが読み取られる状況を避けるために、不安定な書き込みがあるクライアントは、すべての読み取りをその同じノードから実行しなければなりません。

8.3. メタデータサーバーによるファイルの再ミラーリング

• メタデータサーバーは、レイアウトセグメントの新しいミラーをいつでも作成することを選択できます。
• クライアントがレイアウトセグメントに対して行っている更新をメタデータサーバーが認識しないため、メタデータサーバーは再ミラーリングしている書き込み可能なレイアウトセグメントをリコールしなければなりません。

9. フレキシブルファイルレイアウトタイプのリターン

• layoutreturn_file4は、LAYOUTRETURN操作でレイアウトタイプ固有の情報をサーバーに伝えるために使用されます。
• lora_layout_typeレイアウトタイプがLAYOUT4_FLEX_FILESで、lr_returntypeがLAYOUTRETURN4_FILEの場合、lrf_body opaque値はff_layoutreturn4によって定義されます。

9.1. I/Oエラー報告

• ff_ioerr4構造は、データ転送中にエラーを生成したデータファイルのエラーインジケータを返すために使用されます。
• ストレージデバイスがNFSv3を介してアクセスされ、NFSv3エラーをクライアントに報告する場合でも、クライアントはこれらを適切なNFSv4ステータスコードにマッピングする責任があります。

9.2. レイアウト使用統計

• ff_io_latency4には、操作カウントと転送されたバイト数の両方が保持されます。
• LAYOUTSTATSは累積的であり、操作が送信されるたびにリセットされるわけではありません。

9.2.2. ff_layoutupdate4

• ffl_addrは、クライアントがストレージデバイス上のどのネットワークアドレスに接続しているかを区別します。
• ffl_durationは、統計情報が収集された期間を示すために使用されます。

9.2.3. ff_iostats4

• ff_iostats4は、クライアントがレイアウトを返す際にI/O統計情報をメタデータサーバーに報告するために使用される場合があります。
• クライアントは、レイアウトを使用したすべてのI/Oを報告することは現実的ではないため、I/O統計を報告する「ホットな」バイト範囲を特定する場合があります。
• ffis_offsetとffis_lengthは、範囲の開始オフセットとバイト単位の範囲の長さを表します。

9.3. ff_layoutreturn4

• データファイルI/O操作が失敗した場合、fflr_ioerr_report<>は、これらのエラーをff_ioerr4型の要素の配列としてメタデータサーバーに報告するために使用されます。
• クライアントは、fflr_iostats_report<>を使用して、I/O統計のリストをff_iostats4型の要素の配列として報告することもできます。

10. フレキシブルファイルレイアウトタイプ LAYOUTERROR

• クライアントがNFSv4.2を使用してメタデータサーバーと通信している場合、LAYOUTRETURNを待ってエラー情報をメタデータサーバーに送信する代わりに、LAYOUTERRORを使用してその情報を通信する場合があります。
• フレキシブルファイルレイアウトタイプの場合、LAYOUTERROR4argsはff_ioerr4と同じ内容として扱われます。

11. フレキシブルファイルレイアウトタイプ LAYOUTSTATS

• クライアントがNFSv4.2を使用してメタデータサーバーと通信している場合、LAYOUTRETURNを待ってI/O統計をメタデータサーバーに送信する代わりに、LAYOUTSTATSを使用してその情報を通信する場合があります。
• フレキシブルファイルレイアウトタイプの場合、LAYOUTSTATS4args.lsa_layoutupdateはffis_layoutupdateと同じ内容でオーバーロードされます。

12. フレキシブルファイルレイアウトタイプの作成ヒント

• layouthint4型は、クライアントが特定のファイルに対して作成したいレイアウトのタイプに関するヒントを渡すために使用されます。
• loh_typeレイアウトタイプがLAYOUT4_FLEX_FILESの場合、loh_body opaque値はff_layouthint4型によって定義されます。

12.1. ff_layouthint4

• この型は、目的のデータマップのヒントを伝えます。
• すべてのパラメータはオプションであり、クライアントは関心のあるパラメータについてのみ値を与えることができます。

13. レイアウトのリコール

• メタデータサーバーは、ファイルのセキュリティポリシーが変更された場合や、既存のレイアウトがロッキング制約の適用と矛盾している場合など、未処理のレイアウトをリコールすべきです。

13.1. CB_RECALL_ANY

• メタデータサーバーは、CB_RECALL_ANYコールバック操作を使用して、クライアントにレイアウトの一部またはすべてを返すように通知できます。
• craa_type_maskビットマップはリコールされるリソースのタイプを指定し、craa_layouts_to_keep値はクライアントが保持できるリコールされたフレキシブルファイルレイアウトの数を指定します。
• PNFS_FF_RCA4_TYPE_MASK_READフラグは、クライアントにLAYOUTIOMODE4_READのiomodeのレイアウトを返すように通知し、PNFS_FF_RCA4_TYPE_MASK_RWフラグはLAYOUTIOMODE4_RWのiomodeのレイアウトを返すように通知します。

14. クライアントのフェンシング

• クライアントが通信不能でリースが期限切れになった場合、またはクライアントがリコールされたレイアウトをリース期間内に返さない場合、サーバーはクライアントレイアウトを取り消し、これらのリソースを他のクライアントに再割り当てする場合があります。
• データ破損を避けるために、メタデータサーバーは取り消されたクライアントをそれぞれのデータファイルからフェンスしなければなりません。

15. セキュリティの考慮事項

• pNFSシステムのコンポーネントの組み合わせは、クライアントを介してデータにアクセスするエンティティに関して、NFSv4.1+のセキュリティプロパティを保持する必要があります。
• メタデータサーバーは、LAYOUTGET時にファイルアクセス制御ポリシーを適用します。
• メタデータサーバーは、いつでもデータファイルをフェンスすることによりアクセスを拒否でき、これにより、クライアントは現在のレイアウトを返し、データファイルへのI/Oを継続したい場合は新しいレイアウトを取得することを強制されます。

15.1. RPCSEC_GSSとセキュリティサービス

• 疎結合モデル内のプリンシパルの特殊な使用により、結合モデルによって問題が異なります。

15.1.1. 疎結合

• RPCSEC_GSSバージョン3（RPCSEC_GSSv3）[RFC7861] は、クライアントがメタデータサーバーに代わってストレージデバイスに承認されることを可能にする機能を含んでいますが、この文書ではそのための具体的な仕様は記述されていません。
• この結果、この文書で記述されているレイアウトタイプは、疎結合モデルとともにRPCSEC_GSSの使用をサポートしません。

15.1.2. 密結合

• 密結合では、メタデータファイルにアクセスするために使用されるプリンシパルは、データファイルにアクセスするために使用されるプリンシパルとまったく同じです。
• ストレージデバイスは、制御プロトコルを使用して任意のRPC資格情報を検証できます。

16. IANAの考慮事項

• この文書は、既存のレイアウトタイプ番号であるLAYOUT4_FLEX_FILESに関連付けられたプロトコルを定義します。
• この文書は、RCA4_TYPE_MASK_FF_LAYOUT_MINとRCA4_TYPE_MASK_FF_LAYOUT_MAXの新しいリコール可能なオブジェクトを定義します。

17. 参照

• このセクションでは、この文書の作成に使用された規範的参照と情報提供の参照を提供します。
• 規範的参照には、BCP 14 [RFC2119] [RFC8174] や、NFSおよび関連プロトコルのRFCが含まれます。