在上面的一个回答中，有人建议会话是inode耗尽的原因，在我们的例子中正是如此。为了补充这个答案，我建议检查php.ini文件并确保session。Gc_probability = 1也是session。gc_除数= 1000和 会话。Gc_maxlifetime = 1440。在我们的案例会议上。Gc_probability等于0，导致了这个问题。

即使磁盘不是很满，也很容易在磁盘上使用大量的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_$$

迟到的回答: 对我来说，是我的会话文件

/var/lib/php/sessions

使用Inodes的。 我甚至无法打开crontab或创建新目录，更不用说触发删除操作了。 因为我使用PHP，所以在本指南中，我复制了示例1中的代码，并设置了cronjob来执行这部分代码。

<?php
// Note: This script should be executed by the same user of web server 
process.

// Need active session to initialize session data storage access.
session_start();

// Executes GC immediately
session_gc();

// Clean up session ID created by session_gc()
session_destroy();
?>

如果您想知道我是如何打开crontab的，那么好吧，我通过CLI手动删除了一些会话。

希望这能有所帮助!

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

当df -i说100% Inode使用;

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

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

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

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

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

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

rm -rf /var/cache/eaccelerator/*

(或者你的缓存目录)