说实话，作为运维或者开发人员，Zui让人心跳加速的时刻之一，莫过于半夜收到监控告警：某台服务器的磁盘空间利用率突破了90%甚至100%。你慌慌张张地登录上去，第一反应肯定是敲下那个熟悉的命令——df -h。结果一kan，确实红了/dev/sda1确实满了。紧接着，你习惯性地用du -sh /*去排查，想kankan到底是哪个目录在“吃”空间。可是诡异的事情发生了：du统计出来的占用空间加起来远远小于df显示的Yi用空间。

这种时候，你是不是感觉头皮发麻？明明文件删了或者明明没kan到大文件，空间却回不来。别急，这其实是Linux世界里非常经典的一个“坑”。今天我们就抛开那些枯燥的教科书式定义，像老朋友聊天一样，深入剖析一下当df和du“打架”时我们到底该如何一步步揪出背后的真凶，彻底解决磁盘空间满却找不到大文件的棘手问题。

第一回合：理解df与du的“性格差异”

在开始动手之前，我们得先搞清楚这两个命令到底在关注什么。hen多时候，排查陷入僵局是因为我们误解了工具的输出。

df这个家伙，其实是个宏观派。它并不关心目录底下具体有哪些文件，它是直接去读取文件系统的超级块信息。也就是说df眼里kan到的是“这块硬盘被分配了多少空间出去”，至于这些空间是被正在运行的文件占着，还是Yi经被删除了但还没释放，它dou算作“Yi用”。这就好比你去酒店订房，前台登记册上写着这间房“Yi入住”，不管客人是不是还在房间里只要没退房，这间房对前台来说就是被占用的。

而du则是个微观派，甚至有点像个较真的会计。它会老老实实地去遍历你指定的目录，把每一个文件的大小加起来。Ru果一个文件被删除了du是kan不到的，自然也不会把它算进去。

所以当你发现df显示空间满了但du却显示还有hen多空间时这中间的“差额”，往往就是那些“Yi经退房但还没收拾好房间”的文件——也就是我们常说的“Yi删除但句柄未释放”的文件。

第二回合：常规排查——du与find的组合拳

当然并不是所有的情况dou是因为句柄未释放。hen多时候，确实就是有某个不起眼的日志文件或者临时文件在疯狂增长。这时候，我们需要一套标准的排查流程，快速定位大文件。

1. 宏观定位：kankan到底是哪个目录在作祟

我们还是得用du，不过要用得巧。直接在根目录跑du可Neng会慢得让你怀疑人生，所以我们通常只kan一级目录：

# 查kan根目录下各文件夹的大小，并按从大到小排序
du -sh /* 2>/dev/null | sort -hr | head -n 10

这里加个2>/dev/null是为了把那些无权访问的错误信息扔掉，免得干扰视线。通过这一步，你通常Neng一眼发现，比如/var或者/home目录特别大。假设我们锁定了/var，那就继续往下挖：

# 深入/var目录，查kan二级目录占用
du -sh /var/* 2>/dev/null | sort -hr | head -n 10

像剥洋葱一样一层层找下去，直到你找到那个具体的罪魁祸首。

2. 精准打击：用find直接搜大文件

Ru果du一层层找太慢，或者你只想找超过一定体积的文件，find命令就是你的狙击枪：

# 在根目录下查找大于100MB的文件
find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | awk '{print $5, $9}'

或者，Ru果你只想kanZui近修改过的大文件，Ke以加上时间参数：

# 查找/var/log下7天内修改过且大于50M的文件
find /var/log -type f -mtime -7 -size +50M -exec ls -lh {} \;

这一套组合拳下来Ru果是常规的大文件占用，基本douNeng抓个正着。但Ru果你发现，明明du统计出来的总和hen小，df却依然坚挺地显示“满”，那我们就得进入下一阶段的“灵异事件”排查了。

第三回合：隐形杀手——Yi删除文件未释放空间

这是生产环境中Zui容易让人抓狂的场景。你明明执行了rm -f /var/log/nginx/access.log，文件也kan不到了为什么空间没变回来？

原因在于，在Linux中，当一个文件被进程打开时它就不仅仅是一个磁盘上的数据块了它在内存里还有一个对应的“文件句柄”。Ru果你直接用rm命令删除文件，只是删除了磁盘上的目录链接，但只要那个进程还活着，还握着那个句柄，磁盘空间就不会被释放。这就像你把门牌号摘了但屋里还有人住着，房子自然还是被占用的状态。

这时候，我们需要请出神器——lsof。

使用lsof揪出“僵尸文件”

执行下面的命令，你会kan到另一个世界：

lsof | grep deleted

这个命令会列出所有被标记为“deleted”但依然被进程占用的文件。输出结果里重点关注SIZE那一列。你会发现，有些文件虽然标着，但占用的空间却大得惊人。

找到了怎么办？

Zui简单粗暴的方法，是重启占用该文件的服务。比如Ru果是Nginx的日志文件，重启Nginx即可：

systemctl restart nginx

但Ru果你不想重启服务，那就Ke以通过/proc文件系统来清空它。假设lsof输出显示该文件的PID是1234，文件描述符是4w，那么你Ke以这样操作：

# 直接清空该句柄的内容，而不是删除文件
echo> /proc/1234/fd/4

执行完这一步，再去查kandf，你会发现空间终于降下来了。是不是感觉松了一口气？

第四回合：隐藏的吞噬者——Docker与碎片化

除了进程占用文件，现代服务器上还有一个常见的“空间黑洞”，那就是Docker。hen多时候，服务器本身没存多少东西，但Docker相关的层、悬空镜像、停止的容器却悄悄吃光了硬盘。

Docker空间清理

不要只盯着宿主机的目录，记得kankanDocker的磁盘占用情况：

docker system df

这个命令会清晰地展示镜像、容器、本地卷以及构建缓存各自占用了多少空间。Ru果你kan到Images或Build cache大得离谱，那就该动手清理了。

对于测试环境或者不介意清理旧资源的场景，Ke以使用这条“核弹”级别的命令：

# 清理所有停止的容器、未被使用的网络、悬空镜像以及构建缓存
# 加上 -a 会清理未使用镜像，--volumes 会清理未使用的卷
docker system prune -a --volumes

执行这个命令前，千万要确认好，别把还在用的镜像给删了否则哭dou来不及。

第五回合：被忽视的角落——inode耗尽

还有一种情况，特别狡猾。你用df -hkan，磁盘空间明明还剩80%以上，但系统却提示“No space left on device”。这时候，千万别怀疑人生，可Neng不是Block满了而是Inode耗尽了。

Linux系统存储文件，不仅需要存放数据的地方，还需要存放文件元数据的地方，这就是Inode。每个文件，不管多小，dou会占用一个Inode。

Ru果你的系统里充斥着数以百万计的小文件，Inode就会先于空间被耗尽。

检查Inode使用率

检查这个指标非常简单：

df -i

关注IUse%这一列。Ru果它接近了100%，那就是Inode满了。

排查Inode满的问题，不Neng用常规的du按大小排序，因为那些小文件体积hen小，加起来也没多少GB。你需要按文件数量排序：

# 查找当前目录下文件数量Zui多的子目录
for i in /*; do echo $i; find $i | wc -l; done | sort -k2 -rn | head -n 10

或者geng精准一点，查找特定目录下的小文件：

# 查找/var目录下小于10K的文件，并统计数量
find /var -type f -size -10k | wc -l

通常，Inode耗尽dou是因为某个程序疯狂生成小文件且不清理。找到那个目录，删掉那些无用的小文件，Inode就会释放出来系统也就恢复正常了。

保持系统健康的习惯

排查磁盘空间问题，有时候就像是在破案。从dfkan全局，用du查细节，借lsof找幽灵，Zui后还得防备Docker和Inode的暗箭。这不仅仅是敲几行命令那么简单，geng需要我们对Linux文件系统的底层机制有一点点的理解。

当然与其等到报警响了再火急火燎地去救火，不如平时就养成良好的习惯。比如配置好日志轮转，定期清理Docker未使用的资源，以及对关键目录设置磁盘配额。毕竟谁也不想在大半夜被叫起来对着黑乎乎的终端屏幕，去寻找那些kan不见摸不着的“丢失空间”。

希望这篇实战指南Neng帮你下次遇到“磁盘满了却找不到大文件”的怪事时Neng从容应对，手到病除。技术这东西，懂了原理，就不慌了。

---