ファイルシステム

ウィキペディア

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2024/01/10 14:36 UTC 版)

分類

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

ディスクファイルシステム

「ディスクファイルシステム」は、直接的か間接的かに関わらずコンピュータシステムに接続された補助記憶装置、特にハードディスク上にファイルを格納するためのものである。ディスクファイルシステムとしては、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ファイルシステムを使用しているが、これらはフラッシュメモリに実装されている点が重要である。

脚注

注釈

^ IBMは1990年にAIX 3.1 リリース時に JFS を導入。これは現在 JFS1 と呼ばれている。新たなJFS (JFS2などと呼ばれる) はLinux移植版がベースで、1999年にOS/2 Warp Server for e-Business で最初に出荷された。
^ マイクロソフトはWindows 95 OSR2で最初に FAT32 を導入し、Windows 98で本格的に採用した。
^ ディスク上のディレクトリ構造自体に制限がある。特にInstallable File System（英語版）のドライバはファイル名とディレクトリ名に制限がある。また、OSがファイルシステムの種類に寄らず全体に制限を加えていることもある。MS-DOS, Microsoft Windows, OS/2は全ファイルシステムについて \ / : ? * " > < | NUL といった文字をファイル名やディレクトリ名に使えない。UNIXおよびLinuxは全ファイルシステムについて / NUL という文字をファイル名やディレクトリ名に使えない。
^ ^a ^b ^c ブロックサイズやクラスタサイズが可変なファイルシステムについては、ブロックサイズの最大と最小のときのボリュームサイズの範囲を示す。例えば、FATではディスク上のクラスタサイズが512 B – 128 KBである。しかし、Installable File System（英語版）の一部のドライバやOSによっては32 KBより大きいクラスタサイズをサポートしていない。
^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j ^k ^l ^m ⁿ ^o ^p これらのファイルシステムでは、. と .. というディレクトリエントリ名は特別な意味を持つ。そのような名前のディレクトリエントリは禁じられておらず、むしろ普通のディレクトリエントリ名として存在している。しかし、これらはある意味で固定のエントリで固定の値を持ち、ディレクトリ生成時に自動的に生成される。これらのエントリがないディレクトリは壊れていると見なされる。
^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j ^k ^l ^m ⁿ ^o ^p ^q ^r ディスク上の構造としては制限はないが、一部のInstallable File SystemのドライバやOSによっては制限している場合がある。MS-DOSはFAT12やFAT16に関して260バイト以上のパス名をサポートしていない。Windows NTはNTFSに関して32767文字 (UTF-16) 以上のパス名をサポートしていない。POSIXの規定では「NULL終端で1024バイトを保証すること」とされているが、上限についての記述はない。
^ ^a ^b ^c ^d ^e ^f FAT12、FAT16、FAT32の実装が、長いファイル名 (LFN) をサポートしているかどうかに依存する。OS/2, MS-DOS, Windows 95, Windows 98 のDOSモードやLinuxの msdosドライバではLFNをサポートしていないので、ファイル名は8.3形式に制限される (制限を越えるとベース名も拡張子も空白で埋められる)。また、NUL (ディレクトリ終端マーカー) を含むこともできず、文字5 (削除済みファイルマーカーとして使われる文字229の代用) も含むことができない。短い名前では小文字も含まれない。
^ FAT32のパーティションをこのサイズで作成して使用することは可能だが、ソフトウェアによっては 32 GiB以上のFAT32用パーティションを作成できない。有名なのは、Windows XPのインストールプログラムである (これはNTFSの利用を促すための意図的な制限であると思われる)。これを回避するには Windows Meの緊急用ブートディスクのFDISKを使う必要がある。
^ Mac OSはHFS+のボリューム上のファイル名を扱う関数群を2種類用意している。ひとつは完全なUnicodeの名前を返し、もうひとつは従来互換を保つために31バイトまでの名前を返すものである。
^ HFS+は任意のUnicode文字を許すためにエスケープシーケンスをサポートしている。古いソフトウェアからはそのエスケープシーケンスがそのまま見える。
^ HFS+のボリュームサイズはほぼ無制限であるが、Mac OSには以下のような制限がある。Mac OS 8, 9：2 TiB。Mac OS X 10、10.1：2 TiB。Mac OS X 10.2：8 TiB。Mac OS X 10.3、10.4：16 TiB。ファイルサイズの最大はこれより若干小さい (Mac OS 8では2 GB)。フォルダ内の最大ファイル数 (フォルダ数) は以下の通り。 Mac OS 8, 9：2^15 (32767)。macOS：2^31。しかし、通常最大ボリュームサイズをブロックサイズで割った値で制限される。
^ ^a ^b これはディスク上の構造による制限である。Windows NT用NTFSドライバはボリュームサイズを256 TiB、ファイルサイズを16 TiB に制限している。
^ ReiserFSの理論上の最大ファイルサイズは1 EiBだが、[1]によれば、「ページキャッシュの制限により、32ビット int のアーキテクチャでは 8 TiB に制限される」
^ この制限は新しい版では大きくなるかもしれない。
^ ^a ^b Linux 2.4 では XFS の最大ファイルサイズは 64 TiB だが、Linux 2.4 自体が最大 2 TiB までしかサポートしていない。IRIXにはこの制限はない。
^ ^a ^b 一部のInstallable File SystemドライバやOSによってはFAT12やFAT16で拡張ファイル属性をサポートしていない。OS/2とWindows NTはFAT12/FAT16向けに拡張ファイル属性をサポートしている ("EA DATA. SF"擬似ファイルを使ってそのためにアロケートされたクラスタを予約している)。他のOSのファイルシステムドライバではサポートしていない。
^ f-nodeにはユーザー識別子用フィールドがあるが、OS/2 Warp Server 以外では使われていない。
^ NTFSのアクセス制御リストは単純なPOSIX式ファイルパーミッションで表せることは表現できるが、Services for UNIX や Cygwin を使わないとPOSIXのインターフェイスがサポートされない。
^ ^a ^b ^c ^d アクセス制御リストとMACラベルは拡張属性として実装される。
^ FreeBSD 4.XなどのOSでは拡張属性をparallel backing fileを使って実装している。
^ ^a ^b ^c ^d ^e ^f ^g ^h 一部のInstallable File SystemドライバやOSによっては、これらのファイルシステムについて拡張属性、ACL、セキュリティラベルをサポートしていない。2.6.x以前のLinuxはこれらをサポートしていないか、パッチが必要である。
^ NTFS 5.0 以降では、junctions を生成でき、(個々のファイルではなく) ディレクトリ全体をローカルに管理するドライブのいずれかのディレクトリツリーにマップすることができる。これは reparse points と呼ばれる機能で実現されており、ファイル名解析部分を柔軟に拡張可能となっている。
^ NTFS自体は大文字/小文字を区別するが、Windowsサブシステムは互換性を維持するため大文字/小文字の差異しかないファイル名を生成できないようになっている。新しいファイルを書き込みのためにオープンしたとき、大文字/小文字の差異を無視したときに同じ名前となるファイルが既に存在すると、その既存のファイルの内容が消されて書き込みに使われてしまう。Services for UNIXを使うと、完全な大文字/小文字の区別が行われる。
^ メタデータのみのジャーナリングは、Max OS X v10.2.2 の HFS+ドライバから導入された。デフォルト値でジャーナリングが有効となったのはMac OS X v10.3以降である。
^ 一般に大文字/小文字を区別していると思われがちであるが、HFS+は基本的には区別していない。単に大文字/小文字の違いを保護しているだけである。Mac OS X v10.3のコマンド newfs_hfs -s で大文字/小文字を区別するファイルシステムを作成できる。HFSXという別のファイルシステムは、HFS+を改良したもので、こちらは大文字/小文字を区別する。Technical Note TN1150: HFS Plus Volume FormatではHFS+とHFSXについて技術的詳細を論じている。
^ Mac OS X v10.4とMac OS X v10.3はファイル変更ログを提供している (ファイルシステムソフトウェアの機能であり、ボリューム形式自体がサポートしているわけではない)。fsloggerを参照されたい。
^ NetBSDの"Soft dependencies" (softdep) およびFreeBSDの"soft updates"はジャーナリングせずにメタデータの一貫性を常に保つ機能がある。
^ Linux 2.6.12 以降。
^ デフォルトでは無効になっている。
^ デフォルトでは無効になっている。
^ ログ構造化ファイルシステムであり，メタデータだけでなく全てのファイルデータの更新がインクリメンタルに記録される。
^ ReiserFSの完全なブロック・ジャーナリングは Linux 2.6.8 で追加された。
^ 一部のInstall File SystemドライバやOSによってはJFSでの大文字/小文字区別をサポートしていない。OS/2はサポートしておらず、Linux はマウント時のオプションで指定できる。
^ "aliases"と呼ばれている。
^ ^a ^b UDFはログ構造ファイルシステムであり、ファイルシステム全体がジャーナルであるかのように振舞う。
^ VxFSはオプションとして「ストレージ・チェックポイント」と呼ばれる機能を提供している。これは高機能のファイルシステム・スナップショット機能である。
^ ^a ^b ZFSはトランザクション・ファイルシステムであり、コピー・オン・ライト方式であるため、ジャーナルを使わなくてもディスク上の状態は常に正常である。しかし、同期書き込みを指定されたときなどの性能向上のため、ログを実装している。
^ ここで言う可変ブロックサイズとは、ファイル毎にブロックサイズを変更できるシステムである。エクステント（英語版）と似ているが実装方針が微妙に異なる。UFS2の現状の実装はリードオンリーのみである。
^ ^a ^b ^c DOS 6 の DoubleSpace や Windows 95およびWindows 98の DriveSpace は FAT におけるデータ圧縮機能だが、マイクロソフトが既にサポートしていない。
^ ^a ^b ^c 8:1以外の「ブロック：フラグメント」のサイズ比もサポートしているが、8:1が最も一般的で多くの実装で推奨されている。
^ 1997年から利用可能なe2comprというパッチのセットでext2でのブロック単位のデータ圧縮が可能となる。しかし、これがLinuxカーネルのメインラインにマージされたことはない。
^ ^a ^b フラグメントは計画されていたが、ext2とext3に実装されたことはない。
^ Reiser4はデータ圧縮を実装しているが、そのためのVFS APIが提供されていない。
^ "extents"モードで実現。
^ UDFの実装に依存する。
^ ZFSの論理ブロックベースの圧縮を有効にすると、ファイルの最後尾ブロックに対してTail-Packingのように働く。
^ コピーオンライトであるため、ZFSは全ての書き込みについて遅延アロケーションを行う。