この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "ファイルシステム" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2021年5月)

オペレーティングシステム
主要項目
プロセス管理 割り込み メモリ管理 ファイルシステム デバイスドライバ ネットワーク セキュリティ グラフィカルユーザインタフェース 入出力
表 話 編 歴

ファイルシステム（英: file system、filesystem）は、コンピュータのリソースを操作するための、オペレーティングシステム (OS) が持つ機能の一つ。ファイルとは、主に補助記憶装置に格納されたデータを指すが、デバイスやプロセス、カーネル内の情報といったものもファイルとして提供するファイルシステムもある。

より正確に定義すれば、ファイルシステムは抽象データ型の集まりであり、ストレージ、階層構造、データの操作/アクセス/検索のために実装されたものである。ファイルシステムを特殊用途のデータベース管理システム (DBMS) と見なせるかどうかは議論があるが、ファイルシステムとデータベース管理システムには多くの共通点がある。

最も身近なファイルシステムは補助記憶装置上のもので、「セクタ」などと呼ばれる通常512バイトの固定サイズの「ブロック」の配列にアクセスするものである。ファイルシステムはこのセクタ群を使用してファイルやディレクトリを構成し、各セクタがどのファイルに使用され、使用されていないセクターはどれなのかを把握する必要がある。

しかし、ファイルシステム自体は記憶装置を利用する必要はない。ファイルシステムはデータへの操作とアクセスを提供するものであり、対象データが記憶装置に格納されているか (例えば、ネットワーク接続経由で) 動的に生成させるかは問題ではない^[1]。

ファイルシステムがストレージ上にあるかどうかに関わらず、一般的なファイルシステムはファイルのファイル名を束ねるディレクトリを持つ。通常、ファイル名は何らかのファイル・アロケーション・テーブルのインデックスと対応しており、それはMS-DOSのファイルシステムであるFATでも、Unix系ファイルシステムでのinodeでもそのようになっている。ディレクトリ構造は平坦な場合もあるし、ディレクトリの下にサブディレクトリのある階層構造の場合もある。いくつかのファイルシステムではファイル名も構造化されていて、拡張子やバージョン番号の文法が存在する。そうでない場合、ファイル名は単なる文字列であり、ファイル毎のメタデータは適当な場所に格納される。

階層型ファイルシステムはUNIXで有名なデニス・リッチーの初期の研究対象であった。それまでの実装では階層はあまり深くできなかった。例えばIBMの初期に生まれたデータベース管理システムであるIMSなどがそうである。UNIXの成功により、リッチーはその後のOS開発 (Plan 9やInferno) でもファイルシステムのコンセプトを様々な対象に広げていった。

初期のファイルシステムはファイルとディレクトリの生成、移動、削除といった機能を提供していた。ディレクトリへの追加リンクを生成する機能 (UNIXにおけるハードリンク)、親リンク (Unix系OSにおける..) の名称変更、ファイル間の双方向リンクの生成といった機能は当初は存在しなかった。

初期のファイルシステムはファイルの切捨て (内容を一部削除すること)、ファイルとファイルの連結、ファイルの生成、ファイルの移動、ファイルの削除、ファイルの更新などの機能を提供していた。ファイルの先頭へのデータ挿入 (prepend)、ファイルの先頭からの内容切捨て、任意の位置の内容の削除や挿入などといった機能は提供されていなかった。提供された操作は対称性に乏しく、どんな状況でも便利というものではない。例えばUNIXにおけるプロセス間のパイプはファイルシステム上には実装できない。というのもパイプはファイル先頭からの切捨てに対応できないためである。

ファイルシステムの基本操作への安全なアクセスはアクセス制御リストまたはケーパビリティに基づいて行われる。研究によれば、アクセス制御リストは完全なセキュリティを確保するのが困難といわれており、研究中の最新のOSではケーパビリティが使われる傾向にある。商用ファイルシステムはまだアクセス制御リストを使用している (コンピュータセキュリティ参照)。

また、アプリケーションソフトウェアの中にも、独自のファイルシステムを採用しているものがある。(FMRシリーズ・FM TOWNS用のワープロソフトウェアである「FM-OASYS」など)

ファイルシステムはディスクファイルシステム、分散ファイルシステム、特殊用途のファイルシステムに分類できる。

「ディスクファイルシステム」は、直接的か間接的かに関わらずコンピュータシステムに接続された補助記憶装置、特にハードディスク上にファイルを格納するためのものである。ディスクファイルシステムとしては、FAT、NTFS、HFS、ext2、ext3、ext4、WAFL（英語版）、ISO 9660、ODS-5（英語版）、UDF、HPFS、JFS、UFS、VTOC、XFSなどがある。ディスクファイルシステムの一部はジャーナルファイルシステムまたはバージョニングファイルシステムでもある。

データベースに基づいたファイルシステムである。メインフレームにあったVSAMのように以前からあるものであり、何ら新しいコンセプトではない。通常のファイルシステムでは、設計の時点でその情報構造が決め打ちで決定されている、ファイルの型、内容、作者などといったメタデータの代わりに、各データベース毎に設定されるメタデータに基づいた管理するが、従来のファイルシステムをその上にマップすることもできる。操作はデータベース操作言語 (例えばSQL) で行われる。データベース管理システムが通常のファイルにアクセスしてデータベースを操作するのに比べオーバーヘッドの削減による性能向上などが期待される。BFS、GnomeVFS、HFS+、WinFSなどがある。

ファイル操作により引き起こされる、ディスク上のデータ構造を操作するイベントやトランザクションを、それ用に確保してある領域にまず記録してから行うものである。多くの場合データ構造の操作は相互に関連しているため、「どれも全く行われていない」か「全て成功裏に完了した」のどちらかでなければ、壊れた状態ということになってしまう。例として銀行から銀行へ電子送金する場合を考えてみよう。銀行のコンピュータは、もう一方の銀行へ転送命令を「送信」し、自身の記録として転送開始したことを保持しておく。もし、コンピュータが記録を更新する前に何らかの原因でクラッシュしてしまった場合、転送したという記録が残っていないし、お金だけが失われる。トランザクションシステムは、このような間違いを、事前の記録と照合することにより検出して、切り戻すか再実行し、健全な状態を保とうとするシステムである。各トランザクションは記録され、どこで何をしたのかという完全な記録を残す。この種のファイルシステムはフォールトトレラント設計であることを意図して設計されているため、オーバーヘッドが大きくなる。

ネットワークに対応したOSの多くが、ファイル共有のためのプロトコルを備えている。これを分散ファイルシステムと呼ぶ。

Windowsで標準的なSMB/CIFS、あるいはMacintoshのAFP、UNIXのNFSなどが有名である。

こういったネットワークファイルシステムは、共有元のファイルシステムを抽象化した、別の一種のファイルシステムとして扱われる。

個々のOSが標準とするNTFS、UFS、HFS+、ext3、HPFS、BFSなどの差異も、Sambaなどを使ったファイル共有では実用上の問題はほとんど無くなる。ただし、ファイル名制限自体は存在し、また拡張属性等が利用できないなどの問題はあり得る。

なお、WindowsやmacOSを対象にしたNAS装置でも、内部のハードディスクドライブ (HDD) ではReiserFSやXFSなどが使われている場合が少なくない。

特殊用途のファイルシステムとは、ディスクファイルシステムでも分散ファイルシステムでもないものを意味する。ソフトウェアが動的にファイルを用意するようなシステムがこれに当たる。用途としてはプロセス間の通信のためだったり、一時的なファイル空間のためだったりする。

特殊用途のファイルシステムはUNIXのようなファイル中心のOSで主に使用されている。例えば一部のUNIX系システムで使用されている procfs (/proc) ファイルシステムは、プロセスや他のOS機能の情報へのアクセスを提供している。

ボイジャー計画などの深宇宙探査機ではデジタルテープに基づいた特殊なファイルシステムが使われた。最近の探査機カッシーニはリアルタイムオペレーティングシステム (RTOS) のファイルシステム (あるいはRTOSに影響されたファイルシステム) を使用している。マーズ・パスファインダーのローバーもそのようなRTOSファイルシステムを使用しているが、これらはフラッシュメモリに実装されている点が重要である。

ほとんどのオペレーティングシステム (OS) はファイルシステムを提供しており、ファイルシステムは最近のOSの重要な部分となっている。初期のマイクロコンピュータのOSではファイル管理がほとんど唯一の仕事であり、「DOS」というその名前にも現われている。初期のOSにはディスクオペレーティングシステムと呼ばれるファイルシステム相当の部分が存在していた。マイクロコンピュータによっては、その部分だけをロードして使用することができた。初期のOSでは、唯一の名前のないファイルシステムがサポートされていた。例えば、CP/Mにも独自のファイルシステムがあるが、改めて名前を付けるほどの機能は持っていない。

一般に、OSはファイルシステムに関する次の2種類のインタフェースを提供する。1種類目はプログラムのためにカーネルが提供するシステムコール群であり、2種類目はユーザによるファイル操作のための、コマンド群やグラフィカルユーザインタフェースによるツール (いわゆるファイルマネージャ等) などである。真に重要なのは前者である。なぜなら後者はOSによって提供される以外のプログラムを使っても何ら問題ないからである。しかし後者だけがインタフェースの全てであるかのように思われていることもまた、多いようである。

組み込み用途向けや、特定用途向けのOSでは、ファイルシステムをサポートしていなかったり、ファイルシステムをサポートしていても、実際の利用時にファイルシステムを使用しないこともある。このようなケースでは、コンピュータは外部記憶装置を持っていないか、持っていてもOSからは単なるデータストリームとして認識し、直接アドレスを指定することでアクセスされる。このように、ファイルシステムはコンピュータやOSにとって必須の機能ではない。

平坦なファイルシステムでは、ディレクトリが存在せず、ハードディスクドライブ (HDD) であれフロッピーディスクであれ、全てが唯一の階層に格納される。単純なシステムだが、ファイルの数が増えるにつれてユーザーがデータを分類して管理することが非常に困難となり、非能率的になった。

他の初期の小規模システムと同様、Mac OSは当初、平坦なファイルシステム、Macintosh File System（英語版） (MFS) を採用していた。そのバージョンのMac OSでは、Finderがあたかも階層があるかのようにファイルシステムを見せかけていた。MFSは即座に本当のディレクトリをサポートしたHierarchical File Systemに置き換えられた。

UNIXとUnix系OSは、各デバイスにデバイス名を設定するが、デバイス上のファイルにそれを使ってアクセスするわけではない。UNIXは仮想ファイルシステムを生成し、全てのデバイス上の全てのファイルがひとつの階層構造内にあるように見せかける。従って、UNIXにはひとつのルートディレクトリがあり、全てのファイルはその下のどこかに配置されるのである。さらにUNIXのルートディレクトリは物理的にデバイス上に存在している必要がない。それはそのシステムの1台目のディスクにあるとは限らず、そのシステム内にあるとも限らない。UNIXではルートディレクトリをネットワーク経由で共有することができる。

別のデバイス上のファイルにアクセスするため、最初にOSにそのデバイスのファイル群をディレクトリツリー上のどこに置くか (見せるか) を指示しなければならない。この処理をファイルシステムのマウント (英: mount) と呼ぶ。例えば、CD-ROM内のファイルにアクセスするには、OSに対して「このCD-ROMのファイルシステムを、このディレクトリの下にツリーとして見せろ」と指示しなければならない。このときに指定するディレクトリを「マウントポイント」と呼ぶ。Unix系システムには/mediaや/mntディレクトリがあることが多く、フロッピーディスクやCDといった媒体を一時的にマウントするのに使われる。マウントされるデバイスは何も格納されていないこともあるし、サブディレクトリがあるかもしれない。一般に、システムアドミニストレータ (すなわちスーパーユーザー)だけがファイルシステムのマウントを行うことができる。

Unix系OSにはマウント処理のためのソフトウェアやツールがあり、新たな機能も提供されている。そのひとつとして「自動マウント (英: auto-mount)」がある。

多くの場合、ルート以外のファイルシステムもブート直後からOSにとって必要とされる。全てのUnix系システムはブート時にファイルシステムをマウントする機能を提供している。システムアドミニストレータは、それらのファイルシステムをfstab（英語版）ファイルに定義しておく。fstabにはオプションやマウントポイントが記述される。

場合によっては、後で必要とされるとしてもブート時にファイルシステムをマウントする必要がないこともある。Unix系システムには要求されたときに初めてファイルシステムを自動的にマウントする機能もある。

可搬記憶媒体は非常に一般化してきた。可搬媒体は物理的に接続されていないコンピュータ間でプログラムやデータを転送することを可能とする。最も一般的なものとしてCD-ROMとDVDがある。それらが機器に挿入されたことを自動的に検知し、その中身がファイルシステムとして使用可能であることをチェックし、自動的にマウントするユーティリティも開発されてきた。

最新のUnix系システムでは「スーパーマウント (英: supermount)」と呼ばれる機能が登場している。実例としてthe Linux supermount-ng projectを参照されたい。例えば、スーパーマウントされたフロッピーディスクはシステムから物理的に取り去ることができる。通常、補助記憶装置は内容の同期を取る必要があり、その後にアンマウント (unmount) 処理をしてから取り去らなければならない。これに対して、スーパーマウントではアンマウントする必要が無く、続いて次の媒体を挿入することができる。システムは自動的にそれを検知しマウントポイント以下の内容を新たな媒体のものに変更する。

同様の機能として一部ユーザーが好んで使うのはautofsである。このシステムはスーパーマウントに似ていて、マウントコマンドを手で入力する必要がない。異なるのは、分散ファイルシステムなどを経由して使用する際の互換性に優れていて、媒体の挿入を検知するのではなく、アプリケーションがそのファイルシステムの中身にアクセスしようとしたときにマウントするようになっている点である。従って、ネットワークサーバなどで使われている。

Unix系OSではMS-DOS系のOSとは違い、仮想メモリのためのHDD利用に、仮想メモリファイルのほかにスワップファイルシステムも利用する。

MS-DOS系OSでは、HDDのパーティション内 (OSからドライブとして認識されるFATやNTFSのファイルシステム内) に、スワップ用の隠しシステムファイルを作成する。

Unix系OSでは、たとえばLinuxではスワップ用パーティションを用意し、mkswap、swaponコマンドで利用可能とする。 FreeBSDなどの場合は、BIOSから扱われるパーティションをスライスと呼称し、その中にさらに独自に管理する複数のパーティションとしてスワップファイルシステムを構築する。

macOSのファイルシステムはClassic Mac OSから継承したHFSX (HFS+) である。HFSXはメタデータが豊富で大文字/小文字保護をするファイルシステムである。macOSはPOSIXに準拠しているが、HFSXにもPOSIX ACL準拠のパーミッション情報が追加されている。HFSXにはジャーナルが追加されてファイルシステム構造の破損を防ぐようになり、自動的にフラグメント化したファイルを正規ブロックにするなどのアロケーション機能の最適化もいくつか導入されている。

ファイル名は最大255文字である。HFS+はファイル名の格納に独自のルールで正規分解したUnicodeを使用している。macOSではファイルフォーマットはファイル名のタイプコードや拡張子等から総合的に判断している。Mac OS X v10.5からはUTIを用いてより柔軟にフォーマットを判断する。

POSIX系のファイルシステムとは異なり、ファイルをディレクトリの相対位置でアクセスするため、理論上パス長に制限がない。ただ、基盤となるDarwinがUNIX互換を保つため、システムの多くの部分で1024文字を限界としている。Carbonを経由し、HFSXを直接アクセスする場合はこの限りではない。

HFSXには3種類のリンクがある。ハードリンクとシンボリックリンクとエイリアス（英語版）である。エイリアスはリンク先のファイルが移動されたり改名されたりしてもリンクし続けるようになっている。

Plan 9 from Bell Labs (Plan 9) はUNIXの長所を拡張して新たなアイデアを導入し、UNIXの欠点を修正したものとして計画された。

ファイルシステムの観点から言えば、UNIX的に何でもファイルとして扱うという思想は変わっていないが、Plan 9では本当に「すべて」がファイルとして扱われ、アクセスされる (つまりioctlもmmapもない)。ファイルインターフェイスを汎用化すると同時にそれを大幅に単純化している。例えば、シンボリックリンクもハードリンクもsuidも古い機能とされ (obsolete)、アトミックなcreate/open操作が導入された。重要な点はファイル操作がうまく定義されているためにioctlなどを排除できたことである。

また、9Pプロトコルによってローカルとリモートのファイルの違いが無くなっている (時間的な遅延だけは残っている)。このため、ネットワーク経由で別のコンピュータシステム上のデバイス (これもファイルとして表される) をローカルにあるデバイスと全く同じように操作することが可能となっている。従ってPlan 9の元では、複数のファイルサーバをひとつのファイルシステムに見せることができる。この「合成」ファイルシステムのサーバ群は、システムの単純さを保ちながらマイクロカーネルの利点を生かしてユーザー空間で動作することもできる。

Plan 9では全てのものがファイルとして抽象化されている。ネットワーク、グラフィックス、認証、暗号化など様々なサービスをファイル識別子経由の入出力で扱える。例えば、NATなしでIPスタックのゲートウェイシステムを構築したり、追加コードなしでネットワーク透過なウィンドウシステムを提供したりできる。

Plan 9のアプリケーションはFTPサイトからFTPサービスを受けることもできる。ftpfsサーバによってリモートのFTPサイトをローカルのファイルシステムにマウントすることができ、普通のファイルシステムとして扱えるのである。仮想的なファイルやディレクトリを合成するファイルサーバで /mail/fs/mbox をユーザーのメールボックスとするような電子メールシステムもある。wikifsはwikiへのファイルシステムインターフェイスを提供する。

これらのファイルシステムは、プロセス毎のプライベートな名前空間によって構成される。そのため、各プロセスは分散システムに存在する数々のファイルシステムを固有の観点で見ることができる。

Infernoは、これらの概念をPlan 9から受け継いでいる。

Windowsは、CP/M、次いでMS-DOSを継承して開発されており、MS-DOSのファイルシステムであったFATはWindowsでも用いられている。FATファイルシステムの古い版では、ファイル名に強い制限があり、FATでフォーマットできるディスクやパーティションのサイズにも強い制限があった。 MS-DOSがUnix的なファイル管理を導入した事から、以降のマイクロソフト製OSでは同様の方針が継承されている。

また、IBMとマイクロソフトで共同開発していたOS/2には、FATに加え、FATの欠点を補ったHPFSというファイルシステムが用意された。Windows NTでも、NT 4.0までHPFSをサポートした。

Windows NTにはその後、OS/2のHPFSをより進化させたNTFSが用意された。その結果、Windowsでは FATとNTFSという2種類のファイルシステムが存在することとなった。

WindowsはGUIを通してユーザーと対話するため、ディレクトリを「フォルダの一種」として扱い、フォルダアイコンでグラフィカルに表示している。

NTFSはACLベースのパーミッション制御を可能とした。ハードリンク、代替データストリーム、属性索引、クオータ管理、圧縮、ファイルシステム間のマウントポイント (ジャンクションと呼ばれる)、不良セクタの動的ホットフィックスなどがサポートされている。ただし、一部の仕様は未公開である。

Windowsでは、UNIX系のファイルシステムとは異なり、「ドライブレター」によってディスクやパーティションをユーザーに見せている。例えば C:\WINDOWS\ というパスはCドライブにある WINDOWS ディレクトリを意味している。

Cドライブは1台目のハードディスクパーティションを表すものとして使われることが多く、そこにブート時に起動されるWindowsが格納される。この「伝統」は非常に堅固に植えつけられているため、一時期のWindowsには必ずCドライブにインストールされるという仕様が存在することもあった。これは、MS-DOSから受け継がれた伝統で、AとBがフロッピーディスクドライブ用に予約されていたために Cドライブ以降がハードディスクとなったものである。ネットワークドライブにも同様のドライブ文字がマップされる。ただし、PC-9800シリーズおよびその互換機では、HDD上のWindowsをOSとして起動したときAドライブがHDDに割り当てられた。

Windows NT系OSでは、NTエグゼクティブレベルではドライブレターそのものは実体として存在しなくなった。従前のドライブレターは例えばC:ならば、デバイスオブジェクト\??\C:から\Device\HarddiskVolume1などのボリュームデバイスオブジェクトへのシンボリックリンクで、従来のWindowsと互換性を持たせている。Windows NT系でも見かけ上ドライブレターに縛られていると誤解される場合があるが、例えばボリュームにドライブレターを与えず、ジャンクションによって特定のディレクトリにボリュームを割り当てた場合、ドライブレターを介する事なくボリュームにアクセスできるといった形でNT系ではドライブレターが必須の要素で無くなった事を知ることが出来る。ただし、Win32サブシステムの制約により、Win32アプリはNTエグゼクティブレベルのディレクトリを起点にパス名を指定する事はできない。例えば、Win32サブシステムの制約を受けないInterixサブシステムでは可能。また、WAIK (Automated Installation Kit) を利用する事でC:\以外にもインストールする事も可能。

パーソナルコンピュータ (パソコン) ではハイバネーションという機能が使える場合がある。この機能を使うとメモリー内容をHDD等に保存して電源を落とし、再度電源投入した際に速やかに作業を再開できる。この為にはハイバネーションファイルを利用するものと、ハイバネーション用パーティションを作成するものが存在する。

ハイバネーション用パーティションを作成する場合は、特殊なファイルシステムとも考えられるが、実際には単にメモリーをベタ複製しているだけとも言える。

市販パソコンでは、リカバリー領域と呼ばれる隠しパーティションをもつものがある。

リカバリー領域のファイルシステムについての情報は通常、公開されていない。リカバリー領域をもつパソコンは実質すべてがWindows付属のため、Windows用のNTFSやFAT32等でフォーマットされていると推測される。

これについては、Files-11で解説する。

これについては、MVSファイルシステムで解説する。

IBM PC/ATやPC-9800シリーズ等ではHDDのパーティションごとの利用目的を判別しやすくするため、パーティションごとに番号を与えている。

この番号により、OSの起動時の、利用すべきパーティションの自動判別が速やかに行なわれる。

ただし、正常な設定が行なわれていない場合も考えて、実際のファイルシステム状況を分析して認識する処理が一般的。 具体的には、HPFSと同じパーティション番号を引き継いで開発されたNTFSのような計画上の問題もあった。

また、開発組織がまったく違うために、Linux用のスワップファイルシステムとサン・マイクロシステムズのSolarisのファイルシステムが同じ番号を持ってしまったような例もある。

こういった状況では、誤った認識でデータ破壊が起きる可能性がある。

ファイルシステム名	開発者	登場年	最初にサポートしたOS
RT-11	DEC	1973年	RT-11
FAT12	マイクロソフト	1977年	Microsoft Disk BASIC
ODS-2	DEC	1979年	VMS
UFS (FFS)	カーク・マキュージック	1983年	4.2BSD
HFS	Apple	1985年	Macintosh System 2.1
FAT16	マイクロソフト	1987年	MS-DOS 3.31
HPFS	IBM & マイクロソフト	1988年	OS/2
JFS	IBM	1990年	AIX[注釈 1]
VxFS	VERITAS	1991年	SVR4.0
NTFS	マイクロソフト	1993年	Windows NT
ext2	レミ・カール	1993年	Linux
UFS (FFFS)	カーク・マキュージック	1994年	4.4BSD
XFS	SGI	1994年	IRIX
UDF	ISO/Ecma International/OSTA	1995年	-
FAT32	マイクロソフト	1996年	Windows 95 OSR2[注釈 2]
HFS Plus	Apple	1998年	Mac OS 8.1
ext3	スティーブン・トウィーディ	1999年	Linux
VMFS	VMware	2000年	VMware ESX
ReiserFS	Namesys	2001年	Linux
UFS2	カーク・マキュージック	2002年	FreeBSD 5.0
HFSX	Apple	2003年	Mac OS X v10.3
ZFS	サン・マイクロシステムズ	2004年	Solaris
Reiser4	Namesys	2004年	Linux
NILFS	NTT	2005年	Linux
ext4	Mingming Cao, Dave Kleikamp, Alex Tomas, Andrew Morton他	2006年	Linux
exFAT	マイクロソフト	2006年	Windows Embedded CE 6.0
btrfs	オラクル	2007年	Linux
HAMMER-FS	Matthew Dillon (en:Matthew Dillon)	2008年	DragonFly BSD 2.0
ReFS	マイクロソフト	2012年	Microsoft Windows Server 2012
APFS	Apple	2017年	macOS High Sierra

	最大ファイル名長	ディレクトリ名に使える文字種[注釈 3]	最大パス名長	最大ファイルサイズ	最大ボリュームサイズ[注釈 4]
Btrfs	255バイト	NUL 以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	16 – EiB	16 EiB
ext2	255バイト	NUL 以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	16 – GiB – 2 – TiB[注釈 4]	2 TiB – 32 TiB
ext3	255バイト	NUL 以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	16 GiB – 2 TiB[注釈 4]	2 TiB – 32 TiB
ext4	255バイト	NUL 以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	16 GiB – 16 TiB	1 EiB
FAT12	8.3形式 (または255文字)[注釈 7]	NUL 以外の全Unicode[注釈 7][注釈 5]	制限の定義無し[注釈 6]	32 – MiB	1 MiB – 128 MiB
FAT16	8.3形式 (または255文字)[注釈 7]	NUL 以外の全Unicode[注釈 7][注釈 5]	制限の定義無し[注釈 6]	2 GiB	16 MiB – 4 GiB
FAT32	8.3形式 (または255文字)[注釈 7]	NUL 以外の全Unicode[注釈 7][注釈 5]	制限の定義無し[注釈 6]	4 GiB	512 MiB – 2 TiB[注釈 8]
HFS+	255文字 (UTF-16)[注釈 9]	任意の正しいUnicode[注釈 10][注釈 5]	無制限	8 EiB	8 EiB[注釈 11]
HFS	31バイト	: 以外の任意のバイト	無制限	2 GiB	2 TiB
JFS	255バイト	NUL以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	8 EiB	512 TiB – 4PiB
NILFS	255文字	NUL 以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	8 EiB	8 EiB
NTFS	255文字	NUL 以外の全Unicode	Unicodeで32,767文字 (ファイル名やディレクトリ名はそれぞれ255文字まで)[注釈 6]	16 EiB[注釈 12]	16 EiB[注釈 12]
ReFS	255文字 (UTF-16)	NUL 以外の全Unicode	Unicodeで32,767文字 (ファイル名やディレクトリ名はそれぞれ255文字まで)[注釈 6]	16 EiB	3.76ZiB
Reiser4	不明	不明	制限の定義無し[注釈 6]	x86では 8 TiB	不明
ReiserFS	4032バイト/255バイト (VFSによる制限)	NUL 以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	8 TiB[注釈 13]	16 TiB
RT-11	12バイト	A-Z, 0-9, $	16バイト	33,554,432バイト (65536 * 512)	33,554,432バイト
UDF	255バイト	NUL 以外の全Unicode	1023バイト[注釈 14]	16 EiB	不明
UFS (FFS)	255バイト	NUL 以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	4 GiB	256 TiB
UFS (FFFS)	255バイト	NUL 以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	4 GiB – 256 TiB	256 TiB
UFS2	255バイト	NUL 以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	512 GiB – 32 PiB	1 YiB
VxFS	255バイト	NUL以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	16 EiB	不明
XFS	255バイト	NUL以外の任意のバイト[注釈 5]	制限の定義無し[注釈 6]	8 EiB[注釈 15]	8 EiB[注釈 15]

	ファイル所有者名を保持	POSIX式ファイルパーミッション	作成時タイムスタンプ (TS)	最新アクセス時TS	最新メタデータ更新TS	最新アーカイブTS	ACL	セキュリティ/MACラベル	拡張ファイル属性/フォーク	チェックサム/ECC
RT-11	×	×	×	○	○	×	×	×	×	×
FAT12	×	×	○	○	×	×	×	×	×[注釈 16]	×
FAT16	×	×	○	○	×	×	×	×	×[注釈 16]	×
FAT32	×	×	○	○	×	×	×	×	×	×
HPFS	○[注釈 17]	×	○	○	×	×	×	不明	○	×
NTFS	○	×[注釈 18]	○	○	○	×	○	不明	○	×
ReFS	○	×	○	○	○	×	○	不明	○	○
HFS	×	×	○	×	×	○	×	×	○	×
HFS+	○	○	○	○	○	○	○	不明	○	×
UFS (FFS)	○	○	×	○	○	×	×	×	×	×
UFS (FFFS)	○	○	×	○	○	×	○[注釈 19]	○[注釈 19]	×[注釈 20]	×
UFS2	○	○	○	○	○	×	○[注釈 19]	○[注釈 19]	○	×
ext2	○	○	×	○	○	×	○[注釈 21]	○[注釈 21]	○	×
ext3	○	○	×	○	○	×	○[注釈 21]	○[注釈 21]	○	×
ext4	○	○	○	○	○	×	○	○	○	○
NILFS	○	○	○	×	○	×	×	×	×	○
ReiserFS	○	○	×	○	○	×	○[注釈 21]	○[注釈 21]	○	×
Reiser4	○	○	×	○	○	×	×	×	×	×
XFS	○	○	×	○	○	×	○	○[注釈 21]	○	×
JFS	○	○	○	○	○	×	○	○	○	×
VxFS	○	○	○	○	○	×	○	不明	○[注釈 21]	×
UDF	○	○	○	○	○	○	○	×	○	×

	ハードリンク	ソフトリンク	ブロック・ジャーナリング または	メタデータのみのジャーナリング	大文字/小文字区別	大文字/小文字保護	ファイル更新ログ	インクリメンタル・スナップショット	XIP
RT-11	×	×	×	×	×	×	×	×	×
FAT12	×	×	×	×	×	×	×	×	×
FAT16	×	×	×	×	×	△	×	×	×
FAT32	×	×	×	×	×	△	×	×	×
HPFS	×	×	×	×	×	○	×	不明	×
NTFS	○	△[注釈 22]	×	○	○[注釈 23]	○	○	○	不明
ReFS	×	△	不明	不明	○	○	不明	不明	不明
HFS+	△	○	×	○[注釈 24]	△[注釈 25]	○	○[注釈 26]	×	×
UFS (FFS)	○	○	×	×	○	○	×	×	×
UFS (FFFS)	○	○	×	×	○	○	×	×	×
UFS2	○	○	×	×[注釈 27]	○	○	×	○	不明
ext2	○	○	×	×	○	○	×	×	○[注釈 28]
ext3	○	○	○[注釈 29]	○	○	○	×	×	不明
ext4	○	○	○[注釈 30]	○	○	○	×	×	不明
NILFS	○	○	○[注釈 31]	×	○	○	×	○	不明
ReiserFS	○	○	○[注釈 32]	○	○	○	×	×	不明
Reiser4	○	○	○	×	○	○	×	不明	不明
XFS	○	○	×	○	○	○	○	○	不明
JFS	○	○	×	○	○[注釈 33]	○	×	不明	不明
ODS-2	○	○[注釈 34]	×	○	×	×	○	○	×
UDF	○	○	○[注釈 35]	○[注釈 35]	○	○	×	×	○
VxFS	○	○	○	×	○	○	○	○[注釈 36]	不明
ZFS	○	○	○[注釈 37]	×[注釈 37]	○	○	×	○	×

	Tail Packing	透過的圧縮	ブロックの分割割り当て	遅延アロケーション	エクステント（英語版）	可変ファイルブロックサイズ[注釈 38]
FAT12	×	×[注釈 39]	×	×	×	×
FAT16	×	×[注釈 39]	×	×	×	×
FAT32	×	×[注釈 39]	×	×	×	×
HPFS	×	×	×	×	○	×
NTFS	×	○	△	×	○	×
ReFS	不明	×	不明	不明	不明	×
HFS+	×	×	不明	×	○	×
UFS (FFS)	×	×	● 8:1[注釈 40]	×	×	×
UFS (FFFS)	×	×	● 8:1[注釈 40]	×	×	×
UFS2	×	×	● 8:1[注釈 40]	×	×	○
ext2	×	×[注釈 41]	×[注釈 42]	×	×	×
ext3	×	×	×[注釈 42]	×	×	×
ext4	×	×	○	○	○	×
NILFS	×	×	×	○	×	×
ReiserFS	○	×	×	×	×	×
Reiser4	○	×[注釈 43]	×	○	○[注釈 44]	×
XFS	×	×	×	○	○	×
JFS	×	×	○	×	○	×
VxFS	×	×	不明	×	○	×
UDF	×	×	×	不明[注釈 45]	○	×
ZFS	×[注釈 46]	○	不明	○[注釈 47]	×	○

• ファイルシステム
  • ジャーナリングファイルシステム
  • バージョニングファイルシステム
  • 仮想ファイルシステム
  • 分散ファイルシステム
• ファイルシステムAPI
• ファイル編成法
• ファイルフォーマット
• 拡張子
• 記憶装置
• パーティション