【转载】ZFS 入门：为什么它是目前最适合 NAS 的文件系统

2026-04-05 NAS存储转载

📋 转载说明：本文转载自知乎专栏，作者：存储工程师阿木，原文已注明 CC BY-SA 4.0 协议。原文链接：知乎专栏

写时复制（CoW）
端到端校验
快照与克隆
RAID-Z
与 ext4/Btrfs 对比
实用建议

ZFS 存储池（zpool）与数据集（dataset）的层次结构

在自建 NAS 这件事上，选文件系统是最重要也最容易被忽视的决策。大多数人习惯了 ext4，但对于存放珍贵数据（照片、备份、文档）的 NAS，ZFS 才是更合适的选择。

一、写时复制（Copy on Write）

ZFS 最核心的设计是 CoW。传统文件系统（ext4）更新文件时，直接在原来的位置覆盖写入。这意味着如果写入过程中断电，文件可能处于部分写入的状态，数据损坏且难以恢复。

ZFS 的做法是：永远不覆盖已有数据。更新文件时，把新内容写到空闲区域，然后原子性地更新指针。写入要么完整成功，要么完整失败，不存在中间状态。

CoW 写入流程与传统覆盖写入的对比

这个设计还带来了一个"副产品"——快照几乎免费。因为旧数据没有被覆盖，只需要保留旧的指针，就有了快照。

二、端到端数据完整性校验

ZFS 对每一个数据块计算校验和（默认是 Fletcher4，也可以选 SHA-256），并把校验和存在数据块本身的父节点里（而不是和数据放一起）。读取时自动验证，如果校验不通过说明数据损坏了。

更重要的是，ZFS 能区分两种损坏：

可修复的：如果你用了冗余配置（mirror 或 RAID-Z），ZFS 会自动从另一份副本恢复正确数据并写回——这叫自愈（self-healing）。
不可修复的：在 zpool status 里会报告 checksum errors，提醒你这块盘可能快坏了，赶紧换。

# 手动触发全盘 scrub（校验所有数据）
zpool scrub tank

# 查看进度和结果
zpool status tank

建议每月跑一次 scrub，能提前发现磁盘的隐患。

三、快照与克隆

# 创建快照（瞬间完成，几乎不占空间）
zfs snapshot tank/data@2026-04-05

# 列出快照
zfs list -t snapshot

# 回滚到快照
zfs rollback tank/data@2026-04-05

# 从快照克隆出一个新数据集（可写）
zfs clone tank/data@2026-04-05 tank/data-test

ZFS 快照的空间使用随时间变化

快照不占额外空间（只记录变化部分），创建几百个快照也很正常。很多人用它来做自动备份：每小时一个快照，保留 24 小时；每天一个，保留 30 天；每月一个，保留 12 个月。

四、RAID-Z

ZFS 内置 RAID，不依赖硬件 RAID 卡：

级别	可损坏盘数	最少盘数	适用场景
mirror	n-1（n 为镜像组盘数）	2	2-4 块盘，性能最好
RAID-Z1	1	3	4-8 块盘，平衡
RAID-Z2	2	4	6+ 块盘，重要数据
RAID-Z3	3	5	8+ 块盘，企业级

RAID-Z 的一个优点是没有传统 RAID-5 的"写洞"问题（因为 CoW 保证了原子写入）。缺点是扩容不方便，一组 RAID-Z 的盘数是固定的（但可以加新的 vdev 组）。

ZFS 原理与 TrueNAS 实战配置（B站）

五、与 ext4/Btrfs 的对比

特性	ext4	Btrfs	ZFS
CoW	❌	✅	✅
端到端校验	❌	✅（元数据）	✅（数据+元数据）
内置 RAID	❌	✅（RAID-5/6 有已知 bug）	✅（生产级）
快照	❌（需要 LVM）	✅	✅
稳定性	⭐⭐⭐⭐⭐	⭐⭐⭐（RAID 慎用）	⭐⭐⭐⭐⭐
内存需求	低	中	高（建议 1GB/TB）

六、实用建议

内存至少 8GB，建议 16GB 以上。ZFS 的 ARC 缓存吃内存，内存够大才能发挥完整性能。
ZFS 不能直接用分区，要整块磁盘。如果你的盘是 4K 扇区，创建 pool 时加 -o ashift=12。
不要用在生产环境里随意 zpool upgrade，升级后不能降级，确保你能接受风险再操作。
建议开 compression（zfs set compression=lz4 tank），lz4 对 CPU 开销极低但对文本、日志类文件压缩效果很好，实际空间利用率提升明显。

原文作者：存储工程师阿木 · 发布于知乎专栏 · 转载已获授权（CC BY-SA 4.0）· 本站排版有调整

← 返回首页