Unix File System

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
UFS
開発者 CSRG
正式名 UNIX file system
導入 (4.2BSD)
構造
ディレクトリ テーブル
限度
最大ファイル サイズ 273バイト
(8 ZiB)
最大ファイル名長 255 バイト
最大ボリューム サイズ 273バイト
(8 ZiB)
特徴
対応OS FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, A/UX
テンプレートを表示

Unix File SystemUFS)とは、UNIX系列のOSにおいて使用されるファイルシステムである。

また固有のファイルシステムを指す言葉ではなく、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/SolarisSVR4UP-UXTru64 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 と FreeBSDNetBSDOpenBSDDragonFly 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 を使っていた。それより派生したアップルMac OS X では、HFS+の代替として UFS を使うこともできたが、Mac OS X v10.5 以降では UFS でフォーマットされたボリュームにインストールできなくなった。また、UFS ボリュームにインストールされた10.5より前のバージョンの Mac OS X を10.5以降のバージョンにアップグレードすることもできなくなった。[3]

脚注[編集]

参考文献[編集]

外部リンク[編集]