LWN：何时以及为何需要废弃一些文件系统？
关注了就能看到更多这么棒的文章哦～
When and why to deprecate filesystems
By Jonathan Corbet
March 7, 2022
DeepL assisted translation
https://lwn.net/Articles/886708/
可以肯定在内核中有大量代码是完全没有在使用的。即便如此，这些代码仍然必须要进行维护和发布，这些工作给开发社区带来了持续开销。对于那些未被维护和可能未被使用的代码，应该怎么做呢？回答这个问题需要了解仍然存在有哪些用户（如果真的有的话），并认真研究对这些代码在未来如何支持。内核社区最近在文件系统，特别针对 Reiserfs 文件系统讨论了这个问题，问题的核心是即将到来的 2038 年截止日期。
移除对旧硬件的支持就已经很困难了，但往往还是会有一个时间点，在此之后是可能可以移除的。也就是如果一类设备已经多年无法正常支持，而且没有人可以列举出一个仍在运行的带有此类设备的系统，那么就可能是时候把它的支持从内核中移除了。另一个明确信号就是维护者完全没有兴趣继续维护，例如，最近决定取消对 NDS 架构的支持就是这个情况。不过，文件系统方面就会更加困难了，它们不依赖于具体硬件，因此可以比任何具体设备类型都存活得更长久。用户可能在世界绝大多数使用场景都已经不再使用这个文件系统很久之后，仍然决定继续使用这个自己比较熟悉的文件系统类型。
Reiserfs 就是一个典型的例子；这个文件系统在 1999 年首次在 LWN 中报道；尽管有相当多的人反对 2.4 版本作为 stable，但它还是在第二年进入了 2.4.1 内核。把 Reiserfs 加进来的原因有很多，其中最主要的原因可能是它是第一个支持日志的 Linux 文件系统。这个文件系统在早期吸引了相当多人的兴趣，一些发行版缺省使用了 Reiserfs，但这个文件系统的开发者很快就转向了其他方案。到 2004 年的时候，Hans Reiser 反对继续加强 Reiserfs，而是认为应该采用他新开发的 Reiser4 文件系统。最终，Reiser4 没有被合入 mainline，内核中仍然是使用 Reiserfs。
最近，Matthew Wilcox 发现 Reiserfs 的维护工作似乎已经停止了。因此，他很自然地就想问是否还有活跃的 Reiserfs 用户，也就是说是否可以删除该文件系统。毕竟，保留这个文件系统是有开发成本的，而且它妨碍了他想做的一些改进工作。
如上所述，很难有一个明确的时间点可以让内核开发者得出结论说内核中不再需要保留一个文件系统的实现了。Reiserfs 对任何仍在运行的用户来说仍然是有效的，移除该文件系统代码的话，他们就会认为这属于 regression，而内核社区不允许出现这种 regression。因此，通常来说最好办法是在内核中放置一个显眼的 deprecation （弃用）提示信息，等待几年。如果在这段时间内没有出现反对意见，那么可能就可以安全删除这个文件系统了。目前已经发布了一个添加了 deprecation 提示信息的 patch，并有可能在 5.18 版本内核中得到合并。
在讨论中，Byron Stanoszek 承认他一直在使用 Reiserfs，并希望看到它能得到更久的支持。Jan Kara 回应说，Reiserfs 现在得到的支持也是很有限的：
坦率地说，Reiserfs 的实际情况是，它几乎没有得到任何开发和测试精力。现在，这本身并不是一个大问题，因为过去实现好的代码应该能继续工作，但普通文件系统基础设施的其他代码一直在进行改动（例如 Matthew 的 page cache 改动，新的 mount API 等），所以可能发生的情况是，由于缺少测试和开发，reiserfs 会在我们没有注意到的情况下就无法正常工作了。因此，我认为现在的 reiserfs 不是一个特别安全的文件系统选项了，而应该考虑迁移到其他文件系统。
如果确实有必要的话，Kara 愿意推后 Reiserfs 的废弃日期。
碰巧的是，Stanoszek 提出了一个与 Reiserfs 的废弃日期有关的问题，者也刚好展示了一般的废弃行为都需要注意到的一个问题。那就是哪怕是 Reiserfs 最忠实的用户，最终也会发现自己需要换个方案了，因为该文件系统有一个 2038 年的问题。在这一年的一月份，Reiserfs 中使用的时间戳会溢出，导致世界一团乱。由于这些时间戳深藏在磁盘文件系统的底层格式中，因此无法通过简单的代码调整来解决。因此最好在到这个日子之前从 Reiserfs 文件系统把自己的数据搬移出来。
这可能看起来不是一个紧迫的问题，因为最后期限还有 15 年。但现在有理由要采取行动了，这就是为什么 Dave Chinner 断定现在已经到了废除所有不适合 2038 年的文件系统的时刻了。他后来做了更详细的解释：
基于同样的原因，我们已经废除了 XFS 中不符合 y2038k 的那些功能，这样企业级环境里的内核就可以在他们的下一个主要版本（N+1）中标记为 deprecated 状态，然后这个版本可能需要支持 10 年。再然后，就可以在之后的 N+2 主要版本发布时取消对它的支持（这可能至少是 5 年之后了），这样，才能让那些不兼容的功能不会在 y2038k 日期之后还在使用。
问题是，在 mainline 内核中废弃一个文件系统并不能改变它还是在最近的长期支持的内核中有支持的事实。如果过去的模式保持不变的话，5.15 内核将会要支持到 2028 年。这期间都会一直包含 Reiserfs。正如 Wilcox 所指出的，这对于那些不能立即从这个文件系统迁移走的用户来说是一个延续支持的方式，这可能是一件好事。但它也给负责维护这些内核的开发者们带来了一个持续的问题。
这是因为在一个长期稳定的（long-term-stable）内核中支持 deprecated 代码将变得越来越困难。Ted Ts'o 指出，stable 内核的维护者将不能再依赖 upstream 的 fix，而且由于缺乏一个中心决策点，所以可能任何 fix 都无法同步到其他版本内核上去。因此，在 Reiserfs 从 mainline 被删除后的六年里，如何对它进行保证质量的维护，这会是一个挑战。任何基于这个 stable 版本的企业内核支持 Reiserfs 的时间都可能会超过这个时间。企业发行版提供商必须考虑在 15 年内保证支持当前内核具有的功能。如果他们想避免在 2038 年之后继续支持这些无法正常使用的文件系统的额外工作，那么现在就需要开始 deprecate 流程了。
这意味着我们可能会在不久之后看到其他一些文件系统也会进入 deprecation。例如，NFSv3 协议使用 32 位时间值，将在 2038 年溢出。ext3 文件系统也有类似的问题，虽然数据可以作为 ext4 文件系统来读取，但磁盘上的格式根本无法正确表示时间了。因此，就像 XFSv4 磁盘格式一样，ext3 也不能在 2038 年使用，它需要先进行迁移。
这些文件系统进入待废弃状态，可能会给那些多年来一直坚持在使用并且用得好好的那些用户带来一些不快，而且切换到一个新的文件系统类型经常会让人们感到紧张。但另一种情况更糟。2038 年为开发者提供了一个很好的（也是合法的）借口，让他们可以更快地删除一些旧的、不受欢迎的文件系统。等这次机会过去之后，今后需要决定老文件系统应该何时废弃，就会再次成为一个问题，更加难于处理了。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～