要約

  • RFC 9737 は、MDS の recovery grace period 中に all-zero の anonymous stateid を使い、停止中に観測した data-server I/O error を LAYOUTRETURN で報告できるようにする。
  • 報告内の layout と現在の mirror instance が一致しなければ、MDS は報告を無視して resilver しなければならない。
  • 正しい過去の観測は、現在の対象を同定できなければ現在の決定権を持たない。

クライアントは mirror B への WRITE が失敗したと記録した。offset も length も operation も残っている。ところが MDS が再起動した時点で、ファイルの mirror set は A、C、D に変わっていた。

報告は真実だった。それでも使えなかった。

RFC 9737 の重要な点は、エラー報告を受け取れるようにしたことだけではない。報告が指している対象と、MDS が今管理している対象の同一性を確認できない限り、その証言を再構築判断に使わせないことにある。

制御状態が消えても、data plane の結果は残る

pNFS flexible file layout では、MDS が配置情報を与え、クライアントは data server へ直接アクセスする。client-side mirroring では、すべての mirror を更新する責任がクライアントにある。したがって、一つの copy だけが WRITE を拒否した事実を最初に知るのもクライアントである。

RFC 8435 の ff_ioerr4 は device、operation、status、byte range と stateid を運ぶ。これは MDS にとって有力な hint だが、全データの integrity proof ではない。クライアントが観測した失敗の範囲を説明するものであり、観測しなかった silent corruption や application semantics までは証明しない。

MDS restart 後、旧 layout stateid は無効になる。一方、client は outage 中にも DS に直接書き込めた可能性がある。通常の authority は失効したが、その authority の下で生じた結果の記録は残っている。

RFC 9737 は grace 中に all-zero stateid を受け入れ、旧 layout を復活させずに report だけを recovery decision へ渡す。

anonymous stateid は対象同一性を省略しない

all-zero は「どの layout でもよい」という wildcard ではない。使えるのは recovery grace period の LAYOUTRETURN error path だけである。grace 中の別 stateid は NFS4ERR_GRACE、grace 後の zero は NFS4ERR_NO_GRACE になる。応答時に result stateid の seqid を進めてはならない。

さらに MDS は、returned layout が current mirror instances と一致するか調べる。一致しなければ report を ignore して file を resilver する。これは証言を疑う規則ではない。証言が現在の対象に結び付かないため、別の安全な経路を選ぶ規則である。

運用記録には client-side mirror-set fingerprint と MDS-side current fingerprint が必要だ。error accepted だけでは、message transport が成功したのか、decision input として採用されたのかを区別できない。

古い対象への真実は、新しい対象への権限ではない

この境界は storage 以外にも通じる。識別子が再利用されたり、component membership が変わったりすると、過去の正確な observation が別の構成に誤適用される危険がある。RFC 9737 はその事故を mirror set comparison で防ぐ。

たとえば device address が同じでも、再起動 epoch や layout membership が違えば同じ mirror set とは限らない。ログ収集側が device 名だけで join すると、旧障害を新構成へ貼り付ける可能性がある。

運用検証では、specification の field 名より実際の membership と時系列を優先する。どの client がどの set を見て、MDS がどの set を current とし、比較がどう終わったかを観測しなければならない。

report が無い理由も区別される

client が file を reclaim し error を報告しなければ、MDS は resilver してはならない。error report があれば resilver しなければならない。reclaim も report も無ければ、client が再起動して state を失った可能性があるため resilver しなければならない。

clean reclaim と silent client は同じ zero-error count を持ち得るが、意味は逆である。前者には recovery participation があり、後者には witness がいない。監視がこの差を消すと、absence of evidence を evidence of absence に変えてしまう。

ただし clean reclaim も万能ではない。client が error を観測しなかったことは、全 byte が正しいことや別 client の観測が無いことを保証しない。protocol decision と data validation は別の receipt である。

resilver の開始にも authority の順序がある

client が LAYOUTIOMODE4_RW を得ると write intent が生じる。MDS は restart をまたいで outstanding intent を追跡する。resilver が必要なら、file を fence し、必要性を記録し、write intent を release し、残りがゼロになってから copy を始める。intent が残る間は resilver してはならない。

copy 中に I/O を止めるか、MDS 経由にするか、proxy を挿入するかは implementation choice である。アクセスを続けるなら client が見る layout set は restart 前と同じでなければならず、proxy は grace の終了まで残る。

したがって accepted report は repair completion ではない。source mirror の可読性、copy range、convergence、post-read、application acceptance を別に確認する必要がある。

version mismatch は conservative cost を生む

新 client が anonymous stateid を送り、旧 MDS が extension を知らなければ NFS4ERR_BAD_STATEID を返す。client は旧 behavior に fallback し、この path で error を報告しない。

未知の報告を理解したふりはしない。その代わり MDS は evidence 不足を resilver の費用で埋める。これは安全側の互換性だが、RFC 9737 の成功ではない。fallback rate、追加 copy、recovery time を別に測るべきである。

all-zero stateid の価値は権限の大きさではなく、境界の小ささにある。expired layout を復活させず、正しい対象と正しい時間に限って一つの witness を聞く。その厳密さが、不要な copy と誤った trust の両方を減らす。

出典