Linux Foundation Japan Symposium講演レポート

Linuxカーネル開発最新事情

2007/07/10

　Linuxカーネルはリーナス・トーバルズが1991年に個人的に書き始めたもの。以来、多くの開発者を巻き込みLinuxカーネルは成長し、今も新機能を取り込み続けている。もともと趣味の延長やアカデミックな好奇心から開発に関わった人が多かったことから、かつては「Linuxカーネルの開発はボランティアによって支えられている」と言われたが、それは、現状のLinuxカーネルの開発には、まったく当てはまらない。そう話すのは、7月10日に東京で開催された第5回The Linux Foundation Japan Symposiumで講演した米LWN.netのジョナサン・コーベット（Jonathan Corbet）氏だ。

　「最新のカーネルに対して機能を加えたり、変更したりするパッチを送った開発者は2006年6月のバージョン2.6.17以降、全部で2100人。このうち、少なくとも3分の2以上の人々がレッドハットやIBMといった企業に在籍し、正規の業務としてカーネル開発に携わっている」（コーベット氏）。

　カーネル開発に対してもっとも貢献度が高いグループは、所属が不明の人々（27％）。次いで多いのがレッドハット（14％）。趣味で参加している人の割合は5％にしか過ぎず、所属不明の人々と合わせても32％にしかならない。残りの68％はLinuxに関連する大企業などに所属しているというわけだ。

　貢献度だけ見れば、上位10社の企業関係者だけで約半分と大きな割合を占めるが、開発に参加している人々は多様だ。約1年で200万行が変更されたというが、その1％以上に貢献したのは10組織のみ。最大の貢献企業でも2.3％に過ぎない。この数字からは、Linuxカーネルの大部分が、多くの所属の異なる開発者から、個別にはごく小さなパッチを受け取った集大成という姿が浮かび上がってくる。

　逆に何千もの開発者が関わっていることから、現在GPLv2のライセンスのもとに配布されているLinuxカーネルを、GPLv3に移行するのは「とても起こりそうもないこと」（コーベット氏）だという。Linuxカーネル開発者の間では、GPLv3が不評なうえに、権利を持つ関係者すべての合意を取り付けることは、現実的に難しいという。

ロードマップはないが、頻繁なアップデート

　リーナスが各方面から送られてくるパッチを採り入れるか否かを決め、ある時点でカーネルに統合するという開発プロセス自体は変わっていないが、ここ1、2年でリリースのプロセスや速度には変化が見られるという。

　「Linuxには公式のロードマップがないということで、良くアナリストやユーザーから苦情が出てくる。将来のLinuxがどんな機能を採り入れるかについては、誰にも分からないし、リーナスにさえ分からない。いや、リーナスなら次期リリースに何が入るかは分かるでしょう。現にほんの12時間前に新しいCPUスケジューラをカーネルに採り入れたのですから」（コーベット氏）

　Linuxカーネルは現在2.6.22が最新バージョンで、10月には2.6.23がリリースされると見られている。このリリースの間隔は2、3カ月とハイペースで、ここ1、2年ほどは一定しているという。新バージョンのカーネルがリリースされた直後の開発の初期段階の約2週間は「マージ期間」と呼ばれ、リーナスが次期リリースに取り込むパッチを集め、その取捨選択をフィックスする。そこで出てくるのが「2.6.N-rc1」（release candidate）というバージョンで、ここから8〜12週間の検証期間を経て正式リリースに至る。かつては、明示的に分けていなかったパッチを取り込む時期と検証期間を区別することで、カーネルに加えられる変更は一定期間に集中するようになったという。

4096個のCPUでも問題なくスケールさせるには？

　講演は1時間の短いものだったが、コーベット氏はカーネルの開発体制だけでなく、現在、カーネルに取り込まれつつある、もしくは検討されている新機能についてもかいつまんで説明した。

　現在のLinuxカーネルは、1024個のCPUまでは問題なくスケールするが、4096個のCPUではやや難ありだという。SMPを実現するためのメモリ構造の問題で20％ほどのメモリが無駄に消費されてしまうのだという。4096CPU構成というのは非現実的に思えるが、コーベット氏は「かつて、超ハイエンドの32ビットCPUで1GBのメモリをどう扱うべきかという議論をしていた時代があった。今では、それはノートPCのスペックだ。現在のスーパーコンピュータは、今日のノートPC。常に5年先を見て設計する必要がある」と話す。

　ファイルシステム関連は、最もホットな領域だ。現在Linuxのファイルシステムが抱えている問題の1つは、ファイルシステムの検査・修復に時間がかかることだ。速いペースでディスクの大容量化が進む一方、ディスクI/Oの高速化は、それに追い付いていない。そのため、システムがクラッシュしたときに走らせるfsckは長いときには1週間もかかるようになっているという。

　この問題に対する解決策は、現在「chunkfs」「tilefs」という名前で検討されている。文字通り、ファイルシステムを小さなチャンクのサブファイルシステムに分けて、クラッシュの瞬間に使われていたサブファイルシステムだけをチェックするようにするというアイデアだ。

　このほかオラクルが開発した「Btrfs」、ext3の後継で大幅に扱えるディスク容量が増えた「ext4」、ローレベルのプラグインに対応し、圧縮機能やデータベース機能を備える「Reiser4」、USBメモリなどフラッシュメモリ向けに、書き換えの物理領域をなるべくデバイス全体に分散することでフラッシュメモリの耐用年数を上げる「LogFS」など、多くのファイルシステムが検討されているという。直近の次期リリースである2.6.23でも、高速化するCPUに合わせてタイムスタンプを秒単位ではなくナノ秒単位にする機能や、稼働中にディスクの断片化をデフラグする機能などが入る可能性があるという。

　また、ファイルシステム同様に、「もう開発は終わったと思われている機能」であるCPUスケジューラやシステムコールの挙動を把握するための「utrace」など多くの新機能が検討されているという。

仮想化の次の課題は“コンテナ”

　仮想化についても動きは活発だ。コーベット氏によれば、10月リリース予定の2.6.23でようやくXenがカーネルに入るが、そのほかにもKVMやlguestといった仮想化ソフトウェアがある。特にlguestは、構成がシンプルであることから、むしろXenよりも、今後はlguestのほうが、よく耳にする仮想化ソフトウェアになっていくのではないかというのがコーベット氏の見立てだ。

　もう1つ、興味深い動きとして“コンテナ”の実装がある。コンテナとはホストOSの1つのカーネルイメージを、その上で動くゲストOSが共有する形で仮想化を実現するもので、メモリの利用効率に優れる。しかし、コンテナを実現するにはプロセスやデバイスといったシステムリソースについて高度な管理が必要となるため、コンテナを実現するソフトウェアは複雑になる。

　現在コンテナについては、グーグルをはじめ、いくつかの実装パッチが存在しているという。ただし、カーネルに取り込むに当たっては、少なくとも、それらが共通の土台の上に構築されるようになる必要があるなど、まだ当面時間はかかりそうだという。

（＠IT 西村賢）

情報をお寄せください：

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）