我有一个磁盘驱动器,其中inode使用率为100%(使用df -i命令)。 但是在大量删除文件后,使用率仍然是100%。
那么正确的做法是什么呢?
一个磁盘空间使用较少的磁盘驱动器怎么可能有 更高的Inode使用率比更高的磁盘驱动器磁盘空间使用率?
它是可能的,如果我压缩大量的文件,会减少使用的索引节点数?
我有一个磁盘驱动器,其中inode使用率为100%(使用df -i命令)。 但是在大量删除文件后,使用率仍然是100%。
那么正确的做法是什么呢?
一个磁盘空间使用较少的磁盘驱动器怎么可能有 更高的Inode使用率比更高的磁盘驱动器磁盘空间使用率?
它是可能的,如果我压缩大量的文件,会减少使用的索引节点数?
当前回答
你可以看到这个信息
for i in /var/run/*;do echo -n "$i "; find $i| wc -l;done | column -t
其他回答
这篇文章拯救了我: 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
即使磁盘不是很满,也很容易在磁盘上使用大量的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_$$
首先,获取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
我的情况是我没有inodes了,我已经删除了所有我能删除的东西。
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 942080 507361 11 100% /
我使用的是ubuntu 12.04LTS,无法删除旧的linux内核,它占用了大约400,000个inodes,因为apt因为缺少一个包而损坏了。我无法安装新包,因为我没有inodes了,所以我被卡住了。
我最终手动删除了一些旧的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% /
我有同样的问题,通过删除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)