为什么我的XFS文件系统突然消耗更多的空间和稀疏文件?

我已经将XFS文件系统作为数据/增长分区在各种Linux服务器上运行了近10年。

最近CentOS / RHEL服务器运行的版本是6.2+,我注意到了一个奇怪的现象。

随着从EL6.0和EL6.1迁移到较新的操作系统版本,稳定的文件系统使用变得高度可变。 最初与EL6.2 +一起安装的系统performance出相同的行为; 在XFS分区上显示磁盘利用率的大幅波动(请参阅下图中的线)。

之前和之后。 星期六从6.1升级到6.2。 xfs图

过去一个季度的同一系统的磁盘使用情况图显示了上周的波动情况。 在这里输入图像描述

我开始检查文件系统的大文件和失控进程(日志文件,也许?)。 我发现我最大的文件报告duls不同的值。 使用和不使用--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磁盘使用(请参见上面的第一个图表中的星期三)。 但是,尽快重新启动系统活动,使用量会大增。

这里发生了什么?

    我将这个问题追溯到2010年12月关于XFS源树的提交的讨论。该补丁是在2.6.38内核中引入的(很明显,后来被引入了一些stream行的Linux发行版内核)。

    观察到的磁盘使用率波动是新function的结果; XFSdynamic投机EOF预分配 。

    这是在文件大小增加时通过推测性地分配空间来减lessstream式写入期间的文件碎片化的举措。 每个文件预先分配的空间量是dynamic的,并且主要是文件系统上可用空间的函数(以排除完全空间不足)。

    它遵循这个时间表:

     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) 

    这是对文件系统的一个有趣的补充,因为它可能有助于我处理的一些大规模碎片文件。

    通过释放pagecache,dentries和inode,可以暂时回收额外的空间:

     sync; echo 3 > /proc/sys/vm/drop_caches 

    通过在文件系统安装期间定义allocsize值,可以完全禁用该function。 XFS的默认值是allocsize=64k

    这种变化的影响可能会被监视/阈值系统感觉到(这是我如何捕获它),但也影响了数据库系统,并可能导致精简configuration的虚拟机和存储arrays出现不可预知的或不希望的结果(他们将使用比预期更多的空间)。

    总而言之,由于没有在分发级别上甚至在监视XFS邮件列表中没有明确的文件系统更改声明,所以引起了我的警惕。


    编辑
    使用此function的XFS卷的性能得到显着提高。 我看到以前显示高达50%碎片的卷在<1%碎片上一致。 写作performance在全球范围内!

    来自相同数据集的统计信息,将传统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%