我有一个磁盘驱动器,其中inode使用率为100%(使用df -i命令)。 但是在大量删除文件后,使用率仍然是100%。
那么正确的做法是什么呢?
一个磁盘空间使用较少的磁盘驱动器怎么可能有 更高的Inode使用率比更高的磁盘驱动器磁盘空间使用率?
它是可能的,如果我压缩大量的文件,会减少使用的索引节点数?
我有一个磁盘驱动器,其中inode使用率为100%(使用df -i命令)。 但是在大量删除文件后,使用率仍然是100%。
那么正确的做法是什么呢?
一个磁盘空间使用较少的磁盘驱动器怎么可能有 更高的Inode使用率比更高的磁盘驱动器磁盘空间使用率?
它是可能的,如果我压缩大量的文件,会减少使用的索引节点数?
当前回答
如果你使用docker,删除所有图像。他们使用了很多空间....
停止所有容器
docker stop $(docker ps -a -q)
删除所有容器
docker rm $(docker ps -a -q)
删除所有图片
docker rmi $(docker images -q)
对我有用
其他回答
我们最近遇到了类似的问题,如果一个进程指向一个被删除的文件,Inode不会被释放,所以你需要检查lsof /, kill/ restart进程会释放Inode。
如果我说错了,请指正。
在上面的一个回答中,有人建议会话是inode耗尽的原因,在我们的例子中正是如此。为了补充这个答案,我建议检查php.ini文件并确保session。Gc_probability = 1也是session。gc_除数= 1000和 会话。Gc_maxlifetime = 1440。在我们的案例会议上。Gc_probability等于0,导致了这个问题。
如果你使用docker,删除所有图像。他们使用了很多空间....
停止所有容器
docker stop $(docker ps -a -q)
删除所有容器
docker rm $(docker ps -a -q)
删除所有图片
docker rmi $(docker images -q)
对我有用
在树莓派上,我在/var/cache/fontconfig目录下有大量文件时遇到了问题。取出它花了一个多小时。当然还有rm -rf *。cache* raise参数列表过长错误。我用的是下面的
find . -name '*.cache*' | xargs rm -f
执行sudo apt-get autoremove命令 在某些情况下,它是有效的。如果存在以前未使用的头数据,则将清除这些数据。