我在工作中使用 xfs 文件系统来存储图像处理数据。目前，它有大约8.8T的可用空间。
/dev/sdh1 106T 97T 8.8T 92%
虽然计划将部分数据转移到磁带并腾出空间，但这要到下周才能实现。目前，我经常遇到“设备上没有剩余空间”错误。
通常传输的图像大小约为 128mb，每次传输的图像数量约为 100-500 个。
文件系统是否有任何特定因素导致这大约 8TB 的可用空间无法使用？
就我而言，我能够使用该命令来验证我是否可以使用至少 8TB 的空间fallocate来创建大约 TB 的非常大的文件。
我缺少什么？我需要做任何明显的文件系统级别检查吗？
xfs_info以下是文件系统命令的输出，供您参考。
meta-data=/dev/sdh1 isize=256 agcount=106, agsize=268435455 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=28319810304, imaxpct=1
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
为了重现相同的错误，我编写了一个简单的 shell 脚本，该脚本创建大量文件（10k）小文件（大小为 1M），但失败并出现以下错误：
fallocate: temfile-7464: open failed: No space left on device
df -i这是运行脚本之前的输出
/dev/sdh1 4531169600 648793 4530520807 1% /jumbo/K2LEGINON
之后
/dev/sdh1 4531169600 656256 4530513344 1% /jumbo/K2LEGINON
创建大约 7500 个文件后失败。总计约 7.3G。
答案1
感谢评论中的回复，我能够确定问题与 XFS 文件系统相关。
本质上，文件系统已经耗尽了用于创建 inode 的可用空间。 XFS 文件系统似乎正在使用磁盘的第一个 TB 来执行此操作。
答案2
对于已经运行 inode64 的文件系统，如果文件系统磁盘空间不足/不足，或者无法为其他 inode 分配 4 个连续块，则可能会遇到此错误。因此，如果文件系统严重碎片化（意味着只有 1-3 个块在一起），您将无法创建新文件，但可以将附加数据写入旧文件。
有关识别可用空间碎片程度的更多信息，请参阅 TID 7014320 - 如何判断 XFS 文件系统上可用空间的碎片程度
如果您的文件系统碎片严重，您可以： 添加大量可用空间（即 20% 或更多） 将数据移动到不同的文件系统，然后将其复制回来。这将删除文件之间的空闲块并使其连续。您会发现这对于存储 <= 4,096 字节的文件的文件系统最有帮助。