XFS 文件系统在 RHEL/CentOS 6.x 中损坏 - 我该怎么办？

Question

最新版本的 RHEL/CentOS (EL6) 给我十多年来严重依赖的XFS 文件系统带来了一些有趣的变化。去年夏天，我花了一部分时间来追查由文档记录不足的内核向后移植导致的XFS 稀疏文件情况。其他人在迁移到 EL6 后遇到了不幸的性能问题或不一致的行为。

XFS 是我用于数据和增长分区的默认文件系统，因为它比默认的 ext3 文件系统提供稳定性、可扩展性和良好的性能提升。

2012 年 11 月出现的 EL6 系统上的 XFS 问题。我注意到我的服务器显示异常高的系统负载，即使在空闲时也是如此。在一种情况下，卸载的系统将显示 3+ 的恒定负载平均值。在其他情况下，负载增加了 1+。挂载的 XFS 文件系统的数量似乎会影响负载增加的严重程度。

系统有两个活动的 XFS 文件系统。升级到受影响的内核后，负载为 +2。

深入挖掘，我在XFS 邮件列表上发现了一些线程，这些线程指向xfsaild处于STAT D状态的进程频率增加。相应的CentOS Bug Tracker和Red Hat Bugzilla条目概述了问题的细节，并得出结论，这不是性能问题；只有在比2.6.32-279.14.1.el6更新的内核中报告系统负载时出错。

卧槽？！？

在一次性情况下，我知道负载报告可能没什么大不了的。尝试使用您的 NMS 和数百或数千台服务器来管理它！这是在2012年11 月在EL6.3 下的内核2.6.32-279.14.1.el6 中发现的。内核2.6.32-279.19.1.el6和2.6.32-279.22.1.el6在随后几个月（2012 年 12 月和 2013 年 2 月）发布，此行为没有变化。自从发现这个问题以来，该操作系统甚至还发布了一个新的小版本。EL6.4 已发布，现在位于内核2.6.32-358.2.1.el6 上，表现出相同的行为。

我有一个新的系统构建队列，不得不解决这个问题，要么在 2012 年 11 月之前发布的 EL6.3 版本中锁定内核版本，要么只是不使用 XFS，选择ext4或ZFS，以严重的性能损失对于在上面运行的特定自定义应用程序。有问题的应用程序严重依赖于一些 XFS 文件系统属性来解决应用程序设计中的缺陷。

在 Red Hat 的付费知识库站点后面，会出现一个条目，说明：

安装内核 2.6.32-279.14.1.el6 后观察到高平均负载。高平均负载是由于每个 XFS 格式设备的 xfsaild 进入 D 状态造成的。

目前没有针对此问题的解决方案。目前正在通过 Bugzilla #883905 对其进行跟踪。解决方法 将已安装的内核包降级到低于 2.6.32-279.14.1 的版本。

（除了降级内核不是 RHEL 6.4 上的选项......）

所以我们在这个问题上已经有 4 个多月的时间了，没有为 EL6.3 或 EL6.4 操作系统版本计划真正的修复。有一个针对 EL6.5 的建议修复程序和一个可用的内核源补丁......但我的问题是：

当上游维护者破坏了一个重要的特性时，什么时候离开操作系统提供的内核和包是有意义的？

Red Hat 引入了这个错误。他们应该将修复程序合并到勘误内核中。使用企业操作系统的优势之一是它们提供了一致且可预测的平台目标。这个错误在补丁周期中破坏了已经在生产中的系统，并降低了部署新系统的信心。虽然我可以将建议的补丁之一应用于源代码，但它的可扩展性如何？随着操作系统的变化，需要保持警惕以保持更新。

什么是正确的举动？

• 我们知道这可能会修复，但不确定何时修复。
• 在 Red Hat 生态系统中支持您自己的内核有其自身的一系列警告。
• 对支持资格有什么影响？
• 我应该在新建的 EL6.4 服务器上覆盖一个工作的 EL6.3 内核以获得正确的 XFS 功能吗？
• 我应该等到正式修复吗？
• 这说明我们对企业 Linux 发布周期缺乏控制是什么意思？
• 长期依赖 XFS 文件系统是规划/设计错误吗？

编辑：

这个补丁被并入了最新的CentOSPlus内核版本（kernel-2.6.32-358.2.1.el6.centos.plus）。我正在我的 CentOS 系统上测试这个，但这对基于 Red Hat 的服务器没有多大帮助。

Answer 1

作为 6.4 勘误更新的一部分，Red Hat 于 2013 年 4 月 23 日在RHEL kernel-2.6.32-358.6.1.el6 中（悄悄地）修复了这个问题...

Answer 2

当上游维护者破坏了一个重要的特性时，什么时候离开操作系统提供的内核和包是有意义的？

“在供应商的内核或软件包严重损坏以致于影响您的业务时”是我的一般回答（巧合的是，这也是我所说的开始寻找脱离供应商关系的方法有意义的点） .

基本上正如您和其他人所说，RedHat 似乎不想在他们的分布式内核中修补它（无论出于何种原因）。这几乎让你不得不滚动你自己的内核（自己保持最新的补丁，维护你自己的包并使用 Puppet 或类似的东西将它安装在你的系统上，或者运行一个包服务器，Yum 或任何他们今天使用可以参考），或者拿你的弹珠回家。

是的，我知道拿你的弹珠回家通常是一个昂贵的提议——切换操作系统供应商是一个巨大的痛苦，尤其是在 Linux 世界中，从管理的角度来看，这些风格完全不同。
其他选择，如完全使用 CentOS，也没有吸引力（因为你失去了支持，而且你仍然获得了由其他人构建的本质上 RedHat 的代码，所以你仍然会有这个错误）。

不幸的是，除非有足够多的人（即“大公司”）带着他们的弹珠回家，否则供应商不会太在意通过发送错误代码而不修复它来搞砸人们。