次のページ 前のページ 目次へ

5. いろいろなファイルシステム

歴史とともにファイルシステムへの要請は増えつづけてきました。 大きな構造、大きなファイル、長いファイル名などに対する要求から、 巨大な記憶装置を利用・統合できる、 より先進的なファイルシステムが登場してきました。 今日では数多くのファイルシステムを選択できるようになりました。 この章では、これらのファイルシステムについて詳細に述べたいと思います。

今のところ重点は Linux にありますが、より広い読者に向けた情報も、 お寄せいただければ喜んで追加したいと思います。

5.1 汎用のファイルシステム

ほとんどの OS には一般用途向けのファイルシステムがあり、 日常これが大抵のファイルに対して利用されています。 このようなファイルシステムは許可属性フラグや保護・復旧など OS の機能を反映したものになっています。

minix

これは Linux が最初に用いたファイルシステムでした。 Linux がまだ minix マシンに寄生していた頃のことです。 これは単純ですが機能に制限が多いので、 システムのコンパクトさから一部のレスキューディスクに用いられているのを除き、 今日ではほとんど用いられていません。

xiafsextfs

これらも古く、使われなくなってしまいました。 今後はお薦めできません。

ext2fs

Linux の世界で汎用ファイルシステムの標準の地位を確立している ファイルシステムです。 ext2fs は高速で、効率が良く、成熟したシステムです。 開発もまだ継続しており、 ACL や透過圧縮機能などがそろそろ姿を現しつつあります。

より詳しい情報は、 ext2fs ホームページ を見てください。

ext3fs

これは ext2fs の継承者となるものの名前で、 近い将来に安定版カーネルに取り込まれます。 ext2fs に対して多くの機能が追加されていますが、 このような過激なアップグレードの後で混乱を生じないよう、 名前も変更することになります。 既に聞いたことのあるひとは多いでしょうが、 ソースコードはまだβリリースの段階です。

パッチは Linux.org から入手できます。

訳注: 2.4.15 から標準カーネルにも入ったようです。

ufs

これは BSD やその派生システムで用いられているファイルシステムです。 成熟したシステムですが、 古いタイプのディスクドライブ向けに開発されたもので、 ジオメトリが分からないと使えません。 このファイルシステムは性能を最適化するために多くのトリックを使っていますが、 ディスクジオメトリが様々な方法で変換されるので、 実際の効果はそれほど大きなものではありません。

efs

Extent File System (efs) は Silicon Graphics 社の初期のファイルシステムで、 6.0 以前の IRIX で広く使われていました (それ以降は xfs が使われるようになりました)。 xfs への移行をお薦めしますが、 efs もまだサポートされていますし、 CD では多く使われています。

ベータ版になったばかりですが、 Linux のドライバも Linux extent file system ホームページ から入手できます。

XFS

Silicon 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 カーネルでは利用できるようになるでしょう。

訳注: 2.4.1 から標準カーネルに入ったようです。

enh-fs

Enhanced File System プロジェクトは現在活動していません。

Tux2 fs

これは ext2fs のバリエーションで、 電力障害などの突然の割り込みにおける堅牢性を追加するものです。 このような事態が生じた後には、 Tux2 fs は最近記録された整合性のとれている状態で再起動し、 fsck などのリカバリ動作を行いません。 これを行うため、 Tux2 fs では新たに設計された Phase ツリーと呼ばれるアルゴリズムを用いています。

より詳しい情報は プロジェクトのホームページ にあります。

5.2 Microsoft のファイルシステム

この会社は多くのことに責任がありますが、 多くのファイルシステムを作り、それによって (一番穏やかな言い方でも) 混乱を引き起こしたこともそのひとつです。

fat

じつは fat には二種類あります。 fat12fat16 で、利用しているパーティションサイズに依存しています。 しかしこれらの違いはごくわずかですから、 幸運なら全く違いに気付かずにすむかもしれません。

長所としては、これらは速く、単純で、 多くの OS から読み書きアクセスができます。 というかそのためだけのものですね。

欠点としては、安全性が低い、許可属性フラグが非常に少ない、 拡張性が最悪に乏しい、などが挙げられます。 例えば fat では 2 GB 以上のパーティションを扱うことができません。

fat32

およそ 10 年たって、 Microsoft は fat の問題に気付きました。 そして、えーと、10 年時代を遡って、このファイルシステムを作りました。 拡張性はまあまあですけどね。

許可属性フラグは少ないままです。 NT 4.0 はこのファイルシステムを読むことができません。 Linux はできます。

vfat

Microsoft は fat32 を公開すると同時に、 長いファイル名のサポートを追加しました。 これが vfat です。

vfat タイプでマウントすれば、 Linux は vfatfat32 のパーティションを 読むことができます。

ntfs

これは Win-NT のネイティブなファイルシステムです。 しかし完全な情報が公開されていないために、 他の OS ではほとんどサポートされていません。

5.3 Logging ファイルシステム・ Journaling ファイルシステム

これらは従来とは根本的に異なった方法でファイル更新を扱います。 ファイルの更新情報はログに記録しておき、 しばらく後のある時点で、 そのログを checkpoint する (メインの部分に反映させる) のです。

読み出しの性能は、 ファイルを直接更新する従来のファイルシステムとそれほど変わりません。 書き込みの方は、 更新がログに追加されるだけなので、ずっと高速です。 ユーザに対するインターフェースはこれまでと変わりません。 このファイルシステムは信頼性に優れ、 またファイルシステムの整合性チェックが非常に有利になっています。 最後に checkpoint を行った以前から存在するデータは正しいとみなせますから、 ログだけをチェックすれば良いわけです。 したがって従来のファイルシステムよりもずっと高速になるのです。

logging ファイルシステムはデータと inode の両方の変更を記録します。 一方 journaling ファイルシステムは inode の変更だけを記録します。

Linux ではこのようなファイルシステムに対する選択肢はたくさんありますが、 いずれも製品としてのクォリティは持っていません。 開発が止まっているものもあります。

ext3fs, XFS, reiserfs には logging や journaling の機能があることも触れておきます。

5.4 リードオンリーのファイルシステム

リードオンリーのメディアも、 複雑化してきたファイルシステムの例外であることはできませんでした。 したがってこの分野にも多くの選択肢があり、 頭にくるようなミスをしてしまうような可能性もあるわけです。

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 のページからどうぞ。

5.5 ネットワークファイルシステム

ディスクをローカルな (あるいはグローバルな) ネットワークに公開することを可能にするような ネットワーク技術もたくさん存在します。 これはこの 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 を参照してください。

Coda

AFS と似たネットワークファイルシステムも準備中で、これは Coda という名前が付いています。 これは AFS より堅牢性・耐障害性に勝るよう設計され、 モバイル動作や、切断動作にも対応しています。 今のところはあまり性能が出ていませんし、 AFS が備えている (また ARLA が備えはじめている) 管理用の適切なツールがありません。

nbd

Network Block Device (<tt/nbd/) は Linux 2.2 以降で利用でき、非常に優れた性能を持っているそうです。 興味深いことには、 これは RAID (後述) と組み合わせることができるのだそうです。

enbd

Enhanced Network Block Device (enbd) は nbd を改良しようとしているプロジェクトで、 block 単位でジャーナルされたマルチチャネル通信・ 内部フェイルオーバー・チャネル間の自動負荷分散などの機能を 導入しようとしています。

想定されていた利用法は、ネット越しの RAID 用途です。

GFS

Global File System はワイドエリアネットワークでのストレージを目的として設計された 新しいファイルシステムです。現在はまだ初期段階で、 より詳しい情報がまた登場するでしょう。

5.6 特殊なファイルシステム

一般的なファイルシステムに加え、より特殊なシステムも多数存在します。 より高い性能や、様々な機能を提供します。 ただし通常は他の点とのトレードオフによってですが。

tmpfsswapfs

一時的に利用するための高速なファイルストレージとして、 SunOS では tmpfs というものが提供されています。 NeXT の swapfs もほぼ同様のものです。 これは ufs に宿命的に存在していた速度の遅さを克服するもので、 ファイルデータのキャッシュとコントロール情報をメモリに置くものです。 したがってこのようなファイルシステム上にあるデータは 再起動時には失われます。 ですから主に /tmp 領域に向いています。 /var/tmp のデータは再起動したときにも残っている必要がありますから、 こちらには使ってはいけません。

SunOS では tmpfs に対するチューニングはほとんど行うことができません。 また総ファイル数はマシンの物理メモリによって制限されます。

Linux にもカーネルバージョン 2.4 以降に tmpfs 機能が加わり、 仮想メモリファイルシステムのサポート (以前の shm fs) も可能になりました。カーネルバージョンが古いと、 特定の環境下では tmpfs によってシステムが固まることがあります。 2.4.6 以降を用いるようにしてください。

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 つのアプローチが取られており、 それぞれ異なる開発段階にあります。

scsidev

これはドライブとそれらの位置に関する情報のデータベースを作成して動作します。 詳しい情報は man scsifsscsidev home page をチェックしましょう。

devfs

これはもう少し長期的展望に立ったプロジェクトで、 デバイスの番号づけそのものを止め、 /proc のような動作をするカーネルファイルシステムとして /dev ディレクトリを使おう、というものです。 より詳しい情報が入手できるようになったら、今後この文書に追加します。

smugfs

色々な理由から、 2 GB 以上の大きさのファイルを作ることは 現在では困難です。この制限を乗り越えようと試みている ファイルシステムの一つが smugfs です。これは非常に高速で シンプルなものです。たとえばディレクトリはありませんし、 ブロック割り当ても単純です。

圧縮された tar 形式で ソースコード が入手できます。これは 2.1.85 版のカーネル用のものですが、 多少作業をすれば最近のカーネルに対応させることも可能でしょう。 バージョン番号が小さい (0.0) ことから、取り扱いには極めて 注意が必要かと思われます。

5.7 ファイルシステムのお勧め

まさに選択肢のジャングルですが、 通常はディストリビューションで提供されている 汎用のファイルシステムを用いるのが良いでしょう。 ufs を使うとき、 tmpfs のようなものが同時に利用できる場合は、 まず汎用のファイルシステムからはじめて、 容量がどのくらい必要かを見積もり、 それに応じて tmpfs が必要とする RAM を買い足しましょう。 さもないと原因不明のクラッシュに見舞われ、 時間を無駄にすることになります。

デュアルブートマシンで、 それぞれの OS でデータを共有する必要がある場合に最も簡単なのは、 適切なサイズのパーティションを fat でフォーマットすることです。 大抵のシステムはこのファイルシステムを安全に読み書きできるはずですから。 ただし fat パーティションには 2 GB の制限があるのを忘れないように。

ファイルシステムの相互可搬性に関する詳細は、 file system のページをチェックしてください。なおこのページは今後 file systemKragen's Amazing List of Filesystems が継承するようです。

このガイドは HOWTO にまとめられている最中です。 完成したら、ここからもリンクする予定です。

ドライブが故障したときに、 デバイス名の変更によってシステムが災厄に襲われないようにするためには、 システムの検索順序を調べ、ルートファイルシステムを hdasda に保つようにし、 ZIP ドライブのようなリムーバブルメディアを検索順の最後に配置しましょう。


次のページ 前のページ 目次へ