如何释放 Inode 使用量？

问题描述：

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

那么正确的做法是什么？

为什么磁盘空间使用率较低的磁盘驱动器的 Inode 使用率会比磁盘空间使用率较高的磁盘驱动器高呢？

如果我压缩大量文件，是否可以减少使用的inode数量？

解决方案 1：

如果你运气不好，已经使用了大约 100% 的所有 inode，并且无法创建脚本。你可以使用 来检查这一点df -ih。

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

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

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

解决方案 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_$$

解决方案 3：

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

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

我使用的是 ubuntu 12.04LTS，无法删除旧的 Linux 内核，因为 apt 因缺少软件包而损坏，占用了大约 400,000 个 inode。而且我无法安装新软件包，因为 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% /

解决方案 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

这解决了我的问题。

解决方案 5：

我遇到了同样的问题，通过删除 php 的目录会话解决了这个问题

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

/var/lib/php5如果您使用的是旧版 php则可能位于下方。

使用以下权限重新创建它

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

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

解决方案 6：

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

解决方案 7：

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

rsync -a --delete blanktest/ test/

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

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

解决方案 8：

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

/usr/local/cpanel/bin/purge_dead_comet_files

解决方案 9：

迟来的回答：就我而言，这是我的会话文件

/var/lib/php/sessions

使用 Inode。

我甚至无法打开 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 手动删除了一些会话。

希望这有帮助！

解决方案 10：

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

解决方案 11：

eaccelerator 可能会造成问题，因为它会将 PHP 编译为块...我曾经在一个负载很大的网站上使用 Amazon AWS 服务器时遇到过这个问题。如果问题仍然存在，请删除 /var/cache/eaccelerator 中的 eaccelerator 缓存以释放 Inode。

rm -rf /var/cache/eaccelerator/*

（或者你的缓存目录）

解决方案 12：

我们最近遇到了类似的问题，如果某个进程引用了已删除的文件，则 Inode 将不会被释放，因此您需要检查 lsof /，然后 kill/ 重新启动该进程以释放 Inode。

如果我错了请纠正我。

解决方案 13：

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

解决方案 14：

在上面的一个答案中，有人认为会话是导致 inode 耗尽的原因，而在我们的案例中，情况确实如此。不过，为了补充这个答案，我建议检查 php.ini 文件并确保session.gc_probability = 1和session.gc_divisor = 1000。
session.gc_maxlifetime = 1440在我们的案例中，session.gc_probability 等于 0，导致了这个问题。

解决方案 15：

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

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

解决方案 16：

你可以看到这个信息

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

解决方案 17：

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

当df -i显示 100% Inode 使用率时；

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

它将允许您创建的容器（运行或退出），但将删除所有不再引用的图像，释放一大堆 inode；我从 100％ 回到了 18％！

也许还值得一提的是，我在这台机器上使用了很多 CI/CD 和设置了 docker runner 的设备。

解决方案 18：

它可能是/tmp文件夹（存储所有临时文件的地方，例如 yarn 和 npm 脚本执行，特别是如果你正在启动大量节点脚本）。所以通常情况下，你只需要重新启动你的设备或服务器，它就会删除所有你不需要的临时文件。对我来说，我的使用率从 100% 下降到了 23%！

解决方案 19：

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

解决方案 20：

在某些情况下，运行 sudo apt-get autoremove 命令会起作用。如果存在以前未使用的标头数据，则会清除这些数据。

解决方案 21：

如果您使用 docker，请删除所有图像。它们占用了大量空间……

停止所有容器

docker stop $(docker ps -a -q)

删除所有容器

docker rm $(docker ps -a -q)

删除所有图像

docker rmi $(docker images -q)

对我有用