私はこれについてしばらく考えていました (ご存知のように、プログラマーは危険なことをする傾向があります)。この質問に答える際の問題は、私がこれまでに使用した唯一のものであるため、実際に比較するものが何もないことです.
FAT、NTFS、または特定の種類のファイル システムを意味するのではなく、ファイル システム構造全体を意味します。私たちは単に、ハード ドライブが 1 つの巨大なファイリング キャビネットであるかのように、「フォルダー」内の「ファイル」を考えることに慣れています。これは素晴らしいアナロジーであり、実際、このように考えると学習がはるかに簡単になりますが、プログラムとそのそれぞれの部分を説明するのに本当に最善の方法でしょうか?
オペレーティング システムがデータの一部を別の方法で整理するためにデータを格納するために使用できるデータ ストレージ手法を誰かが考えられる (または知っている) かどうかを知りたいです。何か...違うものは存在しますか？
多くの場合、メールはフォルダに保存されます。しかし、Gmailに移行して以来、メールをタグで分類することに慣れてきました。
ファイルシステム全体をそのように管理できるかどうか疑問に思うことがよくありました。ファイルをフォルダに保存する代わりに、好きなタグでファイルにタグを付けることができます。ファイル識別子は次のようにはなりません。
/home/john/personal/contacts.txt
しかし、もっとこのように：
contacts[john,personal]
ええと...ただの思考の糧（多分これはすでに存在します！）
たとえば、 Oracle Raw Partitionsなどの専用ソリューションを使用できます。他のデータベースも同様のことをサポートしています。このような場合、ファイルシステムは不要なオーバーヘッドを提供するため、省略できます。DB ソフトウェアが構造の編成を処理します。
この問題は非常にアプリケーションに依存しているようで、ファイル/フォルダーは多くのアプリケーションにとって妥当な妥協点のようです (そして、人間が理解するのは簡単です)。
メインフレームは、使用する「デバイス」をプログラマーに提供するだけでした。デバイスはドライブまたはそのパーティションに対応し、プログラマはドライブ上のすべてのデータの編成を担当していました。もちろん、彼らはそれを支援するライブラリを迅速に構築しました。
フラットファイルの一般的な階層配置（UNIXなど）を使用していると私が考える唯一のOSはPICKです。ファイルシステムとして一種のリレーショナル データベースを使用していました。
Microsoft は当初、Windows Vista 用の新しいファイル システム (WinFS - Windows の将来のストレージ) を導入することを計画していました。アイデアは、すべてをリレーショナル データベース (SQL Server) に格納することでした。私の知る限り、このプロジェクトは決して (またはまだ?) 完成していません。
詳細については、ウィキペディアを参照してください。
独自のファイル システムを備えたハードディスクについて博士号を書いた人を知っていました。これは、OS のファイル システム ドライバーをバイパスして、通常のオープン、読み取り、書き込み、およびクローズ コマンドをディスクに直接送信できるようにする SCSI コマンドの拡張に基づいていました。結論としては、柔軟性がなく、あまり効率的ではないということだったと思います。
とにかく、このディスクベースのファイルシステムにはまだフォルダーのような構造があったと思います。
他の応答をエコーします。ファイルシステムの種類を選択できれば、個人的にはハイブリッドアプローチを検討したいと思います。サブツリーのフラットデータベースで、各サブツリーはまとまりのあるユニットと見なされますが、サブツリー自体を個別のユニットと見なすと、階層はありませんが、代わりに、メタデータ+そのメタデータでクエリ可能にすることができます。
ファイルの理由は、人間が使用しなければならない「もの」に名前を付けるのが好きだからです。そうしないと、話したり、考えたり、区別したりすることが難しくなります。
ヒープ上にあるものが多すぎる場合は、ヒープを分離するのが好きです。私たちはそれを何らかの方法で分類し、任意のサイズの物をナビゲートできる階層を構築したいと考えています。
したがって、ディレクトリとファイルは、実際のオブジェクトを操作する自然な方法をマップするだけです。ファイルには何でも入れることができるので。Unixでは、ハードウェアでさえ「デバイスノード」としてファイルシステムにマップされます。ファイルシステムは、ハードウェアにコマンドを送信するために読み取り/書き込みできる特別なファイルです。
比喩はとても強力だと思います、それはとどまるでしょう。
特定のファイルやディレクトリ構造のバージョン（およびバージョン履歴）を維持する自動バージョン管理ファイルシステムを考え出すのにしばらく時間を費やしました。
すべての標準アクセスコマンド（dir、readなど）には、その時点でファイルシステムにアクセスするために渡すことができるオプションの日付/時刻パラメーターが含まれるという考え方でした。
私はそれでかなり遠くまで行きました、しかし私が実際に外に出てそしていくらかのお金を稼がなければならなかったときそれを放棄しなければなりませんでした。それ以来、それは後回しにされています。
オペレーティングシステムの起動時間を見ると、ディスクへのアクセスを改善できることは明らかです。変更がファイルシステムにあるのか、OSの起動コードにあるのかわかりません。
OS とファイル システムが統合されたデータベースであるPickは常にあります。
従来のファイル システムは、必要なファイルの名前 (パスを含む) がわかっている場合に、高速なファイル アクセス用に最適化されています。ディレクトリは、ファイルをグループ化する方法であり、ファイルのプロパティはわかっていても実際の名前はわかっていない場合でも、見つけやすくなります。
従来のファイル システムは、ファイルについてほとんど知らない場合はファイルを見つけるのが苦手ですが、その上にレイヤーを追加して、コンテンツやタグなどのメタ情報に基づいてファイルを取得するのに役立つほど堅牢です。それがインデクサーの目的です。
肝心なのは、CPU が実行する必要があるバイトを永続的に保存する方法が必要だということです。そのため、連続したバイトのセットを整理するのに非常に優れた従来のファイル システムがあります。また、直接実行されるのではなく、実行されるものによって使用されるファイルのバイトを永続的に保存する必要もあります。同じ基本的なことのために新しいシステムを作成するのはなぜですか?
バイトを保存して取得する以外に、ファイルシステムは何をすべきでしょうか?
個人的には、WinFS が飛ばなかったのが本当に残念です。私はコンセプトが大好きでした.. ウィキペディアから ( http://en.wikipedia.org/wiki/WinFS ) :
WinFS には、情報を格納するためのリレーショナル データベースが含まれており、適切に定義された型のスキーマがあれば、あらゆる種類の情報をそこに格納できます。個々のデータ項目は、特定の属性に基づいてシステムによって推測されるか、ユーザーによって明示的に示される関係によって相互に関連付けることができます。データには明確に定義されたスキーマがあるため、どのアプリケーションでもデータを再利用できます。また、関係を使用して、関連するデータを効果的に整理したり、取得したりできます。システムは情報の構造と意図を認識しているため、複雑なクエリを作成するために使用できます。これにより、データの高度な検索が可能になり、データ間の関係を利用してさまざまなデータ項目を集約できます。