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。 在这里输入图像描述

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

WTF?!?

在一次性的情况下,我明白负载报告可能不是什么大问题。 尝试使用您的NMS和数百或数千台服务器进行pipe理! 这在201211月在内核2.6.32-279.14.1.el6 EL6.3下被确定。 内核2.6.32-279.19.1.el62.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的服务器并没有什么帮助。

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

“在供应商的内核或软件包如此可怕的情况下,它们会影响到你的业务”这个问题是我的一般答案(巧合的是,这也是关于我认为开始寻求离开供应商关系的方法是有意义的) 。

基本上就像你和其他人所说的那样,RedHat似乎不想在分布式内核中修补(无论什么原因)。 这几乎让你不得不推出自己的内核(保持最新的补丁自己,维护自己的软件包,并使用Puppet或类似的方式安装在您的系统上,或运行一个软件包服务器,百胜或任何他们今天用可以参考),或者把你的弹珠拿回家。


是的,我知道把你的弹珠回家常常是一个昂贵的命题 – 切换操作系统供应商是一个巨大的痛苦,尤其是在Linux的世界里,口味与行政立场是完全不同的。
其他的选项,如完全CentOS,也是没有吸引力(因为你失去了支持,你仍然得到RedHat的其他人build立的代码,所以你仍然有这个bug)。

不幸的是,除非有足够多的人(即“大公司”)把他们的弹珠拿回家,否则供应商不会太在意通过运送不好的代码而不去修理它们。

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

如果你确实需要修补你的RHEL内核,你可以自己做,并且在那个内核上得到正式的支持,你只需要他们来certificate它。

在RHEL支持协议中有这样做的规定 – ISTR每个季度或每年限制在1到2个,但不能确定。