今天测试环境上出现了这样的现象，df -lh 显示 tmpfs 目录占用满了，但是 du -lh 查看却只有 500m，出现这个问题一般是写文件删除出问题。

解决办法，找出真正占用的进程 id

1

sudo lsof -w| grep deleted

杀掉进程

1

kill -9 nnnn

3.3 为什么没有释放空间?

为什么有的文件删除之后不释放空间，有兴趣的读者可以看看下面的说明。 这张图是 linux 的系统文件结构。 当一个进程打开一个文件后，便会在内核中创建一个 file 对象，这个对象主要描述了进程如何与文件进行交互。file 对象中将指向一个 dentry 结构（目录项)，目录项中描述了目录项名称，父目录项信息，子目录项信息等。而 dentry 中的 d_inode 所指向的 inode 节点中则包含了实际的文件存储在磁盘上的信息。

当多个进程打开同一个文件时，内核中变会创建相应的 file 对象，但是他们都公用同一个 dentry，只不过每一次打开文件 dentry 的引用计数 d_count 加 1。并且对于打开的同一个文件而言，inode 也是唯一的，inode 的引用计数 i_count 一般为文件硬链接的数目。如果该文件被某个进程写的方式打开，i_count 不为 0，肯定是释放不了的。如果强行释放了可能会引起系统崩溃。

笔者曾遇到过一个问题，一个大的压缩文件包被 rm 删除后，空间一直没有释放。通过 lsof |grep deleted 命令也查不到有什么进程在使用这个文件。如果程序释放处理不当，进程灭掉了但是连接未释放，也可以导致 lsof 查不到被占用的情况。这个时候 i_count>0，空间基本就没法释放了。需要重启服务器才能解决问题。

下面是释放后的情况。

1
2
3
4
5
6
7
8
9

ubuntu@slave:~$ df -h
Filesystem        Size  Used Avail Use% Mounted on
udev              1.9G  4.0K  1.9G   1% /dev
tmpfs             379M   11M  369M   3% /run
/dev/vda1          50G   46G  2.0G  96% /
tmpfs             1.9G   48K  1.9G   1% /dev/shm
tmpfs             5.0M     0  5.0M   0% /run/lock
tmpfs             1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs             379M     0  379M   0% /run/user/500

参考文档：

https://www.cxyzjd.com/article/sitebus/104537400