Loading article…
| 開発者 | CSRG |
|---|---|
| フルネーム | UNIX ファイルシステム |
| 紹介された | 4.2BSDの場合 |
| 構造 | |
| ディレクトリの内容 | テーブル |
| 制限 | |
| 最大ボリュームサイズ | 2 73バイト (8 ZiB ) |
| 最大ファイルサイズ | 2 73バイト (8 ZiB ) |
| ファイル名の最大長 | 255 バイト |
| 特徴 | |
| 記録された日付 | UFS1およびUFS2: 最終アクセス時刻 (atime)、最終変更時刻 (mtime)、最終inode変更時刻 (ctime)、UFS2: inode作成時刻 (birthtime) [1] |
| 日付範囲 | UFS1: 1901年12月14日～2038年1月18日、UFS2:エポックからの64ビット符号付き整数オフセット[1] |
| 日付解決 | UFS1とUFS2:ナノ秒[1] |
| 他の | |
| サポートされている オペレーティングシステム | A/UX、DragonFly BSD、FreeBSD、FreeNAS、NAS4Free、HP-UX、NetBSD、NeXTSTEP、Linux、OpenBSD、illumos、Solaris、SunOS、Tru64 UNIX、UNIX System V、Orbis OS、その他 |
Unixファイル システム( UFS ) は、多くのUnixおよびUnix 系オペレーティング システムでサポートされているファイル システムのファミリです。これは、バージョン 7 Unixで使用されていた元のファイル システムの遠い子孫です。
デザイン
UFS ボリュームは次の部分で構成されます。
- パーティションの先頭の数ブロックはブートブロック用に予約されています（ファイルシステムとは別に初期化する必要があります）
- スーパーブロックには、 UFS ファイルシステムであることを示すマジックナンバーと、このファイルシステムのジオメトリと統計、動作調整パラメータを記述するその他の重要な数字が含まれています。
- シリンダー グループのコレクション。各シリンダー グループには次のコンポーネントがあります。
i ノードは 0 から順に番号が付けられます。i ノード 0 は未割り当てのディレクトリ エントリ用に予約されています。i ノード 1 は、従来の UNIX バージョンでは不良ブロック ファイルの i ノードでした。その後に、常に i ノード 2 であるルート ディレクトリの i ノードと、i ノード 3 である lost+found ディレクトリの i ノードが続きます。
ディレクトリ ファイルには、ディレクトリ内のファイル名のリストと各ファイルに関連付けられた inode のみが含まれます。すべてのファイルメタデータは inode に保存されます。
歴史と進化
初期の Unix ファイルシステムは単にFSと呼ばれていました。FS には、ブート ブロック、スーパーブロック、inodeの塊、およびデータ ブロックのみが含まれていました。これは、初期の Unix が設計された小さなディスクではうまく機能しましたが、テクノロジが進歩してディスクが大きくなると、inode の塊とそれらが参照するデータ ブロックの間をヘッドが行ったり来たりすることでスラッシングが発生するようになりました。当時バークレーの大学院生だったMarshall Kirk McKusick は、V7 FS レイアウトを最適化してBSD 4.2の FFS (Fast File System) を作成しました。これは、シリンダ グループを発明することで行われました。シリンダ グループでは、ディスクをより小さなチャンクに分割し、各グループに独自の inode とデータ ブロックを持たせました。[2] [3]
BSD FFS の目的は、関連するデータ ブロックとメタデータを同じシリンダ グループにローカライズし、理想的にはディレクトリのすべての内容 (すべてのファイルのデータとメタデータの両方) を同じシリンダ グループまたは近くのシリンダ グループにローカライズして、ディレクトリの内容がディスク全体に分散されることで発生する断片化を減らすことです。
スーパーブロックのパフォーマンス パラメータには、トラックとセクターの数、ディスクの回転速度、ヘッド速度、トラック間のセクターの配置などが含まれます。完全に最適化されたシステムでは、プラッターが回転するのを待つ間に、ヘッドを近接したトラック間で移動させて、交互のトラックから散在するセクターを読み取ることができます。
ディスクがどんどん大きくなるにつれて、セクターレベルの最適化は時代遅れになりました (特に、リニアセクター番号とトラックあたりの可変セクターを使用したディスクの場合)。ディスクとファイルのサイズが大きくなると、断片化された読み取りがさらに問題になりました。この問題に対処するために、BSD は当初、4.0 BSD でファイルシステムのブロック サイズを 1 セクターから 1 K に増やし、FFS ではファイルシステムのブロック サイズを 1 K から 8 K に増やしました。これにはいくつかの効果があります。ファイルのセクターが連続している可能性が大幅に高まります。ファイルのブロックをリストするためのオーバーヘッドの量が削減され、任意の数のブロックで表現できるバイト数が増加します。
ブロックの最大数は固定ビット幅ブロック番号によって制限されるため、より大きなディスクサイズも可能です。ただし、ブロックサイズが大きいと、各ファイルが少なくとも 1 つのブロックを占有する必要があるため、多くの小さなファイルを含むディスクではスペースが無駄になります。このため、BSD はブロックレベルの断片化 (ブロックサブアロケーション、テールマージ、テールパッキングとも呼ばれます) を追加しました。これにより、複数のファイルからの最後の部分的なデータブロックが、複数のほとんど空のブロックではなく、単一の「フラグメント」ブロックに格納されるようになります。[4]
Berkeley FFS の成果は他の Unix ベンダーに広く採用され、そこから派生したファイルシステム ファミリは総称して UFS と呼ばれています。
実装
SunOS / Solaris、System V Release 4、HP-UX、Tru64 UNIXなどの一部のプロプライエタリ Unix システムや、illumosなどのオープン Unix 派生システムのベンダーは、UFS を採用しています。そのほとんどは、他のベンダーの Unix バージョンでは認識されない可能性のあるプロプライエタリな拡張機能を追加して、UFS を独自の用途に適応させています。多くの[どれ? ]は、元の UFS と同じブロック サイズとデータ フィールド幅を引き続き使用しているため、プラットフォーム間である程度の読み取り互換性が残っています。[どれ? ] [引用が必要] [誰によると? ]実装間の互換性は、全体としてはせいぜい不完全です。[誰によると? ]
Solaris 7では、Sun MicrosystemsはUFSロギングを組み込み、 UFSにファイルシステムジャーナリングを導入しました。これは、Solarisとillumosの現在のバージョンでも利用可能です。[5] Solaris UFSには、大容量ファイルや大容量ディスクなどの拡張機能もあります。
FreeBSD、NetBSD、OpenBSD、DragonFlyBSDなどの4.4BSD およびそこから派生したBSD Unix システムでは、UFS1 および UFS2 の実装は、ディレクトリ構造を提供し、inode 構造内のメタデータ (権限、所有権など) をサポートする上位層と、inode として実装されたデータ コンテナーを提供する下位層の 2 つの層に分割されています。これは、共通機能の共有コードを使用して、従来の FFS とLFSログ構造ファイル システムの両方をサポートするために行われました。上位層は「UFS」と呼ばれ、下位層は「FFS」および「LFS」と呼ばれます。これらのシステムの一部では、「FFS」という用語は FFS 下位層と UFS 上位層の組み合わせに使用され、「LFS」という用語は LFS 下位層と UFS 上位層の組み合わせに使用されます。
Kirk McKusick は、ブロック再割り当てを実装しました。これは、書き込みが完了する直前にファイル システム内のブロックを並べ替える技術で、断片化を減らし、ファイル システムの経年劣化を制御します。また、従来の同期モードのようにパフォーマンスを制限せずにファイル システムの一貫性を維持するメカニズムであるソフト アップデートも実装しました。これには、クラッシュや電源障害後のファイル システム チェックの必要性を減らすという副次的な効果があります。障害後の残りの問題を克服するために、バックグラウンド fsck ユーティリティが導入されました。
UFS2 では、Kirk McKusick とPoul-Henning Kamp がFreeBSD FFS と UFS レイヤーを拡張し、64 ビット ブロック ポインター (ボリュームを最大 8ゼビバイトまで拡張可能)、可変サイズ ブロック (エクステントと同様)、拡張フラグ フィールド、追加の「誕生時刻」スタンプ、拡張属性サポート、および POSIX1.e ACL を追加しました。FreeBSD 5.0 以降では、UFS2 がサポートされる UFS バージョンになりました。FreeBSD では、UFS1 と UFS2 の両方に対してソフト アップデートとファイル システムスナップショットを作成する機能も導入されました。これらはその後 NetBSD に移植されましたが、最終的にソフト アップデート (NetBSD ではソフト依存関係と呼ばれます) は NetBSD 6.0 から削除され、代わりに NetBSD 5.0 で FFS に追加された、より複雑でないファイル システム ジャーナリング メカニズムであるWAPBL (ログとも呼ばれます) が採用されました。 OpenBSDはバージョン2.9 [6]からバージョン7.4でサポートが中止されるまでソフトアップデートをサポートし、 [7]バージョン4.2以降ではUFS2 (FFS2) をサポートしていました (ACLなし)。[8] OpenBSDは現在UFS2をデフォルトのUFSバージョンにしており、6.7リリースに含まれる予定です。[9] FreeBSD 7.0以降、UFSはgjournal GEOMプロバイダーを使用したファイルシステムジャーナリングもサポートしています。FreeBSD 9.0ではソフトアップデート (SU+J) に加えて軽量ジャーナリングのサポートが追加され、バックグラウンドfsckとNFSv4 ACLの必要性が大幅に軽減されました。
FreeBSD、NetBSD、OpenBSD、DragonFly BSD には、 Ian Dowse が開発したDirhashシステムも含まれています。このシステムは、ディレクトリ検索を高速化するためにメモリ内のハッシュ テーブルを維持します。Dirhash は、UFS の大きなディレクトリに関連するいくつかのパフォーマンスの問題を軽減します。
Linux には、他の Unix との読み取りレベルでのバイナリ互換性のために UFS 実装が含まれていますが、UFS に対するベンダー拡張の標準実装がないため、Linux は UFS への書き込みを完全にサポートしていません。ネイティブの Linux ext2ファイルシステムは UFS1 にヒントを得ていますが、フラグメントをサポートしておらず、ソフトアップデートを実装する予定もありません。[引用が必要] (一部の 4.4BSD 派生システムでは、UFS レイヤーは、FFS や LFS を使用できるのと同様に、ext2 レイヤーをコンテナーレイヤーとして使用できます。)
BSD由来のNeXTStepもUFSのバージョンを使用していました。AppleのMac OS Xでは、独自のファイルシステムであるHFS+の代替として利用できました。しかし、 Mac OS X Leopardでは、UFSフォーマットのボリュームにMac OS Xをインストールできなくなりました。さらに、UFSフォーマットのボリュームにインストールされた古いバージョンのMac OS XをLeopardにアップグレードすることはできません。アップグレードするには、起動ボリュームを再フォーマットする必要があります。[10] Mac OS XでUFSとしてフォーマットされたディスクには4GBのファイル制限がありました。Mac OS X Lionでは、UFSのサポートは完全に廃止されました。[11]
参照
参考文献
引用
- ^ abc "[base] /Head/Sys/Ufs/Ufs/Dinode.h の内容".
- ^ 「オープンソース: オープンソース革命からの声」1999 年 3 月 29 日。
- ^ McKusick, KM; Joy, W; Leffler, S; Fabry, R (1984 年 8 月). 「UNIX 用の高速ファイル システム」(PDF) . ACM Transactions on Computer Systems . 2 (3): 181–197. doi :10.1145/989.990. S2CID 222285164 . 2013 年 4 月 8 日閲覧。
- ^ Allen, Hervey (2005-06-20). 「UFS2 とソフト アップデートの組み合わせは強力です」(PDF)。FreeBSD入門、PacNOG I ワークショップ、追加トピック。ネットワーク スタートアップ リソース センター。p. 23。2013-04-08に取得。
- ^ 「UFS ロギング」。Oracleドキュメント。2022年 9 月 27 日閲覧。
- ^ 「OpenBSD 2.9 リリース」。OpenBSD。2001年6 月 1 日。2013 年 4 月 8 日閲覧。
- ^ 「将来の VFS 作業のためにソフト アップデートが無効化されました」。OpenBSD_Journal。2023年 7 月 5 日。2024年 3 月 9 日閲覧。
- ^ 「OpenBSD 4.2 リリース」。OpenBSD。2007 年 11 月 1 日。2013 年 4 月 8 日閲覧。
- ^ 「FFS2 をデフォルトのファイルシステムにする」 OpenBSD. 2020-04-05 . 2020-04-07閲覧。
- ^ 「アーカイブ — Mac OS X 10.5 Leopard: UFS フォーマットのボリュームへのインストール」Apple, Inc. 2012-06-12 . 2013-04-08に閲覧。
- ^ 「Lion は、組み込みユーティリティまたはディスクユーティリティを使用してディスクイメージをマウントしません」。Appleサポートコミュニティ。Apple 、Inc。2011年 8 月 5 日。2013年 12 月 24 日閲覧。
文献
- Marshall Kirk McKusick、William N. Joy、Samuel J. Leffler、Robert S. Fabry。UNIX 用の高速ファイル システム(PDF) (技術レポート)。コンピュータ システム研究グループ、コンピュータ サイエンス部門、電気工学およびコンピュータ サイエンス学部、カリフォルニア大学バークレー校。2013年 4 月 8 日閲覧。
{{cite tech report}}: CS1 maint: 複数の名前: 著者リスト (リンク) - Marshall Kirk McKusick、William N. Joy、Samuel J. Leffler、Robert S. Fabry (1984 年 8 月)。「UNIX 用の高速ファイル システム」( PDF)。ACM Transactions on Computer Systems。2 ( 3) : 181–197。doi :10.1145/989.990。S2CID 222285164。2013年 4月8 日に取得。
{{cite journal}}: CS1 maint: 複数の名前: 著者リスト (リンク) - Marshall Kirk McKusick、Keith Bostic、Michael J. Karels、John S. Quarterman (1996)。「ローカルファイルシステム、ローカルファイルストア」。4.4BSDオペレーティングシステムの設計と実装。Addison - Wesley。ISBN 0-201-54979-4。
- Marshall Kirk McKusick および Gregory R. Ganger (1999 年 6 月)。「ソフト アップデート: 高速ファイルシステムでの同期書き込みのほとんどを排除する手法」(PDF)。FREENIXトラックの議事録: 1999 USENIX 年次技術会議。pp. 1–18。2013年 4 月8 日に取得。
- Marshall Kirk McKusick (2002 年 2 月)。「バックグラウンドで「fsck」を実行する」。BSDCon 2002 の議事録。pp. 55–64。2013年 4 月 8 日に閲覧。
- Marshall Kirk McKusick (2003 年 9 月)。「マルチテラバイト ストレージ システムをサポートするための高速ファイルシステムの機能強化」BSDCon 2003 の議事録。2019年 2 月 7 日閲覧。
- Richard McDougall、Jim Mauro (2006)。「15: UFS ファイルシステム」。Solaris 内部: Solaris 10 および OpenSolaris カーネルアーキテクチャ( PDF ) (第 2 版)。Sun Microsystems Press/Prentice Hall。ISBN 0-13-148209-2。
外部リンク
- ジェローン・C・ファン・ゲルデレン (2003-04-23)。 「ちょっとしたUFS2 FAQ」。FreeBSD 。2013 年 4 月 8 日に取得。
- 「ファイルシステム HOWTO: その他のファイルシステム」。Linuxドキュメンテーション プロジェクト。2007 年 1 月 27 日。
- Solaris UFSファイルシステムについては、[1]も参照
- USF(sic)/UFS2 フォーマット
- 局所性と高速ファイルシステム