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

テストステ論

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

(writeboost report) WQ_SYSFSの名前衝突

背景

workqueueの比較的新しい機能として, WQ_SYSFSフラグをつけて作成した場合, workqueueの挙動を変更するインターフェイスがsysfsに作られるというものがある. 現在のカーネルではこれは4,5箇所しか使われていない. そして, どれも, ドライバそのものに紐付けられたworkqueueに対して適用されている. なぜだろうか?

例えば, ドライバが複数のデバイスを作成する場合(device-mapperの場合, ターゲットごとではなく, それが作成するデバイスのコンテキストごとに作成する), 仮にそれぞれに対してworkqueueが同名であったとしても, WQ_SYSFS無しならば問題ない. しかし, WQ_SYSFS有りならば名前が衝突してエラーとなる.

[ 4118.824173] ------------[ cut here ]------------
[ 4118.826117] WARNING: CPU: 1 PID: 4033 at fs/sysfs/dir.c:486 sysfs_warn_dup+0x7e/0x8a()
[ 4118.829377] sysfs: cannot create duplicate filename '/devices/virtual/workqueue/wbflusher'

これはすなわち, WQ_SYSFSをつけたいならば, workqueueがデバイスごとに共有されてしまうことを覚悟しなさいということだ. 果たしてこの仕様が妥当かどうかはわからない. しかし, 将来的にデバイスごとにworkqueueを持てなくなるリスクを冒してまでworkqueueを設定可能にする意味はあまりないと思う.

ライトブーストの対応

dm-writeboostとしては, wbflusher(SSDに対してバッファを書き込む人)の並列フラッシュをサポートしないこととした. これは先の計測において, 並列フラッシュの効果があまりなかったことによる. 究極的にライトを降らせたケースでやっと数%の改善があった程度だ.

並列フラッシュをすると, id=kのセグメントは書かれているが, 一つ前のid=k-1のセグメントがチェックサム破綻しているということが起きる. 実装したログリプレイアルゴリズムはこのケースでも破綻なく動くと思うが, 数学的に証明したわけではない. また, SSDエラー特性はまだ研究されている側面もあり, 当然その利用者である私は, あらゆるケースを読み切っているわけではない.

なので, wbflusherは一度に一つのworkerしか起動しないことにして簡便さをとる. 現実問題としては, これで何の問題もなく, RAM bufferも1枚か2枚割り当てれば十分なのだ. そのデバイスが欲するランダムライト性能に比べて, SSDのシーケンシャルライト性能が速いことを想定しているため, よほど究極的なケースを想定しなければ, wbflusherが複数のworkerを抱えたため並列フラッシュしなければならない状況にはなり得ない. また, workerを1つに限定することで実現可能になる実装もあるため, 些細な性能向上のために冒険はすべきではないと判断する.