この記事は、Linux ファイルシステムの概念に関する非常にハイレベルな議論を意図しています。 EXT4 のような特定のファイルシステムタイプがどのように動作するかの低レベルの説明や、ファイルシステム コマンドのチュートリアルを意図したものではありません。
すべての汎用コンピューターは、ハード ディスク ドライブ (HDD) や USB メモリなどの同等物にさまざまなタイプのデータを保存する必要があります。 これには、いくつかの理由があります。 まず、RAMはコンピュータの電源を切ると内容が消えてしまいます。 電源を切った後も保存されているデータを維持できる不揮発性タイプの RAM もありますが (USB メモリやソリッド ステート ドライブで使用されているフラッシュ RAM など)、フラッシュ RAM は DDR3 やその他の同様のタイプの標準揮発性 RAM よりもはるかに高価なのです。 RAM とディスクの両方のコストは急速に低下していますが、バイトあたりのコストという点では RAM がまだリードしています。 16GBのRAMと2TBのハードディスクのコストをもとに1バイトあたりのコストを簡単に計算すると、RAMはハードディスクの約71倍もの単価がかかることが分かります。 典型的な RAM のコストは、今日では 1 バイトあたり約 0.0000000043743750 ドルです。
現在の RAM コストを考慮するための簡単な歴史的メモとして、コンピューターのごく初期に、ある種のメモリは CRT スクリーン上のドットをベースにしていました。 これは、1 ビットあたり約 1 ドルと非常に高価でした。
定義
ファイルシステムについて、多くの異なる混乱した方法で話すのを耳にすることがあるかもしれません。 この単語自体が複数の意味を持つこともあり、議論や文書の文脈から正しい意味を見分ける必要があるかもしれません。
ここでは、「ファイルシステム」という単語がさまざまな状況でどのように使用されているかを観察し、そのさまざまな意味を定義しようと試みます。 標準的な「公式」の意味に準拠しようとしながらも、私の意図は、そのさまざまな使用法に基づいてこの用語を定義することであることに注意してください。 これらの意味は、この記事の次のセクションで詳しく説明します。
- トップ (/) のルートディレクトリから始まる Linux 全体のディレクトリ構造。
- 特定のタイプのデータ記憶フォーマット。 Linux は、最新のものだけでなく、非常に古いものも含め、ほぼ 100 種類のファイルシステムをサポートしています。 これらのファイルシステムタイプはそれぞれ、データがどのように保存され、アクセスされるかを定義するために、独自のメタデータ構造を使用します。
- 特定のタイプのファイルシステムでフォーマットされたパーティションや論理ボリュームで、Linux ファイルシステム上の指定マウントポイントにマウントできます。
Basic filesystem functions
ディスク保存は必要不可欠で、いくつかの興味深い、避けられない詳細を持っています。 明らかに、ファイルシステムはデータの不揮発性ストレージのためのスペースを提供するために設計されており、それがその究極の機能です。 しかし、その要件から派生する他の多くの重要な機能があります。
すべてのファイルシステムは名前空間、つまり、命名および組織化の方法論を提供する必要があります。 これは、ファイルがどのように名付けられるか、特に、ファイル名の長さと、利用可能な文字の総セットのうちファイル名に使用できる文字のサブセットを定義する。 また、ディスク上のデータの論理構造も定義します。たとえば、ファイルを 1 つの巨大なファイルの集合にまとめるのではなく、ファイルを整理するためにディレクトリを使用するなどです。 これには、階層的なディレクトリ構造をサポートするために必要なデータ構造、ディスク上のどのブロックが使用され、どれが使用可能かを決定する構造、ファイルおよびディレクトリの名前を維持できる構造、サイズや作成、変更、最終アクセスの時間などのファイルに関する情報、ディスク上のファイルに属するデータの位置または場所などが含まれます。 その他のメタデータは、論理ボリュームやパーティションなど、ディスクの細分化された部分に関する上位の情報を格納するために使用される。 この上位のメタデータとそれが表す構造は、ドライブまたはパーティションに格納されたファイルシステムを記述する情報を含みますが、ファイルシステムのメタデータとは別個で、独立しています。
ファイルシステムは、ファイルやディレクトリなどのファイルシステムのオブジェクトを操作するシステム関数呼び出しへのアクセスを提供するアプリケーションプログラミングインターフェース (API) を必要とすることもあります。 API は、ファイルの作成、移動、および削除などのタスクを提供します。 また、ファイルがファイルシステム上のどこに配置されるかなどを決定するアルゴリズムも提供する。 そのようなアルゴリズムは、速度やディスクの断片化を最小限にするなどの目的を考慮することができます。
最近のファイルシステムは、ファイルやディレクトリへのアクセス権を定義するスキームであるセキュリティモデルも提供します。 Linux ファイルシステムのセキュリティ・モデルは、ユーザーが自分自身のファイルにのみアクセスでき、他のユーザーやオペレーティング・システム自体にはアクセスできないことを保証するのに役立ちます。 Linux では、システムとプログラマーの両方の効率を向上させる方法として、2 部構成のソフトウェア実装を使用しています。
Figure 1: Linux の 2 部構成のファイルシステム ソフトウェア実装。
この2つの部分からなる実装の最初の部分は、Linuxの仮想ファイルシステムである。 この仮想ファイルシステムは、カーネルや開発者がすべてのタイプのファイルシステムにアクセスするための単一のコマンド セットを提供します。 仮想ファイルシステムのソフトウェアは、様々な種類のファイルシステムにアクセスするために必要な特定のデバイスドライバを呼び出します。 ファイルシステム固有のデバイスドライバは、実装の第二部分である。 デバイス ドライバーは、ファイルシステムの標準コマンドを、パーティションまたは論理ボリューム上のファイルシステムのタイプに固有のコマンドに解釈します。
ディレクトリ構造
通常、非常に組織化された乙女座として、私は物をひとつの大きなバケットではなく、小さく組織されたグループに格納するのが好きです。 ディレクトリを使用することで、必要なファイルを保存し、探しているときにその場所を特定することができます。 Linux や他の多くのオペレーティング システムでは、ディレクトリはツリー状の階層で構造化できます。 Linux のディレクトリ構造は、Linux Filesystem Hierarchy Standard (FHS) で明確に定義され文書化されています。 ディレクトリにアクセスする際には，/var/log や /var/spool/mail のように，スラッシュ(/)でつながれた順次深いディレクトリ名を使用することで参照することができます．
以下の表は、標準的でよく知られ、定義されている Linux のトップレベルディレクトリとその目的の非常に簡単なリストです。
| Directory | Description |
|---|---|
| / (root filesystem) | ルートファイルシステムはファイルシステムのトップレベルディレクトリである。 他のファイルシステムがマウントされる前に、Linux システムを起動するために必要なすべてのファイルが含まれていなければならない。 残りのファイルシステムを起動するために必要な実行ファイルとライブラリをすべて含んでいなければなりません。 システムが起動された後、他のすべてのファイルシステムはルートファイルシステムのサブディレクトリとして、標準的でよく定義されたマウントポイントにマウントされます。 |
| /bin | /bin ディレクトリにはユーザの実行可能ファイルが含まれています。 |
| /boot | Linux コンピュータの起動に必要な静的ブートローダとカーネル実行ファイルおよび設定ファイルが含まれています。 |
| /dev | このディレクトリにはシステムに接続されているすべてのハードウェアデバイスのためのデバイスファイルが入っています。 これらはデバイスドライバではなく、コンピュータ上の各デバイスを表し、それらのデバイスへのアクセスを容易にするファイルです。 |
| /etc | ホストコンピュータのローカルシステム構成ファイルを含みます。 |
| /home | ユーザーファイルのホームディレクトリ保存。 各ユーザーは、/home にサブディレクトリを持ちます。 |
| /lib | システムの起動に必要な共有ライブラリファイルを含みます。 |
| /media | USBメモリなどの外部取り外し可能メディア装置をマウントする場所であり、ホストと接続されることがあります。 |
| /mnt | 管理者がファイルシステムを修復または作業している間に使用できる、通常のファイルシステム用の一時マウントポイント (リムーバブルメディアではない場合) です。 |
| /opt | ベンダーが提供するアプリケーションプログラムなどのオプションのファイルは、ここに配置されるべきです。 ルートユーザのホームディレクトリです。 |
| /sbin | システムのバイナリファイルです。 システム管理のための実行ファイルです。 |
| /tmp | 一時的なディレクトリです。 オペレーティングシステムと多くのプログラムが一時ファイルを保存するために使用します。 ユーザはここに一時的にファイルを保存することもできます。 |
| /usr | これらは共有可能な読み取り専用ファイルで、実行バイナリやライブラリ、マニュアルファイル、および他のタイプのドキュメントを含んでいます。 これには、ログファイル、MySQL、およびその他のデータベースファイル、Web サーバーのデータファイル、電子メールの受信トレイなどが含まれます。 |
表 1 に示すディレクトリとそのサブディレクトリ、および背景色が茶色のものは、ルートファイルシステムの重要部分と見なされています。 つまり、これらは別のファイルシステムとして作成し、スタートアップ時にマウントすることはできない。
/media、/mnt ディレクトリは、ルートファイルシステムの一部ですが、決してデータを含んでいてはいけません。
残りのディレクトリ、表 1 で背景色がないものは、起動シーケンス中に存在する必要はありませんが、ホストが有用な作業を行うための準備を行う起動シーケンス中に、後でマウントされることになります。 WikipediaにもFHSの良い説明があります。 この標準は、運用と機能の一貫性を確保するために、可能な限り忠実に従うべきです。 ホスト上で使用されているファイルシステムの種類に関係なく、この階層的なディレクトリ構造は同じです。
Linux unified directory structure
いくつかの非 Linux PC オペレーティングシステムでは、複数の物理ハードドライブまたは複数のパーティションがある場合、各ディスクまたはパーティションにはドライブ文字が割り当てられています。 これは、ファイルやプログラムが C: や D: など、どのハード ドライブにあるのかを知るために必要なことです。 そして、そのドライブレターをコマンドとして発行し、例えばD:ならD:ドライブに変更し、cdコマンドで正しいディレクトリに移動して目的のファイルを探します。
Linux ファイルシステムは、すべての物理的なハードドライブとパーティションを単一のディレクトリ構造に統一しています。 これは、すべてトップ-ルート (/) ディレクトリから始まります。 他のすべてのディレクトリとそのサブディレクトリは、単一のLinuxルートディレクトリの下に配置されます。
これは、/home、/tmp、/var、/opt、または /usr などのファイルシステムを別の物理ハードドライブ、別のパーティション、または /（ルート）ファイルシステムとは別の論理ボリュームに作成し、ルートファイルシステムツリーの一部としてマウントポイント（ディレクトリ）にマウントできることでのみ機能します。 USB サム ドライブ、外付け USB または ESATA ハード ドライブなどのリムーバブル ドライブもルート ファイルシステムにマウントされ、そのディレクトリ ツリーの不可欠な一部となります。
これを行う良い理由の 1 つは、Linux ディストリビューションのあるバージョンから別のバージョンへのアップグレード時、またはあるディストリビューションから別のものへ変更する時に明らかになります。 一般的に、そして Fedora の dnf-upgrade のようなアップグレードユーティリティは別として、アップグレード中にオペ レーティングシステムを含むハードドライブを時々再フォーマットして、長い間蓄積されたゴミを積極的に 取り除くのは賢明なことでしょう。 もし /home がルートファイルシステムの一部であれば、同様に再フォーマットされ、バックアップから 復元する必要があります。 home を別のファイルシステムとして持つことで、インストールプログラムに別のファイルシステムとして認識され、フォーマットをスキップすることができます。 これは、データベース、電子メール受信箱、ウェブサイト、および他の可変ユーザーとシステム・データが格納されている /var にも適用できます。
Linux ディレクトリ・ツリーの特定の部分を別のファイルシステムとして維持する他の理由があります。 たとえば、昔、必要な Linux ディレクトリをすべて / (ルート) ファイルシステムの一部として持つことにまつわる潜在的な問題をまだ認識していなかったとき、非常に大きなファイルを大量に置いてホーム ディレクトリをいっぱいにしてしまったことがあります。 ホームディレクトリも/tmpディレクトリも独立したファイルシステムではなく、単にルートファイルシステムのサブディレクトリなので、ルートファイルシステム全体が一杯になってしまったのです。 オペレーティングシステムが一時ファイルを作成したり、既存のデータファイルを拡張したりする余地は残っていなかった。 最初は、アプリケーション・プログラムが「ファイルを保存する場所がない」と文句を言い始め、その後、OS自体が非常におかしな動作をするようになった。 シングルユーザーモードで起動し、ホームディレクトリにある問題のあるファイルを消去すると、再び動き出すことができました。 その後、ごく標準的なマルチファイルシステム設定を使用して Linux を再インストールし、完全なシステムクラッシュが再び起こるのを防ぐことができました。
以前、Linux ホストが実行し続け、GUI デスクトップを使用してユーザーがログインできない状況になったことがあります。 ローカルでは仮想コンソールの 1 つを使用してコマンド ライン インターフェイス (CLI) を使用してログインでき、リモートでは SSH を使用してログインすることができました。 問題は、/tmpファイルシステムが一杯になり、GUIデスクトップが必要とするいくつかの一時ファイルがログイン時に作成できなくなったことでした。 CLIでのログインでは、/tmpにファイルを作成する必要がないため、そこに容量がなくてもCLIでのログインを妨げることはありませんでした。 この場合、/tmpディレクトリは独立したファイルシステムであり、/tmp論理ボリュームが属するボリュームグループには十分な空き容量があったのです。 私は、そのホストで必要な一時ファイルスペースの量を新たに理解し、それに対応するサイズに/tmp論理ボリュームを拡張するだけで、問題は解決しました。 4881>
別の状況は、私がある大きなテクノロジ企業でラボ管理者として働いていたときに発生しました。 開発者の 1 人がアプリケーションを間違った場所 (/var) にインストールしていました。 そのアプリケーションは、/var ファイルシステムが満杯で、そのファイルシステムの /var/log に格納されているログ ファイルが、容量不足のために新しいメッセージを追加できないためにクラッシュしていました。 しかし、重要な/（ルート）ファイルシステムと/tmpファイルシステムが一杯にならなかったため、システムは稼働し続けました。 問題のアプリケーションを削除し、/opt ファイルシステムに再インストールすることで、この問題は解決しました。
Filesystem types
Linux は約 100 パーティションタイプの読み込みをサポートしていますが、作成および書き込みができるのはそのうちの数パーセントだけです。 しかし、同じルートファイルシステムに異なるタイプのファイルシステムをマウントすることは可能であり、非常に一般的なことです。 ここでいうファイルシステムとは、ハードディスクや論理ボリュームのパーティションにユーザーデータを保存・管理するために必要な構造やメタデータのことを指します。 Linux の fdisk コマンドが認識するファイルシステム・パーティションタイプの完全なリストは、Linux が非常に多くの種類のシステムと高い互換性を持っていることを感じていただけるよう、ここで提供されています。 Fedora で新しいファイルシステムを作成するときに利用可能な選択肢は、以下のリストに示されています。
- btrfs
- cramfs
- ext2
- ext3
- ext4
- fat
- gfs2
- hfsplus
- minix
- msdos
- ntfs
- reiserfs
- vfat
- xfs
を選択。
他のディストリビューションは異なるファイルシステムタイプの作成をサポートしています。 例えば、CentOS 6 では、上記のリストで太字で強調されているファイルシステムのみを作成しています。
Mounting
Linux でファイルシステムを「マウントする」という言葉は、テープや取り外し可能ディスクパックを適切なドライブデバイスに物理的にマウントする必要があった、コンピューターの初期時代にさかのぼります。 物理的にドライブに置かれた後、ディスク パック上のファイルシステムは OS によって論理的にマウントされ、OS、アプリケーション プログラム、およびユーザーによってコンテンツがアクセス可能になります。
マウント ポイントは単にディレクトリで、他のものと同様にルート ファイルシステムの一部として作成されます。 したがって、たとえば、ホームファイルシステムは、ディレクトリ /home にマウントされます。 ファイルシステムは他の非ルートファイルシステムのマウントポイントにマウントすることができますが、これはあまり一般的ではありません。
Linux ルートファイルシステムは、起動シーケンスの非常に早い段階で、ルートディレクトリ (/) にマウントされます。 他のファイルシステムは、Linux のスタートアップ・プログラム、SystemV では rc、より新しい Linux リリースでは systemd によって、後からマウントされます。 起動時のファイルシステムのマウントは /etc/fstab 設定ファイルによって管理されます。 fstab は “file system table” の略で、マウントされるファイルシステム、指定されたマウントポイント、特定のファイルシステムに必要なオプションのリストです。
ファイルシステムは mount コマンドを使って既存のディレクトリ/マウントポイントにマウントされます。 一般的に、マウントポイントとして使用されるディレクトリは空であるべきで、その中に他のファイルが含まれていてはいけません。 Linux は，既に存在するファイルシステムの上にファイルシステムをマウントしたり， ファイルを含むディレクトリにマウントすることを妨げません． 既存のディレクトリやファイルシステムにファイルシステムをマウントすると、元のコンテンツは隠され、新しくマウントされたファイルシステムのコンテンツのみが表示されます。
Conclusion
この記事により、ファイルシステムという用語を取り巻く混乱がある程度解消されたことと思います。 Linux ファイルシステムの複雑さ、優雅さ、および機能性をそのすべての意味において本当に理解し、感謝するためには、長い時間と非常に有益な指導者が必要でした。 この概念は、ユーザーやシステム管理者にとって、興味深く重要な実用的アプリケーションをいくつか持っています。 なぜこのことを述べるかというと、来月予定している /dev ディレクトリに関する記事の前に、「Everything is a file」の記事を読んでおくとよいからです
。