動画・写真などのデータを仮想化する仕組みとは？ ＝ Linuxカーネルinodeの仕組み ＝：作りながら理解するファイルシステムの仕組み（9）（1/2 ページ）

今回は、前回紹介した「dentry」が参照している、ファイルの実体「inode」について詳しく解説する！

[森 崇 株式会社 永和システムマネジメント，＠IT MONOist]

　約15年前、まだいまのような高性能なパソコンが普及する前、筆者が所属していた研究室にUNIXワークステーションが支給され、先輩が「UNIXでは、文章もディレクトリもデバイス機器も、何でもファイルなのさ！」と自慢げに教えてくれました。

　その当時は訳も分からずに使うだけでしたが、仕事でLinuxカーネルソースを読む機会に恵まれ、その仕組みから理解できるようになったときは、本当に感激でした。

　さて、今回はそのファイルの役割を担う「inode」についてお話ししたいと思います。読み方は、「i “アイ”ノード」です（注1）。

※注1：ちなみに、前回「ファイル名を管理するキャッシュdentry」で紹介した“dentry”の読み方は、「d “ディー”エントリ」でした。

　まず、図1をご覧ください。「プリンタ」「USBメモリ」「スマートフォン」「写真データ」「動画データ」「ワード文章」「ディレクトリ」「ワード文章へのショートカット」と並んでいます。

図1　inodeで管理されるもの

　読者の皆さんは、これらに共通点を見いだすことができるでしょうか？

　これらの共通した特徴は、「オペレーション」と「データ」にあります。オペレーションとしては、少なくとも以下のオペレーションのどれかを有しています。

• （1）参照する
• （2）書き込む

　これらを簡単にまとめると、表1のようになります。

種類	オペレーション	オペレーション結果
ディレクトリ	参照する	ファイル一覧が見える
	書き込む	ファイルを追加する
ショートカット （シンボリックリンク）	参照する	リンク先が見える
	書き込む	―
写真、動画、ワード文章 （通常ファイル）	参照する	写真、動画、ワード文章が見える
	書き込む	写真、動画、ワード文章が作成される
プリンタ （キャラクタデバイス）（注2）	参照する	―
	書き込む	印刷する
USBメモリ （ブロックデバイス）（注3）	参照する	USBメモリのデータが見える
	書き込む	USBメモリにデータを追加する
スマートフォン （ブロックデバイス）（注4）	参照する	端末内のSDカードの内容が見える
	書き込む	端末内のSDカードにデータを追加する
表1　ファイルのオペレーション

　それぞれオペレーションの結果は、まったく異なりますが、「参照する」「書き込む」という点では共通していますよね。

※注2：プリンタやキーボード、マウスなどを操作するためのファイルです。読み書きの操作では、1文字単位で逐次的にI/Oを行う特徴があります。このため、ランダムアクセスを行うことはできません。

※注3：ディスクをはじめとするデバイスを操作するためのファイルです。読み書きの操作では、ブロック単位で、ランダムアクセスすることができます。

※注4：この例では、Android携帯端末をパソコンとUSB接続すると、端末のSDカードのデータを操作できる場合を想定しています。

　また、データという点では、例えば「サイズ」はプリンタ以外で共通したデータといえます（表2）。

	種類	管理するサイズ
	ディレクトリ	管理しているファイル名の文字列の総和
	ショートカット （シンボリックリンク）	リンク先ファイルパスの文字列の長さ
	写真、動画、ワード文章 （通常ファイル）	写真、動画、ワード文章のサイズ
	プリンタ （キャラクタデバイス）	―
	USBメモリ （ブロックデバイス）	USBメモリのサイズ
	スマートフォン （ブロックデバイス）	端末内のSDカードのサイズ
表2　ファイルのデータ

　一般的にUNIX系のOSでは、こうしたデータとオペレーションで構成されるものを「ファイル」と呼び、Linuxカーネルではこのファイルをinodeというデータ構造で管理しているのです。

　ところで、このinodeという名前ですが、連載第2回「素晴らしきファイルシステムのデータ管理」で説明したメタデータのinodeと同じ名前で混同してしまいそうです。BSD系のOSではメタデータのinodeと区別が付くように「vnode（v “ブイ”ノード）」という名前を使っています。vは「virtual（仮想）」からきており、inodeを仮想化したデータ構造として命名されているので分かりやすいのですが、なぜかLinuxではinodeという名前になっています。いずれにしろ、Linuxの仮想ファイルシステムで使用しているinodeは、BSD系のvnodeと同じものと考えてよいでしょう。

ファイルの実体を管理するのは誰？

　inodeは、ファイルの種別を統合する管理データであることは説明したとおりですが、そのファイルの実体は、誰が管理するのでしょうか？ その管理者は、大きく分けて2つに分類されます（図2）。

図2　ファイルの実体は誰が管理する？

　ご覧のとおり、通常ファイル、ディレクトリ、シンボリックリンクの管理は「ローカルファイルシステム」です。一方、キャラクタデバイス、ブロックデバイスは「デバイスドライバ」が管理します。本連載では、ファイルシステムに主眼を置いていますので、以降はローカルファイルシステムが管理するファイルについて説明をしていきます。

　Linuxは、多数のファイルシステムをサポートしていますが、これらのファイルシステムをローカルファイルシステム（LFS）と呼びます。ローカルファイルシステムは、それぞれ独自のデータ管理をするため、通常ファイル、ディレクトリ、シンボリックリンクのデータ管理方法もさまざまです。例えば、RAMFSでは通常ファイルのデータ格納場所はメモリ上にありますが、ext4の通常ファイルのデータ格納場所はHDDなどであるため、データ格納方法および参照方法が根本的に違っています。

　inodeは、ローカルファイルシステムごとに異なるデータ管理およびオペレーションを抽象化しています。こうすることで、ローカルファイルシステム依存処理を隠ぺい化し、共通データ／オペレーションとローカルファイルシステム固有のものを分離することができます。つまり、inodeを使用するVFS層では、共通のデータ管理・オペレーションだけを考えればよくなり、LFS層では固有のデータ管理・オペレーションだけを考えればよいということになります。

inodeの構造

　図3が、Linuxカーネルのinodeの構造です。

図3　inodeの構造（1）