File System

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp
Aichi University
Kurozasa 370, Miyoshi-cho
Aichi, Japan

 ファイルシステム 
2001/12/15 改訂
2001/06/15 改訂
2001/06/09 改訂
2001/05/26 改訂

ファイルシステムの種類
main ファイルシステム
kfs ファイルシステム
ファイルの名前規則
ファイルシステムの名前空間
ファイルのオーナーシップ
ファイルのアクセス許可

ファイルシステムの種類

Plan9 は3種のファイルシステムを持つ。ファイルサーバに2種(main と other)、端末またはCPUサーバに1種(kfs)である。(下図参照)

この内、other と kfs は簡易ファイルシステムである。

第二版までの kfs は 2GB までのサポートであったが、第三版のファイルシステムは全体が 64 ビットに統一され、その結果(貧弱だった kfs も含めて)

2**63=9223372TB(テラ)

まで扱える様になっている。

Plan9 においては、端末やCPUサーバのカーネルはネットワークを通じて取り寄せるのが標準的な使い方である。この点でX端末と似ているが、スワップ領域はローカルのディスクを使う所がX端末と異なる。

other は無くてもよい。しかし、個人のメールのように WORM に残して置きたくないファイルの入れ場所としては好ましいかもしれない。さらにユーザ none が書き込むファイルとして利用するのもよい。

Plan9 のファイルサーバは極めて安定している。これまで停電以外に落ちた事はない。安定している原因はサーバの仕事が1つだけ(ファイル処理)に限定されているからであろう。

Plan9 の main ファイルシステムの魅力は、処理速度と素晴らしいバックアップシステムである。
main ファイルシステムの設定で dump を指定しておくと、毎日バックアップが採られ(筆者のシステムでは 10分程で完了している)、そうして蓄積されたファイルを過去に遡って見る事が可能である。しかも単に個々のファイルの履歴が見えるのではない。過去の指定した日のディレクトリツリーの中身がファイルと共にそっくりそのまま見えるのである(dumpfs)。しかもコマンド1つで一瞬のうちに!

Plan9 の main ファイルシステムは以下の3種に分類される。

WORM File System
Pseudo-WORM File System
Non-Worm File System

WORM とは Write Once Read Many の意味で、光ディスクを使用した追記型の記憶媒体の事である。jukebox に入った大容量の光ディスクを使用する。(日本では手に入りにくい。)

main 型に限らず、ファイルサーバのディスクは全て SCSI を使用する。

WORM File System

WORM とハードディスクで構成される。下図に示す用にハードディスクはWORMに対するキャッシュに過ぎない。

WORMベースのファイルシステムは魅力的である。なぜなら、

追記型なので、データが消えないと言う絶対的な保証があること。
光ディスクなので大容量が可能である事。本来はjukebox タイプを使う。
メディアがドライブと分離可能なのでドライブが壊れてもメディアは生き残る事。

システムに多数のファイルがあっても実際には頻繁に使用されるのは一部のファイルだけである。殆どのファイルは休眠状態だ。WORMベースのPlan9ではハードディスクはキャッシュに過ぎないからハードディスクが一杯になれば使用頻度の低いファイルは自動的にハードディスクから外される。ユーザはディスクの節約を考えてファイルを消す必要もないし、消してもディスクの節約にはならない。

Pseudo-WORM File System

ハードディスクをWORM の代わりに使用する。このシステムでも dumpfs が利用できる。

現在では、安価で大容量の IDE ディスクが出回っている。これを WORM の代わりに使用するパッチが存在する。筆者は 40GB のIDE を WORM の代わりに使用している。(筆者の ftp サーバ(plan9.aichi-u.ac.jp) には筆者が使用しているものが置かれている。)
最新版のパッチは http://home.san.rr.com/ericdorman/idefs.tgz に置かれているので読者はこちらを取りに行くのがよいであろう。実を言えば筆者のものは不安定なのだ。半年の間に2回もクラッシュしている。

構築法

None-WORM File System

WORM の無いファイルシステムである。dumpfs は利用できない。

構築法

kfs ファイルシステム

kfs ファイルシステムはCPUサーバや Plan9 端末のローカルなファイルシステムである。

第二版までの kfs はいかにも「簡易」と言う感じであったが、第三版の kfs からはそのような印象は出てこない。64ビットで統一された、本格的なファイルシステムのように見える。それでも(あるいはそうであるからこそ?)マニュアルには kfs で満足しないで本来のものを使うように勧められている。

main ファイルシステムが存在するなら kfs はなくてもよい。筆者は CPU サーバに 8GB の kfs を置き、main ファイルシステムがクラッシュした場合に備えて毎日バックアップをとっている。Plan9 のバックアップツール(mkfs)は変更されたファイルだけをバックアップしてくれる。筆者のシステムでは kfs へのバックアップは数分程度で完了する。
main ファイルシステムがクラッシュすれば、保有していた過去の履歴は失われるがそれでも昨日の姿だけは kfs に残っている。

ファイルの名前規則

Plan9 で使用されるファイル名の最大長は大きくはない。27文字までである。開発者たちは長い名前を使用しないので必要性を感じなかったのであろうが、この長さだと他のシステムのファイルをコピーする場合に困る事がある。
(注: ファイル名の最大長は第4版で変更される予定だそうである。長い長いファイル名が許されるそうな...)

Plan9 のファイル名は空白と「/」を除く任意の UTF-8 文字コードから構成される。

UNIX ではファイル名の先頭のピリオドは特殊な意味を持ったが、Plan9 ではピリオドは単なる文字であり、なんらの特殊性も持たない。(隠しファイルと言う考え方を持たない)

ファイルシステムの名前空間

ユーザが見る Plan9 の名前空間は UNIX と同様に木構造を持ち、頂点は「/」で表される。

Plan9 ではユーザが見るファイルは必ずしもディスク内部のファイルを表していない。カーネルのサービスはファイルとして見えているし、システムサービスもまたファイルとして見えている。また mount などによって名前空間にファイルが寄せ集められ、bind によって名前空間のトポロジーが変えられる。
(もっとも UNIX においてもよく似た状況がある。)

他方ではディスクのバックアップを取る時には、ディスクの内部に存在するファイルだけをコピーする必要が発生する。UNIX においてはこれは厄介な問題である。

この問題は Plan9 では実に明快に解決されている。

ディスクファイルシステムをどこかにマウントすれば、そこにはそのディスク内部の名前空間を見ることができる。この名前空間は純粋な木構造をしている。

Plan9 には UNIX に見られるハードリンクもソフトリンクも存在しない事に注意すべきである。Plan9 の名前空間のトポロジーは bind によって変更できるが、この情報はディスクにではなく、カーネルの中に存在するのである。

筆者のファイルサーバの名称は 9fs である。

mount /srv/9fs /n/9fs

を実行すると、

/n/9fs/

にファイルサーバが管理する名前空間が見える。これはファイルサーバのディスクの名前空間である。

mount /srv/kfs /n/kfs

を実行するとローカルファイルシステムである kfs の内容が

/n/kfs/

に見える。

バックアップ作業の目標は明快である。

/n/9fs/

に見える全ての内容をそのまま

/n/kfs/

に見えるようにすることである。

ファイルのオーナーシップ

Plan9 は UNIX と同様にユーザとグループの概念を持っている。ユーザとグループを管理しているファイルは /adm/usersであり、この内容は例えば

-1:adm:adm:
0:none:adm:bootes,arisawa
1:tor:tor:
2:glenda:glenda:
9999:noworld::alice
10000:sys::
10001:upas:upas:
10002:bootes:bootes:
10003:inf::inferno
3:arisawa:arisawa:
5:alice:arisawa:

のようになっている。Plan9 ではユーザとグループは全く別のものとは考えられていない。従って一つのファイルで管理されている。

ファイルシステム毎に/adm/usersが存在し、そのファイルシステムの利用者を定めている。ファイルシステムの間で数字のユーザ ID を統一する必要は無い。

ファイルのアクセス許可

Plan9 では UNIX と同様の形式でファイルのアクセス許可ビットを立てる。例えば、

cpu% ls -l
d-rwxrwxr-x M 51334 arisawa alice         0 Nov 10  2000 T
d-rwxrwxr-x M 51334 arisawa arisawa       0 May 27 16:53 Y
--rw-rw-r-- M 51334 arisawa arisawa     984 Apr 27 10:04 u
alrw-rw-r-- M 51334 arisawa arisawa     681 May 29 14:39 v

である。

この例の最後の行の許可ビットの "a" は append-only を、"l" は lock-openを表している。

ファイルの種類を表す記号(UNIX の c,b,s,...)などはない。

Plan9 には UNIX の SETUID ビットに相当するものは存在しない。

Plan9 では、ユーザは複数のファイルシステムにアクセスする可能性がある。 Plan9 では others は、ファイルシステムを見る事のできる全てのユーザを意味している。

ファイルシステムに登録されていないユーザが、そのファイルシステムを見るのを許して良いのかと言う問題がある。第二版の Plan9 はこの問題に対して概して寛容であったが、第三版では厳しく対処しているようである。(Plan9の開発者たちはこの件に関するポリシーを表明していない。)

ファイルシステム