我已经跑了XFS 文件系统作为各种 Linux 服务器上的数据/增长分区已有近 10 年的历史。
我注意到最近运行 6.2+ 版本的 CentOS/RHEL 服务器出现了一个奇怪的现象。
从 EL6.0 和 EL6.1 迁移到较新的操作系统版本后，稳定文件系统的使用情况变得高度不稳定。最初安装 EL6.2+ 的系统表现出相同的行为；XFS 分区上的磁盘利用率出现剧烈波动（请参阅蓝色的下图中的线）。
前后对比。从 6.1 升级到 6.2 是在星期六。
同一系统过去一个季度的磁盘使用情况图表，显示了过去一周的波动。
我开始检查文件系统中的大文件和失控进程（可能是日志文件？）。我发现我最大的文件报告的值与du和不同ls。du使用和不使用--apparent-size开关运行可以说明差异。
# 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
文件系统充满了稀疏文件，与以前版本的操作系统/内核相比，损失了近70GB的空间！
我仔细阅读了红帽 Bugzilla并更改日志以查看是否有有关相同行为的报告或有关 XFS 的新公告。
没什么。
我从内核版本2.6.32-131.17.1.el6到2.6.32-220.23.1.el6在升级过程中；次版本号没有变化。
我使用该filefrag工具检查了文件碎片。XFS 分区上的一些最大文件有数千个区。xfs_fsr -v在活动较少的时段运行在线碎片整理有助于暂时减少磁盘使用量（参见上面第一张图中的星期三）。但是，一旦系统活动恢复繁忙，使用量就会激增。
这里发生了什么事？
答案1
我将这个问题追溯到关于提交的讨论XFS 源代码树从 2010 年 12 月开始。该补丁在内核 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)
这是对文件系统的一个有趣的补充，因为它可能有助于我处理一些大量碎片的文件。
可以通过释放页面缓存、目录项和 inode 来临时回收额外的空间：
sync; echo 3 > /proc/sys/vm/drop_caches
通过在文件系统挂载期间定义一个值可以完全禁用该功能allocsize。XFS 的默认值为allocsize=64k。
这种变化的影响可能会被监控/阈值系统感受到（我就是这样发现它的），但也影响了数据库系统并可能导致精简配置的虚拟机和存储阵列出现不可预测或不良的结果（它们将使用比您预期更多的空间）。
总而言之，这让我措手不及，因为在发行版层面甚至在监控方面都没有明确宣布文件系统的变化。XFS 邮件列表。
编辑：
使用此功能后，XFS 卷的性能得到了显著改善。我发现卷上的碎片率始终低于 1%，而之前碎片率最高可达 50%。写入性能全面提升！
来自同一数据集的统计数据，将旧版 XFS 与 EL6.3 中的版本进行比较。
老的：
# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%
新的：
# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%