我有一个磁盘驱动器，其中 inode 使用率为 100%（使用df -i命令）。但是在大量删除文件后，使用率仍然是 100%。
那么正确的方法是什么？
磁盘空间使用率较低的磁盘驱动器怎么可能比磁盘空间使用率较高的磁盘驱动器具有更高的 Inode 使用率？
如果我压缩大量文件会减少使用inode次数，是否有可能？
foolishbrat
问问题
579879 次
18 回答
230
如果你很不走运，你已经使用了大约 100% 的所有 inode 并且无法创建 scipt。您可以使用df -ih.
那么这个 bash 命令可以帮助你：
sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n
是的，这需要时间，但您可以找到文件最多的目录。
于 2012-02-22T00:22:45.557 回答
185
即使磁盘不是很满，磁盘也很容易使用大量 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_$$
于 2009-03-17T06:22:42.797 回答
77
我的情况是我的 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% /
于 2015-11-06T08:46:37.380 回答
58
我的解决方案：
尝试查找这是否是 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
这解决了我的问题。
于 2014-12-12T16:56:45.697 回答
14
我有同样的问题，通过删除 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)
于 2016-02-29T00:18:09.540 回答
2
在垃圾邮件攻击之后，我们在 HostGator 帐户（对所有主机设置 inode 限制）上遇到了这种情况。它在 /root/.cpanel/comet 中留下了大量的队列记录。如果发生这种情况并且您发现没有可用的 inode，您可以通过 shell 运行此 cpanel 实用程序：
/usr/local/cpanel/bin/purge_dead_comet_files
于 2014-11-12T08:37:19.307 回答
2
您可以使用 RSYNC 删除大量文件
rsync -a --delete blanktest/ test/
创建包含 0 个文件的空白测试文件夹，命令会将您的测试文件夹与大量文件同步（我使用此方法删除了近 500 万个文件）。
感谢http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux
于 2016-06-03T07:26:16.643 回答
2
迟到的答案：就我而言，这是我的会话文件
/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 手动删除了一些会话。
希望这可以帮助！
于 2020-06-15T11:57:54.023 回答
1
eaccelerator 可能会导致问题，因为它将 PHP 编译成块......我在一个负载很重的站点上的 Amazon AWS 服务器上遇到了这个问题。如果您仍然遇到问题，请通过删除 /var/cache/eaccelerator 中的 eaccelerator 缓存来释放 Inode。
rm -rf /var/cache/eaccelerator/*
（或任何你的缓存目录）
于 2013-04-01T20:17:45.390 回答
1
我们最近遇到了类似的问题，如果一个进程引用了一个被删除的文件，inode不会被释放，所以需要检查lsof /，kill/restart进程会释放inode。
如果我在这里错了，请纠正我。
于 2016-04-01T07:01:07.020 回答
1
如前所述，如果有很多小文件，文件系统可能会用完 inode。我在这里提供了一些方法来查找包含大多数文件的目录。
于 2016-08-17T18:07:08.513 回答
1
在上述答案之一中，有人建议会话是 inode 用完的原因，而在我们的情况下，情况正是如此。尽管我建议检查 php.ini 文件并确保session.gc_probability = 1还添加到该答案session.gc_divisor = 1000，
但session.gc_maxlifetime = 1440. 在我们的例子中 session.gc_probability 等于 0 并导致了这个问题。
于 2020-08-02T16:39:10.870 回答
1
这篇文章拯救了我的一天： 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
于 2020-09-29T09:48:39.377 回答
1
在 Raspberry Pi 上，我遇到了/var/cache/fontconfig包含大量文件的 dir 问题。删除它花了一个多小时。当然会rm -rf *.cache*引发Argument list too long错误。我用了下面一个
find . -name '*.cache*' | xargs rm -f
于 2020-12-11T13:48:06.330 回答
0
你可以看到这个信息
for i in /var/run/*;do echo -n "$i "; find $i| wc -l;done | column -t
于 2020-06-17T02:01:53.620 回答
0
首先，获取 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
于 2022-01-31T09:30:58.317 回答
-1
到目前为止，这个问题有很多答案，以上所有内容似乎都是具体的。我认为你在使用时会很安全stat，但是取决于操作系统，你可能会遇到一些 inode 错误。因此，实现您自己的stat呼叫功能64bit以避免任何溢出问题似乎相当兼容。
于 2017-09-17T17:52:05.033 回答
-3
如果您使用 docker，请删除所有图像。他们使用了很多空间......
停止所有容器
docker stop $(docker ps -a -q)
删除所有容器
docker rm $(docker ps -a -q)
删除所有图像
docker rmi $(docker images -q)
对我有用
于 2019-03-25T04:11:44.230 回答