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など二度と触るか)の略であるという提案がなされた。しかし、全くの嘘として退けられた。
脚注
外部リンク