ファイルシステム

出典: フリー百科事典『ウィキペディア（Wikipedia）』

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

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

目次 1 概要 2 ファイルシステムの分類 2.1 ディスクファイルシステム 2.2 データベースファイルシステム 2.3 トランザクションファイルシステム 2.4 ネットワークファイル共有とファイルシステム 2.5 特殊用途のファイルシステム 3 ファイルシステムとオペレーティングシステム 3.1 平坦なファイルシステム 3.2 UNIXとUNIX系システムのファイルシステム 3.2.1 スワップファイルシステム 3.2.2 Mac OS X のファイルシステム 3.3 ベル研究所の Plan 9 のファイルシステム 3.4 Microsoft Windows のファイルシステム 3.4.1 ハイバネーション領域 3.4.2 リカバリー領域 3.5 OpenVMS のファイルシステム 3.6 MVS（IBM汎用コンピュータ）のファイルシステム 4 ファイルシステムと対応するパーティション番号 5 比較 5.1 一般情報 5.2 諸元 5.3 メタデータ 5.4 機能 5.5 アロケーションとレイアウト 5.6 注 6 関連項目

[編集] 概要

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

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

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

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

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

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

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

[編集] ファイルシステムの分類

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

[編集] ディスクファイルシステム

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

[編集] データベースファイルシステム

新しいファイル管理コンセプトとしてデータベースに基づいたファイルシステムがある。階層構造管理の替わりにファイルはその属性で識別される。属性とは、ファイルの型、内容、作者などといったメタデータである。従って、ファイル検索はSQLまたは自然言語で行われる。例えば、BFS、Gnome VFS、HFS+、WinFSなどがある。

[編集] トランザクションファイルシステム

これは、イベントやトランザクションをファイルに記録する特殊なファイルシステムである。通常、一回の何らかの操作で複数のファイルが変更される。多くの場合それらの変更は相互に関連しており、それら変更を同時に反映するのが重要と言える。例として銀行から銀行へ電子送金する場合を考えてみよう。銀行のコンピュータは、もう一方の銀行へ転送命令を「送信」し、自身の記録として転送開始したことを保持しておく。もし、コンピュータが記録を更新する前に何らかの原因でクラッシュしてしまった場合、転送したという記録が残っていないし、お金だけが失われる。トランザクションシステムは、このような間違いを両方の銀行で訂正して正しいトランザクションを再実行するものである。各トランザクションは記録され、どこで何をしたのかという完全な記録を残す。この種のファイルシステムはフォールトトレラントであることを意図して設計されているため、オーバヘッドが大きくなる。

[編集] ネットワークファイル共有とファイルシステム

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

クライアントPCで標準的なWindowsネットワーク(SMB,NetBIOS,NetBEUI)、あるいはAppleのAppleTalkやApple File Protocol、UNIXのNFSなどが有名。かつてはNovell NetwareのIPX/SPXも大きなシェアを持っていた。

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

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

なお、WindowsやMacOSXを対象にしたNAS装置でも、内部のHDDではRaiserFSやXFSなどが使われている場合が少なくない。

[編集] 特殊用途のファイルシステム

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

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

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

[編集] ファイルシステムとオペレーティングシステム

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

オペレーティングシステムはファイルシステムとユーザーの間のインターフェイスを提供する必要がある。このインターフェイスはテキストベースでもよいし（シェルやOpenVMSのDCLのようなCUI）、グラフィカルでもよい（GUIベースのファイルマネージャなど）。グラフィカルなインターフェイスでは、フォルダのメタファーがディレクトリを表すものとして使用される。

[編集] 平坦なファイルシステム

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

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

[編集] UNIXとUNIX系システムのファイルシステム

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

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

UNIX系オペレーティングシステムにはマウント処理のためのソフトウェアやツールがあり、新たな機能も提供されている。そのひとつとして「自動マウント auto-mounting」がある。

1. 多くの場合、root以外のファイルシステムもブート直後からOSにとって必要とされる。全てのUNIX系システムはブート時にファイルシステムをマウントする機能を提供している。システムアドミニストレータは、それらのファイルシステムをfstabファイルに定義しておく。fstabにはオプションやマウントポイントが記述される。
2. 場合によっては、後で必要とされるとしてもブート時にファイルシステムをマウントする必要がないこともある。UNIX系システムには要求されたときに初めてファイルシステムを自動的にマウントする機能もある。
3. 可搬記憶媒体は非常に一般化してきた。可搬媒体は物理的に接続されていないコンピュータ間でプログラムやデータを転送することを可能とする。最も一般的なものとしてCD-ROMとDVDがある。それらが機器に挿入されたことを自動的に検知し、その中身がファイルシステムとして使用可能であることをチェックし、自動的にマウントするユーティリティも開発されてきた。
4. 最新のUNIX系システムでは「スーパーマウント supermouting」と呼ばれる機能が登場している。実例として the Linux supermount-ng project を参照されたい。例えば、スーパーマウントされたフロッピーディスクはシステムから物理的に取り去ることができる。通常、補助記憶装置は内容の同期を取る必要があり、その後にアンマウント(unmount)処理をしてから取り去らなければならない。これに対して、スーパーマウントではアンマウントする必要が無く、続いて次の媒体を挿入することができる。システムは自動的にそれを検知しマウントポイント以下の内容を新たな媒体のものに変更する。
5. 同様の機能として一部ユーザーが好んで使うのは autofs である。このシステムはスーパーマウントに似ていて、マウントコマンドを手で入力する必要がない。異なるのは、分散ファイルシステムなどを経由して使用する際の互換性に優れていて、媒体の挿入を検知するのではなく、アプリケーションがそのファイルシステムの中身にアクセスしようとしたときにマウントするようになっている点である。従って、ネットワークサーバなどで使われている。

[編集] スワップファイルシステム

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

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

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

[編集] Mac OS X のファイルシステム

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

ファイル名は最大255文字である。HFS+はファイル名の格納にUnicodeを使用している。Mac OS X ではファイルフォーマットはメタデータかファイル名のタイプコード（Windowsの拡張子相当）で示される。

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

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

[編集] ベル研究所の Plan 9 のファイルシステム

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 から受け継いでいる。

[編集] Microsoft Windows のファイルシステム

Microsoft Windowsはそれ以前のオペレーティングシステムから継承して開発されてきた（CP/M→MS-DOS）。また、ファイルシステムとユーザーインターフェイスの考え方を他からも導入してきた（UNIX、OS/2)。そのため、Windowsには FAT (File Allocation Table) と NTFS という二種類のファイルシステムが存在する。FATファイルシステムの古い版では、ファイル名に制限があり、FATでフォーマットできるディスクやパーティションのサイズにも制限があった。

Windows NTオペレーティングシステムで導入されたNTFSはACLベースのパーミッション制御を可能とした。ハードリンク、複数ファイルストリーム、属性索引、クオータ管理、圧縮、ファイルシステム間のマウントポイント（ジャンクションと呼ばれる）、不良セクタの動的ホットフィックスなどがサポートされているが、全てについて充分な文書が公開されているわけではない。

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

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

[編集] ハイバネーション領域

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

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

[編集] リカバリー領域

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

パーティション内のファイルシステムについての情報は公開されないのが通例。ただし、これが提供されるパソコンは実質すべてがWindows付属である。そのため、Windows用のNTFSやFAT32等でフォーマットされている可能性は高い。

[編集] OpenVMS のファイルシステム

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

[編集] MVS（IBM汎用コンピュータ）のファイルシステム

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

[編集] ファイルシステムと対応するパーティション番号

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

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

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

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

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

[編集] 比較

[編集] 一般情報

ファイルシステム名	開発者	登場年	最初にサポートしたOS
RT-11	DEC	1973年	RT-11
FAT12	マイクロソフト	1977年	Microsoft Disk BASIC
ODS-2	DEC	1979年	VMS
UFS	カーク・マキュージック	1983年	4.2BSD
HFS	アップルコンピュータ	1985年	Mac OS
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
UFS1	カーク・マキュージック	1994年	4.4BSD
XFS	SGI	1994年	IRIX
UDF	ISO/ECMA/OSTA	1995年	-
FAT32	マイクロソフト	1996年	Windows 95b[2]
HFS+	アップルコンピュータ	1998年	Mac OS 8.1
ext3	スティーブン・トウィーディ	1999年	Linux
ReiserFS	Namesys	2001年	Linux
UFS2	カーク・マキュージック	2002年	FreeBSD 5.0
ZFS	サン・マイクロシステムズ	2004年	Solaris
Reiser4	Namesys	2004年	Linux
NILFS	NTT	2005年	Linux
ファイルシステム	開発者	登場年	最初にサポートしたOS

[編集] 諸元

	最大ファイル名長	ディレクトリ名に使える文字種[3]	最大パス名長	最大ファイルサイズ	最大ボリュームサイズ [4]
RT-11	12バイト	A-Z, 0-9, $	16バイト	33,554,432バイト (65536 * 512)	33,554,432バイト
FAT12	255バイト [5]	NUL 以外の全Unicode [5] [6]	制限の定義無し [7]	32MB	1MB～32MB
FAT16	255バイト [5]	NUL 以外の全Unicode [5] [6]	制限の定義無し [7]	2GB	16MB～2GB
HFS	31バイト	: 以外の任意のバイト	無制限	2GB	2TB
FAT32	255バイト [5]	NUL 以外の全Unicode [5] [6]	制限の定義無し [7]	4GB	512MB～2TB [8]
NTFS	255文字	NUL 以外の全Unicode	Unicodeで32,767文字（ファイル名やディレクトリ名はそれぞれ255文字まで） [7]	16EB [9]	16EB [9]
HFS+	255文字（UFT-16）[10]	任意の正しいUnicode [11] [6]	無制限	8EB	8EB [12]
UFS	255バイト	NUL 以外の任意のバイト [6]	制限の定義無し [7]	4GB	256TB
UFS1	255バイト	NUL 以外の任意のバイト [6]	制限の定義無し [7]	4GB～256TB	256TB
UFS2	255バイト	NUL 以外の任意のバイト [6]	制限の定義無し [7]	512GB～32PB	1YB
ext2	255バイト	NUL 以外の任意のバイト [6]	制限の定義無し [7]	16GB～2TB[4]	2TB～32TB
ext3	255文字	NUL 以外の任意のバイト [6]	制限の定義無し [7]	16GB～2TB[4]	2TB～32TB
ReiserFS	4032バイト/255文字	NUL 以外の任意のバイト [6]	制限の定義無し [7]	8TB[13]	16TB
Reiser4	不明	不明	制限の定義無し [7]	x86では 8TB	不明
XFS	255バイト	NUL以外の任意のバイト [6]	制限の定義無し [7]	8EB[14]	8EB[14]
JFS	255バイト	NUL以外の任意のバイト [6]	制限の定義無し [7]	8EB	512TB～4PB
VxFS	255バイト	NUL以外の任意のバイト [6]	制限の定義無し [7]	16EB	不明
UDF	255バイト	NUL 以外の全Unicode	1023バイト [15]	16EB	不明
	最大ファイル名長	ディレクトリ名に使える文字種[3]	最大パス名長	最大ファイルサイズ	最大ボリュームサイズ [4]

[編集] メタデータ

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

[編集] 機能

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

[編集] アロケーションとレイアウト

	Tail Packing	可逆圧縮	ブロックの分割割り当て	遅延アロケーション	エクステント	可変ファイルブロックサイズ [36]
FAT12	×	× [37]	×	×	×	×
FAT16	×	× [37]	×	×	×	×
FAT32	×	× [37]	×	×	×	×
HPFS	×	×	×	×	○	×
NTFS	×	○	△	×	○	×
HFS+	×	×	不明	×	○	×
UFS	×	×	● 8:1 [38]	×	×	×
UFS1	×	×	● 8:1 [38]	×	×	×
UFS2	×	×	● 8:1 [38]	×	×	○
ext2	×	× [39]	× [40]	×	×	×
ext3	×	×	× [40]	×	×	×
ReiserFS	○	×	×	×	×	×
Reiser4	○	× [41]	×	○	○ [42]	×
XFS	×	×	×	○	○	×
JFS	×	×	○	×	○	×
VxFS	×	×	不明	×	○	×
UDF	×	×	×	不明 [43]	○	×
ZFS	× [44]	○	不明	○ [45]	×	○
	Tail Packing	可逆圧縮	ブロックの分割割り当て	遅延アロケーション	エクステント	可変ファイルブロックサイズ [36]

[編集] 注

1. ↑ IBMは1990年にAIX 3.1 リリース時に JFS を導入。これは現在 JFS1 と呼ばれている。新たなJFS（JFS2などと呼ばれる）は Linux移植版がベースで、1999年にOS/2 Warp Server for e-Business で最初に出荷された。
2. ↑ マイクロソフトはWindows 95 OSR2（OEM Service Release 2）で最初に FAT32 を導入し、Windows 98 で最初から採用した。
3. ↑ ^3.0 3.1 ディスク上のディレクトリ構造自体に制限がある。特にInstallable File Systemのドライバはファイル名とディレクトリ名に制限がある。また、オペレーティングシステムがファイルシステムの種類に寄らず全体に制限を加えていることもある。MS-DOS, Microsoft Windows, OS/2は全ファイルシステムについて \ / : ? * " > < | NUL といった文字をファイル名やディレクトリ名に使えない。UNIXおよびLinuxは全ファイルシステムについて / NUL という文字をファイル名やディレクトリ名に使えない。
4. ↑ ^{4.0 4.1 4.2 4.3} ブロックサイズやクラスターサイズが可変なファイルシステムについては、ブロックサイズの最大と最小のときのボリュームサイズの範囲を示す。例えば、FATではディスク上のクラスターサイズが512B～128KBである。しかし、Installable File Systemの一部のドライバやOSによっては 32KB以上のクラスターサイズをサポートしていない。
5. ↑ ^{5.0 5.1 5.2 5.3 5.4 5.5} FAT12、FAT16、FAT32の実装が、いわゆる 8.3ファイル名でないLFNをサポートしているかどうかに依存する。OS/2, MS-DOS, Windows 95, Windows 98 ではLFNをサポートしていないので、DOSモードやLinuxの msdosドライバではファイル名は11バイトに制限される（制限を越えるとベース名も拡張子も空白で埋められる）。また、NUL（ディレクトリ終端マーカー）を含むこともできず、文字 299（削除済みファイルマーカー）も含むことができない。短い名前では小文字も含まれない。
6. ↑ ^{6.00 6.01 6.02 6.03 6.04 6.05 6.06 6.07 6.08 6.09 6.10 6.11 6.12} これらのファイルシステムでは、"." と ".." というディレクトリエントリ名は特別な意味を持つ。そのような名前のディレクトリエントリは禁じられておらず、むしろ普通のディレクトリエントリ名として存在している。しかし、これらはある意味で固定のエントリで固定の値を持ち、ディレクトリ生成時に自動的に生成される。これらのエントリがないディレクトリは壊れていると見なされる。
7. ↑ ^{7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13} ディスク上の構造としては制限はないが、一部の Installable File System のドライバやOSによっては制限している場合がある。MS-DOSはFAT12やFAT16に関して260バイト以上のパス名をサポートしていない。Windows NT は NTFS に関して 32767バイト以上のパス名をサポートしていない。
8. ↑ FAT32のパーティションをこのサイズで作成して使用することは可能だが、ソフトウェアによっては 32GB以上の FAT32用パーティションを作成できない。有名なのは、Windows XPのインストールプログラムである。これを回避するには Windows Meの緊急用ブートディスクのFDISKを使う必要がある。
9. ↑ ^9.0 9.1 これはディスク上の構造による制限である。Windows NT用NTFSドライバはボリュームサイズを256TB、ファイルサイズを16TB に制限している。
10. ↑ Mac OS はHFS+のボリューム上のファイル名を扱う関数群を2種類用意している。ひとつは完全なUnicodeの名前を返し、もうひとつは従来互換を保つために31文字までの名前を返すものである。
11. ↑ HFS+は任意のUnicode文字を許すためにエスケープシーケンスをサポートしている。古いソフトウェアからはそのエスケープシーケンスがそのまま見える。
12. ↑ HFS+のボリュームサイズはほぼ無制限であるが、Mac OS には以下のような制限がある。Mac OS 8、9：2TB。Mac OS X 10、10.1：2TB。Mac OS X 10.2：8TB。Mac OS X 10.3、10.4：16TB。ファイルサイズの最大はこれより若干小さい（Mac OS 8 では 2GB）。フォルダ内の最大ファイル数（フォルダ数）は以下の通り。 Mac OS 8、9：2^15 (32767)。Mac OS X：2^31。しかし、通常最大ボリュームサイズをブロックサイズで割った値で制限される。
13. ↑ ReiserFSの理論上の最大ファイルサイズは1EBだが、[1]によれば、「ページキャッシュの制限により、32ビット int のアーキテクチャでは 8TB に制限される」
14. ↑ ^14.0 14.1 Linux 2.4 では XFS の最大ファイルサイズは 64TB だが、Linux 2.4 自体が最大 2TB までしかサポートしていない。IRIXにはこの制限はない。
15. ↑ この制限は新しい版では大きくなるかもしれない。
16. ↑ ^16.0 16.1 一部の Installable File System ドライバやOSによってはFAT12やFAT16で拡張ファイル属性をサポートしていない。OS/2とWindows NTはFAT12/FAT16向けに拡張ファイル属性をサポートしている（"EA DATA. SF"擬似ファイルを使ってそのためにアロケートされたクラスターを予約している）。他のOSのファイルシステムドライバではサポートしていない。
17. ↑ f-nodeにはユーザー識別子用フィールドがあるが、OS/2 Warp Server 以外では使われていない。
18. ↑ NTFSのAccess Control Listは単純なPOSIX式ファイルパーミッションで表せることは表現できるが、Services for UNIX や Cygwin を使わないとPOSIXのインターフェイスがサポートされない。
19. ↑ ^{19.0 19.1 19.2 19.3} Access Control List と MACラベルは拡張属性として実装される。
20. ↑ FreeBSD 4.X などのOSでは拡張属性を parallel backing file を使って実装している。
21. ↑ ^{21.0 21.1 21.2 21.3 21.4 21.5 21.6 21.7} 一部の Installable File System ドライバやOSによっては、これらのファイルシステムについて拡張属性、ACL、セキュリティラベルをサポートしていない。2.6.x 以前の Linux はこれらをサポートしていないか、パッチが必要である。
22. ↑ NTFS 5.0 以降では、junctions を生成でき、（個々のファイルではなく）ディレクトリ全体をローカルに管理するドライブのいずれかのディレクトリツリーにマップすることができる。これは reparse points と呼ばれる機能で実現されており、ファイル名解析部分を柔軟に拡張可能となっている。
23. ↑ NTFS自体は大文字/小文字を区別するが、Windows標準のファイルシステムドライバは互換性を維持するため大文字/小文字の差異しかないファイル名を生成できないようになっている。新しいファイルを書き込みのためにオープンしたとき、大文字/小文字の差異を無視したときに同じ名前となるファイルが既に存在すると、その既存のファイルの内容が消されて書き込みに使われてしまう。Services for UNIXを使うと、完全な大文字/小文字の区別が行われる。
24. ↑ メタデータのみのジャーナリングは Max OS 10.2.2 の HFS+ドライバから導入された。デフォルト値でジャーナリングが有効となったのは Mac OS 10.3 以降である。
25. ↑ 一般に大文字/小文字を区別していると思われがちであるが、HFS+は基本的には区別していない。単に大文字/小文字の違いを保護しているだけである。Mac OS 10.3 のコマンド newfs_hfs -s で大文字/小文字を区別するファイルシステムを作成できる。HFSX という別のファイルシステムは、HFS+を改良したもので、こちらは大文字/小文字を区別する。Technical Note TN1150: HFS Plus Volume Format ではHFS+とHFSXについて技術的詳細を論じている。
26. ↑ Mac OS Tiger (10.4) と後の版 Panther (10.3) はファイル変更ログを提供している（ファイルシステムソフトウェアの機能であり、ボリューム形式自体がサポートしているわけではない）。fsloggerを参照されたい。
27. ↑ NetBSDの"Soft dependencies" (softdep)およびFreeBSDの"soft updates"はジャーナリングせずにメタデータの一貫性を常に保つ機能がある。
28. ↑ Linux 2.6.12 以降。
29. ↑ デフォルトでは無効になっている。
30. ↑ ReiserFSの完全なブロック・ジャーナリングは Linux 2.6.8 で追加された。
31. ↑ 一部の Install File System ドライバやOSによってはJFSでの大文字/小文字区別をサポートしていない。OS/2はサポートしておらず、Linux はマウント時のオプションで指定できる。
32. ↑ "aliases"と呼ばれている。
33. ↑ ^33.0 33.1 UDFはログ構造ファイルシステムであり、ファイルシステム全体がジャーナルであるかのように振舞う。
34. ↑ VxFSはオプションとして「ストレージ・チェックポイント」と呼ばれる機能を提供している。これは高機能のファイルシステム・スナップショット機能である。
35. ↑ ^35.0 35.1 ZFSはトランザクション・ファイルシステムであり、コピー・オン・ライト方式であるため、ジャーナルを使わなくてもディスク上の状態は常に正常である。しかし、同期書き込みを指定されたときなどの性能向上のため、ログを実装している。
36. ↑ ^36.0 36.1 ここで言う可変ブロックサイズとは、ファイル毎にブロックサイズを変更できるシステムである。エクステントと似ているが実装方針が微妙に異なる。UFS2の現状の実装はリードオンリーのみである。
37. ↑ ^{37.0 37.1 37.2} DOS 6 の DoubleSpace や Windows 95およびWindows 98の DriveSpace は FAT におけるデータ圧縮機能だが、マイクロソフトが既にサポートしていない。
38. ↑ ^{38.0 38.1 38.2} 8:1 以外の「ブロック：フラグメント」のサイズ比もサポートしているが、8:1 が最も一般的で多くの実装で推奨されている。
39. ↑ 1997年から利用可能な e2compr というパッチのセットで ext2 でのブロック単位のデータ圧縮が可能となる。しかし、これが Linux カーネルのメインラインにマージされたことはない。
40. ↑ ^40.0 40.1 フラグメントは計画されていたが、ext2 と ext3 に実装されたことはない。
41. ↑ Reiser4はデータ圧縮を実装しているが、そのための VFS API が提供されていない。
42. ↑ "extents"モードで実現。
43. ↑ UDFの実装に依存する。
44. ↑ ZFSの論理ブロックベースの圧縮を有効にすると、ファイルの最後尾ブロックに対して Tail-Packing のように働く。
45. ↑ コピーオンライトであるため、ZFSは全ての書き込みについて遅延アロケーションを行う。

[編集] 関連項目

• ファイルフォーマット
• ジャーナリングファイルシステム
• 参照カウント
• 拡張子
• Virtual File System
• 分散ファイルシステム
• ファイルシステムAPI
• 記憶装置
• パーティション