Linux Kernel File Systems

Mark as read

Linux Kernel ファイルシステム総合ガイド (ext4, XFS, Btrfs)

本ドキュメントは Linux カーネルにおける主要ファイルシステムの設計思想、内部構造、運用方法、パフォーマンスチューニングを網羅的に解説する技術文書です。

はじめに
ファイルシステムの基礎概念
ext4 ファイルシステム
XFS ファイルシステム
Btrfs ファイルシステム
ジャーナリングモード詳解
OverlayFS (コンテナ向け)
tmpfs と ramfs
FUSE (Filesystem in Userspace)
F2FS (Flash-Friendly File System)
Bcachefs (Linux 6.7 新規)
ファイルシステムベンチマーク
ファイルシステム機能比較表
ファイルシステム選択のベストプラクティス
まとめ

1. はじめに

Linux カーネルは世界で最も多くのファイルシステムをサポートするオペレーティングシステムカーネルである。VFS (Virtual File System) 層を通じて、数十種類のファイルシステムに対して統一的なインターフェースを提供している。

本文書では、Linux 環境で最も広く使用されている3つのファイルシステム -- ext4、XFS、Btrfs -- を中心に、その内部アーキテクチャ、設計思想、実用的な設定例、パフォーマンスチューニング手法を詳細に解説する。加えて、OverlayFS、tmpfs、FUSE、F2FS、Bcachefs といった特殊用途・新世代ファイルシステムについても取り上げる。

対象読者

Linux システム管理者およびSREエンジニア
ストレージアーキテクト
カーネル開発者・ファイルシステム開発者
クラウドインフラエンジニア
パフォーマンスエンジニア

前提知識

Linux の基本的なコマンド操作
ブロックデバイスとパーティションの概念
inode、ディレクトリエントリの基本理解

本文書の表記規則

# root権限で実行するコマンド
$ 一般ユーザーで実行するコマンド
// コード内のコメント

2. ファイルシステムの基礎概念

2.1 VFS (Virtual File System) レイヤー

Linux カーネルの VFS は、すべてのファイルシステムに対する共通インターフェースを提供する抽象化レイヤーである。

ユーザー空間アプリケーション
        |
    システムコール (open, read, write, close, stat, ...)
        |
    VFS (Virtual File System)
        |
    +---+---+---+---+---+
    |   |   |   |   |   |
  ext4 XFS Btrfs NFS tmpfs ...
    |   |   |
    ブロックデバイスレイヤー
        |
    I/O スケジューラ
        |
    デバイスドライバ
        |
    物理ストレージ

VFS の主要データ構造は以下の4つである:

データ構造	説明
`struct super_block`	マウントされたファイルシステムのメタデータ
`struct inode`	ファイルのメタデータ (パーミッション、サイズ、タイムスタンプ等)
`struct dentry`	ディレクトリエントリ (ファイル名と inode の対応)
`struct file`	オープンされたファイルの状態

// カーネルソースコード: include/linux/fs.h より抜粋 (簡略化)
struct super_operations {
    struct inode *(*alloc_inode)(struct super_block *sb);
    void (*destroy_inode)(struct inode *);
    void (*dirty_inode)(struct inode *, int flags);
    int (*write_inode)(struct inode *, struct writeback_control *wbc);
    int (*drop_inode)(struct inode *);
    void (*evict_inode)(struct inode *);
    void (*put_super)(struct super_block *);
    int (*sync_fs)(struct super_block *sb, int wait);
    int (*statfs)(struct dentry *, struct kstatfs *);
    int (*remount_fs)(struct super_block *, int *, char *);
    // ...
};

2.2 ブロックデバイスとセクタ

ファイルシステムは、ブロックデバイス上にデータを格納する。ブロックデバイスは固定サイズのブロック単位でアクセスされる。

# ブロックデバイスの情報を確認
# セクタサイズの確認
$ cat /sys/block/sda/queue/logical_block_size
512

$ cat /sys/block/sda/queue/physical_block_size
4096

# ブロックデバイスの一覧
$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME   SIZE TYPE FSTYPE MOUNTPOINT
sda    500G disk
├─sda1   1G part ext4   /boot
├─sda2  50G part xfs    /
└─sda3 449G part btrfs  /data

# デバイスの詳細情報
$ sudo hdparm -I /dev/sda | grep -i "sector size"
    Logical  Sector size:                   512 bytes
    Physical Sector size:                  4096 bytes

2.3 inode の構造

inode はファイルのメタデータを保持するデータ構造である。ファイル名は含まれず、ディレクトリエントリ (dentry) に格納される。

# inode 情報の確認
$ stat /etc/passwd
  File: /etc/passwd
  Size: 2845        Blocks: 8          IO Block: 4096   regular file
Device: 803h/2051d  Inode: 1048593     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2026-04-10 10:00:00.000000000 +0900
Modify: 2026-04-01 12:00:00.000000000 +0900
Change: 2026-04-01 12:00:00.000000000 +0900
 Birth: 2026-01-01 00:00:00.000000000 +0900

# ファイルシステム全体の inode 使用状況
$ df -i
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/sda2     3276800  245678 3031122    8% /
/dev/sda3           0       0       0     - /data

2.4 エクステント vs ブロックマッピング

従来のファイルシステム (ext2/ext3) はブロック単位のマッピングを使用していたが、現代のファイルシステムはエクステントベースのアロケーションを採用している。

【ブロックマッピング (旧方式)】
inode → ブロック0 → データ
      → ブロック1 → データ
      → ブロック2 → データ
      → ...
      → 間接ブロック → ブロック12~267
      → 二重間接ブロック → 間接ブロック → ブロック268~65803
      → 三重間接ブロック → ...

【エクステントベース (現代方式)】
inode → エクステント1: 開始ブロック=1000, 長さ=500
      → エクステント2: 開始ブロック=2500, 長さ=300
      → エクステント3: 開始ブロック=5000, 長さ=1200

エクステントベースのアプローチにより:

大容量ファイルのメタデータが大幅に削減される
連続領域の割り当てによりシーケンシャル I/O 性能が向上する
ファイルシステムの管理オーバーヘッドが減少する

3. ext4 ファイルシステム

3.1 概要と歴史

ext4 (Fourth Extended Filesystem) は Linux における標準ファイルシステムであり、ext3 の後継として2008年に Linux 2.6.28 で安定版として導入された。多くの Linux ディストリビューションでデフォルトファイルシステムとして採用されている。

主要スペック:

項目	値
最大ファイルサイズ	16 TiB (4K ブロック時)
最大ボリュームサイズ	1 EiB
最大ファイル名長	255 バイト
最大パス長	なし (VFS制限)
ジャーナリング	あり
エクステント	あり
透過的暗号化	fscrypt
オンラインリサイズ	拡大のみ
オンラインデフラグ	あり (e4defrag)

3.2 ext4 のディスクレイアウト

+-------+-------------------+-------------------+-------------------+-----+
| スーパー |  ブロックグループ 0  |  ブロックグループ 1  |  ブロックグループ 2  | ... |
| ブロック |                   |                   |                   |     |
+-------+-------------------+-------------------+-------------------+-----+

各ブロックグループの構造:
+--------+--------+--------+--------+--------+--------+
| スーパー | GDT    | データ  | inode  | inode  | データ  |
| ブロック | ブロック | ビット  | ビット  | テーブル | ブロック |
| (冗長)  |        | マップ  | マップ  |        |        |
+--------+--------+--------+--------+--------+--------+

ext4 は Flexible Block Groups (flex_bg) を導入し、複数のブロックグループのメタデータを集約して配置することで、メタデータの局所性を向上させている。

3.3 ジャーナリング

ext4 のジャーナリングは JBD2 (Journaling Block Device 2) サブシステムによって実装されている。

# ジャーナルの情報を確認
$ sudo dumpe2fs /dev/sda1 | grep -i journal
Journal inode:            8
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0001a5f3
Journal start:            1

ジャーナリングの仕組み:

1. トランザクション開始
   ↓
2. メタデータ変更をジャーナルに書き込む
   (data=journal の場合はデータも)
   ↓
3. ジャーナルコミット (コミットブロック書き込み)
   ↓
4. 実際のメタデータをディスク上の本来の位置に書き込む (チェックポイント)
   ↓
5. ジャーナル領域を再利用可能としてマーク

3.4 エクステント

ext4 はエクステントツリーを使用してファイルのデータブロックを管理する。

// カーネルソース: fs/ext4/ext4_extents.h (簡略化)
struct ext4_extent_header {
    __le16 eh_magic;      // マジックナンバー: 0xF30A
    __le16 eh_entries;    // 有効なエントリ数
    __le16 eh_max;        // 最大エントリ数
    __le16 eh_depth;      // ツリーの深さ (0 = リーフ)
    __le32 eh_generation; // 世代番号
};

struct ext4_extent {
    __le32 ee_block;      // 論理ブロック番号 (ファイル先頭からのオフセット)
    __le16 ee_len;        // エクステントの長さ (ブロック数)
    __le16 ee_start_hi;   // 物理ブロック番号の上位16ビット
    __le32 ee_start_lo;   // 物理ブロック番号の下位32ビット
};

# ファイルのエクステント情報を確認
$ sudo filefrag -v /var/log/syslog
Filesystem type is: ef53
File size of /var/log/syslog is 1234567 (302 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..      63:    1048576..   1048639:     64:
   1:       64..     127:    1048704..   1048767:     64:    1048640:
   2:      128..     301:    1049000..   1049173:    174:    1048768: last,eof
/var/log/syslog: 3 extents found

# debugfs でより詳細なエクステント情報を表示
$ sudo debugfs -R "extents /var/log/syslog" /dev/sda1

3.5 遅延割り当て (Delayed Allocation)

遅延割り当ては、write() システムコール時にはブロックを割り当てず、実際にディスクに書き出す (フラッシュ) 時点まで割り当てを遅延させる機能である。

【即時割り当て (従来方式)】
write() → ブロック割り当て → ページキャッシュに書き込み → 後でフラッシュ
  ※ 小さな write が連続すると断片化が発生しやすい

【遅延割り当て (ext4)】
write() → ページキャッシュに書き込み (ブロック未割り当て)
  ↓ (後でフラッシュする際に)
writeback → まとめてブロックを割り当て → ディスクに書き込み
  ※ 連続した領域を割り当てやすく、断片化を抑制

利点:

ファイルの最終サイズが判明してからブロックを割り当てるため、より最適な配置が可能
短命なファイル (作成後すぐに削除) の場合、ディスクI/Oを完全に回避できる
連続ブロックの割り当てにより断片化を大幅に削減

# 遅延割り当ての状態を確認
$ cat /proc/fs/ext4/sda1/delayed_allocation_blocks
0

# マウントオプションで遅延割り当てを制御
# デフォルトで有効 (delalloc)
# 無効にする場合 (非推奨):
# mount -o nodelalloc /dev/sda1 /mnt

3.6 インラインデータ (Inline Data)

非常に小さなファイルのデータを inode 内に直接格納する機能。データブロックの割り当てが不要になり、小さなファイルのアクセス性能が大幅に向上する。

# インラインデータ機能の有効化 (ファイルシステム作成時)
# mkfs.ext4 -O inline_data /dev/sda1

# 既存ファイルシステムで有効化
$ sudo tune2fs -O inline_data /dev/sda1

# インラインデータが有効か確認
$ sudo tune2fs -l /dev/sda1 | grep -i "features"
Filesystem features:  has_journal ext_attr resize_inode dir_index
  filetype needs_recovery extent 64bit flex_bg sparse_super large_file
  huge_file dir_nlink extra_isize metadata_csum inline_data

# inode サイズの確認 (インラインデータに使える領域に影響)
$ sudo tune2fs -l /dev/sda1 | grep "Inode size"
Inode size:               256

インラインデータは inode の余剰スペース (通常 256 バイトの inode で約 60 バイト + 拡張属性領域) に小さなファイルのデータを直接格納する。

3.7 暗号化 (fscrypt)

fscrypt はカーネルレベルのファイルシステム暗号化フレームワークであり、ext4、F2FS、UBIFS でサポートされている。

# fscrypt のセットアップ

# 1. カーネルが fscrypt をサポートしているか確認
$ grep -i "fs_encryption\|fscrypt" /boot/config-$(uname -r)
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_ALGS=y

# 2. ファイルシステムで暗号化を有効化
$ sudo tune2fs -O encrypt /dev/sda1

# 3. fscrypt ツールのインストール
$ sudo apt install fscrypt libpam-fscrypt   # Debian/Ubuntu
$ sudo dnf install fscrypt                   # Fedora/RHEL

# 4. fscrypt の初期化
$ sudo fscrypt setup
$ sudo fscrypt setup /mnt/encrypted

# 5. ディレクトリの暗号化
$ mkdir /mnt/encrypted/secret
$ fscrypt encrypt /mnt/encrypted/secret
  [prompts for protector type and passphrase]

# 6. 暗号化ディレクトリの使用
$ echo "秘密データ" > /mnt/encrypted/secret/data.txt

# 7. ロック (暗号化ディレクトリをアクセス不可にする)
$ fscrypt lock /mnt/encrypted/secret

# 8. アンロック
$ fscrypt unlock /mnt/encrypted/secret

fscrypt のアーキテクチャ:

ユーザー空間                カーネル空間
+-----------+             +------------------+
| fscrypt   |  ioctl()    | VFS              |
| ツール     | ----------->| fscrypt サブシステム |
+-----------+             +------------------+
                                |
                          +-----+-----+
                          |           |
                     ファイル名     ファイル内容
                     暗号化        暗号化
                     (AES-256-CTS) (AES-256-XTS)
                          |           |
                     +----+----+ +----+----+
                     | 暗号化   | | 暗号化   |
                     | ファイル名 | | データ   |
                     +----+----+ +----+----+
                          |           |
                       ディスク上に格納

3.8 ext4 ファイルシステムの作成とマウント

# === ext4 ファイルシステムの作成 ===

# 基本的な作成
$ sudo mkfs.ext4 /dev/sdb1

# 詳細オプション付き作成
$ sudo mkfs.ext4 \
    -b 4096 \              # ブロックサイズ: 4KB
    -i 16384 \             # bytes-per-inode: 16KB (inode密度の制御)
    -I 256 \               # inode サイズ: 256 バイト
    -J size=256 \          # ジャーナルサイズ: 256MB
    -m 1 \                 # 予約ブロック: 1% (デフォルト5%)
    -O has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize,encrypt \
    -E stride=16,stripe-width=64 \  # RAIDパラメータ
    -L "data-volume" \     # ラベル
    /dev/sdb1

# === マウントオプション ===

# 基本マウント
$ sudo mount /dev/sdb1 /mnt/data

# 推奨マウントオプション (一般用途)
$ sudo mount -o defaults,noatime,commit=60 /dev/sdb1 /mnt/data

# パフォーマンス重視マウントオプション
$ sudo mount -o defaults,noatime,nodiratime,commit=120,delalloc,barrier=1 /dev/sdb1 /mnt/data

# SSD 向けマウントオプション
$ sudo mount -o defaults,noatime,discard /dev/sdb1 /mnt/data

# /etc/fstab エントリ例
# <デバイス>  <マウントポイント>  <タイプ>  <オプション>                         <dump> <pass>
# UUID=xxxx   /data              ext4     defaults,noatime,commit=60           0      2

3.9 ext4 のパフォーマンスチューニング

# === パフォーマンスチューニング ===

# 1. ジャーナルモードの選択
# data=ordered (デフォルト): バランス重視
$ sudo mount -o data=ordered /dev/sdb1 /mnt/data

# data=writeback: パフォーマンス重視 (クラッシュ時のデータ整合性リスクあり)
$ sudo mount -o data=writeback /dev/sdb1 /mnt/data

# data=journal: 安全性重視 (パフォーマンス低下)
$ sudo mount -o data=journal /dev/sdb1 /mnt/data

# 2. コミット間隔の調整
# デフォルト: 5秒, パフォーマンス重視: 60-120秒
$ sudo mount -o commit=60 /dev/sdb1 /mnt/data

# 3. バリアの制御
# バッテリーバックアップ付きRAIDコントローラの場合
$ sudo mount -o nobarrier /dev/sdb1 /mnt/data  # 非推奨 (データ損失リスク)

# 4. 予約ブロックの削減 (非rootパーティション)
$ sudo tune2fs -m 1 /dev/sdb1  # 1%に削減 (デフォルト5%)

# 5. ファイルシステムのチェック間隔
$ sudo tune2fs -c 0 -i 0 /dev/sdb1  # 自動チェック無効化

# 6. ディレクトリインデックス (htree) の有効化
$ sudo tune2fs -O dir_index /dev/sdb1

# 7. I/O スケジューラの最適化
# SSD向け
$ echo "none" | sudo tee /sys/block/sdb/queue/scheduler
# HDD向け
$ echo "bfq" | sudo tee /sys/block/sdb/queue/scheduler

# 8. readahead の調整
$ sudo blockdev --setra 2048 /dev/sdb  # 1MB readahead (512バイト単位)

# 9. 現在のマウントオプションの確認
$ mount | grep sdb1
/dev/sdb1 on /mnt/data type ext4 (rw,noatime,commit=60)

# 10. デフラグ
$ sudo e4defrag /mnt/data
$ sudo e4defrag -v /mnt/data/large_file  # 特定ファイルのデフラグ

3.10 ext4 のリペアツール

# === ファイルシステムの修復 ===

# 事前確認: ファイルシステムをアンマウント
$ sudo umount /mnt/data

# 基本的なチェック
$ sudo fsck.ext4 /dev/sdb1

# 詳細チェック (自動修復)
$ sudo fsck.ext4 -y /dev/sdb1

# 強制チェック (クリーンでも実行)
$ sudo fsck.ext4 -f /dev/sdb1

# 読み取り専用チェック (変更なし)
$ sudo fsck.ext4 -n /dev/sdb1

# 詳細な進捗表示
$ sudo fsck.ext4 -fvy /dev/sdb1

# === デバッグツール ===

# debugfs でファイルシステムを調査
$ sudo debugfs /dev/sdb1
debugfs: stat <8>          # ジャーナル inode の情報
debugfs: ls -l /lost+found # lost+found ディレクトリの内容
debugfs: quit

# スーパーブロックの情報表示
$ sudo dumpe2fs /dev/sdb1 | less

# バックアップスーパーブロックからの復旧
$ sudo mkfs.ext4 -n /dev/sdb1  # バックアップSBの位置を表示
$ sudo fsck.ext4 -b 32768 /dev/sdb1  # バックアップSBを使用して修復

# tune2fs でパラメータ確認・変更
$ sudo tune2fs -l /dev/sdb1  # 全パラメータ表示

4. XFS ファイルシステム

4.1 概要と歴史

XFS は Silicon Graphics (SGI) が IRIX OS 向けに1993年に開発した高性能ファイルシステムである。2001年に Linux に移植され、RHEL 7 以降ではデフォルトファイルシステムとして採用されている。

主要スペック:

項目	値
最大ファイルサイズ	8 EiB
最大ボリュームサイズ	8 EiB
最大ファイル名長	255 バイト
ジャーナリング	メタデータジャーナリング
エクステント	あり
Reflink	あり (Linux 4.9+)
オンラインリサイズ	拡大のみ
オンラインデフラグ	あり (xfs_fsr)
B+ツリー	全メタデータ管理に使用

4.2 XFS の内部アーキテクチャ

アロケーショングループ (AG)

XFS の最も特徴的な設計要素はアロケーショングループである。ファイルシステムを複数の等サイズの領域 (AG) に分割し、各 AG が独立したメタデータ構造を持つ。

XFS ファイルシステム全体:
+-------+-------+-------+-------+-------+-------+-------+-------+
| AG 0  | AG 1  | AG 2  | AG 3  | AG 4  | AG 5  | AG 6  | AG 7  |
+-------+-------+-------+-------+-------+-------+-------+-------+

各 AG の内部構造:
+--------+--------+--------+---------+---------+--------+
| AG     | AGF    | AGI    | AGFL    | フリー   | データ  |
| スーパー | (フリー | (inode | (フリー  | スペース  | ブロック |
| ブロック | スペース | 情報)  | リスト)  | B+ツリー |        |
|        | 情報)  |        |         |         |        |
+--------+--------+--------+---------+---------+--------+

アロケーショングループの利点:

並列性: 各 AG は独立したロックを持ち、マルチスレッドでの並列アロケーションが可能
スケーラビリティ: 非常に大きなファイルシステムでもメタデータ操作が高速
復旧性: AG 単位での修復が可能

# AG の情報を確認
$ sudo xfs_info /mnt/xfs
meta-data=/dev/sdb1              isize=512    agcount=16, agsize=6553600 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=104857600, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=51200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

# AG ごとのフリースペース情報
$ sudo xfs_db -r /dev/sdb1 -c "freesp -s"

B+ ツリー構造

XFS はほぼすべてのメタデータ管理に B+ ツリーを使用する。

XFS で使用される B+ ツリー:

1. フリースペース B+ ツリー (2種類)
   - ブロック番号順 B+ ツリー (bnobt)
   - サイズ順 B+ ツリー (cntbt)

2. inode B+ ツリー (inobt)
   - inode の割り当て状況を管理

3. フリー inode B+ ツリー (finobt)
   - 未使用 inode の高速検索

4. リバースマッピング B+ ツリー (rmapbt) [オプション]
   - 物理ブロックから所有者への逆引き

5. リファレンスカウント B+ ツリー (refcntbt) [reflink使用時]
   - 共有ブロックの参照カウント管理

# B+ ツリーの状態を確認
$ sudo xfs_db -r /dev/sdb1
xfs_db> agf 0
xfs_db> p
magicnum = 0x58414746
versionnum = 1
seqno = 0
length = 6553600
bnoroot = 3
cntroot = 4
bnolevel = 2
cntlevel = 2
freeblks = 5000000
longest = 1000000

4.3 遅延割り当て (Delayed Allocation)

XFS も ext4 と同様に遅延割り当てをサポートしている。XFS の遅延割り当ては ext4 よりも先に実装されており、アロケーショングループとの組み合わせにより高い効率を発揮する。

# XFS の遅延割り当て統計
$ cat /proc/fs/xfs/stat | grep -i "xs_xstrat"
xs_xstrat_quick 123456
xs_xstrat_split 789

# delalloc の状態は xfs_info で確認可能
# XFS ではデフォルトで有効 (allocsize オプションで制御)

4.4 Reflink (参照リンク)

Reflink は Copy-on-Write (CoW) を利用した高速ファイルコピー機能である。

# Reflink が有効か確認
$ sudo xfs_info /mnt/xfs | grep reflink
reflink=1

# Reflink を使用したコピー (cp --reflink)
$ cp --reflink=always source.img dest.img

# コピー時間の比較
$ time cp large_file.dat copy_regular.dat        # 通常コピー: 数秒~数分
$ time cp --reflink=always large_file.dat copy_reflink.dat  # reflink: ほぼ瞬時

# Reflink 有効な XFS ファイルシステムの作成
$ sudo mkfs.xfs -m reflink=1 /dev/sdb1

# Reflink の使用状況を確認
$ sudo xfs_db -r /dev/sdb1
xfs_db> agf 0
xfs_db> p refcntroot
refcntroot = 5
xfs_db> p refcntlevel
refcntlevel = 1

Reflink の動作原理:

【Reflink コピー時】
ファイルA: エクステント → [データブロック 1000-1999] (refcount=1)
                           ↓ cp --reflink
ファイルA: エクステント → [データブロック 1000-1999] (refcount=2)
ファイルB: エクステント ↗

【一方を変更時 (CoW)】
ファイルA: エクステント → [データブロック 1000-1999] (refcount=1)
ファイルB: エクステント → [新データブロック 5000-5999] (refcount=1)
           (変更分のみ新しいブロックに書き込まれる)

4.5 オンラインデフラグメンテーション

# xfs_fsr (ファイルシステム再編成)
$ sudo xfs_fsr /mnt/xfs

# 特定ファイルのデフラグ
$ sudo xfs_fsr /mnt/xfs/large_file.dat

# デフラグの実行時間制限 (秒)
$ sudo xfs_fsr -t 3600 /mnt/xfs  # 1時間で打ち切り

# 断片化状況の確認
$ sudo xfs_db -r /dev/sdb1 -c "frag -f"

# filefrag でファイル単位の断片化を確認
$ filefrag -v /mnt/xfs/data.db

4.6 XFS ファイルシステムの作成とマウント

# === XFS ファイルシステムの作成 ===

# 基本的な作成
$ sudo mkfs.xfs /dev/sdb1

# 詳細オプション付き作成
$ sudo mkfs.xfs \
    -b size=4096 \                # ブロックサイズ: 4KB
    -d agcount=32 \               # AG 数: 32
    -i size=512 \                 # inode サイズ: 512 バイト
    -l size=256m,version=2 \      # ログサイズ: 256MB
    -m crc=1,reflink=1,bigtime=1 \# メタデータCRC, reflink, bigtime有効
    -n size=4096 \                # ディレクトリブロックサイズ
    -L "xfs-data" \               # ラベル
    /dev/sdb1

# RAID 向け作成
$ sudo mkfs.xfs \
    -d sunit=128,swidth=512 \     # stripe unit=64KB, stripe width=256KB
    /dev/md0

# 強制作成 (既存ファイルシステムを上書き)
$ sudo mkfs.xfs -f /dev/sdb1

# === マウントオプション ===

# 基本マウント
$ sudo mount /dev/sdb1 /mnt/xfs

# 推奨マウントオプション (一般用途)
$ sudo mount -o defaults,noatime,logbufs=8,logbsize=256k /dev/sdb1 /mnt/xfs

# パフォーマンス重視
$ sudo mount -o defaults,noatime,nodiratime,logbufs=8,logbsize=256k,allocsize=64m /dev/sdb1 /mnt/xfs

# SSD 向け
$ sudo mount -o defaults,noatime,discard /dev/sdb1 /mnt/xfs

# /etc/fstab エントリ例
# UUID=xxxx   /data   xfs   defaults,noatime,logbufs=8,logbsize=256k   0   0

4.7 XFS のパフォーマンスチューニング

# === パフォーマンスチューニング ===

# 1. ログバッファの増加
$ sudo mount -o logbufs=8,logbsize=256k /dev/sdb1 /mnt/xfs

# 2. アロケーションサイズの指定 (ストリーミング書き込み向け)
$ sudo mount -o allocsize=64m /dev/sdb1 /mnt/xfs

# 3. inode サイズの最適化
# 拡張属性を多用する場合は 512 バイト以上推奨
$ sudo mkfs.xfs -i size=512 /dev/sdb1

# 4. AG 数の最適化
# CPU コア数に合わせて AG 数を設定
$ sudo mkfs.xfs -d agcount=32 /dev/sdb1  # 32コアシステム向け

# 5. XFS 統計情報の確認
$ cat /proc/fs/xfs/stat
extent_alloc 123456 789012 345678 901234
abt 12345 6789 0 0 0 0 0 0 0 0 0 0 0 0 0 0

# 6. xfs_spaceman でフリースペースの管理
$ sudo xfs_spaceman -c "freesp -s" /mnt/xfs

# 7. プロジェクトクォータの設定
$ sudo xfs_quota -x -c "project -s myproject" /mnt/xfs
$ sudo xfs_quota -x -c "limit -p bhard=100g myproject" /mnt/xfs

# 8. リアルタイムセクションの使用 (低レイテンシー要件)
$ sudo mkfs.xfs -r rtdev=/dev/sdc1,extsize=64k /dev/sdb1

4.8 XFS のリペアツール

# === XFS ファイルシステムの修復 ===

# ファイルシステムをアンマウント
$ sudo umount /mnt/xfs

# 基本的なチェック (ドライラン)
$ sudo xfs_repair -n /dev/sdb1

# 修復実行
$ sudo xfs_repair /dev/sdb1

# ログが破損している場合 (-L で強制ログクリア)
# 注意: 最後のトランザクションが失われる可能性あり
$ sudo xfs_repair -L /dev/sdb1

# 詳細ログ出力
$ sudo xfs_repair -v /dev/sdb1

# 並列修復 (マルチスレッド)
$ sudo xfs_repair -o ag_stride=4 /dev/sdb1

# === 診断ツール ===

# xfs_db でメタデータを調査
$ sudo xfs_db -r /dev/sdb1
xfs_db> sb 0          # スーパーブロックの表示
xfs_db> p              # 内容を表示
xfs_db> agf 0          # AG 0 のフリースペース情報
xfs_db> agi 0          # AG 0 の inode 情報
xfs_db> freesp -s      # フリースペースの統計

# xfs_metadump でメタデータのダンプ (サポート問い合わせ用)
$ sudo xfs_metadump /dev/sdb1 /tmp/xfs_metadump.img

# xfs_logprint でログの内容を表示
$ sudo xfs_logprint /dev/sdb1

# xfs_info でファイルシステム情報 (マウント中でも可)
$ sudo xfs_info /mnt/xfs

# xfs_growfs でオンライン拡大
$ sudo xfs_growfs /mnt/xfs
$ sudo xfs_growfs -D 209715200 /mnt/xfs  # 特定サイズに拡大

5. Btrfs ファイルシステム

5.1 概要と歴史

Btrfs (B-tree File System, 通称 "Butter FS") は Oracle が2007年に開発を開始した次世代ファイルシステムである。ZFS の機能を Linux ネイティブで実現することを目標としている。SUSE Linux Enterprise では安定版としてサポートされ、Facebook (Meta) の大規模デプロイメントでも実績がある。

主要スペック:

項目	値
最大ファイルサイズ	16 EiB
最大ボリュームサイズ	16 EiB
コピーオンライト	あり
スナップショット	あり (読み書き可能)
サブボリューム	あり
内蔵 RAID	RAID 0/1/10/5/6
圧縮	zlib, lzo, zstd
チェックサム	CRC32C, xxhash, SHA-256, BLAKE2b
Send/Receive	あり
クォータ	サブボリューム単位
オンラインデフラグ	あり

5.2 Btrfs の内部アーキテクチャ

Btrfs は全データ構造を B ツリー (正確には CoW B ツリー) で管理する。

Btrfs ディスクレイアウト:
+----------+----+----+----+----+----+----+----+----+----------+
| スーパー  |    |    |    |    |    |    |    |    | スーパー  |
| ブロック  |  チャンク / ストライプ アロケーション         | ブロック  |
| (1st)    |                                       | (2nd/3rd)|
+----------+----+----+----+----+----+----+----+----+----------+

主要な B ツリー:
1. Root ツリー      - 全ツリーのルートを管理
2. FS ツリー        - ファイル/ディレクトリのメタデータ
3. エクステントツリー - データエクステントの割り当て管理
4. チェックサムツリー - データチェックサムの格納
5. チャンクツリー    - 論理アドレスから物理アドレスへのマッピング
6. デバイスツリー    - 物理デバイスの情報
7. Quota ツリー      - クォータ情報

5.3 コピーオンライト (CoW)

Btrfs の根幹をなす仕組みがコピーオンライトである。

【CoW によるデータ更新】

書き込み前:
Root → Node A → Leaf 1: [データX]
              → Leaf 2: [データY]

データX を データX' に更新:
1. 新しい Leaf 1' に データX' を書き込む
2. 新しい Node A' を作成し、Leaf 1' と Leaf 2 を参照
3. Root' を更新して Node A' を参照
4. Root' をスーパーブロックに反映 (アトミック)

書き込み後:
Root' → Node A' → Leaf 1': [データX'] (新規)
               → Leaf 2:  [データY]  (共有)

旧データ:
Root → Node A → Leaf 1: [データX] (スナップショットで保持可能)
             → Leaf 2: [データY] (共有)

CoW の利点:

クラッシュ一貫性: 更新はアトミックであり、部分書き込みが発生しない
スナップショット: 旧バージョンのツリーを保持するだけで実現
チェックサム: 全データにチェックサムを付与し、サイレントデータ破損を検出

# CoW を特定ファイルで無効化 (データベースファイル向け)
$ chattr +C /mnt/btrfs/database/
$ lsattr /mnt/btrfs/database/
---------------C---- /mnt/btrfs/database/

# NoCoW ファイルの確認
$ lsattr -R /mnt/btrfs/ | grep "C"

5.4 スナップショット

# === スナップショット操作 ===

# 読み取り専用スナップショット
$ sudo btrfs subvolume snapshot -r /mnt/btrfs/data /mnt/btrfs/snapshots/data-20260410

# 読み書き可能スナップショット
$ sudo btrfs subvolume snapshot /mnt/btrfs/data /mnt/btrfs/snapshots/data-writable

# スナップショットの一覧
$ sudo btrfs subvolume list /mnt/btrfs
ID 256 gen 100 top level 5 path data
ID 257 gen 101 top level 5 path snapshots/data-20260410
ID 258 gen 102 top level 5 path snapshots/data-writable

# スナップショットの削除
$ sudo btrfs subvolume delete /mnt/btrfs/snapshots/data-20260410

# === 自動スナップショット (cron/systemd timer) ===

# /usr/local/bin/btrfs-snapshot.sh
#!/bin/bash
SNAPSHOT_DIR="/mnt/btrfs/snapshots"
SOURCE="/mnt/btrfs/data"
DATE=$(date +%Y%m%d-%H%M%S)
MAX_SNAPSHOTS=30

# スナップショット作成
btrfs subvolume snapshot -r "$SOURCE" "$SNAPSHOT_DIR/data-$DATE"

# 古いスナップショットの削除
SNAPSHOTS=($(ls -d "$SNAPSHOT_DIR"/data-* 2>/dev/null | sort))
while [ ${#SNAPSHOTS[@]} -gt $MAX_SNAPSHOTS ]; do
    btrfs subvolume delete "${SNAPSHOTS[0]}"
    SNAPSHOTS=("${SNAPSHOTS[@]:1}")
done

5.5 サブボリューム

# === サブボリューム操作 ===

# サブボリュームの作成
$ sudo btrfs subvolume create /mnt/btrfs/home
$ sudo btrfs subvolume create /mnt/btrfs/var
$ sudo btrfs subvolume create /mnt/btrfs/tmp

# サブボリュームの一覧
$ sudo btrfs subvolume list -a /mnt/btrfs

# サブボリュームの詳細情報
$ sudo btrfs subvolume show /mnt/btrfs/home
/mnt/btrfs/home
    Name:           home
    UUID:           12345678-1234-1234-1234-123456789abc
    Parent UUID:    -
    Received UUID:  -
    Creation time:  2026-04-10 10:00:00 +0900
    Subvolume ID:   256
    Generation:     100
    Gen at creation: 100
    Parent ID:      5
    Top level ID:   5
    Flags:          -
    Send transid:   0
    Send time:      2026-04-10 10:00:00 +0900
    Receive transid: 0
    Receive time:   -
    Snapshot(s):

# サブボリュームを個別にマウント
$ sudo mount -o subvol=home /dev/sdb1 /home
$ sudo mount -o subvol=var /dev/sdb1 /var

# /etc/fstab でサブボリュームを個別マウント
# UUID=xxxx  /      btrfs  defaults,subvol=@          0  0
# UUID=xxxx  /home  btrfs  defaults,subvol=@home      0  0
# UUID=xxxx  /var   btrfs  defaults,subvol=@var       0  0

# デフォルトサブボリュームの設定
$ sudo btrfs subvolume set-default 256 /mnt/btrfs

5.6 RAID

# === Btrfs 内蔵 RAID ===

# RAID1 でファイルシステム作成 (メタデータ: RAID1, データ: RAID1)
$ sudo mkfs.btrfs -m raid1 -d raid1 /dev/sdb1 /dev/sdc1

# RAID10 で作成 (4台以上必要)
$ sudo mkfs.btrfs -m raid10 -d raid10 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

# RAID0 (ストライピングのみ)
$ sudo mkfs.btrfs -m raid1 -d raid0 /dev/sdb1 /dev/sdc1

# RAID5/6 (注意: まだ安定性に問題あり、本番非推奨)
$ sudo mkfs.btrfs -m raid1 -d raid5 /dev/sdb1 /dev/sdc1 /dev/sdd1

# === デバイスの管理 ===

# デバイスの追加
$ sudo btrfs device add /dev/sdd1 /mnt/btrfs

# デバイスの削除
$ sudo btrfs device remove /dev/sdc1 /mnt/btrfs

# デバイスの一覧
$ sudo btrfs filesystem show /mnt/btrfs

# データの再バランス (デバイス追加後に必要)
$ sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/btrfs

# バランスの状態確認
$ sudo btrfs balance status /mnt/btrfs

# バランスのキャンセル
$ sudo btrfs balance cancel /mnt/btrfs

# デバイスの統計情報
$ sudo btrfs device stats /mnt/btrfs
[/dev/sdb1].write_io_errs    0
[/dev/sdb1].read_io_errs     0
[/dev/sdb1].flush_io_errs    0
[/dev/sdb1].corruption_errs  0
[/dev/sdb1].generation_errs  0

5.7 圧縮

# === 透過的圧縮 ===

# マウント時に圧縮を有効化
$ sudo mount -o compress=zstd /dev/sdb1 /mnt/btrfs
$ sudo mount -o compress=zstd:3 /dev/sdb1 /mnt/btrfs   # zstd レベル3
$ sudo mount -o compress=lzo /dev/sdb1 /mnt/btrfs       # lzo (高速)
$ sudo mount -o compress=zlib /dev/sdb1 /mnt/btrfs      # zlib (高圧縮)
$ sudo mount -o compress-force=zstd /dev/sdb1 /mnt/btrfs # 全ファイル強制圧縮

# 圧縮アルゴリズムの比較
# zstd : 圧縮率と速度のバランスが良い (推奨)
# lzo  : 最速だが圧縮率は低い
# zlib : 最高圧縮率だが遅い

# ディレクトリ単位で圧縮を設定
$ sudo btrfs property set /mnt/btrfs/logs compression zstd

# 圧縮の確認
$ sudo btrfs property get /mnt/btrfs/logs
compression=zstd

# 圧縮効率の確認
$ sudo compsize /mnt/btrfs
Processed 50000 files, 30000 regular extents (35000 refs), 20000 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       65%       32G          49G          52G
none       100%       20G          20G          22G
zstd        40%       12G          29G          30G

# 既存データを圧縮 (デフラグ+再圧縮)
$ sudo btrfs filesystem defragment -r -czstd /mnt/btrfs/data

5.8 チェックサム

Btrfs はすべてのデータとメタデータにチェックサムを付与し、サイレントデータ破損 (ビット腐敗) を検出する。

# チェックサムアルゴリズムの指定 (ファイルシステム作成時)
$ sudo mkfs.btrfs --checksum crc32c /dev/sdb1    # デフォルト
$ sudo mkfs.btrfs --checksum xxhash /dev/sdb1     # 高速ハッシュ
$ sudo mkfs.btrfs --checksum sha256 /dev/sdb1     # 暗号学的ハッシュ
$ sudo mkfs.btrfs --checksum blake2 /dev/sdb1     # 高速暗号学的ハッシュ

# スクラブ: チェックサム検証と自動修復
$ sudo btrfs scrub start /mnt/btrfs

# スクラブの状態確認
$ sudo btrfs scrub status /mnt/btrfs
UUID:             12345678-1234-1234-1234-123456789abc
Scrub started:    Thu Apr 10 10:00:00 2026
Status:           running
Duration:         0:05:30
Total to scrub:   400.00GiB
Rate:             1.21GiB/s
Error summary:    no errors found

# 定期スクラブ (systemd timer)
$ sudo systemctl enable btrfs-scrub@-.timer
$ sudo systemctl start btrfs-scrub@-.timer

RAID 構成でチェックサムエラーが検出された場合、Btrfs は正常なコピーから自動的にデータを修復する。

5.9 Send/Receive

# === インクリメンタルバックアップ ===

# 初回: フルバックアップ
$ sudo btrfs subvolume snapshot -r /mnt/btrfs/data /mnt/btrfs/snapshots/data-base
$ sudo btrfs send /mnt/btrfs/snapshots/data-base | sudo btrfs receive /mnt/backup/

# 2回目以降: 差分バックアップ
$ sudo btrfs subvolume snapshot -r /mnt/btrfs/data /mnt/btrfs/snapshots/data-incr1
$ sudo btrfs send -p /mnt/btrfs/snapshots/data-base \
    /mnt/btrfs/snapshots/data-incr1 | sudo btrfs receive /mnt/backup/

# リモートバックアップ (SSH経由)
$ sudo btrfs send /mnt/btrfs/snapshots/data-base | \
    ssh backup-server "sudo btrfs receive /mnt/backup/"

# 差分をファイルに保存
$ sudo btrfs send -p /mnt/btrfs/snapshots/data-base \
    /mnt/btrfs/snapshots/data-incr1 > /tmp/btrfs-diff.stream

# ファイルから復元
$ sudo btrfs receive /mnt/restore/ < /tmp/btrfs-diff.stream

# 圧縮付きリモートバックアップ
$ sudo btrfs send /mnt/btrfs/snapshots/data-incr1 -p /mnt/btrfs/snapshots/data-base | \
    zstd -3 | ssh backup-server "zstd -d | sudo btrfs receive /mnt/backup/"

5.10 Btrfs ファイルシステムの作成とマウント

# === Btrfs ファイルシステムの作成 ===

# 基本的な作成
$ sudo mkfs.btrfs /dev/sdb1

# 詳細オプション付き作成
$ sudo mkfs.btrfs \
    -L "btrfs-data" \             # ラベル
    -n 16384 \                     # ノードサイズ: 16KB
    -s 4096 \                      # セクタサイズ: 4KB
    --checksum xxhash \            # チェックサムアルゴリズム
    -m raid1 \                     # メタデータ: RAID1
    -d raid0 \                     # データ: RAID0
    /dev/sdb1 /dev/sdc1

# シングルデバイス (DUP メタデータ)
$ sudo mkfs.btrfs -m dup -d single /dev/sdb1

# === マウントオプション ===

# 基本マウント
$ sudo mount /dev/sdb1 /mnt/btrfs

# 推奨マウントオプション (一般用途)
$ sudo mount -o defaults,noatime,compress=zstd,space_cache=v2,discard=async /dev/sdb1 /mnt/btrfs

# SSD 向け
$ sudo mount -o defaults,noatime,compress=zstd,space_cache=v2,discard=async,ssd /dev/sdb1 /mnt/btrfs

# データベース向け (CoW無効)
$ sudo mount -o defaults,noatime,nodatacow /dev/sdb1 /mnt/btrfs

# /etc/fstab エントリ例
# UUID=xxxx  /data  btrfs  defaults,noatime,compress=zstd,space_cache=v2,discard=async  0  0

5.11 Btrfs のパフォーマンスチューニング

# === パフォーマンスチューニング ===

# 1. space_cache v2 の有効化
$ sudo mount -o space_cache=v2 /dev/sdb1 /mnt/btrfs

# 2. 適切な圧縮の選択
# CPU に余裕がある場合: compress=zstd:3
# CPU が逼迫している場合: compress=lzo
# 圧縮不要: compress=no

# 3. discard=async (SSD 向け)
$ sudo mount -o discard=async /dev/sdb1 /mnt/btrfs

# 4. autodefrag (自動デフラグ)
$ sudo mount -o autodefrag /dev/sdb1 /mnt/btrfs

# 5. commit 間隔の調整
$ sudo mount -o commit=120 /dev/sdb1 /mnt/btrfs

# 6. スレッドプール設定
$ echo 4 > /sys/fs/btrfs/<UUID>/thread_pool

# 7. デフラグ
$ sudo btrfs filesystem defragment -r /mnt/btrfs/
$ sudo btrfs filesystem defragment -r -czstd /mnt/btrfs/  # 再圧縮付き

# 8. ファイルシステムの使用状況確認
$ sudo btrfs filesystem df /mnt/btrfs
Data, RAID1: total=200.00GiB, used=150.00GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=8.00GiB, used=5.50GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

$ sudo btrfs filesystem usage /mnt/btrfs

5.12 Btrfs のリペアツール

# === Btrfs ファイルシステムの修復 ===

# チェック (読み取り専用)
$ sudo btrfs check /dev/sdb1

# 修復実行 (注意: バックアップを取ってから)
$ sudo btrfs check --repair /dev/sdb1

# チャンクツリーの再構築
$ sudo btrfs rescue chunk-recover /dev/sdb1

# スーパーブロックの復元
$ sudo btrfs rescue super-recover /dev/sdb1

# ゼロログ (ログツリーをクリア)
$ sudo btrfs rescue zero-log /dev/sdb1

# restore モード (マウント不能な場合のデータ救出)
$ sudo btrfs restore /dev/sdb1 /mnt/recovery/

# restore で特定パスを指定
$ sudo btrfs restore -p /important/data /dev/sdb1 /mnt/recovery/

# read-only マウントで salvage
$ sudo mount -o ro,rescue=all /dev/sdb1 /mnt/rescue

6. ジャーナリングモード詳解

6.1 ジャーナリングとは

ジャーナリングは、ファイルシステムの更新操作をログ (ジャーナル) に先行記録することで、システムクラッシュや電源断後の整合性を保証する仕組みである。

【ジャーナリングなし (ext2)】
クラッシュ時: メタデータが不整合な状態で残る可能性あり
復旧: fsck で全ファイルシステムをスキャン (大容量で数時間かかる)

【ジャーナリングあり (ext3/ext4)】
クラッシュ時: ジャーナルから未完了の操作を再実行 or 破棄
復旧: ジャーナルの再生のみ (数秒で完了)

6.2 ext4 のジャーナリングモード

data=journal モード

すべてのデータとメタデータをジャーナルに書き込む。最も安全だがパフォーマンスは最低。

Write 操作の流れ (data=journal):
1. データをジャーナルに書き込む
2. メタデータをジャーナルに書き込む
3. ジャーナルコミット
4. データを本来の位置に書き込む
5. メタデータを本来の位置に書き込む
6. ジャーナルのトランザクションを解放

※ データが2回書き込まれるため、書き込みスループットが半減する

# data=journal でマウント
$ sudo mount -o data=journal /dev/sdb1 /mnt/data

# 用途: 重要なデータベース、金融系システム

data=ordered モード (デフォルト)

データは本来の位置に直接書き込み、メタデータのみジャーナルに記録する。ただし、メタデータのコミット前にデータの書き込み完了を保証する。

Write 操作の流れ (data=ordered):
1. データを本来の位置に書き込む
2. データの書き込み完了を待つ
3. メタデータをジャーナルに書き込む
4. ジャーナルコミット
5. メタデータを本来の位置に書き込む

※ クラッシュ時にデータが部分的に書き込まれている可能性はあるが、
   メタデータは常に整合性が保たれる

# data=ordered でマウント (デフォルト)
$ sudo mount -o data=ordered /dev/sdb1 /mnt/data

# 用途: 一般用途 (デフォルト推奨)

data=writeback モード

メタデータのみジャーナルに記録し、データの書き込み順序を保証しない。最高のパフォーマンスだが、クラッシュ後に古いデータが見える可能性がある。

Write 操作の流れ (data=writeback):
1. データを本来の位置に書き込む (非同期)
2. メタデータをジャーナルに書き込む (データ書き込み完了を待たない)
3. ジャーナルコミット
4. メタデータを本来の位置に書き込む

※ メタデータが先にコミットされ、データがまだ書き込まれていない状態で
   クラッシュすると、ファイルに古いデータ (stale data) が含まれる可能性

# data=writeback でマウント
$ sudo mount -o data=writeback /dev/sdb1 /mnt/data

# 用途: ログファイル、一時データ、パフォーマンス重視

6.3 ジャーナリングモードの比較

項目	journal	ordered	writeback
データの安全性	最高	高	中
メタデータの安全性	最高	最高	最高
書き込み性能	低	中	高
読み取り性能	同等	同等	同等
ディスクI/O量	多 (2x)	中	少
stale data リスク	なし	なし	あり
推奨用途	金融/DB	一般	ログ/tmp

6.4 XFS のジャーナリング

XFS はメタデータジャーナリングのみをサポートし、data=ordered 相当の挙動を提供する。

# XFS ログの設定
$ sudo mkfs.xfs -l size=256m,version=2 /dev/sdb1

# 外部ログデバイスの使用 (高性能)
$ sudo mkfs.xfs -l logdev=/dev/ssd1,size=256m /dev/sdb1
$ sudo mount -o logdev=/dev/ssd1 /dev/sdb1 /mnt/xfs

# ログバッファの最適化
$ sudo mount -o logbufs=8,logbsize=256k /dev/sdb1 /mnt/xfs

6.5 Btrfs のジャーナリング (CoW)

Btrfs は従来のジャーナリングではなく、コピーオンライト (CoW) によってクラッシュ整合性を保証する。

Btrfs の CoW によるクラッシュ整合性:

1. 変更されたデータを新しい位置に書き込む
2. メタデータツリーを上位に向かって更新 (新しいノードを作成)
3. ルートノードを更新
4. スーパーブロックをアトミックに更新 (コミットポイント)

クラッシュ時:
- スーパーブロック更新前: 旧データが完全に保持される
- スーパーブロック更新後: 新データが完全に反映される
- 部分的な状態は発生しない (アトミック)

7. OverlayFS (コンテナ向け)

7.1 概要

OverlayFS はユニオンファイルシステムの一種であり、複数のディレクトリを重ね合わせて単一のファイルシステムとして提示する。Docker/Podman のコンテナストレージドライバーとして広く使用されている。

OverlayFS の構造:

          マージビュー (merged)
          /    |    \
        /      |      \
      /        |        \
  upperdir  workdir  lowerdir
  (書き込み) (作業用) (読み取り専用)

例:
lowerdir (ベースイメージ):
  /bin/bash
  /etc/passwd
  /usr/lib/...

upperdir (変更レイヤー):
  /etc/hostname  (新規作成)
  /etc/passwd    (変更)

merged (ユーザーから見えるビュー):
  /bin/bash      (lowerdir から)
  /etc/hostname  (upperdir から)
  /etc/passwd    (upperdir から - 上書き)
  /usr/lib/...   (lowerdir から)

7.2 OverlayFS の使用

# === 基本的な使用 ===

# ディレクトリの準備
$ mkdir -p /tmp/overlay/{lower,upper,work,merged}

# lower ディレクトリにファイルを配置
$ echo "original" > /tmp/overlay/lower/file1.txt
$ echo "base config" > /tmp/overlay/lower/config.txt

# OverlayFS をマウント
$ sudo mount -t overlay overlay \
    -o lowerdir=/tmp/overlay/lower,upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work \
    /tmp/overlay/merged

# マージビューを確認
$ ls /tmp/overlay/merged/
config.txt  file1.txt

# ファイルを変更 (CoW で upper に書き込まれる)
$ echo "modified" > /tmp/overlay/merged/config.txt

# upper ディレクトリを確認
$ ls /tmp/overlay/upper/
config.txt
$ cat /tmp/overlay/upper/config.txt
modified

# lower は変更されない
$ cat /tmp/overlay/lower/config.txt
base config

# === 複数 lower レイヤー ===
$ sudo mount -t overlay overlay \
    -o lowerdir=/layer3:/layer2:/layer1,upperdir=/upper,workdir=/work \
    /merged
# layer3 が最上位、layer1 が最下位

7.3 Docker における OverlayFS

# Docker のストレージドライバーを確認
$ docker info | grep "Storage Driver"
 Storage Driver: overlay2

# Docker のレイヤー構造を確認
$ docker inspect nginx:latest | jq '.[0].GraphDriver'
{
  "Data": {
    "LowerDir": "/var/lib/docker/overlay2/abc123/diff:/var/lib/docker/overlay2/def456/diff",
    "MergedDir": "/var/lib/docker/overlay2/ghi789/merged",
    "UpperDir": "/var/lib/docker/overlay2/ghi789/diff",
    "WorkDir": "/var/lib/docker/overlay2/ghi789/work"
  },
  "Name": "overlay2"
}

# overlay2 のディスク使用量確認
$ du -sh /var/lib/docker/overlay2/
15G     /var/lib/docker/overlay2/

# Docker デーモンの設定 (/etc/docker/daemon.json)
{
    "storage-driver": "overlay2",
    "storage-opts": [
        "overlay2.override_kernel_check=true",
        "overlay2.size=20G"
    ]
}

7.4 OverlayFS のパフォーマンス特性

操作                  | パフォーマンス | 備考
---------------------|-------------|------
読み取り (lower)      | ○ 高速     | 直接アクセス
読み取り (upper)      | ○ 高速     | 直接アクセス
新規ファイル作成       | ○ 高速     | upper に直接作成
ファイル変更 (初回)    | △ やや遅い  | copy-up 発生
ファイル変更 (2回目以降)| ○ 高速     | upper で直接操作
ファイル削除           | ○ 高速     | whiteout ファイル作成
ディレクトリ列挙       | △ やや遅い  | 全レイヤーをマージ

8. tmpfs と ramfs

8.1 tmpfs

tmpfs は RAM 上に構築されるファイルシステムであり、スワップにも対応する。

# tmpfs のマウント
$ sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk

# サイズ制限付き
$ sudo mount -t tmpfs -o size=512M,nr_inodes=10000,mode=1777 tmpfs /tmp

# /etc/fstab エントリ
# tmpfs  /tmp  tmpfs  defaults,size=2G,mode=1777  0  0

# 現在の tmpfs の使用状況
$ df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           2.0G  100M  1.9G   5% /tmp

# tmpfs のオプション
# size    : 最大サイズ (デフォルト: RAM の 50%)
# nr_inodes: 最大 inode 数
# mode    : パーミッション
# uid     : 所有者UID
# gid     : 所有者GID
# huge    : Huge Pages の使用制御

# /dev/shm (POSIX 共有メモリ)
$ ls -la /dev/shm
$ df -h /dev/shm

# /run (ランタイムデータ)
$ mount | grep tmpfs
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3256660k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)

8.2 ramfs

ramfs は tmpfs の前身であり、サイズ制限がなく、スワップにも退避されない。

# ramfs のマウント
$ sudo mount -t ramfs ramfs /mnt/ramdisk

# 注意: ramfs にはサイズ制限がない
# メモリを使い果たすとシステムがフリーズする可能性がある
# 通常は tmpfs の使用を推奨

8.3 tmpfs vs ramfs 比較

項目	tmpfs	ramfs
サイズ制限	あり (指定可能)	なし (危険)
スワップ対応	あり	なし
ページキャッシュ	使用	使用
OOM リスク	低い	高い
推奨度	推奨	非推奨
用途	/tmp, /run, /dev/shm	特殊用途のみ

9. FUSE (Filesystem in Userspace)

9.1 概要

FUSE はユーザー空間でファイルシステムを実装するためのフレームワークである。カーネルモジュールの開発が不要で、任意のプログラミング言語でファイルシステムを実装できる。

FUSE アーキテクチャ:

ユーザー空間アプリケーション
       |
   VFS (カーネル)
       |
   FUSE カーネルモジュール (/dev/fuse)
       |
   libfuse (ユーザー空間)
       |
   FUSE ファイルシステムデーモン
       |
   バックエンド (クラウドストレージ, SSH, DB, etc.)

9.2 代表的な FUSE ファイルシステム

# === sshfs (SSH 経由のリモートマウント) ===
$ sudo apt install sshfs
$ sshfs user@remote:/path /mnt/remote -o reconnect,ServerAliveInterval=15
$ fusermount -u /mnt/remote  # アンマウント

# === rclone mount (クラウドストレージ) ===
$ rclone mount gdrive:backup /mnt/gdrive --allow-other --vfs-cache-mode full
$ fusermount -u /mnt/gdrive

# === s3fs (Amazon S3) ===
$ s3fs mybucket /mnt/s3 -o passwd_file=$HOME/.passwd-s3fs
$ fusermount -u /mnt/s3

# === ntfs-3g (NTFS) ===
$ sudo mount -t ntfs-3g /dev/sdb1 /mnt/windows

# === encfs (暗号化) ===
$ encfs ~/.encrypted ~/decrypted
$ fusermount -u ~/decrypted

# === gocryptfs (暗号化 - 推奨) ===
$ gocryptfs -init ~/.encrypted
$ gocryptfs ~/.encrypted ~/decrypted
$ fusermount -u ~/decrypted

9.3 FUSE のパフォーマンス特性

# FUSE のパフォーマンスオプション
$ mount -t fuse.sshfs ... -o \
    max_read=131072 \        # 最大読み取りサイズ
    max_write=131072 \       # 最大書き込みサイズ
    max_readahead=131072 \   # readahead サイズ
    async_read \             # 非同期読み取り
    big_writes               # 大きな書き込み要求を許可

# FUSE のパフォーマンスは一般にカーネルファイルシステムより低い
# 理由: ユーザー空間-カーネル空間のコンテキストスイッチが発生
# 目安: カーネルFSの 50-80% の性能

10. F2FS (Flash-Friendly File System)

10.1 概要

F2FS は Samsung が開発したフラッシュストレージ (SSD, eMMC, SD カード) に最適化されたファイルシステムである。NAND フラッシュの特性 (消去ブロック、ウェアレベリング) を考慮した設計になっている。

F2FS のディスクレイアウト:

+------+------+------+------+------+------+------+------+
| SB   | CP   | SIT  | NAT  | SSA  |      メイン       |
|      |      |      |      |      |      エリア        |
+------+------+------+------+------+------+------+------+

SB  : スーパーブロック
CP  : チェックポイント
SIT : セグメント情報テーブル
NAT : ノードアドレステーブル
SSA : セグメント概要エリア
メイン: 実データとノード

10.2 F2FS の主要機能

# === F2FS ファイルシステムの作成 ===
$ sudo mkfs.f2fs \
    -l "flash-storage" \    # ラベル
    -O encrypt \            # 暗号化サポート
    -O extra_attr \         # 拡張属性
    -O compression \        # 圧縮サポート
    /dev/sdb1

# === マウントオプション ===
$ sudo mount -t f2fs \
    -o noatime,compress_algorithm=lz4,compress_extension=*.log,gc_merge,atgc \
    /dev/sdb1 /mnt/flash

# 主要マウントオプション:
# compress_algorithm : 圧縮アルゴリズム (lz4, zstd, lzo, lzo-rle)
# compress_extension : 圧縮対象ファイル拡張子
# gc_merge           : GC (ガベージコレクション) の最適化
# atgc               : 適応型GC (age-threshold GC)
# discard            : TRIM サポート

# === F2FS の状態確認 ===
$ cat /sys/fs/f2fs/sdb1/gc_urgent  # GCの緊急度
$ cat /sys/fs/f2fs/sdb1/gc_idle    # GCアイドル閾値

# === F2FS の修復 ===
$ sudo fsck.f2fs /dev/sdb1
$ sudo fsck.f2fs -a /dev/sdb1  # 自動修復

10.3 F2FS が適するユースケース

Android デバイス (多くの Android スマートフォンで採用)
SD カード/eMMC ストレージ
USB フラッシュドライブ
組み込みシステム
SSD (ただし ext4/XFS でも十分な場合が多い)

11. Bcachefs (Linux 6.7 新規)

11.1 概要

Bcachefs は Kent Overstreet が開発した次世代ファイルシステムで、2024年に Linux 6.7 で mainline にマージされた。bcache (ブロックレイヤーキャッシング) から発展し、Btrfs と ZFS の長所を組み合わせた設計を目指している。

主要スペック:

項目	値
コピーオンライト	あり
チェックサム	あり (CRC32C, CRC64, xxhash, SHA-256)
圧縮	あり (lz4, gzip, zstd)
暗号化	あり (ChaCha20/Poly1305)
スナップショット	あり
Erasure Coding	あり
階層型ストレージ	あり (SSD キャッシュ + HDD)
RAID	1/5/6 + Erasure Coding
リプリケーション	あり

11.2 Bcachefs の特徴的機能

# === Bcachefs ファイルシステムの作成 ===

# 基本的な作成
$ sudo bcachefs format /dev/sdb1

# 暗号化+圧縮+チェックサム
$ sudo bcachefs format \
    --encrypted \
    --compression=zstd \
    --data_checksum=xxhash \
    --metadata_checksum=crc32c \
    /dev/sdb1

# マルチデバイス (階層型ストレージ)
$ sudo bcachefs format \
    --label=ssd.ssd1 \
    --durability=1 \
    /dev/nvme0n1p1 \
    --label=hdd.hdd1 \
    --durability=2 \
    /dev/sdb1

# === マウント ===
$ sudo bcachefs mount /dev/sdb1 /mnt/bcachefs
$ sudo bcachefs mount /dev/nvme0n1p1:/dev/sdb1 /mnt/bcachefs  # マルチデバイス

# === スナップショット ===
$ sudo bcachefs subvolume create /mnt/bcachefs/data
$ sudo bcachefs subvolume snapshot /mnt/bcachefs/data /mnt/bcachefs/snapshots/data-snap

# === ファイルシステムの確認・修復 ===
$ sudo bcachefs fsck /dev/sdb1
$ sudo bcachefs show-super /dev/sdb1

# === 階層型ストレージの設定 ===
# SSD にホットデータ、HDD にコールドデータを自動配置
# foreground_target: 書き込み先 (SSD)
# background_target: バックグラウンド移動先 (HDD)
# promote_target: 読み込みキャッシュ (SSD)

$ sudo bcachefs set-option \
    --foreground_target=ssd \
    --background_target=hdd \
    --promote_target=ssd \
    /mnt/bcachefs

11.3 Bcachefs の現状と注意点

安定性: Linux 6.7+ で mainline だが、まだ成熟段階にある
本番利用: 重要なデータにはまだ早い (2026年4月現在)
開発速度: 活発に開発が進行中
コミュニティ: 成長中だが Btrfs/XFS ほど大きくない

推奨: テスト環境や非重要データでの評価を推奨
今後: Btrfs の代替として期待されている

12. ファイルシステムベンチマーク

12.1 fio (Flexible I/O Tester)

# === fio のインストール ===
$ sudo apt install fio          # Debian/Ubuntu
$ sudo dnf install fio          # Fedora/RHEL

# === 基本的なベンチマーク ===

# シーケンシャル読み取り
$ fio --name=seqread --rw=read --bs=1M --size=4G \
    --numjobs=1 --iodepth=32 --runtime=60 --time_based \
    --filename=/mnt/test/fio-test --direct=1 --ioengine=libaio

# シーケンシャル書き込み
$ fio --name=seqwrite --rw=write --bs=1M --size=4G \
    --numjobs=1 --iodepth=32 --runtime=60 --time_based \
    --filename=/mnt/test/fio-test --direct=1 --ioengine=libaio

# ランダム読み取り (4K)
$ fio --name=randread --rw=randread --bs=4k --size=4G \
    --numjobs=4 --iodepth=32 --runtime=60 --time_based \
    --filename=/mnt/test/fio-test --direct=1 --ioengine=libaio

# ランダム書き込み (4K)
$ fio --name=randwrite --rw=randwrite --bs=4k --size=4G \
    --numjobs=4 --iodepth=32 --runtime=60 --time_based \
    --filename=/mnt/test/fio-test --direct=1 --ioengine=libaio

# 混合ワークロード (70% 読み取り, 30% 書き込み)
$ fio --name=mixed --rw=randrw --rwmixread=70 --bs=4k --size=4G \
    --numjobs=4 --iodepth=32 --runtime=60 --time_based \
    --filename=/mnt/test/fio-test --direct=1 --ioengine=libaio

# === ファイルシステム比較用ジョブファイル ===
# /tmp/fs-bench.fio
$ cat << 'EOF' > /tmp/fs-bench.fio
[global]
ioengine=libaio
direct=1
time_based
runtime=120
size=8G
group_reporting

[seq-read-1M]
rw=read
bs=1M
numjobs=1
iodepth=32

[seq-write-1M]
rw=write
bs=1M
numjobs=1
iodepth=32

[rand-read-4k]
rw=randread
bs=4k
numjobs=4
iodepth=32

[rand-write-4k]
rw=randwrite
bs=4k
numjobs=4
iodepth=32

[rand-rw-4k]
rw=randrw
rwmixread=70
bs=4k
numjobs=4
iodepth=32
EOF

$ fio /tmp/fs-bench.fio --filename=/mnt/test/fio-test --output-format=json \
    --output=/tmp/fio-results.json

12.2 bonnie++

# === bonnie++ のインストール ===
$ sudo apt install bonnie++

# === ベンチマーク実行 ===
$ bonnie++ -d /mnt/test -s 16G -n 256 -r 8G -u root

# オプション:
# -d : テストディレクトリ
# -s : テストファイルサイズ (RAMの2倍推奨)
# -n : ファイル数テストの規模
# -r : RAMサイズ (キャッシュ効果を排除するため)
# -u : 実行ユーザー

# CSV 出力
$ bonnie++ -d /mnt/test -s 16G -r 8G -u root -q > /tmp/bonnie-results.csv

# 結果の整形
$ cat /tmp/bonnie-results.csv | bon_csv2html > /tmp/bonnie-report.html

12.3 iozone

# === iozone のインストール ===
$ sudo apt install iozone3

# === ベンチマーク実行 ===

# 全自動テスト
$ iozone -a -g 4G -f /mnt/test/iozone.tmp

# レコードサイズと ファイルサイズを指定
$ iozone -s 4G -r 4k -r 64k -r 1M -f /mnt/test/iozone.tmp

# スループットテスト (マルチスレッド)
$ iozone -t 4 -s 1G -r 1M -i 0 -i 1 -F /mnt/test/f1 /mnt/test/f2 /mnt/test/f3 /mnt/test/f4

# Excel 出力
$ iozone -a -g 4G -f /mnt/test/iozone.tmp -Rb /tmp/iozone-results.xls

# オプション:
# -a : 自動テスト
# -g : 最大ファイルサイズ
# -s : ファイルサイズ
# -r : レコードサイズ
# -t : スレッド数
# -i : テスト種別 (0=write, 1=read, 2=randread, 3=randwrite)

12.4 ベンチマーク実施のベストプラクティス

# === ベンチマーク前の準備 ===

# 1. ページキャッシュのクリア
$ sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

# 2. 他のI/Oプロセスの確認
$ iostat -x 1 3

# 3. CPU ガバナーの固定 (安定した計測のため)
$ echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# 4. TRIM の実行 (SSD)
$ sudo fstrim -v /mnt/test

# 5. ファイルシステムの同期
$ sync

# === 結果比較のスクリプト例 ===
#!/bin/bash
# /usr/local/bin/fs-benchmark.sh

FILESYSTEMS=("ext4" "xfs" "btrfs")
TEST_DIR="/mnt/test"
RESULTS_DIR="/tmp/fs-benchmark-results"
DEVICE="/dev/sdb1"

mkdir -p "$RESULTS_DIR"

for fs in "${FILESYSTEMS[@]}"; do
    echo "=== Testing $fs ==="

    # ファイルシステム作成
    sudo umount "$TEST_DIR" 2>/dev/null
    case "$fs" in
        ext4)  sudo mkfs.ext4 -F "$DEVICE" ;;
        xfs)   sudo mkfs.xfs -f "$DEVICE" ;;
        btrfs) sudo mkfs.btrfs -f "$DEVICE" ;;
    esac

    # マウント
    sudo mount -o noatime "$DEVICE" "$TEST_DIR"

    # キャッシュクリア
    sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

    # fio テスト
    fio /tmp/fs-bench.fio \
        --filename="$TEST_DIR/fio-test" \
        --output-format=json \
        --output="$RESULTS_DIR/$fs-results.json"

    # クリーンアップ
    sudo umount "$TEST_DIR"
done

echo "Results saved to $RESULTS_DIR"

13. ファイルシステム機能比較表

13.1 主要機能比較

機能	ext4	XFS	Btrfs	F2FS	Bcachefs
最大ファイルサイズ	16 TiB	8 EiB	16 EiB	3.94 TiB	16 EiB+
最大ボリュームサイズ	1 EiB	8 EiB	16 EiB	16 TiB	16 EiB+
CoW	-	Reflink	全面	-	全面
スナップショット	-	-	あり	-	あり
チェックサム (データ)	-	-	あり	-	あり
チェックサム (メタデータ)	あり	あり	あり	あり	あり
圧縮	-	-	あり	あり	あり
暗号化	fscrypt	-	-	fscrypt	ネイティブ
RAID	-	-	あり	-	あり
クォータ	あり	あり	あり	-	あり
オンライン拡大	あり	あり	あり	あり	あり
オンライン縮小	-	-	あり	-	あり
デフラグ	あり	あり	あり	あり	あり
Reflink	-	あり	あり	-	あり
安定性	最高	最高	高	高	開発中

13.2 パフォーマンス特性比較

ワークロード	ext4	XFS	Btrfs
シーケンシャル読み取り	優秀	優秀	良好
シーケンシャル書き込み	優秀	優秀	良好
ランダム読み取り (4K)	優秀	優秀	良好
ランダム書き込み (4K)	優秀	良好	良好
大量小ファイル作成	良好	良好	優秀
メタデータ集中処理	良好	優秀	良好
並列I/O	良好	優秀	良好
CPU 使用率	低い	低い	やや高い

13.3 ツール比較

ツール	ext4	XFS	Btrfs
作成	mkfs.ext4	mkfs.xfs	mkfs.btrfs
チェック	fsck.ext4	xfs_repair	btrfs check
デフラグ	e4defrag	xfs_fsr	btrfs filesystem defragment
リサイズ	resize2fs	xfs_growfs	btrfs filesystem resize
デバッグ	debugfs	xfs_db	btrfs inspect-internal
ダンプ	dumpe2fs	xfs_metadump	btrfs-image
チューニング	tune2fs	xfs_admin	btrfs property

14. ファイルシステム選択のベストプラクティス

14.1 ユースケース別推奨

【一般用途 / デスクトップ】
→ ext4 (最も安定、広くサポート)
→ Btrfs (スナップショットが必要な場合)

【エンタープライズサーバー】
→ XFS (大容量、高並列I/O)
→ ext4 (シンプルさ重視)

【データベースサーバー】
→ XFS (大容量DB、並列I/O)
→ ext4 (小〜中規模DB)
※ Btrfs は CoW のオーバーヘッドにより非推奨 (nodatacow でも限定的)

【NAS / ファイルサーバー】
→ Btrfs (スナップショット、圧縮、チェックサム)
→ XFS (シンプルさと性能重視)

【コンテナホスト】
→ ext4 + OverlayFS (Docker デフォルト)
→ Btrfs (Docker の Btrfs ドライバー)
→ XFS + OverlayFS

【組み込み / フラッシュストレージ】
→ F2FS (フラッシュ最適化)
→ ext4 (汎用性重視)

【バックアップサーバー】
→ Btrfs (send/receive、圧縮、重複排除)

【仮想マシンイメージストレージ】
→ XFS + reflink (高速クローン)
→ Btrfs (スナップショット)

【一時データ / キャッシュ】
→ tmpfs (メモリ上)
→ ext4 (ディスク上)

【階層型ストレージ (SSD + HDD)】
→ Bcachefs (ネイティブサポート、ただし成熟度に注意)
→ dm-cache + ext4/XFS (従来方式)

14.2 選択基準のフローチャート

Q1: スナップショットが必要?
  → Yes: Q2
  → No:  Q3

Q2: RAID も必要?
  → Yes: Btrfs (RAID1/10) or Bcachefs
  → No:  Btrfs

Q3: 大容量 (>16TB) or 高並列I/O?
  → Yes: XFS
  → No:  Q4

Q4: 最大の安定性・互換性が必要?
  → Yes: ext4
  → No:  Q5

Q5: フラッシュストレージ特化?
  → Yes: F2FS
  → No:  ext4 (デフォルト推奨)

14.3 移行のベストプラクティス

# === ファイルシステムの移行手順 ===

# 1. 現在のファイルシステムの確認
$ df -Th
$ mount | grep "type ext4\|type xfs\|type btrfs"

# 2. データのバックアップ
$ sudo rsync -aAXv --progress /source/ /backup/

# 3. 新しいファイルシステムの作成
$ sudo mkfs.xfs -f /dev/sdb1  # 例: ext4 → XFS

# 4. データの復元
$ sudo mount /dev/sdb1 /mnt/new
$ sudo rsync -aAXv --progress /backup/ /mnt/new/

# 5. fstab の更新
$ sudo blkid /dev/sdb1  # UUID を確認
$ sudo vi /etc/fstab    # UUID とタイプを更新

# 6. 検証
$ sudo umount /mnt/new
$ sudo mount -a
$ df -Th

15. まとめ

15.1 各ファイルシステムのまとめ

ext4: Linux の標準ファイルシステム。20年以上の実績があり、最も安定している。ジャーナリング、エクステント、遅延割り当て、インラインデータ、fscrypt による暗号化をサポート。大多数のユースケースで最初の選択肢となる。

XFS: 大規模ストレージと高並列I/Oに最適化されたファイルシステム。アロケーショングループによる並列処理、B+ ツリーベースのメタデータ管理、reflink による高速コピーが特徴。RHEL/CentOS のデフォルト。

Btrfs: 次世代の多機能ファイルシステム。CoW、スナップショット、内蔵 RAID、圧縮、チェックサム、send/receive など、ボリュームマネージャーの機能を内包。NAS やバックアップ用途に最適。

F2FS: フラッシュストレージに特化したファイルシステム。NAND の特性を考慮した設計により、SSD や eMMC での性能が優れる。

Bcachefs: 最新の CoW ファイルシステム。階層型ストレージ、暗号化、圧縮、Erasure Coding をネイティブサポート。将来性は高いが、本番環境での利用はまだ慎重に。

15.2 今後の展望

io_uring の活用: 各ファイルシステムでの io_uring 最適化が進行中
Bcachefs の成熟: Linux カーネルでの安定化と機能拡張が継続
NVMe/ZNS 対応: ゾーンドストレージ向けの最適化
CXL メモリ対応: Compute Express Link メモリを活用した新しいストレージ階層
ファイルシステム暗号化の標準化: fscrypt の機能拡張と対応ファイルシステムの拡大

15.3 参考資料

Linux Kernel Documentation: https://www.kernel.org/doc/html/latest/filesystems/
ext4 Wiki: https://ext4.wiki.kernel.org/
XFS Documentation: https://xfs.wiki.kernel.org/
Btrfs Wiki: https://btrfs.wiki.kernel.org/
F2FS Documentation: https://www.kernel.org/doc/html/latest/filesystems/f2fs.html
Bcachefs Documentation: https://bcachefs.org/
fio Documentation: https://fio.readthedocs.io/

本文書は 2026年4月時点の情報に基づいています。各ファイルシステムは活発に開発が続けられており、最新の情報はカーネルのリリースノートおよび各プロジェクトのドキュメントを参照してください。

Linux Kernel File Systems

Linux Kernel ファイルシステム総合ガイド (ext4, XFS, Btrfs)

目次

1. はじめに

対象読者

前提知識

本文書の表記規則

2. ファイルシステムの基礎概念

2.1 VFS (Virtual File System) レイヤー

2.2 ブロックデバイスとセクタ

2.3 inode の構造

2.4 エクステント vs ブロックマッピング

3. ext4 ファイルシステム

3.1 概要と歴史

3.2 ext4 のディスクレイアウト

3.3 ジャーナリング

3.4 エクステント

3.5 遅延割り当て (Delayed Allocation)

3.6 インラインデータ (Inline Data)

3.7 暗号化 (fscrypt)

3.8 ext4 ファイルシステムの作成とマウント

3.9 ext4 のパフォーマンスチューニング

3.10 ext4 のリペアツール

4. XFS ファイルシステム

4.1 概要と歴史

4.2 XFS の内部アーキテクチャ

アロケーショングループ (AG)

B+ ツリー構造

4.3 遅延割り当て (Delayed Allocation)

4.4 Reflink (参照リンク)

4.5 オンラインデフラグメンテーション

4.6 XFS ファイルシステムの作成とマウント

4.7 XFS のパフォーマンスチューニング

4.8 XFS のリペアツール

5. Btrfs ファイルシステム

5.1 概要と歴史

5.2 Btrfs の内部アーキテクチャ

5.3 コピーオンライト (CoW)

5.4 スナップショット

5.5 サブボリューム

5.6 RAID

5.7 圧縮

5.8 チェックサム

5.9 Send/Receive

5.10 Btrfs ファイルシステムの作成とマウント

5.11 Btrfs のパフォーマンスチューニング

5.12 Btrfs のリペアツール

6. ジャーナリングモード詳解

6.1 ジャーナリングとは

6.2 ext4 のジャーナリングモード

data=journal モード

data=ordered モード (デフォルト)

data=writeback モード

6.3 ジャーナリングモードの比較

6.4 XFS のジャーナリング

6.5 Btrfs のジャーナリング (CoW)

7. OverlayFS (コンテナ向け)

7.1 概要

7.2 OverlayFS の使用

7.3 Docker における OverlayFS

7.4 OverlayFS のパフォーマンス特性

8. tmpfs と ramfs

8.1 tmpfs

8.2 ramfs

8.3 tmpfs vs ramfs 比較

9. FUSE (Filesystem in Userspace)

9.1 概要

9.2 代表的な FUSE ファイルシステム

9.3 FUSE のパフォーマンス特性

10. F2FS (Flash-Friendly File System)

10.1 概要

10.2 F2FS の主要機能

10.3 F2FS が適するユースケース

11. Bcachefs (Linux 6.7 新規)

11.1 概要

11.2 Bcachefs の特徴的機能

11.3 Bcachefs の現状と注意点

12. ファイルシステムベンチマーク

12.1 fio (Flexible I/O Tester)

12.2 bonnie++