ext4 / Btrfs / NTFS / XFS 四大文件系统深度对比：原理、特性与 Btrfs 快照完全解析

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

┌─────────────────────────────────────────────────────────────┐
│                文件系统生态地图                                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Linux 生态                                                  │
│   ├── ext4 ────── 经典稳定，Linux 装机量最大的默认 FS          │
│   ├── XFS ─────── RHEL/CentOS 默认，擅长大文件                 │
│   └── Btrfs ───── 现代特性集大成者，COW + 快照 + 内置 RAID      │
│                                                             │
│  Windows 生态                                                 │
│   └── NTFS ────── Windows 默认，权限/加密/日志俱全              │
│                                                             │
│  其他现代 FS                                                  │
│   ├── ZFS ─────── 存储界的传奇，OpenZFS 跨平台                 │
│   ├── APFS ────── macOS/iOS 默认                               │
│   └── ReFS ────── Windows Server 现代版                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

1
2
3

ext2（1993）→ ext3（2001）→ ext4（2008）→ 至今
                ↑              ↑
                加入日志       Extent + 多块分配 + 大容量支持

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

✓ 优势：
  - 极度稳定，20 年实战检验
  - 性能可预期，没有"惊喜"
  - 几乎所有 Linux 工具都支持
  - 修复工具成熟（e2fsck）
  - 资源占用低

✗ 局限：
  - 没有内建快照（需要 LVM 或第三方工具）
  - 没有透明压缩
  - 没有数据校验（bit rot 静默腐化）
  - 没有内建 RAID
  - 单目录文件数有限（数十万级别）

1
2
3
4
5
6
7
8

XFS 分配组结构：
  ┌──────┬──────┬──────┬──────┬──────┐
  │ AG0  │ AG1  │ AG2  │ AG3  │ AG4  │
  │超级B │  元数据│  数据│  数据│  数据│
  │  + 数据│              │      │      │
  └──────┴──────┴──────┴──────┴──────┘
  ↑ 每个 AG 独立管理自己的 inode、空闲空间、journal
  ↑ 多 AG 并行操作 → 多核性能极佳

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

✓ 优势：
  - 大文件性能极佳（视频、数据库、科学计算）
  - 多核 CPU 扩展性强（AG 并行）
  - 在线扩容（lvextend + xfs_growfs）
  - 稳定可靠（RHEL 主力 FS）
  - 性能可预测

✗ 局限：
  - 不支持缩小（这是公认的硬限制）
  - 没有内建快照（需要 dm-thin 或外部工具）
  - 没有数据校验
  - 没有内建 RAID
  - 单机部署成本相对高（适合大磁盘）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

✓ 优势：
  - 完善的权限与安全模型
  - 文件级加密（EFS）
  - 透明压缩（NTFS 压缩）
  - 单目录文件数：理论上 4G+
  - Windows 生态完整支持

✗ 局限：
  - 跨平台兼容性差（Linux 写 NTFS 长期不稳定）
  - 没有 COW 快照（早期 VSS 是基于卷影复制）
  - 没有数据校验
  - 设计复杂，性能不如 XFS/ext4
  - 大量小文件性能下降明显

1
2
3
4
5

# Linux 5.15+ 内核自带 ntfs3 驱动
mount -t ntfs3 /dev/sda1 /mnt/windows

# 或使用传统 ntfs-3g
mount -t ntfs-3g /dev/sda1 /mnt/windows

1
2
3
4
5
6
7

传统架构：
  磁盘 → 物理卷 → LVM 卷组 → 逻辑卷 → ext4 文件系统 → 目录树
  多个步骤，多个工具

Btrfs 架构：
  磁盘 → Btrfs 文件系统（自带卷管理、RAID、快照）
  一个步骤，一个 FS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

✓ 优势：
  - 内建快照，秒级完成
  - 内建 RAID，无需 mdadm
  - 数据校验，防止静默损坏
  - 透明压缩（zstd 几乎不影响性能）
  - 子卷可以独立挂载
  - 增量备份（send/receive）
  - 支持 SSD TRIM

✗ 局限：
  - 稳定性历史上不如 ext4（2016 年前问题多）
  - RAID 5/6 实现长期不成熟（2024 年仍需注意）
  - 单文件修复能力弱（损坏后只能恢复整个子卷）
  - 工具链相对较新
  - 不支持 ext4 那种内核原生 fsck 全面修复

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 创建 Btrfs 文件系统
mkfs.btrfs -L mydata /dev/sdb1

# 挂载
mount -t btrfs /dev/sdb1 /mnt/data

# 创建子卷
btrfs subvolume create /mnt/data/subvol1
btrfs subvolume create /mnt/data/subvol2

# 单独挂载子卷
mount -t btrfs -o subvol=subvol1 /dev/sdb1 /mnt/subvol1

# 启用透明压缩
mount -o remount,compress=zstd /mnt/data

# 创建快照
btrfs subvolume snapshot /mnt/data/subvol1 /mnt/data/snap1

# 查看磁盘使用
btrfs filesystem df /mnt/data
btrfs filesystem usage /mnt/data

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

大文件顺序读写：
  XFS > Btrfs > ext4 > NTFS

小文件随机读写：
  XFS ≈ Btrfs > ext4 > NTFS

创建/删除大量小文件：
  Btrfs > XFS > ext4 > NTFS

元数据操作（创建目录、移动文件）：
  Btrfs > XFS > ext4 > NTFS

数据库（PostgreSQL/MySQL）：
  XFS ≈ ext4 > Btrfs (旧) > NTFS
  （Btrfs 在新版本内核下接近 XFS）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

写时复制快照（Copy-on-Write，COW）：
  写入新数据前，先把旧数据复制到快照空间
  → 快照创建瞬间完成，几乎零空间
  → 写入时性能损失（需要先复制）
  → Btrfs、ZFS 采用

写时重定向快照（Redirect-on-Write，ROW）：
  新数据写入新位置，不动旧数据
  → 写入性能好
  → 删除旧数据时性能差
  → LVM 旧版本采用

引用快照（Reference）：
  不实际复制数据，只记录指针
  → 实际是 COW 的一种

1
2
3
4

时间 T1：文件 A 的数据在块 100，inode 指向 100
         ↓ 用户修改文件 A
时间 T2：读取块 100 → 在内存中修改 → 写回块 100（原地覆盖）
         没有任何副本，如果电源中断 → 数据丢失

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

时间 T1：文件 A 的数据在块 100，inode 指向 100
         ↓ 用户修改文件 A
时间 T2：
  1. 找到空闲块 200
  2. 把块 100 的内容复制到块 200
  3. 在块 200 上修改数据
  4. 把 inode 指向 200
  5. 旧块 100 暂时保留（成为快照的"资源"）

结果：旧版数据（块 100）被保留，新版数据（块 200）生效
     任何意外的崩溃都不会破坏旧数据

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

传统块映射（ext4）：
  文件 offset 0-4095 → 块 100
  文件 offset 4096-8191 → 块 101
  文件 offset 8192-12287 → 块 102
  ...
  每 4KB 都要一个映射项 → 大文件元数据巨大

Btrfs Extent 映射：
  文件 offset 0-1048575 → 块 100-355（连续 256 个块）
  一个 extent 描述一整段连续空间
  → 大文件元数据极小

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Btrfs 的 B-tree 树形结构：

           根节点
          /      \
        内部节点  内部节点
        /     \
     叶子1    叶子2
   (extent) (extent)
   (inode)  (inode)
   (目录)    (目录)

1
2
3

# 短短几秒完成
btrfs subvolume snapshot /mnt/data /mnt/data/snap1
# Create a snapshot of '/mnt/data' in '/mnt/data/snap1'

1
2
3
4
5
6
7
8
9

快照创建前：
  子卷 data 的 Root B-tree 根节点是 ROOT_1
  data 的所有数据通过 ROOT_1 索引

快照创建后：
  snap1 有自己的根 ROOT_2（顶层 B-tree 节点）
  但 ROOT_2 和 ROOT_1 指向完全相同的 extent 节点
  → 没有复制任何数据！
  → 创建一个根 B-tree 节点的时间：< 1 秒

1
2
3
4

  Root_Tree
    ├── RO Subvol data → ROOT_1 ──┐
    │                              │ 共享 extent
    └── RO Subvol snap1 → ROOT_2 ─┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

假设根 B-tree 节点 ROOT_1 要被修改：

传统 COW（每次写都复制）：
  🔄 必须从叶子节点开始，逐层复制整个路径
  → 大文件写入性能差

Btrfs 优化（lazy COW / nodatacow 模式）：
  对于 data extent，可以选择：
  1. 默认 COW（写入安全但开销）
  2. nodatacow（必须用某些工具如 dd 创建大文件）
  3. 某些场景下可以配置 partial COW

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

修改前：
  ROOT_1 → 共享 extent → Block 100（snap1 仍可见）

修改过程（COW）：
  1. 分配新的 Block 200
  2. 把 Block 100 的内容复制到 Block 200
  3. 在 Block 200 上修改数据
  4. 把 ROOT_1 指向 Block 200
  5. Block 100 仍然保留（快照仍可访问）

修改后：
  ROOT_1 → Block 200（新版）
  ROOT_2 → Block 100（旧版，快照访问）

1
2
3
4
5
6

原始子卷得到：所有写操作都"复制 + 改 + 指向新块"
快照保留：旧版的数据（extent 100）被保留，新版不影响快照

共享程度：
  没有变化的 extent：原始 + 快照共享（零空间）
  被修改的 extent：复制了一份（少量空间）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

情景一：刚创建快照，数据完全没变
  快照空间占用：0（只增加一个根 B-tree 节点）

情景二：修改了文件 A 的第 1 个块
  快照空间占用：1 个块（4KB-8KB）

情景三：删除了文件 B
  原始子卷释放 B 的 extent
  快照保留 B 的 extent（防止快照损坏）
  → 快照占用：B 原本的大小

这是 Btrfs 快照的"陷阱"：
  原始子卷删除文件，快照中仍保留
  → 必须通过 btrfs subvolume delete 删除快照，
    或 send/receive 收回空间

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# 1. 创建子卷（被快照的对象）
btrfs subvolume create /mnt/data/projects

# 2. 创建快照（升级前先打快照）
btrfs subvolume snapshot /mnt/data/projects /mnt/data/projects-snap-20260725

# 3. 升级系统
apt upgrade -y  # 或 yum update

# 4. 升级失败，回滚
# 步骤：
#   4.1 删除当前子卷
btrfs subvolume delete /mnt/data/projects
#   4.2 还原快照
btrfs subvolume snapshot /mnt/data/projects-snap-20260725 /mnt/data/projects

# 5. 删除旧快照（释放空间）
btrfs subvolume delete /mnt/data/projects-snap-20260725

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

快照（Snapshot）：
  - 在同一文件系统内
  - 几乎零成本
  - 不防文件系统损坏（损坏会一起损坏）
  - 适合快速回滚、临时备份
  - 不能替代真正的备份

备份（Backup）：
  - 在另一个文件系统或设备上
  - 占用等量的空间
  - 防文件系统损坏、物理故障
  - 需要定期执行
  - btrfs send/receive 可以做增量备份

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 第一次：完整快照发送到远程
btrfs send /mnt/data/projects-snap-20260725 | \
  ssh user@backup-server "btrfs receive /mnt/backup/"

# 第二次：只发送增量差异
btrfs send -p /mnt/data/projects-snap-20260725 \
           -c /mnt/data/projects-snap-20260726 | \
  ssh user@backup-server "btrfs receive /mnt/backup/"

# 第二次只传输第 26 日相比第 25 日的差异数据
# → 首次 100GB，增量可能只有 100MB

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 把 3 块盘做成 Btrfs RAID1（每份数据存 2 份）
mkfs.btrfs -L mydata -m raid1 -d raid1 /dev/sdb /dev/sdc /dev/sdd

# 在线添加设备
btrfs device add /dev/sde /mnt/data

# 平衡数据分布到所有设备
btrfs balance start /mnt/data

# 替换故障设备
btrfs device replace /dev/sdb /dev/sdf /mnt/data

# 移除设备
btrfs device delete /dev/sdb /mnt/data

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 挂载时启用 zstd 压缩（推荐）
mount -o compress=zstd /dev/sdb1 /mnt/data

# 重新挂载启用压缩
mount -o remount,compress=zstd /mnt/data

# 性能与压缩比：
# zstd:  压缩率好，CPU 开销低（推荐日常）
# lzo:   压缩率低，速度最快
# zlib:  压缩率好，CPU 开销高

1
2
3
4
5
6
7
8

# 手动启动 scrub（检查所有数据完整性）
btrfs scrub start /mnt/data

# 查看 scrub 状态
btrfs scrub status /mnt/data

# 添加到 crontab 每周自动 scrub
0 3 * * 0 /sbin/btrfs scrub start /mnt/data

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

你的系统是什么？
  ├─ Windows → NTFS（唯一选择）
  └─ Linux
      │
      ├─ 你的应用是数据库（MySQL/PostgreSQL）？
      │   ├─ 是 → XFS 或 ext4（生产 OLTP 仍以稳定为先）
      │   └─ 否 → 继续
      │
      ├─ 你需要快照、压缩、校验、增量备份？
      │   ├─ 是 → Btrfs
      │   └─ 否 → 继续
      │
      ├─ 你的磁盘很大（> 10TB）？
      │   ├─ 是，多文件大文件为主 → XFS
      │   └─ 否，小文件为主 → ext4 或 Btrfs
      │
      └─ 你需要兼容性、不折腾？
          └─ ext4（最稳）