第7回 HFS、HFS Plusの基本的概念【前編】：Undocumented Mac OS X（2/4 ページ）

[白山貴之，ITmedia]

HFS Plusの基本構造

　先に挙げたいきさつから分かるように、HFS Plusは、NeXTSTEPをベースとしたRhapsodyやその後継であるMac OS Xとはまったくかかわりのない*、純粋にCoplandの遺産とも言えるファイルシステムである。Copland自体は失敗したプロジェクトだが、HFS Plusに込められた技術は捨てたものではない。エクステントやカタログノードといった、ファイルサイズの大きなファイルを管理するのに有利な構造を持っており、このためMac OS Xでも継続してネイティブファイルシステムとして採用されることとなった。

エクステント

　HFS Plusではエクステントという単位がファイルの基本構造となっている。HDDやMOなど、ディスク上のHFS Plusボリュームは512バイトのセクタ、そしてそのセクタを幾つか集めた「アロケーションブロック」という単位に分けられ、それぞれに順に番号（アロケーションブロック番号）がつけられる。

　エクステントは「どのアロケーションブロックから」開始し、「何ブロック使っているか」を記録したものだ。HFS Plusではファイルの中身はこのエクステントの集まりとして表現される（図1）。

図1　エクステントによる管理の場合、連続するアロケーションブロックをひとまとめに管理できる。このため、効率の良い直接参照だけでもより大きなファイルを扱える

　iノードによる管理の場合1つのブロックのサイズは固定で、ファイルサイズが大きくなればなるほど管理に必要なiノードや間接参照が増えて、処理が遅くなっていく（図2）。このアロケーションブロックの場合は、連続する領域が取れる限り1つのエクステントでまかなえるため、直接参照でより大きなファイルが管理できる。

図2　UFS系のファイル管理。UNIX系のファイルシステムで使われているiノードによる管理では、iノード内に固定サイズのブロックへの参照が記録される。参照の数が多くなりiノードに収まりきれなくなると、別のiノードを使用して間接的な参照を行う。ファイルが大きくなればなるほど間接参照の段数が増え、データアクセスの効率が落ちていく

　エクステントで効率的に管理しようとすると、自然とデータが連続して並ぶようになるためアクセス性能が向上するという副次的効果がある。

　UNIXでは、通常ファイルの中身といえば単一のバイト列だ。つまり、リスト1のようなコードを用意し実行すると、ファイルの内容が先頭から最後まですべて読み取れることが保証される。

int c ;
FILE *fp = fopen( "/path/to/file", "r" );
while( EOF != ( c = fgetc( fp ) )
{
  fputc( c, stdout );
}

リスト1　ファイルの内容（バイト列）読み取り用サンプル

　しかしHFS Plusではそうではない。ファイルには、通常のデータ本体とは別のバイト列を格納できる。こうした領域のことをフォークと呼び、データ本体に当たるフォークは「データフォーク」という。またMac OSでは、アプリケーションが使う画像やウインドウの定義などを別の領域に格納しており、この領域を「リソースフォーク」という。旧来のHFSでは、ファイルはこの2つのフォークのみで構成されており、直接参照用にそれぞれ3つのエクステントが用意されている。HFS Plusではそれぞれ8つのエクステントが用意されており、さらにこの2つのフォーク以外のフォークを生成することもできる*構造になっている。

このページで出てきた専門用語

まったくかかわりわりのない

Rhapsodyは、HFS PlusにOSをインストールできなかった。このため、Rhapsodyのインストール用にUFSパーティーションを用意し、従来のMac OSとの互換環境であるBlueBoxのためにHFSないしはHFS Plusパーティーションを別途用意する必要があった。

この2つのフォーク以外のフォークを生成することもできる

データフォークとリソースフォーク以外のフォークはカタログファイルではなくアトリビュートファイル（別の回で解説予定）に別途記録される。