この記事の最終更新日: 2025年6月16日
はじめに
Linuxでは、ディスク上のデータを管理するために「ファイルシステム」という仕組みを使います。ファイルシステムは、ファイルやディレクトリの構造、アクセス権限、データの配置などを定義し、効率的な読み書きを可能にします。その中心的な役割を果たすのが「inode（インデックスノード）」と呼ばれるデータ構造です。
本記事では、以下のポイントを中心に、具体的な用語の定義や内部構造、実践的な操作方法を詳しく説明します。
- ファイルシステムの内部構造
- inodeの構造と役割
- ハードリンクとシンボリックリンクの違い
- ジャーナリング機能とデータ整合性
- 実践的なコマンドと運用上の注意点
1. ファイルシステムの内部構造
Linuxで一般的なext4を例に、ディスク上の領域構成を具体的に見ていきます。
- スーパーブロック (Superblock)
- ファイルシステム全体のメタデータを保持
- 全体サイズ、ブロックサイズ、総inode数、使用中inode数など
- グループディスクリプタ (Group Descriptor)
- ディスクを複数のブロックグループに分割した際の各グループ管理情報を保持
- 各グループの先頭ブロック位置、ビットマップ位置、inodeテーブル位置
- ブロックビットマップ (Block Bitmap)
- 各データブロックの使用状況をビット単位で管理
- 1ビット＝1ブロック。0が空き、1が使用中を示す
- inodeビットマップ (Inode Bitmap)
- inodeの使用状況をビット単位で管理
- 0が未使用inode、1が使用中inodeを表す
- inodeテーブル (Inode Table)
- 各inodeの情報（ファイルタイプ、アクセス権、所有者、タイムスタンプ、データブロックポインタ）を格納
- データブロック (Data Block)
- ファイルの実データを格納する領域。ブロックサイズ（例：4KiB）ごとに分割
これらを順番に配置することで、ファイルのメタデータと実データが明確に分かれた構造となり、アクセス効率と管理機能を両立しています。
2. inodeの構造と役割 ーー「ファイルの名刺入れ」
inodeはファイルシステムの中で「ファイルの名刺入れ」のような存在です。実際のデータ（本体）はデータブロックに格納され、inodeにはそのファイルを識別し参照するための情報だけがまとめられています。
inodeが保持する主な情報
- ファイルタイプとパーミッション
- 例：通常のファイル、ディレクトリ、シンボリックリンクなどの区別と、誰が読める／書ける／実行できるかを示すビット情報
- 所有者UIDとグループGID
- どのユーザー／グループがこのファイルの所有者かを表します
- ファイルサイズ
- バイト単位で記録。小さいテキストファイルから数GBの動画ファイルまで管理可能
- タイムスタンプ
atime（最終アクセス日時）mtime（最終変更日時）ctime（inode情報の最終変更日時。パーミッション変更時などにも更新される）
- ハードリンク数
- そのinodeを参照しているディレクトリエントリの数。複数の名前で同じファイルを扱うときに増える
- データブロックポインタ
- ファイルの中身（データ）がどのブロックにあるかを示すポインタ（参照先）の配列
- 直接ポインタ×12本
- シングル間接ポインタ×1本
- ダブル間接ポインタ×1本
- トリプル間接ポインタ×1本
データブロックポインタの具体的挙動 ー 倉庫の棚で考える簡単イメージ
ファイルの中身は「データブロック」という小さな箱に分かれて保管されています。inodeの「ポインタ」は、その箱がどの棚（ディスク上のどの位置）にあるかを教えてくれる“棚札”のようなものです。
- 直接ポインタ（0〜11番）
- イメージ：小さな倉庫の棚に、12個の箱を直接並べて置けるスペースがあると考えてください。
- しくみ：最初の12個分のデータブロックは、この棚札だけでどこにあるかがすぐに分かります。
- メリット：アクセスが早く、管理もシンプル。
- 制限：12箱分以上はここだけでは扱えません。
- シングル間接ポインタ（13番目）
- イメージ：倉庫の入り口に「追加の箱は2階の棚にあります」という案内板がある状態。
- しくみ：13番目のポインタは「別の箱の位置リストが書かれたブロック」を指しています。そのリストを使って追加の箱（データブロック）を探します。
- メリット：直接ポインタの12箱を超えるデータも扱える。
- ダブル間接ポインタ（14番目）
- イメージ：倉庫の入り口に「案内は2階の案内板を見てください」と書かれ、2階の案内板にはさらに「さらに奥の部屋にあります」と指示があるようなもの。
- しくみ：14番目は「案内板の案内板」を指す二段階のポインタ構造です。大量のデータを扱うときに使います。
- トリプル間接ポインタ（15番目）
- イメージ：さらに深い階層の案内を辿って、巨大倉庫の奥にたどり着く感じ。非常に大きなファイル向けです。
- しくみ：三重のポインタ階層で、数テラバイト級のファイルも参照可能。
上記のように、直接ポインタは扱いやすい範囲の小さなファイル向け、間接ポインタは大きなファイルや可変サイズのデータを効率よく管理するために段階的に伸ばせる仕組み**となっています。**これにより、シンプルな小ファイルから巨大なファイルまで、inode一本で幅広く対応可能です。
3. ハードリンクとシンボリックリンクの違い ハードリンクとシンボリックリンクの違い ハードリンクとシンボリックリンクの違い
Linuxでは、同じファイルを複数の場所から参照する方法として、ハードリンクとシンボリックリンクが用意されています。
3-1. ハードリンク
- 同一inode番号を指す複数のディレクトリエントリを作成
- ファイル名を消しても、リンクが残っていればデータは維持される
- 同一ファイルシステム内でのみ利用可能
ln /path/to/file1 /path/to/file1_hardlink
# 両者は同じinode番号を共有
ls -i /path/to/file1 /path/to/file1_hardlink
3-2. シンボリックリンク
- 新しいinode番号を持つ特殊ファイルに、参照先のパス文字列を格納
- 参照先が削除・移動されるとリンク切れとなる
- 異なるファイルシステム間でも作成可能
ln -s /path/to/target /path/to/symlink
# symlinkは別のinodeを持ち、内容は"/path/to/target"という文字列
readlink /path/to/symlink
4. ジャーナリング機能とデータ整合性
ext4やXFS、Btrfsなど多くのLinuxファイルシステムは、ジャーナリングによりクラッシュ時のメタデータ整合性を保証します。
- データジャーナリング（データとメタ両方記録）: より高い整合性だが性能低下の可能性あり
- メタデータジャーナリング（メタのみ記録）: 一般的なモード。メタデータの整合性を優先し、データは通常書き込み
- Orderedモード: データ書き込み完了後にメタデータをジャーナル。ext4デフォルト
# mount例
mount -t ext4 -o defaults,data=ordered /dev/sda1 /mnt/data
ジャーナルファイルは通常、ファイルシステム内部に専用領域として配置されます。fsck実行時にジャーナルを順番に再生し、未完了の更新を適用して整合性を回復します。
5. 実践的なコマンドと運用上の注意点
inode利用状況の確認
# ファイルシステム全体のinode使用状況
df -ih
iused(使用中inode数)、ifree(空きinode数)、iuse%(使用率)
小さなファイル大量生成の検出
# 10000個以上の小ファイルがあるディレクトリを探す
find /var/log -maxdepth 2 -type f | wc -l
inode総数の再設定
# mkfs時に-Nでinode総数を指定
mkfs.ext4 -N 5000000 /dev/sdb1
- デフォルトはディスク容量/ブロックサイズに基づく。大量ファイル用途は増やす。
メタデータの詳細確認
# 指定ファイルのinode情報を表示
stat --format='%i %A %U %G %s %y' filename
# スーパーブロック情報を取得
dumpe2fs /dev/sda1 | head -20
整合性チェックと修復
# 強制ファイルシステムチェック
fsck.ext4 -f -y /dev/sda1
- 運用中はアンマウント、またはリードオンリーモードで実行推奨
まとめ
Linuxのファイルシステムは、メタデータ管理（スーパーブロック、ビットマップ、inodeテーブル）とデータブロックの効率的な配置により、信頼性とパフォーマンスを両立しています。inodeはファイルの中核情報を保持し、リンク機能やジャーナリング技術と組み合わせることで、データ管理と障害復旧を支えます。
日常の運用では、df -iやstat、dumpe2fs、fsckといったコマンドを活用し、容量だけでなくinode利用状況も監視してトラブルを未然に防ぐことが重要です。
大阪のエンジニアが書いているブログ。
コメント