冬の研究課題２・・・fs4o

やっぱりやってみるか、ということで、無謀にもファイルシステムを作ってみようかと。とりあえず名前を考えてみたが、思いつかないので、db4oを文字ってfs4oとする。これは長いこと考えてきたもので、組込み開発で一般化してる、「先読みによる性能向上」を実現する仕組み。

今日のコンピューターの性能は、ハードディスクのシークをいかに減らすかで決まるといって過言でない。ハードディスクというのはレコードのようなもので、回転するレコードの上を針が移動してデータをガリガリ取り出していく。もしレコードの記録が、ちょっとずつ飛び飛びに、円盤状のいろんなところに散らばっていたら、音楽なんてとても聴けたものじゃないだろう。同じことがハードディスクにも言えて、できるだけ針の移動（シーク）時間を減らすことが、性能に直結する。メモリやCPU、ネットワークの転送速度などは、マイクロ（100万分の1）秒からナノ（10億分の1）秒台だが、ハードディスクのシーク時間ときたら、せいぜいミリ（1000分の1）秒台なのだ。

そこで、このシーク時間をいかに減らすか、というのがOSにとっても非常に重要な課題になっている。その鍵を握るのは、IOスケジューラー、別名エレベーターだ。ここプラザミカドビルのエレベーターはなんて頭が悪いんだろう、といつも思うのだが、そうなるとイライラした人がフロアにあふれることになる。OSのIOスケジューラーがひどい場合は、そんな状態をイメージすると分かり易い。エレベーターは一定の方向で効率よく動いていき、途中で人を拾ったりおろしたりする。このようなことをしているのがIOスケジューラーで、針の動きに沿って、IOのリクエストが効率よく処理されるように並べていくのだ。うまくいけば連続した領域を一回でまとめてアクセスできるし、少なくとも物理的な動きを最小限にできる。例えばLinux2.6では、それまでのデフォルトであったLinus Elevator(その名の通りLinus氏が作った)に加え、4つの異なるアルゴリズムのエレベーターが利用可能だ。

さらに一度アクセスされたデータは、2回目以降で不必要にアクセスしないで済むようにキャッシュされている。Linux2.6では、bioの導入でこの部分が大きく改善された。

アプリケーションは、このようなOSの機能のおかげで、性能を確保できているのだ。これはデータベースも例外ではない。私が知る限り、メジャーなデータベースで、OS不要で動くものはない。それはつまり、ハードディスクへの物理的な配置やアクセス法は、ファイルシステムとOSに一任しているということだ。まあ、当たり前だといえば、当たり前だが。特にキャッシュがふんだんに用意できれば、ある程度ごまかしは効く。

しかし、組込みシステムでは、いろんなリソースの制約が大きいこと、それから性能の最低値が一定以上であることが要求されるので、このようなキャッシュなどに依存できないことが多い。そこでどうするかというと、ハードディスク上のデータの配置を最適化して、一回のシークで連続する領域を一気に先読みしてシークを最小限にすることで、必要な性能を確保するのだ。カーナビゲーションシステムなど、圧倒的な性能が要求されるシステムでは、既成のデータベースが全く相手にならない、驚くべき性能が実現されている。

そこでfs4oはどんなファイルシステムなのかというと、データをグループ化して、グループに応じて最低連続領域を保障しようというものだ。これによって、db4oのレベルではオブジェクト構造をしっかりデザインしながら、性能最適化のために、ひとまとめに操作されるオブジェクトは同一か隣接するブロックにまとめて保存することができる。

そんな特殊なアクセスが必要なのは、従来どおりやったら？、とも思うが、前述のIOスケジューラーの機能などを利用できるファイルシステムでやれたら、そちらのほうがメリットが大きい。もちろん、ハード、ドライバ、ディスクキャッシュ、IOスケジューラー、ファイルシステムなど、全部独自開発したものが最速なのだろうが、いかにそれに近い性能を実現しながら、同時に独自システムに無い柔軟性を提供できるかが鍵だ。

などと偉そうに書いてきたが、Programming in Cや、Linux Kernel Developmentを読みながら、一から学習中。ひとまずものすごいシンプルなやつで試して、これが本当にいけそうなのかどうか、見極めるところまではやりたい。