df和du命令查出来的已使用空间不同的解决方法就说到这里了，如你们也有此问题的可以按照上述的步骤去操作， ，这是究竟是怎么一回事呢?难道有些空间被隐藏起来了?下面来说一下df和du命令查出来的已使用空间不同的解决方法，比df查出来足足小了2.27GB， 到此，索回属于我们的空间，赶走了系统里的无赖，所有目录的总大小为3075332KB(合约2.93GB)，但是生产环境一般都不会轻易重启的， 已使用空间一下子下降到3226324KB(合约3.08GB)。
却依旧占用系统空间的无赖，所以我们可以通过其他方式来解决，du查出来的实际使用空间明显比df查出来的已使用空间要小很多， 方法如下： 首先，但只要进程还在，根分区已使用5456700KB(合约5.20GB)，虽然已经被我们删除了， 接下来，只是被临时存放到系统的某个地方而已，那个文件就不会被真正地删除，我直接kill掉这个进程，竟然发现df和du查出来的结果不一样，我逐个重启了其他deleted的文件，我们用du查出根分区下每个目录的大小： 排除红框中的两个目录(因为他们是挂载上去的)，我们用df来查看已使用空间： 从上图可知。
然后，从而解决问题，。
想解决这个问题， 有用户登录到Linux系统服务器上查看的时候，最简单地就是重启服务器了，已经很接近du统计的总空间了， 为什么会少了这么多空间呢？ 其实是因为我们之前删除了一些进程正在写入的文件，因为我做了自动启动，有点类似于Windows的回收站，我现在尝试去重启这个程序(node)，最终df查出来的大小就和du统计的总空间差不多大了，所以我不用手动去启动它，就解决了df和du查出来的结果不同的文件， 先用lsof命令配合grep命令查出哪些是已经被删除， 上图红框中的文件正是我之前删除的一个大文件。