テストステ論

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

(writeboost report) dm-flakeyを使ってみる

dm-flakeyは, 周期的に壊れるデバイスをエミュレートするターゲットである. 主にテストに使う用途である(http://www.redhat.com/archives/dm-devel/2013-October/msg00131.html).

現在, writeboostのblockupを突然ONにした時のXFSの挙動がおかしいということで, 「お前のせいだ」ということを言われている. あるいはそうかも知れないという疑念はあるが, 何にせよ, 己のJustificationのために簡単に出来ることはさっとやるものである.

論点は, blockupをONにした時, writeboostがEIOを返したが, この時に何かが起こっていてXFSの挙動がおかしいのでは, だ. 思考実験によると, EIOを返したあとに, その前に発行されていたbioが正常に完了してしまうタイミング依存が発生し, それがXFSにとって想定し得ない挙動となっているのではと考えれるが, 無駄に悩むよりは, (1) EIOを返した時に本当にそんな挙動をするのか調査 (2) underlying deviceが死んだ時にキャッシュターゲットはどういう挙動をすべきか検討 の2つの仕事をこなす方が先である. 今回は前者をやる. 後者は, 他のターゲットを見て検討する. あるいはドキュメントがある可能性がある. writeboostにとってほぼ不可能な挙動を要求されたら困るが, デバイスのエラーごときでそこまで厳しい要求があるとは考えにくい. 少なくともdm-flakeyの挙動は許容されていいはずである(レッドハットは厳しいので, いかにテスト用といえども, 要求を満たさないターゲットはインクルードしないと思う).

初期化は以下のように行う. 引数は, である. 詳しくはDocumentationを読む.

sz=`blockdev --getsize ${BACKING}`
dmsetup create writeboost-vol --table "0 ${sz} flakey ${BACKING} 0 15 1"

tableを確認すると, 以下のようになっている. 正しく初期化出来ていそうである.

root@Hercules:~/dm-writeboost# dmsetup table writeboost-vol
0 6291456 flakey 254:49 0 15 1 0

同じようにxfs上でRubyをコンパイルしてEIOを突然返してみたが, 特におかしなことは起きず, gracefullyにshutdownして終了である. writeboostの方が悪い可能性が高くなってきた.