テストステ論

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

(writeboost report) マージへの希望 ある

この数日, レッドハッドのDM Guysと戦っていた. 顛末をまとめる.

スレッドは2つある.

最初のスレッドは, 現在lc-daemon(in Python)が担っているライトバック自動調整機能のカーネルデーモン化だ. 良い実装アイデアが分かったので, こうしたいんだけどという提案をしてみた(http://www.redhat.com/archives/dm-devel/2013-September/msg00066.html). しかしすぐさまジョーから, 「お前何言ってんだ?お前はlinux-nextに入れようとしているんだよな?それなのに設計を変更する?狂ってんのか?」的なコメントを拝受した. これに対しておれは, 「どの道設計を直すなら今だ. だから提案した. このタイミングでの提案という点に問題があるなら謝るが, 設計がダメなら直すしかない」という返答をした. それからなぜか, ユーザ獲得作戦は進んでいるのか?という別方向の議論になってしまったので以下省略する.

次のスレッドの方がより重要だ. それからしばらくして, マイクから, 9/1におれが投稿したstaging提案についてリプライを拝受した(http://www.redhat.com/archives/dm-devel/2013-September/msg00075.html). 要点は, 「この設計はダメだ. なぜダメなのかは分からないがダメだ. DMの標準に従わないといけない. とりあえず, stagingは諦めろ」ということである. その根拠は, 「sysfsが臭い. こんなsysfsを持っているやつは他におらん」「writeboost-mgrが臭い」「デバッグ用のコードがあってプロダクションレディじゃない」あたりである.

おれは一日中悩んだ. 明らかにここが正念場である. 明らかにネガティブな返事であり, stagingへの道は完全に絶たれたと見てよい. DMのツリーにマージされることが目的なのだから, 自分を貫いて打破したとしても, おれの設計が神の目から見て正しいとしても, その先にマージは絶対にない. 従って, もしマージを狙うのであれば, 出来るだけダメージの少ない譲歩をして設計を相手の望みどおりに行う提案を, 論理的に展開する必要がある. おれは論理的な議論が得意だが, さすがにこれは骨だった. 帰りのバスの中で構成を練って, 帰宅してから一気に書いた.

おれのレスが以下の2通.

  1. http://www.redhat.com/archives/dm-devel/2013-September/msg00078.html
  2. http://www.redhat.com/archives/dm-devel/2013-September/msg00079.html

英語が読めないみなさんのために解説しよう.

1つ目の要点は, 「設計が悪いことは分かったし自分も感じていた. こうすれば設計を改善出来る(dm-cacheに近づける), 直してからカムバックする」である. 設計が悪い原因は, キャッシュ共有であると思う. この設計判断は悩んだ末だから後悔はしていない. しかし, 結果として, writeboostはdevice-mapperにフィットするためには幾分自己主張的になってしまったように思う. それが, レッドハットのGuysにはSmellとして感じられたのだろうと思う.
自分の主張を始める前に, 議論のポイントをしっかり理解していることを, 聞き手への尊敬とともに示すことは有力である. この目的に私は, Smellへの理解を示した. Smellへの嗅覚は, 一流の開発者しか持ち得ない. 私も, この嗅覚を共有出来る人間と一緒に働きたいと思う. 彼らもだろうと推察する. 私が嗅覚への理解を示すことで, writeboostへの期待も示すことが出来る. もちろんこれは単なるテクニックではない. 実際にwriteboostの設計にSmellを感じていた. それがadd_sysfsやremove_sysfsといったmessageであり, メール中に示してある. なぜこうなってしまったのだろうか. この設計はおかしいのではないかと悩みつつも, その中でもっともシンプルな解を探していったものが, 現在のwriteboostである. 従って, レッドハットのGuysに否定されはしたものの, 私には恥じる点が何もない. むしろ誇りである. 世界中どこの誰も, 今のwriteboostを開発することは出来ないと思う.
最後に, 設計の単純化をすることによるメリットに関する考察を述べた. シンプルさの追求もまた, 開発者の好むところであると思う. 実際に, キャッシュ共有を止めることで設計をdm-cacheに近づけることが可能なことが, 私には分かる. たぶんマイクにも, 直感的に分かる. 実際に彼は, キャッシュ共有を切ることが良さそうなディレクションだというアドバイスをしてくれた. 文章を読んではい分かったという人間ではないように思う.

2つ目は, キャッシュメタデータのフォーマッティングに関する設計案の提示である. 設計が二通り浮かんだので, どちらが良いだろうかと聞くと, 良くわからんマクロを使うのだという回答だった. 完全に糞だと思うが, 受け入れて大損というものでもない. ただし, ポータビリティがないのが鬱陶しい.

上記2通のメールへ, 次の朝, マイクからの返答があった(http://www.redhat.com/archives/dm-devel/2013-September/msg00080.html, http://www.redhat.com/archives/dm-devel/2013-September/msg00082.html).

要点は以下である.

  • 設計の変更には同意する. あなたのやる気も評価する.
  • stagingはwriteboostにとって必要とは思わない. 設計がまともになり, 明らかなベネフィットがあるならば, たくさんのユーザを獲得することは必要ではない, DMツリーへのマージを達成するために.
  • 設計のシンプル化は良いアイデアだ. キャッシュ共有をやめることは良さそうに感じる. さらにいうと, キャッシュ共有は, writeboostデバイスの上でlinearを切るで達成出来る(これは本当の意味では嘘であるが, 近似的には正しい. ストレージ出身なので分かる. 反論しても良いが, 本質的ではない).
  • LVM2での管理も考えよう. dm-cacheにインターフェイスを似せることは, この可能性を高める.
    • この発想はなかった. 設計を妥協することで損をすることは覚悟したが, 思わぬところから得になりそうである. LVM2で管理出来ることは, とてつもなく素晴らしいことだ. writeboostはすごい成果になるかも知れない.
  • すべてのアロケーションは.ctr以下で行われるべきだ(これは前にも言われた. たぶん, LVM2などのツールとの兼ね合いだと思われる).
  • log構造化に関する部分はfactor out出来ない?bio-prisonやpersistent-dataは利用出来ないかな?明らかに, new space mapは必要だ.
    • 何言ってるのか分からないし, たぶんやらない方がいいしあまりやりたくない. マージしてくれるなら, それから考えてもいいという程度.
  • log-structured cachingはdm-cacheとは違うと思うので, 明日, 詳細にレビューする.

この戦いは, おれの良いように終結したと思う. 良い線で妥協して, 思わぬ収穫も得た. マイクも, writeboostのマージに向けてかなり友好的になってくれた印象がある. writeboostに興味が出てきた?writeboostは3.13でのDMツリーへのマージを狙う.

コミュニティで戦うためにもっとも必要なものは, もちろん開発のスキルであり, これがないやつは全くダメだが, それとほぼ同等に, 論理的な議論を英語で行う技術が求められる. これは簡単ではない. 英語が話せればいいだろうか?日本語を話せる人でも論理的にものを読み書き出来るかは別問題だ. では大学院を出れば良いのだろうか?クソみたいな院卒は山ほどいる. 自分の言いたいことを必要なことだけリーンに主張することが出来たのだろう, それがこの結果につながった. コミュニティで戦うことは辛いこともある. しかし, 自分がまともな技術者なのだと示せれば, 彼らは必ず仲間になってくれる. コミュニティは素晴らしい. Linuxカーネルに突っ込んでいく日本人はあまり多くない. もっと攻めてほしい. コミュニティでの戦いがなければ, おれは生きがいを失ってしまっていると思う. 戦ってみなければ分からないことは多くあるように思う. そして何より, 戦ってもいないやつには何に対しても口出しする権利はない.