歴史とともにファイルシステムへの要請は増えつづけてきました。 大きな構造、大きなファイル、長いファイル名などなどに対する要求から、 ファイルシステムはどんどん進化し、 巨大な記憶装置へのアクセスしたり、 そのような装置を管理したりできるようになっていきました。 今日では数多くのファイルシステムを選択できるようになりました。 この章では、それらファイルシステムについて詳細に述べたいと思います。
今のところ重点は Linux にありますが、より広範な読者向けの情報も、 お寄せいただければ喜んで追加したいとおもいます。
ほとんどの OS には汎用のファイルシステムがあり、 これが大抵のファイルに対して常用されています。 このようなファイルシステムは許可属性フラグや保護・復旧など OS の機能を反映したものになっています。
minixこれは Linux が最初に用いたファイルシステムでした。 Linux がまだ minix マシンに寄生していた頃のことです。 これは単純ですが機能に制限が多いので、 今日ではレスキューディスクなどを除いてはほとんど用いられていません (レスキューディスクに用いられるのはシステムが小さいからです)。
xiafs と extfsこれらも古く、使われなくなってしまいました。 今後はお薦めできません。
ext2fs
Linux の世界で汎用ファイルシステムの標準の地位を確立している
ファイルシステムです。
ext2fs は高速で、効率が良く、成熟したシステムです。
開発もまだ継続しており、
ACL や透過圧縮機能などがそろそろ姿を現しつつあります。
より詳しい情報は、 ext2fs ホームページ を見てください。
ext3fs
これは今後 ext2fs を継承するもので、
近い将来に安定版カーネルに取り込まれます。
このために名前も変更されました。
ext2fs に対して多くの機能が追加されますが、
このような過激なアップグレードの前後で
同じ名前でありつづけるのは混乱の原因となるからです。
既に聞いたことのあるひとは多いでしょうが、
ソースコードはまだβリリースの段階です。
パッチは Linux.org から入手できます。
ufsこれは BSD やその派生システムで用いられているファイルシステムです。 成熟したシステムですが、 古いタイプのディスクドライブ向けに開発されたもので、 ジオメトリが分かっていなければ使えません。 このファイルシステムは性能を最適化するために多くのトリックを使っていますが、 ディスクジオメトリの変換方法がいくつもあるため、 実際の効果はそれほど大きなものではありません。
efsExtent File System (efs) は Silicon Graphics 社の初期のファイルシステムで、 6.0 以前の IRIX で広く使われていました (それ以降は xfs が使われるようになりました)。 xfs への移行がお薦めですが、 efs もまだサポートされていますし CD では多く使われています。
ベータ版になったばかりですが、 Linux のドライバも Linux extent file system ホームページ から入手できます。
XFSSilicon Graphics Inc (sgi) は、彼らのメインフレームグレードのファイルシステムを、 Linux へ移植し始めました。 現在彼らは法律的な厄介ごとを急ピッチで整理している 段階なので、ソースはまだ入手できませんが、これが片づけば ソースコードは GPL のもとに提供される予定です。
現在入手できる情報は、 SGI の XFS project page からどうぞ。
reiserfs
1997 年 6 月 23 日、
Hans Reiser reiser (at) RICOCHET.NET
は、彼が開発したツリーベースのファイルシステムである
reiserfs
のソースコードを web に置きました。
このファイルシステムには非常に面白い機能がいくつかあるうえ
ext2fs よりもずっと高速であるため、多くの人々が
利用するようになりました。おそらくは今年の年末にリリースされる
2.4.0 カーネルでは利用できるようになるでしょう。
enh-fsEnhanced File System プロジェクトは現在活動していません。
Tux2 fs
これは ext2fs のバリエーションで、
電力障害などの突然の割り込みにおける堅牢性を追加するものです。
このようなイベントの後には、
Tux2 fs は最近記録された整合性のとれている状態で再起動し、
fsck や他のリカバリ動作を行いません。
これを行うために、
Tux2 fs は新たに設計された
Phase ツリーと呼ばれるアルゴリズムを用いています。
より詳しい情報は プロジェクトのホームページ にあります。
この会社は多くのことに責任がありますが、 多くのファイルシステムを作り、それによって (一番穏やかな言い方でも) 混乱を引き起こしたこともそのひとつです。
fat
じつは fat には二種類あります。 fat12 と fat16
で、利用しているパーティションサイズに依存しています。
しかしこれらの違いはごくわずかですから、
幸運なら全く違いに気付かずにすむかもしれません。
長所としては、これらは速く、簡単で、 多くの OS から読み書きアクセスができます。 というかそのためだけのものですね。
欠点としては、安全性が低い、許可属性フラグが非常に少ない、
拡張性が最悪に乏しい、などが挙げられます。
例えば fat では 2 GB 以上のパーティションを扱うことができません。
fat32
およそ 10 年たって、 Microsoft は fat の問題に気付きました。
そして、あー、10 年時代を遡って、このファイルシステムを作りました。
拡張性はまあまあですけどね。
許可属性フラグは少ないままです。 NT 4.0 はこのファイルシステムを読むことができません。 Linux はできます。
vfat
Microsoft は fat32 を公開すると同時に、
長いファイル名のサポートを追加しました。
これが vfat です。
vfat タイプでマウントすれば、
Linux は vfat と fat32 のパーティションを
読むことができます。
ntfsこれは Win-NT のネイティブなファイルシステムです。 しかし完全な情報が公開されていないために、 他の OS ではほとんどサポートされていません。
これらは従来とは根本的に異なった方法でファイル更新を扱います。 ファイルの更新情報はログに記録しておき、 しばらく後のある時点で、 そのログを checkpointing する (メインの部分に反映させる) のです。
読み出しの性能は、 ファイルを直接更新する従来のファイルシステムとそれほど変わりません。 書き込みはずっと高速です。更新はログに追加されるだけだからです。 ユーザに対するインターフェースはこれまでと変わりません。 このファイルシステムは信頼性に優れ、 またファイルシステムの整合性チェックが非常に有利になっています。 最後に checkpointing を行った以前から存在するデータは正しいとみなせますから、 ログだけをチェックすれば良いわけです。 したがって従来のファイルシステムよりもずっと高速になるのです。
logging ファイルシステムはデータと inode の両方の変更を記録します。 一方 journaling ファイルシステムは inode の変更だけを記録します。
Linux ではこのようなファイルシステムに対する選択肢はたくさんありますが、 いずれも製品としてのクォリティは持っていません。 開発が止まっているものもあります。
ext3fs, XFS, reiserfs
には logging や journaling の機能があることも触れておきます。
リードオンリーのメディアも 複雑化してきたファイルシステムの例外であることはできませんでした。 したがってこの分野にも多くの選択肢があり、 頭にくるようなミスをしてしまうような可能性もあるわけです。
ext2fs も CD-ROM でちゃんとうまく動作しますし、
領域の節約になるようです。通常のファイルシステムの機能である
長いファイル名や許可属性も提供されますし、これらは
読み書き可能なメディアに対してコピーするときにも保存されます。
CD-ROM に
/dev
をつくることも可能です。
これらの多くは CD-ROM メディアで用いられていますが、 最近の DVD でも使えますし、 ハードディスクファイル上に作成した loopback デバイス (ROM を焼く前にイメージをチェックするために使います) でも用いることができます。
Linux にはリードオンリーの romfs もありますが、
これはディスク用のものではありませんので、
ここではこれ以上は触れません。
High Sierraこれは CD-ROM のフォーマットとしては最も初期に標準となったものでした。 おそらく最終的な合意が成されたホテルの名前に基づいて名づけられたのでしょう。
High Sierra にはごく限られた機能しかなかったので、
新しい拡張がなされていきました。
新しいフォーマットは続々と登場していきましたが、
オリジナルの High Sierra はそれらの共通の母体であり、
したがって現在でも広くサポートされています。
iso9660
International Standard Organization でも拡張とその標準化が行われました。
iso9660 規格として知られているものです。
Linux の iso9660 ファイルシステムは High Sierra と Rock Ridge
拡張を両方サポートしています。
Rock Ridge
短い名前や許可属性がないことに我慢していられる人たちばかりではなかったので、
Rock Ridge 拡張がこれらの欠点を補うべく早々に登場しました。
Joliet
Microsoft も、標準拡張ゲームから遅れを取らないようにすべく、
CD-ROM フォーマットを拡張して国際化の機能を付加しました。
彼らはこれを Joliet と名づけました。
Linux はこの規格を 2.0.34 以降のカーネルでサポートしています。 この機能を用いるには NLS を有効にする必要があります。
Joliet は Chicago 郊外の町です。映画 "Blues Brothers" で Jake が収監されていた刑務所があることで知られています。 Rock Ridge (ISO 9660 に対する UNIX 拡張) は、 映画 "Blazing Saddles" に出てくる (架空の) 町にちなんで名づけられました。
UDF
DVD が 18 GB もの容量とともに登場すると、
世の中にはまた別のフォーマットが必要になりました。
今度は野心的にも Universal Disk Format (UDF) という名前がつけられました。
これは iso9660 を置き換えようとするもので、
DVD にはこれが用いられるようになるでしょう。
現在のところでは標準カーネルではサポートされていません。 しかし Linux 用の UDF driver プロジェクト が進行中です。パッチと文書とが入手できます。
詳しい情報は Linux and DVDs のページからどうぞ。
ディスクをローカルな (あるいはグローバルな) ネットワークに公開することを可能にするような ネットワーク技術もたくさん存在します。 これはこの HOWTO の目的からするとおまけ的な話題ですが、 まあローカルなディスクと一緒に利用することもできるので、 簡単に網羅しておきます。 でもこれは誰かが別の HOWTO に仕立ててくれるのが一番いいでしょうね...
NFS
あるマシンのファイルスペースを他のマシンからマウントさせるための技術として、
もっとも初期からあるものです。
NFS には性能からセキュリティにいたるまで数多くの問題が存在しますが、
しかし確立された技術であることも間違いありません。
AFSこれは大きなネットワークで有効にファイルを共有するためのシステムです。 学術的なプロジェクトとしてスタートしましたが、現在では Transarc によって販売されるようにもなっています。 彼らのホームページから詳細が得られるはずです。
MIT の Derek Atkins は AFS を Linux に移植し、また Linux AFS mailing List linux-afs@mit.edu を準備してくれました。このメーリングリストは公開されています。 メーリングリストへの参加希望は linux-afs-request@mit.edu まで。またバグの報告は linux-afs-bugs@mit.edu へ送ってください。
重要: AFS は暗号化技術を使っているので、 アメリカ国外への持ち出しは許可されていません。
Transarc を保有する IBM では、 最新の Linux 向けクライアント・サーバの公開をアナウンスしました。
Arla はフリーな AFS の実装です。 詳しい情報やドキュメントは Arla homepage を参照してください。
AFS と似たネットワークファイルシステムも準備中で、これは
Coda
という名前が付いています。
これは AFS より堅牢性・耐障害性に勝るよう設計され、
モバイル動作や、切断動作にも対応しています。
今のところはあまり性能が出ていませんし、
AFS が備えている (また ARLA が備えはじめている)
管理用の適切なツールがありません。
nbdNetwork Block Device (<tt/nbd/) は Linux 2.2 以降で利用でき、非常に優れた性能を持っているそうです。 興味深いことには、 これは RAID (後述) と組み合わせることができるのだそうです。
enbd
Enhanced Network Block Device
(enbd) は nbd を改良しようとしているプロジェクトで、
block 単位でジャーナルされたマルチチャネル通信・
内部フェイルオーバー・チャネル間の自動負荷分散などの機能を
導入しようとしています。
想定されていた利用法は、ネット越しの RAID 用途です。
Global File System はワイドエリアネットワークでのストレージを目的として設計された 新しいファイルシステムです。現在はまだ初期段階で、 より詳しい情報がまた登場するでしょう。
一般的なファイルシステムに加え、より特殊なシステムも多数存在します。 より高い性能や、様々な機能を提供します (通常は他の点とのトレードオフによってですが)。
tmpfs と swapfs
一時的に利用するための高速なファイルストレージとして、
SunOS では tmpfs というものが提供されています。
NeXT の swapfs もほぼ同様のものです。
これは ufs に宿命的に存在していた速度の遅さを克服するもので、
ファイルデータのキャッシュとコントロール情報をメモリに置くものです。
したがってこのようなファイルシステム上にあるデータは
再起動時には失われます。
ですから主に /tmp 領域に向いています。
/var/tmp のデータは再起動したときにも残っている必要がありますから、
こちらには使ってはいけません。
SunOS では tmpfs に対するチューニングはほとんど行うことができません。
また総ファイル数はマシンの物理メモリによって制限されます。
Linux には同等なファイルシステムは存在しません。
多くの人は ext2fs は十分高速だと思っているので、
そのようなニーズが存在しないのでしょう。
userfs
user file system (userfs) は
従来のファイルシステムに様々な機能追加を可能にするものです。
例えば FTP ベースのファイルシステムや
圧縮機能 (arcfs)、
高速な prototyping、
他にもいろいろなものがあります。
詳しい情報は
userfs homepage
をチェックしてください。
devfs
ディスクが追加されたり削除されたり故障したりすると、
残りのディスクのディスクデバイス名が変更されてしまうことが良く起こります。
例えば sdb が故障すると、
sdc だったものが sda になり、
sda だったものが sdc になってしまったりします。
なお hda の場合には、 hdb などは変化しません。
同様に追加の際にも変化は起きません。
SCSI ID 0 が sda になるという保証はありません。
ですからディスクを大きな ID 番号に順に追加しても、
以前からのデバイス名が保存されたまま
新しいデバイス名で追加されるとは限りません。
SCSI のドライバには、 ID 0 から小さい順に割り当てを行うものと、
検索された順に割り当てを行うものが共存しているからです。
同様に SCSI ホストアダプタの追加の際にも
名前の変更が起こる可能性があります。
一般には、デバイス名は見付かった順に割り当てられます。
この問題の原因は、デバイスファイルに対する
メジャー番号・マイナー番号に用いることのできるビット桁数が
制限されていることにあります。
これらは
/dev
ディレクトリに存在し、
番号づけと割り当ての情報は man MAKEDEV から得られます。
現在のところ、この問題解決には 2 つのアプローチが取られており、
それぞれ異なる開発段階にあります。
これはドライブとそれらの位置に関する情報のデータベースを作成して動作します。
詳しい情報は man scsifs や
scsidev home page
をチェックしましょう。
これはもう少し長期的展望に立ったプロジェクトで、 デバイスの番号づけそのものを止め、 /proc のような動作をするカーネルファイルシステムとして /dev ディレクトリを使おう、というものです。 より詳しい情報が入手できるようになったら、今後この文書に追加します。
smugfs
色々な理由から、 2 GB 以上の大きさのファイルを作ることは
現在では困難です。この制限を乗り越えようと試みている
ファイルシステムの一つが smugfs です。これは非常に高速で
シンプルなものです。たとえばディレクトリはありませんし、
ブロック割り当ても単純です。
圧縮された tar 形式で ソースコード が入手できます。これは 2.1.85 版のカーネル用のものですが、 多少作業をすれば最近のカーネルに対応させることも可能でしょう。 バージョン番号が小さい (0.0) ことから、取り扱いには極めて 注意が必要かと思われます。
まさに選択肢のジャングルですが、
通常はディストリビューションで提供されている
汎用のファイルシステムを用いるのが良いでしょう。
ufs を使うとき、 tmpfs のようなものが同時に利用できる場合は、
まず汎用のファイルシステムからスタートして、
容量がどのくらい必要かを見積もり、
それに応じて tmpfs が必要とする RAM を買い足しましょう。
さもないと原因不明のクラッシュに見舞われ、
時間を無駄にすることになります。
デュアルブートマシンで、
それぞれの OS でデータを共有する必要がある場合に最も簡単なのは、
適切なサイズのパーティションを
fat でフォーマットすることです。
大抵のシステムはこのファイルシステムを安全に読み書きできるはずですから。
ただし fat パーティションには 2 GB の制限があるのを忘れないように。
ファイルシステムの相互可搬性に関する詳細は、 file system のページをチェックしてください。なおこのページは今後 file system と Kragen's Amazing List of Filesystems が継承するようです。
このガイドは HOWTO にまとめられている最中です。 完成したら、ここからもリンクする予定です。
ドライブが故障したときに、
デバイス名の変更によってシステムが災厄に襲われないようにするためには、
システムの検索順序を調べ、ルートファイルシステムを
hda か sda に保つようにし、
ZIP ドライブのようなリムーバブルメディアを検索順の最後に配置しましょう。