Linux 文件系统原理与常见文件系统对比
一、什么是文件系统？
计算机中的磁盘本质上只提供：
Block（块）级别的数据存储能力。
例如一块 SSD：
Block 0
Block 1
Block 2
Block 3
...
Block N
磁盘本身并不知道：
什么是文件
什么是目录
什么是文件名
什么是权限
什么是 /etc/passwd
什么是 /home/user
这些概念主要由：
File System（文件系统）
组织和管理。
因此可以简单理解：
文件系统是一套规定“数据如何在存储设备上组织、命名、定位、读取、修改和管理”的数据结构与规则。
二、文件系统解决什么问题？
假设磁盘有：
1 TB
如果没有文件系统，操作系统面对的基本只是：
Block 0
Block 1
Block 2
...
现在创建：
/home/user/test.txt
文件系统必须解决：
test.txt 在哪里？
它属于哪个目录？
它多大？
属于哪个 UID？
属于哪个 GID？
权限是什么？
什么时候创建？
什么时候修改？
数据存在哪些 Block？
哪些 Block 已使用？
哪些 Block 还是空闲的？
如果突然断电怎么办？
因此文件系统至少要管理两大类东西：
Metadata
+
File Data
即：
元数据
+
真正的数据
三、Metadata 是什么？
Metadata：
元数据
可以理解为：
描述数据的数据。
例如文件：
hello.txt
真正内容可能是：
Hello Linux
这是：
File Data
而：
文件大小
UID
GID
权限
时间戳
数据块位置
文件类型
扩展属性
属于：
Metadata
所以：
File
├── Metadata
└── Data
四、Linux 文件系统的整体结构
Linux 中应用程序不会直接操作 ext4、XFS、Btrfs 的磁盘结构。
中间存在一个非常重要的抽象层：
VFS
即：
Virtual File System
可以理解：
Application
│
│ open/read/write
▼
System Call
│
▼
VFS
│
├── ext4
├── XFS
├── Btrfs
├── tmpfs
├── NFS
└── ...
│
▼
Block Layer
│
▼
Device Driver
│
▼
SSD / HDD / NVMe
因此应用程序调用：
open()
read()
write()
close()
时，不需要知道底层到底是：
ext4
XFS
Btrfs
NFS
tmpfs
VFS 为它们提供统一接口。
五、VFS 的核心对象
理解 Linux 文件系统，建议掌握几个非常重要的概念：
Superblock
Inode
Dentry
File
可以建立：
File System
│
├── Superblock
│
├── Inode
│
├── Dentry
│
└── File
六、Superblock
Superblock：
超级块
描述整个文件系统的总体信息。
例如：
文件系统类型
Block Size
文件系统大小
状态
挂载信息
特性标志
文件系统 UUID
内部管理结构位置
可以理解：
Superblock
=
整个文件系统的“总说明书”
例如：
ext4 filesystem
Superblock
├── Block Size = 4096
├── UUID = ...
├── Feature Flags
├── Block Count
└── ...
七、Inode
Inode：
Index Node
是 Unix/Linux 文件系统中非常核心的概念。
一个 inode 描述一个文件对象的主要元数据。
例如：
inode
├── File Type
├── Permission
├── UID
├── GID
├── Size
├── Timestamp
├── Link Count
├── Extended Attributes
└── Data Location Information
但有一个特别重要的知识：
传统 Unix/Linux inode 本身通常不保存普通文件名。
文件名主要存在于：
Directory Entry
中。
八、文件名与 inode
例如：
/home/user/hello.txt
目录中可以概念化保存：
hello.txt
↓
inode 12345
然后：
inode 12345
↓
Metadata
↓
Data Blocks / Extents
所以：
File Name
↓
Directory Entry
↓
Inode
↓
Data
这是理解 Linux 文件系统非常重要的一条链。
九、Dentry
Dentry：
Directory Entry
VFS 中的 dentry 用于表示：
目录项 / 路径组件与文件对象之间的关系
例如路径：
/home/user/test.txt
可以拆成：
/
↓
home
↓
user
↓
test.txt
Linux 在解析路径时，需要逐级查找这些路径组件。
因此：
Path
↓
Dentry
↓
Inode
Linux 还会维护：
Dentry Cache
提高路径查找效率。
十、目录本质是什么？
初学者经常认为：
目录就是“装文件的盒子”。
从 Unix 文件系统角度，更准确地说：
目录本身也是一种特殊文件。
它保存目录项，用于建立：
File Name
↓
Inode
之间的映射关系。
例如：
Directory /home/user
.
..
hello.txt → inode 100
test.c → inode 101
a.out → inode 102
十一、Linux 中“文件”是一个非常广泛的概念
Unix 有一个著名设计思想：
Everything is a file.
虽然不能机械地把所有内核对象都理解成普通磁盘文件，但 Linux 确实通过文件描述符统一操作很多对象。
例如：
Regular File
Directory
Device
Pipe
Socket
Terminal
procfs object
sysfs object
很多都可以通过：
FD
进行访问。
这就和前面的“进程”章节连接起来了：
Process
↓
FD Table
↓
struct file
↓
VFS
↓
Filesystem / Kernel Object
十二、从 open() 到文件系统发生了什么？
例如：
int fd = open("/home/user/test.txt", O_RDONLY);
可以概念化理解：
Application
↓
open()
↓
System Call
↓
VFS
↓
解析路径 /
↓
home
↓
user
↓
test.txt
↓
找到 Dentry
↓
找到 Inode
↓
检查权限
↓
建立 Open File State
↓
分配 File Descriptor
↓
返回 fd
例如：
fd = 3
于是：
Process
FD Table
├── 0 → stdin
├── 1 → stdout
├── 2 → stderr
└── 3 → test.txt
十三、read() 的工作过程
执行：
read(fd, buf, 4096);
可以简化：
Process
↓
FD
↓
Open File
↓
VFS
↓
Filesystem
↓
Page Cache
↓
数据存在？
┌────┴────┐
YES NO
│ │
│ ▼
│ Block I/O
│ ↓
│ SSD/HDD
│ ↓
│ Page Cache
│ │
└──────────┘
↓
复制给用户空间
↓
Application Buffer
因此：
read()并不意味着每次都真正访问物理磁盘。
如果数据已经存在：
Page Cache
中，就可以直接从内存获得。
十四、write() 的工作过程
例如：
write(fd, buf, 4096);
很多情况下不是：
Application
↓
立刻写 SSD
而更接近：
Application
↓
write()
↓
Kernel
↓
Page Cache
↓
Dirty Page
↓
稍后 Writeback
↓
Filesystem
↓
Block Layer
↓
SSD / HDD
因此：
write() 返回成功
并不在所有情况下都等价于：
数据已经永久落盘。
十五、fsync()
如果应用程序需要要求内核将相关修改同步到持久存储，需要考虑：
fsync(fd);
例如数据库：
Transaction
↓
write()
↓
fsync()
↓
确认关键数据持久化
当然实际持久性还会受到：
文件系统
设备写缓存
SSD Firmware
硬件
挂载参数
等因素影响。
十六、Mount：挂载
Linux 没有：
C:
D:
E:
这样的盘符模型。
Linux 使用：
单一目录树。
例如：
/
├── boot
├── etc
├── home
├── usr
├── var
└── mnt
不同文件系统通过：
mount
加入这棵目录树。
例如：
mount /dev/sdb1 /data
表示：
/dev/sdb1
中的文件系统
↓
挂载到
↓
/data
于是：
/data/file.txt
实际数据可能位于：
/dev/sdb1
十七、磁盘、分区和文件系统不是同一个概念
例如：
NVMe SSD
/dev/nvme0n1
这是：
Block Device
可以建立：
GPT Partition Table
然后：
/dev/nvme0n1p1
/dev/nvme0n1p2
/dev/nvme0n1p3
再格式化：
p1 → FAT32 / ESP
p2 → ext4
p3 → XFS
所以：
Disk
↓
Partition Table
↓
Partition
↓
Filesystem
↓
Mount Point
↓
Directory Tree
这些概念一定要分开。
十八、Block 与 Extent
传统文件系统可以把文件的数据位置理解成：
Block
例如一个文件：
File A
占用：
Block 100
Block 101
Block 102
Block 103
如果每个 Block 都单独记录，管理大型文件会很麻烦。
现代文件系统经常大量使用：
Extent
即：
一段连续的数据块范围。
例如：
Start Block = 100
Length = 1000 Blocks
就可以描述：
Block 100
~
Block 1099
这比记录 1000 个独立 Block 更高效。
ext4、XFS 等都大量使用 Extent。
十九、什么是碎片？
如果文件数据原本：
100 101 102 103 104
连续存储，顺序读取非常方便。
但随着不断：
Create
Delete
Extend
Rewrite
可能变成：
100
↓
500
↓
901
↓
1300
这叫：
Fragmentation（碎片化）
现代文件系统会通过：
Extent
Delayed Allocation
Allocation Groups
Copy-on-Write 策略
Defragmentation
等机制控制或处理碎片。
二十、Crash Consistency：突然断电怎么办？
假设创建：
hello.txt
可能需要修改：
Directory Entry
Inode
Free Space Metadata
Data Block
如果：
修改到一半
↓
突然断电
可能导致文件系统元数据不一致。
因此现代文件系统必须考虑：
Crash Consistency
二十一、Journaling：日志文件系统
ext3、ext4、XFS 都是典型的：
Journaling File System
基本思想：
准备修改文件系统
↓
先记录 Journal / Transaction
↓
执行实际修改
↓
Commit
发生断电：
Reboot
↓
读取 Journal
↓
恢复到一致状态
因此 Journal 的主要目的不是：
“备份用户文件。”
而是：
提高文件系统在崩溃后的元数据/事务一致性恢复能力。
二十二、Journaling 与 Copy-on-Write
现代文件系统大致存在两种很重要的设计思路：
Journaling
和：
Copy-on-Write
传统 Journaling 思路：
记录即将发生的修改
↓
Journal
↓
更新原来的文件系统位置
Copy-on-Write：
不直接覆盖旧数据
↓
写到新的位置
↓
更新引用
↓
旧版本暂时仍然存在
例如：
Old Block
│
│ 修改
▼
New Block
↓
更新 Metadata Pointer
ZFS、Btrfs、APFS 都大量采用：
Copy-on-Write（CoW）
设计。
二十三、为什么 CoW 很适合 Snapshot？
假设原始文件：
A → Block 100
B → Block 200
C → Block 300
创建 Snapshot：
Snapshot
不需要立刻复制全部数据。
可以：
Live FS Snapshot
A ─────────┐
├→ Block 100
B ─────────┼→ Block 200
C ─────────┘→ Block 300
修改 A 时：
Live A
↓
New Block 500
Snapshot 继续引用：
Old Block 100
所以：
Snapshot
可以非常快速。
二十四、文件系统完整工作过程
把前面知识串起来：
Application
↓
open("/data/test")
↓
System Call
↓
VFS
↓
Path Lookup
↓
Dentry
↓
Inode
↓
Filesystem
↓
ext4 / XFS / Btrfs / ...
↓
Page Cache
↓
Block Layer
↓
Device Driver
↓
NVMe / SSD / HDD
读取：
read()
↓
FD
↓
VFS
↓
Page Cache
↓
Filesystem
↓
Storage
写入：
write()
↓
Page Cache
↓
Dirty Pages
↓
Filesystem
↓
Journal / CoW Transaction
↓
Block Layer
↓
Storage
二十五、ext2 → ext3 → ext4
Linux 中非常经典的一条发展路线：
ext2
↓
ext3
↓
ext4
其中：
ext2
→ 没有 Journaling
ext3
→ 在 ext2 基础上引入 Journaling
ext4
→ 大幅改进扩展性、性能和数据结构
二十六、ext3
ext3：
Third Extended Filesystem
是 Linux 历史上非常重要的 Journaling 文件系统。
核心特点：
ext2 架构基础
+
Journal
可以概念化：
ext3
│
├── Superblock
├── Block Groups
│
├── Inode Bitmap
├── Block Bitmap
├── Inode Table
├── Data Blocks
│
└── Journal
二十七、ext3 的 Block Group
ext 系列并不是把整个磁盘所有 metadata 全部堆在一起。
而是划分：
Block Group 0
Block Group 1
Block Group 2
...
一个 Block Group 可以概念化：
Block Group
│
├── Superblock Backup / Metadata
├── Block Bitmap
├── Inode Bitmap
├── Inode Table
└── Data Blocks
这样可以：
提高局部性
降低管理巨大磁盘的复杂度
提供一定冗余
二十八、ext3 工作原理
例如修改文件：
test.txt
ext3 会根据 journaling 模式处理相关事务。
基本思想：
Application
↓
write()
↓
Page Cache
↓
ext3
↓
Journal Transaction
↓
更新 Filesystem
↓
Commit
发生崩溃：
Boot
↓
检查 Journal
↓
Replay
↓
恢复文件系统一致性
二十九、ext3 的优缺点
优点：
成熟
稳定
历史兼容性好
结构简单
比 ext2 有更好的崩溃恢复能力
缺点：
设计年代较早
扩展能力有限
大文件/大文件系统能力落后于现代文件系统
传统 block mapping 效率有限
性能和并发扩展性不如 ext4/XFS
缺少现代 CoW/Snapshot/Checksum 等高级能力
因此今天新部署 Linux 系统通常不会优先选择 ext3。
三十、ext4
ext4：
Fourth Extended Filesystem
可以理解成：
ext 系列传统设计的现代化版本。
它仍然属于：
Journaling Filesystem
但相比 ext3 有大量改进。
三十一、ext4 的核心结构
概念上：
ext4
│
├── Superblock
│
├── Block Groups
│ ├── Block Bitmap
│ ├── Inode Bitmap
│ ├── Inode Table
│ └── Data Blocks
│
├── Extents
│
├── Directory Index
│
└── Journal
ext4 仍然保留：
inode
block group
journal
等 ext 家族核心思想。
三十二、ext4 的 Extent
ext4 相比传统 ext3 一个非常重要的变化是：
Extent
例如一个 400 MiB 文件的数据连续存在：
Block 10000
~
Block 112399
不需要记录：
10000
10001
10002
10003
...
而可以记录类似：
Start = 10000
Length = N
大幅降低大型文件的映射开销。
三十三、ext4 Delayed Allocation
ext4 还大量使用：
Delayed Allocation
即：
Application write()
↓
Page Cache
↓
暂时不立即决定最终磁盘 Block
↓
等待更多数据
↓
一次性选择更连续的空间
好处：
减少碎片
提高顺序写性能
更合理地分配 Extent
三十四、ext4 Journal
ext4 默认仍使用 Journal 保证重要文件系统状态的一致性。
可以概念化：
Transaction
↓
Journal
↓
Commit
↓
Filesystem Metadata
ext4 支持不同的数据日志策略。
常见默认模式：
data=ordered
主要目标是在性能和一致性之间取得平衡。
三十五、ext4 的特点
ext4 的优势：
成熟
稳定
兼容性广
维护工具成熟
性能均衡
恢复工具成熟
Linux 支持非常普遍
所以：
ext4 是通用 Linux 系统非常常见的默认选择之一。
它并不追求所有高级功能，而强调：
稳定
简单
成熟
通用
三十六、XFS
XFS 最早由：
Silicon Graphics（SGI）
开发，后来成为 Linux 中非常重要的高性能文件系统。
XFS 的设计目标非常强调：
大文件
大文件系统
高吞吐
并行 I/O
可扩展性
它同样属于：
Journaling Filesystem
三十七、XFS 的核心思想：Allocation Group
XFS 会把文件系统划分成多个：
Allocation Group（AG）
概念上：
XFS
│
├── AG 0
│
├── AG 1
│
├── AG 2
│
├── AG 3
│
└── ...
每个 AG 可以相对独立地管理：
Free Space
Inode
Allocation Metadata
这样多个 CPU/线程同时操作文件系统时：
CPU 0 → AG 0
CPU 1 → AG 1
CPU 2 → AG 2
CPU 3 → AG 3
可以降低全局锁竞争。
这也是 XFS：
高并发扩展性
的重要来源之一。
三十八、XFS 使用 B+Tree
XFS 大量使用：
B+Tree
管理：
Free Space
Extents
Inodes
Directories
Reverse Mapping
...
原因是 B+Tree 很适合：
大量数据
有序查找
范围查询
动态插入删除
磁盘结构管理
因此 XFS 从设计上非常强调：
Scalability
三十九、XFS 的 Extent
XFS 同样大量使用：
Extent
管理文件数据。
例如：
File
↓
Extent Tree
↓
Extent 1
Extent 2
Extent 3
因此非常适合：
大型文件
视频
数据库文件
日志
大型服务器工作负载
四十、XFS Journal
XFS 使用 Journal 主要保护：
Metadata
可以概念化：
Metadata Change
↓
Log / Journal
↓
Commit
↓
更新主文件系统结构
系统崩溃：
Mount
↓
Replay Log
↓
恢复一致状态
四十一、XFS 的特点
优势：
大型文件性能优秀
大型文件系统扩展性强
高并发
成熟
在线扩容能力成熟
企业 Linux 使用广泛
需要注意：
XFS 擅长 grow
但传统管理方式中：
不能像某些文件系统那样简单在线 shrink
因此容量规划时需要注意。
四十二、ext4 与 XFS 的核心区别
可以简单理解：
ext4
→ 通用、成熟、简单、均衡
XFS
→ 大规模、高吞吐、高并发
但这不是说：
小文件只能 ext4
大文件只能 XFS
实际性能高度依赖：
Kernel Version
Storage Device
Mount Options
Workload
File Size
Concurrency
Database/Application
四十三、从传统文件系统进入 CoW 文件系统
ext4/XFS 主要属于：
Journaling Filesystem
而接下来：
ZFS
Btrfs
APFS
具有非常重要的共同设计思想：
Copy-on-Write
即：
旧数据
↓
不直接覆盖
修改
↓
写新位置
↓
更新 Metadata
这会带来：
Snapshot
Clone
Checksum
Atomic Update
等现代能力。
四十四、ZFS
ZFS 最初由 Sun Microsystems 为 Solaris 开发。
ZFS 的设计非常特殊：
它不仅仅想做传统意义上的文件系统，还把存储池管理和文件系统深度结合。
传统 Linux 存储栈经常是：
Disk
↓
Partition
↓
RAID
↓
LVM
↓
Filesystem
而 ZFS 的思路更接近：
Physical Disks
↓
VDEV
↓
ZFS Storage Pool
↓
Dataset / Zvol
四十五、ZFS Storage Pool
ZFS 使用：
zpool
管理存储池。
例如：
Disk 1 ─┐
Disk 2 ─┼→ VDEV → ZPOOL
Disk 3 ─┘
然后在池中建立：
Dataset
例如：
tank
├── home
├── database
├── backup
└── vm
每个 Dataset 可以拥有自己的：
Compression
Quota
Snapshot
Record Size
Mount Point
等属性。
四十六、ZFS 的 CoW
假设：
Block A
需要修改。
ZFS 不直接：
Overwrite Block A
而是：
Block A
↓
保留
修改后的数据
↓
Block B
↓
更新上层 Metadata
这种机制不断向上更新，最终形成新的完整一致状态。
四十七、ZFS 的 Merkle Tree 思想
ZFS 数据结构中一个极其重要的特点是：
数据和元数据校验。
可以概念化：
Root
│ checksum
▼
Metadata Block
│ checksum
▼
Data Block
上层结构保存下层块的：
Checksum
所以读取：
Data
↓
Calculate Checksum
↓
Compare
如果不一致：
Data Corruption
就可以发现。
四十八、ZFS Self-Healing
如果 ZFS 底层拥有冗余：
Mirror
RAID-Z
发现：
Block A
Checksum Error
就可能：
读取另一个正确副本
↓
验证 Checksum
↓
获得正确数据
↓
修复损坏副本
这就是：
Self-Healing
的重要思想。
注意：
Checksum 能发现错误，但要自动修复通常还需要可用的冗余副本。
四十九、ZFS RAID-Z
ZFS 自己提供类似 RAID 的能力：
Mirror
RAID-Z1
RAID-Z2
RAID-Z3
大致可以理解：
RAID-Z1
→ 可容忍一个相应设备故障
RAID-Z2
→ 可容忍两个
RAID-Z3
→ 可容忍三个
因此 ZFS 不只是：
Filesystem
而更像：
Filesystem
+
Volume / Pool Management
+
RAID
+
Checksum
+
Snapshot
+
Compression
的一整套存储系统。
五十、ZFS ARC
ZFS 有自己的重要缓存体系：
ARC
即：
Adaptive Replacement Cache
主要使用 RAM 缓存文件系统数据。
还可以使用：
L2ARC
作为二级读取缓存。
此外还有与同步写相关的：
ZIL
SLOG
等概念。
因此 ZFS 的性能调优体系比 ext4 更复杂。
五十一、ZFS Snapshot
因为 CoW：
Snapshot
创建速度通常很快。
例如：
Current Dataset
│
├── Snapshot 1
│
├── Snapshot 2
│
└── Snapshot 3
Snapshot 最初不需要复制所有数据。
只有后续修改发生后，新旧版本逐渐引用不同 Block。
五十二、ZFS 的特点
优势：
端到端数据完整性设计
Checksum
Snapshot
Clone
Compression
Storage Pool
RAID-Z
Scrub
Self-Healing（有冗余时）
强大的存储管理能力
代价：
体系复杂
管理理念不同于传统 ext4
内存使用策略更积极
部署和调优需要更多知识
五十三、Btrfs
Btrfs：
B-tree File System
是 Linux 原生的现代 CoW 文件系统之一。
设计目标包括：
Copy-on-Write
Snapshot
Checksum
Subvolume
Compression
Multi-device
RAID
Online Management
可以把它理解为：
Linux 世界中试图将现代文件系统和卷管理功能结合起来的一套设计。
五十四、Btrfs 为什么叫 B-tree？
因为 Btrfs 大量使用：
B-tree
组织内部 metadata。
例如：
Btrfs
│
├── Root Tree
├── Extent Tree
├── Chunk Tree
├── Device Tree
├── Checksum Tree
└── File System Tree
这些树共同描述：
文件
目录
Extent
设备
Checksum
空间分配
等信息。
五十五、Btrfs 的 CoW
修改：
Old Extent
时：
Old Extent
↓
保持不变
New Data
↓
New Extent
↓
更新 B-tree
因此天然适合：
Snapshot
Clone
Reflink
五十六、Btrfs Subvolume
Btrfs 一个非常重要的概念：
Subvolume
它看起来类似目录，但不是普通目录。
例如：
Btrfs Filesystem
│
├── @
├── @home
├── @snapshots
└── @var
不同 Subvolume 可以独立：
Snapshot
Mount
管理
这也是很多 Linux 发行版使用 Btrfs 时的重要设计。
五十七、Btrfs Snapshot
例如：
@root
创建：
@snapshot1
由于 CoW：
Root
├── Current
└── Snapshot
│
└── 初始共享大量 Extents
修改 Current 后：
Current
→ New Extent
Snapshot
→ Old Extent
所以 Snapshot 可以非常高效。
五十八、Btrfs Checksum
Btrfs 可以为：
Data
Metadata
维护 checksum。
读取时：
Read Block
↓
Calculate Checksum
↓
Compare
↓
Correct?
如果底层具有可用冗余副本，还可以在一定条件下：
读取正确副本
↓
修复错误数据
五十九、Btrfs Compression
Btrfs 原生支持透明压缩，例如常见：
zstd
概念：
Application
↓
Write Data
↓
Btrfs Compression
↓
Compressed Extent
↓
SSD
读取：
SSD
↓
Compressed Data
↓
Decompress
↓
Application
对于：
源码
文本
日志
虚拟机之外的一些普通数据
可能节省空间，并在某些场景降低实际 I/O。
六十、Btrfs 的特点
优势：
Linux Kernel 原生支持
CoW
Snapshot
Subvolume
Checksum
Compression
Reflink
多设备管理
在线管理能力丰富
需要注意：
功能复杂
CoW 对某些随机写工作负载需要调优
数据库/VM 镜像等场景需要理解 CoW 行为
不同 RAID Profile 的成熟度和限制需要具体确认
所以不能简单说：
“Btrfs 一定比 ext4 快。”
它的主要价值更多来自：
现代存储管理能力。
六十一、APFS
APFS：
Apple File System
是 Apple 为其生态设计的现代文件系统。
主要用于：
macOS
iOS
iPadOS
watchOS
tvOS
APFS 针对：
SSD / Flash Storage
Encryption
Snapshot
Clone
Space Sharing
等现代需求设计。
六十二、APFS Container
APFS 的重要概念之一：
Container
一个 APFS Container 中可以包含多个：
Volume
例如：
Physical Storage
↓
APFS Container
│
├── Volume A
├── Volume B
├── Volume C
└── Volume D
这些 Volume 可以：
Space Sharing
即共享 Container 的可用空间。
六十三、APFS Space Sharing
传统固定分区：
Partition A = 100 GB
Partition B = 100 GB
A 用不完：
50 GB
B 也不能随意使用。
APFS Container 中：
Container = 200 GB
Volume A
Volume B
两个 Volume 可以根据实际使用情况动态共享 Container 空间。
因此：
APFS Container
↓
Shared Free Space
↓
Multiple Volumes
六十四、APFS Copy-on-Write
APFS 同样大量使用：
Copy-on-Write
特别是 Metadata 更新。
修改时：
Old Metadata
↓
保留
New Metadata
↓
写入新位置
↓
切换引用
从而提高：
Crash Consistency
Snapshot
Clone
等能力。
六十五、APFS Clone
例如：
File A
复制成：
File B
APFS 可以使用：
Clone
初始：
File A ───┐
├→ Shared Blocks
File B ───┘
不需要马上复制全部数据。
如果 B 修改：
File B
↓
New Blocks
而 A：
File A
↓
Old Blocks
这和 CoW 思想紧密相关。
六十六、APFS Snapshot
APFS 同样支持：
Snapshot
例如 macOS 系统更新、备份和恢复机制可以利用文件系统快照能力。
其基本思想仍然是：
Snapshot
↓
引用某一时刻的文件系统状态
↓
后续修改使用 CoW
六十七、APFS Encryption
APFS 从设计上非常重视：
Encryption
尤其与 Apple 的：
Secure Enclave
FileVault
设备安全体系
结合。
因此 APFS 很明显是一套：
针对 Apple 硬件、Flash 存储和 Apple OS 生态深度优化的现代文件系统。
六十八、六种文件系统的架构分类
首先不要急着比较谁“最好”。
应该先按照设计哲学分类：
传统 Journaling Filesystem
ext3
ext4
XFS
Modern Copy-on-Write Filesystem
ZFS
Btrfs
APFS
进一步：
ext3
→ 经典 Linux Journaling
ext4
→ 通用 Linux Journaling
XFS
→ 高扩展性 Journaling
ZFS
→ CoW + Storage Pool + Data Integrity
Btrfs
→ Linux Native CoW + Subvolume
APFS
→ Apple Native CoW + Flash/Encryption
六十九、ext3 vs ext4 vs XFS vs ZFS vs Btrfs vs APFS
| 特性 | ext3 | ext4 | XFS | ZFS | Btrfs | APFS |
|---|---|---|---|---|---|---|
| 核心年代 | 较老 | 成熟现代 | 成熟现代 | 现代存储体系 | 现代 Linux | 现代 Apple |
| Linux 原生常用 | 是 | 是 | 是 | 生态方式不同 | 是 | 否 |
| Journaling | 是 | 是 | 是 | 非传统核心模式 | 非传统核心模式 | CoW 事务设计 |
| Copy-on-Write | 否 | 否 | 非核心设计 | 是 | 是 | 是 |
| Extent | 能力较传统 | 是 | 是 | 自有块结构 | Extent | 自有结构 |
| Snapshot | 原生无 | 原生无 | 原生无通用快照体系 | 是 | 是 | 是 |
| Checksum | 能力有限 | 主要不是端到端数据校验体系 | 主要不是 ZFS 式数据校验体系 | 数据+元数据 | 数据+元数据 | 内部完整性机制 |
| Compression | 原生无透明通用压缩 | 原生无 | 原生无通用透明压缩 | 是 | 是 | 系统层有相关能力 |
| Subvolume/Dataset | 否 | 否 | 否 | Dataset | Subvolume | Volume |
| 多设备管理 | 依赖 RAID/LVM | 依赖 RAID/LVM | 依赖 RAID/LVM | 原生 Pool/VDEV | 原生支持 | Apple Container |
| RAID | 外部 | 外部 | 外部 | Mirror/RAID-Z | 多种 Profile | 不是其主要定位 |
| 在线扩容 | 有限制 | 是 | 强 | Pool 模型 | 是 | Container 管理 |
| 在线缩容 | 有限/离线工具 | 可离线缩容 | 通常不支持缩小 | 取决于池设计 | 支持相关 resize | Apple 自动管理 |
| Clone/Reflink | 否 | 非核心 | 支持 Reflink | Clone | Reflink | Clone |
| 典型定位 | 老 Linux | 通用 Linux | 企业/大规模 Linux | NAS/存储服务器 | Linux 桌面/服务器 | Apple 设备 |
注意：
这张表用于理解“设计方向”，不能简单转换成性能排行榜。
七十、数据更新方式对比
ext3 / ext4 / XFS
核心思想更接近：
Old Metadata / Data
↓
Journal Transaction
↓
更新原位置
↓
Commit
主要依靠：
Journaling
保证 Crash Consistency。
ZFS / Btrfs / APFS
核心思想更接近：
Old Block
↓
保留
New Data
↓
New Block
↓
New Metadata
↓
Atomic Pointer / Root Update
主要大量利用：
Copy-on-Write
因此天然更容易实现：
Snapshot
Clone
Checksum Tree
Versioned State
七十一、ext4 工作过程
例如：
write("hello")
概念上：
Application
↓
write()
↓
Page Cache
↓
Dirty Page
↓
ext4
↓
Delayed Allocation
↓
Extent Allocation
↓
Journal Metadata Transaction
↓
Writeback
↓
Block Layer
↓
SSD
因此 ext4 的核心关键词：
Block Group
Inode
Extent
Delayed Allocation
Journal
七十二、XFS 工作过程
概念上：
Application
↓
write()
↓
Page Cache
↓
XFS
↓
Allocation Group
↓
B+Tree / Extent Allocation
↓
Metadata Log
↓
Writeback
↓
Storage
核心关键词：
Allocation Group
B+Tree
Extent
Journal / Log
Parallelism
Scalability
七十三、ZFS 工作过程
概念上：
Application
↓
write()
↓
ZFS
↓
Transaction Group
↓
CoW
↓
New Data Blocks
↓
Checksum
↓
New Metadata Blocks
↓
Update Tree
↓
Storage Pool
↓
VDEV
↓
Disk
核心关键词：
Storage Pool
VDEV
CoW
Checksum
Transaction Group
ARC
Snapshot
RAID-Z
Self-Healing
七十四、Btrfs 工作过程
概念上：
Application
↓
write()
↓
Page Cache
↓
Btrfs
↓
CoW
↓
New Extent
↓
Checksum
↓
Update B-tree
↓
Transaction Commit
↓
Storage
核心关键词：
B-tree
CoW
Extent
Checksum
Subvolume
Snapshot
Compression
Reflink
七十五、APFS 工作过程
概念上：
Application
↓
macOS VFS / Kernel
↓
APFS
↓
Container / Volume
↓
CoW Metadata
↓
Block Allocation
↓
Snapshot / Clone Structures
↓
Encryption Layer
↓
Apple Storage
核心关键词：
Container
Volume
Space Sharing
CoW
Snapshot
Clone
Encryption
SSD Optimization
七十六、如何选择文件系统？
不能简单问：
“哪个文件系统最好？”
应该问：
我的工作负载是什么？
需要 Snapshot 吗？
需要 Checksum 吗？
需要 RAID 吗？
是不是 NAS？
是不是数据库？
是不是 Linux RootFS？
是不是 Apple 系统？
文件是大量小文件还是大型文件？
是否需要透明压缩？
是否需要 Reflink？
是否需要在线扩容？
运维人员熟悉哪个文件系统？
七十七、普通 Linux 系统
如果目标只是：
Linux Desktop
普通 Server
Web Server
开发环境
Root Filesystem
通常首先会遇到：
ext4
XFS
Btrfs
三类选择。
其中设计思路分别可以记成：
ext4
→ 传统、成熟、均衡
XFS
→ 高扩展性、高吞吐
Btrfs
→ Snapshot、Compression、CoW、Subvolume
七十八、NAS / 数据存储服务器
如果核心目标变成：
大量磁盘
长期保存数据
数据完整性
Checksum
Snapshot
Compression
RAID
Scrub
那么：
ZFS
会成为非常重要的研究对象。
典型思想：
Disk
↓
VDEV
↓
Pool
↓
Dataset
↓
Snapshot / Compression / Checksum
七十九、Apple 系统
macOS/iPhone/iPad 等 Apple 生态：
APFS
是核心文件系统。
它和：
Apple Silicon
SSD
FileVault
Snapshot
System Volume
Container
Volume
等 Apple 系统设计紧密结合。
因此 APFS 不应该简单理解成：
“Apple 版本的 ext4。”
它们的设计时代和设计哲学差异很大。
八十、为什么 ext4 仍然大量存在？
看到 ZFS/Btrfs 拥有：
Snapshot
Checksum
Compression
CoW
以后，很容易产生一个问题：
为什么不全部换成 Btrfs/ZFS？
因为文件系统不是：
功能越多 = 一定越好
复杂功能意味着：
更多代码
更多状态
更多运维知识
不同性能特征
更多调优需求
而 ext4 最大的优势之一恰恰是：
成熟
稳定
简单
广泛
工具完善
行为容易理解
因此：
文件系统设计本质上是在可靠性、功能、性能、复杂度、兼容性之间做取舍。
八十一、为什么 XFS 在服务器中很常见？
XFS 从一开始就非常重视：
Scalability
Parallelism
Large Files
Large Filesystem
High Throughput
通过：
Allocation Groups
B+Trees
Extents
Delayed Allocation
等机制，让它非常适合大型服务器工作负载。
因此在很多企业 Linux 环境中，XFS 是重要选择。
八十二、为什么 CoW 文件系统会产生新的问题？
CoW 很强大：
Snapshot
Clone
Checksum
Crash Consistency
但是也有代价。
例如数据库不断：
随机覆盖
随机覆盖
随机覆盖
传统文件系统可能：
Overwrite
而 CoW：
Write New Block
↓
Update Metadata
↓
产生新的 Extent
长期下来可能出现：
Fragmentation
Write Amplification
Metadata Overhead
因此：
CoW 不是“无成本的高级功能”。
针对：
Database
VM Image
High Random Write
等工作负载，需要理解具体文件系统的优化方法。
八十三、Journal 与 Snapshot 不是一回事
这是非常容易混淆的地方。
Journal：
目的：
Crash Recovery
Filesystem Consistency
Snapshot：
目的：
保存某个时间点的文件系统状态
所以：
Journal
≠
Snapshot
≠
Backup
进一步：
Snapshot
通常也不能替代：
Backup
因为如果：
整块磁盘损坏
而 Snapshot 也在同一块磁盘上：
Snapshot 也可能一起消失
八十四、Checksum 与 RAID 也不是 Backup
同样：
Checksum
→ 检测数据损坏
RAID
→ 提高设备故障容忍能力
Snapshot
→ 保存历史状态
Backup
→ 独立的数据副本
四者解决的是不同问题。
可以记：
Checksum
解决：
“数据有没有悄悄损坏？”
RAID
解决：
“某块磁盘坏了怎么办？”
Snapshot
解决：
“我想回到之前状态怎么办？”
Backup
解决：
“整个存储系统没了怎么办？”
八十五、文件系统知识最终总图
整个 Linux 文件系统可以整理成：
Application
│
├── open()
├── read()
├── write()
├── mmap()
├── fsync()
└── close()
│
▼
System Call
│
▼
VFS
│
├── Superblock
├── Inode
├── Dentry
└── File
│
▼
Concrete Filesystem
│
├── ext3
├── ext4
├── XFS
├── Btrfs
└── ...
│
▼
Page Cache
│
▼
Filesystem Allocation
│
├── Block
└── Extent
│
▼
Block I/O Layer
│
▼
Device Driver
│
▼
Storage
│
├── HDD
├── SATA SSD
└── NVMe SSD
而不同文件系统的核心设计思想：
ext3
│
└── Classic Journaling
ext4
│
├── Journaling
├── Extent
└── Delayed Allocation
XFS
│
├── Allocation Group
├── B+Tree
├── Extent
└── Journaling
ZFS
│
├── Storage Pool
├── VDEV
├── CoW
├── Checksum
├── Snapshot
├── Compression
└── RAID-Z
Btrfs
│
├── B-tree
├── CoW
├── Checksum
├── Subvolume
├── Snapshot
├── Compression
└── Multi-device
APFS
│
├── Container
├── Volume
├── Space Sharing
├── CoW
├── Snapshot
├── Clone
└── Encryption
八十六、最终记忆模型
如果只记每种文件系统最核心的一句话：
ext3
=
ext2 + Journal
经典老牌 Linux 日志文件系统
ext4
=
Block Group + Inode + Extent + Journal
成熟、稳定、通用
XFS
=
Allocation Group + B+Tree + Extent + Journal
大型、高并发、高吞吐
ZFS
=
Storage Pool + CoW + Checksum + Snapshot + RAID-Z
强调数据完整性的完整存储体系
Btrfs
=
B-tree + CoW + Checksum + Subvolume + Snapshot
Linux 原生现代 CoW 文件系统
APFS
=
Container + Volume + CoW + Snapshot + Clone + Encryption
Apple 为 SSD 和自身生态设计的现代文件系统
八十七、一句话总结
文件系统的本质，是在块设备提供的原始存储空间之上建立一套数据和元数据组织规则，使操作系统能够用“目录、文件名、权限、inode、文件内容”等高级抽象管理数据。Linux 又通过 VFS 对不同文件系统提供统一的 open/read/write/mmap 接口。ext3、ext4 和 XFS 主要代表成熟的 Journaling 文件系统设计，其中 ext4 强调通用和稳定，XFS 强调大规模和并发扩展；ZFS、Btrfs 和 APFS 则大量采用 Copy-on-Write 思想，从而自然发展出 Snapshot、Clone、Checksum 等现代能力。ZFS进一步把存储池、RAID 和数据完整性整合进统一体系，Btrfs强调 Linux 原生的 Subvolume/Snapshot/Compression，APFS则围绕 Apple 的 SSD、加密和设备生态进行设计。
浙公网安备 33010602011771号