テストステ論

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

(writeboost report) リリース前にType1 Persistent Logggingを棄てる

良いソフトウェアの作り方として, まず機能や性能などをとことんやってみた上で削るという方法がある. とことんやってみると, そのソフトウェアのあるべき姿が浮かび上がってくる. 最後に, 余分なものを削るとシャープで良いものになる. ちょうど, ボディビルダーがコンテストに向けて, まずは筋肉も脂肪もつけてバルクアップして, その後に一気に脂肪を落とすのと同じだ. プロトタイピングというのはバルクアップである.

決定: ライトブーストは, v1.0へのマイルストーンとして, Type1を棄てる

これは, カーネルコードのみならず, テストコードにも影響する. たぶん, 合計で2000行近い修正となるはずである. かなり骨のいる作業になる. 間違いなく, 一日作業になるだろう.

Type1とは何だろうか?ライトブーストはType0とType1がある. これはデバイスの初期化引数typeによって分岐出来る. Type1の時は, 通常のHDD, SSDの他にもう1つ, plog device(plog: Persistent Logging)というものを与えなければいけない. 一体これは何なのか.

ライトブーストのPersistent Loggingは, ライトブーストがフラッシュ命令に対して持つオーバーヘッドの大きさを解決するために実装された. ライトブーストは, フラッシュ命令に対してAckする前に, 自らが持つRAMバッファのデータをSSDに対して永続化する必要がある. フラッシュ命令が細かく出されると, それだけオーバーヘッドは目立ってくる. そこで, ライト情報の全情報をplog device上にロギングしておき, フラッシュ命令に対しては, plog device上で永続化するだけに省略出来るようにする. これによって, オーバーヘッドを軽減出来るという理屈である.

リリース前にこの拡張を除去する. 理由は以下である.

  • 仮に現象レベルでバグを報告されても, デバグ出来る自信がない.
  • dbenchにおいて, Type1が優位になる場合があるが, 他の場合においては悪くなったりする. データを冗長に書くためである.
  • ドキュメントが複雑になってしまっている. "Type1とは一体何なのだ?"ということを聞かれることが多い. うんざりしてきた.
  • リードキャッシングを実装した今, dbenchなどの実に近いワークロードで, Type0のみでもかなりの性能ゲインがある.
  • 現実的には, フラッシュ命令はそこまで多くない.
  • dm-thinやdm-cacheも, フラッシュ命令が来た時に同様の問題を抱えており, 彼らの解決策は遅延である. ライトブーストは同等の実装をしており, 同等ならばそれ以上求めるのは欲張り.
  • Type1を使うユーザはたぶんいないと思う. 研究者や我々開発者の中では, SSDキャッシングは当然のものとなっているが, 運用の人たちはまだまだ懐疑的だ. デバイスを2つ追加することにコストや信頼性の点で嫌気すると思う.
  • リードキャッシングとType1の相性が悪いかも知れない. はっきり言ってもう頭脳がついていかず, 読みきれない. だから棄てるしかない.
  • Type1を棄てることによって, Type0の実装を特化することが出来る可能性が高い.
  • plog deviceは, 未来のデバイス向けのアダプタを書くという楽しみがあるのだが, 手に入らないデバイス向けに当てずっぽうでコードを書くのは虚しい.

はっきり言って, 実装はかなり難しかったので棄てるのは惜しいのだが, 棄てないとリリース後に憂いを残しすぎるように思うので, 棄てる決断をした.