INDEX（Topページ） | News & Topics | Glossary | Column List | GuestBook | Link & Profile

Mac OS Xにおけるファイルシステム事情〜32bitファイルシステム「HFS Plus（Mac OS拡張フォーマット）」〜

Classic Mac OS時代に「System 3.x」が稼働していた80年代中盤、従来までのフラットなファイルシステム「MFS（Macintosh File System）」を拡張した形にて登場した「HFS（Hierarchical File System）フォーマット（Mac OS標準フォーマット）」。このHFSフォーマットが「Mac OS 8.1」から更に上位互換（注１）の「HFS Plus（Mac OS拡張フォーマット、Sequoia）」に拡張され、Mac OS X時代に入ると「Mac OS X 10.2.2」より可用性（Availability）に重きをおいたジャーナリングファイルシステムにも対応し、現在に至っています。今回からは数回に渡ってこれらのファイルシステムの仕様等について、様々な角度から考察していきたいと思います。

●16bitから32bitへ、歴史上の大きなターニングポイント

1998年に発表されたMac OS 8.1は、8.0からのリビジョンアップであるにも関わらず、HFS Plus（Mac OS拡張フォーマット）と名付けられた新しいファイルシステムをサポートした事により、Mac OSの歴史上における大きなターニングポイントとして位置付けられています。この新しいファイルシステムHFS Plusは、従来までのHFS（Mac OS標準フォーマット）がディスク上のリソースを16bitで管理していたのに対し、その構造を32bitに対応させた事により、ディスク（ファイル）管理における様々な制限を飛躍的に拡張させる事に貢献しました。

因にこの「〜bit」という単位は、コンピュータを扱っていく上で頻繁に耳にする用語だと思います。身近な例で言うとAppleがPowerMac G5を発表した際、使用されているIBM製「PowePC 970」が64bitアーキテクチャをサポートしている事による「64bit時代の幕開け」と「無限の可能性」が報じられた時に脚光を浴びていたかと思いますが、まずはこの「〜bit」とは何を示す数値なのか？或いは数値が上がると何が違ってくるのか？といった事を、ファイルシステムと絡めて考えていきたいと思います。

コンピュータ（CPU）というのは既知の通り「０」か「１」、つまりシロかクロでしか物事を判断できません。このような数値の扱い方は「２進数」と呼ばれ、普段日常的に使われる「10進数」が０〜９まで、つまり９に１を加算した時点で桁上がりするのに対し、２進数は１に１を加算にた際に次の桁に桁上がりします（１桁につき２種類の数値しか表現できない）。そしてこの仕様（２進数）で16桁までの数値を扱う事ができるのが16bit、32桁まで扱う事ができるのが32bit、64桁まで扱う事ができるのが64bitという事になり、言い換えると「コイン64枚を同時に投げた際の表裏の組合わせのパターン数」が64bitで扱える数値パターン数という事ができます。そしてこれらが実際にどの位の数値を扱えるのかというと、

となっています。先程も例に挙げたPowePC G5による64bitプロセッシングサポート時に比較対象として語られた「32bitプロセッシング（アドレッシング）によるメモリ管理の上限＝4GB」というのは32bitが扱える数値（約43億）（注２）をそのままbyte（ブロック）数に当てはめた「約40億byte＝約4GB」という計算からきています（逆から考えると4GBの領域には1byte毎に２の32乗個の領域が存在し、これを識別するためには同数のアドレスが必要となります。そしてこの２の32乗個のアドレスを２進数で表現しようとした場合には32桁の数値が必要となるため、4GBの領域を管理するには32bitアドレッシングが必要と考える事ができます）。尚、64bitプロセッシングでは理論上「２の64乗byte=16EB（エクサバイト）=約170億GB」という天文学的な容量の物理メモリを管理する事が可能となっており、このようなシステムが近未来に登場する見込みは、現時点では考えられません。このあたりのbitと数値の相関は、計算機（/Applications/Calculator.app）から「表示」>「プログラマ」とする事により、各進数におけるbit列の対応状況等を確認する事ができます。
計算機におけるプログラマモード
↑計算機のプログラマモードで、２進数32bitの最大数を10進数で表示したところ。プログラマモードでは他にも論理演算やシフト演算等もサポートしている

そしてこれらの数値をファイルシステムに当てはめて考えた場合、１つのボリュームに割り振る事のできるアロケーションブロック（注３）の数、つまり１ボリュームで扱えるファイル数に大きな違いが出る事となります。具体的には16bitをサポートするHFS標準ではボリュームの容量に関わらず、１ボリュームを理論上で最大65,536分割する事ができ、32bitをサポートするHFS Plusでは、１ボリュームを最大約43億分割する事が可能（注４）という事になります。つまり、同じ要領の器をより多くの数で分割する事により、その器における最小単位（この場合アロケーションブロック）をハードディスクの構造上の限界（512byte）まで小さく設定する事が可能となっており、結果として大容量のボリュームを扱う時のファイル格納時の効率性に大きな差を生み出す事となります。尚、Windowsの世界ではHFS標準に相当する16bitファイルシステムが「FAT16（File Allocation Table 16）」、HFS Plusに相当する32bitファイルシステムが「FAT32（File Allocation Table 32）」という名称で存在しており、更にはアカウント単位でのアクセス権の設定や、ファイルシステムにおける暗号化、或いは後に説明するジャーナリングをもサポートした「NTFS（NT File System）」というファイルシステムもサポートされています。

●格納効率向上によるボリュームの有効活用

では、同一サイズのボリュームをより多くのブロックで分割すると、何故格納効率が向上するのでしょうか？例として1GBのボリュームに対してHFS標準（16bit）を適用した場合を仮定してみましょう。まずは単純に計算してみます。

1GB=1,024,000,000byte / 65,536（16bitで扱える最大数）=15,625=約16kbyte

格納可能なファイルの最小サイズが16kbyteとなりました。この計算方法でもアロケーションブロックのサイズを近似値で導き出す事はできますが、正確な計算方法はもう少し複雑です。

1GB=1,024MB x 2000（1MB中におけるディスクブロック数） / 65,536 x 512=15,872=約16kbyte

アロケーションブロックのサイズが論理ブロック数で32、格納可能なファイルの最小サイズが16kbyte。結果としてHFS標準（16bit）では、仮にファイル名のみを指定し、内容が何も無いようなファイルを保存したとしても、16KB分のディスク容量を消費してしまう事となります。この無駄を省くために１ボリュームをより多くのブロック数で分割し、ファイル格納時における効率性を向上させる事が、32bit対応ファイルシステム「HFS Plus（Mac OS拡張フォーマット）」の大きなメリットの１つとなります。更に具体的な例を挙げてみますと、4GBのボリューム上で4KBのサイズのファイルを保存しようとした場合、HFS標準では64KBもの容量を必要としてしまいますが、同条件下でHFS Plusを使用した場合には4KBの消費量に押さえる事が可能となり、この差というのは扱うファイル数が多ければ多くなる程、大容量として跳ね返ってくる事となります。身近な例では、Mac OS X標準のメールクライアント「Apple Mail」が、10.3 PantherまでのVer.1.X以前では「１メールボックス１ファイル」として扱ってきたものが、10.4 TigerにおけるVer.2.XではSpotlightとの絡みにより「１メール１ファイル」という仕様に変更されましたが、この場合においてもファイルの格納効率の大きな無駄に繋がらないのは、32bitファイルシステムがもたらす恩恵であるといえます。このように大容量ボリュームの管理時に、より有効とされるHFS Plusは、1GB以下のボリュームではさほど大きな効果を得る事はできず、32MB以下のボリュームやメディア（FD含む）に対してHFS Plusフォーマットとして初期化する事は不可能という仕様になっています。
ブロックサイズの異なるボリュームに対して同容量のファイルを保存した場合の格納効率の差異
↑10KBの容量のファイルを、ブロックサイズ16KBのボリューム（Vol.1）と4KBのボリューム（Vol.2）に保存した際の格納効率で、黒字を無駄な領域として表している。Vol.1では6KBの容量が無駄に消費されているが、より細かいブロックサイズで分割されているVol.2では、無駄な領域が2KBで抑えられているのが見て取れる

尚、HFS Plus上におけるMac OS Xの現行バージョン（Mac OS X 10.4.5）、及びClassic Mac OSの最終バージョン（Mac OS 9.2.2）のボリュームやファイルに対する制限事項は、

最大ボリューム数

最大ボリュームサイズ

１フォルダに格納可能なファイル、及びフォルダ数

１つのファイルやフォルダに割り振る事のできるファイル名（フォルダ名）の長さ

となっています（2006年３月現在）。そしてファイル名のハンドリングに関しては、英大文字／小文字の違いを識別しつつ、ファイルシステム上ではそれらの違いを吸収し、同一の文字として扱う事が可能（注５）となっており（case-insensitive）、Mac OS X以降ではUnicodeにも正式対応。「Mac OS X 10.3 Panther」以降では、コマンドラインにおける「diskutil」を用いる事により、ファイル名における英大文字／小文字を別の文字として扱わせる事（case-sensitive）を可能としたHFS Plusの拡張版「HFSX」のサポートも実現。「Terminal（ターミナル、/Aplication/Utilities/Terminal.app）」にて以下のコマンドを使用する事により、HFSXに対応したボリュームを作成する事が可能となっています（事前にボリュームの初期化を必要とするので要注意）。

※「VolName」には任意のボリューム名が入ります。尚、「Mac OS X 10.4 Tiger」以降においては、ディスクユーティリティのオプション（Mac OS 拡張（大文字と小文字を区別／ジャーナリング））を利用したGUI環境による設定が可能。

そして、HFSXに対応したイメージファイルを作成するには、

※ターミナルにおけるカレントディレクトリに容量5MBのイメージファイルを作成

にて、対応可能となっています。
HFSXを採用したボリュームイメージにおける英大文字／小文字の取り扱い
↑HFSXを採用したボリュームイメージに「MacOSX」というフォルダと「macosx」というフォルダを同居。英大文字／小文字を別の文字として認識している様子が見て取れる

このようにユーザに対し多大なメリットを享受してくれるHFS Plusですが、旧Mac OSの時代にはシステムレベルでも扱っているファイル数がさほど多くはなかったため、最終バージョンである9.2.2の時代に至るまで、完全な移行は実現されていませんでした。考えられる主な理由としては、

等の様々な事情があったかと思われますが、それでも用が足りていたのが旧Mac OS時代の実情でもありました。しかしMac OS Xの時代に入り状況は一変します。BSD UNIXベースの「Darwin」を基盤としているMac OS Xは、UNIX由来の膨大な数の不可視ファイルを含め、基本的なシステム構成だけで数万単位のファイル数を必要としています。このため、HFS標準（16bit）ではシステム自体を支える事ができなくなり、必然的にHFS Plus（32bit）への完全移行が実現される事となった訳です。そして上記の制限事項のように旧Mac OSでは「Finder」の仕様上、HFS Plusの様々なメリットがスポイルされる形になっていましたが、Mac OS Xの時代に入り、遅ればせながらHFS Plusの真の実力を発揮させる土台が整った形となっています。

次回は、Mac OS X 10.2.2より導入されたジャーナリングファイルシステムを取り上げたいと思います。

●本文訳注

（注１）Mac OS 8.1から更に上位互換

Mac OS 8.0以前のシステム（8.0含む）ではHFS Plusボリュームを認識する事ができないが、Mac OS 8.1以降がネットワーク上に共有リソースとして提供したHFS Plusボリューム（ファイル共有にて共有ポイントとしたボリューム）は、Mac OS 8以前のシステムからでもアクセスする事ができる。つまりHFS Plusボリュームを提供するMac OS 8.1以降のサーバ（Mac OS X含む）に対して、HFSボリュームから起動している旧バージョンのクライアントが自らを接続し、サービスを受ける事ができる。

（注２）32bitが扱える数値（約43億）

TCP/IPで利用されているIPアドレス（IPv4）も、２進数32bitを８bit区切りの10進数で表現しているので、扱える数は２の32乗=約43億となっている（実際にはプロトコル上の規約による使用不可能なアドレス範囲もあるので、単純に２の32乗分のグローバルアドレスを割り振れる訳ではない）

（注３）アロケーションブロック

単一、或いは複数の論理ブロックで構成されたボリューム上の記憶容量の単位。アロケーションブロックの理論的な最大数は、ファイルシステムでサポートしているbitが扱える数と等価になり、ボリュームサイズに比例して、１つのアロケーションブロックに割り当てられる論理ブロックの数も増える事となる。

（注４）32bitをサポートするHFS Plusでは、１ボリュームを最大約43億分割する事が可能

ここで記している数値は理論上の最大値であるため、ボリュームサイズによってはこれ以下となる事もあり得る。

（注５）ファイルシステム上ではそれらの違いを吸収し、同一の文字として扱う事が可能

Mac OS Xがサポートしているもう１つのファイルシステム「UFS（UNIX File System）」では、ファイル名における英大文字／小文字の違いを別の文字として判断する。つまり「MacOSX」というファイルと「macosx」というファイルは、HFS Plus上では同一ファイルとして認識されるが、UFS上では別ファイルとして認識する事となる。

御意見、御感想はこちらまで
Topページへ

Created Date : 06/03/06
Modified Date : 06/03/18