我有一个磁盘驱动器,其中inode使用率为100%(使用df -i命令)。 但是在大量删除文件后,使用率仍然是100%。
那么正确的做法是什么呢?
一个磁盘空间使用较少的磁盘驱动器怎么可能有 更高的Inode使用率比更高的磁盘驱动器磁盘空间使用率?
它是可能的,如果我压缩大量的文件,会减少使用的索引节点数?
我有一个磁盘驱动器,其中inode使用率为100%(使用df -i命令)。 但是在大量删除文件后,使用率仍然是100%。
那么正确的做法是什么呢?
一个磁盘空间使用较少的磁盘驱动器怎么可能有 更高的Inode使用率比更高的磁盘驱动器磁盘空间使用率?
它是可能的,如果我压缩大量的文件,会减少使用的索引节点数?
当前回答
对于大量的文件,可以使用RSYNC删除
rsync -a --delete blanktest/ test/
创建空白测试文件夹,其中包含0个文件,命令将与大量文件同步测试文件夹(我已经使用这种方法删除了近500万个文件)。
感谢http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux
其他回答
我有同样的问题,通过删除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)
在一次垃圾邮件攻击后,我们在一个HostGator帐户(他对所有主机都设置了inode限制)上遇到过这种情况。它在/root/.cpanel/comet中留下了大量队列记录。如果发生这种情况,你发现你没有空闲的inode,你可以通过shell运行这个cpanel实用程序:
/usr/local/cpanel/bin/purge_dead_comet_files
到目前为止,这个问题有很多答案,上面所有的答案似乎都是具体的。我认为你使用stat是安全的,但根据操作系统的不同,你可能会遇到一些inode错误。因此,使用64位来实现自己的统计调用功能以避免任何溢出问题似乎是相当兼容的。
即使磁盘不是很满,也很容易在磁盘上使用大量的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耗尽的原因,在我们的例子中正是如此。为了补充这个答案,我建议检查php.ini文件并确保session。Gc_probability = 1也是session。gc_除数= 1000和 会话。Gc_maxlifetime = 1440。在我们的案例会议上。Gc_probability等于0,导致了这个问题。