以下は、 RFC5661 の kanda.motohiro@gmail.com による抄訳です。手っ取り早く日本語で NFS v4.1 を理解するのが目的なので、はしょった訳になっています。ことわりなく原文の部分を省略しているところがあります。いまのところ、 pNFS 関連以外の部分は、訳す予定はありません。http://trustee.ietf.org/license-info/ に派生物のライセンスの規定があるのかよくわかりません。なければ、Creative Commons Attribution-Share Alike, Version 3.0 で提供します。他の nfsv4 RFC 訳は、ここを参照。
Internet Engineering Task Force (IETF) S. Shepler, Ed.
Request for Comments: 5661 Storspeed, Inc.
Category: Standards Track M. Eisler, Ed.
ISSN: 2070-1721 D. Noveck, Ed.
NetApp
January 2010
Network File System (NFS) バージョン4 マイナーバージョン1 プロトコル
概要
この文書は、Network File System (NFS) バージョン4 マイナーバージョン1 プロトコルを記述します。RFC 3530 にある、ベースプロトコルである NFS バージョン4 マイナーバージョン０のころからある機能と、それ以降作られたプロトコル拡張を含みます。NFSv4.1 で導入された大きな拡張は、セッション、ディレクトリ委譲、そして、パラレル NFS (pNFS) です。NFSv4.1 は、 NFSv4.0 に依存せず、独立したプロトコルとみなすことができます。このため、この文書は、RFC 3530 を更新したり置換することはありません。NFSv4.1 は、 NFSv4.0 に比べて、機能の低下はなく、優れていると考えられるので、こちらの使用をお勧めします。NFSv4.1 と、 NFSv4.0 は、同じネットワーク上で、同じクライアントとサーバーの間で同時に使うことができます。
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5661.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
目次
１．８ NFSv4.0 との違い
１２ パラレル NFS (pNFS)
１３ NFSv4.1 を、pNFS のストレージプロトコルとして使う：ファイルレイアウトタイプ
________________
１．８ NFSv4.0 との違い
以下は、ベースプロトコルとマイナーバージョン１の主な違いです。
o セッションモデルの実装。(Section 2.10)
o データへのパラレルアクセス。(Section 12)
o ロック回収処理をよりよい構造にするための、 RECLAIM_COMPLETE 操作の追加。(Section 18.51)
o 以下の、委譲の強化
* 通常ファイル以外の、ディレクトリーや他のファイルタイプの委譲。(Section 18.39, Section 18.49)
* 回収あるいは拒否された委譲の獲得を最適化する操作。(Section 18.49, Section 20.5, Section 20.7)
* ファイルとディレクトリの変更の通知。(Section 18.39, Section 20.4)
* サーバーが、資源管理上の都合で１つ以上の委譲を回収していることを示すための方法。そして、クライアントが、返却する委譲を選択するための方法。(Section 20.6)
o OPEN 操作により、排他的なファイル作成のときに、複数の属性をアトミックに設定できます。(Section 18.16 の、新しい EXCLUSIVE4_1 作成メソッドを参照)
o ファイルが削除されて、ハードリンク（定義は、Open Group [6] standard を参照。）数がゼロになっても、オープンファイルはそのままでいられます。このため、クライアントで、「silly rename」と呼ばれてきたように、削除されたファイルをほぼ隠れた別の名前にしておいておく必要がなくなりました。（Section 18.16 の 新しい OPEN4_RESULT_PRESERVE_UNLINKED 応答フラグを参照。）
o Access Control List について、Microsoft Windows との互換性が向上。(Section 6.2.3, Section 6.2.2, Section 6.4.3.2)
o データリテンション（訳注。更新禁止期間）(Section 5.13)
o ＮＦＳ クライアントとサーバーの実装を識別します。(Section 18.35)
o バイトレンジロックが可能となったら通知します。（Section 18.16 and see Section 20.11 の、新しい OPEN4_RESULT_MAY_NOTIFY_LOCK 応答フラグを参照。）
o LIPKEY and SPKM-3 は、必須のセキュリティ機構ではなくなりました。[32]
１２ パラレル NFS (pNFS)
１２．１ はじめに
pNFS は、NFSv4.1 でオプショナルな機能です。pNFS は、ファイルデータを持っているストレージデバイスへ、クライアントが直接アクセスすることを可能とします。１つの NFSv4 サーバーの管理するファイルデータが複数の、そして／あるいは、高スループット（サーバーのスループット能力と比べて）のストレージデバイスに格納されている場合、飛躍的に高性能なファイルアクセスが得られることがあります。pNFS における、複数のクライアント、１つのサーバー、そして複数のストレージデバイス
の関係を、Figure 1 に示します。（サーバーとクライアントは、すべてのストレージデバイスにアクセスできます。）
+-----------+
|+-----------+ +-----------+
||+-----------+ | |
||| | NFSv4.1 + pNFS | |
+|| Clients |<------------------------------>| Server |
+| | | |
+-----------+ | |
||| +-----------+
||| |
||| |
||| Storage +-----------+ |
||| Protocol |+-----------+ |
||+----------------||+-----------+ Control |
|+-----------------||| | Protocol|
+------------------+|| Storage |------------+
+| Devices |
+-----------+
Figure 1
このモデルでは、クライアント、サーバー、そしてストレージデバイスが、ファイルアクセスを管理します。これは、 pNFS のない NFSv4 ではサーバーが主にそれを行っていることと大きく違います。なお、サーバーの役割の一部は、クライアントに委譲されることができました。ストレージプロトコルについては、Section 12.2.5 を、制御プロトコルについては、 Section 12.2.6 を参照ください。
pNFS は、「レイアウト」 (Section 12.2.7) と呼ばれるプロトコルオブジェクトを管理するための、オプショナルな操作の集まりです。それは、ファイルのバイト範囲と、ストレージの位置の情報を持ちます。レイアウトは、 NFSv4.1 のデータの委譲と似たように扱われます。例えば、レイアウトは、リースされ、回収され、失効されます。しかし、レイアウトは特別な抽象化の結果であり、新しい操作により扱われます。クライアントがレイアウトを持つとき、クライアントは、そのレイアウトに示されるバイト範囲を、指定されたストレージ位置で直接アクセスする権限があります。
レイアウトと、その他の NFSv4.1 の抽象化の結果である、データ委譲やバイトレンジロックの間には相互作用があります。委譲の問題は、 Section 12.5.5 で、バイトレンジロックの問題は、 Sections 12.2.9 and 12.5.1 を参照ください。
１２．２ pNFS 定義
NFSv4.1 の pNFS 機能は、複数のストレージサーバーに内容をストライプしたファイルシステムへの並列データアクセスを提供します。NFSv4.1 の一部としての pNFS の最初の実装は、ファイルシステムプロトコル処理を２つの部分に分けます。メタデータ処理とデータ処理です。データは、ストレージサーバーの間にストライプされた通常ファイルの内容です。データストライピングは、少なくとも２つの方法で行われます。ファイルごと、あるいは、十分に大きなファイルではブロックごとです。一方、 pNFS クライアントからのメタデータへのストライプされたアクセスは NFSv4.1 では提供されません。 pNFS サーバーのバックエンドとなるファイルシステムがメタデータをストライプすることはあるかもしれませんが。メタデータは、通常ファイル以外（つまりディレクトリ）の内容を含む、その他すべてです。Section 12.2.1 を参照下さい。メタデータ機能は、 pNFS をサポートし、 Section 18 にある操作を行う NFSv4.1 サーバーにより実装されます。それを、メタデータサーバーと呼びます。(Section 12.2.2)
データ機能は、１つ以上のストレージデバイスにより実装されます。それぞれは、クライアントからストレージプロトコルでアクセスされます。NFSv4.1 の１つのサブセット(defined in Section 13.6)は、そのストレージプロトコルの１つです。pNFS 機能を記述するために新しい用語が NFSv4.1 に追加され、既存の用語が明確にされました。
１２．２．１ メタデータ
名前、ネームスペース内の位置、所有者、ACL、他の属性など、ファイルシステムオブジェクトに関する情報。メタデータは、ストレージ位置の情報も含み、それは元になるストレージ機構によって変わります。
１２．２．２ メタデータサーバー
pNFS 機能をサポートする NFSv4.1 サーバー。メタデータサーバーと、サーバーが保持するファイルシステム情報の使い方には、様々なアーキテクチャ上の選択肢があります。メタデータサーバーはメタデータだけを保持し、ファイルデータは対応するストレージデバイスに置くもの、メタデータサーバーにも、一定のファイルデータを置くものがあるでしょう。
１２．２．３ pNFS クライアント
pNFS 機能をサポートする NFSv4.1クライアントで、少なくても１つのストレージプロトコルをサポートするもの。
１２．２．４ ストレージデバイス
は、通常ファイルのデータを保持します。メタデータ管理は、メタデータサーバーに任せます。ストレージデバイスは、NFSv4.1 サーバーであったり、オブジェクトベースのストレージデバイス（OSD）であったり、System Area Network (SAN, e.g., either FiberChannel or iSCSI SAN)経由でアクセスされるブロックデバイスであったりします。
１２．２．５ ストレージプロトコル
Figure 1 に示したように、クライアントはストレージデバイスに直接データを読み書きするためにストレージプロトコルを使います。
NFSv4.1 pNFS 機能は、いろいろなストレージプロトコルを定義、使用できるように作られました。ストレージプロトコルの１つの例は、 NFSv4.1 それ自身です。Section 13 を参照。その他のストレージプロトコルは、いろいろなところに書いてあるでしょうが、少なくても以下があるでしょう。
o ブロック／ボリュームプロトコル。例えば、 Internet SCSI (iSCSI) [48] and FCP [49] 。ブロック／ボリュームプロトコルサポートは、使われるブロック／ボリュームプロトコルのアドレッシング構造とは独立していることができるため、同じファイルデータを１つ以上のプロトコルがアクセスすることができ、他のブロック／ボリュームプロトコルに対しての拡張性も保証されます。訳注。よくわからない？
pNFS で、ブロック／ボリュームストレージプロトコルを使うためのレイアウト仕様は、 [41] を参照。
o オブジェクトプロトコル。例えば、OSD over iSCSI or Fibre Channel [50]。NFS で、オブジェクトストレージプロトコルを使うためのレイアウト仕様は、 [40] を参照。
クライアントとサーバーでいろいろなストレージプロトコルが使われ、ときには、クライアントとサーバーで両方が共通に使えるストレージプロトコルがないこともあるでしょう。このため、 pNFS サーバーは、 pNFS 機能でアクセス可能なすべてのファイルに対して、通常の NFSv4.1 アクセスをサポートしなくてはいけません。これにより、 NFSv4.1 クライアントとサーバーの間で、将来的にも相互運用性が保たれるはずです。
１２．２．６ 制御プロトコル
Figure 1 に示したように、制御プロトコルは、エクスポートされたファイルシステムのために、メタデータサーバーとストレージデバイスの間で使われます。そのプロトコル仕様は、 NFSv4.1 プロトコル仕様の対象ではありません。制御プロトコルは、例えば、記憶域の確保と解放、ストレージデバイスがクライアントのアクセス制御をするために必要な状態管理、メタデータサーバーで行っている制限がストレージデバイスでも行えるための認証と認可などのために使われるでしょう。
NFSv4.1 で、特定の制御プロトコルが必須とされることはありません。しかし、制御プロトコルがファイル変更時刻、 change 属性、そしてファイル終端位置(EOF) などの属性を維持することは必要です。もし、pNFS がクラスターパラレルファイルシステム (e.g., PVFS [51]) の上に位置するなら、そのファイルシステムでクラスター化とパラレル処理を可能とする機構を、制御プロトコルとみなすこともできます。
１２．２．７ レイアウトタイプ
レイアウトは、ファイルのデータとストレージデバイスのマッピングを記述します。レイアウトは、あるレイアウトタイプ（layouttype4, see Section 3.3.13）に属します。レイアウトタイプは、block/volume [41], object [40], ファイル（１３節）のような、異なるストレージプロトコルを可能とします。メタデータサーバーは、その制御プロトコルに加えて、少なくとも１つのレイアウトタイプをサポートしなくてはいけません。レイアウトタイプネームスペースの、プライベートなサブレンジも定義されており、内部的なテストや実験に使うことができます。(see Section 3.3.13)
例えば、ファイルレイアウトタイプは、タプル（デバイス ID とファイルハンドル）の配列として構成されることができます。それに、データがどのようにデバイス間で格納されるかという定義（ストライピング）も必要です。ブロック／ボリュームレイアウトでは、＜デバイス ID,ブロック番号、ブロック数＞を持つタプルの配列に、ブロック長やブロック番号に対応するファイルオフセットの情報を加えたものとなるでしょう。オブジェクトレイアウトでは、＜デバイス ID、オブジェクト ID＞のタプル配列に、ファイルデータの論理的バイト列が異なるオブジェクトの間にどのようにシリアライズされるかを決める追加の構造（aggregation map）を加えたものとなるでしょう。なお、実際のレイアウトは、上記の例よりずっと複雑でしょう。
pNFS に関連する操作の要求は、レイアウトタイプを指定することが多いです。操作の例としては、GETDEVICEINFO and LAYOUTGET があります。これらの操作の応答は、device_addr4 or a layout4 構造体を含み、その中にレイアウトタイプがあります。サーバーが送るレイアウトタイプは、クライアントが要求したものと常に等しくなくてはならず、そうでないときは、クライアントは応答を無視して、エラーとして扱うべきです。
１２．２．８ レイアウト
レイアウトは、ファイルのデータがストレージデバイスにどのように配置されるかを決めます。レイアウトタイプはいろいろあり、データをアクセスするのに使うストレージプロトコルと、ファイルデータを元になるストレージデバイスに配置する集約スキーマにより区別されます。レイアウトは、タプル＜クライアント ID,ファイルハンドル、レイアウトタイプ、iomode 、範囲＞で正確に識別されます。ファイルハンドルは、メタデータサーバーにおけるそのファイルのファイルハンドルです。２つのレイアウトがオーバーラップあるいは競合する条件を決めることは重要です。バイト位置がオーバーラップする２つのレイアウトが実際にオーバーラップするためには、レイアウトタイプ、ファイルハンドル、 iomode が同じである必要があります。オーバーラップして、かつ、レイアウトの内容（つまり、ストレージデバイスやファイルマッピングのパラメーター）が異なる場合、レイアウトは競合します。 iomode の違いは、競合を起こしません。同じクライアントが、同じバイト範囲のレイアウトを、異なる iomode で保持するのは許されます。これは、ブロック／ボリュームレイアウトタイプのときの、コピーオンライト機能で使われます。
１２．２．９ レイアウト iomode
レイアウト iomode (data type layoutiomode4, see Section 3.3.20) は、クライアントが READ 操作だけをするつもりか、 WRITE もするかをメタデータサーバーに示します。レイアウトタイプによっては、クライアントが LAYOUTGET (Section 18.43) を送るときにこの意図を指定することが役に立ちます。例えば、ブロック／ボリュームベースのプロトコルでは、LAYOUTIOMODE4_RW iomode が指定された時に、ブロック確保をすることができます。特別な、LAYOUTIOMODE4_ANY iomode が定義されており、これは、LAYOUTRETURN and CB_LAYOUTRECALL, で使われます。 LAYOUTGET で使うことはできません。それは、READ あるいは RW モードのレイアウトを返却あるいは回収するために指定されます。
ストレージデバイスは、 iomode により、I/O をチェックすることもありますが、これは実装とレイアウトタイプによります。このため、クライアントの iomode が実行される I/O と矛盾するとき、ストレージデバイスは、エラーを返して、正しい iomode を持つレイアウトを LAYOUTGET で取得し直すようにさせることがあります。例えば、クライアントがレイアウトを LAYOUTIOMODE4_READ iomode で取得して、ストレージデバイスに WRITE を発行した場合、ストレージデバイスはその WRITE を拒否することができます。
レイアウト iomode と、OPEN の共有モードあるいはバイトレンジ LOCK 操作とは競合しません。それらは、pNFS でないときと同様に適用され、論理的に、レイアウトレベルとは別のものです。オープンの共有モードとバイトレンジロックは、ユーザーのデータファイルへのアクセスを制限する良い方法です。OPEN of OPEN4_SHARE_ACCESS_WRITE は、他のクライアントの発行する LAYOUTIOMODE4_RW を持つ LAYOUTGET とは競合しません。同じファイルに同時に書き込みをするアプリケーションは、バイトレンジロックを使うのが良いでしょう。
１２．２．１０ デバイス ID
デバイス ID (data type deviceid4, see Section 3.3.14) は、ストレージデバイスのグループを示します。デバイス ID のスコープは、＜クライアント ID,レイアウトタイプ＞です。実際にストレージデバイスを完全に位置づけるには、多くの情報が必要となることがあるでしょう。それらすべての情報をレイアウトに入れる代わりに、デバイス ID が使われます。NFSv4.1 GETDEVICEINFO (Section 18.40) 操作が、あるレイアウトタイプとデバイス ID に関するストレージデバイスの完全なアドレス情報（そのデバイス ID のすべてのデバイスアドレスを含む）を得るために使われます。例えば、NFSv4.1 データサーバーや、オブジェクトベースのストレージデバイスのアドレスとは、 IP アドレスとポートかもしれません。ブロックストレージデバイスのアドレスとは、ボリュームラベルかもしれません。
クライアントは、メタデータサーバーが再開始したときに、デバイス ID とストレージデバイスのアドレスのマッピングが不変である期待はできません。その場合の回復手段については、Section 12.7.4 を参照下さい。
デバイス ID は、それを参照するレイアウトがある限り、有効です。参照するレイアウトがなくなったら、サーバーはデバイス ID を解放することができます。その場合、サーバーは、同じレイアウトタイプとクライアント ID に対して、同じデバイス ID を再使用してはいけません。デバイス ID は１６バイトなので、サーバーがジェネレーション番号を含めるのに十分な長さがあると思われます。この条件は、デバイス ID 追加と削除の非同期の通知の間の競合を防ぐために必要です。
デバイス ID とデバイスアドレスのマッピングはリースされるものではないため、いつでも変更されます。（メタデータサーバーが再開始するとマッピングは変更されるのが普通でしょうが、サーバーはそれを変更しないこともできます。）サーバーがマッピングを変えるときには、２つの選択肢があります。そのデバイス ID を使うすべてのレイアウトを回収するか、通知機能を使うかです。
NFSv4.1 プロトコルには、特定のデバイス ID に対応するレイアウトをすべて回収するための最適な手段はありません。（もし、サーバーが、１つのデバイス ID を１つの fsid あるいは、１つのクライアント ID に対応つけた場合は、CB_LAYOUTRECALL の、特定の fsid, クライアントID の組もしくは、特定のクライアント ID に対応するすべてのレイアウトを回収するオプションが使えます。）
通知機能(see Section 20.12)を使って、サーバーが動作したまま、レイアウトの回収も失効もせずに、マッピングを変えることができます。
参照するレイアウトがないとき、通知機能により、デバイス ID を削除することもできます。通知により、マッピングのすべてあるいは一部は、ただちにあるいはいずれ、無効となります。サーバーは通知をサポートしなくてはならず、クライアントは、それを使う前に要求する必要があります。詳しくは、Section 20.12 を参照下さい。
１２．３ pNFS 操作
NFSv4.1 には、レイアウトタイプやストレージプロトコルによらず、pNFS サーバーが必要とする操作がいくつかあります。
これらはすべて、メタデータサーバーに送られます。以下に概要を示します。pNFS はオプショナルな機能ですが、もしそれが実装されるならば、pNFSに準拠するために必要な操作があります。Section 17 を参照ください。
これは、フロントチャネル操作です。
GETDEVICEINFO (Section 18.40), 以前に述べたように、 (Section 12.2.10), デバイスＩＤ とストレージデバイスアドレスのマッピングを返します。
GETDEVICELIST (Section 18.41) クライアントが、そのファイルシステムのすべてのデバイスＩＤを得るのに使います。
LAYOUTGET (Section 18.43) クライアントが、ファイルのレイアウトを得ます。
LAYOUTCOMMIT (Section 18.42) クライアントが、ストレージデバイス（LAYOUTGET で得たストレージデバイス）に書き込んだデータをコミットしようとしていることを、メタデータサーバーに伝えます。
LAYOUTRETURN (Section 18.44)ファイルのレイアウト、ファイルシステムＩＤ (FSID), あるいはクライアント ＩＤ を返します。
以下は、バックチャネル操作です。
CB_LAYOUTRECALL (Section 20.3) ある特定のレイアウト、あるファイルシステムのすべてのレイアウト、あるいは、あるクライアント ＩＤ が持つすべてのレイアウトのいずれかを回収します。
CB_RECALL_ANY (Section 20.6) クライアントが、いくつかの回収可能なオブジェクト、これにはレイアウトも含みます、をメタデータサーバーに返すように指示します。
CB_RECALLABLE_OBJ_AVAIL (Section 20.7) 以前に、資源不足のために拒否された回収可能オブジェクト（pNFS の場合、LAYOUTGET の失敗）が、使用可能になったことをクライアントに伝えます。
CB_NOTIFY_DEVICEID (Section 20.12) デバイス ＩＤ の変化をクライアントに伝えます。
１２．４ pNFS 属性
pNFS 固有のいくつかの属性があり、５．１２で記述されています。
１２．５ レイアウトのセマンティクス
１２．５．１ レイアウトが保証するもの
レイアウトは、クライアントに、ストレージデバイスにあるデータを適当なストレージプロトコルでアクセスすることを許可します。レイアウトは、以下の２つのどれかが起きた時に回収されます。競合するレイアウトが要求されるか、レイアウトに含まれる状態が無効になる（イベントにより、レイアウトが直接あるいは間接的に更新される場合）かです。レイアウトが回収され、クライアントにより返却されても、クライアントはメタデータサーバーを経由して、通常の NFSv4.1 操作によって、ファイルデータをアクセスし続けることができます。ストレージデバイスをアクセスする能力だけが影響を受けます。
すべてのユーザーアクセス権は、適当な OPEN, LOCK, and ACCESS 操作によって獲得されなくてはいけないという NFSv4.1 の要求は、レイアウトがあっても、同じです。レイアウトは NFSv4.1 クライアントに提供され、ユーザーアクセスは、レイアウトのあるなしと関係なしに、プロトコルの規則に従います。クライアントがストレージデバイスをアクセスするときにはそのクライアントがレイアウトを持たなくてはいけません。ストレージデバイスが、クライアントがレイアウトを保持しないバイト範囲に I/O 要求を受けたら、ストレージデバイスはそれを拒否するべきです。一般的には、レイアウトが保持されているファイルを更新することは、かまいません。ストレージプロトコルとレイアウトタイプが、必要なふるまいを決めます。例えば、ブロック／ボリュームレイアウトタイプでは、レイアウトの iomode が実行される I/O と一致している必要があります。
使われるストレージプロトコルとレイアウトタイプによっては、ストレージデバイスのアクセス権限が LAYOUTGET で許可され、そのタイプ固有のレイアウトにエンコードされることがあります。[50] の、オブジェクトベースのプロトコルに例があります。アクセス権がレイアウトにエンコードされているならば、メタデータサーバーはこれらの権限が無効になった時にレイアウトを回収するべきです。ファイルがクライアントから書き込みできなくなったとか、アクセスできなくなったなど。なお、クライアントは以前に述べたとおり、適当な OPEN, LOCK, and ACCESS 操作が必要です。クライアントがこれらの操作を回避できる度合いと、そうしたときの結果は、それぞれのレイアウトタイプの仕様にきちんと書かれるべきです。さらに、仕様では、サーバーの行うチェックの要件と要件でないものがきちんと書かれるべきです。
１２．５．２ レイアウトを得る
クライアントは、 LAYOUTGET 操作でレイアウトを得ます。メタデータサーバーは、特定のタイプのレイアウトを（ブロック／ボリューム、オブジェクト、あるいはファイル）許可します。クライアントは、サーバーがサポートし、クライアントが使うことのできる適当なレイアウトタイプを選択します。クライアントに返されるレイアウトは、クライアントが要求したバイト範囲とは必ずしも同じでないこともあります。Section 18.43.3 を参照。クライアントは必要に応じて複数の LAYOUTGET 操作を送ることがあります。その結果、複数のオーバーラップする、競合のないレイアウトができることがあります。(see Section 12.2.8)
レイアウトを得るには、クライアントはまずそのファイルを OPEN 操作で開く必要があります。クライアントがファイルにレイアウトを持っていない場合は、loga_stateid 引数に、オープン、委譲、あるいはバイトレンジロックの stateid を指定しなくてはいけません。LAYOUTGET が成功すると、応答にレイアウト stateid が返ります。レイアウト stateid 以外を引数に持った、最初の成功した LAYOUTGET は、応答のレイアウト stateid の「seqid」フィールドが１に設定されていなければいけません。以降、クライアントは、そのファイルへの LAYOUTGET に、レイアウト stateid (see Section 12.5.3)
を使い、「seqid」はゼロに設定されてはいけません。一度取得されたレイアウトは、複数の OPEN and CLOSE シーケンスの間、保持されることができます。このため、クライアントの誰も使っていないファイルのレイアウトをクライアントが持っているという事もあります。レイアウトのキャッシュは、 CLOSE を越えて有効です。
クライアントがストレージデバイスのデータをアクセスするために使うストレージプロトコルは、レイアウトタイプによって決まります。レイアウトを解釈して使う方法と、レイアウトタイプを対応つけるのはクライアントの責任です。この、レイアウトタイプの選択方法は、 pNFS 機能のスコープ外です。
メタデータサーバーがファイルのレイアウトの制御をするのですが、 pNFS クライアントは、ファイルをオープン、あるいは作成するときに、望みのレイアウトタイプと集約スキーマのヒントをサーバーに提供することができます。layout_hint 属性(Section 5.12.4)により、クライアントはファイル作成のときにヒントを伝えることができます。ファイルが作成された後で、この属性を設定しても、サーバー実装によっては、それを採用するのが不可能のことがあります。
EXCLUSIVE4 createmode4 だと、ファイル作成のときに属性を設定することができないので、NFSv4.1 では EXCLUSIVE4_1 createmode4 を導入し、それを可能としました。さらに、セッションが永続的応答キャッシュつきで作成された時、 EXCLUSIVE4_1 は必要でもなく、許可されてもいません。その代わりに、GUARDED4 が使えます。Table 10 in Section 18.16.3 に、クライアントが排他的作成をどのようにできるかがまとめられています。
１２．５．３ レイアウト stateid
他のすべての stateid と同じように、レイアウト stateid は、"seqid" と "other" フィールドがあります。一度レイアウト stateid が確立したら、 "other" は一定で、 stateid が失効したり、クライアントがファイルのすべてのレイアウトを返してサーバーが stateid を破棄するまで変わりません。"seqid" フィールドは最初は１に設定され、フォアチャネル、バックチャネルを問わず、レイアウト stateid を使うすべての NFSv4.1 操作において、ゼロではありません。レイアウト stateid が確立された後、サーバーは、以降の LAYOUTGET and LAYOUTRETURN 応答、そして、CB_LAYOUTRECALL 要求のたびに、"seqid" を１つづつ加算します。
pNFS の設計目的が、並列処理を可能とすることですから、レイアウト stateid は他の stateid と違って、クライアントが LAYOUTGET and LAYOUTRETURN 操作を並列して発行することを考慮しなくてはいけません。"seqid" フィールドは、クライアントがLAYOUTGET 応答と LAYOUTRETURN を正しくソートするために使われます。"seqid" はまた、LAYOUTGET と CB_LAYOUTRECALL の競合を防ぐためにも使われます。レイアウト stateid と、他の stateid とで、処理ルールが違いますから、この文書の pNFS セクションだけが、レイアウト stateid の扱いを決めるものとします。
クライアントは、レイアウト stateid を受け取ったら、以降の LAYOUTGET or LAYOUTRETURN 操作で正しい "seqid" を使わなくてはいけません。正しい "seqid" とは、完全に処理された LAYOUTGET あるいは LAYOUTRETURN 操作の応答、あるいは、完全に処理された CB_LAYOUTRECALL の引数の中で、最高の "seqid" 値として定義されます。サーバーはレイアウト操作のたびに "seqid" を加算しますから、クライアントはそれを見れば、操作された順番を知ることができます。オーバーラップするレイアウト範囲の場合、順序情報によりクライアントはどのレイアウトが保持されているかを知ることができます。なお、オーバーラップするレイアウトは、クライアントの特定の要求によってできることもありますし、サーバーが要求されたレイアウト範囲を拡張して、クライアントに LAYOUTRETURN 応答で知らせる結果起きることもあります。レイアウト stateid のシーケンシングについてのその他の要件は、Section 12.5.5.2 を参照下さい。
クライアントが "seqid" を受け取っただけでは、以降の使用には不十分です。クライアントは、完全にその操作を処理しなくてはいけません。 LAYOUTGET 応答ならば、クライアントが忘れっぽいモデル(Section 12.5.5.1)を使っているのでなければ、クライアントは自分が持っているレイアウトの範囲をまず更新しなくてはいけません。LAYOUTRETURN 応答ならば、自分が持っているレイアウト範囲からそれを削除しなくてはいけません。CB_LAYOUTRECALL 引数ならば、回収の応答を投げなくてはいけません。クライアント処理の基本的要請は、 "seqid" は処理の順序を示すために使われるという事です。 複数の LAYOUTGET 応答は、並列実行されることができます。複数の LAYOUTRETURN 応答は、並列実行されることができます。LAYOUTGET と LAYOUTRETURN 応答は、範囲がオーバーラップしていなければ並列実行されることができます。CB_LAYOUTRECALL 要求の処理は、常に、 "seqid" 順に行われなくてはいけません。
クライアントがファイルにレイアウトを何も持たなくなったら、レイアウト stateid は無効で、使ってはいけません。使うと、NFS4ERR_BAD_STATEID になります。
１２．５．４ レイアウトをコミットする
いろいろなストレージプロトコルを許容するために pNFS は、メタデータサーバーとストレージデバイスが、ファイルの属性とデータ位置のマッピングに関して、一貫した見方をすることを要求しません。データ位置のマッピングとは、どのオフセットが、実際のデータを格納するのではなくてホールであるかということです。（１３．４．４節を参照ください。）同様に、レイアウトが以前に確保されたブロックを含む一方、クライアントとサーバーの完全な再起動があると、これらのブロック確保が忘れられてしまうという問題もあります。
この矛盾を防ぐためには、クライアントがメタデータサーバーとストレージデバイスと同期して、すべての潜在的な変更が、他のクライアントにも見えるようにする必要があります。これは、 LAYOUTCOMMIT 操作によって行われます。
LAYOUTCOMMIT 操作は、変更されたレイアウトを、メタデータサーバーにコミットします。LAYOUTCOMMIT に先立って、データは、適当なストレージデバイスに書き込まれ、コミットされる必要があります。LAYOUTCOMMIT のスコープは、使われるストレージプロトコルによります。同期のLAYOUTCOMMIT を送ったクライアントの立場からであることに注意ください。メタデータサーバーでの更新された状態は、LAYOUTCOMMIT の前のクライアントの最後の操作を反映する必要があるだけです。メタデータサーバーは、そのときに同時に行われた他のクライアントのI/O を含むグローバルなビューを維持する必要はありません。
ブロックあるいはボリュームベースのレイアウトでは、LAYOUTCOMMIT は、ファイルを構成するブロックリストを更新して、このレイアウトをステーブル記憶域にコミットすることを意味するでしょう。ファイルベースのレイアウトでは、メタデータサーバーとストレージデバイスの間の、属性、特に、ファイル長、の同期が必要でしょう。
制御プロトコルは、LAYOUTCOMMIT を受ける前に属性を同期させてもかまいません。しかし、LAYOUTCOMMIT の成功の後は、メタデータサーバーにある、そのファイルについての状態は、クライアントの最後の操作のときにそのファイルを構成するストレージデバイスと同期している必要があります。このため、ストレージデバイスへのライトと、LAYOUTCOMMIT の間にファイル長を問い合わせるクライアントは、実際に書かれたデータとは対応しないファイル長を見ることがあります。
クライアントは、LAYOUTCOMMIT を送るためには、レイアウトを持たなくてはいけません。
１２．５．４．１ LAYOUTCOMMIT と change/time_modify
サーバーが LAYOUTCOMMIT を処理した時、change と time_modify 属性が変わることがあります。レイアウトタイプによっては、ストレージデバイスが I/O を処理するときにはこれらの属性を更新することができないためです。クライアントがLAYOUTIOMODE4_RW iomode のレイアウトを持っている場合、クライアントはサーバーに、LAYOUTCOMMIT の引数に入れて、 time_modify 値を提案することができます。レイアウトタイプによって、これが使われるかどうかはわかりません。サーバーは、使う前には、値の妥当性チェックをするべきです。例えば、時刻が逆走しないか、など。クライアントは、明示的に SETATTR 操作で、 time_modify を設定することもできます。
ストレージプロトコルによっては、ストレージデバイスがメタデータサーバーに I/O の発生を伝えることができます。この結果、change と time_modify 属性がメタデータサーバーで更新されることができます。change と time_modify 属性の変更を監視できるメタデータサーバーにとっては、LAYOUTCOMMIT 処理で change 属性を変える必要はありません。この場合、メタデータサーバーはその属性の更新以降、データの更新が無いことを保証しなくてはいけません。ファイルベースのプロトコルでは、それは容易なことで、ファイルの更新のたびに、 change 属性を変えることもできます。今述べたことは、 time_modify 属性についても同じです。サーバーが、最後の time_modify 属性の変更以降、ファイルの変更が無いことを保証できるなら、LAYOUTCOMMIT 処理で time_modify 属性を変える必要はありません。ファイルが前回の LAYOUTCOMMIT あるいは LAYOUTGET 以降変更されているなら、LAYOUTCOMMIT の完了時に、変更された前記属性は見えるようにならなくてはいけません。
１２．５．４．２ LAYOUTCOMMIT と長さ
クライアントが LAYOUTCOMMIT をすることでファイル長が変わることがあります。LAYOUTCOMMIT の引数に loca_last_write_offset があります。これは、今までに書かれた最高位のバイトオフセットであって、LAYOUTCOMMIT でコミットされていないものです。loca_last_write_offset のデータ型は newoffset4 であり、以前のライトがあったかどうかを示すブール値 no_newoffset でスイッチされます。no_newoffset が偽なら、オフセットは指定されません。クライアントがそのファイルの LAYOUTIOMODE4_RW iomode のレイアウトを持っており、lo_offset とlo_length で示されるそのバイト範囲が、loca_last_write_offset とオーバーラップするなら、クライアントは no_newoffset を真にして、オフセットを提供し、ファイル長を変更することができます。なお、オフセットとファイル長は、関連していますが、同じではないことに注意下さい。例えば、loca_last_write_offset がゼロは、１バイトがオフセットゼロに書かれたことを意味します。なので、ファイル長は少なくとも１バイトです。
メタデータサーバーは、以下のいずれかを実行します。
１ クライアントが提供した最後の書き込みオフセットを使って、ファイル長を更新します。これは、ファイルの本当の長さの時も、そのヒントの時もあります。メタデータサーバーは可能なら、ファイル長として与えられた新しい値の有効性を検証するべきです。例えば、クライアントが現在のファイル長より小さい最後の書き込みオフセットを提供したのでない限り、ファイルは切り詰められてはいけません。訳注。原文逆。
２ クライアントが提供した最後の書き込みオフセットを無視します。メタデータサーバーはファイル長を決定するための、他の情報源からの十分な知識を持っていなければいけません。例えば、メタデータサーバーが制御プロトコルを使ってストレートデバイスに問い合わせるなどです。
ファイル長を更新する方法は、ストレージデバイスと制御プロトコルの能力に依存します。例えば、ストレージデバイスがブロックデバイスで、ファイル長について何も知識がない場合は、メタデータサーバーはクライアントが最後の書き込みオフセットを正しく設定してくることに頼るほかありません。
LAYOUTCOMMIT 応答は、newsize4 ユニオンデータ型の形で、新しい長さを返します。ファイル長が、LAYOUTCOMMIT の結果により設定されたならば、メタデータサーバーは新しい長さを返さないといけません。そうでない場合、新しい長さは返されません。ファイル長が更新されたら、メタデータサーバーはストレージデバイスを更新して、LAYOUTCOMMIT 処理が完了した時には新しいファイル長が反映されるようにするべきです。例えば、クライアントは新しいファイル長までのデータを読むことができるべきです。
クライアントは、長さ属性のある SETATTR 操作をメタデータサーバーに送ることによって、ファイルの長さを伸ばしたり縮めたりできます。指定された長さが現在のファイル長より大きければ、ファイルは「ゼロ拡張」されます。つまり、ゼロデータが、以前の EOF と新しい EOF の間に暗黙的に追加されます。（多くの実装で、ゼロ拡張されたバイト範囲は、領域が確保されていないホールになります。）クライアントが WRITE により、EOF を越えて書き込む場合、 SETATTR 操作は不要です。
１２．５．４．３ LAYOUTCOMMIT と layoutupdate
LAYOUTCOMMIT 引数には、データ型 layoutupdate4 (Section 3.3.18) の loca_layoutupdate (Section 18.42.1) フィールドがあります。この構造は、レイアウトタイプ固有です。これは、LAYOUTCOMMIT 時に、クライアントからメタデータサーバーにレイアウト固有の任意の情報を渡すのに使います。例えば、ブロック／ボリュームレイアウトの場合、予約あるいは確保されたブロックのうち、クライアントが使ったものと使わなかったものを伝えることができます。loca_layoutupdate (field lou_body) の内容は、 LAYOUTGET (Section 18.43.2)のときに、loc_body field of the lo_content field of the logr_layout field に返されるものと同じである必要はありません。 loca_layoutupdate の内容はレイアウトタイプの仕様で定義され、LAYOUTCOMMIT からは不透明です。
１２．５．５ レイアウトを回収する
レイアウトは、クライアントがストレージデバイスとの直接のパスを使うときのクライアントのファイルへのアクセスを保護するものですから、レイアウトは、セマンティクス的にこの機能を果たすことができない場合に限って回収されるべきです。典型的には、これは、レイアウトが、それが示すファイルのバイト範囲の正しい位置を示さなくなったときに起きます。レイアウトを変更する任意の操作、あるいはアクション（サーバーでの再ストライプやロードバランス）は、レイアウトの回収につながります。レイアウトは、CB_LAYOUTRECALL コールバック(see Section 20.3) で回収され、LAYOUTRETURN (see Section 18.44) で返却されます。CB_LAYOUTRECALL は、バイト範囲で指定される特定のレイアウト、あるファイルシステム ID (FSID) に関連するすべてのレイアウト、あるクライアント ID のすべてのレイアウト、を回収することができます。Section 12.5.5.2 ではレイアウトの取得、返却、そして回収についてのシーケンシングについて議論がされます。
レイアウトを回収するとき、 iomode も指定されます。普通は、回収要求の iomode と、応答の iomode は同じであるはずです。例えば、 LAYOUTIOMODE4_RW 指定の回収要求は、クライアントに LAYOUTIOMODE4_RW を返却させますが、LAYOUTIOMODE4_READ は返却させません。しかし、特別な LAYOUTIOMODE4_ANY が定義されており、このときはクライアントは両方を返却します。
REMOVE 操作があったら、メタデータサーバーはレイアウトを回収するべきです。クライアントが存在しないファイルをアクセスするのをやめさせ、クライアントにある状態を回収する必要があります。REMOVE は、ファイルの最後のクローズがされるまで遅れることがあるので、レイアウト回収も遅れることがあります。ファイルの最後の参照が解放されて、ファイルが削除された後は、クライアントはそのレイアウトを使って I/O をできてはいけません。ファイルベースのレイアウトの場合、データサーバーは、削除されたファイルへのすべての操作に NFS4ERR_STALE を返すべきです。
一旦レイアウトを返却したら、クライアントはそのレイアウトが示すファイル、バイト範囲、 iomode に対してストレージデバイスに I/O を投げてはいけません。クライアントが持っていないレイアウトに I/O を出したら、ストレージデバイスは、I/O を拒否すべきです。
pNFS がクライアントのファイルキャッシュ能力やセマンティクスを変えることはありませんが、クライアントによっては、pNFS の利点を最大にするためによりアグレッシブなライトアフターキャッシングをすることがあるでしょう。しかし、その場合、CB_LAYOUTRECALL の応答としてレイアウトを返却する時の遅延を増大する負の効果があります。これは、ファイル委譲について、ファイルデータキャッシングが DELEGRETURN に与える影響と同じです。クライアント実装は、いつの時点でも、保持する書き込まれていないデータの量を制限して、CB_LAYOUTRECALL の応答に時間がかかりすぎることのないようにするべきです。レイアウト回収を要求したら、サーバーは次のアクションを取る前に１リース期間、待たなくてはいけません。リース期間が過ぎたら、サーバーは、クライアントがいつまでもレイアウトを返してこないと判断した場合は、クライアントのストレージデバイスへのアクセスをフェンスするかもしれません。しかし、データ委譲と DELEGRETURN の時と同じように、サーバーは、クライアントがレイアウトを返そうとして進捗を見せていると判断したら、待つかもしれません。進捗とは、例えば、クライアントがストレージデバイスにアクセスすることや、レイアウトの一部を返却することなどです。サーバーは、あらかじめ、レイアウトに含まれるバイト範囲を制限して、未書き込みデータの量を減らすことで、この問題を避けることもできます。
１２．５．５．１ レイアウト回収コールバックの頑強さ
pNFS クライアントのファイルの状態（レイアウトの範囲と iomode）は、サーバーのそれと全く同じであると今まで仮定してきました。これに従うと、サーバーとクライアントは維持されている状態について合意しているため、 LAYOUTRETURNあるいはその組によって返されるコールバックへの応答は、コールバックで要求される範囲と全く同じであると思われます。しかし、ある場合には、この仮定を除いたほうが都合が良いことがあります。例えば、
o コールバックが必要となる競合がまれであり、サーバーがクライアントごとの資源を回復するのに複数ファイルのコールバックを使うことができるならば、（つまり、FSID 指定の回収あるいは、１つの CB_COMPOUND の中の複数ファイルの回収）クライアント、サーバー間の pNFS トラフィックを大いに減らすことができます。
o サーバーは、クライアントが保持している範囲を、荒い粒度で管理するのが便利なことがあります。この結果、サーバーのレイアウト範囲は、クライアントが実際に持っているものより広くなります。極端な場合、サーバーはファイルベースで競合を管理して、クライアントがファイルの一部を要求、獲得した場合でもファイル全体の回収コールバックを送ることがあるでしょう。
o 逆に、クライアント側が、正確に自分が持っている範囲を「忘れて」、サーバーのレイアウト範囲がクライアントが持っていると「思う」ものより大きくなるというのも、便利なことがあります。クライアントが、サーバーが許可したものより大きいレイアウトを持っていると仮定しない限り、これは問題ありません。クライアントが持っている範囲とレイアウトを忘れ、 CB_LAYOUTRECALL を受けたなら、クライアントはサーバーが要求したものを、 LAYOUTRETURN で応答しなければいけません。あるいは、要求された範囲にレイアウトを持たないならば、 NFS4ERR_NOMATCHING_LAYOUT を返します。
o 誤りを避けるために、クライアントが、サーバーが許可した以上のレイアウトを使わないことと、サーバーが、自分が許可したレイアウトを忘れないことは重要です。その一方、サーバーが、クライアントが持っていると信じるレイアウトを、クライアント自身は知らない場合、クライアントは、 LAYOUTRETURN で要求された範囲をいわれるまま返却するか、 CB_LAYOUTRECALL に NFS4ERR_NOMATCHING_LAYOUT を返して、回収要求を完了させるのも良いことでしょう。
これらの例でわかるように、サーバーが、自分が許可していないレイアウト範囲を回収するためのコールバックを送ったり、クライアントが自分で持っていない範囲を返却することができるのは、便利なことがあります。pNFS クライアントは常に、回収で要求された完全な範囲のレイアウトを返却する必要があります。なお、完全なレイアウト範囲は、一度の操作で返す必要はなく、部分的な返却もできます。これによりクライアントは、ダーティデータのフラッシュとコミット、そしてレイアウト返却を、段階に分けて行うことができます。また、メタデータサーバーは、クライアントが進展を見せていることを知ることもできます。
レイアウトが返却されるとき、クライアントはそのレイアウトに関連するストレージデバイスに実行中の I/O 要求があってはいけません。繰り返しますと、クライアントは、実行中の I/O 要求があるうちは、レイアウトを返してはいけません。
クライアントがこれを守っても、I/O 要求が、その実行が許可されなくなったストレージデバイスに届くことはありえます。サーバーは、クライアントがレイアウトをいつ返すかについて完全な制御を持ちませんから、サーバーは、回収要求後しばらくして、一方的にレイアウトに示されるストレージデバイスへのクライアントアクセスを失効させるかもしれません。その時、サーバーは、漂っている I/O 要求に対処しなくてはいけません。つまり、失効されたレイアウトにあるストレージデバイスへの I/O が飛んでくる途中という事です。すべてのレイアウトタイプ仕様は、メタデータサーバーによる一方的なレイアウト失効をサポートするか示す必要があります。サポートする場合、漂うライトをどう処理するか示す必要があります。例えば、失効されたレイアウトにあるストレージデバイスを、レイアウトを持っていたクライアントからフェンスするなど。
レイアウト状態について、クライアントとサーバーを収束させるために、ある回収に対する LAYOUTRETURN シーケンスの最後の LAYOUTRETURN は、回収される範囲の全体を指定しなくてはいけません。つまり、回収要求にあったレイアウトタイプ、 iomode、回収タイプ（FILE, FSID, or ALL）そしてバイト範囲を、エコーバックします。既に部分的に返されたレイアウトがあってもです。また、クライアントが回収要求されたレイアウトとオーバーラップするものを持たない場合、クライアントは CB_LAYOUTRECALL に NFS4ERR_NOMATCHING_LAYOUT を返すべきです。これにより、サーバーはクライアントのレイアウト状態についての自分の見方を更新できます。
１２．５．５．２ レイアウト操作のシーケンシング
ステートを持つ他の操作と同じように、pNFS ではレイアウト操作の正しいシーケンシングが必要です。そのために、レイアウト stateid にある "seqid" を使って、通常の操作とコールバックの順序を正しく保ちます。提供したレイアウトの間の矛盾を防ぐのはサーバーの責任、レイアウト要求と返却を正しくシリアライズするのはクライアントの責任です。
１２．５．５．２．１ レイアウト回収と応答のシーケンシング
レイアウト操作のシーケンシングに関して重要な問題の１つは、コールバックです。プロトコルは、 LAYOUTGET or LAYOUTRETURN の応答と、 CB_LAYOUTRECALL の競合に対処しなくてはいけません。クライアントは、まだ応答をもらっていない LAYOUTGET or LAYOUTRETURN の結果を対象とする CB_LAYOUTRECALL を処理してはいけません。クライアントは、そのような CB_LAYOUTRECALL は、リコールのレイアウト stateid の "seqid" フィールドを見ればわかります。 "seqid" がクライアントが現在記録しているものより１つだけ大きいのでなく、かつクライアントが１つ以上の実行中の LAYOUTGET and/or LAYOUTRETURN 操作を持っているなら、クライアントは、サーバーが、実行中の LAYOUTGET or LAYOUTRETURN に応答を返した後、 CB_LAYOUTRECALL を送ってきたことがわかります。クライアントは、受け取った CB_LAYOUTRECALL の seqid (lor_stateid; see Section 20.3.) より小さい seqid を持つ、そのファイルに関する、実行中の LAYOUTGET and LAYOUTRETURN のすべての応答を処理するまで、 CB_LAYOUTRECALL の処理を待たなくてはいけません。
seqid ベースの機構の他に、 Section 2.10.6.3 は、クライアントがコールバックの競合を検知して、処理を遅らせることのできるセッション機構を説明します。サーバーは、 CB_LAYOUTRECALL の前に出す CB_SEQUENCE で、競合する操作を参照してもかまいません。サーバーはコールバックを送る前に、既にそれらの操作の応答を返したのですから、応答は CB_LAYOUTRECALL と競合する可能性があります。クライアントは、すべての参照されている操作が完了するのを待って、自分のレイアウト状態を更新して、後にCB_LAYOUTRECALL を処理しなくてはいけません。
１２．５．５．２．１．１ Get と返却のシーケンシング
プロトコルでは、クライアントは並列実行する LAYOUTGET and LAYOUTRETURN 操作をサーバーに送ることができます。プロトコルは、サーバーがそれらの要求を、生成された順に処理するための方法を何も提供しません。しかし、クライアントは、レイアウト stateid の "seqid" フィールドを使って、サーバーでそれら並列実行された要求が処理された順を知ることができます。このため、もし LAYOUTGET 操作の結果得られたレイアウトが、同じファイルへの LAYOUTRETURN で返却されたレイアウトと重複する場合、２つの競合する操作が行われた順序が、最終的なオーバーラップするレイアウトの状態を決めます。順序は、それぞれの操作で返される "seqid" で決まります。大きいほうが、後から実行されたものです。
クライアントが、同じファイルに複数の同時実行する LAYOUTGET を送るのはかまいません。 LAYOUTRETURN および、それらの混合も同じ事です。
クライアントが、 LAYOUTGET 操作に、現在の stateid (see Section 16.2.3.1.2) を使うのは、かまいません。例えば、複数の LAYOUTGET を複合（ compound ）したり、 OPEN と複数の LAYOUTGET を複合したりするときなどです。複数の LAYOUTRETURN を複合するときも同じです。
クライアントが、同じ COMPOUND 要求に、同じファイルの LAYOUTRETURN and LAYOUTGET を入れるとき、現在の stateid を使うのは、かまいません。サーバーは、これらを順に処理しなくてはいけませんから。しかし、もしクライアントがそのような複合要求を投げたときは、同時に同じファイルに、１より多くの実行中のものがあってはいけません。さらに、同時に同じファイルに、それ以外の LAYOUTGET or LAYOUTRETURN 操作が実行中ではいけません。
ーーーーーーここからーーーーーー
１２．５．５．２．１．２ クライアントの考察
pNFS クライアントが、LAYOUTGET を送って、その応答を得る前に、同じファイルの、オーバーラップする範囲への CB_LAYOUTRECALL を受けたとします。２つの可能性があり、クライアントは、リコール中のレイアウト stateid で区別することができます。
１． サーバーは、リコールを送る前に、LAYOUTGET を処理しました。このため、クライアントはLAYOUTGET の応答を待つ必要があります。 CB_LAYOUTRECALL でレイアウトを返却するために、LAYOUTGET の応答に含まれるレイアウト情報が必要だからです。
２． サーバーは、LAYOUTGET を受ける前に、コールバックを送りました。サーバーは、CB_LAYOUTRECALL が処理されるまで、LAYOUTGET には応答しません。
これらの可能性が区別できないときには、デッドロックが起きます。最初のケースでは、クライアントはリコールを処理する前に LAYOUTGET の応答を待つ必要がありますが、２つめのケースではその応答はリコールが処理されるまで届かないからです。最初のケースでは、リコールに入っているレイアウト stateid の"seqid" は、クライアントが記録しているものより２つ大きいはすです。２つめのケースでは、１つ大きいはずです。このため、クライアントは２つのケースを確実に区別できます。
ケース１では、クライアントはリコールを処理する前に LAYOUTGET 応答を待つ必要があります。（あるいは、クライアントは NFS4ERR_DELAY を返すこともできます。）
ケース２では、クライアントはリコールを処理する前に LAYOUTGET 応答を待つ必要がありません。待てばデッドロックになるからです。クライアントが待つ必要があるのは、クライアントがサーバーからの以前の LAYOUTGET への応答を受け取っていないときだけです。
リコール処理は、リコールされた範囲に対する最後の LAYOUTRETURN 操作が完了したときに、完了したとみなされます。LAYOUTRETURN は、CB_LAYOUTRECALL で指定されたレイアウトstateid （seqid が含まれます）を使います。クライアントが、１つのリコールを処理するために複数の LAYOUTRETURN を使った場合、最初の LAYOUTRETURN は、CB_LAYOUTRECALL で指定されたレイアウトstateid を使います。続く LAYOUTRETURN は、通常通り、最も大きい seqid を使います。
１２．５．５．２．１．３ サーバーの考察
１２．５．５．２．１．４ seqid の回避と確認
１２．５．５．２．１．５ バルク回収と応答
ーーーーーーここまでーーーーーー
１２．５．６ レイアウト失効
pNFS では、サーバーは、クライアントが回収に応答しないときや、時間内にリースを更新しない時にはレイアウトを失効させることができます。レイアウトタイプにより、サーバーは、レイアウトを失効させたときに、クライアントのデータサーバーへの I/O に関して、アクションをとることがあります。
１２．５．７ メタデータサーバーのライト伝搬
メタデータサーバーを経由する非同期ライトは、ストレージデバイスに、遅れて伝搬されることがあります。その場合、ストレージデバイスを読むクライアントは、メタデータサーバーで COMMIT がされるまで、新しく書かれたデータが見える保証はありません。古いデータ、新しいデータ、両方の混じったものが読める可能性があります。同期ライトあるいはコミット（非同期ライトに対して）の完了後は、メタデータサーバーは、ストレージデバイスが新しいデータを提供し、データはステーブル記憶域に書かれることを保証しなくてはいけません。サーバー実装がこの条件を満たすことのできない場合、レイアウトを回収して、リードが正しいものを読むようにしなくてはいけません、。なお、レイアウトは、サーバーがライトに応答を返す前に回収されなくてはいけません。
１２．６ pNFS のしかけ
この節では、pNFS クライアントがメタデータサーバーとストレージデバイスに送る操作の流れを説明します。
pNFS クライアントが新しい FSID を見つけたら、NFSv4.1 サーバーに GETATTR を送って、 fs_layout_type (Section 5.12.1) 属性を得ます。属性にレイアウトタイプが含まれ、それがクライアントがサポートしているものであれば、クライアントはそのファイルシステムに pNFS が使えることを知ります。もし、クライアントがそのサーバーから以前に EXCHGID4_FLAG_USE_PNFS_MDS のついた EXCHANGE_ID 結果によってクライアント ID をもらっていないときは、クライアントはそのサーバーに、 EXCHGID4_FLAG_USE_PNFS_MDS ビットを立てた EXCHANGE_ID を送らなくてはいけません。サーバーの応答がそのビットを立てていないときは、 fs_layout_type 属性で言ったこととは違って、サーバーは pNFS をサポートしておらず、クライアントはそのサーバーに pNFS を使えないという事です。この場合、サーバーは、すべての pNFS 操作に対して、 NFS4ERR_NOTSUPP を返さなくてはいけません。
次にクライアントはセッションを作成します。排他的作成が createmode4 を GUARDED4 にした１回のラウンドトリップでできるように、永続的セッションを要求します。永続的セッションが得られなかったときは、クライアントは 排他的作成のために EXCLUSIVE4_1 を使います。
pNFS が有効なファイルシステムでファイルを作成するには、クライアントは、 OPEN 操作を使います。通常の属性の他に、オプショナルな layout_hint 属性があります。それによってクライアントは、レイアウトタイプと関連するレイアウトの詳細についての要求を伝えることができます。createmode4 をUNCHECKED4, GUARDED4 あるいは EXCLUSIVE4_1 EXCLUSIVE4_1 にすることで、クライアントは作成時に layout_hint 属性を与えることができます。クライアントは、EXCLUSIVE4 (see Table 10) を使ってはいけません。クライアントは、１つの COMPOUND の中で、 OPEN の後で GETATTR を出すのをおすすめします。そうすれば、新しく作られたファイルの layout_type 属性を見ることができます。クライアントは、サーバーがどんなレイアウトタイプを選択したかを知り、自分が使うべきストレージプロトコルがわかります。
クライアントが既存のファイルをオープンするとき、GETATTR を含めることで、そのファイルのサポートするレイアウトタイプがわかります。
上記の GETATTR に、さらに layout_blksize と layout_alignment 属性を含めれば、クライアントはそのファイルの I/O に最適なオフセットと長さがわかります。
クライアントが GETATTR で返されたレイアウトタイプをサポートしており、データアクセスに pNFS を使うと決めたとします。クライアントは次に、 OPEN で返されたファイルハンドルと stateid を使い、I/O したい範囲を指定して LAYOUTGET を出します。応答はレイアウトです。クライアントが要求したもののサブセットのこともあります。デバイス ID と、データがデバイス間でどう配置されているか（書き込みの時は、どう配置されるか）の記述も返ります。デバイス ID とデータ配置の記述は、レイアウトタイプ固有のエンコードがされていますが、クライアントは理解できるはずです。
クライアントが I/O を投げるときは、レイアウトのデータ配置記述をもとに、どのデバイスに I/O コマンドを投げるか決めます。次に、デバイス ID からデバイスアドレスを得るために、 GETDEVICEINFO を出します。最後にクライアントは、デバイスアドレスに I/O 要求を投げます。レイアウトタイプに固有のストレージプロトコルを使います。クライアントが複数の I/O を投げるとき、それらは並列に実行されることができます。
I/O が WRITE なら、クライアントは、どこかのポイントで LAYOUTCOMMIT を出して、そのファイルの変更時刻と新しいファイル長を（ファイル長が大きくなったならば）メタデータサーバーに、変更されたデータをファイルシステムにコミットするのが良いでしょう。
１２．７ 回復
pNFS プロトコルの分散した性質のために、回復は複雑です。一般的に、レイアウトの障害回復はベース NFSv4.1 プロトコルの委譲の回復と似ています。しかし、クライアントはメタデータサーバーとコンタクトすることなく I/O する能力がありますから、正しく処理されないとファイルシステム破壊につながるような微妙な問題も発生します。
１２．７．１ クライアント再開始からの回復
クライアントがレイアウトを回復するのは、他のロックや委譲状態の回復と似ています。pNFS クライアントが再開始したら、以前に持っていたレイアウトの情報を忘れます。サーバーがそれら資源を回収して、他のクライアントに与えるためには２つの方法があります。
１つめは、クライアントリースの満了によります。リース期間内にクライアントが回復してこないときは、リースは満了して、サーバーはその状態を解放しても良いと判断します。レイアウトについて、サーバーは、リースが満了したらすぐにそれを解放してもよいですし、他のレイアウトと競合があるまでそのままにして、回復を待つこともできます。
２つめは、リース期間内にクライアントが回復した場合です。クライアントは通常の EXCHANGE_ID でサーバーにコンタクトしようとします。サーバーは、クライアントの co_ownerid が以前のクライアント実行と同じで、ベリファイアが異なることがわかります。サーバーは、これを契機に、以前のクライアント実行に関連ついたすべてのレイアウト状態を解放します。このシナリオで、クライアントが書いたけど、成功した LAYOUTCOMMIT でカバーされないデータは、未定義の状態となります。書き込みは成功したかもしれないし、失われたかもしれません。これは仕方ないことで、 LAYOUTCOMMIT を使って、望むデータ保証レベルを達成するのはクライアントの責任です。
１２．７．２ クライアントでリース満了に対処する
クライアントが、リースが満了したことに気がついたら、リースを再確認するまで、ストレージデバイスに I/O を投げてはいけません。クライアントは、メタデータサーバーに SEQUENCE 操作を投げます。それが成功して、 sr_status_flag がSEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED,
SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED, or
SEQ4_STATUS_ADMIN_STATE_REVOKED が立っていたら、クライアントは今持っているレイアウトを使ってはいけません。クライアントがリース満了に対処するには、２つの選択肢があります。１つめは、クライアントは、すべての、書かれてコミットされていないデータを、 FILE_SYNC4 つきのライトあるいは、ライトとコミットによりメタデータサーバーに送ります。２つめは、クライアントは、サーバーとの間でクライアント ID とセッションを再確立して、変更されたデータ範囲に対する新しいレイアウトとデバイス ID からデバイスアドレスへのマッピングを得て、ストレージデバイスにデータを書き込むというものです。
sr_status_flag に、SEQ4_STATUS_RESTART_RECLAIM_NEEDED が立っている(あるいは、 SEQUENCE が NFS4ERR_BAD_SESSION を返し、CREATE_SESSION が
NFS4ERR_STALE_CLIENTID を返した)場合は、メタデータサーバーが再開始したので、クライアントは Section 12.7.4 の方法で回復するべきです。
sr_status_flag に、SEQ4_STATUS_LEASE_MOVED が立っている場合は、クライアントは Section 11.7.7.1 に従って回復します。その後、クライアントは、レイアウトはファイルシステムとともには移動しなかったといわれることがあります。クライアントはこの節の前記２つのパラグラフに従って回復します。
sr_status_flag が、状態の喪失は無かったと言った場合、クライアントの持っているレイアウトは有効かつ、有効期限が延長されているので、クライアントはストレージデバイスに I/O を投げることができます。
クライアントは、リース満了の後まで続く I/O をストレージデバイスに投げるべきではありませんが、これは不可能なときもあります。例えば、I/O が送られてからネットワーク分断が始まり、ストレージデバイスに I/O が届くまでなおらない時などです。なので、メタデータサーバーも、ストレージデバイスも、リース満了の前に送られた I/O がリース満了後に届くことに対して、自らを防御する責任があります。Section 12.7.3 を参照下さい。
１２．７．３ メタデータサーバーでのレイアウト状態の喪失に対処する
これは、以下のすべてが当てはまるケースの記述です。
o メタデータサーバーは、再開始していません。
o pNFS クライアントのレイアウトは破棄され、無効です。（通常、クライアントのリースが満了したためでしょう）
o pNFS クライアントからの I/O がストレージサーバーに届きました。
メタデータサーバーとそのストレージデバイスは、この場合、クライアントをフェンスすることで対処します。つまり、レイアウト状態が失われたクライアントからの I/O 操作の実行は、阻止されなくてはいけません。実際に、どうやってフェンスするかは、レイアウトタイプによります。NFSv4.1 ファイルベースのレイアウトのときの対策は、13.11 節にあります。その他のレイアウトのときの対策は、それぞれの仕様書にあります。
１２．７．４ メタデータサーバー再開始からの回復
pNFS クライアントは、Section 8.4.2 と、Paragraph 2, of Section 12.7.2 に述べた方法で、メタデータサーバーが再開始したことを知ります。クライアントは、以前にメタデータサーバーから受け取ったレイアウトを使うのをやめ、デバイス ID とアドレスのマッピングを削除しなくてはいけません。それが終わった後で、もしもクライアントがストレージデバイスにデータを書いたことがあり、 LAYOUTCOMMIT でレイアウトをコミットしていないならば、さらにやるべきことがあります。クライアント、メタデータサーバー、ストレージデバイスの間で、データの状態を同期しなくてはいけません。
o もしクライアントが変更後のデータで、書かれていないものをクライアントのメモリーに持っているなら、２つの選択肢しかありません。
１ クライアントは、サーバーのグレースピリオドの後、 LAYOUTGET でレイアウトを得て、ストレージデバイスにデータを書きます。
２ クライアントは、メタデータサーバー経由で、WRITE (Section 18.32) 操作を使ってデータを書きます。レイアウト取得は、その後、必要に応じて行います。
o もしクライアントがストレージデバイスに非同期にデータを書き、自分のメモリーにそのコピーを持っているなら、一つ前に述べた回復方法が使えます。メタデータサーバーが、グレースピリオド内にあるなら、以下に述べる選択肢もあります。
o もしクライアントがデータのコピーを持っておらず、メタデータサーバーが、グレースピリオド内にある場合、クライアントは LAYOUTGET を使ってレイアウトをリクレームすることはできません。（グレースピリオドの中であっても外であっても）なぜならば、 LAYOUTGET の応答は、以前と違うかもしれないからです。レイアウトの範囲が違うかもしれません。レイアウトの内容が違うかもしれません。デバイス ID とアドレスのマッピングが違うかもしれません。アドレスは別のデバイスにアサインされているかもしれません。データをストレージデバイスから読んで、メタデータサーバー経由で書くという回復シナリオは、使えません。レイアウトの範囲からデバイス物理デバイスに至るマッピングは古くなっていて、新しい LAYOUTGET でマッピングを取りなおすことは解決にならないからです。
このシナリオでの唯一の回復方法は、LAYOUTCOMMIT をリクレームモードで投げることです。メタデータサーバーは、グレースピリオドの間に限り、それを受け付けます。リクレームモードの LAYOUTCOMMIT は、メタデータサーバーに、そのレイアウトが変更されたことを伝えます。その知らせを、メタデータサーバーが、グレースピリオドが終わる前に受け取ることが重要です。そうでないと、ファイルシステムの更新を許してしまいますから。
LAYOUTCOMMIT をリクレームモードで投げるには、クライアントは、loca_reclaim フィールドを真にします。(Section 18.42.1) メタデータサーバーは、グレースピリオドの間に限り、それが立っている LAYOUTCOMMIT を受け付けます。
loca_reclaim が真ということは、クライアントが、メタデータサーバーの再開始の前に起きたレイアウト変更をコミットしようとしているという事です。メタデータサーバーは、 loca_layoutupdate フィールドに一定のチェックをして、クライアントがストレージデバイスに書いたデータをファイルシステムにもコミットできるかを確認します。loca_layoutupdate は、 layoutupdate4 型で、レイアウト固有の内容です。（lou_body field of loca_layoutupdate）それについては、Section 12.5.4.3 で議論されます。チェックが成功したら、メタデータサーバーは、ストレージデバイスに書かれたそのデータ（loca_offset, loca_length, and loca_layoutupdate の示す）をコミットしなければいけません。チェックが失敗したら、メタデータサーバーは、 LAYOUTCOMMIT を拒絶して、ファイルシステムに変更は加えません。ただし、loca_reclaim が真の LAYOUTCOMMIT が失敗するという事は、クライアントは <loca_offset, loca_length> の範囲のデータをすべて失うという事です。クライアントは、自分のメモリーに同期も非同期も、すべてのライト済みデータをキャッシュして、 LAYOUTCOMMIT が成功するまで保持することで、この危険に対処できます。この条件は、すべてのレイアウトタイプで有効ではありません。例えば、ファイルベースのストレージデバイスは、この制限を受けません。
o もしクライアントが、自分のメモリーにデータのコピーを持っておらず、メタデータサーバーもグレースピリオドを過ぎている場合、つまり、メタデータサーバーが、 NFS4ERR_NO_GRACE を返す場合、前記のシナリオで述べたとおり、 LAYOUTCOMMIT の失敗は、 <loca_offset, loca_length> の範囲のデータ喪失を意味します。これに対処するのは、前に述べたように、LAYOUTCOMMIT の成功するまでライトデータを保持することです。
１２．７．５ メタデータサーバーのグレースピリオドの間の操作
今まで述べた回復シナリオは、ある種の操作（WRITE と LAYOUTGET）が、メタデータサーバーのグレースピリオドの間、許されることがあると想定してきました。LAYOUTGET についていうと、メタデータサーバーは、それを許すことが、来るかもしれないLAYOUTCOMMIT リクレーム要求と競合しないことを保証しなくてはいけません。WRITE についていうと、それが OPEN あるいは、マンダトリーバイトレンジロックが有効なファイルへの LOCK 要求と競合しないことを保証しなくてはいけません。
以前に述べたように、メタデータサーバーは、簡単のため、ある種の操作（WRITE と LAYOUTGET）を、グレースピリオドの間、拒否することもできます。最も簡単で、正しいアプローチは、すべてのリクレームでない pNFS 操作を NFS4ERR_GRACE でエラーにすることだからです。しかし、ストレージプロトコル（レイアウトタイプによります）と、メタデータサーバー実装によっては、メタデータサーバーは、ある要求が安全かを知ることができます。例えば、メタデータサーバーが、ファイルごとの、記憶域アロケーションマップの予定をステーブル記憶域に退避することが考えられます。あるいは、サーバー再開始のときに競合の可能性が生じるかもしれない、オープンの共有モードとマンダトリーバイトレンジロックを退避するのもよいでしょう。メタデータサーバーは、これらの情報を使って、グレースピリオドの間も、 特定の WRITE が安全だと判断できます。
１２．７．６ ストレージデバイス回復
ストレージデバイスの再開始からの回復は、ほぼ、レイアウトに依存します。しかし、クライアントが、ストレージデバイスが非同期に書かれた変更済みデータで、コミットされていないものを持ったまま落ちたとわかった時に使える、一般的なテクニックがあります。１つめで、最も重要なのは、コミットされていないデータを回復するのに必要な情報を持っているのは、クライアントただ一人だと認識することです。２つめは、クライアントは安全のために、変更済みデータを別のパスを使って、再度書き込みを試みるのが最善だということです。
クライアントは直ちに、stable field in the WRITE4args set to FILE_SYNC4 にしたライトを使って、そのデータをメタデータサーバーに書くべきです。これができたら、元のクラッシュしたストレージデバイスの回復を待つ必要はありません。
１２．８ メタデータとストレージデバイスの役割
同じ物理ハードウエアが、メタデータサーバーとストレージデバイスの両方に使われるとき、ある時点でハードウエアがどちらの役をしているか、注意が必要です。
2つのケースがあります。
１ ストレージデバイスは、NFSv4.1 を、ストレージプロトコルとして使います。つまり、同じハードウエアが、メタデータとデータサーバーに使われます。複数の役割を実行することについて、 Section 13.1 を参照下さい。
２ NFSv4.1 を、ストレージプロトコルとして使いません。同じハードウエアが、メタデータとストレージデバイスに使われます。メタデータサーバーとストレージデバイスで、別のネットワークアドレスが使われるかは問いません。クライアントとサーバーにとって、使う上位プロトコルによって、どっちの役をしているかは明らかだからです。
１２．９ pNFS とセキュリティ考察（大意）
pNFS は、メタデータアクセスとデータアクセスを分離します。前者は、通常の NFSv4.1 セキュリティ機能を使いますからよいとして、問題は後者です。
クライアントからストレージデバイスへの接続のセキュリティが問題となる場合、物理的に接続を隔離する、あるいは、pNFS の使用をやめてしまうという結論になることがあります。例えば、盗聴防止が必要だと言っても、それができないストレージプロトコルもあるでしょう。その場合、クライアントとストレージデバイスを直接つなぐか、pNFS の使用をやめて、通常の NFSv4.1 アクセスをするのが適当なことがあります。
クライアントとストレージデバイスの通信が、メタデータサーバーとの通信と同じくらい、セキュリティ脅威に対処する必要があるなら、使うプロトコルは、NFSv4.1 で RPCSEC_GSS を使っている以上の強度が必要です。次の節で説明する LAYOUT4_NFSV4_1_FILES を除いては、この文書でストレージアクセスプロトコルのセキュリティ機能について述べることはありません。
pNFS 実装は、 NFSv4.1 のアクセス制御を除いてはいけません。クライアント、ストレージデバイス、メタデータサーバーの３者は、すべてのクライアントとストレージデバイスのファイルデータアクセスが、 NFSv4.1 の ACL とファイルオープンモードを尊重するようにする責任があります。この結果、アクセス毎にクライアント、ストレージデバイス、あるいは両者でこれらのチェックをすることになります。（ストレージデバイスが NFSv4.1 サーバーなら、それが、 Section 13.9.2 に述べたように、アクセス制御の最終責任を持ちます。）チェックをクライアントだけが行う場合、行儀の悪いクライアントが、前記アクセスチェックを順守しないおそれがあることが問題となるなら、そのようなレイアウトタイプは使うべきではありません。そういうときは、ファイルレイアウトを使って下さい。レイアウトごとのアクセス制御については、それぞれの仕様書を参照下さい。NFSv4.1/ ファイルレイアウト (Section 13) ブロックレイアウト [41], オブジェクトレイアウト [40]
１３ NFSv4.1 を、pNFS のストレージプロトコルとして使う：ファイルレイアウトタイプ
この節では、pNFS のための、 NFSv4.1 のファイルベースのレイアウトのセマンティクスと形式を記述します。NFSv4.1 のファイルベースのレイアウトは、 LAYOUT4_NFSV4_1_FILES レイアウトタイプを使います。それは複数のデータサーバーで、データをストライプするやり方を定義します。
１３．１ クライアント ID とセッションの考察
セッションは、 NFSv4.1 で必須です。それは、メタデータサーバーにも、ファイルベースのデータサーバーにも適用されます。
サーバーの役割は、EXCHANGE_ID の結果で決まります。
o メタデータサーバー（応答のeir_flags
に EXCHGID4_FLAG_USE_PNFS_MDS がセットされています。）
o データサーバー（EXCHGID4_FLAG_USE_PNFS_DS）
o メタデータサーバーでない。（EXCHGID4_FLAG_USE_NON_PNFS）これは、 LAYOUTGET などの、 pNFS に関連する操作や属性をサポートしないものです。
クライアントは前記３つのフラグのどの組み合わせでも要求できます。EXCHGID4_FLAG_USE_NON_PNFS | EXCHGID4_FLAG_USE_PNFS_MDS など、矛盾する組み合わせもあります。サーバーは、以下の組み合わせしか返すことはできません。
+--------------------------------------------------------+
| Acceptable Results from EXCHANGE_ID |
+--------------------------------------------------------+
| EXCHGID4_FLAG_USE_PNFS_MDS |
| EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_PNFS_DS |
| EXCHGID4_FLAG_USE_PNFS_DS |
| EXCHGID4_FLAG_USE_NON_PNFS |
| EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_NON_PNFS |
+--------------------------------------------------------+
つまり、サーバーは、１つあるいは２つの役割を持つことができます。サーバーは、メタデータサーバーであり、かつデータサーバーであることができます。あるいは、データサーバーであり、メタデータサーバーでないことができます。サーバーは、２つの役割を、同じクライアント ID を使って提供することも、役割ごとに別のクライアント ID とserver owner を使うこともできます。
前者、１つのクライアント ID で２つの役割を行うサーバーの場合、サーバーは、クライアントの要求する EXCHANGE_ID の eia_flags のビット設定を尊重して、組み合わせ可能な最高のビット設定を返すべきです。例えば、クライアントが (EXCHGID4_FLAG_USE_NON_PNFS | EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_PNFS_DS) を要求し、サーバーがメタデータサーバーでありデータサーバーであるなら、サーバーは(EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_PNFS_DS) を返します。
後者、クライアント ID ごとに役割を変える場合、サーバーはクライアントの要求するビット設定の１つだけを立てて返すべきです。返したビットがクライアントの意図と違う場合、クライアントは必要なビットだけを立てた EXCHANGE_ID を送りなおします。
pNFS クライアントが、 NFSv4.1 データサーバーを参照するレイアウトを得たとき、クライアントはそのデータサーバーでのクライアント IDが必要です。まだ、EXCHGID4_FLAG_USE_PNFS_DS が立った EXCHANGE_ID 応答をそのサーバーからもらっていないときは、クライアントは、メタデータサーバーに送ったのと同じ co_ownerid を使い、EXCHGID4_FLAG_USE_PNFS_DS を立てた EXCHANGE_ID をデータサーバーに送る必要があります。サーバーの応答に、 EXCHGID4_FLAG_USE_PNFS_DS が立っていれば、クライアントはそのクライアントID を使ってセッションを作成し、そこで pNFS データ操作を行うことができます。メタデータサーバーから返されるクライアントIDと、データサーバーから返されるそれは、クライアントIDが等しく、かつ、メタデータサーバーとデータサーバーの所有者とスコープが同じである場合を除いては、無関係です。
NFSv4.1 では、 SEQUENCE 操作中のセッションIDは、クライアントIDを前提とします。クライアント IDは、一方、サーバーが stateid を正しいクライアントとサーバーの組にマップするために使われることがあります。
しかし、データサーバーがある stateid を持つ READ あるいは WRITE 操作を受けたときを考えて見ますと、その stateid は、メタデータサーバー上のクライアントIDと関連づいており、以前の SEQUENCE 操作で得たセッションIDはデータサーバー上のクライアントIDと関連づいているため、データサーバーは、前述のREAD あるいは WRITE 操作を含む COMPOUND 手続きだけから、メタデータサーバーが誰なのかを判定する明確な手段がなく、このため stateid の検証もできないことになります。１つの推奨される対策は、pNFS サーバーがメタデータサーバーのルーティングそして／あるいは識別情報を、レイアウトに含まれるデータサーバーファイルハンドルにエンコードすることです。
その場合、メタデータサーバーの識別子や場所が変わったら、発行されたデータサーバーファイルハンドルは無効(stale)になります。このため、メタデータサーバーはまず最初にレイアウトを回収しなくてはいけません。データサーバーファイルハンドルを無効にするだけでは、NFS クライアントのデータキャッシュを無効にできません。クライアントのキャッシュは、データサーバーファイルハンドルをメタデータサーバーファイルハンドルにマップし、メタデータサーバーファイルハンドルをキャッシュされているデータにマップしているからです。
サーバーがメタデータサーバーでもあり、データサーバーでもある場合、受け取ったファイル操作がどちら宛てなのか判定するのに困ることがあるかもしれません。推奨される対策は、LAYOUTGET で返るファイルハンドルの値を、同じファイルを OPEN したときのそれと変えることです。
もうひとつのシナリオは、クライアントによって、メタデータサーバーとストレージデバイスの役割が逆に見えることがあるというものです。例えば、クラスターファイルシステムモデルでは、あるクライアントのとってのメタデータサーバーが別のクライアントにはデータサーバーになることがあるでしょう。ストレージプロトコルに NFSv4.1 が使われる場合、 pNFS サーバーは自分の役割をファイルハンドルにエンコードする必要があります。
１３．１．１ データサーバーのセッション考察
Section 2.10.11.2 では、クライアントは、セッションがサーバーにより削除されるのを防ぐためにリース更新を続ける必要があると述べています。EXCHANGE_ID 応答が、 EXCHGID4_FLAG_USE_PNFS_DS の役割だけを立てている場合、Section 13.6 で述べたように、クライアントはデータサーバーの lease_time 属性を知ることはできません。データサーバーへの GETATTR はできないからです。この場合のルールは、メタデータサーバーの lease_time 属性を使うことです。このため、データサーバーは自分が I/O を提供しているすべてのメタデータサーバーの lease_time 属性を知る必要があり、そのうちの最大値を自分のリース期間として使う必要があります。
例えば、あるメタデータサーバーの lease_time 属性が２０秒で他のが１０秒で、どちらも EXCHGID4_FLAG_USE_PNFS_DS だけの役割のデータサーバーを参照するレイアウトを返すなら、データサーバーは、異なる COMPOUND 手続きに含まれる SEQUENCE 操作の間隔が２０秒以下である時にはクライアントのリースを更新しなければいけません。
１３．２ ファイルレイアウトの定義
以下の定義は、 LAYOUT4_NFSV4_1_FILES レイアウトタイプに適用されます。他のレイアウトタイプにも有効かもしれません。
ユニットは、データサーバーに書かれる、固定長のデータです。
パターンは、１つ以上の同じ長さのユニットをデータサーバーのセットに分配する方法です。パターンは、１回以上繰り返されます。
ストライプは、１回のパターンで配置されるデータの集まりです。
ストライプ数は、１つのパターンの中のユニットの数です。
ストライプ幅は、ストライプの長さをバイトで表したものです。ストライプ幅 ＝ ストライプ数 ＊ ストライプユニットの長さ
パターンを構成するユニットを、｢ストライプユニット」と呼びます。
パターンに含まれるストライプユニットの数は、データサーバーの数より多くなることがあります。その場合、１つのストライプで、１つ以上のストライプユニットを持つデータサーバもあります。データーサーバーはそれぞれのユニットを異なるデータファイルに格納するかもしれません。（実装によっては、それぞれのデータファイルにユニークなファイルハンドルを与えるでしょう。）
１３．３ ファイルレイアウトデータタイプ
高レベルの NFSv4.1 レイアウトタイプは、nfsv4_1_file_layouthint4, nfsv4_1_file_layout_ds_addr4, and nfsv4_1_file_layout4 です。
SETATTR 操作は、 layout hint 属性 (Section 5.12.4). をサポートします。クライアントが layout hint (データタイプ layouthint4) に、LAYOUT4_NFSV4_1_FILES レイアウトタイプを指定した場合、( loh_typeフィールド), loh_body フィールドは、データタイプ nfsv4_1_file_layouthint4 の内容を持ちます。
const NFL4_UFLG_MASK = 0x0000003F;
const NFL4_UFLG_DENSE = 0x00000001;
const NFL4_UFLG_COMMIT_THRU_MDS = 0x00000002;
const NFL4_UFLG_STRIPE_UNIT_SIZE_MASK
= 0xFFFFFFC0;
typedef uint32_t nfl_util4;
enum filelayout_hint_care4 {
NFLH4_CARE_DENSE = NFL4_UFLG_DENSE,
NFLH4_CARE_COMMIT_THRU_MDS
= NFL4_UFLG_COMMIT_THRU_MDS,
NFLH4_CARE_STRIPE_UNIT_SIZE
= 0x00000040,
NFLH4_CARE_STRIPE_COUNT = 0x00000080
};
/* Encoded in the loh_body field of data type layouthint4: */
struct nfsv4_1_file_layouthint4 {
uint32_t nflh_care;
nfl_util4 nflh_util;
count4 nflh_stripe_count;
};
一般的なレイアウトヒント構造体は、Section 3.3.19 で記述されます。クライアントは、layout_hint (Section 5.12.4) 属性を使って、新しく作られたファイルに使ってほしいレイアウトタイプを指定します。 LAYOUT4_NFSV4_1_FILES はレイアウトタイプ固有であり、その内容は、３つのフィールドを持ちます。第一の nflh_care は、ヒント中のどの値をクライアントが指定してきたかを示すフラグです。 NFLH4_CARE_DENSE フラグが立っていれば、クライアントは２つめのフィールドnflh_util で、データファイルがどのようにパックされてほしいか(Section 13.4.4)を指定します。それは、nflh_util & NFL4_UFLG_DENSE 式の結果で制御されます。（& はビット AND です。）NFLH4_CARE_COMMIT_THRU_MDS フラグが立っていれば、クライアントは COMMIT 操作をメタデータサーバーあるいはデータサーバー(Section 13.7)に送るべきかについての希望を指定します。それは、 nflh_util & NFL4_UFLG_COMMIT_THRU_MDS 式の結果で制御されます。NFLH4_CARE_STRIPE_UNIT_SIZE フラグが立っていれば、クライアントは希望するストライプユニット長を指定します。それは、 nflh_util & NFL4_UFLG_STRIPE_UNIT_SIZE_MASK で示されます。（このため、ストライプユニット長は、６４バイトの倍数でなくてはいけません。）最小のストライプユニット長は、６４バイトです。NFLH4_CARE_STRIPE_COUNT フラグが立っていれば、クライアントは３つめのフィールド nflh_stripe_count に、ストライプ数を指定します。ストライプ数＊ストライプユニット長はストライプ幅です。
LAYOUTGET の結果 LAYOUT4_NFSV4_1_FILES が返ったなら、（lo_content フィールドの loc_type でわかります。）lo_content フィールドの loc_body フィールドは nfsv4_1_file_layout4 の内容です。nfsv4_1_file_layout4 の内容の中で特に、データタイプdeviceid4 を持つ (nfl_deviceid) ストレージデバイス ID があります。GETDEVICEINFO 操作は、デバイス ID を、ストレージデバイスアドレス(type device_addr4)にマップします。GETDEVICEINFO が レイアウトタイプ LAYOUT4_NFSV4_1_FILES (the da_layout_type field), のデバイスアドレスを返したとき、da_addr_body フィールドは nfsv4_1_file_layout_ds_addr4 の内容を含みます。
typedef netaddr4 multipath_list4<>;
/*
* Encoded in the da_addr_body field of
* data type device_addr4:
*/
struct nfsv4_1_file_layout_ds_addr4 {
uint32_t nflda_stripe_indices<>;
multipath_list4 nflda_multipath_ds_list<>;
};
nfsv4_1_file_layout_ds_addr4 データタイプが、デバイスアドレスを示します。それは２つのフィールドを持ちます。
１ nflda_multipath_ds_list:データサーバーのリストの配列。１つのリストには、１つ以上の要素があり、要素は、同じように I/O 操作のターゲットとなるデータサーバーのアドレスです。(see Section 13.5)配列の長さは、ストライプ数と異なることがあります。
２ nflda_stripe_indices:nflda_multipath_ds_list に使うインデックスの配列。nflda_stripe_indices の要素の値は、nflda_multipath_ds_list の要素数より小さくなくてはいけません。nflda_multipath_ds_list の要素は、１つ以上の nflda_stripe_indices 要素から参照されているべきです。nflda_stripe_indices の要素数は、常に、ストライプ数と同じです。
/*
* Encoded in the loc_body field of
* data type layout_content4:
*/
struct nfsv4_1_file_layout4 {
deviceid4 nfl_deviceid;
nfl_util4 nfl_util;
uint32_t nfl_first_stripe_index;
offset4 nfl_pattern_offset;
nfs_fh4 nfl_fh_list<>;
};
nfsv4_1_file_layout4 データ型が、レイアウトです。以下のフィールドからなります。
１ nfl_deviceid: nfsv4_1_file_layout_ds_addr4 型の値にマップされるデバイス ID。
２ nfl_util: nfsv4_1_file_layouthint4 の nflh_util フィールドと同じく、ファイルのデータがそれぞれのデータサーバーでどのようにパックされるか、クライアントはコミット操作をメタデータサーバーに送るのかデータサーバーに送るのか、そしてストライプユニット長を示すコンパクトな表現。サーバーが２つ以上のオーバーラップするレイアウトを返すときは、それらレイアウトのストライプユニット長は等しくなくてはいけません。
３ nfl_first_stripe_index: 使われる最初のnflda_stripe_indices 要素へのインデックス。
４ nfl_pattern_offset: ストライピングパターンが開始するファイル内の論理的オフセット。クライアントの論理的 I/O オフセット（つまり、 read() or write() システムコールが発行されるときの、 POSIX ファイル記述子の現在位置）を、ストライプユニット番号に変換するために必要です。(see Section 13.4.1)
デンスパッキングが使われているときは、nfl_pattern_offset は、クライアントの論理 I/O オフセットを、そのストライプユニット番号に対応するデータサーバーのファイルオフセットに変換するためにも使われます。(see Section 13.4.4)
nfl_pattern_offset は、 lo_offset と違うこともあることに注意ください。例えば、クライアントは LAYOUTGET 操作でファイルのオフセット 1000 から始まるレイアウトを得るかもしれませんが、そのストライピングパターンはオフセットゼロから始まるかもしれません。
５ nfl_fh_list: nflda_multipath_ds_list 配列の要素にあるデータサーバーリストが使うデータサーバーファイルハンドルの配列。nfl_fh_list の要素数は、スパースとデンスのどちらのパッキングが使われているかに依存します。
* スパースパッキングの場合、要素数は、以下のどれかです。
+ ゼロ。データーサーバーに使われるファイルハンドルは、オープン操作のときにメタデータサーバーから返されたファイルハンドルと同じです。
+ １．すべてのデータサーバーは、同じファイルハンドルを使います。それは nfl_fh_list[0] です。
+ nflda_multipath_ds_list の要素数と同じです。つまり、 nflda_multipath_ds_list[X] のデータサーバーに I/O 操作を送るときには、ファイルハンドル nfl_fh_list[X] を使います。
Section 13.4.4 のスパースパッキングの議論を参照ください。
* デンスパッキングの場合、要素数は、nflda_stripe_indices の要素数と同じです。つまり、nflda_multipath_ds_list[nflda_stripe_indices[Y]] のデータサーバーに I/O 操作を送るときには、ファイルハンドル nfl_fh_list[Y] を使います。さらに、nflda_multipath_ds_list[nflda_stripe_indices[i]] と nflda_multipath_ds_list[nflda_stripe_indices[j]] の積が空でない i and j, (i != j) があった場合、nfl_fh_list[i] と nfl_fh_list[j] は同じではいけません。わかりやすく言えば、デンスパッキングのときにデータサーバーが２つ以上のストライピングパターンにあらわれたら、それらの参照は異なるファイルハンドルを使わなくてはいけないということです。
もう一度言うと、layout4 データ型の複数のオブジェクト（１回の LAYOUTGET 操作で得られたときも複数回で得られたときも）が存在することで示されるように、複数のストライピングパターンがあり、あるデータサーバーが１つのパターンユニットのターゲットであり、かつ他のパターンの他のターゲットであるならば、それぞれのデータサーバーの参照は、異なるファイルハンドルを使わなくてはいけません。
Section 13.4.4 のデンスパッキングの議論を参照ください。
レイアウトの解釈の詳細は、Section 13.4 を参照ください。
１３．４ ファイルレイアウトの解釈
１３．４．１ ストライプユニット番号を決定する
クライアントの論理的ファイルオフセットに対応するストライプユニット番号の計算には、パターンオフセットも使われます。i 番目のストライプユニット (SUi) は、
relative_offset = file_offset - nfl_pattern_offset;
SUi = floor(relative_offset / stripe_unit_size);
１３．４．２ スパースパッキングのとき、ファイルレイアウトを解釈する
スパースパッキングのときに、ストライプユニット i (SUi) を各ファイルハンドルとデータサーバーネットワークアドレスを決めるアルゴリズムは：
stripe_count = number of elements in nflda_stripe_indices;
j = (SUi + nfl_first_stripe_index) % stripe_count;
idx = nflda_stripe_indices[j];
fh_count = number of elements in nfl_fh_list;
ds_count = number of elements in nflda_multipath_ds_list;
switch (fh_count) {
case ds_count:
fh = nfl_fh_list[idx];
break;
case 1:
fh = nfl_fh_list[0];
break;
case 0:
fh = filehandle returned by OPEN;
break;
default:
throw a fatal exception;
break;
}
address_list = nflda_multipath_ds_list[idx];
次にクライアントは address_list からデータサーバーを選んで、fh のファイルハンドルを使ってリードやライトを投げます。
以下の例を考えましょう。
７つのデータサーバーがあり、３つの同等クラス (Section 13.5) に入っています。
{ A, B, C, D }, { E }, { F, G }
A から G はネットワークアドレスです。
すると、
nflda_multipath_ds_list<> = { A, B, C, D }, { E }, { F, G }
つまり、
nflda_multipath_ds_list[0] = { A, B, C, D }
nflda_multipath_ds_list[1] = { E }
nflda_multipath_ds_list[2] = { F, G }
ストライピングインデックス配列は、
nflda_stripe_indices<> = { 2, 0, 1, 0 }
クライアントが、前記デバイスアドレスにマップするデバイス ID を持つレイアウトを得たとします。最初のインデックスは、
nfl_first_stripe_index = 2,
そしてファイルハンドルリストは、
nfl_fh_list = { 0x36, 0x87, 0x67 }.
クライアントが SU0 に書き込みたいとき、 SUi の有効な { ネットワークアドレス、ファイルハンドル } の組は、以下で計算されます。
nfl_first_stripe_index = 2
idx = nflda_stripe_indices[(0 + 2) % 4]
= nflda_stripe_indices[2]
= 1
なので、
nflda_multipath_ds_list[1] = { E }
そして
nfl_fh_list[1] = { 0x87 }
結局、クライアントは SU0 を、 { 0x87, { E } } に書き込みます。
最初の13 のストライプユニットの行き先は：
+-----+------------+--------------+
| SUi | filehandle | data servers |
+-----+------------+--------------+
| 0 | 87 | E |
| 1 | 36 | A,B,C,D |
| 2 | 67 | F,G |
| 3 | 36 | A,B,C,D |
| 4 | 87 | E |
| 5 | 36 | A,B,C,D |
| 6 | 67 | F,G |
| 7 | 36 | A,B,C,D |
| 8 | 87 | E |
| 9 | 36 | A,B,C,D |
| 10 | 67 | F,G |
| 11 | 36 | A,B,C,D |
| 12 | 87 | E |
+-----+------------+--------------+
１３．４．３ デンスパッキングのとき、ファイルレイアウトを解釈する
ーーーーーーここからーーーーーー
ーーーーーーここまでーーーーーー
１３．４．４ スパースとデンスストライプユニットパッキング
nfl_util4 データタイプの NFL4_UFLG_DENSE フラグ (field nflh_util of the data type nfsv4_1_file_layouthint4 and field nfl_util of data type nfsv4_1_file_layout_ds_addr4) は、データサーバー上で、データをどのようにデータファイルにパックするかを指定します。スパースと、デンスの２つのパッキングがあります。パッキングタイプは、クライアントに見えるファイルオフセットを、データサーバー上のデータファイル内のオフセットにマップする計算を決定します。
nfl_util & NFL4_UFLG_DENSE がゼロなら、スパースパッキングです。リードとライトを投げるクライアントから見えるファイルのオフセットは、データサーバーがストライプユニットを格納する時に使うオフセットと全く同じです。この結果、データサーバーでのファイルは、スパースあるいは、「ホールがある」ことになります。例えば、３つのストライプユニットを持つパターンがあり、ストライプユニット長は４０９６バイト、パターンには３つのデータサーバーがあるとします。データサーバー１のファイルは、ストライプユニット 0, 3, 6, 9, ... が埋まっています。データサーバー２は、 1, 4, 7, 10, ... が埋まっており、データサーバー３は 2, 5, 8, 11, ... が埋まっています。埋まっていないストライプユニットは、ホールになります。つまり、データサーバー上のファイルはスパースです。
スパースパッキングが使われており、クライアントがホールに I/O を出したら、データサーバーはエラーを返さなくてはいけません。上記の例では、データサーバー３がブロック４にリードかライトを受けたなら、NFS4ERR_PNFS_IO_HOLE が返ります。このように、スパースパッキングをサポートするデータサーバーはストライピングパターンを理解する必要があります。
nfl_util & NFL4_UFLG_DENSE が１なら、デンスパッキングです。データサーバーのファイルはホールを持ちません。デンスパッキングは、データサーバーがホールファイルを（効率的に）サポートできない場合や、ホールのある時に先読みをきちんと認識できないときに有効です。レイアウトにデンスパッキングが指定されていると、データファイルは詰められます。スパースパッキングの時と同じ例を使うと、こうなります。
o ファイルの論理的ストライプユニット 0, 3, 6, ... は、データサーバー１の 0, 1, 2, ... に置かれます。
o 1, 4, 7, ... は、データサーバー２の 0, 1, 2, ... に置かれます。
o 2, 5, 8, ... は、データサーバー３の 0, 1, 2, ... に置かれます。
デンスパッキングでは、ホールはできないので、pNFS クライアントは、ストライプ中のどのオフセット、どのファイル、どのデータサーバーに書き込むことも可能です。このように、データサーバーはストライピングパターンを知らなくても構いません。
デンスパッキングの場合のデータファイル内バイトオフセットの計算は、以下です。
stripe_width = stripe_unit_size * N;
where N = number of elements in nflda_stripe_indices.
relative_offset = file_offset - nfl_pattern_offset;
data_file_offset = floor(relative_offset / stripe_width)
* stripe_unit_size
+ relative_offset % stripe_unit_size
デンスパッキングが使われ、１つのデータサーバーがストライピングパターンに複数回現れるときは、ストライピングユニットを別のと区別するために、データサーバーは異なるファイルハンドルを使わなくてはいけません。２つのデータサーバーがあるとして、論理的ストライプユニット 0, 3, 6 がデータサーバー１で、 1, 4, 7 はデータサーバー２で、 2, 5, 8 も、データサーバー２で提供されるとします。データサーバー２が２つのファイルハンドル（それぞれが異なるデータファイルを参照します）を使わない限り、例えば、論理的ストライプユニット１へのライトは論理的ストライプユニット２へのライトを上書きします。いずれの論理的ストライプユニットも、データサーバー２の同じストライプユニット（０）にあるからです。
１３．５ データサーバーのマルチパス
NFSv4.1 のファイルレイアウトでは、複数のデータサーバーアドレスへのマルチパスをサポートします。データサーバーレベルのマルチパスは、トランキング(Section 2.10.5)を使ったバンド幅スケーリングのためと、データサーバー障害の場合の高信頼のために使われます。マルチパスを使えば、クライアントは同じデータストライプユニットを公開している別のデータサーバーに、新しいレイアウトのためにメタデータサーバーにコンタクトすることなく、切り替えることができます。
データサーバーのマルチパスをサポートするため、nflda_multipath_ds_list の各要素は、データサーバーのネットワークアドレスの配列を持ちます。この配列 (data type multipath_list4) は、データサーバーのリストです。同じデータサーバーが複数回現れることもあります。
クライアントは、データサーバーに要求を投げる宛先として、どのネットワークアドレスを使ってもかまいません。あるアドレスが、ほかのと比べて、データへのパスとして最適でないならば、MDS はそれを nflda_multipath_ds_list に含めるべきではありません。フェールオーバーのために、最適でないアドレスを使う必要があるならば、推奨されるやりかたは、それをデバイス ID からデバイスアドレスのマッピングもしくは、デバイス ID の代替要素として提供することです。クライアントが、nflda_multipath_ds_list のどのサーバーからも応答を得られないときは、クライアントは GETDEVICEINFO を投げて、今のデバイス ID とデバイスアドレスのマッピングを入れ替えるべきです。MDS が、nflda_multipath_ds_list のすべてのサーバーが落ちていることに気がついたら、MDS は CB_NOTIFY_DEVICEID を投げて（クライアントが、デバイス ID の変更通知を受けたいと言ったならば）マッピングを変更させるべきです。デバイス ID 自身が変更されるべきときは、 MDS はそれを使うすべてのレイアウトを回収して、クライアントに LAYOUTGET と GETDEVICEINFO で新しいレイアウトとデバイス ID マッピングを取得させるべきです。
一般的に、nflda_multipath_ds_list の１つの要素に２つのネットワークアドレスがあれば、それらは同じデータサーバーを指し、その２つのデータサーバーアドレスは、Section 2.10.5 に定めるクライアント ＩＤ あるいはセッションのトランキング（後者のほうがおすすめです）の実装をサポートします。２つのデータサーバーアドレスは、サーバー所有者あるいはサーバー所有者のメジャー ＩＤ を共用します。２つのデータサーバーアドレスであっても、同じサーバーのトランキングのために使われないこともあります。例えば、データはリードオンリーで、２つのデータは完全な複製の場合など。
１３．６ NFSv4.1 データサーバーに送られる操作
NFSv4.1 データサーバーのデータをアクセスするクライアントは、NULL と COMPOUND 手続きだけを使うことができ、操作も、以下の２つのセットに限られます。クライアントは、レイアウトに指定されたファイルハンドルを使わなくてはいけません。
有効な操作のセットの１つめは、管理のための操作で、BACKCHANNEL_CTL,
BIND_CONN_TO_SESSION, CREATE_SESSION, DESTROY_CLIENTID,
DESTROY_SESSION, EXCHANGE_ID, SECINFO_NO_NAME, SET_SSV, そして SEQUENCE です。クライアントは、クライアント ID 、セッション、セキュリティコンテキストを作成及び維持するためにこれらの操作を使います。以下でこれらを、データサーバーのハウスキーピング操作と呼びます。
２つめのセットは、COMMIT, READ, WRITE, そして PUTFH です。これらの操作では、レイアウトに指定された現在のファイルハンドルを使わなくてはいけません。PUTFH する新しいファイルハンドルは、レイアウトから取られたものでなくてはいけません。以下でこれらを、データサーバーの I/O 操作と呼びます。12.5.1 に述べたように、クライアントは有効なレイアウトを持たないデータサーバーに I/O を出してはいけませんし、サーバーはそれを受け付けてはいけません。
サーバーが、データサーバー以外の役割も同時に実行しているとき以外は、上記の２つのセットに含まれる以外の操作は、NFS4ERR_NOTSUPP でエラーを返さなくてはいけません。（大意）
サーバーが、２つの役割を同時に実行している場合、クライアントは、１つの COMPOUND 手続きに、別の役割に向けたものを混ぜてはいけませんし、サーバーもそれを許してはいけません。この制限を説明するために、１つの COMPOUND 手続き内の操作を以下の３つのクラスに分けます。
１ 役割が不明確な操作。これには、データサーバーのハウスキーピング操作がすべて含まれます。また、サーバーが、レイアウトのために定義されるファイルハンドルと、メタデータサーバーのために使われるそれに同じものを使うときは、そのファイルハンドルを使うすべての操作がこのクラスに含まれます。ただし、以下の例外を除きます。例外とは、データサーバーと非互換の stateid （０か１の特別の stateid あるいは、"seqid" がゼロでないもの。 Section 13.9.1 を参照。）を使うものと、操作が以下のクラス３に含まれるものです。このクラス１操作だけを複数含む COMPOUND 手続きは、２つの役割を同時に実行するサーバーに送ることができます。
２ 明らかにデータサーバーに向けた操作。これは、データサーバーに対してだけ有効なファイルハンドルを使った I/O 操作です。
３ 明らかにメタデータサーバーに向けた操作。これは、データサーバーのハウスキーピング操作でもなく、データサーバーの I/O 操作でもない COMPOUND 手続きです。
なお、データサーバーの I/O 操作のうち、現在ファイルハンドル（PUTFH の場合は、これから現在になるもの）あるいは、 stateid がメタデータサーバーにおいてだけ有効なものも含みます。
COMPOUND の最初がクラス３操作なら、メタデータサーバーとしての役割が確定して、データサーバーの役割は無関係となります。COMPOUND の以降の操作は、データサーバー専用の操作に限られる必要はありません。PUTFH で使われるファイルハンドルがレイアウト由来であれば、NFS4ERR_BADHANDLE MUST になります。現在ファイルハンドルとして使われれば、NFS4ERR_STALE となります。
COMPOUND の最初がクラス２操作なら、それは、レイアウト由来のファイルハンドルの PUTFH のはずで、データサーバーの役割が確定します。前述したデータサーバー専用の操作以外は、 NFS4ERR_NOTSUPP になります。ファイルハンドルは、データサーバーとしての評価がされ、メタデータサーバーに対しては有効なものでも、 NFS4ERR_BADHANDLE and/or NFS4ERR_STALE になることがあります。 stateid が不適当な場合、 NFS4ERR_BAD_STATEID になります。
サーバーが最初にクラス２あるいは３の操作を実行するまで、クライアントは、操作がデータサーバーで行われたのかメタデータサーバーで行われたのか、前提としてはいけません。サーバーは、ある COMPOUND が与えられたら、一貫して１つの役割を選択しなくてはいけません。
データサーバーでもメタデータサーバーでも使えるファイルハンドルというものは、今までの議論でわかるように面倒を起こすだけなので、両方の役割をするサーバーは、両者が区別できる、一意なファイルハンドルを使うべきです。
GETATTR and SETATTR の宛先は、メタデータサーバーです。ファイル長の SETATTR の場合、制御プロトコルは、ファイル長の変更をデータサーバーに伝搬する必要があります。ファイルを伸長する WRITE の場合、新しいサイズは、 LAYOUTCOMMIT 完了後（see Section 12.5.4.2）、メタデータサーバーに見える必要があります。Section 13.10 には、メタデータサーバーのファイル長を反映していないデータサーバーのファイルを、クライアントが対処する機構が述べてあります。
１３．７ メタデータサーバー経由のコミット
ファイルレイアウトには、データサーバーに書き込まれたデータをコミットするための２つの方法があります。ファイルレイアウト (data type nfsv4_1_file_layout4)
の nfl_util フィールドの NFL4_UFLG_COMMIT_THRU_MDS フラグは、メタデータサーバーからクライアントに、コミットをデータサーバーに送るか、メタデータサーバーに送るかを指示します。これにより、ファイルレイアウトをサポートする pNFS サーバーの実装に広がりを持たせることができます。
o フラグが偽なら、COMMIT 操作は対応する WRITE 操作が送られたデータサーバーに送られなくてはいけません。このアプローチは、ファイルストライピングが、ファイルシステムではなくて、 pNFS サーバーによって実装されている時に便利です。つまり、それぞれのデータサーバーは、自分のファイルシステムを持つ時です。
o フラグが真なら、COMMIT 操作は、個々のデータサーバーではなく、メタデータサーバーに送られなくてはいけません。このアプローチは、ファイルストライピングが、pNFS サーバーのバックエンドであるクラスターファイルシステムで実装されている時に便利です。その場合、それぞれのデータサーバーに COMMIT を投げると、メタデータブロックに繰り返しライトがされ、性能低下につながることがあります。クラスターファイルシステムが、コミットの調整をする能力があるならば、メタデータサーバーに１度だけ COMMIT を投げるのがずっと効率的です。
フラグが真なら、現在の NFSv4.1 のコミットと回復モデルに準拠するため、データサーバーはあるファイルレイアウトへのすべてのライトに、共通の writeverf ベリファイアを返さなくてはいけません。さらに、メタデータサーバーのコミット応答は、同じ writeverf を返さなくてはいけません。 writeverf ベリファイアの値は、コミットされていないデータ喪失につながるおそれのあるサーバーイベントがあった場合、メタデータサーバーあるいはレイアウトに参照されているすべてのデータサーバーにおいて、変更されなくてはいけません。ベリファイアのスコープは、単一ファイルでも、 pNFS サーバー全体でもかまいません。ファイルごとにベリファイアを維持するのはサーバーにとってたいへんかもしれませんが、回復もファイルごとにできるという利点があります。
レイアウトがデンスパッキングのときは、MDS に送られるコミットに指定されたオフセットは、データサーバーに送られるコミットに指定されるオフセットと異なるかもしれないことに注意下さい。
メタデータサーバーへの単一のコミットはベリファイアを返しますが、クライアントはそれを今までのライトすべてのベリファイアと比較し、違っていれば、コミットを失敗させます。その場合、クライアントは、ファイルのすべての更新されたデータのライトを再送します。クライアントは、ベリファイアが違った更新済みデータを、ライト失敗として扱い、レイアウトが回収されていないならば、ライトを元のデータサーバーあるいはそのデータへの別のパスを使って、再送することで、回復を試みます。
あるいは、クライアントは新しいレイアウトを得てもよいですし、メタデータサーバーに直接書いてもよいです。
前記フラグが偽なら、メタデータサーバーにコミットを送っても、何も効果がないかもしれません。その場合、メタデータサーバーに直接書かれたデータをコミットする効果はあるでしょう。回復オプションについて、Section 12.7.6 を参照下さい。
１３．８ レイアウト iomode
メタデータサーバーは、 NFSv4.1 ファイルベースのレイアウトを提供するときに、レイアウトの iomode を使う必要はありません。しかし、役に立つこともあります。例えば、サーバー実装がリードオンリーのレプリカあるいはミラーからの読み込みをサポートしているとき、そのためのレイアウトをクライアントに返すのは良いことかもしれません。このため、クライアントは、データを読むか書くか、自分の意図に従って、 iomode を設定するべきです。デフォルトの LAYOUTIOMODE4_RW を使ってもよいです。
クライアントが I/O するとき、データサーバーは iomode をチェックする必要はありません。しかし、データサーバーはクライアントが有効なレイアウトを持っているかをチェックして、エラーを返すべきです。
１３．９ メタデータサーバーとデータサーバーの状態調整
１３．９．１ グローバルな stateid の必要性
クライアントがデータサーバーに I/O を投げるとき、使われる stateid は、 LAYOUTGET で得たり、CB_LAYOUTRECALL で送ったりするレイアウト stateid ではいけません。以下の stateid だけが許されます。
OPEN stateid （OPEN で返る、 OPEN4resok データ型の stateid フィールド。）、
委譲 stateid （OPEN or WANT_DELEGATION で返されるか、 CB_PUSH_DELEG で送られる、 open_read_delegation4 and open_write_delegation4 データ型の stateid フィールド。）
LOCK or LOCKU 操作で返る stateid 。
データサーバーに送られる stateid は、 seqid がゼロで、最新バージョンを示さなくてはいけません。特別な stateid は、使えません。
データサーバーにおいて I/O に使われる stateid は、 pNFS が使われていない時にメタデータサーバーによって直接実行されたときと、全く同じ効果を持ち、同じチェックがされなくてはいけません。これはつまり、 stateid は、メタデータサーバーとデータサーバーの間で、グローバルに有効でなくてはいけないということです。このため、メタデータサーバーは、 LOCK and OPEN 状態の変更をデータサーバーに伝搬して、データサーバーで I/O アクセスがチェックできるようにしなくてはいけません。詳しくは、 Section 13.9.2 を参照下さい。stateid が伝搬されるとき、データサーバーでの有効な stateid の存在は、有効なレイアウトがあることの証拠になります。
I/O 操作をするクライアントは、自分が持っているロック（オープンと委譲も含みます。）と、I/O 要求を送るいろいろなタイプの状態の保持者に従って、適当な stateid を選ぶ必要があります。その規則は、 Section 8.2.5 で述べた、メタデータサーバーをアクセスする時の規則とはいくらか異なります。
以下が、適当な stateid を選ぶ規則です。最初のが一番重要です。
o クライアントが問題のファイルの委譲をもっているなら、委譲の stateid を使うべきです。
o そうでない場合、現在のオープンオーナーの OPEN stateid があるはずです。それを使いなさい。ただし、以下のマンダトリーロックのためにそれができないときを除きます。
o かつてデータサーバーがその OPEN stateid を使った時に NFS4ERR_LOCKED を返したことがあるなら、クライアントはバイトレンジロックをとっているはずで、その stateid を使いなさい。
o 特別な stateid は使ってはいけません。サーバーは NFS4ERR_BAD_STATEID でエラーにしなくてはいけません。
１３．９．２ データサーバーの状態伝播
バイトレンジロック、オープンモード、それにACLを管理するメタデータサーバーは、実際に I/O アクセスがチェックされるデータサーバーと同じ場所にあるとは限らないので、サーバーの実装では、前記の状態の変更を、データサーバーに伝播することが重要です。データサーバーへの伝播が完了したら、データサーバーにおいて、前記変更のすべての影響が有効とならなくてはいけません。すべての変更はすみやかに伝播されるべきですが、直ちに伝播する必要のない状態変更もあります。制御プロトコルはこの仕様の範囲外ですが、これらの状態の伝播は制御プロトコルの設計にとって重要です。直ちに伝播する （Immediate propagation）とは、メタデータサーバーからデータサーバーへ、状態が同期的に伝播することです。クライアントに応答が返る前に、伝播は完了していなければいけません。
１３．９．２．１ ロック状態の伝播
pNFS サーバーが、マンダトリーなバイトレンジロックをサポートしているならば、あるファイルへのマンダトリーバイトレンジロックは、それを確立した要求がコール元に返る前に、データサーバーにおいて有効にならなくてはいけません。制御プロトコルによっては、ある条件下で実際の状態の伝播がなされないことがあるかもしれませんが、外から見た場合には、その効果は、マンダトリーバイトレンジロック状態が同期的にデータサーバーに伝播されたのと同じでなくてはいけません。
これに比べて、アドバイザリーバイトレンジロック状態は、データサーバーにおいて I/O アクセスをチェックすることには使われないため、データサーバーにアドバイザリーバイトレンジロック状態を伝播するべきセマンティックな理由はありません。アドバイザリーロックの更新は、権限を上げたり下げたりもしないので、更新を直ちに伝播する必要はないですし、たぶん、早めに伝播する必要もないかもしれません。アドバイザリーロックの更新は、データサーバーが stateid に関する問題を解決する必要が生じたときにだけ伝播されればよいのです。要するに、バイトレンジロックがマンダトリーでない（アドバイザリー）場合は、クライアントは、I/O のときに、バイトレンジロックをベースとした stateid は使わないのがよいでしょう。このときの状態伝搬については、オープンで返る stateid が十分で、余計なオーバーヘッドもありません。
クライアントがデータサーバーから NFS4ERR_LOCKED エラーをもらったときは、マンダトリーバイトレンジロックがかかっているということです。これに対してクライアントは、目的範囲をカバーするバイトレンジロックを確保して、そのバイトレンジロックの stateid を使って I/O を投げ直します。
１３．９．２．２ オープンと拒否モードの確認
オープンと拒否モードの確認は、データサーバーが持っているオープンと拒否モードに対して行われなくてはいけません。アクセス権が弱まったり、拒否モードが強化されたりした場合、（CLOSE or OPEN_DOWNGRADE のため）データサーバーは、メタデータサーバーにおいては拒否される I/O は、すべて拒否しなくてはいけません。アクセス権が強まった場合、その逆で、状態の伝搬の遅延のために、本来許されるアクセスが拒否されてはいけません。
１３．９．２．３ ファイル属性
SETATTR 操作は、メタデータサーバーとデータサーバーの両方に見える属性（ファイル長など）を変える能力がありますから、特に、ファイルを切り詰めたり伸ばしたりするときに、関連するデータサーバーすべてにおいて、矛盾のない状態となるように注意が必要です。
以前に述べたように、 LAYOUTCOMMIT 操作は、データサーバーに行われた変更を、メタデータと同期させるために使われます。NFSv4.1 ベースのストレージでは、サイズ属性などの状態を再同期し、mtime/change/atime を設定する必要があります。 LAYOUTCOMMIT と属性の同期のセマンティクスについての完全な記述は、Section 12.5.4 を参照下さい。NFSv4.1 ベースのレイアウトを使った時、この状態を、 LAYOUTCOMMIT が出る前に同期することもできることに注意下さい。例えば、制御プロトコルを使って、データサーバーにある属性を問い合わせることができます。
メタデータサーバーにおいて行われるファイル属性の変更のうち、ACCESS コールあるいは、 READ、 WRITE に影響を与える、認可やアクセス権を制御するものは、データサーバーに伝搬され、 READ、 WRITE I/O コールに反映されなくてはいけません。メタデータサーバーにおいて行われる変更が、いずれかのユーザーにとってより制限されたアクセス権につながるならば、この変更は同期的にデータサーバーに伝搬されなくてはいけません。
OPEN 操作(Section 18.16.4) は、オープンファイルへの I/O が、OPEN 自身と同じクレデンシャルを持つことを要求しません。（EXCHANGE_ID がクライアント ID を生成する時に EXCHGID4_FLAG_BIND_PRINC_STATEID が立っている時を除きます。）このため、サーバーが、読み書き操作の時に適当なアクセスチェックをすることが求められます。ACL が変わった時も、サーバーでの読み書きチェックを新しくする必要が生じます。ACL の変更によるアクセス権の変更の伝搬は、古い ACL にあるすべてのユーザーに対して、新しい ACL がより制限が強くなってはいないことをサーバー実装が判定できる時に限って、非同期であることが許されます。ACL 更新は比較的まれなので、すべての変更を同期で伝搬することをおすすめします。
１３．１０ データサーバーコンポーネントファイル長
特定のデータサーバーのコンポーネントデータファイルが、EOF を越えて大きくなる時、潜在的な問題があります。デンスレイアウトでもスパースレイアウトでも起きます。以下のシナリオを考えて下さい。クライアントが新しいファイルを作成しました。(size == 0) 次に、バイト 131072 に書きました。クライアントはファイル先頭にシークして、バイト100 を読みます。クライアントはリードの結果、ゼロを受け取るべきです。しかし、ストライプパターンによって、クライアントのリードが、クライアントが最初にライトをしたデータサーバー以外のところに送られたならば、リードを処理するデータサーバーは、ファイル長がゼロのままだと思っているかもしれません。リード応答は、EOF を示すでしょう。データサーバーは、ファイルが伸長されたことを知りませんから。そのために、ファイル長をすべてのデータサーバーに直ちに伝搬するのはとても非効率的です。このため、ファイル長を伸ばしたクライアントは、このような EOF 条件に対処しなくてはいけません。リード引数のオフセットが、クライアントの思うファイル長より小さい場合、リード応答が EOF を示したり要求より少ないバイト数を返した場合クライアントはそのような応答をファイル中のホールと解釈して、ゼロを補完するべきです。
NFSv4.1 プロトコルは、クローズからオープンまでのファイルデータキャッシュセマンティクスを提供するだけです。つまり、ファイルがクローズされたら、すべての更新済みデータはサーバーに書かれます。そのファイルが次にオープンされるとき、キャッシュされている change 属性が比較されます。前述のケースでは、クローズで LAYOUTCOMMIT がされ、（データライトを伴い）そのときにファイル長と change 属性が更新されます。その後の他のクライアントからのアクセスは、正しいサイズを返します。
１３．１１ レイアウトの失効とフェンシング
12.7 節で述べたように、レイアウトタイプ固有のストレージプロトコルは、リースが有効なときに開始して、リース満了の後まで続く I/O の影響を正しく扱う責任があります。LAYOUT4_NFSV4_1_FILES レイアウトタイプの場合、リースの満了の後は、データサーバーへのすべての I/O を実行されないようにすることができます。（これを「フェンシング」と呼びます。）これは、クライアントの正確なリースタイマーに依存せず、データサーバーでのリースタイマーの維持も不要です。LAYOUT4_NFSV4_1_FILES pNFS サーバーは個々のレイアウトを失効させることができ、ファイルごとに I/O をフェンスできます。
リースの満了以外にも、レイアウトが失効する原因は、クライアントが CB_LAYOUTRECALL に応答しない時、メタデータサーバーが再開始した時、あるいは、管理者の介入などです。理由によらず、クライアントのレイアウトが一度失効したならば、 pNFS サーバーは、影響を受けるファイルについての、すべてのデータサーバーへのI/O を阻止しなくてはいけません。つまり、クライアントをデータサーバー上の影響を受けたファイルからフェンスするのです。
フェンシングは、このようにはたらきます。Section 13.1 で述べたように、データサーバーに送られる COMPOUND 手続きにおいて、 PUTFH 操作に与えられる filehandle と、リードとライト操作で与えられる stateid が、クライアントが実行される I/O に関して有効なレイアウトを持っていることを保証するのに使われます。そうでないときは、I/O は、NFS4ERR_PNFS_NO_LAYOUT で拒否されます。サーバーは、ただ、 stateid をチェックして、さらに、メタデータサーバーがそのファイルに使っている filehandle と、レイアウトが指定するデータ filehandle が異なる場合、データ filehandle を無効にすればよいです。（Section 13.3 の nfl_fh_list の記述を参照下さい。）
メタデータサーバーが、以前のインスタンスがクライアントに提供したレイアウト状態を失効させる前に、それらすべてのレイアウトがデータサーバーにおいて無効になっていることを確認しなければいけません。これは、以下の意味を持ちます。
o メタデータサーバーは、すべてのデータサーバーで以前のレイアウトを無効にするまで、ファイルの再ストライプをしてはいけません。
o メタデータサーバーは、特定のレイアウトの無効化あるいは、グローバルなデータサーバーの無効化をするまで、以前のレイアウトと競合するマンダトリーロックを許可してはいけません。
１３．１２ ファイルレイアウトタイプのセキュリティーの考察
NFSv4.1 ファイルレイアウトタイプは、 Section 12.9 のセキュリティ考察に従わなくてはいけません。NFSv4.1 データサーバーは、NFSv4.1 プロトコルが定めるすべての必須のアクセスチェックをすべてのリードとライト I/O で実施しなくてはいけません。メタデータサーバーがあるファイルへのリードやライトを、ACL のため、モード属性のため、オープンアクセスモードのため、オープン拒否モードのため、マンダトリーバイトレンジロック状態のため、あるいはどのような属性や状態のためであっても、拒否するならば、データサーバーも全く同じようにしなくてはいけません。このために、制御プロトコルと、メタデータサーバーからデータサーバーへの状態伝搬に影響があります。Section 13.9.2 を参照下さい。
LAYOUT4_NFSV4_1_FILES レイアウトタイプのデータサーバーにおいて、認証、データの改ざん防止、機密性のために使われる方法は、メタデータサーバーで使われるものと同じです。それは、認証のために ONC RPC セキュリティフレーバーを使い、 SECINFO and SECINFO_NO_NAME で使うセキュリティ機構とサービスをネゴシエートします。このため、LAYOUT4_NFSV4_1_FILES レイアウトタイプを使うとき、 pNFS による RPC ベースのセキュリティモデルへのインパクトはゼロです。
あるファイルオブジェクトに対して、メタデータサーバーはデータサーバーと異なるセキュリティパラメータ (secinfo4 value) を必要とするかもしれません。複数のデータサーバーに置かれるファイルの場合、secinfo4 の値はすべてのデータサーバーで同じであるべきです。メタデータサーバーとデータサーバーでの secinfo4 の値が異なる場合、プリンシパルからサーバーの内部的なユーザー識別子へのマッピングは同じでなくてはいけません。ACL,モード、オープンと拒否モード、マンダトリーロックによるアクセス制御チェックが、 pNFS サーバーの間で一貫しなくなるからです。
NFSv4.1 実装が pNFS をサポートし、 NFSv4.1 ファイルレイアウトをサポートするなら、メタデータサーバーとデータサーバーの両方で SECINFO_NO_NAME 操作をサポートしなくてはいけません。
23. References
23.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Eisler, M., Ed., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006.
[3] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 5531, May 2009.
[4] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[5] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version
5 Generic Security Service Application Program Interface (GSS-
API) Mechanism Version 2", RFC 4121, July 2005.
[6] The Open Group, "Section 3.191 of Chapter 3 of Base Definitions
of The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004.
[7] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[8] Talpey, T. and B. Callaghan, "Remote Direct Memory Access
Transport for Remote Procedure Call", RFC 5666, January 2010.
[9] Talpey, T. and B. Callaghan, "Network File System (NFS) Direct
Data Placement", RFC 5667, January 2010.
[10] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia,
"A Remote Direct Memory Access Protocol Specification",
RFC 5040, October 2007.
[11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[12] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February 2009.
[13] 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,
January 2010.
[14] The Open Group, "Section 3.372 of Chapter 3 of Base Definitions
of The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004.
[15] Eisler, M., "IANA Considerations for Remote Procedure Call
(RPC) Network Identifiers and Universal Address Formats",
RFC 5665, January 2010.
[16] The Open Group, "Section 'read()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004.
[17] The Open Group, "Section 'readdir()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004.
[18] The Open Group, "Section 'write()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004.
[19] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002.
[20] The Open Group, "Section 'chmod()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004.
[21] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS)
- Part 1: Architecture and Basic Multilingual Plane",
ISO Standard 10646-1, May 1993.
[22] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[23] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (IDN)", RFC 3491,
March 2003.
[24] The Open Group, "Section 'fcntl()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004.
[25] The Open Group, "Section 'fsync()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004.
[26] The Open Group, "Section 'getpwnam()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004.
[27] The Open Group, "Section 'unlink()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004.
[28] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005.
[29] National Institute of Standards and Technology, "Cryptographic
Algorithm Object Registration", URL http://csrc.nist.gov/
groups/ST/crypto_apps_infra/csor/algorithms.html,
November 2007.
23.2. Informative References
[30] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M., and D. Noveck, "Network File System (NFS)
version 4 Protocol", RFC 3530, April 2003.
[31] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3
Protocol Specification", RFC 1813, June 1995.
[32] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism
Using SPKM", RFC 2847, June 2000.
[33] Eisler, M., "NFS Version 2 and Version 3 Security Issues and
the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999.
[34] Juszczak, C., "Improving the Performance and Correctness of an
NFS Server", USENIX Conference Proceedings, June 1990.
[35] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[36] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995.
[37] Werme, R., "RPC XID Issues", USENIX Conference Proceedings,
February 1996.
[38] Nowicki, B., "NFS: Network File System Protocol specification",
RFC 1094, March 1989.
[39] Bhide, A., Elnozahy, E., and S. Morgan, "A Highly Available
Network Server", USENIX Conference Proceedings, January 1991.
[40] Halevy, B., Welch, B., and J. Zelenka, "Object-Based Parallel
NFS (pNFS) Operations", RFC 5664, January 2010.
[41] Black, D., Glasgow, J., and S. Fridella, "Parallel NFS (pNFS)
Block/Volume Layout", RFC 5663, January 2010.
[42] Callaghan, B., "WebNFS Client Specification", RFC 2054,
October 1996.
[43] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996.
[44] IESG, "IESG Processing of RFC Errata for the IETF Stream",
July 2008.
[45] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624,
June 1999.
[46] The Open Group, "Protocols for Interworking: XNFS, Version 3W,
ISBN 1-85912-184-5", February 1998.
[47] Floyd, S. and V. Jacobson, "The Synchronization of Periodic
Routing Messages", IEEE/ACM Transactions on Networking 2(2),
pp. 122-136, April 1994.
[48] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E.
Zeidner, "Internet Small Computer Systems Interface (iSCSI)",
RFC 3720, April 2004.
[49] Snively, R., "Fibre Channel Protocol for SCSI, 2nd Version
(FCP-2)", ANSI/INCITS 350-2003, Oct 2003.
[50] Weber, R., "Object-Based Storage Device Commands (OSD)", ANSI/
INCITS 400-2004, July 2004,
<http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf>.
[51] Carns, P., Ligon III, W., Ross, R., and R. Thakur, "PVFS: A
Parallel File System for Linux Clusters.", Proceedings of the
4th Annual Linux Showcase and Conference, 2000.
[52] The Open Group, "The Open Group Base Specifications Issue 6,
IEEE Std 1003.1, 2004 Edition", 2004.
[53] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[54] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation
for WebNFS", RFC 2755, January 2000.
[55] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
以上