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以后的内核中，报告系统负载中只有一个错误。
WTF？！？
在一次性情况下，我了解到负载报告可能并不重要。尝试使用您的NMS和成百上千的服务器进行管理！在EL6.3下的2012年11月内核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 OS版本计划任何真正的修复。有一个针对EL6.5的建议修复程序和一个内核源补丁可用...但是我的问题是：
当上游维护者破坏了重要功能时，在什么时候离开操作系统提供的内核和软件包是有意义的？
红帽介绍了此错误。他们应该将修复程序合并到勘误内核中。使用企业操作系统的优势之一是它们提供了一致且可预测的平台目标。此错误在补丁程序周期内破坏了已经投入生产的系统，并降低了部署新系统的信心。虽然我可以将其中一个建议的补丁应用于源代码，但它的可伸缩性如何？随着操作系统的更改，需要保持警惕以保持更新。
什么是正确的举动？
- 我们知道这可能是固定的，但不是固定的。
- 在Red Hat生态系统中支持自己的内核有其自身的警告。
- 对支持资格有什么影响？
- 我是否应该将工作正常的EL6.3内核覆盖在新建的EL6.4服务器之上以获得适当的XFS功能？
- 我应该等到这个问题正式解决吗？
- 这说明我们对企业Linux发行周期缺乏控制是什么意思？
- 长期以来一直依赖XFS文件系统进行计划/设计错误吗？
编辑：
该补丁已合并到最新的CentOSPlus内核发行版中（kernel-2.6.32-358.2.1.el6.centos.plus）。我正在CentOS系统上对此进行测试，但这对基于Red Hat的服务器没有太大帮助。