Linux节点释放,关于linux：如何释放Inode的使用量？

我有一个磁盘驱动器，其索引节点使用率为100％(使用df -i命令)。

但是，在实质上删除文件后，使用率仍为100％。

那么正确的方法是什么？

磁盘空间使用较少的磁盘驱动器如何可能具有

Inode的使用率比磁盘空间使用率更高的磁盘驱动器高？

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

想给你50分的问题。 我能怎么做！ :)

@Sophy不要那样做。 你会被自动禁止

@StevenLu谢谢您的信息！ 我想感谢他，因为我花了几天时间解决我的问题。 但是这个问题可以帮助我。 再次感谢

@Sophy：为什么要为SO奖励一些题外话？ :)那绝对不是编程问题，无论获得多少票。

空目录也会占用inode。 删除它们可以释放一些索引节点。 在某些用例中，该数字可能很重要。 您可以使用以下命令删除空目录：find。 类型d-空-删除

有用，但我投票决定关闭此问题为离题，因为这似乎属于unix.stackexchange.com

如果您很不幸，您已经使用了所有索引节点的大约100％，并且无法创建Scipt。

您可以使用df -ih进行检查。

然后，此bash命令可能会帮助您：

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

是的，这将花费一些时间，但是您可以找到包含最多文件的目录。

可以解决问题。我的问题是/ lib / php / sessions目录中有大量会话。也许有人有同样的问题

Parallels plesk无法加载，ftp无法打开会话，Internet磁盘配额被取消(122)是当您的服务提供商将inode数(?文件)设置为最大时会遇到的一些问题即使您有无限的空间，也为20,000个inode(?文件)。

有人应该将此查找，剪切，uniq排序重写为单个awk命令！

有时，它也有助于尝试查找占用大量空间的目录。例如，如果使用Apache默认配置启用了mod_disk_cache，则您会发现varcacheapache2mod_disk_cache下的每个目录仅具有合理的条目数量，但是整个层次结构将占用您的所有inode。运行du -hs *可能会提示一些占用比您预期更多的空间的地方。

@mogsie，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可能无法将所有内容保留在内存中，并会尝试自动回退以写入临时文件。一个显然会失败的过程...

谢谢，这完全帮助了我。我的小型VM的空间不足，但实际上是inode。最初，我四处清理大文件，但无济于事，然后我运行了您的脚本并找到了一个包含6万个小文件的目录。我摆脱了他们，现在我重新开始营业。谢谢！

sort对我来说失败了，但是我能够给出有效的--buffer-size=10G。

@mogsie在我的版本中使用了一些gawk。这也算目录。

@mogsie这是脚本的一个版本，它还计算目录并处理包含换行符的文件名：find . -maxdepth 1 -not -path . -type d -print0 | xargs -0 -n 1 -I{} find {} -xdev -not -path {} -print0 | gawk BEGIN{RS="\0";FS="";ORS="\0"}{print $2} | uniq -cz | sort -nz。 gawk命令可以替换为grep -ozZ \.[^]*(由GNU grep 2.25测试)。不幸的是，cut不能处理空终止行。

@FrederickNord，sort失败时的错误消息是什么？如何报告失败？

@SteMa，目录不可以自我清理吗？

即使磁盘不是很满，也很容易使用大量的索引节点。

索引节点已分配给文件，因此，如果您有成千上万个文件(每个都有1字节)，则在磁盘用尽之前，节点用尽了很长时间。

如果文件具有多个硬链接，则删除文件也可能不会减少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_$$

当然，>tmpcount_em_$$仅在有空间的情况下才起作用...如果是这样，请参阅@simons答案。

@alxndr，这就是为什么将文件系统分开通常是一个好主意的原因-这样，填充类似tmp之类的内容不会影响您的其他文件系统。

您的答案非常适合"如果删除该文件，系统将不会在重新启动后继续使用该文件"。但是有人问，"删除inode指针后如何回收或重用inode？"。基本上，Linux内核每次创建文件时都会在文件中创建一个新的索引节点，并且在删除文件时也不会自动回收该索引节点。

@paxdiablo，您说："我最初的建议是删除所有可以删除的文件，然后重新启动该框，以确保没有使文件保持打开状态的进程。"但是其产品服务器无法重新启动，因此如何在不重新启动的情况下释放那些inode

@AshishKarpe，我想您是在谈论您自己的情况，因为OP没有提及生产服务器。如果您不能立即重启，则有两种可能性。首先，希望运行中的进程最终关闭当前文件，以便可以释放磁盘资源。其次，即使生产服务器也应有一定程度的重启空间-只需安排一些计划内的停机时间，或等待下一个停机时间窗口出现。

发现在/ tmp中创建了许多小文件，这些文件正在消耗inode，因此使用cmd" find / tmp -type f -mmin +100 -name" *" | perl -nle unlink;"将其释放。 ..........谢谢

非常感谢这篇文章。我有一台RHEL 6.3服务器，该服务器具有所有可用分区，但是由于count_em脚本，由于一些奇怪的缓存文件填充了/ var / lib / sss / db，因此我能够看到/ var分区中的inode全部用完了目录 。我所有的应用程序(包括auditd和lvm)都没有任何可用空间。现在到真正的问题... :-(

我想您想要的是ls -A而不是ls -A。你为什么要数。和..？

我的情况是我没有i节点，并且已经删除了所有可能的内容。

$ df -i

Filesystem     Inodes  IUsed  IFree IUse% Mounted on

/dev/sda1      942080 507361     11  100% /

我在ubuntu 12.04LTS上，无法删除占用约40万个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 usrsrclinux-headers-3.2.0-2*，如果我确定我没有使用该内核？

@MarsLee您可以使用" uname -a"检查当前正在运行的内核

一个人叫$ sudo apt-get autoremove帮了我大忙。

我的解决方案：

尝试查找这是否是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 varspoolMailScannerincomingSpamAssassin-Temp -mtime +1 -print | xargs rm -f完成了工作:)谢谢！

对我来说，这要花几个小时。但是，有一个简单的解决方案：当第二个命令挂在特定目录上时，请终止当前命令，然后重新将/ *更改为挂在其上的任何目录。我能够深入分析罪魁祸首。

我使用了此命令的此变体以便在同一行上打印数字：for i in usrsrc*; do echo -en"$i\t"; find $i 2>devnull |wc -l; done

for i in src*; do echo"$i, `find $i |wc -l`"; done|sort -nrk 2|head -10展示前10大目录

我有同样的问题，通过删除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 varlibphpsessions*可能是一个更好的命令-它不会删除会话目录，只删除其目录...那么您不必担心重新创建它

我没有php会话，但有magento会话问题，与此类似。感谢您的指导。

php会话不应通过cron作业清除，请在php.ini php.net/manual/zh/中设置session.gc_maxlifetime

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

rsync -a --delete blanktest/ test/

创建其中包含0个文件的blanktest文件夹，命令将使您的测试文件夹与大量文件同步(我已使用此方法删除了近5M个文件)。

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

从文章/评论中可以看出，由于扩展了通配符并传递/处理了每个参数，对于许多文件来说，这比rm *更快，但是对于删除包含很多文件的test文件夹，rm test很好文件。

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

/usr/local/cpanel/bin/purge_dead_comet_files

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

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

如果这里不对，请纠正我。

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

rm -rf /var/cache/eaccelerator/*

(或任何您的缓存目录)

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

我们很喜欢这里的例子;)

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

停止所有容器

docker stop $(docker ps -a -q)

删除所有容器

docker rm $(docker ps -a -q)

删除所有图片

docker rmi $(docker images -q)

对我有用

这无助于检测" inode过多"是否是问题所在。

这与Docker无关。