如果有人要用 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 有非常多已知问题