テストステ論

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

(writeboost report) dm-writeboost 2.2.0をリリースしました

https://github.com/akiradeveloper/dm-writeboost/tree/v2.2.0

2016-05-01  Akira Hayakawa  <ruby.wktk@gmail.com>

    * v2.2.0
    * Remove partial writeback in foreground. This results in writing
    back cached data strictly from the older ones, which makes cache
    device corruption safer
    * Fix build error for kernel 4.6. per_bio_data_size is renamed to
    per_io_data_size
    * Remove SECTOR_SHIFT

前バージョンが2.1.2なので, 次は2.1.3にしようかと思っていましたが, 機能拡張レベルで強烈な変更となったため, 2.2.0にしました. 私としては, 構想レベルですべき実装はすべてやり切ったなという思いです.

今回の目玉修正はこれです.

(writeboost report) 2.1.3に向けた改善案 - テストステ論

もう一度おさらいしておくと, この改善によって, 「今ライトバックされた最新のログIDがkである」と言った場合に, 「ログID>kの副作用は一切HDDに適用されていない(ライトバックされていない)」ことが保証されます. つまり, ログ(4KB*127を格納)の粒度になりますが, HDDには過去に書き込まれた情報から適用されていくことになります.

これは, 一般的なキャッシュソフトウェアでも, 一番ナイーブには全キャッシュの書き込まれた時刻を保存しておいてその順にライトバックするなどで実装出来ると思いますが死ぬほど重いです. ライトブーストの場合はログIDという情報を利用してこれを荒い粒度で近似的に実現しているということです.

なぜ, 今までそうなっていなかったかというと, 実装が難しかったからです. 例えば, 3セクタのリードリクエストが来たと考えます. このうち真ん中の1セクタだけがRAMバッファでたまたまヒットしてしまったとします. 今までとっていた実装は, RAMバッファでヒットした時点でRAMバッファのデータを緊急ライトバックしてしまうことです. その後, リードリクエストをHDDに飛ばすことによって, データ合成をHDDにお任せすることが出来ます. しかし, 今回の修正では, ライトブーストの層でこのデータ合成を実行します. HDDから3セクタを読み, RAMバッファの1セクタをbioペイロードにコピーします.

bioペイロードは上位でマージされた結果であることもあるため, 扱いが単なるバッファではありません. 複数セグメントが繋がってることもあり, そのページ内オフセットもバラバラである可能性があります. これをケアしながら安全に合成するのはややこしいことになるので, 優先度が低いままでした. しかし, 他の実装が大体収束したため, 今回やるということになりました. データ合成が必要なケースは, 上記以外にもあります. かなり苦労はしましたが, 性能上の改善はないと思います.

他には, 4.6でdevice-mapperがper_bio_data_sizeからper_io_data_sizeへのリネームというカスみたいなリファクタリングをするため, マクロを使ってこれに追従しました.