Bcachefs从主线内核移除
[发布于2025年9月30日 by corbet]
在6.17版本中将Bcachefs标记为"外部维护"后，Linus Torvalds已在6.18版本中完全移除该文件系统。“它现在是一个DKMS模块，使得内核内代码变得陈旧，因此移除它以避免任何版本混淆。”
风险讨论
由patrakov发表于2025年9月30日 10:30 UTC
在Bcachefs进入主线之前，用户必须从Bcachefs作者处获取整个内核源代码树。这是因为该文件系统依赖于其他子系统的更改，而不仅仅是一个独立的附加组件。在上游化过程中，所需的更改被应用到这些子系统中，使Bcachefs变得自包含，然后它被拆分出来作为一个可以通过DKMS编译的模块。
我在这里看到主线内核可能撤销其他子系统更改的风险，因为它们可能不再有树内用户。我是否过于偏执？如果这个风险成为现实，Bcachefs项目对此的立场是什么——他们是会适应，还是回到告诉用户编译他们的整个树，而不是仅针对现有内核编译他们的模块？
由georgh-cat发表于2025年9月30日 16:45 UTC
这正是我的想法，这种对话在phoronix上是不可能的（但应该要有）。
决策过程
由daeler发表于2025年9月30日 12:44 UTC
只是好奇，没有评判：这个决定是如何做出的？Linus可以单方面决定从内核中移除某些东西吗？
由corbet发表于2025年9月30日 12:56 UTC
是的，Linus可以做出这类决定。不过他不是单方面做出决定的；有一系列公开和私下的讨论导致了这一决定。
由pizza发表于2025年9月30日 12:57 UTC
Linus可以单方面决定从内核中移除某些东西吗？
Linus（就像所有拥有Linux源代码的人一样）可以添加或移除任何他想要的东西。
当然，没有人被迫直接从他那里获取"Linux"。事实上，绝大多数Linux用户从其他人那里获取内核，这些内核包含Linus的Linux中没有或已被移除的功能、驱动程序和修复。
由Lionel_Debroux发表于2025年9月30日 13:37 UTC
请注意，情况也会反向发生：安全修复在Linus的Linux中可用，但在其他内核中缺失，因为反向移植过程由于某种原因（难度、兴趣等）没有发生。
第三方内核版本越旧，它就越可能缺少安全修复的反向移植，以及新版本中引入但未反向移植到给定第三方内核的漏洞代码（一些供应商对其混合内核执行大量反向移植）。
观点讨论
由DemiMarie发表于2025年9月30日 15:41 UTC
我认为实验性文件系统不属于上游。需要超级快速发布修复以恢复用户数据的需求与上游内核的发布周期不太匹配。一旦文件系统稳定下来且紧急修复的可能性降低，上游化就更有意义。
我能想到的唯一例外是如果恢复几乎完全在用户空间处理，这不与内核发布周期绑定。
由intelfx发表于2025年9月30日 15:45 UTC
问题是，根据Linus等人的理念（这随后决定了他们的行动），所有东西都属于上游，而树外模块某种程度上"不存在"。不接受（或相反，拒绝）对内核内部的更改以适应树外模块，并且上述人员在断言这一点时非常直言不讳。
所以，如果你正在开发一些"不属于上游"的东西，一旦你需要修改内核API以适应你的代码（或者相反，一旦内核API以损害你代码的方式被修改）——你就倒霉了。
由roryi发表于2025年9月30日 17:29 UTC
虽然它被明确标记为实验性的。我很难理解谁会在没有备份的情况下，在尖端内核中使用实验性文件系统来存储重要数据。而且，老实说，感觉这里可能存在比那些被广泛讨论的人际关系问题更严重的问题。
是否有人一直在向天真的最终用户积极推荐使用bcachefs？是否存在所谓的模因文件系统——如果是的话，bcachefs是否以某种方式变成了一个？是否有流氓论坛发帖者/YouTuber/TikToker在欺骗人们进行这种风险行为而不意识到其影响？
由GNUtoo发表于2025年9月30日 18:30 UTC
它被明确标记为实验性的。我很难理解谁会没有备份就在尖端内核中使用实验性文件系统存储重要数据。
这也不是一个二元情况。
我确实使用不如ext4稳定的文件系统来存储可以重新创建的数据（基本上是我的根文件系统，重新创建它所需的大部分配置都在git中，其余部分可以快速重新创建，或者位于单独的ext4文件系统上），因为我还需要一些ext4不提供的更高级功能（reflinks，可能还有子卷）。
对我来说，理解是否值得冒这个风险的真正问题是：
- 重新安装需要多长时间
- 数据丢失会有多频繁
当然，文件系统功能、资源消耗、可用性等也被纳入考量。
如果我遇到太频繁的数据丢失，我可能会尝试另一个文件系统，任何可靠性的改进都是好的。
但即使有备份，也存在一些风险，因为我可能有较旧的备份，它可能在我执行git push之前恰好在错误时刻崩溃等。
所以提高可靠性总是好的，尽管它也可能有成本。
因此，我个人更倾向于按比例看待事物，ext4如果使用得当（频繁的fsck）可能是最稳定的，BTRFS稳定性较差，NILFS2稳定性更差。虽然这是高度主观的，因为这也包括个人经验（你的情况可能不同），而且甚至分散在不同时间（事物确实在演变）。
由koverstreet发表于2025年9月30日 20:53 UTC
我认为你完全搞反了。
相当一部分bcachefs用户使用它是因为他们在btrfs上受过伤害并丢失了整个文件系统，需要更可靠的东西——他们发现bcachefs就是这样的。
“模因文件系统”？说真的？我只是想为用户提供一个实际上坚如磐石的现代文件系统——并且正在成功，除了上游的戏剧性事件。