要約

  • 9月26日の第12版はNFSv4作業部会の有効なInternet-Draftであり、RFCになったわけではない。
  • 新設されたpNFSの説明は、クライアントが毎回READDIRを行っても、LAYOUTCOMMITより前なら古いファイル属性を受け取り得ると述べる。

数千の出力ファイルが並ぶ共有ディレクトリを、バックアップ処理が巡回する。ある計算ノードがファイルを更新しても、名前やディレクトリの構成は変わらない。ディレクトリ自身の変更属性だけでは、個々のファイルのサイズや更新時刻が変わったことを示せない。そのうえクライアントが前回の一覧に添えられた属性を保持していれば、バックアップは新しい書き込みを見落とし得る。提案中の「キャッシュ不可ディレクトリエントリメタデータ」属性は、このクライアント側の古さに対する、ディレクトリ単位の信号である。

属性が設定されたディレクトリについて、それを尊重するクライアントは列挙のたびに新しいREADDIRを実行する。同じエントリの属性を報告する際、直近のREADDIRより前に持っていた値を使ってはならない。仕組みそのものは9月5日の第11版から存在する。第12版は、単にREADDIRを送るだけでは不足だと説明を補った。属性をほとんど要求しないまま、結果の欄を古いローカル値で埋めれば、更新した意味が消える。必要な属性をREADDIRで要求するか、後からGETATTRで取得する必要があり、後者はエントリごとの通信を増やし得る。

今回加わった第5.2節は、別の古さを明示する。pNFSではディレクトリとこの属性をメタデータサーバーから得る一方、ファイルのデータは別のストレージ装置を経由し得る。あるレイアウトで書き込み後のサイズとtime_modifyがLAYOUTCOMMITまでメタデータサーバーに伝わらないなら、それより前のREADDIRは以前の値を返す。クライアントがその値を報告しても、草案のクライアント規則には従っている。サーバーがまだ知らない書き込みを、クライアントの再読込だけで発見することはできない。

これは「新しく取得した属性」を「全保存装置の最新状態」と同一視しないための境界線だ。ただし、草案はすべてのpNFSレイアウトが同じ伝達経路を持つとは述べていない。ファイル内容のキャッシュ禁止、全体で一つの瞬間を切り取るスナップショット、あるいは書き込みの即時可視化も定めていない。新しい属性が制約するのは、あるディレクトリを列挙したクライアントが何を報告してよいかである。

第12版には操作権限についても重要な追記がある。サーバーは現地の管理方針に従い、属性のSETATTRを拒める。その際はNFS4ERR_ACCESS、または所有者・特権に関する指定された場合のNFS4ERR_PERMを使い、NFS4ERR_INVALを使ってはならない。後者は、対応状況を調べるクライアントに「サーバーは属性を知らない」と誤認させる。対応済みだが変更権限がない場合と、そもそも未対応の場合では、取るべき対策が違う。

公式Datatrackerの状態はなお「I-D Exists」である。実装欄のHammerspaceサーバーとLinuxクライアントは試作についての記述であり、一般的な本番導入や異なる実装間の保証を示すものではない。ニュースは一貫性が完成したことではなく、保証の及ぶ範囲がよりはっきりしたことにある。

出典