linux下du和df命令已使用空间结果不一致的原因及处理办法
来源：互联网 2026-04-03 10:55:32当df和du结果不一致时，到底谁在说谎？ 有用户登录Linux服务器查看空间使用情况时，发现df和du这两个命令给出的结果竟然大相径庭——du统计的“实际使用空间”明显小于df显示的已使用空间。这不禁让人疑惑：难道有一部分空间被隐藏起来了？今天我们就来揭开这个谜团，并分享具体的解决方案。 方法如下：
当df和du结果不一致时，到底谁在说谎？
有用户登录Linux服务器查看空间使用情况时，发现df和du这两个命令给出的结果竟然大相径庭——du统计的“实际使用空间”明显小于df显示的已使用空间。这不禁让人疑惑：难道有一部分空间被隐藏起来了？今天我们就来揭开这个谜团，并分享具体的解决方案。
方法如下：
首先，通过df命令查看磁盘使用情况：
从图中可以看到，根分区显示已使用5456700KB（约合5.20GB）。
接着，使用du命令逐级统计根分区下各个目录的大小：
排除红框中两个挂载目录后，所有目录的总大小为3075332KB（约2.93GB），比df的结果整整少了2.27GB。这个差距相当可观，难怪会引起使用者的警觉。
消失的空间去了哪里？
问题的根源其实很常见：我们之前删除了一些正在被进程写入的文件。虽然文件已经从目录结构中移除，但只要相关进程仍在运行，这些文件就不会被真正释放。这种情况类似于Windows系统中的回收站机制，文件实际上还在占用磁盘空间，只是从常规视图中“消失”了。
要解决这个问题，最简单的办法确实是重启服务器。但在生产环境中，重启往往不是首选方案。幸运的是，我们还有更温和的处理方式。
首先使用lsof命令配合grep过滤，找出那些已被删除却仍在占用空间的“顽固分子”：
红框中标出的文件正是之前删除的一个大文件。接下来尝试重启相关程序（本例中是node进程），直接终止该进程即可——由于配置了自动重启机制，无需手动重新启动服务。
可以看到，已使用空间立刻下降到3226324KB（约3.08GB），已经非常接近du统计的总空间了。
继续逐个重启其他标记为“deleted”的文件关联进程后，df显示的空间使用量最终与du统计结果基本吻合。
至此，df与du结果不一致的问题得到圆满解决。我们成功清除了系统中的“空间钉子户”，收回了被占用的磁盘空间。
关于df和du命令显示结果差异的解决方法就介绍到这里。如果你也遇到类似问题，按照上述步骤操作通常都能解决。希望这个案例对大家有所帮助，欢迎继续关注更多实用技术分享。
相关推荐：
linux/ubuntu系统怎么安装百度网盘 linux百度网盘安装图文教程
侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述
