Unix File System

Unix File System (UFS) とは、Unix系オペレーティングシステム (OS) において使用されるファイルシステムである。

UFS
開発者	CSRG
正式名	UNIX file system
導入	(4.2BSD)
構造
ディレクトリ	テーブル
限度
最大ファイル サイズ	273バイト (8 ZiB)
最大ファイル名長	255 バイト
最大ボリューム サイズ	273バイト (8 ZiB)
特徴
対応OS	FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, A/UX

また固有のファイルシステムを指す言葉ではなく、Version 7 Unixのファイルシステムおよびそこから派生した一連のファイルシステムの総称である。 一般にUFSと呼ぶ場合は4.2BSDで実装された Fast File System (FFS) のことを指す場合が多く^[要出典]、他にはFFFS、UFS2、UFS Logging等が存在する。

設計

UFSボリュームは以下の部分から構成される。

• パーティションの先頭数ブロックはブートブロックとして予約されている（ファイルシステムとは別に初期化する必要がある）。
• UFSであることを示すマジックナンバーやファイルシステムの構成を示す基本的な値や統計情報やチューニングパラメータを含むスーパーブロック。
• シリンダグループの集合体。各シリンダグループには以下のような構成要素がある。
  • スーパーブロックのバックアップコピー
  • シリンダグループのヘッダ。そのシリンダグループの統計情報、フリーリストなど、スーパーブロックに似た情報がある。
  • inode群。それぞれにファイル属性情報が格納されている。
  • データブロック群。

inodeは順に番号を振られている。ルートディレクトリのinodeの後の何個かのinodeは歴史的理由により予約されている。

ディレクトリファイルは、そのディレクトリにあるファイルのファイル名と対応するinode番号だけを格納している。ファイルについての全てのメタデータはinodeにある。

背景

初期のUNIXで使っていたファイルシステムは、単にFSと呼ばれていた。FSにはブートブロック、スーパーブロック、inode群、データブロック群だけが存在していた。初期のUNIXで使っていた小さいディスクではこれで十分であったが、技術の進歩と共にディスク容量が大きくなり、inodeのある部分とデータブロックの間をヘッドが行き来することによる効率の激しい低下が無視できなくなってきた。BSDではこれを最適化したFFS (Fast File System) を導入した。これは、シリンダグループという概念を発明したもので、ディスクを小さい部分に分け、それぞれにinodeとデータブロックを配置する構成である。

BSD FFSは、データブロックとそれに関連するメタデータを同じシリンダグループに配置することでアクセスを局所化しようとしたものであり、理想的には1つのディレクトリのコンテンツが（データブロックも対応するメタデータも）同じか近いシリンダグループに配置され、ディレクトリのコンテンツがディスク全体に分散配置されることによるフラグメンテーションを低減する。

スーパーブロックには性能に関わるパラメータとして、トラック数、セクタ数、回転速度、ヘッド速度、トラック間のセクタ配置などの情報がある。完全に最適化されたシステムでは、プラッタの回転を待つ間に近接するトラック間でヘッドを移動させ、不連続に配置されているセクタを読むことができる。

ディスク容量が大きくなると、セクタレベルの最適化は効果を発揮できなくなってきた（特に、トラック当たりのセクタ数が一定でない場合）。ディスクが大容量化しファイルが巨大化すると、読み込みが断片化することがさらに大きな問題となってきた。これに対してBSDは当初、ファイルシステムのブロックサイズを1セクタから1Kに増やし (4.0BSD)、FFSではそれをさらに8Kに増やした。これにはいくつかの効果がある。ファイルのセクタが連続確保される可能性が大きくなる。ファイルのブロックをリストで保持するオーバーヘッドを低減できる。ブロック数を保持するビットフィールドで表現できるファイルサイズ上限が大きくなる。

ブロックサイズが大きくなると、小さいファイルがたくさんある場合は領域を無駄に消費することになる。そこでBSDではブロックレベルのフラグメント化を導入した。ファイルの最後の部分はブロックサイズ未満になるので、それをブロックを分割したサブブロックに格納することで領域を有効活用できるようにする。これをブロックのサブアロケーション、テールマージ、テールパッキングなどとも呼ぶ。

実装

SunOS/Solaris、SVR4、UP-UX、Tru64 UNIX などの商用UNIXではUFSを導入した。その多くは独自の拡張を施したため、別のベンダーのUFSを認識することができない。しかし、元のブロックサイズやデータフィールド幅は保持されていることが多く、ある程度の互換性は保持されている。しかし、ディスクを異機種間で共有する場合、事前に互換性を確認することが重要である。

サン・マイクロシステムズはSolaris 7でUFSにジャーナリングファイルシステムの機能を追加したUFS Loggingを導入した。Solaris UFSには他にも巨大ファイルを扱うための拡張、巨大ディスクを扱うための拡張など様々な拡張がなされている。

カーク・マキュージックはFreeBSDのFFS層とUFS層を拡張し、UFS2を開発した。これは64ビットのブロックポインタを追加し（ボリュームの最大を8ゼタバイトに拡大）、ブロックサイズを可変化し、フラグフィールドを拡張し、'birthtime'というタイムスタンプを新たに追加するなどの拡張をしたものである。FreeBSD 5.0ではUFS2がデフォルトとなった。FreeBSDではさらに soft updates とUFS1およびUFS2両方でのスナップショット機能を導入している。これらはNetBSDにも移植された。OpenBSDでは、2.9からsoft updatesをサポートし^[1]、4.2からUFS2をサポートしている^[2]。

4.4BSDとFreeBSD、NetBSD、OpenBSD、DragonFly BSDなどのBSD系システムでは、UFS1とUFS2の実装は2つの層に分かれている。上位層はディレクトリ構造と inode構造内のメタデータ（パーミッション、所有者情報など）を扱い、下位層はinodeとして実装されているデータコンテナを扱う。これは従来からのFFSとLFSというログ構造ファイルシステムで共通部分を共有するための仕組みである。上位層を "UFS" と呼び、下位層を "FFS" または "LFS" と呼ぶ。この場合、下位層にFFSを使っている場合は全体をFFSと呼び、下位層にLFSを使っている場合は全体を LFS と呼ぶことがある。

LinuxでもBSDなどとの互換性のためにUFSを実装しているが、UFSには共通の標準実装があるわけではないので、Linux がサポートしているのは読み込みが中心であり、書き込みは完全サポートしていない。Linux の ext2 ファイルシステムはUFSの影響を受けている（実際、4.4BSDから派生した一部のシステムでは、UFSを上位層とし、ext2 をFFSやLFSなどのように下位層として使えるものもある）。

NeXTStepもBSDから派生しているため、UFS を使っていた。それより派生したAppleのmacOSでは、HFS+の代替としてUFSを使うこともできたが、Mac OS X v10.5以降ではUFSでフォーマットされたボリュームにインストールできなくなった。また、UFSボリュームにインストールされたv10.5より前のバージョンのmacOSをv10.5以降のバージョンにアップグレードすることもできなくなった^[3]。