読者です 読者をやめる 読者になる 読者になる

テストステ論

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

金魚釣りはやめろ

最近, おぞましい遊びを知った. 金魚釣りという.

堀の中で泳いでいる飼いならされた金魚を, ゴミみたいな餌で釣って楽しむという遊びらしいのだが, 吐き気がする.

現実社会には, 金魚がたくさんいる.

金魚は, 金魚に生まれたかったわけではない. きれいな鯉に生まれて, 豪邸の庭にある池の中を優雅に泳いで, 死んだ時にはちゃんと埋葬される人生を望んでいたはずだが, 願い叶わず金魚になり, 生きるためにゴミみたいな餌を期待して堀の中を泳いでいる.

現実社会も同じだ. 本当はもっとお金持ちの家に生まれたかった. もっと教育を受けたかった. そしたらもっといい大学に行って, きっと今とは違う暮らしをしていたに違いない. 堀の中から逃げ出すことは出来ず, 安っぽい餌を口をぱくぱくしながら待つだけの日々.

近鉄の駅員が線路に逃げ出したというニュースがあった. どうか罰しないでほしい. これが罰せられたらこの世界は終わりだ. あの人だって, 近鉄の駅員になりたくてなったわけじゃないはずだ. 毎日毎日酔っぱらいや民度の低い「お客様」に絡まれて, そりゃ嫌にだってなる. だけど駅員を辞めるわけにはいかない. 他に行くところがないからだ. そこで必死に生きていくしかない. きっと, 養わないといけない家族だっている.

昔, 笑う犬というお笑い番組でテリードリーというコントがあって, お兄ちゃんのドリーが「毎日毎日同じことの繰り返しで生きてる気がしないんだよ!」という下りから始まるのだが, 駅員だって同じ. 毎日毎日ゴミみたいなお客様の相手をしなきゃいけなくて, うんざりしてる. もう嫌だ死にたいと言ったという.


笑う犬 テリーとドリー 生きる

逃げることが出来ない人をひたすら虐めるのはやめよう. 昨今問題となっている下請けいじめもそうだ. 下請けの人だって, 好きでその仕事をしているわけじゃあない. かといってスキルはないから現状から這い出ることも出来ない. ほとんどの人がそうだ. 最近ではスーパーやコンビニの店員に土下座させる客まで出てきているという. ブラック企業と呼ばれるところでは, 社員が鬱になって自殺することだってある. みんな, 金魚なんだ.

金魚釣りは, この世界の縮図だ.

金魚釣りに行く人は, 現実社会では金魚をしているから, せめて休日くらいは, 金魚を釣る側になってみたいと考えて金魚釣りに行くのだと思う. 私は, その気持ち自体は別に悪いものだとは思わないが, 自分はそうはなりたくないと思う. 苦しい現状を受け入れて必死に生きている人を虐める連鎖に関わってしまったら, 人として終わりだ.

もう「お客様は神様」はやめよう.

最近, こんな記事を読んだ.

「お前は客じゃない!」外資系企業の支配人がクレーマーを一喝 「お客様は神様」ではスタッフを守れない

この外国人上司にとって客の定義とは, 客として正しく振る舞う人だけであり, それ以外は客とはみなさないということだ. 一方で日本人にとって客の定義は, そのサービスを利用する人すべてだから近鉄駅員のようなおかしなことが起こるのだ. 日本社会というのは, サービスを提供する側はなんでもやるということが要求されるおかしな社会だ. それは, ジョブディスクリプションが存在しない雇用文化にも表れている. 雇用される側は常に, 何でもやることを求められる. 「それはおれの仕事じゃない」は許されない社会だ. だから, 酔っぱらいのサンドバックになることも仕事だし, ちんぽを舐めろと言われたら舐めるしかない.

みんなが今から一秒後に一斉に外国型のサービス精神に切り替えれば, 日本社会は一気に浄化される.

スカイマークは, 日本企業の中ではいち早く, 外国型のサービス精神に切り替えた企業だ. スカイマークのサービスコンセプトが言っていることは「私たちは, 客がまともであることを前提として, 安全なフライトを提供する」ということだ. だから, キチガイは外に放り出すと書いてあるし, 安全なフライトに必要のない制服だとか上品な言葉遣いはやめると言っている. 客の中で赤ちゃんが泣きわめいて迷惑をかけても, そんなことは知らんと言っている.

スカイマーク・サービスコンセプト〜無神経とも思える傲慢な文章表現は、おそらくしたたかに計算されたもの

それでいい. そうすることによって, 客の質は上がる. そして, それが結果として, 全員にとってフライトを快適にするのだ. だから, ここからここまでしかしませんと明確にすることは, 実はサービスを受ける側にもメリットがあることなのだ. 実際私はスカイマークのそのドライさが好きだ. イギリスに行った時にヒースローからエジンバラまで国内線に乗ったが, フライトアテンダントは服がズボンからはみ出ていた. 服なんか関係ないからだ. 離陸時に衝撃で荷物入れが開いてしまったのだが, その時も飛行機が安定するまではそれを閉めには行かなかった. 荷物入れをちゃんと閉めなかったのは客の責任であり, 離陸時に立つことは自分の身の安全を脅かすからだ. 彼らは楽しそうにフライトアテンダントをしていた.

人の能力に差があることはしょうがないことだが, みんなが自分の仕事に誇りを持って楽しんで働ける社会になればいいなと思う.

使ってはならない3つの危険な日本語

誤解を恐れずいうと

いや, 誤解は恐れてくれ. 言いたいことを正確に伝える努力を放棄しないでくれ.

もし, 自分の理解が間違ってるかもしれないけど, と言いたいならそのように言ってくれ. もしくは何も言わないでくれ.

この言葉は, 文系の人が好んで使う. 文系の有名人に, 誤解を恐れない人がいるのだろうか. 文系の中には, 誤解を恐れずに主張することがかっこいいと勘違いしている人が結構な数いるように感じている.

おれはこの言葉を聞く度に, この人は何を言ってるのだろうかと悩んでしまう. 余計なことは言わず主張だけすればいい.

そもそも, 人間のコミュニケーションの中で誤解が起こるのは当然であるから, そもそもこんな言葉は必要ない. 使用禁止すべき.

こんなこと本当は言いたくないけど

じゃあ言うな.

マウンティングである. 本当は言いたくないけど, あなたのためを思って言ってあげるというニュアンスを含む. 余計なおせっかいだから言わなくていい.

この言葉を使う人間は危険なので, 絶対に関わりたくない. 職場にいたら速攻で辞めるレベル.

要は

本当に要ってる場合は1%に満たない. ほとんどの場合は, 話してる当人が話すことがまとまらないままに話しているため, 当人の息継ぎのような形で使われている.

考えをまとめてから話せない人だと思われるのが嫌なら使わない方がいい. それに, 要があるならばはじめに言えばいい.

「筋トレは最強のソリューションである」を読んだ

私がテストステロンという概念に出会ったのが, 京都大学に入ったばかりの頃. 20やそこらの頃だった. 当時, 京大バーベル部はテストステロンにこだわる文化があり, 私はそこでテストステロンを学んだ. 運動をしないやつは人間のクズだという考えは麻布高校時代から持っていたが, テストステロンという概念にたどり着いていたわけではないから, やはり京都大学入学後が正しい.

この世界のあらゆる人間的な事象を説明出来る可能性をテストステロンに感じ取った私は, それを一般レイヤーに布教することを考えた. その結果, 私の周りではテストステロンの重要性を理解する人が増え, 冗談ではあるが京都大学にテストステ論が開講されていることとなった.

kyoko-np.net

議会政治に詳しい京都大学政治学部の坂本義太夫教授(テストステ論)は「物事を決める根拠が多数決から戦闘力、すなわち「数の力」から「力の数」に変化してきたのだろう。近い将来女性議員のいない「ガチムチ国会」が常態化するのではないか」と話す。

このブログの名前がテストステ論であることも, 私がテストステロンを, 同じく論のつく素粒子だとか整数だとかそういった世界の根源を為すものと同等であると考えているからである. このブログを通じて, 多くの人がテストステロンという言葉を知ったと思う.

テストステロンの高低によって, 人間の人生は決定すると言っても過言ではない. これは低テスの人にとっては不愉快な事実かもしれないが, 厳然たる事実である. 事実だと感じ取っているからこそ, これほどにテストステロンは受け入れはじめているのだ.

teststerone(@badassceo)氏は, 私とは別のルートでテストステロンを学び, 布教しようとしている. 本を読んでいて, パラレルワールドの自分を見ているかのようだった. 別のルートを通ったとしても, ある1つのものにたどり着けるということは, テストステロンがこの世の真理であることの証左である. 

彼はアメリカ留学中に筋トレの重要性に気づいた. そして自身でもビッグスリーを中心に筋トレをすることによって人生が好転することに気づき, それを広めようと思った. ただ若干おふざけが入っていて, 彼女が出来なくてもバーベルが恋人だから問題ないとか, それはテストステロンの本質ではない. 悪ふざけはやめてほしい. おれは彼女がほしい.

ただ, 高テスマインドやテストステロンをTwitterや本という媒体を使って本格的に広めた功績は評価出来る. だけど1つだけ言いたいことがある.

テストステロンについて語りたいならおれのところに挨拶しに来い. 木場に来い (@badassceo風)

SSDキャッシュの歴史

私は2012年頃からdm-writeboostを開発しているわけだが, 私がdm-writeboostを開発しはじめてから新しくSSDキャッシュは開発されていない. 少なくともOSSでは. 一応, Oh Yongseokという韓国人の学生がdm-writeboostを元にしてdm-srcという研究プロジェクトをやったが(https://ysoh.files.wordpress.com/2009/05/dm-src-ibm.pdf), それはプロトタイプのレベルでありプロダクションで使うレベルには至らなかった.

私がdm-writeboostを開発しはじめたころはちょうど, RHのdm-cacheがアップストリームに現れた頃であり, その頃にはbcacheはすでに入っていた. 今, アップストリームに入っているのはbcacheとdm-cacheの2つだが, bcacheが3.9, dm-cacheが3.10にマージされた.

他すべてのSSDキャッシングがdevice-mapperの上に作られているが, bcacheはblockレイヤにごりごり手を入れて作ってある. 故に良いこともあるのだが, コードはむちゃくちゃ複雑になっている. 開発者のKent Overstreetは当時グーグルの社員だったが, 今はやめてDateraというストレージ会社で働いている.

device-mapperというフレームワーク自体はかなり昔からあったが, もともとあったmd(multi device)の改良を狙っていたため, もともとあったターゲットを移植するということだけが行われていた. SSDキャッシュという概念自体がここ10年で出始めたものなので, 当初はSSDキャッシュは存在しなかった.

一番はじめにSSDキャッシュを作ったのは, Eric Van Hensbergenという人とMing Zhaoである. 彼らのプロトタイプはdm-cacheという名前がつけられた.

Another dm-cache project with similar goals was announced by Eric Van Hensbergen and Ming Zhao in 2006, as the result of an internship work at IBM.[8] Later, Joe Thornber, Heinz Mauelshagen and Mike Snitzer provided their own implementation of the concept, which resulted in the inclusion of dm-cache into the Linux kernel. dm-cache was merged into the Linux kernel mainline in kernel version 3.9, which was released on April 28, 2013.

(https://en.wikipedia.org/wiki/Dm-cache)

Eric(https://www.linkedin.com/in/ericvh)は当時, IBMリサーチで働いており, Ming Zhao(https://www.linkedin.com/in/mzhao)はフロリダ大学の学生であり, インターンに来ていた. dm-cache(https://github.com/mingzhao/dm-cache)はインターンでの成果物ということになる. はっきり言ってコードは対したことないし研究プロトタイプの域を出ないが, こういうものをインターンの課題として作らせるのが本物のインターンであり, 日給1000円のインターンとは一体何なのか. Ming Zhaoはそのままアカデミックの道を進み, 今はアリゾナ州立大学で准教授をしている. Ericの方はARMで働いているようである.

このプロトタイプに触発されて, 当時Facebookで働いていたMohan Srinivasan(https://www.linkedin.com/in/mohan-srinivasan-42835066)らはflashcache(https://github.com/facebookarchive/flashcache)を開発した. これはアルゴリズムはナイーブだが, きちんと作り込まれたソフトウェアであり, Facebookの開発者が作っているということもあり, かなり流行った. しかし今は"This project is not actively maintained. Proceed at your own risk!"ということで全くメンテされていない. Mohanは今年になってグーグルに移ったため, もはやflashcacheは棄てられたと言ってよい.

このflashcacheをさらに改良するため, STECというSSDを作っている会社でEnhanceIO(https://github.com/stec-inc/EnhanceIO)は作られた. このソフトウェアはflashcacheの改良版というだけあり, かなりいいものであったが, HGSTがSTECを買収したタイミングでディスコンとなった(https://www.hgst.com/company/media-room/press-releases/western-digital-completes-acquisition-of-stec-inc). しかし人気は根強く, なんとかしてコミュニティでEnhanceIOをメンテし続けようという試みがなされはじめてはいるが, ほぼほぼ失敗している.

おそらくEnhanceIOと同時期くらいにbcacheとdm-cacheが登場し, アップストリームにマージされたと記憶している. もともとflashcacheやEnhanceIOがあったにも関わらず後発で開発されたdm-cacheは, おそらく上からの至上命令で作ったためかなり急ごしらえ感のあるソフトウェアであり, マージされた当初はバグだらけであった. DM自体がRHが管理しているものだから, ゴリ押ししてそこで開発しようという魂胆だったが, 無難に作ろうとしたためかアルゴリズムが平凡であり, 性能は悪い. おまけにライトバックキャッシュですらないということもちらほら聞く. コードを読めば, 面白くないものだということはわかるから使ったことすらない.

その後, dm-writeboostが作り始められることになる.

dm-writeboostは, 他のソフトウェアが基本的には平凡なN-way set associative cachingをベースにしているに対して, ログ構造化キャッシングというアルゴリズムを元に作りはじめられた研究色の強いソフトウェアである.

もともとのアイデアは, DCD(http://www.ele.uri.edu/research/hpcl/DCD/DCD.html)という, ログ構造化ファイルシステムのブロックキャッシュ版を作ろうというアイデアで研究されたものがあり, これを参考にした. DCD自体は, 大昔の研究というだけであり基本的なアイデアしか記されておらず, 書いてある通りに作ったら実用性はほぼないというものであるが, その基本的なアイデアをベースにして, 効率的なライトバックの仕組みや, スレッショルドつきのリードキャッシングなどを実装したものがdm-writeboostということになる.

dm-writeboostはログ構造化キャッシングというアルゴリズムがうけて, Phoronixなどにも紹介されることになる. (http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Mjg)

その後, アップストリーム入りの提案が何度も撥ねられて希望がなくなった頃, もともとEnhanceIOのパッケージメンテナをしていたDmitry Smirnovの目に止まり, out-of-treeカーネルモジュールとしてメンテナンスしながらDebianを中心にディストリビューションにパッケージングしていくという方向に進むことになる. ただし, アップストリーム入りの提案自体は決して無駄だったわけではなく, RH開発者によるコードレビューも受けれたし, dm-cacheの開発者のJoeにはdm-writeboostを改良してアップストリーム入りを果たせるようにかなり協力してもらった.

このように, SSDキャッシュには, 色々な人が「おれの考える最強のSSDキャッシュ」を作ってきた歴史がある. もちろんNetAppやEMCのようなストレージベンダーは彼ら独自のSSDキャッシュを作っているし, IntelのSmart Responce Technologyなども存在する. dm-writeboostはそれらの中の1つにすぎないがログ構造化というユニークなアルゴリズム(注: NetAppの研究論文には彼らがログ構造化リードキャッシングを実装していることが示されていたりするが, ライトキャッシュを実装したものはみたことがない)を武器にして, まぁまぁの存在感を示せるようになってきた.

私はdm-writeboost v2.2.6にはかなりの自信がある. 今後dm-writeboostを試すユーザは全員が最高のソフトウェアだと感動するだろうし, 全員がプロダクションユーザになる. そうなった時どうなるかというと全くわからないが, 今までもそうしてきたように, その時最善だと思う判断をしていくだけである. ユーザが増えれば, アップストリーム化を望む声も出てくるはずなので, そうなったらまた挑戦してみると思う.

(writeboost report) おれは蚊帳の外だ

1) [dm-devel] To add, or not to add, a bio REQ_ROTATIONAL flag

Eric Wheelerが, SSDキャッシュソフトウェアに対して「このデータはキャッシュしてほしい/ほしくない」を渡す方法でどういうの考えられるかな?という議題を出した時,

With the many SSD caching layers being developed (bcache, dm-cache, 
dm-writeboost, etc), how could we flag a bio from userspace to indicate 
whether the bio is preferred to hit spinning disks instead of an SSD?

明らかにdm-writeboostが触れられているが, おれへのccはなかった.

2) #838547 - dm-writeboost: module fails to compile with kernel 4.8 - Debian Bug report logs

Ubuntuは2.2.3以降, 新しいバージョンに追従していないのだが, 4.8カーネル対応をする時にupstream maintainerのおれには一切報告なしに勝手にやったらしい. 4.8対応は, 2.2.6にもっといい形で入っている. また, 2.2.3以降にはリードキャッシュのfixなど重要なfixが入ってしまったため, 早急に2.2.6にupdateしてくれということをレスした. 2.2.6はまじで自信がある. 絶対に追従してほしい.

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=838547;filename=dm-writeboost_2.2.3-1ubuntu1.debdiff;msg=5


どちらも, upstream maintainerのおれには一切知らされていなかった.

SSDキャッシュソフトウェアの文脈で, メインツリーに入ってるbcache, dm-cacheの次にout-of-treeのdm-writeboostが出てきたことは喜ばしいことだ. LinuxCon Europeに行った時にdm-writeboostの開発者ですと挨拶しておいたのが良かったのかも知れない. 彼がRHで今も働いているかは知らないのだが, そうだとするとRHのコンセンサスと言っても過言ではない.

StefanBader - Ubuntu Wiki

StefanはCannonicalのカーネルチームの人みたいだから, そういう人がdm-writeboostに気をかけてくれて, 修正パッチまで作ってくれたのも喜ばしいことだ. (修正すべき点を考えるために読んだということだから) それだけ価値があるソフトウェアだと思われているということではないか.

しかし, 1)についてはおれにccがあるべきだし, 2)についてはGithubにIssueを上げるべきだった. いずれも無視されたことはすなわち, おれという開発者が雑魚であるが故に相談する価値もないと軽んじられたということではないか. ううう

(writeboost report) v2.2.6をリリースしました

一週間前にv2.2.5をリリースしたばかりですが, v2.2.6をリリースしました. v2.2.5で入れた修正によって3.10(3.14以前)でコンパイルが出来なくなったためです. リードキャッシュを修正するために, DM_IO_BIOを使ってdm_ioを実行するコードを入れたのですが, これが入ったのが3.14(bioに大きな修正があった. bi_iterが追加)なので, それ以前のカーネルではコンパイルが通らなくなったということです. 3.14で行われた修正を参考にして, DM_IO_BVECを使うように修正しました. bash99という人がCentOS7で使ってるから捨てないでーと言ってますが, 実際にはTwitterでCentOS7でコンパイル出来ねえと言ってる人を見つけたので気づくことが出来ました. ありがとうございます.

github.com

ちょうど私が支笏湖にリフレッシュ旅行に行ってたということもあり, ついでに設計改善も検討して, 全部盛り込んだリリースとなっています. コーディングは主に, 森の中のテーブルでやりました. みなさんもたまには森の中でコーディングをしてみたらどうでしょうか.

github.com

ライトブーストは, rambuffer, SSD, HDDという3層を制御しているのですが, 副作用はrambufferからHDDに一方向に伝搬していきます. それぞれの間はproducer-consumerパターンになっているのですが, 実装的により明確にするようにしました. その方が, メモリバリアの挿入がよりわかりやすくなるのと, 終了処理がきれいになるからです. メモリバリアについて軽く説明すると, プログラムというのは, 書いた順に実行されるとは限りません. コンパイラやCPUは, 全く依存関係のないコードをout-of-orderに実行します. 従って, スレッドAがデータを書く -> idをincrementする -> スレッドBがidのincrementに気づく -> データを読むというproducer-consumerのような形では, 正しくメモリバリアを挿入しなければ, スレッドBが, スレッドAがライトする前のデータを読む可能性があります. だから, スレッドAがデータを書く -> ライトバリアを挿入; idをincrementする -> スレッドBがidのincrementに気づく; リードバリアを挿入 -> データを読む という形でメモリバリアを挿入してあげる必要があるのが, デザインパターンのような, お決まりの形です. なので, このお決まりの形により明確に帰着させるために, 土台の設計改善もやったというのが今回の修正です. もっと知りたい人は https://www.kernel.org/doc/Documentation/memory-barriers.txt を読んでください. (関係箇所を以下に抜粋)

[!] Note that the stores before the write barrier would normally be expected to
match the loads after the read barrier or the data dependency barrier, and vice
versa:

    CPU 1                               CPU 2
    ===================                 ===================
    WRITE_ONCE(a, 1);    }----   --->{  v = READ_ONCE(c);
    WRITE_ONCE(b, 2);    }    \ /    {  w = READ_ONCE(d);
    <write barrier>            \        <read barrier>
    WRITE_ONCE(c, 3);    }    / \    {  x = READ_ONCE(a);
    WRITE_ONCE(d, 4);    }----   --->{  y = READ_ONCE(b);
 (*) smp_mb__before_atomic();
 (*) smp_mb__after_atomic();

     These are for use with atomic (such as add, subtract, increment and
     decrement) functions that don't return a value, especially when used for
     reference counting.  These functions do not imply memory barriers.

     These are also used for atomic bitop functions that do not return a
     value (such as set_bit and clear_bit).

     As an example, consider a piece of code that marks an object as being dead
     and then decrements the object's reference count:

    obj->dead = 1;
    smp_mb__before_atomic();
    atomic_dec(&obj->ref_count);

     This makes sure that the death mark on the object is perceived to be set
     *before* the reference counter is decremented.

その他, 次リリースの4.8カーネル(現在はrc6)では, bioのフラグの持ち方に大きな修正が入ります. 具体的には, bi_rwに詰め込んでいたものをbi_opとbi_opfに分離します. 4.8-rc6に上げてみるとコンパイルが通らなくなっていたので, 追従しておきました.

github.com

疲れた・・・

(writeboost report) v2.2.5をリリースしました

v2.2.5をリリースすることが出来ました. What a day!

このリリースには超重要な修正が入っています.

Read-caching caused file system corruption · Issue #150 · akiradeveloper/dm-writeboost · GitHub

過去に2度報告されたものの, 1年間未解決だったread-cachingのdata corruption問題が解決しました. clone bioが非LVMデバイスからackした時にペイロードが空になってることが問題であり, この問題についてはMLにフィードバックしました. (https://www.redhat.com/archives/dm-devel/2016-September/msg00043.html) 報告者のベンジャミンが優秀であることは一目で分かったので, このチャンスは逃すまいとベンジャミンと協力しながら集中的にアタックした甲斐があって, 原因究明に至ることが出来ました. 本当にラッキーでした.

lack of memory barriers · Issue #155 · akiradeveloper/dm-writeboost · GitHub

read-cachingのバグをコードの中に探している時に, メモリバリアを疑っていました. 実際にメモリバリアが足りないためバグる可能性があると結論づけて, 修正を行いました. ただし, メモリバリアについてはより完全にするためにアーキテクチャ変更も含めて, これからも検討を続ける必要があると思います. 今回は明らかに必要な箇所と, その他数箇所に防御的に入れました.

最近, 短期間でのリリースが続いていますが, 毎回大事な修正が入っています. フィードバックをくれるユーザは増えており, 実運用をしている挑戦的なユーザもいます. かなり巨大なサービスのバックエンドに使ってくれそうなユーザもいて, これからもっと楽しみです. ユーザがフィードバックをくれることにより, バグが発見されてどんどん品質が上がっていきます. 品質が上がればさらにユーザが増え, フィードバックが増え, ... という正のフィードバックがかかっていくことになります.

今後も, バグ報告があれば対応し, なければメモリバリアを中心に検討を少しずつ進めるという形で, 遅くても3ヶ月後くらいには2.2.6を出せればいいなと思っています.

それではみなさん, ライトブースト v2.2.5をお楽しみください.

GitHub - akiradeveloper/dm-writeboost at v2.2.5