根分区满，但未找到具体的占用文件，十分诡异！

black-hat

这个问题可以这样来理解，咱们简单的做一个测试就拿Nginx程序来测试。
先看看磁盘的大小在说

此时我们来多刷新一下页面让日志写入Log来增加磁盘空间
经过多次刷新后磁盘的文件大小已经变大。
日志文件路径在/var/log/host.access.log

此时在看看磁盘的大小情况

现在我们来删除日志文件
rm -f /var/log/host.access.log
这个时候你可以看的出来虽然删除了文件但是磁盘的空间一样没有释放。
原因是因为程序在打开了一个句柄后没有释放，始终会占用一定block，如果此时有请求会一直的的往下写。
我们在来看看程序的FD状态

好了具体的你在研究研究。详细的地方你参考一下 程序的一些读写机制吧/

frenchleaf

请问一下，这个怎么解决？重启nginx能解决吗？已经写入block的空间能找回来吗？

bacon1001

回复 30# black-hat


这种关于程序未释放空间的说法已经被推倒，我尝试kill掉所有程序和reboot服务器，情形依旧....

hailang424

可以这样试试
1、df -a > /tmp/111
2、cat /tmp/111 |sort -t ' ' -k 1 -nr |more

仔细看看，看能不能查出来。

leeqiand

938M    proc
这个好像一般没容量吧？
du: cannot access `error/controlcc20100526.sql': Permission denied
du: cannot access `error/cacti20100526.sql': Permission denied
你试着查看你的数据库占多大空间
不行的话 你试着进入单用户模式查看下  希望帮助你

missing-cn

df -i 看看inode剩余数量是多少

sobigapple

du: cannot access `error/controlcc20100526.sql': Permission denied
du: cannot access `error/cacti20100526.sql': Permission denied

root都没有权限，先从这个入手吧，估计是文件损坏了。
fsck一下。

wake2000x

/var/spool/clientmqueue/ 里面的文件很大，导致根/满
解决: cd /var/spool/clientmqueue/
ls |xargs -f
造成这个原因是因为cron脚本引起的，在定时服务里  > /dev/null 2>&1

godymoon

回复 37# wake2000x


   

/var/spool/clientmqueue/ 里面的文件很大，导致根/满
解决: cd /var/spool/clientmqueue/
ls |xargs -f
造成这个原因是因为cron脚本引起的，在定时服务里  > /dev/null 2>&1

LZ的帖子显示var目录只占了3.5G

你是根据哪个结果来判断 是/var/spool/clientmqueue/里面 的文件占用的？

taojie2000

回复 37# wake2000x


ls |xargs -f   啥意思