テストステ論

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

(writeboost report) write-aroundがほしいというメールをもらった

ライトブーストをやっていると, 時々海外からメールをもらう. 昨晩もらったメールは面白かった

  • 送信者はホスティング会社のLinuxチームリーダ
  • LinkedInで調べてみると, まともなキャリアのあるエンジニアであることがわかる
  • writeboostを使いたいが, readしかキャッシュしたくないという特殊用途だ. これが出来るか知りたい
  • 現在は, writeboostをテスト/評価しようというフェイズ
  • ワークロードはリードが〜〜ライトが〜〜(具体的)

すぐさま回答した. もちろんYes. Issueではなくプライベートなメールでの問い合わせなため, 会社や名前は明かせない. 何を使っているかということは企業機密なんだろう. のちのち許可をもらったら明かす.

ライトブーストのread-cachingは, writeパスの軽量版として作っている. readのendioから一旦バッファリングしライターを作る. そいつが非同期的にステージングを行うという仕組みだ. もちろん, invalidationについても考慮してある.

原理的に出来るからとりあえず作っておくかと思って作っておいたが, 誰も使っていないためか, なぜか名前がwrite-throughになっていた. 正しくはwrite-aroundだ.

そのことを告げて, 明日まともにして再度連絡するとした. そして今日は作業をしている.

作業をしてみると, 単にリネームで済む問題ではないことが明らかになってきた. 最大の問題は,

write-around mode can't resurrect the clean caches in the caching device · Issue #132 · akiradeveloper/dm-writeboost · GitHub

この要旨は, write-aroundではdirtyなデータをログとして記録しないため, 再起動時のログリプレイにおいて, キャッシュした古いデータをinvalidateする情報が欠損するということだ. つまり, write-aroundでは, 再起動時にキャッシュを全部捨てる必要がある.

これをユーザにやらせるのは, この仕様についてコントロールを失う. また, writebackキャッシュとして使う場合と同等に使うことが出来るべきだから, カーネルモジュール側でコントロールすべきだという判断に至った. 今はその作業をしている. もしwrite_around_modeフラグが立っていたら, superblockをゼロ埋めした場合と同じパスに誘導するという方針とする.

私は今回の件はビッグチャンスだと考えている. 理由は

  • read-cachingの素晴らしいテストになる
  • ライトブーストの導入実績となる