要約

  • RFC 1094は、ディレクトリ項目を削除したあともプロセスが開いたファイルを使い続けるOSの動作を、ステートレスなNFSサーバーだけでは実現できないと説明した。
  • 回避案はクライアント側にある。削除時に名前を一時的に変更し、ローカルのopenが終わってからその項目を取り除く。RFCは案を示したが、全実装の動作や障害後の清掃方法までは定めていない。

ファイルの寿命と名前の寿命は一致しない

「削除した」という操作が、すべての利用を同時に終わらせるとは限らない。あるプロセスがファイルを開いて読み、別の操作がディレクトリから名前を消したあとも、そのプロセスは閉じるまで参照を保てるOSがある。名前空間と、開いた参照の寿命は別々に進む。

ネットワークファイルシステムでは、この二つの時計を異なるホストが持つ。アプリケーションとローカルOSはプロセスのopenを知る。一方、サーバーが受け取るのはNFSの個々の要求だ。サーバーはリモートのプロセスがまだファイルを必要としていると、どう知ればよいのか。

1989年3月のRFC 1094は、NFSバージョン2でこの問題を明記した。ステートレスなサーバーは、削除されたファイルをopenしたプロセスが読み書きし続ける意味を実装できない。文書が挙げる案は、削除時にクライアントがファイル名を変更し、close時にその名前を削除するというものだった。

ここで語られているのは、故障ではなく境界だ。サーバーの単純さを保つために、ローカルOSの状態をワイヤ上で共有しない。その代わり、アプリケーションが期待する動作をクライアントが埋め合わせる可能性がある。

NFSv2の要求にはリモートopenがない

NFSv2はLOOKUP、READ、WRITE、CREATE、REMOVE、RENAMEなどの手続きを定義する。REMOVEはディレクトリと名前を受け取り、名前の項目を取り除く。しかし、サーバーに開き始めと最後のcloseを知らせるNFSv2のOPENやCLOSE手続きはない。

読み書きにはサーバーが発行したfile handleを渡すが、その値はローカルプロセスがopen()を呼んだという通知ではない。クライアントのOSはopenをローカルに処理し、後続の読み書きをNFS要求に変換できる。リモート側に一対一のopen記録が作られるとは限らない。

そのため、サーバーがREMOVEを処理しても、別ホストのプロセスがまだ参照を必要としていることは分からない。RFC 1094はクライアント側の模倣を禁じてはいない。ただし、サーバー単体ではそのローカル意味を保てないとする。必要な情報を持つクライアントが橋渡しを担う。

改名は削除の時点をずらす

提案された順序では、クライアントは元の名前をすぐ削除せず、別名へ変更する。利用者からは元の名前が消えるが、サーバー上では一時名が残る。ローカルのopenが終わったあとで初めて、その項目が削除される。

こうすると、見えなくなった名前と解放されたストレージの間に時間差ができる。ユーザーが一度のunlinkとして捉える操作は、実際には複数ホストにまたがる。名前を隠す決定は先に行われ、サーバー上の最終削除はクライアントのcloseを待つ。

RFCは一時名の形式、名前の衝突、クライアントがclose前に再起動した場合の回復、他のクライアントからの見え方を指定していない。したがって、文書に書かれた案を、あるベンダー実装の確定した仕様として語ることはできない。そこにはコード、運用資料、試験記録など別の証拠が必要だ。

この仕組みからは、清掃遅延や一時項目の残存を運用時に確認すべきだと推論できる。ただし、RFC 1094はその発生率も、特定の障害も報告していない。

ステートレスとは対話状態を保存しないこと

RFC 1094の設計目標は、サーバーが各クライアントのプロトコル状態を保たなくても正しく動くことだった。障害後に、クライアントがopenセッション全体を再構成しなくてよい。ファイル内容、属性、ディレクトリ項目やディスク上の状態までなくなるという意味ではない。

open参照はローカルOSの状態である。NFSv2の要求一覧から、サーバーがその寿命を推測することはできない。同じRFCはファイルやレコードのロックを別サービスとして扱い、NFS本体の仕様対象から外している。遠隔操作を用意する範囲と、ローカル規約をプロトコル化する範囲は同じではなかった。

後のNFSは異なる分担を選んだ。NFSv3の手続きには依然としてリモートOPEN、CLOSEがない。NFSv4を記すRFC 7530には、それらの操作とstateidがある。これは全環境での移行や互換性を証明するものではない。open状態の調整をプロトコルへ持ち込み、その費用も受け入れる別の設計が存在することを示している。

互換性を誰が保つのか

サーバーはexportされたディレクトリを管理し、REMOVEを実行する。クライアントOSは、どのプロセスが参照を保持しているかを知る。開いているという情報が届かない以上、サーバーだけで安全な削除時点を判断できない。RFCの改名案は、clientの知識を使って実削除を遅らせる。

この選択には、クライアント内の記録と清掃方針が必要になる。削除後もファイルを使うアプリケーションは、実際のクライアント・サーバー組合せがその意味を保つか確認したい。サーバー管理者には、元の名前がないのに項目が残る理由を説明できる記録が役立つ。RFCはどちらの運用方針も詳細には指定していない。

小さく保ったサーバーには実装上の利点がある。反対に、ローカルOSが提供するすべての約束を遠隔環境でも必要とするなら、追加の調整と試験がいる。マウントが成功した事実だけで、そのセマンティクスまでは証明できない。

出典と証拠の限界

これらの文書は仕様と設計議論を示す。改名案の普及、特定クライアントのクラッシュ後清掃、あるいは問題の発生頻度までは示さない。