到目前为止，这个问题有很多答案，上面所有的答案似乎都是具体的。我认为你使用stat是安全的，但根据操作系统的不同，你可能会遇到一些inode错误。因此，使用64位来实现自己的统计调用功能以避免任何溢出问题似乎是相当兼容的。

如前所述，如果有很多小文件，文件系统可能会耗尽inode。我提供了一些方法来查找这里包含大多数文件的目录。

eaccelerator可能会导致这个问题，因为它将PHP编译成块…我在一个负载很重的网站上使用亚马逊AWS服务器时遇到过这个问题。如果您仍然有问题，可以通过删除/var/cache/eaccelerator中的eaccelerator缓存来释放Inodes。

rm -rf /var/cache/eaccelerator/*

(或者你的缓存目录)

首先，获取inode存储使用情况:

df -i

下一步就是找到那些文件。为此，我们可以使用一个小脚本列出目录和其中的文件数量。

for i in /*; do echo $i; find $i |wc -l; done

从输出中，您可以看到使用大量文件的目录，然后对该目录重复此脚本，如下所示。重复该操作，直到看到可疑目录。

for i in /home/*; do echo $i; find $i |wc -l; done

当您发现有大量不需要的文件的可疑目录时。只需删除该目录上不需要的文件，并通过以下命令释放一些inode空间。

rm -rf /home/bad_user/directory_with_lots_of_empty_files

你已经成功地解决了这个问题。现在再次使用df -i命令检查inode的使用情况，您可以看到如下的差异。

df -i

在树莓派上，我在/var/cache/fontconfig目录下有大量文件时遇到了问题。取出它花了一个多小时。当然还有rm -rf *。cache* raise参数列表过长错误。我用的是下面的

find . -name '*.cache*' | xargs rm -f

对于那些使用Docker并最终来到这里的人，

当df -i说100% Inode使用;

只需运行docker rmi $(docker images -q)

它会让你创建的容器(运行或退出)，但会删除所有不再引用的图像，释放一大堆索引节点;我从100%回到了18%

值得一提的是，我在这台机器上使用了大量的CI/CD和docker运行程序。