这篇文章拯救了我: https://bewilderedoctothorpe.net/2018/12/21/out-of-inodes/

find . -maxdepth 1 -type d | grep -v '^\.$' | xargs -n 1 -i{} find {} -xdev -type f | cut -d "/" -f 2 | uniq -c | sort -n

我们最近遇到了类似的问题，如果一个进程指向一个被删除的文件，Inode不会被释放，所以你需要检查lsof /， kill/ restart进程会释放Inode。

如果我说错了，请指正。

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

在一次垃圾邮件攻击后，我们在一个HostGator帐户(他对所有主机都设置了inode限制)上遇到过这种情况。它在/root/.cpanel/comet中留下了大量队列记录。如果发生这种情况，你发现你没有空闲的inode，你可以通过shell运行这个cpanel实用程序:

/usr/local/cpanel/bin/purge_dead_comet_files

这篇文章拯救了我: https://bewilderedoctothorpe.net/2018/12/21/out-of-inodes/

find . -maxdepth 1 -type d | grep -v '^\.$' | xargs -n 1 -i{} find {} -xdev -type f | cut -d "/" -f 2 | uniq -c | sort -n

即使磁盘不是很满，也很容易在磁盘上使用大量的inode。

inode被分配给一个文件，因此，如果您有无数个文件，每个文件都是1个字节，那么在耗尽磁盘之前，您就会耗尽inode。

如果文件有多个硬链接，删除文件也可能不会减少inode计数。正如我所说，inode属于文件，而不是目录条目。如果一个文件有两个目录条目链接到它，删除一个不会释放inode。

此外，您可以删除目录条目，但如果正在运行的进程仍然打开该文件，则不会释放inode。

我最初的建议是尽可能删除所有文件，然后重新启动计算机，以确保没有进程保留这些文件。

如果你这样做，你仍然有问题，让我们知道。

顺便说一下，如果你正在寻找包含大量文件的目录，这个脚本可能会有帮助:

#!/bin/bash

# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -mount -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$