第一部分 · 速查表（先看这里）
T1 · 全文件系统总表
文件系统 | 阵营 | 最大单文件 | 最大卷 | 日志 | 校验和 | CoW | 快照 | 压缩 | 加密 | 跨平台 |
|---|
FAT12/16 | 远古/嵌入式 | 2 GB | 2–4 GB | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ⭐⭐⭐⭐⭐ |
FAT32 | 通用 | 4 GB−1B | 2 TB (Win创建限制) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ⭐⭐⭐⭐⭐ |
exFAT | 闪存/跨平台 | 16 EB | 128 PB | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ⭐⭐⭐⭐⭐ |
NTFS | Windows | 16 EB (实现 256TB) | 256 TB | ✅ 元数据 | ❌ | 部分 | ❌ (VSS) | ✅ | ✅ BitLocker | ⭐⭐ (macOS只读) |
ReFS | Windows Server | 35 PB | 1 YB | ✅ | ✅ 可选 | ✅ | ❌ | ❌ | ✅ | ⭐ |
HFS+ | 旧 macOS | 8 EB | 8 EB | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ⭐⭐ |
APFS | macOS/iOS | 8 EB | 8 EB | CoW 替代 | ✅ 元数据 | ✅ | ✅ | ✅ | ✅ 原生强 | ⭐ (仅 Apple) |
ext2 | Linux/嵌入式 | 2 TB | 32 TB | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ⭐ |
ext3 | Linux 旧 | 2 TB | 16 TB | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ⭐ |
ext4 | Linux 默认 | 16 TB | 1 EB | ✅ 3模式 | ❌ | ❌ | ❌ | ❌ | ❌ (需LUKS) | ⭐⭐ |
XFS | Linux 大文件 | 8 EB | 8 EB | ✅ 元数据 | ✅ 元数据CRC | ❌ | ❌ | ❌ | ❌ | ⭐⭐ |
Btrfs | Linux 现代 | 16 EB | 16 EB | CoW | ✅ 数据+元数据 | ✅ | ✅ | ✅ zstd | ❌ (fscrypt未落地) | ⭐⭐ |
ZFS | 跨平台存储 | 16 EB | 256 ZB | CoW | ✅ 端到端 | ✅ | ✅ | ✅ LZ4/zstd | ✅ 原生 | ⭐⭐ |
F2FS | 闪存/手机 | 3.94 TB | 16 TB | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ⭐ |
tmpfs | 内存 | 受内存限制 | 受内存限制 | 不适用 | 不适用 | ❌ | ❌ | ✅ zram | ❌ | Linux |
FAT32 的 4GB 天花板是最常见的坑：单文件超过 4GB 就写不进去，拷蓝光原盘、虚拟机镜像、系统镜像时必踩。
T2 · 场景选型速查
场景 | 首选 | 备选 | 关键理由 |
|---|
Windows 系统盘 / 内置盘 | NTFS | ReFS | 权限 ACL、日志、BitLocker 全支持 |
Windows Server / Hyper-V | ReFS | NTFS | 校验和 + 自动修复，抗数据损坏 |
macOS 系统盘 / 外接 SSD | APFS | — | 为闪存优化，快照 + 空间共享 |
旧款 Mac / 机械盘 | HFS+ | APFS | APFS 在机械盘上优势不明显 |
Linux 系统盘 / 通用 | ext4 | Btrfs | 稳、可预测、工具链成熟 |
Linux 大文件 / 高并发 | XFS | ext4 | 大文件吞吐强、在线扩容快 |
Linux 需要快照/回滚 | Btrfs | ZFS | 子卷快照，Fedora/openSUSE 主流方案 |
NAS / 数据中心存储池 | ZFS | Btrfs | 端到端校验 + 自愈 + 复制 |
跨平台 U 盘 / 移动硬盘 | exFAT | FAT32 | 全平台读写、无 4GB 限制 |
老设备（车载/相机/游戏机） | FAT32 | exFAT | 兼容性最广 |
SD 卡 / U 盘（小文件） | exFAT | FAT32 | NTFS 的日志会加速闪存老化 |
数据库（MySQL/PG） | XFS / ext4 | 避开 Btrfs/ZFS CoW | CoW 在数据库随机写上碎片化严重 |
容器 / K8s 持久化 | XFS | ext4 | overlay2 推荐 backend |
手机 / 嵌入式闪存 | F2FS | ext4 | 专为 NAND 设计，减少写放大 |
临时文件 / /tmp | tmpfs | — | 内存盘，重启即清 |
T3 · 检查与修复时间主表（核心）
这是选文件系统时最容易被忽略、出事时最要命的一列。 对应 RAID 笔记里的"重建时间"——都是"出事后要等多久"的指标。
文件系统 | 工具 | 1 TB | 10 TB | 16 TB | 备注 |
|---|
ext4 | fsck.ext4 (e2fsck)
| 5–15 min
(强制 -f 翻倍) | 数小时 | 4–6 h
(全盘扫描) | 正常检查快，损坏修复指数级变慢 |
XFS | xfs_repair
| 数分钟 | ~30 min
(干净修复) | < 1 h | 严重元数据损坏时 2–8 h，可能反而慢于 ext4 |
Btrfs | btrfs scrub
| 1–3 h/TB | 10–30 h | 16–48 h | 可中断可暂停，速度慢但有校验 |
ZFS | zpool scrub
| 数小时 | 12–24 h (10TB 池) | 更长 | 边扫边自愈，可限速，不影响业务 |
NTFS | chkdsk
| 数分钟–数小时 | — | — | /f 修复需卸载，系统盘要重启进修复
|
exFAT/FAT32 | chkdsk / fsck.vfat
| — | — | — | 无日志，只能全盘扫，慢且救不回来 |
关键实测对照（ext4 vs XFS，同硬件同文件数）：
卷大小 | 文件数 | XFS xfs_repair | ext4 fsck | 倍差 |
|---|
72 TB | 1.05 亿 | 1,629 s (~27 min) | 3,193 s (~53 min) | 2.0× |
72 TB | 5,100 万 | 534 s (~9 min) | 1,811 s (~30 min) | 3.4× |
72 TB | 1,020 万 | 161 s (~3 min) | 972 s (~16 min) | 6.0× |
38 TB | 1.05 亿 | 710 s (~12 min) | 3,372 s (~56 min) | 4.7× |
38 TB | 5,100 万 | 266 s (~4 min) | 1,358 s (~23 min) | 5.1× |
38 TB | 1,020 万 | 131 s (~2 min) | 470 s (~8 min) | 3.6× |
数据来源：EnterpriseStorageForum 组织的 fsck 基准测试。XFS 在文件数少、卷大时优势最明显（6 倍）；AWS EBS 4TB 卷测试也显示 ext4 的 fsck 耗时约为 XFS 的 3 倍。
极端案例：一台跑了五年的数据库服务器，文件系统里塞了 5000 万+ 小文件，强制 fsck 跑了将近 19 小时。
时间受什么影响（按权重排序）：
文件数量 > 卷大小 —— 元数据遍历是瓶颈，不是容量
是否强制全盘扫描（-f）
损坏程度 —— 一旦涉及 orphan inode 或目录结构混乱，时间指数级增长
介质：HDD vs SSD 能差几十倍
T4 · 格式化与扩容时间
操作 | ext4 | XFS |
|---|
格式化 1 TB | 30–60 s | — |
格式化 16 TB | 10–20 min | 5–8 min（调优后约 3 min） |
格式化 100 TB | > 2 h | 明显快于 ext4 |
16 TB 在线扩容 | 15 min 量级 | 15 min 量级（xfs_growfs） |
缩容 | 支持（离线） | 不支持 ← XFS 的硬伤 |
ext4 格式化时的 -E lazy_itable_init=0,lazy_journal_init=0 会在格式化时完成元数据初始化，多花几分钟，但避免后台偷 CPU。
T5 · 网络与分布式文件系统
注意：NFS/SMB 不是文件系统，是网络协议，跑在本地文件系统之上。这是最常被混淆的概念。
名称 | 类型 | 阵营 | 端口 | 认证 | 最佳场景 |
|---|
NFS v4 | 网络协议 | Unix/Linux 原生 | 2049 | Kerberos / IP 信任 | Linux 服务器间、K8s、虚拟化后端 |
SMB 3.x | 网络协议 | Windows 原生 | 445 | AD / Kerberos | Windows 文件共享、混合办公 |
CIFS (=SMBv1) | 网络协议 | 遗留 | 139/445 | 弱 | ❌ 已废弃，永恒之蓝漏洞载体，应禁用 |
NFS vs SMB 快速判断：
维度 | NFS | SMB |
|---|
状态 | 无状态、轻量 | 有状态、功能丰富 |
优势场景 | 大文件顺序传输、Linux-to-Linux | 小文件、元数据密集、Windows/混合 |
认证 | UID/GID（AUTH_SYS 弱）、Kerberos | AD 集成、每用户 ACL |
加密 | NFSv4 + krb5p | SMB 3.x 原生端到端加密 |
特殊能力 | pNFS 并行访问 | SMB Direct (RDMA)、Multichannel |
一句话 | Linux 后端选它 | 有 Windows 客户端就选它 |
分布式文件系统：
系统 | 一致性 | 接口 | 强项 | 弱项 | 典型场景 |
|---|
HDFS | 强一致（WORM） | HDFS API | 高吞吐、Hadoop 生态 | 小文件灾难、随机写差、NameNode 瓶颈 | 离线批处理、数仓 |
CephFS | 强一致 | S3/RBD/POSIX | 对象/块/文件统一、CRUSH 去中心化 | 运维复杂度高 | 私有云、K8s、统一存储 |
GlusterFS | 最终一致 | NFS/SMB/FUSE | 无元数据服务器、易扩展 | 大目录遍历慢、再平衡开销 | 通用 NAS 替代、媒体库 |
Lustre | 强一致 | POSIX 并行 | 极高吞吐（超算级 200GB/s） | 非云原生、成本高 | HPC、基因测序、渲染 |
MinIO | 强一致 | S3 API | 轻量、S3 兼容、高性能 | 非 POSIX 语义 | 数据湖、AI 训练、备份归档 |
GPFS | 强一致 | POSIX 并行 | 企业级可靠、分布式锁 | 商业授权、贵 | 金融核心业务 |
第二部分 · 检查与修复详解（核心）
2.1 日志 vs CoW：崩溃后怎么恢复
这是理解文件系统可靠性的钥匙。两种完全不同的思路：
机制 | 原理 | 代表 | 崩溃后行为 |
|---|
无日志 | 直接改，什么都不记 | FAT32/exFAT/ext2 | 断电 = 结构损坏，必须全盘 fsck，可能丢数据 |
日志（Journaling） | 先写日志再改数据 | NTFS/ext3/ext4/XFS | 重放日志，秒级回到一致状态 |
写时复制（CoW） | 永不覆写，写新块后换指针 | APFS/Btrfs/ZFS | 天然一致，要么旧状态要么新状态，不存在写洞 |
日志的三种模式（ext4 可调，影响巨大）：
模式 | 保护范围 | 性能 | 恢复速度 |
|---|
data=writeback
| 仅元数据 | 最快 | 快，但数据可能脏 |
data=ordered
| 元数据 + 顺序保证（默认） | 均衡 | 快 |
data=journal
| 元数据 + 数据全记 | 慢约 25% | 最快，恢复比 XFS 快 47% |
2.2 修复工具与危险操作
文件系统 | 检查命令 | 修复命令 | 危险操作 |
|---|
ext4 | fsck.ext4 -n /dev/sdX (只读检查)
| fsck.ext4 -y /dev/sdX
| -y 无脑确认可能删数据；必须先卸载
|
XFS | xfs_repair -n /dev/sdX (只读)
| xfs_repair /dev/sdX
| ⚠️ xfs_repair -L 会清空日志，丢失所有未提交事务，仅在日志损坏无法挂载时用 |
Btrfs | btrfs scrub start /mnt
| btrfs check --repair
| ⚠️ --repair 被官方标记为危险，优先用 scrub + 有冗余自愈 |
ZFS | zpool scrub tank
| 自动修复 | 无需手动修复工具，scrub 发现即修 |
NTFS | chkdsk X:
| chkdsk X: /f
| 系统盘需重启进修复模式，期间不可用 |
修复铁律：
先只读检查（-n）看清楚损坏范围，别直接上修复
必须卸载（或只读挂载）后再修，挂载状态修复会二次破坏
有备份先备份——严重损坏时修复本身可能丢数据
XFS 的 -L 是最后手段，不是常规操作
2.3 静默损坏：为什么 ext4/XFS 看不见
这是选择现代文件系统的核心理由。硬盘会返回错误的数据而不报错——磁翻转、固件 bug、线缆问题、控制器写错位置。
文件系统 | 能发现吗 | 能自愈吗 | 说明 |
|---|
ext4 / XFS | ❌ | ❌ | 只校验元数据，不知道你的文件内容本来长什么样 |
NTFS | ⚠️ 部分 | ❌ | 无端到端数据校验 |
ReFS | ✅ | ✅ | 校验和 + 自动从冗余修复 |
APFS / Btrfs / ZFS | ✅ | ✅ | 校验和 + 冗余 + scrub = 自愈 |
三件套缺一不可：
校验和：每个块存指纹，读的时候验证
巡检（scrub）：定期全盘走一遍验证指纹
冗余：发现坏的能用好的副本补回来
→ 只有前两个 = 能发现问题但修不了；三个都有 = 自愈。这也是 ZFS/Btrfs 存在的根本理由。
2.4 ZFS vs Btrfs 实战对比
维度 | ZFS | Btrfs |
|---|
数据完整性 | 最佳：端到端校验和，scrub 时自动修复 | 有校验和，但自愈可靠性弱于 ZFS |
RAID 成熟度 | RAIDZ1/2/3 久经考验 | RAID 0/1/10 稳；RAID5/6 有写洞 bug，生产禁用 |
扩容 | 历史上僵化；OpenZFS 2.3 起支持 RAIDZ 扩容 | 随时加单盘、混用不同容量，再平衡 ← 最大优势 |
内存 | 重：约 1GB RAM / 1TB 存储，建议 ECC | 轻：2–4GB 就能跑，普通内存即可 |
快照 | 微秒级，百万级数量 | 微秒级，可写快照（更像 ZFS clone） |
复制 | zfs send/recv，可断点续传、可加密
| btrfs send/recv，无原生流加密
|
加密 | 原生，按 dataset，支持加密复制 | 无原生，靠底层 LUKS |
去重 | 原生（但极吃内存，家用基本别开） | 无在线去重，需 duperemove/bees 离线跑 |
内核状态 | CDDL 授权，树外模块（TrueNAS/Proxmox 原生） | GPL，内核主线，开箱即用 |
适合 | TrueNAS、专用存储服务器、大批量同规格盘 | 群晖 DSM、Fedora/openSUSE、预算有限的家用 |
一句话选择：在乎数据完整性 + 有同规格盘和足够内存 → ZFS；盘大小不一、内存有限、想省事 → Btrfs（但避开 RAID5/6）。
第三部分 · 数据保护（核心）
3.1 文件系统能防什么，防不了什么
情形 | 日志 | 校验和+自愈 | 快照 | 备份 |
|---|
断电/崩溃导致结构不一致 | ✅ | ✅ | ✅ | ✅ |
静默损坏（位衰减） | ❌ | ✅ | ⚠️ | ✅ |
硬盘物理损坏 | ❌ | ⚠️ 需冗余 | ❌ | ✅ |
误删除 / 误格式化 | ❌ | ❌ | ✅ 可回滚 | ✅ |
勒索病毒加密 | ❌ | ❌ | ⚠️ 本地快照可能被删 | ✅ 需离线/不可变 |
文件系统自身 bug | ❌ | ❌ | ❌ | ✅ |
整机损毁 / 被盗 | ❌ | ❌ | ❌ | ✅ 需异地 |
关键认知：文件系统的所有高级特性（日志、校验和、快照）都作用于同一份在线数据。它们提升的是"数据正确性"，不是"数据可恢复性"。
3.2 快照不是备份（再强调一次）
| 快照 | 备份 |
|---|
位置 | 同一块盘/同一个池 | 独立介质 |
池/盘坏了 | 一起没 | 还在 |
防误删 | ✅ 回滚秒级 | ✅ |
防勒索 | ⚠️ 本地快照可能被一起加密/删除 | ✅（离线或不可变才行） |
防硬件故障 | ❌ | ✅ |
快照的正确定位：快照是最快的第一道防线（秒级回滚误删、失败的系统更新），但它是备份的补充，不是替代。
推荐组合：Btrfs/ZFS 快照（防误删）+ 异地备份（防灾难），前者管分钟级、后者管天灾。
3.3 备份仍然要 3-2-1
文件系统层面的一切手段都替代不了：
3 份副本（生产 + 本地备份 + 异地备份）
2 种介质（阵列 + 磁带/对象存储/外置盘）
1 份异地（物理隔离）
1 份离线/不可变（防勒索）
0 错误（定期恢复演练验证）
文件系统特性只是降低了"出事的概率"，备份决定的是"出事后还有没有"。
第四部分 · 原理备查
4.1 文件系统的组成
几乎所有文件系统都由这几块构成：
组件 | 作用 |
|---|
超级块 Superblock | 文件系统的"身份证"：类型、大小、状态、块大小。坏了整个 FS 就废，所以有多份备份 |
inode | 文件的元数据：权限、时间戳、数据块指针。不含文件名 |
数据块 Data Block | 真正存文件内容的地方 |
目录项 dentry | 文件名 → inode 的映射表 |
位图 Bitmap | 记录哪些块/inode 已用 |
日志 Journal | 崩溃恢复用的预写日志（若有） |
找 /home/a.txt 的过程：根目录 inode → 查目录项找到 home 的 inode → 查 home 的数据块找到 a.txt 的 inode → 按 inode 里的指针读数据块。
4.2 关键概念速记
概念 | 一句话 |
|---|
inode | 文件的元数据身份证，一个文件一个；inode 用光了即便有空间也写不进去（小文件多的场景常见） |
Extent | 连续块分配，替代传统的单块指针表；ext4/XFS 都用，大幅减少大文件碎片 |
块大小 | 常见 4KB。小文件多用小块省空间，大文件用大块提性能 |
延迟分配 | 写入时先缓存不落盘，攒够再一次性分配连续块 → 减少碎片，但断电风险高一点 |
稀疏文件 | 空洞不占实际空间（ls 显示大，du 显示小） |
硬链接 / 软链接 | 硬链接共享 inode（不能跨 FS）；软链接是路径指针（可跨 FS） |
写放大 | CoW 文件系统在数据库随机写场景下会严重碎片化，需定期对碎片整理或关闭 CoW（chattr +C） |
TRIM / Discard | SSD 告知哪些块可回收；开 discard 挂载选项或定期 fstrim |
写洞 Write Hole | 非 CoW 的 RAID5/6 断电后校验不一致；ZFS/Btrfs 的 CoW 天然免疫 |
4.3 三平台默认格式速查
平台 | 默认 | 历史 | 备注 |
|---|
Windows | NTFS | FAT32 (XP 时代) | 服务器版可用 ReFS |
macOS | APFS | HFS+ (10.12 及更早) | 机械盘外接仍可用 HFS+ |
Linux | ext4 | ext3/ext2 | RHEL/CentOS 系常用 XFS 作数据盘 |
Android | F2FS / ext4 | — | 旗舰机多用 F2FS |
路由器/嵌入式 | ext4 / SquashFS / JFFS2 | — | SquashFS 只读压缩，用于固件 |
4.4 常见误区
问题 | 正解 |
|---|
NTFS 在 Mac 上能写吗？ | 默认只读，需装 Paragon/Tuxera 等驱动；跨平台还是用 exFAT |
U 盘用 NTFS 更好吗？ | 不好。NTFS 日志会增加主控擦写次数，加速 U 盘老化；闪存首选 exFAT |
ext4 比 XFS 更安全？ | 不是一回事。XFS 恢复更快、有元数据 CRC；ext4 更保守成熟。两者都不做数据校验和 |
CoW 文件系统一定更好？ | 数据库场景反而更差。MySQL/PostgreSQL 的随机写会让 CoW 严重碎片化，应对数据目录关 CoW 或用 ext4/XFS |
Btrfs 可以放心用了吗？ | RAID1/10 和单盘场景已经很稳；RAID5/6 至今仍是已知问题，生产禁用 |
ZFS 一定要 ECC 内存吗？ | 官方说非强制，但强烈建议。ZFS 靠内存做校验和验证，内存出错会污染数据 |
格式化等于彻底删除？ | 不等于。只重建了目录结构，原始数据短期内物理上还在，可恢复 |
卷越大越好？ | 不是。检查时间、扩容风险、恢复成本都随容量增长；16TB 是很多管理员的心理安全线 |
4.5 运维清单
[ ] 定期检查（ext4 半年一次强制 fsck；ZFS/Btrfs 每月 scrub）
[ ] 监控 inode 使用率（df -i），别只看容量
[ ] SSD 开启定期 TRIM（systemctl enable fstrim.timer）
[ ] 数据库目录关 CoW（chattr +C）或直接用 ext4/XFS
[ ] ZFS 配 ECC 内存，别开去重
[ ] Btrfs 避开 RAID5/6，只用 RAID1/10
[ ] 记录文件系统类型、挂载参数、UUID 到配置文档
[ ] 分片规划：单分区建议不超过 16TB（检查/恢复时间可控）
[ ] 定期做恢复演练（最容易漏的一条）
4.6 命令速查
场景 | 命令 |
|---|
查看所有块设备/文件系统 | lsblk -f ｜ df -hT ｜ findmnt
|
查看 ext4 信息 | tune2fs -l /dev/sdX
|
查看 XFS 信息 | xfs_info /dev/sdX
|
查看 Btrfs 信息 | btrfs filesystem show ｜ btrfs filesystem df /mnt
|
查看 ZFS 池 | zpool status -v ｜ zpool list -v
|
只读检查 ext4 | fsck.ext4 -n /dev/sdX
|
只读检查 XFS | xfs_repair -n /dev/sdX
|
触发 ZFS 巡检 | zpool scrub tank
|
触发 Btrfs 巡检 | btrfs scrub start /mnt
|
格式化 ext4（立即初始化） | mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdX
|
格式化 XFS（高并发分配） | mkfs.xfs -d agcount=64 /dev/sdX
|
在线扩容 ext4 | resize2fs /dev/sdX
|
在线扩容 XFS | xfs_growfs /mnt
|
SSD 手动 TRIM | fstrim -v /mnt
|
挂载 NFS | mount -t nfs -o vers=4 server:/export /mnt
|
挂载 SMB | mount -t cifs -o credentials=/root/.smb //server/share /mnt
|
