- A+
在换服务器时,tar解压网站打包文件时,发现中途出现 Cannot open: No such file or directory
第一感觉是空间不足,于是就查了大量资料,发现是站点文件个数太多造成的,也就是索引节点(inode)不足。
方案一:
| 1 2 3 4 5 6 7 8 9 | df -h   Filesystem                    Size  Used Avail Use% Mounted on   /dev/mapper/dev01-root         75G   58G   14G  82% /   udev                          2.0G  4.0K  2.0G   1% /dev   tmpfs                         396M  292K  396M   1% /run   none                          5.0M     0  5.0M   0% /run/lock   none                          2.0G  4.0K  2.0G   1% /run/shm   /dev/sda1                     228M  149M   68M  69% /boot | 
空间剩余14G,可以排除空间已满的情况。导致文件生成失败还有另一个原因,就是文件索引节点inode已满。
| 1 2 3 4 5 6 7 8 9 | df -i   Filesystem                    Inodes   IUsed  IFree IUse% Mounted on   /dev/mapper/dev01-root       4964352 4964352      0  100% /   udev                          503779     440 503339    1% /dev   tmpfs                         506183     353 505830    1% /run   none                          506183       5 506178    1% /run/lock   none                          506183       2 506181    1% /run/shm   /dev/sda1                     124496     255 124241    1% /boot | 
inodes 占用100%,果然是这个问题。
解决方法:删除无用的临时文件,释放inode。
查找发现 /tmp 目录下有很多sess_xxxxx的 session临时文件。
| 1 2 | ls -lt /tmp | wc -l   4011517 | 
进入/tmp目录,执行find -exec命令
| 1 | sudo find /tmp -type f -exec rm {} \; | 
如果使用rm *,有可能因为文件数量太多而出现Argument list too long错误,关于Argument list too long错误可以参考《linux Argument list too long错误解决方法》
除了/tmp的临时文件外,0字节的文件也会占用inode,应该也释放。
遍历寻找0字节的文件,并删除。
| 1 | sudo find /home -type f -size 0 -exec rm {} \; | 
删除后,inode 的使用量减少为19%,可以正常使用了。
| 1 2 3 4 5 6 7 8 9 | df -i   Filesystem                    Inodes  IUsed   IFree IUse% Mounted on   /dev/mapper/dev01-root       4964352 940835 4023517   19% /   udev                          503779    440  503339    1% /dev   tmpfs                         506183    353  505830    1% /run   none                          506183      5  506178    1% /run/lock   none                          506183      2  506181    1% /run/shm   /dev/sda1                     124496    255  124241    1% /boot  | 
方案二:
服务器监控突然曝出了如下的错误:
| 1 | vfs.fs.inode[/,pfree]):5 % | 
登录到服务器上df -i
一看/路径下96%,而数据目录/data下才用了30%,故初步判断生成的数据量正常,可能是一些系统产生的文件把根路径占满了
于是乎在执行以下命令,查看根路径下各个文件夹的文件数
| 1 | for i in /*; do echo $i; find $i |wc -l|sort -nr; done | 
数文件数超过10W的有两个/data(我们的数据分区,确认数据量正常)和/var
/data 13W+文件
/var下70W+文件
楼主Linux水平有限,于是把/var下的目录一个个的执行了上面的命令
| 1 2 3 | for i in /var/cache; do echo $i; find $i |wc -l|sort -nr; done    for i in /var/db; do echo $i; find $i |wc -l|sort -nr; done    ........ | 
重点来了,当执行到下面的时候
| 1 | for i in /var/spool/; do echo $i; find $i |wc -l|sort -nr; done | 
文件夹里有70W+文件
于是重复上述步骤,终于找到了罪魁祸首
| 1 | for i in /var/spool/postfix/maildrop/; do echo $i; find $i |wc -l|sort -nr; done | 
/var/spool/postfix/maildrop/下有67W+文件

楼主百度了一把
于是乎执行rm -rf ./* 竟然报错

只能来大招了。
| 1 | find . -name "*" | xargs rm -rf | 
10S后,成功收到报警解除的邮件
胜利处理完困扰我好几天的问题

 
	


![OpenAi[ChatGPT] 使用Python对接OpenAi APi 实现智能QQ机器人-学习详解篇](https://www.zxar520.com/wp-content/themes/begin5.2/timthumb.php?src=https://www.zxar520.com/wp-content/uploads/2023/02/1677441093.png&w=280&h=210&a=&zc=1)


