ファイル システムの進化

ディスク オペレーティング システムで機能するようにコンピューターを開発する前は、各コンピューターは、コンピューター全体を完全かつ排他的に制御できる独自のアプリケーションを実行するように構築されていました。 アプリケーションは、コマンドをディスク コントローラーに直接送信することで、永続的なデータをディスクまたはドラムに直接書き込みます。 アプリケーションは、ディスク上のデータの絶対位置を管理し、既存のデータが上書きされていないことを確認する役割を担いました。 コンピューター上で実行されていたアプリケーションは 1 つだけであるため、このタスクは難しすぎなかった。

複数のアプリケーションを実行できるコンピューター システムの出現には、アプリケーションが互いのデータを書き込まないようにするためのメカニズムが必要でした。 アプリケーション開発者は、使用中のディスク セクターと、それに応じてマークすることで空きディスク セクターを区別するための単一の標準を採用することで、この問題に対処しました。 これらの標準は、永続的なストレージを管理するためのファイル システムなど、さまざまなサービスをアプリケーションに提供するディスク オペレーティング システムに統合されました。 ファイル システムの登場により、アプリケーションは物理ストレージ メディアを直接処理する必要がなくなりました。 代わりに、彼らは単にファイルシステムにデータブロックをディスクに書き込むよう指示し、その方法を考えるのはファイルシステムに任せました。 さらに、ファイル システムでは、アプリケーションがディレクトリと呼ばれる抽象化を使用してデータ階層を作成することができました。 ディレクトリには、ファイルだけでなく他のディレクトリを含めることもできます。そのディレクトリには、独自のファイルやディレクトリなどを含めることもできます。

ファイル システムは、アプリケーションとディスクの間に 1 レベルの間接参照を提供し、その結果、ファイル システムが実際にファイルを非連続セクターに格納しているにもかかわらず、すべてのアプリケーションがディスク上の 1 つの連続したバイト ストリームとしてファイルを見たという結果になりました。 間接参照により、アプリケーションはストレージ デバイス上のデータの絶対位置を追跡する必要がなくなった。

現在、ファイル入出力用のほぼすべてのシステム API は、フラット ファイルに情報を書き込むためのアプリケーションを提供します。 アプリケーションでは、このファイルは、ディスクがいっぱいになるまで必要に応じて大きくなる可能性がある 1 つのバイト ストリームと見なされます。 長い間、これらの API は、アプリケーションが永続的な情報を格納するのに十分でした。 アプリケーションは、1 つの情報ストリームを処理して、増分的な "高速" セーブなどの機能を提供する方法に大きな革新を加えています。

ただし、コンポーネント オブジェクトの世界では、単一のフラット ファイルにデータを格納することは効率的ではなくなりました。 ファイル システムが複数のアプリケーションで同じストレージ メディアを共有する必要性から生じたように、コンポーネント オブジェクトには、1 つのファイルの概念フレームワーク内で記憶域を共有できるシステムが必要になります。 従来のフラット ファイル ストレージを使用して個別のオブジェクトを格納することはできますが、いずれかのオブジェクトのサイズが大きくなる場合や、単に別のオブジェクトを追加する場合は、ファイル全体をメモリに読み込み、新しいオブジェクトを挿入して、ファイル全体を保存する必要があります。 このプロセスには非常に時間がかかる場合があります。

COM によって提供されるソリューションは、第 2 レベルの間接参照 (ファイル内のファイル システム) を実装することです。 フラット ファイル ストレージでは、ディスク上の大きな連続したバイト シーケンスを、1 つのシーク ポインターを持つ 1 つのファイル ハンドルを介して操作する必要があります。 これに対し、COM 構造化ストレージでは、1 つのファイル システム エンティティを、ディレクトリやファイルのように動作する 2 種類のオブジェクト (ストレージとストリーム) の構造化コレクションとして扱う方法が定義されています。