RFC 1813 - NFSバージョン3プロトコル仕様 (NFS Version 3 Protocol Specification)
- ステータス: Informational
- 発行日: June 1995
- ストリーム: Legacy
- エラッタ: エラッタなし
概要 (Abstract)
本文書はNFSバージョン3プロトコルについて説明します。本文書は、互換性のある実装を作成できるように提供されています。
目次 (Table of Contents)
- 1. Introduction (はじめに)
- 1.1 Scope of the NFS version 3 protocol (NFSバージョン3プロトコルの範囲)
- 1.2 Useful terms (有用な用語)
- 1.3 Remote Procedure Call (リモートプロシージャコール)
- 1.4 External Data Representation (外部データ表現)
- 1.5 Authentication and Permission Checking (認証と権限チェック)
- 1.6 Philosophy (哲学)
- 1.7 Changes from the NFS version 2 protocol (NFSバージョン2プロトコルからの変更点)
- 2. RPC Information (RPC情報)
- 2.1 Authentication (認証)
- 2.2 Constants (定数)
- 2.3 Transport address (トランスポートアドレス)
- 2.4 Sizes (サイズ)
- 2.5 Basic Data Types (基本データ型)
- 2.6 Defined Error Numbers (定義されたエラー番号)
- 3. Server Procedures (サーバープロシージャ)
- 3.1 General comments on attributes (属性に関する一般的なコメント)
- 3.2 General comments on filenames (ファイル名に関する一般的なコメント)
- 3.3.0 NULL: Do nothing (何もしない)
- 3.3.1 GETATTR: Get file attributes (ファイル属性の取得)
- 3.3.2 SETATTR: Set file attributes (ファイル属性の設定)
- 3.3.3 LOOKUP: Lookup filename (ファイル名の検索)
- 3.3.4 ACCESS: Check access permission (アクセス権限のチェック)
- 3.3.5 READLINK: Read from symbolic link (シンボリックリンクからの読み取り)
- 3.3.6 READ: Read from file (ファイルからの読み取り)
- 3.3.7 WRITE: Write to file (ファイルへの書き込み)
- 3.3.8 CREATE: Create a file (ファイルの作成)
- 3.3.9 MKDIR: Create a directory (ディレクトリの作成)
- 3.3.10 SYMLINK: Create a symbolic link (シンボリックリンクの作成)
- 3.3.11 MKNOD: Create a special device (特殊デバイスの作成)
- 3.3.12 REMOVE: Remove a file (ファイルの削除)
- 3.3.13 RMDIR: Remove a directory (ディレクトリの削除)
- 3.3.14 RENAME: Rename a file or directory (ファイルまたはディレクトリの名前変更)
- 3.3.15 LINK: Create link to an object (オブジェクトへのリンク作成)
- 3.3.16 READDIR: Read From directory (ディレクトリからの読み取り)
- 3.3.17 READDIRPLUS: Extended read from directory (ディレクトリからの拡張読み取り)
- 3.3.18 FSSTAT: Get dynamic file system information (動的ファイルシステム情報の取得)
- 3.3.19 FSINFO: Get static file system information (静的ファイルシステム情報の取得)
- 3.3.20 PATHCONF: Retrieve POSIX information (POSIX情報の取得)
- 3.3.21 COMMIT: Commit cached data on a server to stable storage (サーバー上のキャッシュデータを安定ストレージにコミット)
- 4. Implementation issues (実装上の問題)
- 4.1 Multiple version support (複数バージョンのサポート)
- 4.2 Server/client relationship (サーバー/クライアント関係)
- 4.3 Path name interpretation (パス名の解釈)
- 4.4 Permission issues (権限の問題)
- 4.5 Duplicate request cache (重複リクエストキャッシュ)
- 4.6 File name component handling (ファイル名コンポーネントの処理)
- 4.7 Synchronous modifying operations (同期変更操作)
- 4.8 Stable storage (安定ストレージ)
- 4.9 Lookups and name resolution (検索と名前解決)
- 4.10 Adaptive retransmission (適応的再送信)
- 4.11 Caching policies (キャッシュポリシー)
- 4.12 Stable versus unstable writes (安定書き込みと不安定書き込み)
- 4.13 32 bit clients/servers and 64 bit clients/servers (32ビットクライアント/サーバーと64ビットクライアント/サーバー)
- 5. Appendix I: Mount protocol (付録I: マウントプロトコル)
- 5.1 RPC Information (RPC情報)
- 5.2 Server Procedures (サーバープロシージャ)
- 6. Appendix II: Lock manager protocol (付録II: ロックマネージャープロトコル)
- 6.1 RPC Information (RPC情報)
- 6.2 NLM Procedures (NLMプロシージャ)
- 6.3 Implementation issues (実装上の問題)
- 7. Appendix III: Bibliography (付録III: 参考文献)
- 8. Security Considerations (セキュリティに関する考慮事項)
- 9. Acknowledgements (謝辞)
- 10. Authors' Addresses (著者の連絡先)
関連リソース (Related Resources)
- 公式RFC: RFC 1813
- DataTracker: RFC 1813 on IETF
1. 序論 (Introduction)
Sunの NFSプロトコル (NFS Protocol) は、ネットワーク全体で共有ファイルシステムへの透過的なリモートアクセスを提供します。NFSプロトコルは、マシン、オペレーティングシステム、ネットワークアーキテクチャ、トランスポートプロトコルから独立するように設計されています。この独立性は、外部データ表現 (eXternal Data Representation, XDR) の上に構築されたリモートプロシージャコール (Remote Procedure Call, RPC) プリミティブを使用することで実現されます。NFSバージョン2プロトコルの実装は、パーソナルコンピュータからスーパーコンピュータまで、さまざまなマシンに存在します。NFSプロトコルの初期バージョンは、Network File System Protocol Specification [RFC1094] で規定されています。初期実装の説明は [Sandberg] にあります。
サポートする MOUNT プロトコルは、クライアントがリモートディレクトリツリーをローカルファイルシステム内のポイントにアタッチすることを可能にする、オペレーティングシステム固有の機能を実行します。マウントプロセスは、エクスポート制御を介して、制限されたクライアントセットにリモートアクセス権限を付与することもサーバーに許可します。
ロックマネージャ (Lock Manager) は、NFS環境で使用される場合にファイルロックのサポートを提供します。Network Lock Manager (NLM) プロトコルは、ファイルロックの本質的にステートフルな側面を別のプロトコルに分離します。
上記のプロトコルとその実装の完全な説明は [X/OpenNFS] にあります。
このドキュメントの目的は:
-
NFSバージョン3プロトコルを規定すること。
-
アノテーションと意図された実装の説明を通じてプロトコルのセマンティクスを記述すること。
-
MOUNTバージョン3プロトコルを規定すること。
-
NLMバージョン3プロトコルとNLMバージョン4プロトコル間の変更を簡単に説明すること。
規範的テキストは、RPCプロシージャとその引数および結果の記述であり、これはオーバーザワイヤプロトコル (over-the-wire protocol) とこれらのプロシージャのセマンティクスを定義します。実装実践を記述する資料は、プロトコル仕様の理解を助け、いくつかの可能な実装の問題と解決策を説明します。すべての実装を記述することは不可能であるため、NFSバージョン3プロトコルのUNIXオペレーティングシステム実装が例を提供するために最もよく使用されます。このため、実装の議論は、オーバーザワイヤプロトコルの記述自体の権威を持ちません。
1.1 NFSバージョン3プロトコルの範囲 (Scope of the NFS version 3 protocol)
このNFSプロトコルの改訂は、新しい要件に対処します。より大きなファイルとファイルシステムをサポートする必要性により、64ビットファイルサイズとオフセットを許可する拡張が促されました。この改訂は、サーバー上でアクセスチェックを実行するサポートを追加することでセキュリティを強化します。パフォーマンスの変更は3つのタイプがあります:
-
特定のファイル操作セットのオーバーザワイヤパケット数は、すべての操作でファイル属性を返すことで削減され、変更された属性を取得する呼び出し数が減少します。
-
NFSバージョン2プロトコルでの書き込みの同期定義によって引き起こされる書き込みスループットのボトルネックは、NFSサーバーが安全でない書き込み (unsafe writes) を実行できるようにサポートを追加することで対処されました。安全でない書き込みとは、操作が返される前に安定したストレージにコミットされていない書き込みです。この仕様は、これらの安全でない書き込みを信頼性の高い方法で安定したストレージにコミットする方法を定義します。
-
転送サイズの制限が緩和されました。
RPCでプロトコルの複数バージョンをサポートする機能により、NFSバージョン3プロトコルの実装者は、既存のNFSバージョン2プロトコル実装の基盤と下位互換性を提供するクライアントとサーバーを定義できます。
ここで説明する拡張は、既存のNFSプロトコルの進化を表しており、[Sandberg] で説明されているNFSプロトコルの設計機能のほとんどは維持されています。この改訂で導入された変更の詳細な要約については、11ページの「NFSバージョン2プロトコルからの変更」を参照してください。
1.2 有用な用語 (Useful terms)
この仕様では、"サーバー (server)" はネットワークにリソースを提供するマシンです; "クライアント (client)" はネットワーク経由でリソースにアクセスするマシンです; "ユーザー (user)" はクライアントにログインしている人です; "アプリケーション (application)" はクライアント上で実行されるプログラムです。
1.3 リモートプロシージャコール (Remote Procedure Call)
Sun Remote Procedure Call仕様は、リモートサービスへのプロシージャ指向インターフェースを提供します。各サーバーはプログラム、つまりプロシージャのセットを提供します。NFSサービスはそのようなプログラムの1つです。ホストアドレス、プログラム番号、バージョン番号、プロシージャ番号の組み合わせが1つのリモートサービスプロシージャを指定します。サーバーは、異なるプロトコルバージョン番号を使用することで、プログラムの複数のバージョンをサポートできます。
NFSプロトコルは、下位レベルから特定のレベルの信頼性を必要としないように設計されているため、多くの基礎となるトランスポートプロトコルで使用される可能性があります。NFSサービスはRPCに基づいており、これは下位レベルのネットワークおよびトランスポートプロトコルの上に抽象化を提供します。
このドキュメントの残りの部分は、NFS環境がSun RPCの上に実装されていることを前提としています。Sun RPCは [RFC1057] で規定されています。完全な議論は [Corbin] にあります。
1.4 外部データ表現 (External Data Representation)
外部データ表現 (eXternal Data Representation, XDR) 仕様は、ネットワーク上でデータ型のセットを表現する標準的な方法を提供します。これにより、異なる通信マシン間でのバイトオーダー、構造体アラインメント、データ型表現の違いの問題が解決されます。
このドキュメントでは、RPCデータ記述言語 (RPC Data Description Language) を使用して、NFSサーバーが提供する各RPCサービスプロシージャのXDR形式パラメータと結果を指定します。RPCデータ記述言語は、Cプログラミング言語の宣言に似ています。いくつかの新しい構造が追加されています。表記:
string name[SIZE];
string data<DSIZE>;
は、name を定義します。これはSIZEバイトの固定サイズブロックであり、data は最大DSIZEバイトの可変サイズブロックです。この表記は、固定長配列と固定最大値までの可変数の要素を持つ配列を示します。サイズが指定されていない可変長定義は、フィールドに最大サイズがないことを意味します。
判別共用体 (discriminated union) の定義:
union example switch (enum status) {
case OK:
struct {
filename file1;
filename file2;
integer count;
}
case ERROR:
struct {
errstat error;
integer errno;
}
default:
void;
}
は、ネットワーク上の最初のものがstatusという列挙型である構造を定義します。statusの値がOKの場合、ネットワーク上の次のものはfile1、file2、countを含む構造になります。そうでなく、statusの値がERRORの場合、ネットワーク上の次のものはerrorとerrnoを含む構造になります。statusの値がOKでもERRORでもない場合、構造にはそれ以上のデータはありません。
XDR型 hyper は8バイト (64ビット) の量です。整数型と同じ方法で使用されます。例えば:
hyper foo;
unsigned hyper bar;
fooは8バイトの符号付き値であり、barは8バイトの符号なし値です。
RPCデータ記述言語入力からクライアントとサーバースタブを生成するRPC/XDRコンパイラが存在しますが、NFS実装ではそれらの使用は必要ありません。XDRで定義されたデータの正規ネットワーク順序と同等のエンコードとデコードを提供するソフトウェアは、他のNFS実装と相互運用するために使用できます。
XDRは [RFC1014] で説明されています。
1.5 認証と権限チェック (Authentication and Permission Checking)
RPCプロトコルには、すべての呼び出しで認証パラメータのスロットが含まれています。認証パラメータの内容は、サーバーとクライアントが使用する認証のタイプによって決定されます。サーバーは、複数の異なる認証フレーバーを同時にサポートできます。AUTH_NONEフレーバーはヌル認証を提供します。つまり、認証情報は渡されません。AUTH_UNIXフレーバーは、各呼び出しでUNIXスタイルのユーザーID、グループID、およびグループを提供します。AUTH_DESフレーバーは、ネットワーク全体の名前に基づくDES暗号化認証パラメータを提供し、公開鍵スキームを介してセッション鍵を交換します。AUTH_KERBフレーバーは、Kerberos秘密鍵を介してセッション鍵を交換するネットワーク全体の名前に基づくDES暗号化認証パラメータを提供します。
NFSサーバーは、各リモート要求のRPC認証情報から資格情報を取得して権限をチェックします。例えば、AUTH_UNIXフレーバーの認証を使用して、サーバーは各呼び出しでユーザーの有効ユーザーID、有効グループID、およびグループを取得し、それらを使用してアクセスをチェックします。ユーザーIDとグループIDを使用することは、クライアントとサーバーが同じIDリストを共有するか、ローカルユーザーおよびグループIDマッピングを実行することを意味します。一貫したユーザーIDとグループIDスペースを実装していないサイトの場合、サーバーとクライアントは、ユーザーからuidへ、グループからgidへのマッピングについて合意する必要があります。実際には、このようなマッピングは通常、静的マッピングスキームまたはマウント時にクライアントからユーザーによって確立されたマッピングに従って、サーバー上で実行されます。
AUTH_DESおよびAUTH_KERBスタイルの認証は、ネットワーク全体の名前に基づいています。AUTH_DESの場合はDES暗号化と公開鍵の使用により、AUTH_KERBの場合はDES暗号化とKerberos秘密鍵 (およびチケット) により、より高いセキュリティを提供します。繰り返しますが、サーバーとクライアントは、ネットワーク上の特定の名前のアイデンティティについて合意する必要がありますが、名前からアイデンティティへのマッピングは、AUTH_UNIXのuidとgidマッピングよりもオペレーティングシステムに依存しません。また、認証パラメータが暗号化されているため、悪意のあるユーザーがそのユーザーになりすますには、別のユーザーのネットワークパスワードまたは秘密鍵を知っている必要があります。同様に、サーバーが返すベリファイアも暗号化されているため、サーバーになりすますにはネットワークパスワードを知っている必要があります。
NULLプロシージャは通常、認証を必要としません。
1.6 設計哲学 (Philosophy)
この仕様は、NFSバージョン3プロトコル、つまりクライアントがサーバーにアクセスするオーバーザワイヤプロトコルを定義します。プロトコルは、サーバーのファイルリソースへの明確に定義されたインターフェースを提供します。クライアントまたはサーバーはプロトコルを実装し、ローカルファイルシステムのセマンティクスとアクションをNFSバージョン3プロトコルで定義されたものへのマッピングを提供します。実装は、特定の環境がNFSバージョン3プロトコルで定義されたすべての操作とセマンティクスをサポートできる程度に応じて、さまざまな程度で異なる場合があります。実装が存在し、NFSバージョン3プロトコルのさまざまな側面を説明するために使用されますが、プロトコル仕様自体がクライアントがサーバーリソースにアクセスする方法の最終的な記述です。
NFSバージョン3プロトコルはオペレーティングシステムに依存しないように設計されているため、必ずしも既存のシステムのセマンティクスと一致するわけではありません。サーバー実装は、プロトコルをサポートするために最善を尽くすことが期待されます。サーバーが特定のプロトコルプロシージャをサポートできない場合、操作がサポートされていないことを示すエラーNFS3ERR_NOTSUPを返すことができます。例えば、多くのオペレーティングシステムはハードリンクの概念をサポートしていません。ハードリンクをサポートできないサーバーは、LINK要求に対してNFS3ERR_NOTSUPを返す必要があります。FSINFOは、プロパティビットマップで最も一般的にサポートされていないプロシージャを記述します。あるいは、サーバーは特定の操作をネイティブにサポートしていない場合がありますが、より大きな機能を提供するためにNFSバージョン3プロトコル実装でエミュレートできます。
場合によっては、サーバーはプロトコルで説明されているセマンティクスのほとんどをサポートできますが、すべてではありません。例えば、fattr構造のctimeフィールドは、ファイルの属性が最後に変更された時刻を示します。多くのシステムはこの情報を保持していません。この場合、サーバーはGETATTR操作をサポートしないのではなく、ctimeの代わりに最終変更時刻を返すことでシミュレートできます。サーバーは、クライアントに対する副作用の可能性があるため、属性情報をシミュレートする際には注意する必要があります。例えば、多くのクライアントは、キャッシュ一貫性スキームの基礎としてファイル変更時刻を使用します。
NFSサーバーは単純で、NFSクライアントはスマートです。サーバーが提供する一般化されたファイルアクセスを、アプリケーションとユーザーにとって有用なファイルアクセス方法に変換するために必要な作業を行うのはクライアントです。上記のLINKの例では、サーバーからNFS3ERR_NOTSUPエラーを受信したUNIXクライアントは、アプリケーションにリンク要求が成功したように見せるか、合理的なエラーを返すために必要なリカバリを実行します。一般的に、リカバリの負担はクライアントにあります。
NFSバージョン3プロトコルは、ステートレスサーバー実装を前提としています。ステートレスとは、サーバーが正しく機能するためにクライアントに関する状態を維持する必要がないことを意味します。ステートレスサーバーは、クラッシュ時にステートフルサーバーよりも明確な利点があります。ステートレスサーバーの場合、クライアントはサーバーが応答するまで要求を再試行するだけでよく、クライアントはサーバーがクラッシュしたことを知る必要さえありません。詳細については、99ページの「重複要求キャッシュ」を参照してください。
サーバーが有用であるためには、不揮発性状態を保持します: ファイルシステムに格納されたデータ。NFSバージョン3プロトコルでの変更されたデータを安定したストレージにフラッシュすることに関する設計上の前提により、データ損失が発生する可能性のある障害モードの数が削減されます。この方法で、NFSバージョン3プロトコル実装は、ネットワークの一時的な障害を含む一時的な障害を許容できます。一般的に、NFSバージョン3プロトコルのサーバー実装は、安定したストレージ自体の非一時的な障害を許容できません。ただし、このような問題に対処しようとするフォールトトレラントな実装が存在します。
これは、NFSバージョン3プロトコルサーバーが非クリティカルな状態を維持できないということではありません。多くの場合、サーバーはパフォーマンスを向上させるために、以前の操作に関する状態 (キャッシュ) を維持します。例えば、クライアントのREAD要求は、クライアントが順次読み取りを実行していることを予測して、ファイルの次のブロックをサーバーのデータキャッシュに先読みすることをトリガーする可能性があり、次のクライアントREAD要求は、ディスクからではなくサーバーのデータキャッシュから満たされます。サーバー上の先読みは、サーバーディスクI/Oとクライアント要求を重ね合わせることでパフォーマンスを向上させます。ここで重要な点は、先読みブロックが正しいサーバー動作に必要ではないということです。サーバーがクラッシュして読み取りバッファのメモリキャッシュを失った場合、再起動時のリカバリは簡単です - クライアントはサーバーディスクからデータを取得する読み取り操作を継続します。
NFSプロトコルのほとんどのデータ変更操作は同期的です。つまり、データ変更プロシージャがクライアントに戻ると、クライアントは操作が完了し、要求に関連付けられた変更されたデータが安定したストレージ上にあると想定できます。例えば、同期クライアントWRITE要求により、サーバーはデータブロック、ファイルシステム情報ブロック、およびファイル属性情報を更新する可能性があります - 後者の情報は通常メタデータ (metadata) と呼ばれます。WRITE操作が完了すると、クライアントは書き込みデータが安全であると想定し、それを破棄できます。これは、サーバーのステートレス性の非常に重要な部分です。サーバーがクライアントに戻る前にダーティデータを安定したストレージにフラッシュしない場合、クライアントは変更されたデータを安全に破棄できるタイミングを知る方法がありません。次のデータ変更プロシージャは同期的です: WRITE (安定フラグがFILE_SYNCに設定されている場合)、CREATE、MKDIR、SYMLINK、MKNOD、REMOVE、RMDIR、RENAME、LINK、およびCOMMIT。
NFSバージョン3プロトコルは、WRITEプロシージャをCOMMITプロシージャと組み合わせて使用する場合に、サーバー上で安全な非同期書き込みを導入します。COMMITプロシージャは、クライアントが以前の非同期WRITE要求からのデータをサーバー上の安定したストレージにフラッシュし、データを再送信する必要があるかどうかを検出する方法を提供します。49ページのWRITEと92ページのCOMMITのプロシージャ記述を参照してください。
LOOKUPプロシージャは、クライアントが複数コンポーネントのファイル名 (パス名) をトラバースするために使用されます。各LOOKUP呼び出しは、パス名の1つのセグメントを解決するために使用されます。LOOKUPを単一のセグメントに制限する理由は2つあります: 階層ファイル名の共通形式を標準化することは困難であり、クライアントとサーバーはパス名からファイルシステムへの異なるマッピングを持つ可能性があります。これは、クライアントがファイルシステムアタッチメントポイントでパス名を分割する必要があるか、サーバーがクライアントのファイルシステムアタッチメントポイントについて知っている必要があることを意味します。NFSバージョン3プロトコル実装では、クライアントがマウントを使用して階層を構築することで階層ファイル名空間を構築します。Automounterなどのサポートユーティリティは、クライアントマウントプロセスによって駆動されながら、ファイル名空間の共有された一貫したイメージを管理する方法を提供します。
クライアントは、さまざまな方法でキャッシングを実行できます。NFSバージョン2プロトコルでの一般的な実践は、時間ベースのクライアントサーバーキャッシュ一貫性メカニズムを実装することでした。NFSバージョン3プロトコル実装は、同様のメカニズムを使用することが期待されます。NFSバージョン3プロトコルには、明示的な属性チェックを排除するために、追加の属性情報の形式でいくつかの明示的なサポートがあります。ただし、キャッシングは必要なく、プロトコルによってキャッシングポリシーも定義されていません。NFSバージョン2プロトコルとNFSバージョン3プロトコルはどちらも、厳密なクライアントサーバー一貫性 (および、暗黙的に、クライアントキャッシュ全体の一貫性) を維持する手段を提供しません。
1.7 NFSバージョン2プロトコルからの変更 (Changes from the NFS Version 2 Protocol)
ROOTおよびWRITECACHEプロシージャは削除されました。MKNODプロシージャは、特殊ファイルの作成を許可するために定義され、CREATEのオーバーロードを排除しました。クライアント上のキャッシングは、プロトコルによって定義または指示されませんが、キャッシングを実装するクライアントがキャッシュをより効果的に管理できるように、追加の情報とヒントがプロトコルに追加されました。ファイルまたはディレクトリの属性に影響を与えるプロシージャは、操作完了後に新しい属性を返すことができるようになり、属性キャッシュの検証に使用される後続のGETATTRを最適化します。さらに、ターゲットオブジェクトが存在するディレクトリを変更する操作は、ディレクトリの古い属性と新しい属性を返し、クライアントがより賢明なキャッシュ無効化プロシージャを実装できるようにします。ACCESSプロシージャはサーバー上でアクセス権限チェックを提供し、FSSTATプロシージャはファイルシステムに関する動的情報を返し、FSINFOプロシージャはファイルシステムとサーバーに関する静的情報を返し、READDIRPLUSプロシージャはディレクトリエントリに加えてファイルハンドルと属性を返し、PATHCONFプロシージャはファイルに関するPOSIX pathconf情報を返します。
以下は、NFSバージョン2プロトコルとNFSバージョン3プロトコル間の重要な変更のリストです。
ファイルハンドルサイズ (File handle size)
ファイルハンドルは、32バイトの固定配列から最大64バイトの可変長配列に拡張されました。これにより、やや大きなファイルハンドルサイズのいくつかの既知の要件に対処します。ファイルハンドルは、64バイトの長さ全体を使用しないシステムのローカルストレージとネットワーク帯域幅要件を削減するために、固定長から可変長に変換されました。
最大データサイズ (Maximum data sizes)
READおよびWRITEプロシージャで使用されるデータ転送の最大サイズは、FSINFO戻り構造の値によって設定されるようになりました。さらに、推奨転送サイズもFSINFOによって返されます。プロトコルは、最大転送サイズに人為的な制限を課しません。
ファイル名とパス名は、可変長の文字列として指定されるようになりました。実際の長さ制限は、クライアントとサーバーの実装によって適切に決定されます。プロトコルは、長さに人為的な制限を課しません。エラーNFS3ERR_NAMETOOLONGは、サーバーが処理するには長すぎるパス名を受信したことをクライアントに返すための表示をサーバーが返すことを許可するために提供されます。
エラー戻り値 (Error return)
一部のインスタンスでは、エラー戻り値がデータ (例: 属性) を返すようになりました。nfsstat3は、サーバーが返すことができるエラーの完全なセットを定義するようになりました。他の値は許可されません。
ファイルタイプ (File type)
ファイルタイプには、特殊ファイル用のNF3CHRとNF3BLKが含まれるようになりました。これらのタイプの属性には、UNIXメジャーおよびマイナーデバイス番号のサブフィールドが含まれます。ファイルシステム内のソケットとFIFO用にNF3SOCKとNF3FIFOが定義されるようになりました。
ファイル属性 (File attributes)
blocksize (ファイル内のブロックのサイズ（バイト単位）) フィールドは削除されました。modeフィールドには、ファイルタイプ情報が含まれなくなりました。sizeおよびfileidフィールドは、4バイト整数から8バイト符号なし整数に拡張されました。メジャーおよびマイナーデバイス番号情報は、異なる構造で提示されるようになりました。blocksフィールド名はusedに変更され、ファイルが使用する合計バイト数が含まれるようになりました。これも8バイト符号なし整数です。
ファイル属性の設定 (Set file attributes)
NFSバージョン2プロトコルでは、設定可能な属性はファイル属性構造のサブセットで表されていました; クライアントは、対応するフィールドを-1に設定することで、変更しない属性を示し、一部の符号なしフィールドをオーバーロードしました。ファイル属性設定構造は、各フィールドに判別共用体を使用して、そのフィールドを設定するかどうか、またはどのように設定するかを伝えるようになりました。atimeおよびmtimeフィールドは、サーバーの現在時刻またはクライアントが提供する時刻のいずれかに設定できます。
LOOKUP
LOOKUP戻り構造には、検索されたディレクトリの属性が含まれるようになりました。
ACCESS
明示的なオーバーザワイヤ権限チェックを許可するために、ACCESSプロシージャが追加されました。これにより、多くのサーバー実装でのスーパーユーザーIDマッピング機能の既知の問題 (ルートユーザーのマッピングにより、ファイルの読み取りまたは書き込み中に予期しない権限拒否エラーが発生する可能性がある) に対処します。これにより、NFSバージョン2プロトコルでの、ファイルへのアクセスがUNIXスタイルのモードビットのみに基づいているという仮定も削除されます。
READ
応答構造には、READでファイルの終わりに遭遇した場合にTRUEとなるブール値が含まれます。これにより、クライアントはファイルの終わりを正しく検出できます。
WRITE
beginoffsetおよびtotalcountフィールドは、WRITE引数から削除されました。必要に応じて、応答にはカウントが含まれるようになり、サーバーは要求されたデータ量よりも少ない量を書き込むことができます。クライアントが必要とするキャッシュ同期のレベルをサーバーに指示するために、引数にインジケータが追加されました。
CREATE
通常ファイルの排他的作成のために、排他フラグと作成ベリファイアが追加されました。
MKNOD
特殊ファイルの作成をサポートするために、このプロシージャが追加されました。これにより、一部のNFSバージョン2プロトコル実装で行われたように、CREATEのオーバーロードが回避されます。
READDIR
READDIR引数には、サーバーがCookieを検証できるようにするベリファイアが含まれるようになりました。Cookieは、NFSバージョン2プロトコルで使用されていた4バイト配列ではなく、64ビット符号なし整数になりました。これにより、相互運用性の問題を軽減できます。
READDIRPLUS
拡張ディレクトリリストでファイルハンドルと属性を返すために、このプロシージャが追加されました。
FSINFO
ファイルシステムに関する不揮発性情報を提供するために、FSINFOが追加されました。応答には、推奨および最大読み取り転送サイズ、推奨および最大書き込み転送サイズ、およびリンクまたはシンボリックリンクがサポートされているかどうかを示すフラグが含まれます。また、READDIRプロシージャ応答の推奨転送サイズ、サーバー時間粒度、およびSETATTR要求で時刻を設定できるかどうかも返されます。
FSSTAT
Unix systemのdfコマンドなどのユーティリティで使用するために、ファイルシステムに関する揮発性情報を提供するために、FSSTATが追加されました。応答には、バイト単位で指定されたファイルシステムの合計サイズと空き容量、ファイルシステム内のファイルの総数と空きファイルスロット数、およびファイルシステム変更間の時間推定 (キャッシュ一貫性チェックアルゴリズムで使用) が含まれます。
COMMIT
COMMITプロシージャは、非同期WRITE操作と共に使用される同期メカニズムを提供します。
2. RPC情報 (RPC Information)
2.1 認証 (Authentication)
NFSサービスは、NULLプロシージャでAUTH_NONEを使用します。AUTH_UNIX、AUTH_DES、またはAUTH_KERBは、他のすべてのプロシージャで使用されます。将来的には他の認証タイプがサポートされる可能性があります。
2.2 定数 (Constants)
NFSバージョン3サービスを呼び出すために必要なRPC定数です。これらは10進数で示されています。
PROGRAM 100003
VERSION 3
2.3 トランスポートアドレス (Transport address)
NFSプロトコルは通常、TCPおよびUDPプロトコル上でサポートされます。NFSバージョン2プロトコルと同じポート2049を使用します。
2.4 サイズ (Sizes)
NFSバージョン3プロトコルで使用されるさまざまなXDR構造体のサイズを10進バイト単位で示します:
NFS3_FHSIZE 64
- 不透明なファイルハンドルの最大サイズ（バイト単位）。
NFS3_COOKIEVERFSIZE 8
- READDIRおよびREADDIRPLUSによって渡される不透明なクッキー検証子のサイズ（バイト単位）。
NFS3_CREATEVERFSIZE 8
- 排他的CREATEに使用される不透明な検証子のサイズ（バイト単位）。
NFS3_WRITEVERFSIZE 8
- 非同期WRITEに使用される不透明な検証子のサイズ（バイト単位）。
2.5 基本データ型 (Basic Data Types)
以下のXDR定義は、他の構造体で使用される基本定義です。
uint64
typedef unsigned hyper uint64;
int64
typedef hyper int64;
uint32
typedef unsigned long uint32;
int32
typedef long int32;
filename3
typedef string filename3<>;
nfspath3
typedef string nfspath3<>;
fileid3
typedef uint64 fileid3;
cookie3
typedef uint64 cookie3;
cookieverf3
typedef opaque cookieverf3[NFS3_COOKIEVERFSIZE];
createverf3
typedef opaque createverf3[NFS3_CREATEVERFSIZE];
writeverf3
typedef opaque writeverf3[NFS3_WRITEVERFSIZE];
uid3
typedef uint32 uid3;
gid3
typedef uint32 gid3;
size3
typedef uint64 size3;
offset3
typedef uint64 offset3;
mode3
typedef uint32 mode3;
count3
typedef uint32 count3;
nfsstat3
enum nfsstat3 {
NFS3_OK = 0,
NFS3ERR_PERM = 1,
NFS3ERR_NOENT = 2,
NFS3ERR_IO = 5,
NFS3ERR_NXIO = 6,
NFS3ERR_ACCES = 13,
NFS3ERR_EXIST = 17,
NFS3ERR_XDEV = 18,
NFS3ERR_NODEV = 19,
NFS3ERR_NOTDIR = 20,
NFS3ERR_ISDIR = 21,
NFS3ERR_INVAL = 22,
NFS3ERR_FBIG = 27,
NFS3ERR_NOSPC = 28,
NFS3ERR_ROFS = 30,
NFS3ERR_MLINK = 31,
NFS3ERR_NAMETOOLONG = 63,
NFS3ERR_NOTEMPTY = 66,
NFS3ERR_DQUOT = 69,
NFS3ERR_STALE = 70,
NFS3ERR_REMOTE = 71,
NFS3ERR_BADHANDLE = 10001,
NFS3ERR_NOT_SYNC = 10002,
NFS3ERR_BAD_COOKIE = 10003,
NFS3ERR_NOTSUPP = 10004,
NFS3ERR_TOOSMALL = 10005,
NFS3ERR_SERVERFAULT = 10006,
NFS3ERR_BADTYPE = 10007,
NFS3ERR_JUKEBOX = 10008
};
nfsstat3型は、NULLプロシージャを除くすべてのプロシージャの結果とともに返されます。NFS3_OKの値は、呼び出しが正常に完了したことを示します。その他の値は、エラーコードによって識別される呼び出しで何らかのエラーが発生したことを示します。正確な数値エンコーディングに従う必要があることに注意してください。サーバーは他の値を返すことはできません。サーバーは、定義されたエラーコードのセットへのエラー条件のマッピングに最善の努力をすることが期待されています。さらに、この仕様ではエラーの優先順位は指定されていません。エラーの優先順位は、特定の状況で複数のエラーが適用される場合に返すべきエラー値を決定します。エラーの優先順位は、個々のサーバー実装によって決定されます。クライアントが特定のエラーの優先順位を必要とする場合は、特定のエラーを自身でチェックする必要があります。
2.6 定義されたエラー番号 (Defined Error Numbers)
定義された各エラーの説明は以下の通りです:
NFS3_OK
- 呼び出しが正常に完了したことを示します。
NFS3ERR_PERM
- 所有者ではありません。呼び出し元が特権ユーザー（root）でないか、操作のターゲットの所有者でないため、操作が許可されませんでした。
NFS3ERR_NOENT
- ファイルまたはディレクトリが存在しません。指定されたファイルまたはディレクトリ名が存在しません。
NFS3ERR_IO
- I/Oエラー。要求された操作の処理中にハードエラー（ディスクエラーなど）が発生しました。
NFS3ERR_NXIO
- I/Oエラー。そのようなデバイスまたはアドレスはありません。
NFS3ERR_ACCES
- アクセス拒否。呼び出し元は、要求された操作を実行するための正しい権限を持っていません。これを、所有者または特権ユーザーの権限失敗に限定するNFS3ERR_PERMと対比してください。
NFS3ERR_EXIST
- ファイルが存在します。指定されたファイルはすでに存在します。
NFS3ERR_XDEV
- デバイス間のハードリンクを試みました。
NFS3ERR_NODEV
- そのようなデバイスはありません。
NFS3ERR_NOTDIR
- ディレクトリではありません。呼び出し元がディレクトリ操作で非ディレクトリを指定しました。
NFS3ERR_ISDIR
- ディレクトリです。呼び出し元が非ディレクトリ操作でディレクトリを指定しました。
NFS3ERR_INVAL
- 無効な引数または操作でサポートされていない引数。2つの例は、シンボリックリンク以外のオブジェクトに対してREADLINKを試みること、またはこの操作をサポートしていないサーバー上で時刻フィールドをSETATTRしようとすることです。
NFS3ERR_FBIG
- ファイルが大きすぎます。操作により、ファイルがサーバーの制限を超えて拡大されるところでした。
NFS3ERR_NOSPC
- デバイスに空き容量がありません。操作により、サーバーのファイルシステムがその制限を超えるところでした。
NFS3ERR_ROFS
- 読み取り専用ファイルシステム。読み取り専用ファイルシステムで変更操作が試みられました。
NFS3ERR_MLINK
- ハードリンクが多すぎます。
NFS3ERR_NAMETOOLONG
- 操作のファイル名が長すぎました。
NFS3ERR_NOTEMPTY
- 空でないディレクトリを削除しようとしました。
NFS3ERR_DQUOT
- リソース（クォータ）のハードリミットを超えました。サーバー上のユーザーのリソースリミットが超過されました。
NFS3ERR_STALE
- 無効なファイルハンドル。引数で指定されたファイルハンドルが無効でした。そのファイルハンドルによって参照されるファイルはもはや存在しないか、それへのアクセスが取り消されています。
NFS3ERR_REMOTE
- パスのリモートレベルが多すぎます。引数で指定されたファイルハンドルは、サーバー上の非ローカルファイルシステム上のファイルを参照していました。
NFS3ERR_BADHANDLE
- 不正なNFSファイルハンドル。ファイルハンドルが内部整合性チェックに失敗しました。
NFS3ERR_NOT_SYNC
- SETATTR操作中に更新同期の不一致が検出されました。
NFS3ERR_BAD_COOKIE
- READDIRまたはREADDIRPLUSクッキーが古くなっています。
NFS3ERR_NOTSUPP
- 操作はサポートされていません。
NFS3ERR_TOOSMALL
- バッファまたはリクエストが小さすぎます。
NFS3ERR_SERVERFAULT
- 正規のNFSバージョン3プロトコルエラー値のいずれにもマップされないエラーがサーバーで発生しました。クライアントはこれを適切なエラーに変換する必要があります。UNIXクライアントは、これをEIOに変換することを選択できます。
NFS3ERR_BADTYPE
- サーバーがサポートしていないタイプのオブジェクトを作成しようとしました。
NFS3ERR_JUKEBOX
- サーバーはリクエストを開始しましたが、タイムリーに完了できませんでした。クライアントは待機してから、新しいRPCトランザクションIDでリクエストを再試行する必要があります。たとえば、階層ストレージをサポートし、移行されたファイルを処理するリクエストを受信するサーバーからこのエラーが返される必要があります。この場合、サーバーは移入プロセスを開始し、このエラーでクライアントに応答する必要があります。
ftype3
enum ftype3 {
NF3REG = 1,
NF3DIR = 2,
NF3BLK = 3,
NF3CHR = 4,
NF3LNK = 5,
NF3SOCK = 6,
NF3FIFO = 7
};
列挙型ftype3は、ファイルのタイプを示します。タイプNF3REGは通常のファイル、NF3DIRはディレクトリ、NF3BLKはブロック特殊デバイスファイル、NF3CHRはキャラクタ特殊デバイスファイル、NF3LNKはシンボリックリンク、NF3SOCKはソケット、NF3FIFOは名前付きパイプです。正確な列挙エンコーディングに従う必要があることに注意してください。
specdata3
struct specdata3 {
uint32 specdata1;
uint32 specdata2;
};
2つのワードの解釈は、ファイルシステムオブジェクトのタイプによって異なります。ブロック特殊（NF3BLK）またはキャラクタ特殊（NF3CHR）ファイルの場合、specdata1とspecdata2はそれぞれメジャーデバイス番号とマイナーデバイス番号です。（これは明らかにUNIX固有の解釈です。）他のすべてのファイルタイプの場合、これら2つの要素は0に設定するか、クライアントとサーバーで値を合意する必要があります。クライアントとサーバーが値について合意しない場合、クライアントはこれらのフィールドを0に設定されているかのように扱う必要があります。このデータフィールドはfattr3構造体の一部として返されるため、属性を返すすべての応答から利用できます。これらのフィールドはデバイスでないオブジェクトには使用されないため、帯域外情報をサーバーからクライアントに渡すことができます。ただし、繰り返しになりますが、サーバーとクライアントの両方が渡される値について合意する必要があります。
nfs_fh3
struct nfs_fh3 {
opaque data<NFS3_FHSIZE>;
};
nfs_fh3は、LOOKUP、CREATE、SYMLINK、MKNOD、LINK、またはREADDIRPLUS操作でサーバーによって返される可変長の不透明オブジェクトであり、クライアントが後続の操作でファイルを参照するために使用されます。ファイルハンドルには、サーバーが個々のファイルを区別するために必要なすべての情報が含まれています。クライアントにとって、ファイルハンドルは不透明です。クライアントは後のリクエストで使用するためにファイルハンドルを保存し、バイトごとの比較を行うことで同じサーバーからの2つのファイルハンドルを等価性について比較できますが、それ以外の方法でファイルハンドルの内容を解釈することはできません。同じサーバーからの2つのファイルハンドルが等しい場合、それらは同じファイルを参照する必要がありますが、等しくない場合、結論を引き出すことはできません。サーバーは、ファイルハンドルとファイル間の1対1の対応を維持しようとする必要がありますが、これは必須ではありません。クライアントは、正しい動作のためではなく、パフォーマンスを向上させるためにのみファイルハンドルの比較を使用する必要があります。
サーバーは、ファイルハンドルによって提供されるアクセスをいつでも取り消すことができます。呼び出しで渡されたファイルハンドルがサーバー上にもはや存在しないファイルシステムオブジェクトを参照しているか、そのファイルハンドルへのアクセスが取り消されている場合、エラーNFS3ERR_STALEが返される必要があります。
nfstime3
struct nfstime3 {
uint32 seconds;
uint32 nseconds;
};
nfstime3構造体は、1970年1月1日グリニッジ標準時の真夜中からの秒数とナノ秒数を示します。時刻と日付情報を渡すために使用されます。ファイルに関連付けられた時刻は、クライアントがファイル時刻を明示的に設定できるSETATTR操作の場合を除いて、すべてサーバー時刻です。サーバーは、時刻値を処理する際にローカル時刻との間で変換を行い、可能な限り精度を保持します。ファイルに保存されるタイムスタンプの精度がNFSバージョン3プロトコルで定義されたものよりも低い場合、精度の損失が発生する可能性があります。クライアントとサーバーの時刻のずれを減らすために、補助的な時刻維持プロトコルが推奨されます。
fattr3
struct fattr3 {
ftype3 type;
mode3 mode;
uint32 nlink;
uid3 uid;
gid3 gid;
size3 size;
size3 used;
specdata3 rdev;
uint64 fsid;
fileid3 fileid;
nfstime3 atime;
nfstime3 mtime;
nfstime3 ctime;
};
この構造体は、ファイルシステムオブジェクトの属性を定義します。オブジェクトに対するほとんどの操作によって返されます。2つのオブジェクトに影響する操作の場合（たとえば、ターゲットディレクトリ属性を変更し、新しく作成されたディレクトリの新しい属性を定義するMKDIR）、両方の属性が返される場合があります。場合によっては、属性は以下で定義されるwcc_data構造体で返されます。他の場合、属性は単独で返されます。NFSバージョン2プロトコルからの主な変更点は、多くのフィールドが拡張され、メジャー/マイナーデバイス情報がワードにパックされるのではなく、別個の構造体で表示されるようになったことです。
fattr3構造体には、ファイルの基本属性が含まれています。すべてのサーバーは、一部のフィールドをシミュレートする必要がある場合でも、この属性セットをサポートする必要があります。Typeはファイルのタイプです。Modeは保護モードビットです。Nlinkはファイルへのハードリンクの数、つまり同じファイルの異なる名前の数です。Uidはファイルの所有者のユーザーIDです。Gidはファイルのグループのグループ IDです。Sizeはファイルのバイト単位のサイズです。Usedは、ファイルが実際に使用するディスクスペースのバイト数です（ファイルにホールがある場合はサイズより小さくなる可能性があり、断片化のためにより大きくなる可能性があります）。Rdevは、ファイルタイプがNF3CHRまたはNF3BLKの場合、デバイスファイルを記述します - 20ページのspecdata3を参照してください。Fsidは、ファイルシステムのファイルシステム識別子です。Fileidは、ファイルシステム内でファイルを一意に識別する番号です（UNIXではこれはinumberになります）。Atimeは、ファイルデータが最後にアクセスされた時刻です。Mtimeは、ファイルデータが最後に変更された時刻です。Ctimeは、ファイルの属性が最後に変更された時刻です。ファイルへの書き込みは、mtimeに加えてctimeも変更します。
モードビットは次のように定義されています:
0x00800 実行時にユーザーIDを設定
0x00400 実行時にグループIDを設定
0x00200 スワップされたテキストを保存（POSIXで定義されていません）
0x00100 所有者の読み取り権限
0x00080 所有者の書き込み権限
0x00040 ファイルに対する所有者の実行権限。またはディレクトリ内の所有者の検索権限。
0x00020 グループの読み取り権限
0x00010 グループの書き込み権限
0x00008 ファイルに対するグループの実行権限。またはディレクトリ内のグループの検索権限。
0x00004 その他の読み取り権限
0x00002 その他の書き込み権限
0x00001 ファイルに対するその他の実行権限。またはディレクトリ内のその他の検索権限。
post_op_attr
union post_op_attr switch (bool attributes_follow) {
case TRUE:
fattr3 attributes;
case FALSE:
void;
};
この構造体は、属性の操作に直接関与していない操作で属性を返すために使用されます。このNFSプロトコルの改訂の原則の1つは、付随的な操作からのエラーではなく、指定された操作からの実際の値を返すことです。post_op_attr構造体は、属性の取得中に発生したエラーからサーバーが回復できるように設計されました。
これは属性を返すことをオプションにしているように見えます。ただし、サーバー実装者は、エラーを返す場合でも、可能な限り属性を返すように最善の努力をすることを強く推奨されます。
wcc_attr
struct wcc_attr {
size3 size;
nfstime3 mtime;
nfstime3 ctime;
};
これは、弱いキャッシュ一貫性セマンティクスをよりよくサポートするために必要な操作前属性のサブセットです。Sizeは、操作前のオブジェクトのファイルサイズ（バイト単位）です。Mtimeは、操作前のオブジェクトの最終変更時刻です。Ctimeは、操作前のオブジェクトの属性の最終変更時刻です。24ページのwcc_attrの議論を参照してください。
クライアントがmtimeを使用してサーバー上にあるファイルシステムオブジェクトへの変更を検出することは、サーバー上の時間ベースの粒度に依存します。
pre_op_attr
union pre_op_attr switch (bool attributes_follow) {
case TRUE:
wcc_attr attributes;
case FALSE:
void;
};
wcc_data
struct wcc_data {
pre_op_attr before;
post_op_attr after;
};
クライアントがサーバー上のファイルまたはディレクトリの状態を変更する操作を実行する場合、クライアントが最後にオブジェクトの属性を受け取ったときから、実行された操作がオブジェクトに対する唯一の操作であったかどうかを、操作後の属性からすぐに判断することはできません。これは重要です。なぜなら、介在する操作がオブジェクトを変更した場合、クライアントはオブジェクトのキャッシュされたデータ（書き込んだばかりのデータを除く）を無効にする必要があるからです。
これに対処するために、弱いキャッシュ一貫性データまたはwcc_dataの概念が導入されています。wcc_data構造体は、操作前のオブジェクト属性の特定のキーフィールドと、操作後のオブジェクト属性で構成されます。この情報により、クライアントはNFSバージョン2プロトコル実装よりも正確にキャッシュを管理できます。弱いキャッシュ一貫性という用語は、このメカニズムがキャッシュ一貫性プロトコルが提供するような厳密なサーバー・クライアント一貫性を提供しないという事実を強調しています。
弱いキャッシュ一貫性モデルをサポートするために、サーバーはオブジェクトの操作前の属性を取得し、意図された変更操作を実行してから、操作後の属性をアトミックに取得できる必要があります。操作とget attributes操作のいずれかの間にオブジェクトが変更されるウィンドウがある場合、クライアントはオブジェクトを変更した唯一のエンティティであるかどうかを判断できません。一部の情報が失われ、弱いキャッシュ一貫性の保証が弱まります。
post_op_fh3
union post_op_fh3 switch (bool handle_follows) {
case TRUE:
nfs_fh3 handle;
case FALSE:
void;
};
このNFSプロトコルの改訂の原則の1つは、付随的な操作からのエラーではなく、指定された操作からの実際の値を返すことです。post_op_fh3構造体は、ファイルハンドルの構築中に発生したエラーからサーバーが回復できるように設計されました。
これは、CREATE、MKDIR、SYMLINK、MKNOD、およびREADDIRPLUSリクエストからファイルハンドルを返すために使用される構造体です。各ケースで、クライアントは、リストされた操作のいずれかからの正常な復帰後にLOOKUPリクエストを発行することでファイルハンドルを取得できます。ファイルハンドルを返すことは、クライアントがファイルハンドルを取得するためにすぐにLOOKUPリクエストを発行することを強制されないようにするための最適化です。
sattr3
enum time_how {
DONT_CHANGE = 0,
SET_TO_SERVER_TIME = 1,
SET_TO_CLIENT_TIME = 2
};
union set_mode3 switch (bool set_it) {
case TRUE:
mode3 mode;
default:
void;
};
union set_uid3 switch (bool set_it) {
case TRUE:
uid3 uid;
default:
void;
};
union set_gid3 switch (bool set_it) {
case TRUE:
gid3 gid;
default:
void;
};
union set_size3 switch (bool set_it) {
case TRUE:
size3 size;
default:
void;
};
union set_atime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
nfstime3 atime;
default:
void;
};
union set_mtime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
nfstime3 mtime;
default:
void;
};
struct sattr3 {
set_mode3 mode;
set_uid3 uid;
set_gid3 gid;
set_size3 size;
set_atime atime;
set_mtime mtime;
};
sattr3構造体には、クライアントから設定できるファイル属性が含まれています。フィールドは、fattr3構造体の同様の名前のフィールドと同じです。NFSバージョン3プロトコルでは、設定可能な属性は、判別共用体のセットを含む構造体によって記述されます。各共用体は、対応する属性を更新するかどうか、更新する場合はどのように更新するかを示します。
2つの形式の判別共用体が使用されます。mode、uid、gid、またはsizeを設定する場合、判別共用体はブール値set_itで切り替えられます。TRUEの場合、適切なタイプの値がエンコードされます。
atimeまたはmtimeを設定する場合、共用体は列挙型set_itで切り替えられます。set_itの値がDONT_CHANGEの場合、対応する属性は変更されません。値がSET_TO_SERVER_TIMEの場合、対応する属性はサーバーによってローカル時刻に設定されます。クライアントからデータは提供されません。最後に、set_itの値がSET_TO_CLIENT_TIMEの場合、属性はクライアントがnfstime3構造体で渡した時刻に設定されます。（時刻粒度の問題を扱う86ページのFSINFOを参照してください）。
diropargs3
struct diropargs3 {
nfs_fh3 dir;
filename3 name;
};
diropargs3構造体はディレクトリ操作で使用されます。ファイルハンドルdirは、ファイルnameを操作またはアクセスするディレクトリを識別します。101ページの「ファイル名コンポーネントの処理」の追加コメントを参照してください。