twitter icon   twitter icon   rss icon

Linux.com Japan

Home 特集 Kernel Hackers Meeting Kernel Hackers Meeting2

カーネルハッカーズ座談会 - Kernel3.0 & Linux20周年特集 -

1991年8月25日に産声を上げたLinuxは、 昨年で 20周年を迎えました。そして、カーネルのメジャーバージョンも3.0に更新。この2つの大きな節目を迎えたLinuxについて、日本を代表するコミュニティ開発者、Kernel Hackerの皆さんの集まって頂き、お話を伺いました。
終始笑いにつつまれた座談会の様子を、4回シリーズでお届けしています。

(編集部注:このインタビューは昨年(2011年)の夏に開催されたものです。時勢等はその当時のものであることをご了承下さい)


連載第1回】  連載第2回】  連載第3回】  連載第4回


杉田:  その他に、3.0で今入ってないけど、動向が気になる技術ってありますか?もしくは、自分たちが開発しているイチオシの技術。3.xxにはいれるぞーと、ここで宣言してもらえるとうれしいです。


亀澤:  仕事の話じゃなくて、趣味の話でいくと、Overlayfsとか unionfs系。Here comes the new challenger.っていうくらい、何人もやっている。でも今、クラウドでマルチテナントなどをしようと思ったら必要だよね。

備考1:
LinuxCon Europeでは、parallels(仮想化技術ビジネスをしている会社)から block device の 重ね合わせができる仮想デバイスの提案がありました。


杉田:  亀澤さん自身は、その機能に関して、なにか開発活動をしています?


亀澤:  いや。今は注目しているだけ。


平松:  趣味の観点で言うと、Kvm-toolsも興味がある。QEMUを使わずにKVMだけで実現するわけでしょ?


山幡:  そうです。でも、他人の開発は楽しそうに見えるのかなぁ? やっている本人は結構大変なんですよ。


亀澤: でも、面白い機能だと思っている。ただ、うちの開発人材をつぎ込んでよいものかが解らない。上司に、これってQEMUに取って変わるのって言われても、まだ解らないからね。それはないだろうという気もするけど・・。


亀澤:  それから、さっき話題に出たcleancache(vol1参照)に関連して、RAMster(解説12)のことをプレゼンしていた人がいたね。リモートシステムのメモリをスワップにつないで使う機能だけど。

【解説12】 RAMster
tmemの実装方法の1つ。cleancacheの仕組みを利用して、メモリ不足になっているプロセスを実行中のマシンが、メモリに余裕がある別マシンのメモリを使うことができる仕組み。


平松:  スワップをネットワーク越しにやっても良いだろうという話ですね。5年位前には、ストレージよりもネットワークの方が速くなるっていう話でしたが、今は、Fusion-ioみたいにPCI expressそのままの性能が出ますよっていうものが出てきていますよね。

亀澤:  ネットワークカードの方が、今は遅いってわけか。技術の進歩って面白いよね。


フェルナンド:  話は違うけど、コンテナ(解説13)では、ネームスペースにまだ課題が残っていますよね。ファイルシステムの問題でもあるけど。例えば、コンテナ1にあるユーザーがファイルを作ったとします。たまたまコンテナ2の別人だけど同じユーザー名の人が、同じファイルシステムを使って、ファイルを作ったとします。そうすると、本来アクセスできないコンテナ1のユーザーが、今は、コンテナ2のファイルにもアクセスできてしまう。つまり、アクセス権限をユーザー名で判断しているので、困ったことがおきるんです。UIDとスーパーブロックを結びつける等様々な提案が出ていますが、まだ結論が出ていません。

【解説13】 コンテナ
1つのOSをあたかも複数のように見せる仕組み。既存のカーネルをそのまま利用し、「通常のOS処理で使われる空間」と「仮想OSが利用する空間」に論理的に分割して動かす。OSレベルで仮想化を行なうため、メモリなどが共有され使用リソースが少なくて済む。その反面、ゲストの脆弱性を付かれると親も乗っ取られる危険性がある。このコンテナをLinuxに実装する方法としては、「Vserver」「OpenVZ」「LXC:Linux Containers」がある。LXCはCgroup+付加機能を提供。


平松:  普通に使う場合、ファイルシステムは共有しないで分けるのでは?


フェルナンド:  確かに運用の仕方で解決できることはできるけど。でも、使い勝手を考慮して、コンテナの枠組みの中で対応した方が良いと思います。


亀澤: 確かに、セキュリティーの問題を解決しないと使い物にならないね。でも、そこさえ解決すれば使いものになるはず。


杉田:  まだまだ課題がある、ということですね。その他にもこの機能には言っておきたいことがある、ということはありますか? こうしたいという話でも良いし、なんでそっちの方向にいくかな?というものもあるのでは?


亀澤:  注目の機能を話していた時に話題にでなかったけど、btrfsとCephには、まだ課題が多い。


平松:  btrfsはfsckができればいいのだけど。ずっと言われているけど、まだ無いよね。


フェルナンド: Red Hatの人とOracleの人がbtrfsのfsckを作っているはずですよ。


西島: 本当ですか? いつできます?


フェルナンド:  それは言えません。(一同爆笑)


平松:  でも、btrfsでfsckをやるととても時間がかかるので、現実的ではないのでは?


亀澤:  Chris Masonは、超高速のfsckを作ってやるといったらしい(備考2)。


一同:  エーっ?? 期待したいね!

備考2:
この座談会の後でbtrfsのメーリングリストでbtrfsckが話題になってlwnで採り上げられました。
http://lwn.net/Articles/462543/
また、LinuxCon Europe でbtrfsck のデモがありました。


フェルナンド:  話が戻りますが、仮想化環境向けのバックアップソリューションを作るためにさっき言ったファイルシステムフリーズ機能を活かそうとしたけど、今の実装が提供するAPIでは安全に使えないことに気づいたんです。そこで、APIのギャップを埋めるべく新しいインターフェースを開発してメーリングリストに投稿したけど、まだ採用されていない。


平松:  どういうインターフェースなの?


フェルナンド:  既存の API は FREEZE と THAW という二つの ioctlだけ提供していて、ファイルシステムをフリーズしたりアンフリーズしたりすることができる。でも、ファイルシステムの状態、つまりフリーズされているか否かを確認するAPIはない。そのために、ゲスト上で動くデーモン、ゲストエージェントというんですけど、それでファイルシステムのフリーズ機能を制御すると、そのデーモンが落ちたかkillされた場合にひどい目に遭う可能性がある。というのも、ファイルシステムをフリーズしたままデーモンが終了したかもしれないから。今は、フリーズ機能に関してファイルシステムの状態を確認するAPIがないので、安全に復帰できるとは限らない。そこで、フリーズの状態をチェックするためのioctlと新しい API を追加したんです。

平松:  新しい API? 具体的にはどう処理が行われるの?


フェルナンド: まず新しい ioctl で、フリーズしたいファイルシステムを制御するためのファイルディスクリプタを取得する。その取得時にファイルシステムがフリーズされます。逆に、取得したファイルディスクリプタを解放する時には、ファイルシステムが解凍される。さっきの例で言うと、この API を使えば、ゲストエージェントが落ちたり Kill されると、そのプロセスの終了処理の延長ですべてのファイルディスクリプタが解放されますね。この時、当然フリーズ用のファイルディスクリプタも解放されるので、ファイルシステムが解凍されるんです。だから、ファイルシステムがフリーズ状態に残ることがない、というわけです。
ついでに、マイクロソフトのVSS(Volume Shadow Copy)みたいな機能も入れてもいいかもしれない。そうすればストレージのスナップショットを取得する時にアプリケーションに通知を出せるから。


平松:  なるほど。そうすれば、その通知を受けたアプリケーションは、ダーティバッファの内容を吐き出したりすることができるね。


フェルナンド:  うん。でも、こういう機能は必須ではないかもしれないので、強くプッシュできてないけど。


平松:  いやー、それが欲しいという声はあるでしょ?


フェルナンド:  でも、商用データベースのようなまともなアプリケーションならば、全てのダーティバッファを吐き出さなくても中でちゃんと処理するから、何かあった時でもスナップショットから復帰できると思うし。だから、PostgreSQLやOracleなどはこの機能はいらないでしょ? 
話は変るけど、RCのパッチが簡単に入るんだけど、たまに誰もメンテナンスしてくれないので困る。組込みだけの問題ではなくて、ネットワークプロトコルの世界でもそういうことがある。自分で直そうとしても簡単にテスト・検証できないことが多いし。


杉田:  それはパッチを作った本人に言うしかないのでは? もしくはその機能のメンテナに言うとか。


フェルナンド:  もちろん、必ずそうするんだけど、本人が忙しいとか転職したとかで対応できないことがある。主要メンテナ達に補佐を付けるべきかもしれない。


平松:  experimentalと印をつけておくべきかも。使う人が限られているのって、ものすごくバグがあるから。


野村: テストできてないものは、区別をつけることを徹底した方がいいかもしれませんね。


亀澤:  CgroupもRHEL6が出るまでは、ほとんどexperimental扱いでしたよ。そう言えば、なんの時だったか忘れたけど、Linusか誰かから言われて、configのデフォルトを読んでいたら、コメントにif unsureと書いてあった。


平松:  Cleancacheもそう。ドキュメントを読んだ時、最後に「unsureだったら、say N」って書いてあった。誰も、ドキュメントをチェックしていないから気がついていなくて、デフォルトがYになっている。


亀澤:  誰かが読んでいるのかと思っていたよ。


杉田: 意図的にデフォルトをYにしたんじゃないの?


亀澤: まぁ、メンテナがアフターケアをしていくから、何とかなりますよ。それに、よい機能や使える機能であれば、年月がたてば理解されて、皆がメンテナンスしてくれます。


平松:  多分そうでしょう。でも、それを見て「これはYがデフォルトなのは違うだろう」って突っ込みたくなりました。


杉田:  みんなチャレンジャーだから、Yにしてみて、大丈夫だったらそのままでいいって、ことじゃないですか? 


(一同爆笑)



Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ

  1. Today's Linux 2018/04/09 2018年 4月 08日
  2. Today's Linux 2018/04/11 2018年 4月 10日
  3. Today's Linux 2018/04/10 2018年 4月 09日
  4. Today's Linux 2018/04/16 2018年 4月 15日
  5. Today's Linux 2018/04/17 2018年 4月 17日

Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!