テストステ論

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

(writeboost report) dmsetup tableの件について自分なりの考え

http://akiradeveloper.hatenadiary.com/entry/2013/11/27/200951

の続き.

http://www.redhat.com/archives/dm-devel/2013-November/msg00193.html

ジョーの言ってることは以下.

  • statusは完全に, 「今走ってるもの」を見せるべきだ.
  • そして, 「初めにロードされたもの」を見せるべきだ.
  • と思う.
  • 我々が直面している問題は, オリジナルテーブルがout of dataになってしまうことになり, その情報に依存しているユーザをミスリードしてしまうことにある.
  • ターゲットは一般に, 以下の「何もしない」シーケンスを満たすべきだろう(何を満たすべきかは書いてない)
  • tunablesをtable lineに入れることは, 当然, テーブルのout of dateに繋がる(初めにロードしたものが見えるはずなのにそうなっていないという意味)
  • (カーゴンが言ったもの以外の候補では) tunablesを(たぶんキャッシュの)メタデータに入れて, messageでのみ変化させるようにするものがありうる.
  • この方法の欠点は, その設定をするextra workがユーザランドに必要なこと(嘘だと思う. メタデータに格納されたtunablesを読み込んだカーネル側で設定すればいい). もしかしたら, ユーザランドメタデータと重複するかも知れないこと. あるいは, (キャッシュの)メタデータからその情報をqueryしないといけないこと.
  • この方法で行くべきだ.

うーん, 微妙だ.

この方法では, device-mapper-test-suiteでtunablesを設定した上でテストすることが出来なくなる. device-mapper-test-suiteでは, テーブルからデバイスを新規生成してテストする. 従って, table lineにtunablesを含み, かつ, .ctrでこれを処理出来るようにしなければならない. まずここを主張しなければならない.

カーゴンの言う, テーブル文字列によってreloadが必要かどうか判定するユーザランドプログラムがあるというのは理解出来る. デバイスについてequalityが定義されていないため, その代替としてテーブル文字列でのequalityに頼っているという論理である. この点については, (1) targetがtable_eqメソッドを実装する (2) そういうバカなことはやめていただくという実装があり得ると思うが, 私は後者が良いと思う. そういうバカなコードを全部排除する方が早い. 所詮はoptimizationである. ユーザランド諸君, 意味のない最適化はやめていただきたい.

私の案は, 少し手間であるが, それぞれのoptional argsについてオリジナルテーブルのロード段階で存在したかどうかをすべて記憶しておき, そのビットを元に現在の値を用いてテーブルを構築する. これはカーゴンの言う「uniqueなフォーマットを定義して, ユーザランドにもその順番を意識して入力していただく. それならば文字列比較が正しく動く」の「optionalなのだから全部指定する必要はない」バージョンである. 全部指定する場合は, 何がデフォルトの値なのかをユーザランドが知る必要が出てくる. これは明らかに過剰な結合である. 従って, 本当に入力されたものについてのみ出力すべきである.

さて, さらに「オリジナルテーブルの順番も保存する」とすれば完全である. これは, indexを保存しておけばいい. writeboostの初期化は, essential_args #opt_args opt_args #tunables tunables という順序である. indices_opt_argsとindices_tunablesをwb_deviceの中に組み込めば良い. だがこれは拡張である.

実装の順序としては,

  1. 全部入力を受け付ける(今の時点でOK)
  2. 全部出力する. unique ordering (実装必要あり). この時点でdevice-mapper-test-suiteに対して正しい挙動を確保出来る.
  3. 実際に入力されたものを覚えておき, これだけをunique orderingで出力する.
  4. さらに, opt_argsとtunablesについて, 入力された順序も覚えておく.

という考察の内容を英語でシンプルに表現することが骨だ... まぁ, やるしかないわけだが. 本当に苦しい. だが, 正しい設計についてちゃんと議論出来る人間であることを示し, 記録を残しておくことは自分のキャリアのためになると思うし, やる.