XFS是我的数据和增长分区的默认文件系统,因为它提供了稳定性,可伸缩性和对默认ext3文件系统的良好性能提升.
在2012年11月浮出水面的EL6系统上存在XFS问题.我注意到我的服务器显示出异常高的系统负载,即使在空闲时也是如此.在一种情况下,卸载系统将显示恒定的平均负载3.在其他情况下,负载有一个凸起.安装的XFS文件系统的数量似乎会影响负载增加的严重性.
系统有两个活动的XFS文件系统.升级到受影响的内核后,加载为2.
深入挖掘,我发现XFS mailing list上的一些线程指出了处于STAT D状态的xfsaild进程的频率增加.相应的CentOS Bug Tracker和Red Hat Bugzilla条目概述了问题的具体细节,并得出结论认为这不是性能问题;只有在2.6.32-279.14.1.el6之前的内核中报告系统负载时出错.
WTF？！？
在一次性情况下,我理解负载报告可能不是什么大问题.尝试使用您的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,在severe performance penalty为在顶上运行的特定自定义应用有问题的应用程序在很大程度上依赖于某些XFS文件系统属性来解决应用程序设计中的缺陷.
落后于Red Hat的paywalled knowledgebase site,一个条目出现了：
High load average is observed after installing kernel
2.6.32-279.14.1.el6. The high load average is caused by xfsaild going into D state for each XFS formatted device.There is currently no resolution for this issue. It is currently being
tracked via Bugzilla #883905. Workaround Downgrade the installed
kernel package to a version lower then 2.6.32-279.14.1.
(除了降级内核不是RHEL 6.4的选项……)
因此,对于EL6.3或EL6.4 OS版本没有真正的修复计划,我们已经有4个月的时间了解这个问题.有一个针对EL6.5的建议修复和一个内核源代码补丁可用…但我的问题是：
当上游维护者破坏了一个重要特性时,在什么时候离开操作系统提供的内核和软件包是有意义的？
Red Hat介绍了这个bug.他们应该将修正结合到勘误内核中.使用企业操作系统的一个优点是它们提供了consistent and predictable platform target.这个错误中断了在补丁周期中已经在生产中的系统,并降低了部署新系统的信心.虽然我可以应用其中一个proposed patches to the source code,但这有多可扩展？随着操作系统的变化,需要保持警惕.
什么是正确的举动？
>我们知道这可能是固定的,但不是.
>在Red Hat生态系统中支持您自己的内核有其自己的一些注意事项.
>对支持资格的影响是什么？
>我是否应该在新构建的EL6.4服务器上覆盖正在运行的EL6.3内核以获得正确的XFS功能？
>我应该等到这个正式修复吗？
>这说明我们对企业Linux发布周期缺乏控制权？
>是否依赖XFS文件系统这么长的计划/设计错误？
编辑：
该补丁已纳入最新的CentOSPlus内核版本(kernel-2.6.32-358.2.1.el6.centos.plus).我在我的CentOS系统上测试它,但这对基于Red Hat的服务器没什么帮助.
解决方法
At what point does it make sense to depart from the OS-provided kernels and packages when the upstream maintainer has broken an important feature?
“在供应商的内核或软件包如此可怕地破坏以至于影响您的业务的时刻”是我的一般答案(巧合的是,这也是我认为开始寻找脱离供应商关系的方法的重要性) .
正如你和其他人所说的那样,RedHat似乎不想在他们的分布式内核中修补它(无论出于何种原因).这几乎让你不得不滚动自己的内核(自己更新补丁,维护自己的软件包并使用Puppet或类似程序在系统上安装它,或运行Yum或其他任何东西的软件包服务器)今天使用可以参考),或拿走你的弹珠和回家.
是的,我知道拿走你的弹珠并回家往往是一个昂贵的主张 – 转换操作系统供应商是一个巨大的痛苦,特别是在Linux世界中,口味与行政立场完全不同.
像完全使用CentOS这样的其他选项也没有吸引力(因为你失去了支持,你仍然得到其他人建造的RedHat代码,所以你仍然有这个bug).
不幸的是,除非有足够多的人(即“大公司”)拿走他们的弹珠并回家,否则供应商不会太在意通过运送不良代码而不是修理它来搞砸人们.
