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

eww*_*ite 65 linux xfs filesystems redhat centos

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

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

从 EL6.0 和 EL6.1 迁移到较新的操作系统版本后,稳定的文件系统使用变得高度可变。最初安装 EL6.2+ 的系统表现出相同的行为;显示 XFS 分区上磁盘利用率的剧烈波动(请参见下图中的线)。

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

同一系统上一季度的磁盘使用图,显示了上周的波动情况。 在此处输入图片说明

我开始检查文件系统中是否有大文件和失控进程(可能是日志文件?)。我发现我最大的文件报告的值与du和不同lsdu使用和不使用--apparent-size开关运行说明了差异。

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT
Run Code Online (Sandbox Code Playgroud)

在整个文件系统中使用ncdu 实用程序进行快速检查,结果如下:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258
Run Code Online (Sandbox Code Playgroud)

文件系统充满了稀疏文件,与之前版本的操作系统/内核相比,损失了近 70GB 的空间!

我仔细阅读了Red Hat Bugzilla并更改了日志,以查看是否有任何关于 XFS 的相同行为或新公告的报告。

纳达。

我在升级过程中从内核版本2.6.32-131.17.1.el62.6.32-220.23.1.el6;次要版本号没有变化。

我使用该filefrag工具检查了文件碎片。XFS 分区上的一些最大文件有数千个区。在xfs_fsr -v活动缓慢期间运行在线碎片整理有助于暂时减少磁盘使用量(参见上面第一张图中的星期三)。然而,一旦繁重的系统活动恢复,使用量就会激增。

这里发生了什么?

eww*_*ite 79

我将这个问题追溯到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)
Run Code Online (Sandbox Code Playgroud)

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

额外的空间可以通过释放 pagecache、dentries 和 inode 来临时回收:

sync; echo 3 > /proc/sys/vm/drop_caches
Run Code Online (Sandbox Code Playgroud)

通过allocsize在文件系统挂载期间定义一个值,可以完全禁用该功能。XFS 的默认值是allocsize=64k.

监控/阈值系统可能会感受到这种变化的影响(这就是我发现它的方式),但也影响了数据库系统,并可能对精简配置的虚拟机和存储阵列(他们将使用比您预期的更多空间)。

总而言之,它让我措手不及,因为在分发级别甚至在监视XFS 邮件列表中都没有明确宣布文件系统更改。


编辑
具有此功能的 XFS 卷的性能得到显着提高。我在之前显示高达 50% 碎片的卷上看到一致的 < 1% 碎片。写入性能在全球范围内上升!

来自同一数据集的统计数据,将旧版 XFS 与 EL6.3 中的版本进行比较。

老的:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%
Run Code Online (Sandbox Code Playgroud)

新的:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%
Run Code Online (Sandbox Code Playgroud)

  • 一百万个赞和我的王国给你 (4认同)
  • 哦,美妙的发现。这是在 35GB 的文件上使用 750GB。在 ```xfs_fsr``` 之后它又回到了大约 35GB。我得留意那个 (3认同)
  • @jds 我保持打开状态。它消除了碎片并提高了我的应用程序的性能。 (2认同)