マウントポイントのディレクトリエントリがファイルシステムの通常のディレクトリエントリとどのように異なるか
ディレクトリは、「名前= iノード番号」のような行を含むファイルであることを知っています。
/home/my_file.txtのようなパスをリクエストすると、次の手順が実行されます。
- Iノード番号2に移動します（ルートディレクトリのデフォルトのiノード）
- Iノード＃2が指しているファイルを取得します。
- このファイルを検索して、「ホーム」エントリを見つけます。そのiノード番号（たとえば135）を取得します。
- Iノード＃135が指しているファイルを取得します。
- このファイルを検索して、「my_file.txt」エントリを見つけます。その245などのiノード番号を取得します。
- Iノード＃245が指しているファイルを取得します。
質問：ホームディレクトリが別のファイルシステムのマウントポイントで、別のブロックデバイスにある場合、このプロセスはどのように異なりますか？システムが理解すると、このディレクトリがマウントポイントであり、それがどのように行われるのでしょうか。この情報は、iノード、ディレクトリファイル、またはその他の場所に保存されますか？
たとえば、iノード番号が表示されたルートディレクトリリストの一部：
ls -d1i /*/
inode # name
656641 /bin/
2 /boot/
530217 /cdrom/
2 /dev/
525313 /etc/
2 /home/
393985 /lib/
ここで、ホームディレクトリとブートディレクトリはマウントポイントであり、独自のファイルシステムに存在します。私の疑似コードアルゴリズム（上記で作成）を実行し、ステップ番号3でスタックします。この場合、ホームiノード番号は2であり、別のファイルシステムと別のブロックデバイスにあります。
プロセスの説明は完全に正しくありません。
カーネルは、どのパスがマウントポイントであるかを追跡します。それがどのように行われるかはカーネルによって異なりますが、通常、情報はパスの観点から保存されます。たとえば、カーネルは「/はこのファイルシステム、/media/cdromはこのファイルシステム、/procはこのファイルシステム」などを記憶します。通常、カーネルはマウントされたファイルシステムを表すデータ構造にパス文字列をマッピングするのではなく、ディレクトリごとにテーブルを保存します。ディレクトリエントリに関連付けられたデータは、古典的にはdentryと呼ばれます。ルート用のdentryがあり、各ディレクトリには、カーネルが記憶しているそのディレクトリ内の各ファイル用のdentryがあります。 dentryには、iノード構造へのポインターが含まれ、iノードには、ファイルが存在するファイルシステムのファイルシステムデータ構造へのポインターが含まれます。マウントポイントでは、関連付けられているファイルシステムは親の歯科の関連付けられているファイルシステムとは異なり、マウントポイントを追跡するための追加のメタデータがあります。したがって、典型的なUNIXカーネルアーキテクチャでは、/のdentryには、ルートディレクトリを含むiノードへのポインタに加えて、ルートファイルシステムに関する情報へのポインタが含まれています。 /procのデントリ（マウントポイントであると想定）には、procファイルシステムなどに関する情報へのポインタが含まれています。/media/cdromがマウントポイントで/mediaではない場合、カーネルは/mediaのデントリで、忘れることはできません。それについて：/mediaについて覚えておくことは、パフォーマンスのためのキャッシュの問題だけではありません。マウントポイント/media/cdromの存在を覚えておく必要があります。
Linuxの場合、ドキュメントは カーネルドキュメント 、 このサイト およびWeb上の他の場所にあります。 Bruce Fields トピックの良いプレゼンテーションがあります。
カーネルがファイルにアクセスするように指示されると、ファイル名をスラッシュで区切られたコンポーネントごとに一度に処理し、毎回コンポーネントを検索します。シンボリックリンクが見つかった場合は、それに従います。マウントポイントが見つかった場合、実際には特別な処理は必要ありません。iノードが別のディレクトリに接続されているだけです。
このプロセスはiノード番号を使用せず、 ポインタ に従います。 iノード番号は、カーネル外の特定のファイルシステム上の各ファイルに一意のIDを与える方法です。一意のiノード番号を持たないファイルシステムがあります。ファイルシステムドライバは通常1つを構成しようとしますが、特にネットワークファイルシステムでは常にうまくいくとは限りません（たとえば、サーバーがマウントポイントを含むディレクトリツリーをエクスポートする場合、そのマウントの上下にあるiノードのセットが重複する可能性がありますポイント）。名前をiノード番号にマップする行は、ハードリンクをサポートしている場合の一般的なオンディスクファイルシステムの動作方法です。ハードリンクをサポートしないファイルシステムは、iノード番号の概念を実際には必要としません。
マウントポイントに関する情報はメモリにのみ保存されることに注意してください。ファイルシステムをマウントする場合、ファイルシステムがマウントされているディレクトリは変更されません。そのディレクトリは、マウントされたファイルシステムのルートによって隠されているだけです。
これは実装の問題であるため、一般的に答えられるかどうかはわかりません。もちろん、OSは、特定のディレクトリがマウントポイントであることを何らかの形で認識している必要がありますが、これがどのように行われるかを検討するのはOSの作成者次第です。たとえば、Linux、* BSD、Solarisなどの内部についてはわかりません。また、それらの間に類似点や相違点があるとは思いません。
推測として、{device、inode}ペア（ st_devおよびst_ino in struct stat ）。ディレクトリへのハードリンクが禁止されていると仮定すると、ディレクトリのiノードも一意の名前になります。
したがって、1つの方法は、システム内のすべてのマウントポイントのテーブルを作成することです。OSは、パスをたどるときに、すべてのディレクトリをチェックします。
システムにiノード用のある種のキャッシュがある場合（便利な最適化）、in-memoryiノード構造にフラグまたはポインタを追加してテーブル全体の検索をスキップできます。そのiノードがマウントポイントであるかどうかを確認します。