2015年1月16日金曜日

論文紹介: Virtualize Storage, Not Disks

USENIX HotOS 2013で発表された Virtualize Storage, Not Disks を読みました。

KVM上で動くゲストOSのディスクには、一般的にファイルシステムが構成されています。つまり、ホストOS上から見ると(ホストOSの)ファイルシステムの上に(ゲストOSの)ファイルシステムが乗っかっているという状況となります。多くのファイルシステムはこの状況を想定せずに設計されているため、ゲストOS側のファイルシステムがホストOS側の環境とマッチせず性能低下を引き起こす可能性があります。

筆者らは、ゲストマシンが直接ホストマシン上のディスクにアクセスすることを提案しました。具体的には、ゲストマシン上のOSを変更してPOSIX(WIN32API)レベルから、専用のAPIを叩くことでホストOS上のファイルシステムにアクセスするというものです。ホストOS側のファイルシステムにも手を加えます。ファイルのメタデータは「どのOSのファイルか」という情報を持ち、また、固定長(4KB)チャンクによる重複除外機構の導入も行います。atomic系命令を使うことでlock-freeな実装を行い、close-to-openコンシステンシ以上のコンシステンシを保証させます。

まだ実装していないとのことだが、筆者らがこの続きを発表することはないんじゃないかと思われます。理由は2つあります。1つは「なぜ今まで誰も提案しなかったのか」ということです。おそらくこの問題は、ファイルシステムと仮想マシンの双方についての知識があれば誰でも解決したいと考える問題です。現に弊研究室の高橋らも似たようなことを考え、実装にまで至っているし、本論文でも類似例を挙げてます。それらの差というのは重複除外と組み合わせていないこととのことですが、それは「やってみたが性能が良くなかった」というオチがあったのではないかと私は考えています。私自身の研究はストレージの重複除外なので、重複除外が性能に与える影響についてはよく分かっているつもりです。ストレージに重複除外を導入したときの性能低下は筆者の想像以上に深刻なものとなるでしょう。

私がこの研究は行き詰まると予想するもう1つの理由は、おそらくこの研究が対象とする完全仮想化への対応は、それこそオーバーヘッドが膨大なものとなることが予想されるからです。何らかのCPU命令、あるいは例外をホストOSがフックして行う方法以外私は思い付かないのですが、フックすることで発生するオーバヘッドがかなり大きいことは多くのVM研究者にとっては常識でしょう。準仮想化する方向(つまりWindowsへの対応は諦める方向)に転換するべきでしょう。