テストステ論

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

(writeboost report) Githubレポジトリをどうするか

現在, writeboostはGithubにて開発されている. developブランチがRedHatの開発者と共有され, レビューを受けている. 他にも, このブランチを落として使ってくれている技術者が世界に何人かはいる(少ない. しかし各々には感謝する. 特に韓国人の彼はバグを発見して貢献してくれた. どこかで聞いたが, 楽天がLeoFSやRomeをOSS化したが, 外部からの興味を集めることは出来なかったという経緯を聞くと, 数人だが利用者が現れていることは多大な成果と見ることが出来る. しかし繰り返す. 少ない. 私が望むのは数千数万というオーダの利用者だ).

ソースコードの, コミュニティ密着度があるとして, writeboostの開発形態はこの度数昇順に以下のように記述出来る.

  1. 現在の形. コードにはバージョン切り替えマクロが散りばめられており, drivers/md以下の機能は使っていない. グローバルに公開されている機能のみを使って実装されている.
  2. バージョン切り替えマクロを廃止して, アップストリームでしかコンパイル出来なくする.
  3. drivers/md以下に置き, headerなどに依存する(理論的にはこの時点で2を行使しないことが可能であるがしかし, 無意味である).

将来的には3に辿り着くべきであるが, マージが決まっていない段階でいきなり3に挑むのは私としては譲歩しづらい. しかし, 1のままは問題である. 従って, 最初のマージまでは2によって突き進もうと思う.

バージョン切り替えマクロによって複数バージョンでコンパイル出来るカーネルをGithubに用意することに何の意味があろうか?現実的には皆無であろうと思う. なぜメインツリーに入れたいのであろうか?ソフトウェアの精度を高め, ユーザを増やしたいからである. ストレージカーネルのように極めてセンシティブなソフトウェアでは, 研究レベルでお試しするならばいざしらず, 実際に運用するためには, 厳しいテストを経た上でディストリビューションに入ることが不可欠である. そのような事情を考えると, さて, 仮にwriteboostがマージされたとして, それを元にしたバックポートを私が提供することに何の意味があろうか?もはや, 「使いたいなら新しいカーネルにアップデートしなさい」で済ませた方が早い. 従って, 意味はない. writeboostを運用してもらうというのは, 遊びではない. データロストの可能性があるソフトウェア(しかも動作原理を完全に理解しているのが私しかいない)なんか, お墨付きでもなければ使う気が起きない. writeboostは全く新しい機能なのである. 一般的に, 性能が高いものは怪しいと思うものであろう. 何か重要なことを放棄していると思うものである. しかし彼は考えを改めなければならない. writeboostは完全である.

従って, 現在とるべき最善手は, バージョン間ポータビリティを完全に捨てて, 3.12に向けて完全に最適化していくことである. メインツリーに入ってavailableとなっていない実装をツリー内で開発することは, テストしてくれる人の負荷を増やすことになるから, とりあえずは2の段階に留めて開発し, 本当に文句を言われるようであればしぶしぶ3にするのが良いだろう. その時点では修正する箇所は現実的にそれほど多くないから大した問題ではない. 大体, そう言ってくるということはマージを前提とした議論に進んでいるということである(もともと, md以下のパーツを使ったらどうだろうかという提案はされているが, マストな表現ではないしdeclineした). 現状のコードにすら正式なレビューが入ってるくらいだから, 基本的な構成として否定されているものではないと思う.

現状を考えれば, マージされる方向に進むものと思う. なので, マージされたあとを考えよう. その時点で私は, GIthubからドライバのコードを排除し, dm-writeboost.txtなどのドキュメントも排除する. メインツリーに取り込まれたものを持っている意味はない. その代わり, テストコードやドキュメントを充実させて, 開発者が参加しやすいようにする. メインツリーに取り込まれた時点で, 今とは比較にならないattentionを集めることになり, それはpotentialな参画者の存在を意味する. メインツリーの先端に興味がある一流技術者たちがwriteboostについて議論を始める光景を思い浮かべるとワクワクする. 私個人は多大なRespectを集めることだろう. その時のために立派な髭を生やしてハッカーヅラしよう. 幸い私は, ハッカーらしい髭が生える. 日本人では珍しいだろう. writeboostシャツも作ろう. 海外では, 自己主張は尊重される.

マージされた暁にはLinuxConなどの場で発表することは当然したい(会社はサポートしないだろうから, 自費でいく. 借金してでも行く. あるいは寄付を募る)し, 出来れば, 研究としての一面を見出して綿密な計測を行った上で論文投稿も行いたい(こちらも会社のサポートが得られないので, 大学や企業などからレンタル出来ればよい. 個人的には, 弊社と敵対する企業と手を組んで研究成果を出すのが最善であると考える. 「永続メモリによるログ構造化キャッシングソフトウェアの最適化」という方向性で実装評価を行う. 参考文献は, MSRのものなどがあり, 関連研究も書くことが出来る). 正式なドキュメントを残すことはとても重要だ. 文章を読んで理解することは多大な労力を要する. 従って, それは公的に認められているとなお良い.

この記事では, マージに向けた・マージ後の戦略について述べた. これだけ面白いソフトウェアをスクラッチ開発して, 提案して, マージされて, そこからさらに育てる, ディストリビューションにも取り込まれて世界中で使われる. writeboostは一生の思い出に残るソフトウェアとなる. しかしこれが私のすべてではない. 私の気持ちはすでに次に動き始めている. マージを急ぐのは, 興味がぷつんと消えてしまいそうだからでもある.