原因

有很多已删除文件被进程占用着。

这些被删除的文件是什么？

这些是命令使用的文件，如第一列所示，在我们的例子中是 rhn_check。
但是一旦这些步骤完成，这些文件作为命令过程的一部分被删除，但由于命令仍在执行，这些文件被锁定并且将处于相同状态，除非 PID 被释放或者命令被完全执行。

我们还可以使用以下命令查看这些已删除的文件

语法：

lsof +aL1 /file-system

# lsof +aL1 /var
COMMAND   PID     USER    FD   TYPE DEVICE      SIZE NLINK   NODE   NAME
rhn_check 31261    root    8u   REG  253,2   22082560 0 327733 /var/cache/yum/prod-03-epel-x86_64-server-5-rhel5/primary.xml.gz.sqlite (deleted)
rhn_check 31261    root    9u   REG  253,2      78848  0 327737 /var/cache/yum/prod-03-likewise-x86_64-client-5-rhel5/primary.xml.gz.sqlite (deleted)
rhn_check 31261    root   12u   REG  253,2    9275392  0 327752 /var/cache/yum/prod-03-rhel-x86_64-server-supplementary-5/primary.xml.gz.sqlite (deleted)
rhn_check 31261    root   13u   REG  253,2     582656  0 327756 /var/cache/yum/prod-03-rhn-tools-rhel-x86_64-server-5-rhel5/primary.xml.gz.sqlite (deleted)
rhn_check 31261    root   14u   REG  253,2   34002944  0 327758 /var/cache/yum/prod-03-epel-x86_64-server-5-rhel5/filelists.xml.gz.sqlite (deleted)
rhn_check 31261    root   15u   REG  253,2   33857536  0 327760 /var/cache/yum/prod-03-epel-x86_64-server-5-rhel5/other.xml.gz.sqlite (deleted)

检查被删除文件锁定的总大小

# lsof /var | gawk -F" " '{ print }' |sort| uniq| awk '{ sum += } END { print sum/(1024*1024*1024) }'
0.937209

可以看到 大约 0.94 GB 大小的文件被锁定。
这就是 du 和 df 命令之间大小有差别的原因。

还可以这样查看

# lsof +aL1 /var | awk -F " " '{print }' | sort | uniq | awk '{ sum += } END { print sum/(1024*1024*1024*1024) }'
0.937209

解决方案：

让我们检查这个 PID 使用的其他文件（我已经修剪了 o/p，因为它很长）

# lsof -p 31261

rhn_check 31261 root  mem    REG              253,0    143144    557343 /lib64/libexpat.so.0.5.0
rhn_check 31261 root  mem    REG              253,0    372912    950724 /usr/lib64/python2.4/site-packages/M2Crypto/__m2crypto.so
rhn_check 31261 root  mem    REG              253,0      7120    918933 /usr/lib64/python2.4/lib-dynload/_weakref.so
rhn_check 31261 root  mem    REG              253,0     34184    919549 /usr/lib64/python2.4/site-packages/_sqlite.so
rhn_check 31261 root  mem    REG              253,0     41784    919601 /usr/lib64/python2.4/site-packages/_sqlitecache.so
rhn_check 31261 root  mem    REG              253,0    647608    557099 /lib64/libglib-2.0.so.0.1200.3
rhn_check 31261 root    5r   REG              253,0     19517    920332 /usr/share/rhn/actions/packages.py
rhn_check 31261 root    6u  unix 0xffff8106770ba980           901384670 socket
rhn_check 31261 root    7w   REG              253,2       107     32851 /var/log/yum.log

如我们所见，还有许多其他文件仍在使用中，并且命令 rhn_check 似乎仍在执行。
现在，此时我们需要决定空间是重要的还是正在执行的服务/命令。
因为如果你继续杀死那个 PID，那么负责这个 PID 的服务就会死掉，影响你的应用程序和使用。

在我的情况下，rhn_check 命令在这个时间点不是很重要，所以我可以继续杀死它

# kill -9 31261

$df -h /var/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-var
3.9G  3.0G  703M  82% /var

此问题的另一个更好的选择是重新启动所需的服务。
例如，如果任何服务（如 named、httpd 等）锁定了任何已删除的文件，则最好重新启动该服务。
这样所有锁定的删除文件都将被释放。
因此，与其杀死 PID，这可能是一个更好的选择。

使用df -h查看文件系统使用率时，显示100%

# df -h /var/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-var
3.9G  3.9G     0 100% /var

使用du检查大小时，却只占用3.9G中的2.9G，使用率只有80%

[root@server1 var]# du -sh
2.9G    .

检查使用 /var的进程，可以使用 lsof 命令

# lsof /var