テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(writeboost report) 閉塞処理を実装した

閉塞処理についてしばらく揉めていた.

閉塞処理の結果が満たす自明な条件は少なくとも,

  1. 入力されたリクエストについてすべてエラーを返すこと
  2. すでに受理したリクエストについてはすべて返却すること
  3. タイミングに依存したデッドロックを起こさないこと
  4. 閉塞後, dmsetup removeによってメモリを正しく解放出来ること
  5. 閉塞後, suspend/resumeを受け付けること. これもタイミングに依らないこと

である. 閉塞後, suspend後に, (1) 内包するデバイスに対するI/Oを一切起こさないか, (2) デーモンが完全に寝てCPUを消費しないか と言った些細な要件があり得るかも知れないが, いずれも少なくともライトブーストでは不可能である. 閉塞した「瞬間」に実行アドレスを突然変更することは危険極まりない. その後の実行におけるバグを生むだろう. この点についてライトブーストは基本的にやらないが, 論理的に誤りとならない場合には(同期的にではないが)やるということにした. 具体的には, flush deamonとmigrate daemonは止めてはならないが, 他は止めても良い. しかし, あるデーモンは止めてあるデーモンは止めないなどという汚い法則は受け入れがたいから, いずれも動かすことにする可能性が高い.

閉塞に関する基本的な原理は, シンプルである.

  1. いずれかのデバイスでエラーが起こると, WB_DEADがset_bitされる. SSDに対して, HDDに対して, R/Wのいずれかで言った分岐で閉塞処理を分岐するのは間違いなくペイしない. 従って, どのデバイスからエラーが出ようが問答無用で閉塞することにした. きわどい状況下においてまだ粘ることは, 危険すぎる.
  2. 内包するデバイスに対するI/Oは完全に無視される. /dev/nullを利用しているのと等価となる(美しい!!!)
  3. メモリ上の操作は続行する. メモリ上のデータ構造が不整合を起こすことはない. ただ, 「ストレージに書き込んでいない」という点のみが通常と異なる. これにより, 思わぬデッドロックなどを完全に除外出来る.
  4. ただし, これでもつじつま合わせは必要であり, 上記bitのon/offによっていくらかのコードを切り替える. 例えば, デバイスのコールバックによってカウントをデクリメントするなどのコードが実行されることは期待出来ないため, これは強制的につじつまを合わせる. 他には, 閉塞時には入力されたリクエストにエラーを返す必要があるから, これも切り替える. flush procにおいて遅延されたwrite barrierもエラーとして返す.

現状では他にも, .mapのreturn前のbio_endioでEIOを返すべきかも知れない. 特に, バッファが永続メモリになった場合に問題となりそうである (これが不揮発性であれば何の問題もない. どの道上位には永続化されたことが保証されない).

さらに行うべき検討は,

  1. バッファが永続的になった場合. さらに, 永続メモリが実は書き込み失敗があり得る場合はどうだろうかなども問題となるが, シンプルな原理によって閉塞を制御しているので, たぶん対応出来るだろうと思う.
  2. キャッシュ上で永続化を約束したものが, デバイスにnullライトバックされたあとに上書きされて消滅する可能性がある. さてどうしようかは検討中であるが, 直感的には, 原理が美しいので何かうまい方法がありそうである. foregroundではただエラーを返せばいいので制約は緩い. (デバイスの状態は凍結されるんだから, 問題ないのか?)

閉塞処理については, イギリスに行く時からずっと考えていた. そしてようやく, それっぽい解が出た. ライトブーストのコードはシンプルであるが, 動作原理は結構きわどい. また, ライトバックキャッシュであるため, 動作の一切の誤りは間違いなく許されない. それ故に, 厳しく精査されることになる. 従って, シンプルな原理とコードによって明らかに正しい閉塞処理をコミュニティに提供しなければ, 理解はされないし結局誤ってることが指摘されるしという苦しみに合うことになる. だから, 検討に長い時間をかけてもっともシンプルなものを探すことはペイしやすい. 今日はその結果がとりあえず出たのでとても嬉しい.

(追記)
TODO

  • この閉塞処理についてドキュメントでまとめる必要がある. メモリの永続化とその開発プランについても同様.
  • ドキュメントの不整合がひどい. PDFを早急に修正したい. コメントも微妙だ. 1回クリーンにする時期かも. ダメージがひどい.
  • dm-develに対して進捗報告を書く必要がある.
  • リポジトリのTODOを修正する必要がある. あれは迷惑