Loading article…
階層型ファイルシステム（HFS）は、Apple Inc.がMac OSを搭載したコンピュータシステムで使用するために開発した独自のファイルシステムです。元々はフロッピーディスクやハードディスクでの使用を想定して設計されましたが、 CD-ROMなどの読み取り専用メディアでも使用されています。HFSはMac OS Standard（またはHFS Standard ）とも呼ばれ、後継のHFS PlusはMac OS Extended（またはHFS Extended）とも呼ばれます。
Mac OS X 10.6の導入に伴い、Apple は HFS Standard ディスクおよびイメージのフォーマットや書き込みのサポートを終了しましたが、 macOS 10.15までは読み取り専用ボリュームとしてサポートされていました。[ 1 ] macOS 10.15 以降、HFS Standard ディスクは読み取れなくなりました。
Appleは1985年9月にHFSを導入しました。これは、 Macintosh向けのApple初のハードディスクドライブをサポートするためであり、 1年半以上前に初代Macintoshコンピュータとともに導入されたオリジナルのファイルシステムであるMacintoshファイルシステム（MFS）に取って代わるものでした。HFSは、 Apple III向けの階層型ファイルシステムを備えたApple初のオペレーティングシステムであるSOSに大きく依存しており、 SOSはApple IIeとApple Lisaの階層型ファイルシステムの基礎にもなりました。HFSはPatrick DirksとBill Bruffeyによって開発されました。HFSは、当時の他のファイルシステムにはなかったMFSと多くの設計上の特徴を共有していました。ファイルは複数のフォーク（通常はデータフォークとリソースフォーク）を持つことができ、これにより、ファイルのメインデータを、ローカライズが必要なアイコンなどのリソースとは別に保存することができました。ファイルはファイル名ではなく一意のファイルIDで参照され、ファイル名は最大31文字まででした。
しかし、MFS はフロッピー ディスクなどの非常に小さくて低速なメディアで使用するために最適化されていたため、より大容量のメディア、特にハード ドライブの登場に伴って発生したパフォーマンスの問題を克服するために HFS が導入されました。主な懸念事項は、フォルダの内容を表示するのに必要な時間でした。MFS では、すべてのファイルとディレクトリの一覧情報が単一のファイルに保存されており、システムは特定のフォルダに保存されているファイルのリストを作成するためにそのファイルを検索する必要がありました。これは、数百キロバイトのストレージとおそらく 100 個のファイルを持つシステムではうまく機能しましたが、システムがメガバイトと数千個のファイルに成長すると、パフォーマンスは急速に低下しました。
解決策は、MFS のディレクトリ構造を、より大きなファイルシステムに適したものに置き換えることでした。HFS は、フラットなテーブル構造をカタログ ファイルに置き換えました。カタログ ファイルは、サイズに関係なく非常に高速に検索できるB ツリー構造を使用しています。 [ 2 ] HFS はまた、より大きな数値を保持できるようにさまざまな構造を再設計し、16 ビット整数をほぼ普遍的に 32 ビットに置き換えました。奇妙なことに、この「サイズアップ」が行われなかった数少ない場所の 1 つはファイル ディレクトリ自体であり、HFS では各論理ディスク上のファイルの合計が 65,535 個に制限されています。
HFSは独自のファイルシステム形式ですが、ドキュメントは充実しており、ほとんどの最新のオペレーティングシステムからHFS形式のディスクにアクセスするためのソリューションが通常利用可能です。
Appleは、1985年9月にMacintosh向けに初めて 20MBのハードディスクを発売した際、パッチファイル（「Hard Disk 20」）を使用して起動時にMFSフロッピーディスクからRAMにロードすることで、必要に迫られてHFSを導入しました。しかし、HFSが広く普及したのは、1986年1月にMacintosh Plusとともに登場した128K ROMに搭載された時で、同時にHFSを使用するMacintosh用の800KBフロッピーディスクドライブも発売されました。HFSの導入は、AppleがMacintoshコンピュータモデルを置き去りにする最初の進歩でした。それは、HFSコードをロードするのに十分なメモリがなく、すぐに販売中止となった初代128K Macintoshです。
1998年、AppleはHFSにおけるディスク領域の非効率的な割り当てに対処し、その他の改善を加えるためにHFS Plusを導入した。
Mac OS X 10.0以降、HFS Standard ボリュームはブートに使用できなくなり、 Mac OS X 10.6 (Snow Leopard)以降、HFS Standard ボリュームは読み取り専用となり、作成や更新ができなくなります。macOS Sierra (10.12) では、Apple のリリース ノートに「HFS Standard ファイルシステムはサポートされなくなりました」と記載されています。[ 3 ]しかし、読み取り専用の HFS Standard サポートはmacOS 10.15のリリースまで引き続き機能し、35 年にわたる従来の HFS Standard の公式サポートが終了しました。[ 4 ]
ストレージボリュームは、本質的に512バイトの論理ブロックに分割されます。階層型ファイルシステム（HFS）は、これらの論理ブロックをアロケーションブロックにグループ化します。アロケーションブロックは、ボリュームの合計サイズに応じて、1つまたは複数の論理ブロックを含むことができます。HFSは、アロケーションブロックのアドレス指定に16ビット値を使用するため、アロケーションブロックの数は65,535（2¹⁶-1）に制限されます。
HFSボリュームは5つの構造から構成されます。
カタログファイルは、すべてのファイルとディレクトリのレコードを単一のデータ構造に格納しますが、システムがマルチタスクを許可している場合、一度に 1 つのプログラムしかこの構造に書き込めないため、パフォーマンスの問題が発生します。つまり、 1 つのプログラムがシステムを「占有」しているため、多くのプログラムがキューで待機することになります。 [ 5 ]また、このファイルが破損するとファイルシステム全体が破壊される可能性があるため、信頼性の問題も深刻です。これは、ファイルとディレクトリのレコードを別々の構造に格納する他のファイルシステム (DOS の FAT ファイルシステムやUnix ファイルシステムなど) とは対照的です。これらのファイルシステムでは、構造がディスク全体に分散されているため、単一のディレクトリが破損してもファイルシステム全体が使用不能になることはなく、破損していない部分に格納されているデータを使用してデータを再構築できる可能性があります。
さらに、割り当てブロック数が65,535に制限されていたため、ファイルの「最小」サイズはディスクサイズの1/65,535に相当しました。つまり、ボリュームのサイズに関係なく、最大で65,535個のファイルしか保存できませんでした。さらに、どのファイルも、割り当てブロックサイズまで、実際に必要な容量よりも多くのスペースが割り当てられました。ディスクが小さかった頃は、個々の割り当てブロックサイズがごくわずかだったため、これはほとんど問題になりませんでしたが、ディスクが1GBに近づくにつれて、どのファイルも占有できる最小容量（単一の割り当てブロック）が過剰に大きくなり、ディスク容量が大幅に無駄になりました。たとえば、1GBのディスクでは、HFSの割り当てブロックサイズは16KBなので、1バイトのファイルでも16KBのディスク容量を占有することになります。大きなファイル（画像、データベース、音声など）を持つユーザーにとっては、これらの大きなファイルはファイルサイズに対する無駄な容量の割合が少なかったため、この問題はそれほど深刻ではありませんでした。一方、小さなファイルを多数保存しているユーザーは、割り当てブロックサイズが大きいため、大量の容量を無駄に消費してしまう可能性がありました。そのため、 Macユーザーにとってディスクをより小さな論理ボリュームに分割することは非常に魅力的でした。なぜなら、小さなドキュメントを小さなボリュームに保存すれば、大きなパーティションに保存する場合よりもはるかに少ない容量で済むからです。同様の問題はFAT16ファイルシステムにも存在していました。
HFSは、ファイルの作成時または名前変更時に付けられたファイル名の大文字/小文字を保存するため、大文字/小文字を保持しますが、動作中は大文字/小文字を区別しません。