一个关于df和du的怪现象，请大家帮助看一下

gldcan

我有一台M85的机器，装的是AIX 4.3。刚开始用df查看时/var目录使用为100%,以为空间用完了，就扩大了空间，但是很快（也就是几分钟的时间）又到了100%，一查是/var/tmp下的snmpd.log文件很大，后来把此文件删掉，再扩大空间，还是很快就到100%了，但是用du查时却很小。如下
Filesystem    512-blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4           65536     23488   65%     1405     9% /
/dev/hd2         2555904    745544   71%    27703     9% /usr
/dev/hd9var      1310720       176  100%      604     1% /var
/dev/hd3         1245184   1162720    7%      144     1% /tmp
/dev/hd1          131072     38672   71%       75     1% /home


M85:/#du -s /var
110472  /var

查看/var/tmp目录下，已经是没有snmpd.log文件了。另外我在空间扩大前后用du查看空间是没有变化的，但是df却是变化很大，一会就到了100%。请大家给分析一下。

CUaixer

rm 掉了？
.log文件最好还是重定向吧 >; *.log

gldcan

哦，谢谢，是被我备份后用rm删掉的，现在如何做呢？我重新拷过去，好象没有用呀，我想主要是snmpd这个进程做的，怎么操作？

dugong

刚才查看了du的命令使用，所显示的块只基于文件的大小，未分配的块没有包含进去，而df是显示文件系统总空间和可用空间的信息，估计是在/var下有某种应用，如数据库的操作日志等，会随着系统的运行而不断增大，但是又没有直接使用文件的形式，所以du是看不到的，而文件系统空间却一直占用着，这样如果重新启动机器，应该会恢复到原来的空间的。
楼主参考一下，是否这样。

gldcan

谢谢楼上，问题解决了。主要是snmpd这个进程的问题，它会在很快的时间内产生很多的日志，把日志文件的大小定义后，重新启动这个进程就可以了。

lylklb

在/etc/snmpd.conf中更改控制snmpd.log文件的定义大小,  只是解决了问题的表面现象!  问题是应该找到究竟是什么原因导致你的snmpd守护进程在不断地往你的snmpd.log写事件信息.  这通常是因为在你的系统中有某个网络应用组件一直处于异常工作状态所致引起的!   正常系统网络运行情况下,  此日志文件内容大小是不动的.

lylklb

另外,  我还碰到了比楼主所说的更麻烦的情况: 在rm掉大文件snmpd.log(近800MB)之后, 使用df查看FS空间仍没有变化,  但使用du查看的确是减小了,  那是因为所删掉文件相对应的FS空间中的进程没有被释放掉的关系(例如, 在这里就是因为/var文件系统被snmpd守护进程给"锁定"了)!
因此, 通常遇到此类情况只需要简单手工地停掉(重启)该相对应的进程(服务)即可而不需要重启系统!!

  例如:   fuser -ku  <FSName>;
     或  stopsrc -s snmpd 再startsrc  -s  snmpd

蓝天一头鸟

/var文件系统被锁定了，删除snmpd.log实际上没有被删除，空间还占有？是不是这样理解？

lylklb

此<FSName>;空间上的文件虽然已被删除, 但因该FS资源本身被其相对应的进程(服务)所持续占有, 所以反映到系统内存中的FS空间数据显示得不到即时刷新.

蓝天一头鸟

哦，这样啊。