テストステ論

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

dm-lcの紹介 (11) 不揮発性メモリの応用

最近, 不揮発性メモリというのが現実的になってきて, 研究の世界では賑やかになっているようです. どういうI/Fでアクセスするとか, 詳しいことは良く分かりませんが, dm-lcが不揮発性メモリによってどう変わるかの展望を書きます.

不揮発性メモリの利用方法は4種類あると思います.

# 適用部分 コメント
1 ストレージという概念が吹っ飛ぶほどすべて不揮発性メモリ dm-lcはすでに必要とされない.
2 インメモリが不揮発化. OSのアーキテクチャに影響してくる. 最近議論されている. 良くわからない.
3 何らかのインターフェイスによって不揮発性メモリを利用出来る. dm-lcにとってもっとも望ましい.
4 キャッシュデバイスの内部キャッシュとして不揮発性メモリが使われている. すでに実装されている. このようなSSDを前提とした実装もあり得る.

今回は, #3と#4について議論します.

いずれもポイントは, 現在, ログ吐き出しまでの一時的な領域として使っているRAMバッファを不揮発に出来たら良いことあるよね, ということです. すでに述べたとおり, dm-lcでは, REQ_FUA/REQ_FLUSHの処理を遅延してバッチ処理します. なぜこのようなことをしなければならないかというと, RAMバッファに書いた状態のままで上位に対してcompletionを返すと, サーバがクラッシュした時にデータが消滅するからです. では, このようなwriteを受け取ったら同期的に, 現在のバッファを永続的なデバイスに書き込んでしまえば良いかというと, それは性能を落としすぎるので, 現実的なラインとして, 例えば3ms以内に発行されたwriteはまとめて発行しようという方策にしています. これが現実的な解決策と判断しました.

しかし, このようにすることでペナルティもあります. そのうちもっとも大きいのは, ログ長が1MBでなくなることです. これによって,

  1. ライトスループット低下
  2. ログ吐きの前処理の回数が増えることによってサーバCPU負荷向上
  3. フラッシュ上で連続したライトにならないため寿命低下

などと言ったペナルティがあります. 特に最後の一つは, 仮にSSDに対するライトがシーケンシャルしか起こらないと完全に仮定出来るのであれば, コントローラの実装は簡単になるでしょうし, 予備領域も減らすことが出来るでしょう.

RAMバッファが完全に不揮発になったらどうなるでしょうか?REQ_FUA/REQ_FLUSHといったフラグを完全に無視することが出来ます. すべてのWriteは, この不揮発RAMバッファに書いた時点でcompletion可能となります(正確には, REQ_FLUSHについてはcompletionを返す前に, キャッシュデバイスに対してblkdev_issue_flushを叩いてフラッシュ命令を発行する必要があるでしょうが, 現状から比べれば随分良いものです).

上記の議論は#3の世界を仮定した場合ですが, #4についてはどうでしょうか. まず単純に, デバイスに対する永続的ライトのペナルティが小さくなります. また, フラッシュチップに対してデバイスが最適と判断したライトが出来るので, 寿命もきっと長くなるでしょう. ただし, サーバのCPU負荷については以前と同じだと思います. 内部的に不揮発メモリが使われてることを見込んで, RAMバッファへのライトを常に, キャッシュデバイスへのライトに置き換えてしまうという実装もあり得ますが, これはあまりエレガントではありませんしたぶん性能も悪いです(I/Oが発行されるため結局CPU負荷も上がるのでメリットがない).

以上より, dm-lcとしては不揮発性メモリが使えると嬉しそうだということが分かりましたが, ではどのくらいの容量があれば良いでしょうか?現在の実装ではデフォルトで64MBのRAMバッファを確保していますから, この分だけ搭載されていれば十分ということが分かります. これは現在の世界でも十分に調達可能なデバイスです. リカバリ時に不揮発メモリ部分まで調べる必要があるため, コードが複雑化すると思いますが, 恩恵が勝るなら実装するに値します. 興味ある人はフォークして実装してください.