XFS文件系统在RHEL / CentOS 6.x中被破解 – 我能做些什么？

最近版本的RHEL / CentOS（EL6）为我十年来所依赖的XFS文件系统带来了一些有趣的变化。 我花了去年夏天的一部分时间来追查一个XFS稀疏文件的情况，这是由于文档logging不完善的内核backport造成的。 自从转到EL6以来，其他人有不幸的performance问题或不一致的行为 。

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

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

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

• 在Linux上存储和备份1000万个文件
• 如果它被移动/复制到同一个卷中的另一个目录，则从父文件夹inheritance
• 分布式存储文件系统 – 哪一个/有没有准备使用的产品？
• 文件系统可以包含的最大文件数是多less？
• 最好的方法来比较（差异）一个完整的目录结构？

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

WTF？！？

在一次性的情况下，我明白负载报告可能不是什么大问题。 尝试使用您的NMS和数百或数千台服务器进行pipe理！ 这在2012年11月在内核2.6.32-279.14.1.el6 EL6.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上 ，它performance出相同的行为。

我有一个新的系统构build队列，必须解决这个问题，要么在2012年11月发布的EL6.3版本上locking内核版本，要么只是不使用XFS，selectext4或ZFS ， 严重的性能损失针对运行在顶层的特定自定义应用程序。 所涉及的应用程序在很大程度上依赖于某些XFS文件系统属性来解决应用程序devise中的缺陷。

在红帽支付知识库网站的背后，出现了一个条目：

安装内核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操作系统版本并没有真正的解决scheme。 有一个build议修复EL6.5和内核源补丁可用…但我的问题是：

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

红帽引入了这个错误。 他们应该把修复join到勘误内核中。 使用企业操作系统的优势之一是它们提供了一致和可预测的平台目标 。 这个bug破坏了补丁周期中已经投入使用的系统，降低了部署新系统的可信度。 虽然我可以将其中一个build议的修补程序应用到源代码 ，那么可扩展性如何？ 随着操作系统的变化，需要保持警惕。

什么是正确的举动？

• 我们知道这可能是固定的，但不是什么时候。
• 在红帽生态系统中支持你自己的内核有它自己的一些注意事项。
• 对支持资格有什么影响？
• 我应该只在新build的EL6.4服务器上覆盖一个工作的EL6.3内核，以获得正确的XFSfunction吗？
• 我应该等待，直到这个正式固定？
• 这对于我们对企业Linux发行周期缺乏控制的说法是什么？
• 依靠一个XFS文件系统长时间的计划/devise错误？

编辑：

这个补丁包含在最新的CentOSPlus内核版本（ kernel-2.6.32-358.2.1.el6.centos.plus ）中。 我在我的CentOS系统上testing了这个function，但是这对于基于Red Hat的服务器并没有什么帮助。