テストステ論

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

(writeboost report) 勉強会資料 & ライトブーストの課題

クリスマスの翌日(12/26)ですが, サイボウズ勉強会に行ってきました. 東大の学生が賞をとった記念勉強会みたいな感じで, それがどかっと45分メインであって, 他は15分ずつ自分のネタを話すみたいな感じの構成でした(その他には, サイボウズの方々の開発に関わる話と, 外からの人が分散システムについて). kernelvmの話をベースにお話させていただきました.

質問で, 「チェックサムはないの」と聞かれて, 「チェックサムないと, データ部分だけ微妙に書かれてしまった時に見事に破綻するな」ということに気づけました. セグメントのパーシャルライトについては一応考えていたはずですが, 一体何を考えていたのやら.

どういうことでしょうか. ライトブーストのログリプレイは実にシンプルです.

  1. SSD上の全ログ中, もっとも古いidを持つセグメントを見つける.
  2. そこから右方向に, idが単調増加する間はセグメントのメタデータをhash tableに反映し続ける(途中でI/Oが起こることもあるが例外的).
  3. それぞれの読み込みでは, そのセグメントがちゃんと書かれたかを確かめて, 良しなにする (#)

ちなみに, もしバッファが不揮発になった場合は, 以下の2つの方式を考えますが, 後者を採用することにしています.

  1. SSDをリプレイ. その後, 不揮発バッファについても同様の方法でリプレイ.
  2. 不揮発バッファのデータをすべてSSDに書き出す. それから, SSDをリプレイ.

後者の方が, ログリプレイの難しいロジックが一つであり, 揮発バッファの時にテストされたものを完全に再利用出来るので簡単ですし, バグが出にくいと思います(1. ロジックが小さいので何か予期せぬ誤ちに出くわして全体破綻する可能性が低い. 2. バッファ上のデータはパーシャルライトないと仮定すると, これでSSD上のデータを上書きしてしまうことによって, SSD上のログリプレイが単純になる可能性がある). ライトブーストは, いきなり不揮発バッファを実装して提案すると嫌がられるので, このままmergeしていただいてからあとで揮発バッファ対応を修正するしかないですが, その際に, あまりにドラスティックに変更を加えるのは避けたいです. 少なくとも, 現行版(揮発バッファ)のユーザだけは完全に守らないといけない. バッファをSSDにフラッシュするシンプルな機構はすでに存在するのですから, ここを利用する方が筋が良いです.

というわけで, 問題は, SSD上のセグメントをリプレイする際の処理 (#) となります. 理想的には, 512KBのライトがアトミックであることなのですが, これは到底期待出来ないので, 策が必要になってきます. 戦略を練る上では, キャッシュとして使うデバイスにどこまで期待出来るのかがポイントになります. 例えば, デバイスが破綻する確率より低い確率でしか破綻しない妥協ならばしても良くなるとか, デバイスについて知ることが重要になります. ここらへんは, 先日書いた並列I/Oとの関連も出てくる(パーシャルライトされる可能性があるセグメントが複数あると難しくなることは明白)ため, 現在検討中です.