以来 Bcacheff文件系统在Linux6.7内核中很流行，它一直运行得很好。但今天，Bcachefs的特性更新被发送到Linux6.9合并窗口，Linus Torvalds对一些提议的代码不满意。
为Linux6.9提交的Bcachefs代码包括一些用于遍历子卷的用户空间界面的准备工作、对目录结构检查的改进、改进日志流水线以获得更好的性能、丢弃更高效的路径改进以及其他优化。这个拉取请求维护人员肯特·奥弗斯特里特将LINUX 6.9的Bcachef更改总结为：
Bcachefs 6.9更新
- Subvolumchildren btree；这是为遍历子卷提供用户空间接口所必需的，这将在后面出现
-对目录结构检查进行了大量改进
- 改进了日志流水线，显著提高了高IOdepth写入工作负载的性能
-丢弃路径改进：丢弃路径更高效，不再不必要地刷新日志
- 缓冲写路径现在可以避免使用inode锁
- 拉出各种库代码供XFS使用：time stats、mean_and_variance、darray、eytzinger、thread_with_file
-新mm帮助器：Memalloc_FLAGS_{SAVE|RESTORE}
- mempool现在启用kvmalloc mempools
但是，错误地使用Linus Torvalds的代码是将Bcachefs代码的某些元素移出到一些库类型代码以便它可以被其他文件系统轻松重用的补丁--XFS是表示对潜在地重用一些Bcachefs函数感兴趣的文件系统。
Linus Torvalds 回应对于该Bcachefs Pull请求，请执行以下操作：
“让随机bcachefs代码成为一个库函数”的东西我看了看，决定是毫无意义的，并最终意味着我不会在没有更多解释的情况下拉它（老实说，我不认为解释会站不住脚）。
“stdio_reDirect_print tf()”和darray_char内容只是可怕的接口，没有任何解释。界面太恶心了。
把它放在你自己的代码中，不要试图把它变成一个通用的库。
如果你要把它变成一个图书馆的东西，它需要是，
(a)更多的解释
(B)有更理智的命名，更少令人厌恶和完全无意义的界面(“DARRAY()”)。
不，找到另一个文件系统来共享这种代码并不足以试图声称它是一个健全的接口和健全的命名。
但主要的交易破坏者是疯狂的算术。
该死的，我们很久以前就讨论过愚蠢的"均值和方差"垃圾了。那时候是错的，现在还是错的。
你没有解释为什么不能使用更简单的MAD（中值绝对偏差）来代替方差。
这个错误的决定直接导致了对过于复杂的128位数学的毫无意义的使用。
我当时称其为疯狂的过度工程，据我所知，除了一些微小的类型名称细节外，绝对没有什么变化。
只要你把它做成某种只给我的东西，我不介意。
但是现在，您正试图将这些垃圾作为其他人会使用的某种通用库代码来推送，这立即意味着我非常介意疯狂地设计接口。
在其他方面，time_stats的东西看起来就像是一个带有名称和用途的正常界面，但这种可怕的基础设施的使用破坏了它。
在奥弗斯特里特为他的案子辩护后， 添加：
加权版本的代码从字面上讲没有更改。
方差值是不同的，但MAD和标准差之间的差异基本上只是一个恒定系数(对于不同的分布会有所不同，但那又如何呢？Any_Special_Case将具有特定的分布)。
那么，为什么恒定系数会对任何指数权重产生影响呢？
无论如何，请随时将代码保存在bcachefs中。
也许XFS甚至想复制这些代码。我不在乎，这看起来很愚蠢，但这是一个文件系统选择。
但是，如果我们要使其成为一个通用内核库，那么它必须是合理的。而不是让人们仅仅为了一个随机的统计元素而计算64位的平方根和128位的除法。
So as it stands now, Linus Torvalds isn't accepting this Bcachefs pull request for the Linux 6.9 kernel due to the proposed generic library code. We'll see if a new pull request comes in the days ahead with those patches dropped or otherwise reworked to satisfy the Linux creator.
