FUSE: Filesystem in Userspace
FUSEは、元々はAVFSを サポートするためにMiklos Szerediによって開発が開始された。2001年11月12日に バージョン0.9が公開され、2004年10月15日から独立したプロジェクトとなっている。 今回は、FUSE導入の経緯と、この機会に議論されたパッチをLKMLに提出する手順を 紹介する。
FUSEの開発者であるMiklos Szerediは、カーネル・メンテナのAndrew Mortonと Linus Torvalds宛に、FUSEをカーネル2.6.10に加えるためのパッチを2005年1月10日に 提出したときに、以下のコメントを添えている。
FUSEはファイルシステムの機能を ユーザ空間にエクスポートする。そのためのインタフェースは、簡潔であり、効率的 であり、安全であり、そして、通常のファイルシステムのセマンティクスの大部分を サポートできる、ように設計されている。
FUSEは、プロトタイプの作成のために、そして、外部のライブラリあるいはプログラム を必要とするネットワーク/仮想ファイルシステムのために、使用することができる。 典型的な例はsshfsであり、sftpプロトコルを使用し、セットアップなし でのリモートサイトのマウントを可能にする。
FUSEは、現在、一般に利用できる多くのファイルシステムによって、そして、多くのin-houseアプリケーション によって、使用されている。また多くのユーザにとって有用で、安定していることが 示されている。
FUSEの経緯
FUSEをカーネルに加えることについての現在までの経緯は以下の通りである。
Miklos Szerediは2004年11月15日に、FUSEをカーネルに加えるための第1回目の パッチをAndrew MortonとLinus Torvalds宛に提出した。この時、FUSEをカーネル に加えるべきだと思った理由を以下のように述べている。
- FUSEは広く使用されている。FUSEを使用した利用可能な多くのファイルシステム がある、そして、たぶんもっと多くのin-houseアプリケーションがある。
- FUSEは開発開始から3年が経過している。とても安定していて、 カーネル・インタフェースとライブラリAPIの両方が完成している。
- FUSEのパッチはカーネルの他の部分には影響しない。
このMiklos SzerediのFUSEをカーネルに加えることについて考えて欲しいという 要望に対して、Linus Torvaldsは「カーネル2.4.xのためのコードを削除して、 整理された本当のパッチを送れば、たぶんもう一度考えるだろう。」と答えた。翌日、 Miklos Szerediは整理したパッチをLinus Torvalds宛に提出した。
その後、Linus Torvaldsは、メモリの割り当てが失敗したときのwrite()の動作に ついてのMiklos Szerediの説明に対して送ったEメールの中で、以下のように述べて いる。
ユーザ空間のファイルシステムには問題があると本当に信じている。私たちが それらをカーネル空間で行おうとするのには理由がある。
また、Linus TorvaldsはMiklos Szerediの
それはそうとして、私自身はデッドロックを見たことがないし、それについての 報告も受けていない。私は、書き込み可能な共有メモリマッピングと意図的に作成 したプログラムを使用して、カーネル2.4でFUSEをデッドロックさせることができて いる、しかし、カーネル2.6ではできていない。
という発言に対しても、以下のように述べている。
書き込み可能な共有メモリマッピングを使用して意地の悪いことをするVMの テスタがいないことはない。あなたは、ただ楽しみのために、しかし個人的に、 それらをやってみることができるだろう。FUSEをカーネルに加えることについて 真面目に話しているのなら、やはり私は書き込み可能な共有メモリマッピングが 全くサポートされないほうが良い。
FUSEは、それをサポートしない唯一のファイルシステムではないだろう。私が ページキャッシュのコードを書き直すまでは、NFSでさえそれらをサポートしなかった と思う。誰も本当に苦情を言わなかった(そうですね、苦情を言った人は極めて 少なかった)。
つまり、カーネルに加えるという観点からは、単純であるほうが本当に好ましい。 たとえダイレクトI/Oや書き込み可能な共有メモリマッピングのような風変わりな 機能をいつか本当に使いたいとしても、このように説明してみよう。特異な状況 について疑問がない何かをカーネルに加え、そしてそれから後で、特異な状況に ついてのものを加えることは、それ全てを一度に加えることよりもずっと簡単である。
私はお人好しだ。誰かに尋ねてみなさい。あなたが正しい方法でパッチを提出 するなら、 以前に受け入れなかったものと全く同じパッチを受け入れるだろう。 何人かの人が実際に故意にただ楽しみのためにそれをするということを確信して いる(ほら、彼がまたそれをやった。なんてバカなんだろう。)。
Miklos Szerediはこれまで2回のパッチの提出において、パッチが置いてあるWebサイト のURLをただ示していた。しかし、パッチを提出する場合には、 カーネル・ソース・ツリーのDocumentation/SubmittingPatchesに記述されている 手順が推奨されている。その手順の概略は以下のようになっている。
- “diff -up”あるいは”diff -uprN”を使用してパッチを作成
- パッチが含む変更点の技術的な詳細を記述
- それぞれの論理的な変更点をそれら自身のパッチに分離
- Eメールの宛て先を選択
MAINTAINERSファイルとソースコードに目を通すこと、そして、カーネルの メンテナが割り当てられた特定のサブシステムに変更点が適用されるか どうかを判断すること。もしそうなら、その人にEメールを送るように。
- CCリストを選択
特別な理由がないなら、CC先をlinux-kernel@vger.kernel.orgとすること。
- MIMEなし、リンクなし、圧縮なし、添付なし。ただの平文テキスト。
- Eメールのサイズ
大量の変更点は、メーリングリストそして何人かのメンテナには適切ではない。 パッチのサイズが未圧縮で40kBを越えるなら、インターネットでアクセス可能な サーバにパッチを置いて、そして、そのパッチを指すURL(リンク)を代わりに 提供することのほうが好ましい。
- カーネルのバージョンをはっきりと明示
題目の行あるいはパッチについての記述の中に、パッチが適用されるカーネルの バージョンを書き留めることは重要である。
- がっかりしないように。再提出すること。
変更点を提出した後は、我慢強く待つように。Linusが変更点を気に入って それを適用するなら、彼がリリースするカーネルの次のバージョンに含まれる だろう。
- 題目にPATCHを含めること
Linusそしてlinux-kernelへのEメールの量が多いために、[PATCH]を題目の 行の初めに付けることが一般的な慣習となっている。これによって、Linusと 他のカーネル開発者は、より簡単にパッチをEメールによる他の議論と見分ける ことができる。
- あなたの仕事に記名
私たちは、特にメンテナのいくつかの層を経由してカーネルの最終的な休息所へ 浸透できるパッチに対して、誰が何をしたかについての追跡を改善するために、 Eメールで回されているパッチに対してsign-offという手続きを導入している。
Miklos Szerediは2004年11月20日に上記の手順に従って、前回の提出からそれまでに 寄せられたコメントに対処した、カーネル2.6.10-rc2にFUSEを加えるためのパッチを Andrew MortonとLinus Torvalds宛に提出した。その後、FUSEをカーネルに加えること に関して具体的な動きが見られなかったため、Miklos Szerediは約2ヶ月後の 2005年1月10日に、前回の提出からそれまでに寄せられたコメントに対処した、 カーネル2.6.10にFUSEを加えるためのパッチをAndrew MortonとLinus Torvalds宛に 提出した。この提出したパッチにわずかな問題が発見されたため、翌日、Miklos Szerediはその問題を修正したパッチを再提出した。そのEメールの中で彼は以下の ように述べている。
どうか私のパッチを取り上げて下さい。
FUSEについて何か不満がまだあるのなら、それについてとても知りたい (FUSEはマイクロカーネルの嫌な臭いがする、FUSEは複雑すぎる、など)、 それでそれらに対処しようとすることができるので。
その後、2005年1月12日に、Miklos Szerediは以下の内容のEメールをfuse-develと linux-kernel(LKML)の2つのメーリングリストに送った。
>> FUSEをAndrewあるいはLinusのカーネル・ソース・ツリーに加えようとする
>> 試みはいかがですか？ およそ3週間前にLKMLでそれが試みられたということ
>> を知った。
>
> 前回の提出からこれまでに、カーネルのコードに対していくつかの変更を加えた
> (要求を中断することができるということに関係して)、そして、いくつかの問題
> がまだ解決される必要がある。その後、再び提出するつもりだ、今度はもっと
> うまくいきますように。うーん、カーネルにFUSEを加えるためのすごく急激な動きはないようだ。 たぶん彼らは、何を逃しているのか全く分かっていない。
だからもし誰かこの提案を支持したいなら、なぜFUSEをカーネルに加えることが良い のか(あるいはそうではないのか)について、ちょっとした議論を起こすために、 linux-kernelメーリングリストとLinusとAndrewあたりにEメールを送ってくれない だろうか。
このMiklos SzerediのEメールに対して、Andrew Mortonは以下のように答えた。
えっ。これまでにどんなユーザ空間のファイルシステムが開発されていて、何のために みんなはそれを使っているのですか？
このAndrew Mortonの問い掛けに対して、Miklos Szerediやその他の人たちから、 「Siemensモバイルフォンのファイルシステムをマウントするためにsiefsを使用して いた。」、「時々、ssh越しにリモートのファイルシステムにアクセスするために LUFSブリッジを使用している。bluetoothアダプタを再び動作するようにしたら、 bluetoothファイルシステム(btfs)も使用するつもりだ。」、「もっと本格的な あるいはそうではないファイルシステムの一覧をhttp://fuse.sourceforge.net/filesystems.htmlで調べる ように。」、「Sshfs(LUFSから恥知らずにも拝借した発想)。もしどこかのホストに sshできるのなら、通常のユーザとしてこのようにそれをマウントすることもできる。 mkdir /tmp/kempelen; sshfs mszeredi@kempelen:/tmp/kempelen 」、「私は数名の gmailfsのユーザのことを間接的に聞いている(1GBの容量を持つgmailアカウントを マウントして、どこにでも物を置いたりそれらを引き出すために使うように)。」、 「現在、どのプロジェクト(mc,gnome,kde)も、ftp越しに透過的に動作する、 アーカイブを取り扱う、ことなどができるように、それら自身の仮想ファイルシステム を実装している。適切に行えば、FUSEのようなユーザ空間ファイルシステムはそれらを 統合することができる、それに加えてもっと良いキャッシュ機能を提供することが できる。またユーザ空間ファイルシステムは、カーネル内に保持するにはとてもつらい だろうと思われる素晴らしいファイルシステム(atari800のような)のための置場所と なる可能性を持っている。」、などの返答が寄せられた。
このような結果、Andrew Mortonは2005年1月14日にリリースした2.6.11-rc1-mm1に 以下のコメントを添えてFUSEを加えた。
FUSEで遊びたい人たちのためにそれを加えた。それが加えられるべきかどうかについて は不可知論的である(とは言っても、まだ全くそれを詳しく読んではいない)、しかし、 明らかにそれに費やされた苦労の量に感心した。意見を求めたい。
これに対してMiklos Szerediは、「素晴らしい、感謝する、Andrew!」と答えた。 そしてその後、Miklos Szerediは2005年3月2日にAndrew Morton宛に以下の内容の Eメールを送った。
FUSEをメインラインのカーネルに加えることに異論がありますか？
FUSEは2.6.11系列のカーネルのための-mmパッチに入っている、そして、それと同じ コードがFUSE-2.2として1ヶ月前にリリースされた。だから、これまでに問題が発見 されることなく、かなりの量のテストを受けているはずだ。
-mmパッチに当初加えられたFUSEのコードは、人々が発見したすべての主要な問題 (最も重要なことには、OOM(Out Of Memory:メモリ不足)デッドロックの問題)に既に 対処した、そして、その時からこれまでにインタフェースに比較的重要ではない いくつかの変更点があったけれど、現在のカーネル・インタフェースは期間のテスト に耐えるだろうという感じがする。
このMiklos SzerediのEメールに対して、Andrew Mortonはその日のうちに以下のように 答えた。
1週間あるいは2週間のうちにFUSEをLinusに送ろうと思っていた。 FUSEとcpusetsは、注目に値する機能であり、カーネル2.6.12の候補者である。
また、SystemVファイルシステムなどのメンテナであるChristoph Hellwigも その日のうちに以下のように反応した。
私やファイルシステムに携わる他の何人かに、それを調べる時間を少し下さい、 本当に疑わしく見えるものが多少あったので。
以前にそれを調べる時間がなかったことをお詫びする、しかし現在、私は少し忙し すぎる。
これに対してMiklos Szerediは、翌日、以下のように答えた。
どうぞ調べて下さい。しかし、FUSEの最も複雑な部分はデバイスの取り扱いだと思う、 それは実際にはファイルシステムのためのコードではない。ファイルシステムの部分 は、大部分は本当に複雑ではない。
やはりより多くの人たちが調べるほど、それは良くなるだろう。
時間を取って下さい、FUSEをメインラインのカーネルに加えることを急がせたくは ない、しかし最近、バグに関して状況はとても静かになった。
Andrew Mortonは2005年3月20日に、カーネルに対してのFUSEの現状について 以下のように答えている。
bert hubert <ahu@xxxxxxx> wrote:
> カーネル2.6.12あるいは2.6.13に対してFUSEの状況は
> どうなのだろうかと思っている。Christoph H.がFUSEのコードを調査するつもりだと言っているので、それが終るまで 私は離れているつもりだ。
次回、FUSEの構造とファイルシステムの実装例について取り上げる予定である。
