我注意到最近运行6.2+版本的CentOS / RHEL服务器出现了一个奇怪的现象。
从EL6.0和EL6.1迁移到较新的操作系统版本后，稳定的文件系统使用变得高度可变。最初安装有EL6.2 +的系统表现出相同的行为。显示XFS分区上磁盘利用率的剧烈波动（请参见下图中的蓝线）。
之前和之后。从6.1升级到6.2是在星期六进行的。
同一系统上一季度的磁盘使用情况图表，显示了上周的波动。 >
我开始检查文件系统中是否有大文件和失控的进程（可能是日志文件）。我发现最大的文件报告的值与
du和ls不同。使用du开关和不使用--apparent-size开关运行filefrag可以说明两者之间的区别。 # du -skh SOD0005.TXT
29G SOD0005.TXT
# du -skh --apparent-size SOD0005.TXT
21G SOD0005.TXT
文件系统中充满了稀疏文件，与先前版本的OS / kernel相比，它丢失了近70GB的空间！
我仔细研究了Red Hat Bugzilla和更改日志以查看是否有关于XFS的相同行为的报告或新公告。
Nada。
在升级过程中，我从2.6.32-131.17.1.el6内核版本升级到了2.6.32-220.23.1.el6。次要版本号没有变化。
我使用
xfs_fsr -v工具检查了文件碎片。 XFS分区上一些最大的文件具有数千个扩展区。在缓慢的活动期间使用q4312079q进行在线碎片整理有助于暂时减少磁盘使用（请参见上方第一张图表中的周三）。但是，一旦系统活动频繁恢复，使用率便迅速增加。这里发生了什么？
#1 楼
我将此问题追溯到有关从2010年12月起提交XFS源树的讨论。该修补程序是在内核2.6.38中引入的（显然，后来又移植到一些流行的Linux发行内核中）。观察到的磁盘使用波动是一项新功能的结果； XFS动态推测EOF预分配。
此举通过在文件大小增加时推测性分配空间来减少流写入期间的文件碎片。每个文件预分配的空间量是动态的，并且主要取决于文件系统上的可用空间（以防止完全用完空间）。
它遵循以下时间表：
freespace max prealloc size
>5% full extent (8GB)
4-5% 2GB (8GB >> 2)
3-4% 1GB (8GB >> 3)
2-3% 512MB (8GB >> 4)
1-2% 256MB (8GB >> 5)
<1% 128MB (8GB >> 6)
这是对文件系统的一个有趣的补充，因为它可能有助于处理我处理的一些大量碎片文件。
可以通过释放页面缓存，牙科和i节点来临时回收额外的空间，方法如下：
文件系统挂载期间的
allocsize值。 XFS的默认值为allocsize=64k。 监视/阈值系统（这就是我所捕捉到的）可能会感觉到此更改的影响，但也影响了数据库系统，可能会对精简配置的虚拟机造成不可预测或不希望的结果和存储阵列（它们将使用比您预期更多的空间）。
总而言之，这使我措手不及，因为在分发级别甚至在监视XFS邮件列表方面都没有明确宣布文件系统更改。
编辑：具有此功能的XFS卷的性能得到了极大的提高。我在以前显示高达50％碎片的卷上看到一致的<1％碎片。全局写入性能得到提高！
来自同一数据集的统计数据，将旧版XFS与EL6.3中的版本进行了比较。
新增：
sync; echo 3 > /proc/sys/vm/drop_caches
评论
一百万个投票和我的王国给你
–乔尔·萨拉斯（Joel E Salas）
2012年7月10日，0：21
谢谢！我们刚刚从Debian Squeeze升级到Ubuntu，一直想知道为什么du和ls如此大的文件显示出如此不同的值（例如50Mb vs 64Mb）
–吉尔斯·托马斯（Giles Thomas）
13年2月20日在12:38
@ewwhite您是否关闭了此功能以回收空间？还是本文只是在说，嘿，此功能是导致报告的大小不一致的原因吗？听起来像“在数据库系统或精简配置的VM上，请考虑关闭此功能”，但我不确定您最终决定做什么。
– JDS
2014年5月12日15:16
@jds我保留它。它消除了碎片，并提高了我的应用程序的性能。
–ewwhite
2014年5月12日15:35
哦，真是太好了。这在35GB的文件上使用了750GB。 xfs_fsr之后，它又减少到约35GB。我得留意一下
–user65539
15年9月15日在22:18
评论
嗯...广场...