要約

  • LAYOUT_WCC は、NFSv3の応答でクライアントが得たデータファイル属性をメタデータサーバーへ運び、追加のGETATTRを省けるようにする。
  • クライアントは報告しないことができ、サーバーも無視または再照会できる。結果には属性ごとの受理表がない。
  • 属性の採用、WRITEの安定化、全ミラーの一致、アプリケーションの結果は、同じ成功応答では証明できない。

あるクライアントが三つのミラーのうち二つだけについて新しい属性を持っている。三番目を空のマスク付きで並べることも、一覧から省くこともできる。この瞬間、「配列の二番目」という説明は証拠として崩れる。

RFC 9766 が要求する device ID、stateid、データファイルhandleの組合せは、この曖昧さへの回答である。しかし、正しい対象を指せたことと、その値が現在の真実であることは別の問題だ。

迂回したI/Oは情報も迂回する

pNFSのflexible file layoutでは、メタデータサーバーがlayout、名前空間、属性を管理し、クライアントはlayoutに従ってデータサーバーへ直接I/Oできる。データサーバーにNFSv3を使う構成では、書込み後の変化をデータサーバーからメタデータサーバーへ一般的に通知する制御路がない。

したがって、メタデータサーバーは必要に応じてデータサーバーへGETATTRを送る。これは直接の確認だが、一往復を追加し、件数が増えればデータ層の負荷になる。クライアント側には、READ、WRITE、COMMITの応答で得たWCC情報が既にある。operation 77は、その既存観測をNFSv4.2属性へ写して返す仕組みだ。

設計が巧いのは、効率化と権限を分離した点にある。報告を利用すれば照会を減らせる。結果の重要性や古さに疑いがあれば、メタデータサーバーはGETATTRを実行してモデルを強められる。

WCCの「弱い」は消せない

RFC 1813のWCCは、操作前のsize、mtime、ctimeなどの要点と、操作後の属性を組み合わせる。クライアントは、自分以外の変更が挟まった可能性を検出し、キャッシュ無効化を判断しやすくなる。

ただし、厳密な整合性プロトコルではない。前属性の取得、変更、後属性の取得が原子的でなければ、途中の書込みを区別できず情報が失われる。原子的であっても、観測後の変更までは拘束しない。RFC 9766はこの証拠強度を変えず、運搬先だけを増やす。

クライアントはWCC属性を使わなくてもよい。メタデータサーバーも報告を無視できる。しかも、クライアントには採用を強制する手段がないため、応答に「どの属性を受理したか」を示すbitmapはない。操作成功を、全フィールド採用の領収書と読んではならない。

同時に届く八項目は同じ重さではない

flexible file layout用のpayloadは、size、space_used、mode、owner、owner_group、time_access、time_modify、time_metadataを対応付ける。uidとgidはowner文字列へ変換される。

容量表示のわずかな遅れと、所有者の誤りは同じ危険ではない。アクセス時刻はREADの手掛かりになり、変更時刻はWRITEの手掛かりになるが、どちらも因果を単独で確定しない。属性ごとに受容条件と直接検証の閾値を分ける必要がある。

RFCは、サイズやchangeや時刻をメタデータサーバーへ問い合わせる直前、NFS4ERR_ACCESSを報告するとき、委譲中に代理していた時刻を更新するときなどを利用例に挙げる。特にアクセスエラー時のuid/gidは有用だが、差があるからといって自動修復が常に正しいわけではない。データ側がずれたのか、期待値が古いのかを別の権威で判断する必要がある。

layoutとデータファイルを混同しない

現在のfilehandleとlowa_stateidが対象layoutを示し、lowa_typeがopaque payloadの解釈を決める。さらに各データファイルを特定する三項目が必要だ。一つのstorage deviceに複数のデータファイルが置かれ得るため、device IDだけでもstateidだけでも足りない。

エラー時には、サーバーが操作全体を無視する場合と、layout固有の内容に応じて一部を適用する場合がある。監査で必要なのはRPCの色ではなく、対象、attribute mask、値、採否、採用時点、直接照会との差分である。

COMMITは別の時計で進む

正しいsizeやmtimeは、データが安定記憶へ到達した証拠ではない。RFC 8435では、データサーバーへのWRITEがFILE_SYNCでなければ、LAYOUTCOMMITの前に該当データサーバーへCOMMITする責任をクライアントへ置く。LAYOUT_WCCはこの順序を代行しない。

ミラーも独立している。client-side mirroringでは全コピー更新後に書込み成功となり、失敗後の修復はメタデータサーバーが担う。一つのミラーの属性は、他のミラーの内容や永続性を証明できない。

アプリケーション層はさらに先にある。属性が新しく、全ミラーが同じでも、アプリケーションが別のfilehandleを参照したり、古いローカルキャッシュを読んだりすれば結果は異なる。技術的に隣接する出来事を一つの「整合」状態へ畳み込むべきではない。

任意機能であることが退路になる

operation 77はNFSv4.2とflexible file layoutの双方でOPTIONALである。未対応は違反ではなく、既存の直接照会経路を使う互換性集合だ。RFC 8178が拡張規律を、RFC 7862と7863がプロトコルとXDRの土台を与える。採用は実装、交渉、実際の呼出しで初めて観測できる。

セキュリティはRFC 8435から継承される。疎結合のsynthetic uid/gidは協力的なクライアントをfenceできても、悪意あるクライアントを止める仕組みではない。密結合では制御プロトコルが責任を持つ。報告チャネルの認証と保護は必要だが、送信者認証は属性の最新性を自動的に作らない。

出典

  1. RFC 9766：NFSv4.2 flexible file layoutのWCC拡張
  2. RFC 8435：pNFS Flexible File Layout
  3. RFC 8434：pNFS Layout Typeの要件
  4. RFC 1813：NFS Version 3 Protocol
  5. RFC 8881：NFS Version 4 Minor Version 1
  6. RFC 7862：NFS Version 4 Minor Version 2
  7. RFC 7863：NFSv4.2 XDR Description
  8. RFC 8178：NFSv4拡張とminor versionの規則
  9. RFC 9754：NFSv4.2のOPENとdelegation拡張
  10. Running-Code Primacy
  11. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile