inode

inode（アイノード）は、ext2などのUnix系ファイルシステムで古くから使われているデータ構造である。inode にはファイル、ディレクトリなどのファイルシステム上のオブジェクトに関する基本情報が格納される。

ReiserFSなどの最近のUnix系ファイルシステムでは inode を使用していないが、同等の機能を提供するには同等の情報をどこかに格納しなければならない。statシステムコールがそれらのデータをプログラム向けに提供するので、これを statデータと呼ぶことがある。

概要

Linuxでは、このようなデータのカーネルでのメモリ上の表現を struct inode と呼ぶ。BSD系システムでは vnode と呼ぶが、この vnode の v はカーネル内の 仮想ファイルシステム層から来ている。

POSIX標準で規定されているファイルシステムの動作は従来からのUNIXファイルシステムに大きく影響されている。通常ファイルは以下のような属性を持つことを要求されている:

• ファイルの長さ（バイト数）
• デバイスID（ファイルを格納しているデバイスを識別）
• ファイル所有者のユーザーID
• ファイルのグループID
• ファイルシステム内でファイルを識別する inode 番号
• ファイルモード（ファイルパーミッション）
• 最終 inode 更新時(ctime)、最終ファイル更新時(mtime)、最終参照時(atime) を示すタイムスタンプ群
• その inode を指すハードリンクがいくつあるかを示す参照カウント

inode という用語はブロックデバイス上の inode も意味し、通常ファイルやディレクトリや場合によってはシンボリックリンクにも対応している。この概念は破損したファイルシステムのリカバリにおいて特に重要である。

inode 番号は、その inode が記録されているデバイス上で一意の整数値である。全てのファイルは inode に物理的にリンクされている。プログラムがファイルをファイル名で参照するとき、システムはそのファイル名に対応する inode を検索する。

statシステムコールはファイルの inode 番号やその他の inode 内の情報の一部を得る機能である。

inode の i が何を意味するのかは不明確である。UNIXの開発者デニス・リッチーは、それを聞かれたとき以下のように述べている:

実際、私にもわからない。我々が使い始めたときは単なる用語だった。たぶん "index" が元になっているんじゃないかと思う。というのはちょっと変わったファイルシステム構造があって、ディレクトリを使った階層構造があるのに全てのファイルのアクセス情報をディスク内のフラットな配列に格納していたんだ。だから i-number というのはその配列のインデックスで、i-node はその配列の要素だろう。（"i-" という書き方は初版のマニュアルで使われていたが、徐々にハイフンが無くなっていった）。

inodeを使用したファイルシステムでのファイルの構造図

関連

ファイルシステムに慣れていないユーザーの多くは、inode のコンセプトを利用するファイルシステムの特性に驚く。

• 複数の名前が同じ inode にリンクしていると（ハードリンク）、どの名前も等価と言える。ファイルを最初に作成したときの名前は特別な意味を持たない。これはシンボリックリンクがオリジナルの名前に依存しているのと全く異なる。
• リンクを全く持たない inode もありうる。通常そのようなファイルはディスクから削除され、そのリソース（ディスクブロック）はファイル削除処理の過程で再利用のために解放されるが、何らかのプロセスがそのファイルを使用中ならば、アクセスし続けることができ、最後にクローズされるときに削除処理が行われる。このため、プログラムを改版（リコンパイル）するときは、以前の実行ファイルをまず削除して、新しい版の実行ファイルは新たな inode で作成されるようにすることが推奨される。これにより、古い版が実行中であっても何ら問題なく処理を続行することになる。（訳注：削除しないで上書きすると、実行中の実行ファイルが書き換えられるため、メモリ管理の実装によってはおかしな状態が発生する）。
• 従来、オープン中のファイル（ファイル記述子）からオープンされたファイル名を得ることはできなかった。オペレーティングシステムは一度ファイル名を inode番号に変換すると、ファイル名の方を忘れてしまう。従って、getcwd() や getwd() といったライブラリ関数は "." ディレクトリに対応する inode 番号からその親ディレクトリを捜し、最終的に "/" ディレクトリまでたどることでフルパス名を得ている。この無駄な処理を省くため、SVR4 や Linux システムは追加情報を保持している。
• ディレクトリのハードリンクは古くから可能だった。これによりディレクトリ構造は木構造ではなく任意の有向グラフとなっている。あるディレクトリを自身の親ディレクトリとすることも可能である。最近のシステムではそのような混乱の元となる状態を防ぐようになっている。

実用上の考慮

UNIXオペレーティングシステムのシステムアドミニストレータが使用するプログラムには、ファイルを特定するために inode 番号を表示するものがある。ハードディスクの健全性チェックユーティリティのfsckやpfilesがそのようなコマンドの例である。そこで inode 番号をファイルのパス名に変換する（およびその逆変換をする）必要が生じる。これはファイル名検索ユーティリティ find（の -inum オプション）や ls コマンドに適当なオプション（多くの場合 -i）を付けることで実現される。

また、「ファイルが削除された際に何らかのプロセスがそのファイルを使用している場合、そのプロセスからはアクセスが継続できる。」という特徴がセキュリティ上問題となる場合がある。例えば、多くのプロセスが参照しているライブラリのセキュリティアップデートを適用した後、当該プロセスからは旧バージョンのライブラリにアクセスし続けるため、脆弱性が完全に修正されないという事態が発生する。したがって、特にシステムの中核に位置するようなライブラリをアップデートした際には動作上問題がなくてもシステムを再起動する等の対策が必要となってくる。

トリビア

International Association of Computer Investigative Specialists (IACIS[1])の2003年の会議で、"inode" は "I'm Not Operating DOS Ever"（DOSなど二度と触るか）の略であるという提案がなされた。しかし、全くの嘘として退けられた。

外部リンク

• The Linux Virtual File-system Layer: Inodes and Operations - Linuxでのinode（英語）