素晴らしきファイルシステムのデータ管理：作りながら理解するファイルシステムの仕組み（2）（2/2 ページ）

ファイルシステムが一体どうやってデータを管理しているのか？ 単純な例を挙げながらその仕組みを詳しく解説しよう

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

データ管理情報

　ファイル、ディレクトリのデータをHDDのどこに配置するのかを管理するのは、そのデータ保持者であるinodeの役割です。そして、このデータを管理するのは、図7で示したデータ管理情報部分です。データの配置を管理するデータ構造に関しては、空きデータ管理領域のところで説明したエクステントを使うことにします。ただし、inodeに関しては、「論理オフセット」というデータを新たに追加します。

　この論理オフセットとは、ユーザーに見せるファイルのオフセットのことです。この説明だけだと分かりにくいので、例を示します。ある通常ファイルが、7kbytesのデータを保持しており、以下のようなデータが保存されているとします。

図9　通常ファイルの論理オフセット

　そして、このデータは、実はユーザーデータ領域内で下図のように3つの領域に分散配置されているとします（注10）。

図10　ユーザーデータ領域内の通常ファイルのデータの配置状況

　前回のファイルシステム操作で説明しましたが、ファイルシステムを使うと、ユーザーはHDDのどこにデータがあるのかを気にしなくて済みます。つまりユーザーは、この通常ファイルには7kbytesのデータがあり、実際にデータを読み込むときはファイルの先頭オフセット0から7kbytes分だけデータを順に読み込む操作をするだけでよいのです。これを実現するために、ファイルシステムは「ユーザーが意識するファイルのオフセット（論理オフセット）」と「実際にデータが配置されているオフセット（物理オフセット）」を管理する必要があるということです。

※注10：

この例では、データが分散配置されていますが、ファイルシステムのデータ管理としては好ましくない状態です。性能面でのデメリットとしては、データが分散配置されていると、HDDのシーク時間が増えてしまいます。また、空いている領域が連続していないので、エクステントが複数必要となってしまい、メタデータのデータ量が増えるだけでなく、その管理も複雑になってきます（思わぬファイルシステムのバグを踏んでしまうかもしれません）。こういった理由から、ファイルシステムのデフラグは定期的に行うことをお勧めします。

　これをエクステントで表現すると、以下の3つのエクステントがinodeのデータ管理情報として登録されることになります（注11）。

	inodeのエクステント	論理オフセット（block）	物理オフセット（block）	サイズ（block）
	エクステント1	0	1	3
	エクステント2	3	5	2
	エクステント3	5	8	2
図11　inodeのデータ管理情報（エクステント配置）

　ここで、ユーザーが0から7kbytesのデータの読み込み要求を行った場合のファイルシステムの処理内容を簡単に見てみましょう。

　まず、ファイルシステムは、inodeのデータ管理情報からエクステントを検索します。このときの検索キーは論理オフセットであり、論理オフセットが0から7kbytesまでを管理するエクステント（エクステント1、2、3）を見つけます。そして、これらのエクステント情報からHDDに実際に配置されているデータの場所が分かるので、ファイルシステムは、そこからデータを読み込み、ユーザーにそのデータを返します。

　これこそ、あなたの書いた・保存したデータが、HDDのどこにあるのかを気にしなくても済む仕掛けなんです！

※注11：

この例では、inodeのエクステントは単純に連続配置していますが、エクステント数が増大してくると、inodeのデータサイズ1ｋbytesだけでは不足する場合があります。このような場合は、エクステントを専用に管理するデータ領域が別に必要となってきますが、話が複雑になりますので、ここでは説明を割愛します。実際にtarファイルシステムを作るときに、この問題についてどのように対処したのかを説明する予定です。

ディレクトリデータ領域

　ディレクトリデータの役割は、ディレクトリ内に存在するファイルの名前をすべて記録することです。この際、ファイルシステムがファイル名から対象ファイルのinodeをアクセスできるように、ファイル名に対するinode番号を関連付けて管理します。

　例えば、あるディレクトリ配下に3つのファイル（ファイルA、ファイルB、ファイルC）がある場合は、図12のようなテーブルで管理されます。

	ファイル名	inode番号
	.	2
	..	1
	ファイルA	5
	ファイルB	6
	ファイルC	7
図12　ディレクトリデータ

　ディレクトリデータの中には、ファイルA、ファイルB、ファイルCのそれぞれの名前に対して、inode番号が関連付けされていることが分かります。このテーブルがあると非常に便利で、例えば、lsコマンドを実行した場合、ファイルシステムはこのテーブルの中のファイル名をすべてユーザーに返すだけで済みます。また、ファイル名から対象のinode情報を取得するには、ファイル名に対応するinode番号を参照し、そのinode番号をキーにしてinode領域を検索することで、対象のinodeを取得できるというわけです。

　なお、ディレクトリデータにはファイルA〜C以外に、“.”“..”があります。“.”については、inode構造のところで説明したとおり、このディレクトリを示しています。“..”は、このディレクトリの親ディレクトリを示しており、このディレクトリで作業しているときに、親ディレクトリに移動するときに使用されるものです（注12）。

※注12：

Linuxのディレクトリ移動コマンドとしてcdコマンドがありますが、作業ディレクトリを親にしたいとき、“cd..”と実行するのは、この理由からきています。

---

　以上で、ファイルシステムを構成するデータ管理のエッセンスは一通り説明し終わりました。このように、ファイルシステムは、あなたが快適にファイル操作できるよう見えないところでいろいろと苦労しているのです。

　さて次回からは、いよいよオリジナルのファイルシステムである「tarファイルシステム」を作っていきます。まずは、tarファイルの構造を知り、tarファイルシステムの設計方法について紹介します。また、実際にtarファイルシステムを使った感じをイメージしてもらえるように、デモ動画をお見せします。お楽しみに！（次回に続く）