ファイルシステム

ファイル名（またはファイルネーム）は、ファイルを利用するアプリケーションや場合によってはユーザーに対して、そのファイルを識別するために使用されます。

ファイル名は一意であるため、アプリケーションは特定の名前に対して必ず1つのファイルのみを参照できます。ファイルシステムがディレクトリをサポートしている場合、通常、ファイル名の一意性は各ディレクトリ内で強制されます。つまり、ストレージには同じ名前のファイルが複数存在できますが、同じディレクトリ内には存在できません。

ほとんどのファイルシステムはファイル名の長さを制限しています。

ファイルシステムによっては、ファイル名を大文字と小文字を区別して照合するものと、区別せずに照合するものとがあります。例えば、ファイル名MYFILEとファイル名は、myfile大文字と小文字を区別しない場合は同じファイルに対応しますが、大文字と小文字を区別する場合は異なるファイルに対応します。

最新のファイルシステムのほとんどは、ファイル名にUnicode文字セットの幅広い文字を含めることができます。ただし、デバイス、デバイスの種類、ディレクトリの接頭辞、ファイルパスの区切り文字、ファイルの種類などの特殊な属性を示すために使用される文字は制限される場合があります。

ファイルシステムは通常、ファイルをディレクトリ（フォルダとも呼ばれる）に整理することをサポートしており、ディレクトリはファイルをグループに分類します。

これは、ファイル名を目次内の索引、またはUnix系ファイルシステムのinodeに関連付けることによって実現できます。

ディレクトリ構造は、フラット（つまり線形）なものもあれば、ディレクトリ内にサブディレクトリと呼ばれるディレクトリを含めることで階層構造を可能にするものもある。

ディレクトリの任意の階層をサポートする最初のファイルシステムは、Multicsオペレーティングシステムで使用されました。^{[ 9 ]} Unix ライクなシステムのネイティブ ファイルシステムも任意のディレクトリ階層をサポートしており、AppleのHierarchical File Systemと、クラシック Mac OS の後継であるHFS+、MS-DOS 2.0 以降のバージョンの MS-DOS およびMicrosoft WindowsのFATファイルシステム、Windows NTファミリーのオペレーティングシステムのNTFSファイルシステム、 OpenVMSのODS-2 (On-Disk Structure-2) およびFiles-11ファイルシステムの上位レベルなどがこれに該当します。

ファイルシステムは、データ（ファイルの内容）に加えて、関連するメタデータも管理します。メタデータには、以下のようなものが含まれますが、これらに限定されません。

• 名前
• サイズは、割り当てられたブロック数またはバイト数として格納できます。
• 作成時、最終アクセス時、最終更新時
• 所有者、ユーザー、グループ
• アクセス権限
• ファイルの属性（読み取り専用か、実行可能かなど）
• デバイスの種類（例：ブロック、文字、ソケット、サブディレクトリなど）

ファイルシステムは、ファイルの内容とは別に、関連するメタデータを保存します。

ほとんどのファイルシステムは、1 つのディレクトリ内のすべてのファイルの名前を、そのディレクトリのディレクトリ テーブルという 1 つの場所に格納します。このディレクトリ テーブルは、他のファイルと同様に格納されることがよくあります。多くのファイルシステムでは、ファイルのメタデータの一部のみをディレクトリ テーブルに格納し、残りのメタデータはinodeなどの完全に別の構造に格納します。

ほとんどのファイルシステムは、特定のファイルに関連付けられていないメタデータも保存します。このようなメタデータには、未使用領域に関する情報（空き領域ビットマップ、ブロック可用性マップ）や不良セクタに関する情報が含まれます。多くの場合、割り当てグループに関するこのような情報は、割り当てグループ自体の中に保存されます。

NTFS、XFS、ext2、ext3 、一部のUFSバージョン、HFS+などのファイルシステムでは、拡張ファイル属性を使用して追加の属性を関連付けることができます。一部のファイルシステムでは、ドキュメントの作成者、ドキュメントの文字エンコーディング、画像のサイズなど、ユーザー定義の属性が提供されています。

ファイルシステムによっては、1つのファイル名に異なるデータコレクションを関連付けることができます。これらの個別のコレクションは、ストリームまたはフォークと呼ばれることがあります。AppleはMacintoshで長年フォークファイルシステムを使用しており、MicrosoftはNTFSでストリームをサポートしています。ファイルシステムによっては、1つのファイル名の下にファイルの複数の過去のリビジョンを保持します。ファイル名自体で最新バージョンを取得できますが、以前に保存されたバージョンには、「ファイル名;4」や「ファイル名(-4)」などの特別な命名規則を使用してアクセスし、4つ前のバージョンにアクセスできます。

ローカルファイルシステムは、ストレージのどの領域がどのファイルに属しているか、またどの領域が使用されていないかを追跡します。

ファイルシステムがファイルを作成する際、データ用の領域を割り当てます。一部のファイルシステムでは、初期領域割り当てと、ファイルのサイズが大きくなるにつれて追加される領域割り当てを指定できる、または必須となっています。

ファイルを削除すると、ファイルシステムはファイルの空き領域（別のファイルに使用可能な領域）が解放されたことを記録します。

ローカルファイルシステムは、信頼性と効率性を確保するためにストレージ領域を管理します。一般的に、ストレージデバイスの領域を、通常は複数の物理単位（つまりバイト）という粒度で割り当てます。たとえば、 1980年代初頭のApple DOSでは、140キロバイトのフロッピーディスク上の256バイトのセクタがトラック/セクタマップを使用していました。^{[ 10 ]}

粒度が細かいため、粒度割り当ての倍数のサイズを持つまれなファイルを除き、各ファイルに未使用領域（スラック領域と呼ばれることもある）が生じます。 ^{[ 11 ]} 512バイトの割り当ての場合、平均未使用領域は256バイトです。64KB クラスタの場合、平均未使用領域は32KBです 。

一般的に、割り当て単位のサイズはストレージの設定時に決定されます。保存されるファイル数に比べてサイズが小さすぎると、アクセスオーバーヘッドが過剰になります。逆にサイズが大きすぎると、未使用領域が過剰になります。ストレージに格納されると予想されるファイルの平均サイズに基づいて割り当てサイズを選択すると、未使用領域を最小限に抑えることができます。

ファイルシステムがファイルを作成、変更、削除するにつれて、基盤となるストレージ表現が断片化される可能性があります。ファイルとファイル間の未使用領域は、連続していない割り当てブロックを占有することになります。

ファイルの内容を保存するために必要な領域を連続したブロックで割り当てることができない場合、ファイルは断片化されます。ファイルが削除されると、空き領域は断片化されます。^{[ 12 ]}

断片化はエンドユーザーには見えず、システム自体は正常に動作します。しかし、ハードディスクドライブのように連続したブロックでより効率的に動作する一部のストレージハードウェアでは、断片化によってパフォーマンスが低下する可能性があります。ソリッドステートドライブなどの他のハードウェアは、断片化の影響を受けません。

ファイルシステムは、多くの場合、管理するデータへのアクセス制御をサポートしています。

アクセス制御の目的は、多くの場合、特定のユーザーが特定のファイルを読み取ったり変更したりすることを防止することにある。

アクセス制御は、プログラムによるアクセスを制限し、データが制御された方法で変更されるようにすることもできます。例としては、ファイルのメタデータやその他の場所に保存されたパスワード、およびパーミッションビット、アクセス制御リスト、または機能の形式によるファイル権限などが挙げられます。ファイルシステムユーティリティがメディアレベルでデータにアクセスして構造を再編成し、効率的なバックアップを提供する必要があるため、これらのユーティリティは通常、礼儀正しいユーザーには有効ですが、侵入者に対しては有効ではありません。

ファイルデータの暗号化方法は、ファイルシステムに組み込まれている場合があります。これは、ファイルシステムユーティリティがデータを効率的に管理するために暗号化シードを知る必要がないため、非常に効果的です。暗号化に依存するリスクとしては、攻撃者がデータをコピーして総当たり攻撃で復号化できる可能性があることが挙げられます。さらに、シードを紛失するとデータも失われます。

一部のオペレーティングシステムでは、システム管理者がディスククォータを有効にして、ユーザーによるストレージ容量の使用を制限できます。

ファイルシステムは通常、通常の操作時だけでなく、次のような例外的な状況においても、保存されたデータの一貫性を維持することを保証します。

• アクセスしているプログラムが、ファイルへのアクセスが完了したこと（ファイルを閉じること）をファイルシステムに通知しない。
• アクセス中のプログラムが異常終了する（クラッシュする）
• メディア障害
• リモートシステムへの接続が失われる
• オペレーティングシステムの障害
• システムリセット（ソフトリブート）
• 停電（強制再起動）

例外的な状況からの復旧には、メタデータやディレクトリエントリの更新、バッファリングされたもののストレージメディアに書き込まれなかったデータの処理などが含まれる場合があります。

ファイルシステムは、次のような問題の分析を可能にするためにイベントを記録する場合があります。

• ファイルまたはシステムの問題とパフォーマンス
• 不正アクセス

通常、ファイルシステムは、ユーザーが様々なユーティリティプログラムを使って管理することができる。

一部のユーティリティを使用すると、ファイルシステムのインスタンスを作成、設定、削除できます。また、ファイルシステムに割り当てられた領域を拡張または切り詰めることもできます。

ディレクトリユーティリティは、ディレクトリエントリ（単数形：dentry）^{[ 14 ]}の 作成、名前変更、削除、およびディレクトリに関連付けられたメタデータの変更に使用できます。ディレクトリユーティリティには、ディレクトリへの追加リンク（Unixではハードリンク）の作成、親リンク（ Unix ライクなオペレーティングシステムでは".."）の名前変更、およびファイルへの双方向リンクの作成機能も含まれる場合があります。

ファイルユーティリティは、ファイルの作成、一覧表示、コピー、移動、削除、およびメタデータの変更を行います。データの切り捨て、領域割り当ての切り捨てまたは拡張、ファイルの追記、移動、およびインプレースでの変更も可能です。ファイルシステムの基盤となる構造によっては、ファイルの先頭への追記または先頭からの切り捨て、ファイルの途中へのエントリの挿入、またはファイルからのエントリの削除を行うメカニズムを提供する場合があります。ファイルシステムに削除復元機能がある場合、削除されたファイルの領域を解放するユーティリティもこのカテゴリに含まれます。

ファイルシステムによっては、空き領域の再編成、空き領域の安全な消去、階層構造の再構築といった操作を、アクティビティが最小限の時に実行するためのユーティリティを提供することで、これらの処理を延期するものがあります。ファイルシステムのデフラグメンテーションユーティリティはその一例です。

ファイルシステムユーティリティの最も重要な機能のいくつかは、管理機能であり、これには所有権の回避や基盤となるデバイスへの直接アクセスが含まれる場合があります。これには、高性能なバックアップとリカバリ、データレプリケーション、ファイルシステム内のさまざまなデータ構造や割り当てテーブルの再編成などが含まれます。

ユーティリティ、ライブラリ、およびプログラムは、ファイルシステムAPIを使用してファイルシステムに要求を行います。これには、データ転送、位置指定、メタデータの更新、ディレクトリの管理、アクセス指定の管理、および削除が含まれます。

小売システムでは、ストレージデバイス全体を単一のファイルシステムが占めるように構成されていることが多い。

別のアプローチとしては、ディスクをパーティション分割して、異なる属性を持つ複数のファイルシステムを使用できる方法があります。ブラウザのキャッシュやメールの保存に使用するファイルシステムは、割り当てサイズを小さく設定できます。これにより、ブラウザのアクティビティでよく見られるファイルの作成と削除のアクティビティが、他のファイル割り当てに干渉しないディスクの狭い領域に留まります。別のパーティションは、比較的大きなブロックサイズでオーディオファイルやビデオファイルを保存するために作成できます。さらに別のパーティションは通常は読み取り専用に設定され、定期的にのみ書き込み可能に設定できます。ZFSやAPFSなどの一部のファイルシステムは、共通の空きブロックプールを共有する複数のファイルシステムをサポートしており、各ファイルシステムに固定量のスペースを予約することなく、異なる属性を持つ複数のファイルシステムをサポートします。^{[ 15 ] [ 16 ]}

3つ目のアプローチは、主にクラウドシステムで使用されるもので、「ディスクイメージ」を使用して、同じ属性を持つか否かにかかわらず、追加のファイルシステムを別の（ホスト）ファイルシステム内にファイルとして格納する方法です。一般的な例としては仮想化があります。ユーザーは、本番環境のWindows（NTFSを使用）上の仮想マシンで、実験的なLinuxディストリビューション（ ext4ファイルシステムを使用）を実行できます。ext4ファイルシステムはディスクイメージ内に存在し、NTFSホストファイルシステム内ではファイル（ハイパーバイザと設定によっては複数のファイル）として扱われます。

単一システム上に複数のファイルシステムを持つことには、1つのファイルシステムが破損した場合でも、残りのファイルシステムは多くの場合無傷のままであるという利点があります。これには、システムファイルシステムがウイルスによって破壊された場合や、システムが起動しなくなった場合も含まれます。専用アクセスを必要とするファイルシステムユーティリティは、効率的に部分的に実行できます。さらに、デフラグメンテーションもより効果的に行える場合があります。ウイルススキャンやバックアップなどのシステムメンテナンスユーティリティも、部分的に処理できます。たとえば、前回のバックアップ以降にファイルが追加されていない場合は、ビデオを含むファイルシステムを他のすべてのファイルと一緒にバックアップする必要はありません。イメージファイルに関しては、マスター（オリジナル）イメージに書き込まれた「新しい」データのみを含む差分イメージを簡単に「スピンオフ」できます。差分イメージは、安全性の懸念（「使い捨て」システムとして、古いイメージを削除して新しいイメージを数秒で作成できるため、自動化された手順がなくても、破壊されたりウイルスに汚染されたりした場合でも迅速に復元できる）と、仮想マシンの迅速な展開（差分イメージはスクリプトを使用してバッチで迅速に生成できるため）の両方に使用できます。

ファイル管理のもう1つの概念は、データベースベースのファイルシステムの考え方です。階層構造の管理の代わりに、またはそれに加えて、ファイルはファイルの種類、トピック、作成者、または同様の豊富なメタデータなどの特性によって識別されます。^{[ 18 ]}

IBM DB2 for i ^{[ 19 ]} (以前は DB2/400 および DB2 for i5/OS として知られていた) は、オブジェクトベースのIBM i ^{[ 20 ]}オペレーティングシステム (以前は OS/400 および i5/OS として知られていた) の一部であるデータベースファイルシステムであり、単一レベルのストアを組み込んで IBM Power Systems (以前は AS/400 および iSeries として知られていた) 上で動作し、IBM i の元チーフサイエンティストである Frank G. Soltis によって設計されました。1978 年頃から 1988 年頃、Frank G. Soltis と IBM Rochester の彼のチームは、Microsoft などが後に達成できなかったデータベースファイルシステムなどの技術を設計し、適用することに成功しました。^{[ 21 ]}これらの技術は非公式に「Fortress Rochester」として知られており、いくつかの基本的な側面では初期のメインフレーム技術から拡張されていましたが、技術的な観点からは多くの点でより進んでいました。

純粋なデータベースファイルシステムではないが、データベースファイルシステムのいくつかの側面を利用している他のプロジェクトをいくつか挙げる。

• 多くのWebコンテンツ管理システムは、リレーショナルDBMSを使用してファイルを保存および取得します。たとえば、XHTMLファイルはXMLまたはテキストフィールドとして保存され、画像ファイルはBLOBフィールドとして保存されます。SQL SELECT文（オプションでXPathも使用可能）を使用してファイルを取得し、「通常のファイルシステム」よりも高度なロジックと豊富な情報関連付けを使用できます。多くのCMSでは、データベース内にメタデータのみを保存し、ファイルのコンテンツは標準のファイルシステムに保存するオプションも用意されています。
• Apache HadoopやGoogle File Systemのようなアプリケーションに代表される非常に大規模なファイルシステムは、データベースファイルシステムの概念の一部を利用している。

一部のプログラムは、複数のファイルシステム変更を行う必要があり、また、何らかの理由で変更が1つ以上失敗した場合は、変更を一切行わない場合があります。たとえば、ソフトウェアをインストールまたは更新するプログラムは、実行ファイル、ライブラリ、および/または構成ファイルを書き込むことがあります。書き込みの一部が失敗し、ソフトウェアが部分的にインストールまたは更新されたままになると、ソフトウェアが破損したり、使用できなくなったりする可能性があります。コマンドシェルなどの重要なシステムユーティリティの更新が不完全な場合、システム全体が使用不能な状態になることもあります。

トランザクション処理はアトミック性保証を導入し、トランザクション内の操作がすべてコミットされるか、トランザクションが中止されてシステムが部分的な結果をすべて破棄されることを保証します。つまり、クラッシュや停電が発生した場合でも、復旧後には保存された状態が一貫性を保ちます。ソフトウェアは完全にインストールされるか、失敗したインストールが完全にロールバックされますが、使用できない部分的なインストールがシステムに残ることはありません。トランザクションは分離性保証も提供します。つまり、トランザクション内の操作はトランザクションがコミットされるまでシステム上の他のスレッドから隠蔽され、システム上の干渉する操作はトランザクションと適切に直列化されます。

Windows は Vista 以降、トランザクション NTFSと呼ばれる機能でNTFSにトランザクション サポートを追加しましたが、現在ではその使用は推奨されていません。^{[ 22 ]} UNIX システム向けのトランザクション ファイルシステムには、Valor ファイルシステム^{[ 23 ]} 、 Amino ^{[ 24 ]} 、 LFS ^{[ 25 ]} 、 TxOS カーネル上のトランザクションext3ファイルシステム^{[ 26 ]}など、多数の研究プロトタイプがあり、TFFS などの組み込みシステム向けのトランザクション ファイルシステムもあります。^{[ 27 ]}

ファイルシステムトランザクションなしでは、複数のファイルシステム操作間で一貫性を確保することは困難、あるいは不可能です。ファイルロックは個々のファイルの同時実行制御メカニズムとして使用できますが、通常はディレクトリ構造やファイルメタデータを保護するものではありません。例えば、ファイルロックではシンボリックリンク上のTOCTTOU競合状態を防ぐことはできません。また、ファイルロックではソフトウェアアップグレードなどの失敗した操作を自動的にロールバックすることもできません。これにはアトミック性が必要です。

ジャーナリングファイルシステムは、ファイルシステム構造にトランザクションレベルの一貫性をもたらすための手法の一つです。ジャーナルトランザクションはOS APIの一部としてプログラムに公開されるものではなく、単一のシステムコールの粒度で一貫性を確保するために内部的にのみ使用されます。

データバックアップシステムは通常、トランザクション形式で保存されたデータの直接バックアップをサポートしていないため、信頼性が高く一貫性のあるデータセットの復旧が困難です。ほとんどのバックアップソフトウェアは、データセット全体内の複数のファイル間で共有されるトランザクション状態に関係なく、特定の時点以降に変更されたファイルを記録するだけです。この回避策として、一部のデータベースシステムは、その時点までのすべてのデータを含むアーカイブ状態ファイルを作成し、バックアップソフトウェアはそのファイルのみをバックアップし、アクティブなトランザクションデータベースとは直接やり取りしません。復旧には、バックアップソフトウェアによってファイルが復元された後、状態ファイルからデータベースを別途再構築する必要があります。

ネットワークファイルシステムは、リモートファイルアクセスプロトコルのクライアントとして機能し、サーバー上のファイルへのアクセスを提供するファイルシステムです。ローカルインターフェイスを使用するプログラムは、リモートのネットワーク接続されたコンピュータで階層ディレクトリとファイルを透過的に作成、管理、アクセスできます。ネットワークファイルシステムの例としては、^{NFS [} 28 ] ^{AFS 、} SMBプロトコルのクライアント、およびFTPやWebDAVのファイルシステムのようなクライアントなどがあります。

共有ディスクファイルシステムとは、複数のマシン（通常はサーバー）がすべて同じ外部ディスクサブシステム（通常はストレージエリアネットワーク）にアクセスできるシステムのことです。ファイルシステムはそのサブシステムへのアクセスを調停し、書き込みの衝突を防ぎます。^{[ 29 ]}例としては、 Red HatのGFS2、 IBM のGPFS（現在は Spectrum Scale として知られています）、DataPlow のSFS 、 SGIのCXFS、Quantum CorporationのStorNext、Versity の ScoutFS などがあります。

一部のファイルシステムは、オペレーティングシステムの要素をファイルとして公開し、ファイルシステムAPIを介して操作できるようにします。これはUnix系オペレーティングシステムでは一般的であり、他のオペレーティングシステムでも程度は低いものの見られます。例としては、以下のようなものがあります。

• devfs、udev、TOPS-10は、I/Oデバイスまたは擬似デバイスを特殊ファイルとして公開します。
• configfsとsysfsは、 Linuxカーネル情報を照会および構成するために使用できる特別なファイルを公開します。
• procfsはプロセス情報を特殊ファイルとして公開する

Unix系オペレーティングシステムは仮想ファイルシステムを作成し、接続されているすべてのストレージデバイス上のすべてのファイルが単一の階層構造に存在するように見せます。つまり、これらのシステムではルートディレクトリが1つだけ存在し、システム上に存在するすべてのファイルはそのディレクトリのどこかに配置されます。Unix系システムは、ルートディレクトリとしてRAMディスクまたはネットワーク共有リソースを使用できます。

Unix系システムでは、各デバイスにデバイス名が割り当てられますが、これはデバイス上のファイルにアクセスする方法ではありません。別のデバイス上のファイルにアクセスするには、まず、それらのファイルがディレクトリツリーのどこに表示されるべきかをオペレーティングシステムに伝える必要があります。このプロセスは、ファイルシステムのマウントと呼ばれます。たとえば、CD-ROM上のファイルにアクセスするには、オペレーティングシステムに「このCD-ROMからファイルシステムを取得し、特定のディレクトリに表示してください」と指示する必要があります。オペレーティングシステムに指定されるディレクトリはマウントポイント と呼ばれ、たとえば/mediaのようになります。/mediaディレクトリは多くのUnix系システムに存在し（ファイルシステム階層標準で規定されています）、CD、DVD、USBドライブ、フロッピーディスクなどのリムーバブルメディアのマウントポイントとして使用することを目的としています。このディレクトリは空の場合もあれば、個々のデバイスをマウントするためのサブディレクトリが含まれている場合もあります。一般的に、ファイルシステムのマウントを承認できるのは管理者（つまりrootユーザー）のみです。

Unix系オペレーティングシステムには、マウントプロセスを支援し、新たな機能を提供するソフトウェアやツールがしばしば含まれています。これらの戦略の中には、その目的を反映して「自動マウント」と呼ばれるものもあります。

• 多くの場合、ルート以外のファイルシステムは、オペレーティングシステムの起動後すぐに利用できる必要があります。そのため、すべてのUnix系システムは、起動時にファイルシステムをマウントする機能を提供しています。システム管理者は、これらのファイルシステムを構成ファイルfstab（Solarisではvfstab）で定義し、オプションやマウントポイントも指定します。
• 状況によっては、起動時に特定のファイルシステムをマウントする必要はありませんが、その後で使用したい場合もあります。Unix系システムには、定義済みのファイルシステムを必要に応じてマウントできるユーティリティがいくつかあります。
• リムーバブルメディアを使用すると、物理的な接続なしにプログラムやデータをマシン間で転送できます。一般的な例としては、USBフラッシュドライブ、CD-ROM、DVDなどがあります。そのため、メディアの存在と利用可能性を検出し、ユーザーの操作なしにそのメディアをマウントするユーティリティが開発されています。
• 先進的なUnix系システムでは、スーパーマウントと呼ばれる概念も導入されています。例えば、Linuxのsupermount-ngプロジェクトを参照してください。スーパーマウントされたフロッピーディスクは、システムから物理的に取り外すことができます。通常、ディスクは取り外す前に同期され、その後アンマウントされている必要があります。同期が完了していれば、別のディスクをドライブに挿入できます。システムはディスクが変更されたことを自動的に検知し、マウントポイントの内容を更新して新しいメディアを反映させます。
• オートマウンターは、マウント先のディレクトリへの参照が示されると、ファイルシステムを自動的にマウントします。これは通常、ネットワークサーバー上のファイルシステムで使用され、リムーバブルメディアの場合のようにメディアの挿入などのイベントに依存することはありません。

OS/2 1.2 introduced the High Performance File System (HPFS). HPFS supports mixed case file names in different code pages, long file names (255 characters), more efficient use of disk space, an architecture that keeps related items close to each other on the disk volume, less fragmentation of data, extent-based space allocation, a B+ tree structure for directories, and the root directory located at the midpoint of the disk, for faster average access. A journaled filesystem (JFS) was shipped in 1999.

PC-BSDはFreeBSDのデスクトップ版で、FreeNASと同様にFreeBSDのZFSサポートを継承しています。PC -BSDの新しいグラフィカルインストーラーは、ZFS上の/（ルート）およびRAID-Zプールのインストールと、Geliを使用したディスク暗号化を、最初から簡単かつ便利な（GUI ）方法で処理できます。現在のPC-BSD 9.0+「Isotope Edition」は、ZFSファイルシステムバージョン5とZFSストレージプールバージョン28に対応しています。

ベル研究所の Plan 9 では、すべてをファイルとして扱い、すべてのオブジェクトにファイルと同様の方法でアクセスします (つまり、ioctlやmmapはありません)。ネットワーク、グラフィックス、デバッグ、認証、機能、暗号化、その他のサービスは、ファイルディスクリプタに対する I/O 操作を介してアクセスされます。9Pプロトコルは、ローカルファイルとリモートファイルの違いをなくします。Plan  9 のファイルシステムは、プロセスごとのプライベート名前空間を使用して構成されており、各プロセスが分散システムでリソースを提供する多数のファイルシステムを異なる視点で見ることができます。

Infernoオペレーティングシステムは、これらの概念をPlan 9と共有している 。

Windows は、 FAT、NTFS、exFAT、Live File System、およびReFSファイルシステムを使用します(最後の ReFS は、Windows Server 2012、Windows Server 2016、Windows 8、Windows 8.1、およびWindows 10でのみサポートされ、使用可能です。Windows は ReFS から起動することはできません)。

Windows は、ユーザー レベルでドライブ レターの抽象化を使用して、ディスクまたはパーティションを区別します。たとえば、パスC:\WINDOWS は、文字 C で表されるパーティション上のディレクトリWINDOWSを表します。ドライブ C: は、通常 Windows がインストールされ、起動されるプライマリハードディスク ドライブパーティションに最もよく使用されます。この「慣習」は非常に定着しており、オペレーティングシステムがインストールされているドライブが C であると想定する多くのアプリケーションにバグが存在します。ドライブ レターの使用、およびプライマリ ハードディスク ドライブ パーティションのドライブ レターとして「C」を使用する慣習は、文字 A と B が最大 2 台のフロッピー ディスク ドライブ用に予約されていたMS-DOSに遡ることができます。これは、1970 年代のCP/Mから派生し、最終的には 1967 年の IBM のCP/CMSに由来します。

VSAMの導入以前、OS/360システムではハイブリッド ファイルシステムが採用されていました。このシステムはリムーバブル ディスク パックを容易にサポートするように設計されていたため、1 つのディスク ( IBM 用語ではボリューム)上のすべてのファイルに関する情報は、ボリューム 目次(VTOC)と呼ばれるフラット システム ファイルに格納されていました。VTOC には、ファイルのすべてのメタデータが格納されます。その後、システム カタログの導入により階層的なディレクトリ構造が導入され、常駐ボリュームとリムーバブル ボリューム上のファイル (データセット) をオプションでカタログ化できるようになりました。カタログには、データセットを特定のボリュームに関連付ける情報のみが含まれています。ユーザーがオフライン ボリューム上のデータセットへのアクセスを要求し、適切な権限を持っている場合、システムは要求されたボリュームのマウントを試みます。カタログ化されたデータセットとカタログ化されていないデータセットの両方に、OPEN 要求に必要なボリューム ID が指定されていれば、カタログをバイパスして VTOC の情報を使用してアクセスできます。さらに後になって、アクセス速度を向上させるために VTOC にインデックスが作成されました。

VM/370のIBM Conversational Monitor System (CMS) コンポーネントは、仮想ディスク(ミニディスク)ごとに個別のフラットファイルシステムを使用します。ファイルデータと制御情報は分散して混在しています。アンカーとなるのは、マスターファイルディレクトリ(MFD) と呼ばれるレコードで、常にディスクの 4 番目のブロックに配置されます。当初、CMS は固定長の 800 バイトのブロックを使用していましたが、後のバージョンでは最大 4K のより大きなサイズのブロックを使用するようになりました。データレコードへのアクセスには 2 レベルの間接参照が必要で、ファイルのディレクトリエントリ (ファイルステータステーブル(FST) エントリと呼ばれる) が、個々のレコードのアドレスのリストを含むブロックを指し示します。

AS/400とその後継機種のデータは、単一レベルのストアにシステム仮想アドレス空間にマッピングされたシステムオブジェクトで構成されています。他のファイルシステムにあるディレクトリやファイルなど、多くの種類のオブジェクトが定義されています。ファイルオブジェクトは、他の種類のオブジェクトとともに、AS/400の統合リレーショナルデータベースのサポートの基盤を形成しています。

• RSRE FLEXファイルシステム- ALGOL 68で記述
• ミシガン端末システム（MTS）のファイルシステムは、次のような点で興味深い。(i) レコードの長さと行番号がメタデータとしてファイル内の各レコードに関連付けられた「行ファイル」を提供し、ファイル全体を読み書きする必要なく、行をファイル内のどこでも追加、置換、同じまたは異なる長さのレコードで更新、削除できる。(ii) プログラムキーを使用すると、ユーザーやグループに加えて、コマンドやプログラムにファイルを共有または許可できる。(iii) ファイルのデータとメタデータの両方を保護する包括的なファイルロック機構がある。^{[ 38 ] [ 39 ]}
• TempleOSは、Terry A. Davisによって作成されたファイルシステムであるRedSeaを使用しています。^{[ 40 ]}

ファイルシステムは保存可能なデータ容量を制限する。これは一般的に、ファイルシステムが設計された時点におけるストレージデバイスの標準的なサイズと、近い将来に想定されるサイズによって決まる。

ストレージ容量はほぼ指数関数的に増加しているため（ムーアの法則を参照）、新しいストレージデバイスは、導入後わずか数年で既存のファイルシステムの限界を超えることがよくあります。そのためには、容量が絶えず増加する新しいファイルシステムが必要となる。

容量が増加すると、必要な機能も増え、それに伴って複雑さも増します。ファイルシステムの複雑さは、一般的に利用可能なストレージ容量に比例します。容量の問題はさておき、1980年代初頭の50KBから512KBのストレージ容量を持つ家庭用コンピュータのファイルシステムは、数百ギガバイトの容量を持つ現代のストレージシステムには適していません。同様に、現代のファイルシステムも、これらの初期のシステムには適していません。なぜなら、現代のファイルシステム構造の複雑さによって、初期のストレージシステムの限られた容量がすぐに消費されてしまうからです。  

ファイルを現在とは異なるファイルシステムに保存することが、有利または必要となる場合があります。その理由としては、現在のファイルシステムの容量制限を超える容量要件の増加、ファイルシステムの制限を超えるパスの深さの増加、パフォーマンスや信頼性に関する考慮事項などが挙げられます。また、既存のファイルシステムをサポートしていない別のオペレーティングシステムへのアクセスを提供することも、理由の一つです。

階層型ファイルシステムでは、ファイルへのアクセスは、ファイルを含むディレクトリの分岐リストであるパスによって行われます。ファイルシステムによって、パスの深さの制限は異なります。また、ファイルシステムには、個々のファイル名の長さにも制限があります。

ファイル名が長いファイルや、パスの階層が深いファイルをあるファイルシステムから別のファイルシステムにコピーすると、望ましくない結果が生じる可能性があります。これは、コピーを実行するユーティリティがその差異をどのように処理するかによって異なります。