iノード

inode （インデックスノード）は、ファイルやディレクトリなどのファイルシステムオブジェクトを記述するUnixスタイルのファイルシステムのデータ構造です。各inodeには、オブジェクトのデータの属性とディスクブロックの場所が格納されます。^[1]ファイルシステムオブジェクトの属性には、メタデータ（最終変更時刻、^[2]アクセス、変更）、所有者および権限データが含まれる場合があります。^[3]

ディレクトリは、割り当てられた名前を持つ inode のリストです。リストには、ディレクトリ自体、その親、およびその各子のエントリが含まれます。

Linuxカーネルのメーリングリストでは、「inode」の「i」の理由について 不明な点が残っていた。2002年にこの質問がUnixの先駆者であるデニス・リッチーに持ち込まれ、彼は次のように答えた。^[4]

実のところ、私も知りません。これは、私たちが使い始めた用語にすぎません。ファイルのアクセス情報をディスク上のフラットな配列として保存し、階層的なディレクトリ情報はすべてこれとは別に保持するという、少し変わったファイル システム構造のため、「インデックス」がおそらく最善の推測です。したがって、i 番号はこの配列のインデックスであり、i ノードは配列の選択された要素です。(「i-」表記は第 1 版のマニュアルで使用されていましたが、ハイフンは徐々に削除されました。)

1978年にリッチーとケン・トンプソン が発表した論文は、「インデックス」がinodeの語源であるという説を裏付けている。彼らは次のように書いている。^[5]

[…] ディレクトリ エントリには、関連付けられたファイルの名前とファイル自体へのポインタのみが含まれます。このポインタは、ファイルのi-number (インデックス番号)と呼ばれる整数です。ファイルにアクセスすると、その i-number は、ディレクトリが存在するデバイスの既知の部分に格納されているシステム テーブル ( i-list ) へのインデックスとして使用されます。これにより見つかったエントリ (ファイルのi-node )には、ファイルの説明が含まれます。

さらに、モーリス・J・バッハは、 inodeという言葉は「インデックス・ノードという用語の短縮形であり、UNIXシステムに関する文献でよく使われている」と書いている。^[6]

ファイル システムは、ファイルの内容ではなく、ファイルに関するデータ構造に依存します。前者はメタデータ(データを説明するデータ) と呼ばれます。各ファイルは、整数 (多くの場合、 i 番号またはinode 番号と呼ばれる) で識別されるinodeに関連付けられています。

i ノードには、ファイルの所有権、アクセス モード (読み取り、書き込み、実行権限)、ファイルの種類など、ファイルとディレクトリ (フォルダー) に関する情報が格納されます。このデータは、プログラムにデータを提供するstat システム コールにちなんで、統計データと呼ばれることもあります。

inode 番号は、ファイル システム上の inode テーブルのインデックスです。inode 番号から、カーネルのファイル システム ドライバーは、ファイルの場所を含む inode の内容にアクセスでき、ファイルへのアクセスが可能になります。ファイルの inode 番号は、ls -iコマンドを使用して見つけることができます。このls -iコマンドは、レポートの最初の列に inode 番号を出力します。

多くの古いファイルシステムでは、inode はファイルシステムの作成時に設定される 1 つ以上の固定サイズの領域に保存されるため、inode の最大数はファイルシステムの作成時に固定され、ファイルシステムが保持できるファイルの最大数が制限されます。ファイルシステム内の inode の一般的な割り当てヒューリスティックは、ファイルシステムに含まれる 2K バイトごとに 1 つの inode です。^[8]

JFS、XFS、ZFS、OpenZFS、ReiserFS、btrfs、APFSなどの一部の Unix スタイルのファイル システムでは、固定サイズの inode テーブルが省略されていますが、同等の機能を提供するには同等のデータを格納する必要があります。固定サイズのテーブルの一般的な代替手段としては、B ツリーと派生B+ ツリーがあります。

ファイル名とディレクトリの意味:

• i ノードにはハード リンク名は含まれず、その他のファイル メタデータのみが含まれます。
• Unix ディレクトリは関連付け構造のリストであり、各ディレクトリには 1 つのファイル名と 1 つの inode 番号が含まれます。
• ファイル システム ドライバーは、ディレクトリ内で特定のファイル名を検索し、そのファイル名を対応する正しい inode 番号に変換する必要があります。

オペレーティング システム カーネルのこのデータのメモリ内表現は、Linuxstruct inodeでは と呼ばれます。BSD から派生したシステムでは、この用語が使用されます(「v」はカーネルの仮想ファイル システム層を指します)。 vnode

POSIX標準では、従来のUNIXファイルシステムの影響を強く受けたファイルシステムの動作が義務付けられています。inode は「ファイルシリアル番号」というフレーズで示され、ファイルシステムごとに一意のファイル識別子として定義されます。^[9]このファイルシリアル番号は、ファイルを含むデバイスのデバイス ID とともに、システム全体でファイルを一意に識別します。^[10]

POSIXシステムでは、ファイルにはシステムコールによって取得できる以下の属性^[10]statがあります。

• デバイス ID (ファイルを含むデバイスを識別します。つまり、シリアル番号の一意性の範囲です)。
• ファイルのシリアル番号。
• ファイルの種類と、ファイルの所有者、グループ、その他のユーザーがファイルにアクセスする方法を決定するファイルモード。
• inode を指すハード リンクの数を示すリンク数。
• ファイルの所有者のユーザーID 。
• ファイルのグループID 。
• デバイス ファイルの場合、ファイルのデバイス ID 。
• ファイルのサイズ（バイト単位）。
• inode 自体が最後に変更された時刻 ( ctime 、 inode変更時刻)、ファイルの内容が最後に変更された時刻 ( mtime、変更時刻)、および最後にアクセスされた時刻 ( atime、アクセス時刻) を示すタイムスタンプ。
• 推奨されるI/Oブロック サイズ。
• このファイルに割り当てられたブロックの数。

inode を使用して設計されたファイルシステムには、次の管理特性があります。

ファイルには複数の名前が付けられます。複数の名前が同じ inode にハードリンクされている場合、それらの名前は同等です。つまり、最初に作成された名前には特別なステータスはありません。これは、inode (番号) ではなく元の名前に依存する シンボリック リンクとは異なります。

inode にはリンクがない場合があります。リンクのない inode は、ファイルシステム内でそのファイルにつながるディレクトリ エントリやパスが残っていないファイルを表します。削除されたファイルや、そのファイルを指すディレクトリ エントリがないファイルは、「リンクされていない」ファイルと呼ばれます。

このようなファイルはファイルシステムから削除され、占有されていたディスク領域が再利用のために解放されます。リンクのない inode は、リンクされていないファイルによって解放されたリソース (ディスク領域とブロック) が割り当て解除されるか、ファイルシステムが変更されるまで、ファイルシステムに残ります。

リンク解除されたファイルはファイルシステム内では見えなくなりますが、そのファイルへのアクセス権を持つすべてのプロセス (ファイルを実行するプロセスによって暗黙的に開いたままになっている実行可能ファイルを含む) がそのファイルの使用を終了するまで、そのファイルの削除は延期されます。

通常、開いているファイルから、それを開くために使用されたファイル名にマップすることはできません。プログラムがファイルを開くと、オペレーティング システムはファイル名を inode 番号に変換し、その後ファイル名を破棄します。その結果、プロセスの現在の作業ディレクトリを取得するgetcwd()やgetwd()などの関数は、ファイル名に直接アクセスできません。

これらの関数は、現在のディレクトリから始めて、その親ディレクトリまで検索し、次にその親の親まで検索し、ルート ディレクトリに到達するまで検索を続けます。各レベルで、関数は、直前に移動したディレクトリの inode と一致する inode を持つディレクトリ エントリを検索します。子ディレクトリの inode は親ディレクトリのエントリとしてまだ存在しているため、関数は現在の作業ディレクトリの絶対パスを再構築できます。

一部のオペレーティングシステムでは、この操作をより高速に実行するために追加の情報を保持しています。たとえば、Linux VFSでは、^[11]ディレクトリエントリキャッシュ^[12]は、 dentryまたはdcacheとも呼ばれ、ディレクトリリンクに関する情報をRAMに保存することでファイルシステムの操作を高速化するためにカーネルによって使用されるキャッシュエントリです。

歴史的には、ディレクトリをハードリンクすることが可能でした。これにより、ディレクトリ構造は、有向非巡回グラフではなく、任意の有向グラフになりました。ディレクトリがそれ自身の親になることさえ可能でした。現代のシステムでは、ルートの親が依然としてルートとして定義されていることを除いて、この紛らわしい状態は一般的に禁止されています。この禁止の最も顕著な例外は、スーパーユーザーがディレクトリのハードリンクを作成できるMac OS X（バージョン10.5以降）にあります。 ^[13]

ファイルが同じファイル システム上の別のディレクトリに再配置された場合、またはディスクのデフラグによって物理的な場所が変更された場合、ファイルの inode 番号は変更されません。

この独自の特性により、読み取りまたは書き込み操作中でもファイルを移動したり名前を変更したりできるため、中断することなく継続的なアクセスが可能になります。

ファイルのメタデータとデータ ブロックの場所が、ファイルの名前変更や移動に関係なく、中央データ構造に保持されるというこの機能は、 FATやその派生ファイルなどの多くの非 Unix ファイル システムでは完全には再現できません。これらのシステムには、ファイルのディレクトリ エントリとそのデータの両方が同時に再配置される場合にこの不変プロパティを維持するメカニズムがないためです。これらのファイル システムでは、ファイルを移動または名前変更すると、ファイルを表すデータ構造にさらに大きな変更が生じる可能性があります。また、システムは、Unix 系システムの inode のように、ファイルのデータ ブロックの場所とメタデータの個別の中央記録を保持しません。

inode ファイル システムでは、別のプロセスが同じファイルを置き換えている間でも、実行中のプロセスがライブラリ ファイルにアクセスし続けることができます。

この操作はアトミックに実行される必要があります。つまり、他のプロセスから見える中間状態がなく、完全に完了するかまったく実行されない単一の操作として表示される必要があります。

置換中に、新しいライブラリ ファイル用に新しい inode が作成され、完全に新しいマッピングが確立されます。その後、そのライブラリに対する今後のアクセス要求では、新しくインストールされたバージョンが取得されます。

オペレーティングシステムがファイルを置き換える（そして新しいinodeを作成する）とき、inode ^[15]と場合によってはそのファイルを含むディレクトリ^{[16 ] にロック[14]}をかけます。これにより、更新操作中に他のプロセスがファイル（inode）^[17]を読み書きするのを防ぎ、データの不整合や破損を回避します。^[18]

更新操作が完了すると、ロックが解除されます。その後、プロセスによるファイルへのアクセス (inode 経由) は、ライブラリの新しいバージョンを指すようになります。これにより、ライブラリが別のプロセスで使用されている場合でも更新を実行できるようになります。

このメカニズムの大きな利点の 1 つは、現在使用中のライブラリを置き換えるためにシステムを再起動する必要がなくなることです。その結果、システムは実行中のプロセスや操作を中断することなく、ソフトウェア ライブラリをシームレスに 更新またはアップグレードできます。

ファイルシステムが作成されると、一部のファイルシステムでは固定数のinodeが割り当てられます。^[19]つまり、ファイルシステムに空き領域が残っていても、ファイルシステム上のinodeが不足する可能性があります。この状況は、電子メールメッセージを保存するサーバーなど、小さなファイルが多数あるユースケースでよく発生します。これは、各ファイルがどんなに小さくても、独自のinodeが必要になるためです。

他のファイルシステムでは、動的な inode 割り当てを使用してこの制限を回避しています。^[20]動的な inode 割り当てにより、ファイルシステムは、ファイルシステムの作成時に作成された固定数に依存するのではなく、必要に応じてより多くの inode を作成できます。 ^[21]これにより、新しいファイルとディレクトリに使用できる inode の数を増やすことでファイルシステムを「拡張」できるため、inode が不足する問題を回避できます。^[22]

非常に小さなファイルを inode 自体に保存すると、スペース (データ ブロックが不要) と検索時間 (それ以上のディスク アクセスが不要) の両方を節約できます。このファイル システム機能はインライン化と呼ばれます。したがって、最新のファイル システムを使用する場合、inode とファイル データの厳密な分離はもはや想定できません。

ファイルのデータがデータへのポインターに割り当てられたスペースに収まる場合、このスペースを便利に使用できます。たとえば、ext2とその後継では、データが 60 バイト以下の場合 (「高速シンボリック リンク」)、シンボリック リンクのデータ (通常はファイル名) をこの方法で保存します。^[23]

Ext4にはと呼ばれるファイルシステムオプションがありinline_data、ファイルシステム作成時に有効にするとext4はインライン化を実行できます。inodeのサイズは制限されているため、これは非常に小さなファイルにのみ機能します。^[24]

• NTFS には、B ツリーにファイルを格納するマスター ファイル テーブル (MFT) があります。各エントリには、このエントリを一意に参照する、inode 番号に類似した「ファイル ID」があります。^[25]エントリには 3 つのタイムスタンプ、デバイス ID、属性、参照カウント、およびファイル サイズが含まれていますが、POSIX とは異なり、アクセス許可は別の API で表現されます。^[26]ディスク上のレイアウトはより複雑です。^[27]以前の FAT ファイル システムにはこのようなテーブルがなく、ハード リンクを作成できませんでした。
  • NTFSには小さなファイルをMFTエントリにインライン化する概念もあります。^[28]
  • 派生したReFSには相同なMFTがあります。ReFSには128ビットのファイルIDがあります。この拡張機能は、元々64ビットのファイルIDを持っていたNTFSにもバックポートされました。^[26]
• 同じ統計のようなGetFileInformationByHandle APIは、クラスター共有ボリュームとSMB 3.0で使用できるため、これらのシステムはおそらくファイルIDに関して同様の概念を持っていると考えられます。^[26]

• inode ポインタ構造
• 通知

• Linux ファイルシステムの解剖
• iノードの定義
• iノード、シンボリックリンク、ハードリンクの説明