要約

  • fattr4_uncacheable_file_data はサーバーが望む扱いを表す属性であり、クライアント内部の状態を読み出すセンサーではない。
  • すでに開かれたファイルでは、サーバー側の値の変更とクライアントが新しい動作を採用する時点が一致しないことがある。
  • 読み取りの再検証と書き込みの永続化を操作単位で残して初めて、方針が実際の挙動になったかを確かめられる。

「設定済み」と「実行済み」の間

ネットワーク・ファイルシステムは、データをクライアントの近くに置くことで性能を得る。その代わり、再利用してよい条件をプロトコルが管理する。ところが、別の利用者による更新を素早く見せたいファイルや、書き込みの完了時点を厳密にしたい処理では、一般的なキャッシュの利点より予測可能性が重要になる。

draft-ietf-nfsv4-uncacheable-files-13 は、その判断をファイルごとのブール値で伝えようとしている。欠けていた語彙を補う提案だ。一方、運用画面で真の値を見て「クライアントのキャッシュは消去済み」と表示すれば、提案にない意味を付け足すことになる。

属性を持つのはサーバーである。クライアントは、対象のエクスポートされたファイルシステムが属性を提供するかを確認し、値を読み、実装固有の方法で後続操作に反映する。サーバーの設定時刻は、そのクライアントの観測時刻ではない。特に、値が変わった時点ですでに開かれていたファイルについては、クライアントが従来のキャッシュ動作を直ちに変えなくてもよい。通常のGETATTRや再検証で値を知った後、新しい操作に反映できる。

同じサーバーでも能力は一つではない

属性番号87は読み書き可能で、NFS属性表ではRECOMMENDEDに分類される。この語は属性の分類を示すもので、すべてのNFSv4.2実装に搭載を義務付ける単独の規範語ではない。対応状況は、サーバー製品全体ではなくエクスポートされたファイルシステムごとに異なり得る。同じサーバー上の別ボリュームで成功した検査を、そのまま対象ボリュームの証拠にはできない。

対象オブジェクトも限定される。意味があるのは通常ファイルと名前付き属性であり、それ以外にGETATTRを行うと偽が返る。適切でない種類へのSETATTRは失敗する。このため、値が偽であるという記録だけでは、通常キャッシュを選んだのか、対象外の種類なのか、そもそも能力がないのか判別できない。

値を誰が決めたかも残す必要がある。サーバーは変更を許可しても、ポリシーにより常に拒否してもよい。新規ファイルへ自動的に値を付けるマウント設定も考えられている。通常の認可は維持されるため、サーバーとファイルシステムの識別子、値、ポリシーの出所、決定権者、観測時刻、拒否された変更を別々に保存すべきだ。

書き込み成功の意味を記録する

属性を尊重するクライアントは、効率のために複数のWRITEをまとめる目的だけで処理を遅らせてはならない。さらに、アプリケーションへ書き込み成功を返す時点では、データがサーバー上で永続化されていなければならない。

実現方法は一つに固定されていない。安定書き込みを要求する方法がある。いったん不安定書き込みを送り、アプリケーションに戻る前にCOMMITを完了する方法もある。サーバーの書き込み検証子が変わった場合は、クライアントが手元に保持しているデータから影響部分を再送する。進行中の書き込みを完結させるための一時保持は、禁止対象のキャッシュとは扱われない。

したがって「メモリーにデータがなかった」という検査は、正しさの証明にならない。むしろ、再送に必要なデータまで失っていれば問題になる。必要なのは、要求値と応答値の安定性、COMMITの結果、検証子の連続性、再送の有無、そしてアプリケーションへ成功を返した時刻をつないだ記録である。障害時に特定の書き込みが残ったかを調べられるのは、この順序がある場合だけだ。

読み取りでは「捨てたか」より「確かめたか」

読み取り側で草案が求める中心的な行動は、再検証せずにキャッシュされたファイルデータを再利用しないことだ。最低限、NFSのchange属性とファイルサイズを確認すれば、この期待を満たす。実装はさらに多くの属性を見てもよい。

この考え方はNFSv4.1の既存モデルと連続している。キャッシュの妥当性は時間の推測だけでなく、change属性、OPEN、共有予約、ロック、委任によって調整される。クライアントが一貫した見え方を保証する委任を持つなら、新属性が真でも読み取りデータを保持することが合理的な場合がある。

そこで監査対象は「ページが存在したか」ではなく、「その操作で再利用できるプロトコル上の根拠があったか」になる。読み取り記録には、比較前後のchange値、ファイルサイズ、再検証時刻、関連する委任やロックを保存する。最後に、再利用、無効化、再取得、失敗のどれを選んだかを示す。こうすれば第三者が結論を検算できる。

サーバー台帳とクライアント受領書

サーバー台帳が答えるのは「この時点で、このファイルにどの扱いを提示したか」だ。サーバーとエクスポート先、属性87への対応、ファイルの識別、値、ポリシー、認可主体、観測時刻を含めればよい。

クライアント受領書は「その提示を、このクライアントがどう実行したか」に答える。実装とバージョン、マウント、ファイルハンドル、OPENの世代、値を観測した時刻、観測時点ですでに開いていたかを記録する。読み取りならchange値、サイズ、委任とキャッシュ操作を、書き込みなら安定性、COMMIT、検証子、再送、アプリケーション復帰時刻を加える。

二つは操作識別子で結び、同じ行に潰さない。サーバーが15時に値を変更し、古いOPENを持つクライアントが15時08分に知ったなら、両方の時刻が必要だ。その差は誤差ではなく、展開状況と障害原因を示す観測値である。

任意採用を段階として見せる

この機能はRFC 8178の仕組みによりNFSv4.2を拡張するもので、RFC 7862の基礎を無効にしない。任意機能である以上、実際の環境には複数の段階が並ぶ。未対応、対応しているが偽、真だがクライアント未観測、新規操作へ反映済み、操作受領書まで検証済み、という分布だ。

草案の実装状況には、Hammerspaceのサーバー試作とLinuxクライアント試作が記載される。設定したマウントポイント配下のファイルに対して直接I/Oに似た動作を行い、適切な入出力で性能、メモリー、CPU面の効果が観測されたという。これは実現可能性の根拠だが、すべての実装が同じ設計を選ぶ証拠ではない。「似ている」を「同一である」に変えたり、単一試作の結果を混在環境へ一般化したりしてはならない。

展開報告は各段階の割合を示すべきだ。一つの対応率だけでは、アップグレードが必要なのか、属性設定が不足しているのか、クライアント観測が遅れているのかが分からない。任意採用を隠さない方が、次に投資すべき場所を正確に選べる。

セキュリティ境界ではない

草案は、新しい認可やアクセス制御を追加せず、この属性をアクセス判断に使ってはならないと明記する。権限を持つ利用者による変更が他のクライアントの性能や見え方に影響する可能性はあるため、変更者の監査は重要だ。それでも値そのものが完全性の封印、機密性の制御、古いデータが存在しない証明になるわけではない。

外部説明もこの範囲に合わせる必要がある。「サーバーがキャッシュ抑制を要求した」は証明できる。「計測対象のクライアントが読み取りを再検証した」「成功を返す前に書き込みを永続化した」も、それぞれ受領書があれば証明できる。最初の記録だけから後の二つを推測してはいけない。

新属性の価値は誇張しなくても十分にある。サーバーの意図を標準フィールドで伝えられるようになるからだ。そこへクライアント側の観測証拠を加えれば、どこで意図が挙動になり、どこで止まったかを確かめられる。

情報源