如何释放 Inode 使用量？答案

【问题标题】：How to Free Inode Usage?如何释放 Inode 使用量？
【发布时间】：2010-10-13 18:39:57
【问题描述】：

我有一个 inode 使用率为 100% 的磁盘驱动器（使用 df -i 命令）。但是在大量删除文件后，使用率仍然是 100%。

那么正确的做法是什么？

磁盘空间使用量较少的磁盘驱动器怎么可能有 Inode 使用率高于磁盘空间使用率更高的磁盘驱动器？

如果我压缩大量文件是否会减少使用的inode 计数？

【问题讨论】：

这道题想给你50分。我能怎么做！ :)
@Sophy 不要那样做。你会被自动封禁
@StevenLu 感谢您的信息！我想感谢他，因为我花了几天时间来解决我的问题。但是这个问题可以帮助我。再次感谢，
@Sophy：为什么要为 SO 奖励一些离题的东西？ :) 这绝对不是一个编程问题，不管它得到多少赞成票。
空目录也会消耗 inode。删除它们可以释放一些 inode。在某些用例中，这个数字可能很大。您可以使用以下命令删除空目录： find 。 -type d -empty -delete

标签： linux unix memory-management inode

【解决方案1】：

如果你很不走运，你已经使用了大约 100% 的 inode 并且无法创建 scipt。您可以通过df -ih 进行检查。

那么这个 bash 命令可能会对你有所帮助：

sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

是的，这需要时间，但您可以找到文件最多的目录。

【讨论】：

就行了。我的问题是在 /lib/php/sessions 目录中有大量的会话。也许有人有同样的问题
有人应该将这个 find、cut、uniq 排序重写为一个 awk 命令！
@alxndr awk 可以保留目录的哈希值和文件数，而无需对大量行进行唯一化和排序。也就是说，也许这里有一个改进：find . -maxdepth 1 -type d | grep -v '^\.$' | xargs -n 1 -i{} find {} -xdev -type f | cut -d "/" -f 2 | uniq -c | sort -n——这只对最后一个列表进行排序。
如果你不能创建任何文件，即使那个可能会失败 因为sort 可能无法将所有内容保存在内存中，并会尝试自动回退到写入临时文件.一个显然会失败的过程......
sort 对我来说失败了，但我能够提供 --buffer-size=10G ，它有效。

【解决方案2】：

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

【讨论】：

当然，>/tmp/count_em_$$ 只有在你有空间的情况下才能工作......如果是这样，请参阅@simon 的答案。
@alxndr，这就是为什么将您的文件系统分开通常是一个好主意 - 这样，填充像 /tmp 这样的东西不会影响您的其他文件系统。
您的回答非常适合“如果该文件被删除，系统将不会在重新启动后继续使用该文件”。但是问题是“删除inode指针后如何回收或重用inode？”。基本上linux内核在创建文件时都会为文件创建一个新的inode，并且在您删除文件时也不会自动回收inode。
@AshishKarpe，我假设您在谈论您的 自己的 情况，因为 OP 没有提及生产服务器。如果您不能立即重新启动，那么有两种可能性。首先，希望运行中的进程最终关闭当前文件，以便释放磁盘资源。其次，即使是生产服务器也应该在某个时候有重新启动的空间——只需安排一些计划的停机时间或等待下一个停机时间窗口出现。
我想你想要ls -A 而不是ls -a。为什么要数。和..？

【解决方案3】：

我的情况是我的 inode 用完了，我已经删除了我能删除的所有内容。

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361     11  100% /

我使用的是 ubuntu 12.04LTS，无法删除占用大约 400,000 个 inode 的旧 linux 内核，因为 apt 由于缺少软件包而损坏。而且我无法安装新软件包，因为我没有 inode，所以我被卡住了。

我最终手动删除了一些旧的 linux 内核以释放大约 10,000 个 inode

$ sudo rm -rf /usr/src/linux-headers-3.2.0-2*

这足以让我安装丢失的包并修复我的 apt

$ sudo apt-get install linux-headers-3.2.0-76-generic-pae

然后使用 apt 删除剩余的旧 linux 内核

$ sudo apt-get autoremove

现在好多了

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361 434719   54% /

【讨论】：

这是在类似情况下最接近我自己的方法。值得注意的是，在help.ubuntu.com/community/Lubuntu/Documentation/… 上记录了更谨慎的方法
完全是我的情况！但必须使用“sudo apt-get autoremove -f”才能进步
这样做安全吗：sudo rm -rf /usr/src/linux-headers-3.2.0-2*，如果我确定我没有使用那个内核？
@MarsLee 您可以使用“uname -a”检查当前正在运行的内核
单独打电话给$ sudo apt-get autoremove，对我有用。

【解决方案4】：

我的解决方案：

尝试找出这是否是 inode 问题：

df -ih

尝试查找具有大量 inode 数的根文件夹：

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

尝试查找特定文件夹：

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

如果这是 linux 头文件，请尝试删除最旧的：

sudo apt-get autoremove linux-headers-3.13.0-24

我个人将它们移动到一个已安装的文件夹（因为对我来说最后一个命令失败）并安装了最新的：

sudo apt-get autoremove -f

这解决了我的问题。

【讨论】：

就我而言，问题是SpamAssasin-Temp。 find /var/spool/MailScanner/incoming/SpamAssassin-Temp -mtime +1 -print | xargs rm -f 完成了这项工作 :) 谢谢！
对我来说，这需要几个小时。但是，有一个简单的解决方案：当第二个命令挂在特定目录上时，终止当前命令并重新将 /* 更改为它挂起的任何目录。我能够深入了解罪魁祸首
我使用了你的命令的这个变体，以便在同一行打印数字：for i in /usr/src/*; do echo -en "$i\t"; find $i 2>/dev/null |wc -l; done
for i in /src/*; do echo "$i, `find $i |wc -l`"; done|sort -nrk 2|head -10 展示前 10 个最大的目录

【解决方案5】：

我有同样的问题，通过删除 php 的目录会话来解决它

rm -rf /var/lib/php/sessions/

如果您使用的是较旧的 php 版本，它可能在 /var/lib/php5 下。

使用以下权限重新创建它

mkdir /var/lib/php/sessions/ && chmod 1733 /var/lib/php/sessions/

Debian 上目录的默认权限显示为drwx-wx-wt (1733)

【讨论】：

知道为什么会这样吗？
@Sibidharan 在我的情况下是因为清除旧 PHP 会话的 PHP cron 作业不起作用。
rm -rf /var/lib/php/sessions/* 可能是一个更好的命令 - 它不会删除会话目录，只是删除它的内容......然后你不必担心重新创建它
我没有 php 会话但 magento 会话问题，类似于此。感谢您的指导。
php 会话不应通过 cron 作业清除，请在 php.ini 中设置 session.gc_maxlifetime php.net/manual/en/…

【解决方案6】：

在遭到垃圾邮件攻击后，我们在 HostGator 帐户（对所有主机设置了 inode 限制）上遇到了这种情况。它在 /root/.cpanel/comet 中留下了大量的队列记录。如果发生这种情况并且您发现没有可用的 inode，您可以通过 shell 运行此 cpanel 实用程序：

/usr/local/cpanel/bin/purge_dead_comet_files

【讨论】：

【解决方案7】：

您可以使用 RSYNC 删除大量文件

rsync -a --delete blanktest/ test/

创建包含 0 个文件的空白测试文件夹，命令将同步您的测试文件夹和大量文件（我使用此方法删除了近 500 万个文件）。

感谢http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux

【讨论】：

从文章/cmets 中我可以看出，由于扩展通配符和传递/处理每个参数，这比 rm * 快很多文件，但 rm test/ 很好删除包含大量文件的test/ 文件夹。
请注意，这很好用，但请确保您在空白目录上正确设置了权限！我没有这样做，并且无意中更改了我的 PHP 会话目录的权限。花了两个小时才弄清楚我搞砸了什么。

【解决方案8】：

迟到的答案：就我而言，这是我在

下的会话文件

/var/lib/php/sessions

正在使用 Inode。
我什至无法打开我的 crontab 或创建新目录，更不用说触发删除操作了。由于我使用 PHP，我们有这个 guide，我从示例 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 手动删除了一些会话。

希望这会有所帮助！

【讨论】：

【解决方案9】：

eaccelerator 可能会导致问题，因为它将 PHP 编译成块...我在负载重的站点上的 Amazon AWS 服务器上遇到了这个问题。如果您仍然遇到问题，请通过删除 /var/cache/eaccelerator 中的 eaccelerator 缓存来释放 Inode。

rm -rf /var/cache/eaccelerator/*

（或任何你的缓存目录）

【讨论】：

【解决方案10】：

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

如果这里有错误，请纠正我。

【讨论】：

【解决方案11】：

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

【讨论】：

【解决方案12】：

在上述答案之一中，有人认为会话是导致 inode 用完的原因，在我们的例子中，情况正是如此。为了增加这个答案，我建议检查 php.ini 文件并确保 session.gc_probability = 1 和 session.gc_divisor = 1000 和 session.gc_maxlifetime = 1440。在我们的例子中 session.gc_probability 等于 0 并导致了这个问题。

【讨论】：

【解决方案13】：

这篇文章拯救了我的一天： 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

【讨论】：

我不知道为什么甚至不考虑这个解决方案！你拯救了我的一天！

【解决方案14】：

在 Raspberry Pi 上，/var/cache/fontconfig 目录存在大量文件问题。删除它花了一个多小时。当然rm -rf *.cache* 引发Argument list too long 错误。我用过以下一个

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

【讨论】：

【解决方案15】：

你可以看到这个信息

for i in /var/run/*;do echo -n "$i "; find $i| wc -l;done | column -t

【讨论】：

【解决方案16】：

首先，获取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

【讨论】：

【解决方案17】：

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

【讨论】：

我们喜欢这里的例子 ;)

【解决方案18】：

如果您使用 docker，请删除所有图像。他们使用了很多空间......

停止所有容器

docker stop $(docker ps -a -q)

删除所有容器

docker rm $(docker ps -a -q)

删除所有图片

docker rmi $(docker images -q)

对我有用

【讨论】：

这无助于检测“inode 太多”是否是问题所在。
这与Docker无关。
@Urda 我在带有 9 个容器的 VM Ubuntu 18.04 上遇到了类似的问题。关闭所有容器后（一次超时），df -i 返回 86%，重新启动 5 个主容器（用于生产）后，再次 df -i，返回 13%！