记我所遇到的各种 Btrfs 问题
大概算了下，从我接触 Linux 开始，至今大概用了快两年的 Btrfs（之前在 Linux 上跑过一年左右的 ZFS），趁着今天心血来潮，干脆就记录下踩过的坑，吐一下槽。
Btrfs 虽然发展历史也已经有七年，但是至今为止，依然存在诸多暗坑，也曾让我吃过苦头。
个人目前遇到的比较严重的几个问题如下：
1、千万不要在任何 Btrfs 子卷上开启 lzo 透明压缩
之前我一度喜欢开启 lzo 压缩，以此达到节省空间的目的。但是前几个月在运行 btrfs scrub 的时候发现报告中出现了很多不可恢复的 csum error。
无奈之下重新安装系统，但是不到个把月，同样的错误再次出现。当时百思不得其解，甚至怀疑是不是我编译的内核有问题。
好在后来看到了 Debian Wiki 才恍然大悟，罪魁祸首就是 lzo 压缩。而且我基本可以确认，这个问题是在今年引入的，因为一直到去年我都未发现异常。
当然，如果有勇士喜欢用 gzip 压缩，我也不反对。
2、慎用 btrfsck
Btrfs 另外一个遭人诟病的地方就是没有完善的 fsck 工具，虽然从设计上来说，Btrfs 和 ZFS一样，应该是 non-fsck 型文件系统。
但是，毕竟世事难预料，如果像我这样真的遇到了 csum error 这种不可恢复的错误，那么 fsck 就是最后的救命稻草了。
当然没有这么简单，事实上，btrfsck 并没有起到任何作用。相反，在重建过 csum 树以后，它反而让我的文件系统坏得更彻底了。
所以，如果真的到了走投无路的时候，反正跑一下 fsck 也不会让问题变得更糟糕了，不是吗？
3、缺乏完善的内建 RAID5/6 支持
其实不光内建 RAID5/6 支持，很多曾经设想的 feature 目前都没有出现在 Btrfs 上，比如 lz4 压缩。
一方面是因为开发人手不足，另一方面也是因为 ZFS 这座大山实在难以逾越。想想看，ZFS 有 zvol，有 RAIDZ，有各种高大上的 feature（貌似开源版本 ZFS 也快实现原生加密了）。
不过 Btrfs 的好处就是，随内核版本而更新，无需像 ZFS 那样，每次升级新版本内核都要等待相应的模块版本更新。
不说了，说多了我又想在 Linux 上用 ZFS 了……