テストステ論

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

(dm-lc report) MLへのupdate投稿 & バリアフラグの実装

さきほど机の上でカレーヌードルをぶちまけて, マックブックがダメージを負ったおれです. 中を開いてみると少し侵食されていましたが, バッテリーの表面とかだけなので大丈夫だと思いますし, 実際に立ち上がって動いていますが, とても不安です. 計算機, 特にストレージは信頼の出来るものでなければいけません.

(1) 投稿

昨日のコーディングに続いて, 今日AMはドキュメンテーションをして, dm-develとLKMLにメールを投稿しました. とりあえず今回は, スライド作ったので読んでね!みたいな軽いメールです. dm-develにはなぜか届きませんでしたが, CCのLKMLには届いたので目的は果たしたかな?まずは, dm-lcというものの存在, その仕組み概要, いかにおれが優れたプログラマかを周知する必要があります.

https://lkml.org/lkml/2013/7/27/161

(2) バリアフラグの実装

segmentに「REQ_FUA/REQ_FLUSHと一緒にログ書きされたか」というフラグ(バリアフラグ)をつけることによって, migration時に「バリアフラグ立ってないならmigrationしたデータを永続化する必要ないよね」という戦略をとれることを説明しました.

segment_headerにpersistentというboolメンバを持たせて, その機能を実装しました. 以下がdiffへのリンクです.
https://github.com/akiradeveloper/dm-lc/commit/5a7a340054b08c2645b8f843811fd59ea4a01d62#Driver/dm-lc.c

実装のポイントは, 「デフォルトはtrueをすること. ディスク上のsegment_headerにはpersistentフラグを保存しない. キャッシュ上から復活したものについてはセーフサイドに倒しておく」という点です. もちろん, 正しく実装しているつもりですが, 自分を信頼しないということが重要です.

(2-1) いや, 誤りでは???

書いていて気づきましたが, 良く考えてみると, この実装はやってはいけないものかも知れません. 以下のシナリオで実装の誤りを指摘出来ます.

キャッシュに対する2つのログ書きがあるとします. これを便宜上A, Bと呼びます(時系列順). persisntetフラグはそれぞれ, false, trueとします. そして, BはREQ_FLUSHを含んでいたとします. それぞれに対してACKを返してしまうと, Aの書き込みが永続化されたこともクライアントに対して保証してしまいます. しかし, Aをmigrateするときになって, persistentがfalseなので永続化しません. この後にAのログ領域が他のログで上書きされ, Bのログがmigrateされる前に電断が起きたとします. この時, Aのmigrateが永続化されていないとすると, データが消滅しますから, BのACKは何だったのだということになります.

はい間違い. はい終了

昨日は映画見れなかったし, 今日はカレーヌードルをこぼすし, 実装してみたら誤りだったと気づくし, なんて週末だ. 絶望しすぎて明日会社に行けるだろうか分からない. まぁ, 誤りに気づけたことは素晴らしいことなので, とりあえず今の実装のまま何かうまい方法はないか考えて, ダメならばrevertしようと思います.

以上.