记我所遇到的各种 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 了……