Logo address

概要

目次

2003/02/20

Plan 9 の第5版で正式に採用予定のファイルシステムが姿を見せた。fossil である。fossil が第4版のうちに姿を現したのは、第5版でシステムの基礎にする前に、まだ改良の余地があるとベル研は判断したのであろう。また現在の標準ファイルシステム fs と簡易ファイルシステム kfs を廃止する前に、fossil を出すことによってユーザの混乱を最小限に抑えたかったものと思われる。図1 に第5版で予想される典型的なシステム構成を示す。

図1. 第5版で予想される典型的なシステム構成

これまでの Plan 9 のファイルシステムとの違い

これまでは Plan 9 は2種類のファイルシステムの下に運用されていた。ネットワークファイルサーバである標準ファイルシステム fs とローカルファイルサーバである kfs である。そのために次のような問題点を抱えていた。
この2つのファイルシステムの機能が fossil と venti の組に置き換わったのである(図2)。

図2. 第4版における Plan 9 ファイルシステムの改革
それとともに新たに以下の変更を行った。
ファイル名の空白文字に関して一言ふれておこう。Plan 9 はこれまでファイル名の中に空白文字を許してこなかった。Plan 9 は多くの UNIX のツールを引き継いでいる。UNIX の多くのツールはファイル名の中に空白文字が存在しないことを前提としている。しかしながら UNIX はファイル名の中に、ディレクトリの区切り記号 "/" と、言語 C における文字列のターミネータであるヌル文字以外の全ての文字(制御文字も含めて)をファイル名の構成要素として許していた。そのために実際に空白文字を含むファイル名が作成され、そのことがツールが正しく動作しない原因になっていくのである。そしてこの問題に対して現在に至っても放置されている。
Plan 9 の開発者たちは一貫性を非常に大切にしている。そのために彼らはファイル名から空白文字を排除しつづけたのである。しかしながら Plan 9 が他の OS と関わった場合に(関わらざるをえない!)空白文字を扱わざるをえない。そして第4版において、u9fs や dosfs などは、Plan 9 以外のファイルを読むときに、ファイル名の中の空白を(他の印字文字に変換しないで)そのまま提示されるようになった。UNIX と異なるのは、Plan 9 は一貫性を保とうとしている事である。すなわち文字列が空白を含む場合に引用符で囲んで書き出す C 言語の書式 %q が追加され、ls コマンドは空白を含むファイルを引用符で囲うようにした。
	term% touch 'my book'
	term% ls -l
	--rw-rw-r-- M 137 arisawa arisawa       0 Feb 15 22:55 'my book'
	term%
この改革は第一歩に過ぎない。全てのツールが最後の第10フィールドを 'my ではなく my book として読みとるようにし向けるのはもっともっと困難な改革である。

fossil が提供するファイルの構造

図3. fossil が提供するファイルの構造
fossil は複数のファイルの木を提供できる。各々の木は図 3 に示すように 3 つの枝を持っている。active はクライアントから読み書きできる枝であり、システムはこの枝に基づいて動作する。archive は長期的なスナップショットであり、snapshot は短期的なスナップショットである。スナップショットとは active の過去の姿である。
fossil のファイルの木の中で、main は特殊である。main は必須であり、また main にはユーザ登録ファイル /active/adm/users が存在しなくてはならない。他の名前の木は main のユーザ登録ファイルに基づいてファイルのオーナーが定められる。
木ごとにスナップショットを撮るか否か、撮るとした場合にその時間間隔を定めることができる。これまでの標準ファイルシステム fs でスナップショットを撮らないファイルシステム other を定義できたが、これはメールのような私的なデータを扱うのに適していた。fossil でも同様な問題を main でないファイルの木で扱うことができる。

fossil と venti との関係

fossil は venti と共に使用される。venti はアーカイバであり、fossil は venti へのインターフェースである。これまでの標準ファイルシステムの記憶階層(図4)と比較すると、venti が WORM に相当し、fossil が DISK に相当する。
図4. これまでの標準ファイルシステムにおける記憶階層
fossil の現在の役割はマニュアルによると書き込みバッファである。将来はフルキャッシュにすると説明されているが、Plan 9 上で venti と fossil を動かしている環境での筆者の使用感では、現在のままでも遅さを感じない。大きなファイルを読みとる筆者の実験では kfs に比べて読みとり速度が半分である。メモリーの使い方はマニュアルには書かれていない。(書き込みキャッシュはされている。)

vac はどうなる?

venti が発表されたとき、とりあえずのユーザインターフェースとして vac が添えられた。venti に保存されたファイルはファイルシステムとしてユーザに提供されるが、保存には vac コマンドが必要である。そのため cp などの自然なコマンドインターフェースが使用できないと言う問題点を持っていた。fossil によって vac は不要なものとなった。スナップショットを撮れる魅力的なファイルシステムができあがったのである。(もっとも vac は原始的なので vacfs とともに診断用としては重宝するかもしれない)

対障害安全性

配布文書[1] によると fossil はディスクに書き込みを行う場合には常に整合性を保とうとする。
ローカルディスクの場合、UNIX のファイルシステムにせよ、Plan 9 の fs も kfs も整合性を保とうとしない。そのために sync 動作なしにファイルシステムを終了した場合には整合性が崩れる。システムの起動の時には整合性のチェックを行う。整合性に問題があれば修復に多くの時間が費やされる。しかも正しく修復される保証はない。メモリキャッシュの使い方に問題があるのである。
もちろん fossil の場合にも sync なしに終了した場合には、メモリ上にのみ存在する情報は次回の fossil の起動時には反映されない。例えばファイルを作成しても sync なしに終了すれば、そのファイルは実際にはディスク上に記録されていないので見ることができない。しかしその場合でもファイルシステムに傷を与えることだけは防いでいる。
fossil はファイルシステムの完全な整合性を保証しているのかと言えば、そうではない。ディスクへの書き込み中の停電はもちろん整合性を崩すはずである。しかしその時間は極めて小さい。不整合な状態のまま動き続けるファイルシステムに比べれば遙かに安全なのは間違いない。

マニュアル[2]によると fossil サーバが故障した場合には venti サーバのデータを基に fossil は復旧可能である。(但し短期的なスナップショットは失われる。actve ファイルは最後の archive の内容である。) 逆に、venti サーバが故障した場合に fossil サーバの動作はどうなるのであろうか? この件に関しては配布文書[1]からははっきりしない。ネットワークの障害はしばしば発生することであるから、これによって fossil サーバの動作が狂うようであれば問題である。配布文書から推測されるのは、fossil サーバのディスクが十分な容量を持っていれば大丈夫なように思えるが、現在のところ筆者は実験をしていない。(筆者のサーバシステムへの本格導入の前にこの実験はしてみたい。)

セキュリティ

venti サーバ、fossil サーバ、認証サーバ、CPU サーバともに部外者を物理的にロックアウトできる場所に保管することが必要である。
venti サーバは一旦起動した後はディスクが満杯になるまで操作の必要はない。ファイルシステムの本体なので、安全な場所に保管しておけばよい。ディスクには RAID の使用が推奨される。venti サーバへのアクセスは認証を伴わない。従って venti を使用する fossil サーバを限定するのが望ましい。(でないと、データを盗み取られることはないによ、誰かがちゃっかりと venti サーバを使用していることはあり得る)
fossil サーバは一旦起動した後はめったには使用しないが、システムのアップデートやユーザ登録に際してアクセスの必要があろう。fossil サーバのディスクは一時的なバッファでありクラッシュしても容易に再構築できるので RAID を使用するほどのことはない。また大きな容量は必要ないので性能だけで選べばよい。

認証サーバと fossil サーバを兼用する場合の注意点

この場合には CPU サーバは fossil を通じて認証サーバにアクセスすることになる。CPU サーバは常にネットワークからの攻撃の危険にさらされており、CPU サーバに提供する fossil のファイルシステムのファイルは不正に書き換えられる危険性をはらんでいる。その場合でも認証システムを支えるファイルに影響を及ぼさないことが大切である。CPU サーバに提供するファイルシステムと認証サーバが働くファイルシステムを分ける注意深さが必要であろう。

参考文献