RHEL/CentOS（EL6）的最新版本对XFS 文件系统我依赖沉重十多年来。去年夏天我花了一部分时间寻找XFS 稀疏文件情况内核反向移植记录不全。其他人则不幸的性能问题或者行为不一致自从迁移到 EL6 以来。
XFS 是我的数据和增长分区的默认文件系统，因为它比默认的 ext3 文件系统提供了稳定性、可扩展性和良好的性能提升。
2012 年 11 月，EL6 系统上的 XFS 出现了一个问题。我注意到我的服务器即使在空闲时也显示出异常高的系统负载。在一个案例中，一个未加载的系统会显示恒定的平均负载为 3+。在其他情况下，负载会增加 1+。安装的 XFS 文件系统的数量似乎会影响负载增加的严重程度。
系统有两个活动的 XFS 文件系统。升级到受影响的内核后，负载 +2。
深入挖掘后，我发现了一些关于XFS 邮件列表这表明xfsaild坐在那里的频率增加了统计D状态。相应的CentOS 错误追踪和红帽 Bugzilla条目概述了问题的具体情况，并得出结论，这不是性能问题；只是在较新的内核中报告系统负载时出现错误2.6.32-279.14.1.el6。
什么鬼？！？
在一次性情况下，我知道负载报告可能不是什么大问题。尝试使用您的 NMS 和数百或数千台服务器来管理它！这是在2012 年 11 月在内核2.6.32-279.14.1.el6EL6.3 下。内核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或者虚拟文件系统，在严重的绩效损失针对在其上运行的特定自定义应用程序。所讨论的应用程序严重依赖某些 XFS 文件系统属性来弥补应用程序设计中的缺陷。
了解 Red Hat 的付费知识库网站，出现一条条目，指出：
安装内核 2.6.32-279.14.1.el6 后，发现平均负载较高。平均负载较高是由于 xfsaild 在每个 XFS 格式化设备上进入 D 状态所致。
目前该问题尚无解决方案。目前正在通过 Bugzilla #883905 进行跟踪。解决方法将已安装的内核包降级到低于 2.6.32-279.14.1 的版本。
（除了降级内核在 RHEL 6.4 上不是一个选项......）
因此，我们已经陷入这个问题 4 个多月了，但还没有针对 EL6.3 或 EL6.4 OS 版本进行真正的修复。有一个针对 EL6.5 的建议修复和一个可用的内核源补丁……但我的问题是：
当上游维护者破坏了某个重要功能时，什么时候脱离操作系统提供的内核和软件包才有意义？
Red Hat 引入了这个错误。他们应该将修复程序合并到勘误内核中。使用企业操作系统的优点之一是它们提供了一致且可预测的平台目标。此错误在补丁周期内破坏了已在生产中的系统，并降低了部署新系统的信心。虽然我可以应用其中一个对源代码提出的补丁，它的可扩展性如何？随着操作系统的变化，需要保持一定的警惕性才能保持更新。
此时正确的做法是什么？
- 我们知道这个问题可能会被修复，但不知道什么时候能修复。
- 在 Red Hat 生态系统中支持自己的内核有其自身的一系列注意事项。
- 这对支持资格有何影响？
- 我是否应该将可运行的 EL6.3 内核覆盖在新建的 EL6.4 服务器上以获得正确的 XFS 功能？
- 我是不是应该等到官方修复这个问题？
- 这说明我们对于企业 Linux 发布周期缺乏控制吗？
- 长期依赖 XFS 文件系统是否是一个规划/设计错误？
编辑：
此补丁已纳入最新的CentOSPlus内核版本（内核-2.6.32-358.2.1.el6.centos.plus）。我正在我的 CentOS 系统上测试这个，但这对基于 Red Hat 的服务器没有太大帮助。
答案1
当上游维护者破坏了某个重要功能时，什么时候脱离操作系统提供的内核和软件包才有意义？
“当供应商的内核或软件包出现严重问题，对您的业务造成影响时”是我的一般回答（巧合的是，这也是我认为开始寻找摆脱供应商关系的方法有意义的时候）。
基本上，正如您和其他人所说的，RedHat 似乎不想在他们的分布式内核中修补这个问题（无论出于什么原因）。这几乎让您陷入必须推出自己的内核（自己更新补丁，维护自己的软件包并使用 Puppet 或类似程序将其安装在您的系统上，或者运行 Yum 或他们现在使用的任何东西可以引用的软件包服务器），或者带着您的弹珠回家。
是的，我知道带着你的大理石回家通常是一个昂贵的提议——更换操作系统供应商是一件非常痛苦的事情，特别是在 Linux 世界，从管理的角度来看，各种操作系统的风格截然不同。
其他选择，比如完全使用 CentOS，也是没有吸引力（因为你失去了支持，而且你仍然得到其他人编写的 RedHat 代码，所以你仍然会遇到这个错误）。
不幸的是，除非有足够多的人（即“大公司”）带着他们的弹珠回家，否则供应商不会太在意通过发送坏代码而不去修复它而欺骗人们。
答案2
此问题已修复（悄悄) 由 Red Hat 于 2013 年 4 月 23 日发表于RHEL 内核-2.6.32-358.6.1.el6作为 6.4 勘误表更新的一部分...
答案3
如果你确实需要修补你的 RHEL 内核，你可以能自己动手，并获得官方支持那内核，你只需要他们来认证它。
RHEL 支持协议中有相关规定 - ISTR 您每季度或每年只能使用 1 或 2 次，但我记不清了。