btrfsの圧縮規格をめぐる争い

btrfsという、現在開発中のファイルシステムがある。これは、既存のextの系譜に変わるべく開発されているファイルシステムである。ext系列のファイルシステムはすでに十分な実績があるが、いかんせん土台とする技術が古い。これは、extのオリジナル作者であるTheodore Ts'oも認めている事実である。つまり、抜本的な革新のためには、全く新しいファイルシステムを開発する必要がある。

そこでbtrfsだ。btrfsは、近代的な技術を使った新しいファイルシステムである。内部の実装はさておくとしても、ユーザーにとっても便利な近代的な機能を多数提供している。スナップショットやサブボリュームのサポート、ファイルシステムによるRAIDや圧縮のサポート、オンラインデフラグ、オンライン動的ディスクの追加と削除、さらには、将来的には暗号化などもサポートする予定である。

これらの機能は、従来、ファイルシステムの外側に実装されていた。しかし、やはりファイルシステムに直接実装した方がいい。

ただし、btrfsはまだ、実際に使うには早すぎる。たとえば、ファイルシステムのチェックがまだ未完成だ。計画によれば、オンライン、オフライン両方のファイルシステムチェックをサポートするらしい。聞くところによると、オフラインチェックの実装は、いまオラクル内部でテスト中であるとか。オフラインチェックは当然あるべき機能であるが、オンラインチェックも欲しい。もはや、HDDはその容量からして、全域にオフラインチェックをかけるのは現実的ではない。

さて、圧縮である。昔、ファイルシステムによる通過的な圧縮のサポートといえば、容量の節約という意味が大きかった。しかし現代では、容量ではなく、パフォーマンス上の理由もある。HDDのパフォーマンスは、実はそれほど変わっていないのだ。確かに、高密度化により、ある程度シーケンシャルな読み書きは速くなったが、劇的な性能向上というわけではない。シーク時間は今も昔も10ミリ秒ぐらいかかるので、ランダムアクセスは遅い。そこで、圧縮により読み書きのサイズを削減してやれば、パフォーマンスの向上になる。

問題は、圧縮によりCPU時間を浪費してしまうと、せっかくのパフォーマンス向上が台無しになってしまう。CPU時間は依然として貴重であり、ディスクアクセスにCPUが多大に浪費されることがあってはならない。そこで、圧縮アルゴリズムは、高速でなければならない。

現在、btrfsに公式に取り込まれている圧縮アルゴリズムは、gzipaとLZOである。しかし、さらにsnappyと、lz4が候補に上がっている。

どうも、btrfsの圧縮アルゴリズムは戦国時代のようである。どれが一番優れているのか判断するためには、もうしばらく時間が必要である。