尝鲜 Bcachefs 的注意事项

12 小时 21 分钟前
 ChaosAttractor

如果有人要用 bcachefs 的话,我这一个月折腾了好久,总结了一些坑,可以参考一下

  1. 一定保证存储的 bcachefs 上的数据有存储在其他文件系统的完整备份

  2. bcachefs format 默认会使用硬盘逻辑 blocksize 作为文件系统的 blocksize ,这和文档中的记录不符,最好格式化时手动设置 blocksize 到 4096

  3. 千万别开透明压缩,除非你完全不 care 性能,它是 zstd 实现是单线程的,且性能只有正常的单线程 zstd 的约 1/10 (原因未知),q64t1 bs=1M 能跑出 28MB/s 的惊世骇俗的成绩

    此外它的压缩是基于 extents 进行压缩的(而不是 block ),因此 extents 的大小直接决定压缩率和速度,开启压缩时你可能可以得到 q64t1 bs=4K 性能比 q64t1 bs=1M 好,好很多

  4. 要保证一个组里没有性能差距过大的硬盘,不然因为数据的多个 replica 的写入不是异步的而导致性能更好的硬盘降级到最差硬盘的水平,目前没法指定 replica 的拓扑

  5. 写入会进 foreground_target 并在对应组的所有硬盘之间条带化,而不是同时在 foreground_target 和 background_target 之间条带化

    由于上一条建议,因此不推荐这么做(你可以通过不设置 foreground_target/background_target 来实现在全部硬盘间条带化)

  6. 如果设置了两个 replicas ,但是却有偶数个硬盘,则多出来的硬盘完全不提供性能提升 例如你在 foreground_target 的组中有三块硬盘,background 组中有两块硬盘,那么写入只会同时写到 foreground_target 中的其中两块硬盘

  7. 如果你用 systemd-mount 挂载硬盘,默认会在一个比较短的时间内超时,如果 bcachefs 更新数据结构,mount 时 fsck 需要非常长的时间,可以通过设置 x-systemd.mount-timeout=3600s 来防止 fsck 到一半 systemd 跳出

  8. 添加硬盘后可以用

    bcachefs data job migrate /mnt
    

    来重新 balance ,尤其是可以强制让 btree 节点移动到新的 metadata_target/foreground_target

  9. 如果 metadata_target=none (默认)那么 metadata 就会写到 foreground_target

  10. background_compression=none 时会继承 compression 的值,默认情况下格式化时只指定 compression 那么 background_compression 就会是 none

  11. bcachefs 不会在检查到磁盘支持 discard 就自动开启,务必手动给 ssd 开启 discard

  12. 通过设置 durability=0 可以得到 writethrough cache ,设置 promote_target 而不设置 foreground_target 可以得到 writearound cache

    假如你有一些性能较差/与其他硬盘不一致的 ssd ,并且你只想让它作为读缓存来提高覆盖率,那么可以加入到 foreground_target 的组中并设置 durability ,roadmap 中,未来还可能支持更复杂的 tiering 配置来覆盖同组中速率不一致时的种种情况

  13. metadata_replicas_required 和 data_replicas_required 决定的是 mount 时有多少副本才认为数据完全,而不是写入多少个 replica 就算写入完成/提供 fsync 保证

  14. 暂时最好别用 online fsck ,有一些问题,可以去 bcachefs 的 github mirror 的 issue 区看

  15. 如果你想尝试 master 分支,请一定先去 irc 里看看是不是已经 ready 了,也可以去看看 ci 的 state

    目前 6.12 用下来没遇到什么大问题,但是 6.11 有非常多已知问题

677 次点击
所在节点    NAS
6 条回复
ChaosAttractor
8 小时 23 分钟前
还观察到一些很有意思的事情,bcachefs 如果硬盘容量不同,为了保证 IO 性能的持续一致性,假如一个硬盘容量 10T ,一个 5T ,那么它们被填充的 IO 量会不一样
我这边比较极端,两个 10T 四个 800G ,可以观测到两个 10T 填充了 100MB/s ,俩 800G 就只被填充了 8MB/s
考虑到后台是可以 rebalance 的,我不觉得这是一个好的做法
这还导致一个很神奇的事情,如果你让数据在 SSD 和 HDD 之间条带,你会发现数据全写到 HDD 里了,SSD 就在那边干看着

然后单个数据的多个镜像在读取时应该没做 Round Robin 来提高吞吐?
然后写入由于我还没有四个 SSD ,我也不知道它能不能很好的在写入时填充多个条带
tenl
7 小时 29 分钟前
等完善了能替换 zfs 不?
MoonLin
6 小时 0 分钟前
赞一个,一直在关注这个 fs ,中文世界对这个 fs 的讨论实在太少了,楼主太棒了
ChaosAttractor
5 小时 5 分钟前
@tenl 对 FS 来说,开发的时间跨度太长了
很可能是 3 年后可用,5 年后稳定,10 年后成熟
relife
4 小时 39 分钟前
我还是继续用 btrfs 吧
roidinev
2 小时 25 分钟前
先存档

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1099208

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX