• 画像はunderstanding the Linux Kernel Third Edition より引用

18章 Ext2、Ext3ファイルシステム

  • LinuxのネイティブなファイルシステムであるExt2(Second Extended Filesystem)と、その上位互換であるExt3を紹介

18.1 Ext2の一般的な特徴

  • 効率的で堅牢なファイルシステム
    • ブロックグループの概念、起動時にファイルシステム状態の整合性を確認する、など
  • 幾つかの機能が外部パッチで拡張可能
    • ブロックのフラグメント化など

18.2 Ext2ディスク上のデータ構造

  • 先頭ブロックはブートセクタとして利用しExt2ファイルシステムは操作しない
  • その他の部分をブロックグループに分割
    • ファイルシステム内の全てのブロックグループの大きさは同じで、連続的に配置
    • 1つのデータ構造は複数のブロックを利用出来る
    • 同じファイルに属するデータブロックはできるだけ同じブロックグループ内に配置するようにする
    • ブロックのビットマップが1つのブロックに収まらなければならない
    • 1ブロックグループ内の最大ブロック数: 8*b個 (b:ブロック長:1024,2048,4096バイト)
    • ブロックグループの総数:s/(8*b) (s:パーテイションの大きさ)

18.2.1 スーパーブロック

  • 各データブロックに1つずつ、ブロックグループ0のスーパーブロックの複製がある
    • カーネルはブロックグループ0のスーパーブロックのみ使用
  • iノードの総数、ブロックの総数、ブロック長などを保持(表18-1)

18.2.2 グループディスクリプタとビットマップ

グループディスクリプタ
  • ブロックグループ0以外は複製を保持
  • ブロックグループの空きブロック数や空きiノード数などを保持
    • 全てのブロックグループの情報がブロックグループ0のグループディスクリプタ(群)に保持される
  • 新しいiノードやデータブロックの割り当てなどに使用

ビットマップ
  • 対応するiノードやデータブロックが空き/使用中の状態をビット値(0,1)で示すためのビット列
  • ブロック長に応じて 8192,16384,32768個のブロックの状態を表現可能

18.2.3 iノードテーブル

  • 連続した複数のブロックを使用
  • 大きさ128バイトのiノードを持つ
  • 1つのブロックに含まれるiノード数は固定(ブロック長/128 個)なので、iノード番号からデータの位置を簡単に割り出せる
  • ファイルの実際の長さ、ファイルに割り当てたデータブロック数などを保持
    • ファイルの実際の長さ = ファイルに割り当てたデータブロック数にならない場合もある
    • ファイルの最大長は32ビットアーキテクチャで2GB(一部の64ビットプロセッサは4GBまで扱える)

18.2.4 iノードの拡張属性

  • iノードが128バイト固定であることによる問題を回避するための拡張機能
  • 属性名と属性値からなり、実際の情報はiノードとは別のブロックに置かれる
  • ACLを実装するため作成された機能

18.2.5 アクセス制御リスト(ACL)

  • ファイルアクセス権を拡張属性を用いて実現
  • 各ファイルにACLを結びつけることで、そのファイルにアクセスできるユーザーを指定する

18.2.6ファイルの種類とディスクブロックの使用法

18.2.6.1 通常ファイル
  • 通常ファイルがデータブロックを必要とするのは、データを持ち始めたときから
    • ファイル作成直後はデータを持たない
18.2.6.2 ディレクトリ
  • Ext2では、ディレクトリをファイルの1つとして扱う
    • ファイル名とファイルのiノード番号を組にしてデータブロックに持つ
  • 効率上の理由から、ディレクトリエントリの長さは必ず4の倍数になる
  • ディレクトリエントリの削除は、inodeメンバを0にし、rec_lenの指示する次のディレクトリの位置を変える(下図)

18.2.6.3 シンボリックリンク
  • シンボリックリンクが指すパス名が60バイト未満の場合はデータブロックを必要としない
18.2.6.4 デバイスファイル、パイプ、ソケット
  • データブロックを必要とせず、iノードが情報を保持

18.3 Ext2メモリ上のデータ構造

  • ファイルシステムのマウント時にディスク上のデータ構造の情報をほとんどRAMへ読み込む
    • ディスク読み込みを減らすため
  • データ構造は頻繁に更新されるため、データの一部はページキャッシュに常に保持されている
    • 常にキャッシュ:スーパーブロック、ブロックグループディスクリプタ
    • キャッシュしない:空きiノード、空きブロック
    • 動的にキャッシュ:その他のブロック

18.3.1 Ext2スーパーブロックオブジェクト

  • スーパーブロックのメンバや、スーパーブロックを読み込んだバッファの位置などを保持する構造体ext2_sb_info
  • Ext2ファイルシステムのマウント時はこの構造体を初期化
  • マウント後もメモリに残り続ける

18.3.2 Ext2 iノードオブジェクト

  • VFSがExt2ディスクiノードにアクセスするとき対応するiノードディスクリプタを生成

18.4 Ext2ファイルシステムの作成

  • ディスクのフォーマット→ファイルシステムの生成の手順をとる
    • ハードディスクなどは出荷時にフォーマット
  • mke2fsユーティリティプログラムで作成
  1. スーパーブロックとブロックグループディスクリプタを初期化
  2. 各ブロックグループに必要なブロック(5種)を予約して、初期化
  3. ルートディレクトリを作成
  4. ルートディレクトリを作成したブロックグループを更新

18.5 Ext2関数

  • VFSメソッドに合わせて対応するExt2関数を用意している

18.6 Ext2 ディスク領域の管理

  • ファイルの断片化を防いだり、ファイルを高速に取得するためのディスク領域の管理

18.6.1 iノードの作成

  • 関係の薄いディレクトリが、異なるブロックグループに配置されるように考慮
  • ブロックグループ内の通常ファイルとディレクトリ数の釣り合いを取るために、負債の概念を導入
    • ディレクトリの新規作成ごとに増加、その他のファイルの作成ごとに減少
    • 負債の少ないブロックグループに優先的にディレクトリを作成

ディレクトリ作成の場合
  1. 親ディレクトリがルートの場合、空きiノード数と空きブロック数が平均以上のブロックグループに作成
  2. 同じディレクトリ階層のディレクトリは、親ディレクトリと同じブロックグループに配置(条件あり)
    1. ブロックグループのディレクトリが多すぎない
    2. iノードが十分残っている
    3. 負債が少ない
  3. 上の条件を満たせない場合、全てのブロックグループから条件に合うグループを選択
  4. 親ディレクトリから順番にブロックグループを走査し、空きiノードが十分にあるブロックグループに作成

iノード作成の場合
  1. 親ディレクトリが存在するブロックグループから、空きiノードがあるグループを対数的検索で走査
  2. 空きiノードが見つからなければ線形検索
  3. 発見したグループのiノードビットマップから空きiノードを検索してディスクに割り当てる
  4. データ書き出しのためのdirtyフラグを立てる
  5. iノードオブジェクトやACLを初期化
  6. ハッシュテーブルに挿入
  7. 書き戻しのためにディスクからブロックを読み出す

18.6.2 iノードの削除

  • iノードに関連付けられた各種データを削除した後にディスクiノードが削除される

18.6.3 データブロックのアドレッシング

  • 通常ファイルは複数のデータブロックで構成される
  • データブロック内のブロックは、ファイル内の相対的な位置、または論理ブロック番号で求められる
  • ファイル内のブロック番号はブロック長から簡単に求められる
  • 論理ブロック番号への変換はマッピング機能を使用
  • 間接ブロックの概念を用いて、限られたディスクiノードのメンバから多くの論理ブロック番号を取得

18.6.4 ファイルホール

  • NULL文字が入っていて、ディスク上のデータブロックには保存されない部分
  • プログラムはホールを含めたデータ長を見るが、実際のディスク使用量は違う

18.6.5 データブロックの割り当て

  • ファイルの断片化を避けるため、そのファイルへ最後に割り当てたブロックの近くへ新しいファイルを割り当てようとする
  • ファイルを割り当てるとき、隣接したデータブロックを予約しておく

18.6.6 データブロックの解放

  • ファイル削除などで使用されなくなったデータブロックは回収される

18.7 Ext3ファイルシステム

  • Ext2ファイルシステムの拡張
  • ジャーナリングファイルシステムを実装

18.7.1 ジャーナリングファイルシステム(JFS)

  • ディスクが大きくなると、ファイルの整合性検査に膨大な時間がかかるようになる
  • 最近の更新情報を格納するジャーナルを用いて、ファイルシステムの整合性検査を低コストで実現

18.7.2 Ext3 ジャーナリングファイルシステム

  • ファイルシステムの更新にジャーナルを挟むことで、システム復旧時の処理を簡単にする
  • メタデータ(データブロック以外のブロックに格納されたデータ)だけジャーナルに書き込むことも出来る
  • メタデータのみの記録ではファイルが壊れるのを防げないが、処理が高速になる

18.7.3 ジャーナリングブロック型デバイス(JBD)

  • ジャーナルはカーネルレイヤのJBDが操作
  • 3つの基本的な処理
    • ログレコード
    • アトミック操作ハンドル
    • トランザクション
18.7.3.1 ログレコード
  • JFSの1ディスクブロックに対する1つの更新処理を表す
  • 容量を無駄に使うが、高速に動作
18.7.3.2 アトミック操作ハンドル
  • システムコール処理がアトミックに行われることを保証する
    • 障害からの復旧時は、全ての操作を完了させるか、まったく実行しない状態に戻すかの2択
18.7.3.3 トランザクション
  • 複数のアトミック操作ハンドルのログレコードを1つのトランザクションにまとめて処理

18.7.4 ジャーナリングの動作


省略

おまけ Ext4ファイルシステム

  • Linux 2.6.28に安定板がリリース(2008/12/25)
  • Ext3を互換した上で、さらに大容量のファイルを扱うために構築された
    • エクステント:ブロックビットマップ方式の上位互換、ブロックを複数使い、より大きなファイルを格納
    • ディスク領域の事前確保方法の変更:fallocate()システムコール
    • タイムスタンプ周期をナノ秒単位に変更

メンバーのみ編集できます