最近版本的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理！ 这在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立一个〜16TB的存储服务器。 目前，我们正在考虑将ZFS和XFS作为文件系统。 有什么优点和缺点？ 我们需要寻找什么？ 有第三个更好的select吗？
我已经将XFS文件系统作为数据/增长分区在各种Linux服务器上运行了近10年。 最近CentOS / RHEL服务器运行的版本是6.2+，我注意到了一个奇怪的现象。 随着从EL6.0和EL6.1迁移到较新的操作系统版本，稳定的文件系统使用变得高度可变。 最初与EL6.2 +一起安装的系统performance出相同的行为; 在XFS分区上显示磁盘利用率的大幅波动（请参阅下图中的蓝线）。 之前和之后。 星期六从6.1升级到6.2。 过去一个季度的同一系统的磁盘使用情况图显示了上周的波动情况。 我开始检查文件系统的大文件和失控进程（日志文件，也许？）。 我发现我最大的文件报告du和ls不同的值。 使用和不使用–apparent-size开关的du运行说明了不同之处。 # du -skh SOD0005.TXT 29G SOD0005.TXT # du -skh –apparent-size SOD0005.TXT 21G SOD0005.TXT 在整个文件系统中使用ncdu实用程序进行快速检查，结果如下： Total disk usage: 436.8GiB Apparent size: 365.2GiB Items: 863258 文件系统中充满了稀疏的文件 ，与之前版本的OS /内核相比，有将近70GB的空间丢失！ 我通过红帽Bugzilla进行了更新，并更改了日志，以查看是否有任何有关XFS的相同行为或新通告的报告。 纳达。 在升级过程中，我从内核版本2.6.32-131.17.1.el6升级到2.6.32-220.23.1.el6 ; 次版本号没有变化。 我用filefrag工具检查了文件碎片。 一些XFS分区上最大的文件有数千个扩展盘区。 在缓慢的活动期间使用xfs_fsr -v在线碎片整理运行帮助暂时减less磁盘使用（请参见上面的第一个图表中的星期三）。 但是，尽快重新启动系统活动，使用量会大增。 这里发生了什么？