私はディレクトリが "name = inode number"行を含むファイルであることを理解しています。
/home/my_file.txt などのパスを要求すると、次の手順が実行されます。
- inode 番号 2 に移動 (ルート ディレクトリのデフォルト inode)
- inode＃2が指すファイルを取得します。
- ファイルを検索して「home」エントリを見つけます。対応する inode 番号 (例: 135) を取得します。
- inode＃135が指すファイルを取得します。
- ファイルを検索して「my_file.txt」エントリを見つけます。対応する inode 番号 (245 など) を取得します。
- inode #245 が指すファイルを取得します。
質問：ホームディレクトリが別のブロックデバイス上の他のファイルシステムのマウントポイントである場合、プロセスはどう違いますか？システムがこのディレクトリがマウントポイントであることがわかったらどうなりますか？この情報はどこに保存されていますか？ inode、ディレクトリファイル、または別の場所ですか？
たとえば、私のルートディレクトリリストの一部にはinode番号が表示されます。
ls -d1i /*/
inode # name
656641 /bin/
2 /boot/
530217 /cdrom/
2 /dev/
525313 /etc/
2 /home/
393985 /lib/
ここで、ホームディレクトリとブートディレクトリはマウントポイントであり、独自のファイルシステムにあります。上記の擬似コードアルゴリズムを実行し、手順3で停止します。この場合、デフォルトのinode番号は2で、他のファイルシステムとは異なるブロックデバイスにあります。
答え1
プロセスの説明が正しくありません。
カーネルは、どのルートがマウントポイントかを追跡します。これが行われる正確な方法はカーネルによって異なりますが、通常、情報はパス形式で保存されます。たとえば、カーネルは「/このファイルシステム、/media/cdromこれはファイルシステム、/procこれはこのファイルシステムです」などを覚えています。通常、カーネルはマウントされたファイルシステムのデータ構造を表すテーブルにパス文字列をマッピングするのではなく、各ディレクトリのテーブルを格納します。ディレクトリエントリに関連するデータディレクトリエントリ。ルートディレクトリのディレクトリエントリがあり、各ディレクトリでは、カーネルはそのディレクトリ内の各ファイルのディレクトリエントリを記憶します。 dentryにはinode構造へのポインタが含まれ、inodeにはファイルを含むファイルシステムのファイルシステムデータ構造へのポインタが含まれています。マウントポイントで関連付けられたファイルシステムは親ディレクトリエントリのファイルシステムとは異なり、マウントポイントを追跡するための追加のメタデータがあります。したがって、一般的なUnixカーネルアーキテクチャでは、dentryには/ルートディレクトリのinodeポインタに加えて、ルートファイルシステム情報へのポインタが含まれています/proc（マウントポイントであると仮定）。 procファイルに関する情報へのポインタが含まれています。システムなどのポインター。/media/cdromマウントポイントですが、そうでない場合、/mediaカーネルはそれをdentryに覚え/mediaて忘れてはいけません。/media単にパフォーマンスのためのキャッシュの問題ではなく、マウントポイントの存在を覚えておく必要があります/media/cdrom。
Linux の場合、次の文書を見つけることができます。カーネル文書、このウェブサイトからそしてウェブの他の場所でも。ブルースフィールドトピックの良い紹介です。
カーネルがファイルにアクセスするように指示されたら、ファイル名を一度にスラッシュで区切られたコンポーネントを1つずつ処理して、そのコンポーネントを検索します。シンボリックリンクを見つけたら、それに従います。マウントポイントを見つけると、実際に特別な処理は必要ありません。 inodeを別のディレクトリに追加するだけです。
このプロセスでは、次のように inode 番号を使用しません。針。 Inode番号は、ディスクとアプリケーションの両方で、カーネルの外側の指定されたファイルシステム内の各ファイルに一意のIDを提供する方法です。一部のファイルシステムには固有のinode番号がありません。ファイルシステムドライバはしばしばそれを設定しようとしますが、常に動作するわけではありません。特に、ネットワークファイルシステムの場合（たとえば、サーバーがマウントポイントを含むディレクトリツリーをエクスポートする場合など）、マウントの下のinodeセット間に重なりがある可能性があります。名前をinode番号にマップする行は、通常のディスクファイルシステムが機能する方法です（ハードリンクをサポートしている場合）。実際には、inode番号の概念は必要ありません。
マウントポイントに関する情報はメモリにのみ保存されます。ファイルシステムをマウントすると、ファイルシステムがマウントされたディレクトリは変更されません。このディレクトリは、マウントされたファイルシステムのルートにのみ隠されています。
答え2
実装問題なので普遍的に答えられるかもしれません。もちろん、オペレーティングシステムは与えられたディレクトリがマウントポイントであることを何とか知る必要がありますが、オペレーティングシステムの作成者はこれがどのように達成されるかを考えなければなりません。私はLinux、* BSD、Solarisなどの内部構造を知りません。
推測では、{device、inode}ペア（st_devst_inoそしてstruct stat）。ディレクトリへのハードリンクが無効になっていると仮定すると、ディレクトリinodeも一意の名前を持ちます。
したがって、1つのアプローチは、システム上のすべてのマウントポイントのテーブルを作成し、オペレーティングシステムがパスをナビゲートするときに各ディレクトリを確認することです。
システムに一種のinodeキャッシュ（有用な最適化）がある場合は、次のようにできます。記憶の中inode構造を使用して、inodeがマウントポイントであることを確認します。
答え3
ファイルシステムが特定のマウントポイントにマウントされると、オペレーティングシステムはマウントされたファイルシステムからスーパーブロックを読み取り、メモリにロードします。スーパーブロックには、とりわけそのファイルシステムルートのinodeに関する情報が含まれています。
上記のポイントは正しいです。オペレーティングシステムのデータ構造は、マウントされたすべてのファイルシステムの履歴を保持し、他のファイルシステムが/ home /にマウントされている場合は、そのファイルシステムのスーパーブロックを照会してルートディレクトリのinode番号を取得します。