为什么我把 /home 换成了 Btrfs

从 ext4 切到 Btrfs 一年半了，写一下心路历程和踩过的坑。为什么换 2024 年初，连续两个月笔记本硬盘做了两次 e2fsck。每次都折腾半天，ext4 没 snapshot 没办法无痛回滚。 Btrfs 的几个特性正好对症： Copy-on-Write snapshot：几乎无成本创建文件系统级快照透明压缩：写时压缩，读时解压 subvolume：可以独立挂载、独立备份 send/receive：增量备份协议迁移过程（不重装的方案）用 btrfs-convert 从 ext4 在线转的： # 0. 备份 sudo rsync -aAXv /home/ /mnt/backup-home/ # 1. 卸载 /home sudo umount /home # 2. 转换 sudo btrfs-convert /dev/sda2 # 3. 编辑 fstab，改文件系统类型 # 4. 挂载 sudo mount /home # 5. 验证 df -T /home 坑： 转换完之后 不要立即删除 ext2 镜像，至少保留一周。压缩效果开 compress=zstd:3 之后： # 转换前: 920G 总量, 680G 已用, 193G 可用 # 转换后: 920G 总量, 510G 已用, 372G 可用多出来 170G 空间。CPU 占用几乎看不出差异。 snapper 配置配了三层 snapshot： timeline：每小时一次 pre/post pacman：每次装包前后自动 snapshot 手动：重要操作前手动创建回滚测试故意 rm -rf ~/important/，然后： # 列出 snapshot snapper -c home list # 回滚 sudo snapper -c home undochange 42..43 成功。important/ 完整恢复。踩过的坑碎片化：虚拟机 qcow2 镜像直接放 Btrfs 上，半年后性能掉一半 swapfile 不能用：用 swap partition scrub 必须定期跑：每月一次 balance 别乱跑：单盘场景下意义不大压缩用 zstd，不要用 lzo send/receive 增量备份 # 第一次全量 sudo btrfs send /home/.snapshots/1/snapshot | \ ssh backup@nas "btrfs receive /backup/home/" # 之后增量 sudo btrfs send -p /home/.snapshots/1/snapshot /home/.snapshots/2/snapshot | \ ssh backup@nas "btrfs receive /backup/home/" 比 rsync 快很多，块级别去重。一年半下来，回不去了。snapshot + 透明压缩 + send/receive 已经深度绑进工作流。