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

テストステ論

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

(writeboost report) 永続メモリ応用によるSSDへの並列I/O発行

writeboostは, バッファのタイプとしてtype=0,1,2の3つを計画する. type=0はバッファが揮発であり, その為に失うものが少なくない. 例えば, SSDに512KBごとでライトすることを保証出来ない. 一方で, バッファが不揮発となれば, これを保証出来ることは明らかである.

他にも, バッファを不揮発にすることで得られるものが分かった. SSDに対してバッファのフラッシュを複数同時発行することが出来る. 言い換えると, フラッシュバッファのidについて順序を問わなくなる. データがバッファに永続化されているからである. 本質的な問題は永続化にある.

もし, バッファが揮発であると, これは危険である. 例えば, id=2とid=3が同時発行され, id=3でREQ_FLUSHをackしてしまったにも関わらず, id=2はSSDに書き込んでもいないのでREQ_FLUSHの対象とならず, データロストする可能性がある. このそもそもの問題は, バッファフラッシュのコンテキストまで永続化を遅延していることにあるが, 少なくとも永続化はデータを書き込んだあとにしか出来ないので, このタイミングより早くすることは原理的に不可能である.

しかしこの世界までいくと, 完全にCPUネックの世界になる. 鍵は, キャッシュ処理のロック処理にある. ここを並行処理することが鍵となるが, writeboostは原理上, バッファへの書き込みをシーケンシャルに行う必要があり, この制約がロック設計に与える影響が大きい. HDDのように性能の低いデバイスを活かすためにはシーケンシャルアクセスが必要であった(そして, CPUネックまで追い込まれることは珍しかった)が, デバイスが高速になれば, シーケンシャルをケアするコストの方が却ってボトルネックになってくるというバランス感覚なのかも知れない.


上記I/Oの並行処理のためには, flush_procをworkqueueで実装し, workerを複数実行するだけで良い. type=0の時には, workerの上限を1とすればバッファ揮発に関する問題は回避出来る.