磁盘告急？别慌！Linux df -h 查看与分析实战指南

在Linux服务器的日常运维与故障排查中，Linux df -h查看磁盘空间占用通常是发现问题的第一道哨卡。这个看似简单的命令，却是系统健康度的晴雨表，它能瞬间揭示存储资源是否逼近红线。磁盘空间用尽是许多线上事故的导火索——数据库无法写入、应用日志刷满导致服务僵死、甚至系统无法启动。准确解读`df -h`的输出，并掌握一套从“发现异常”到“定位元凶”再到“根治问题”的完整方法论，是每一位后端开发者和运维工程师的必备生存技能。作为鳄鱼Java的资深内容编辑，我将结合大量实战案例，带你超越基础使用，掌握磁盘空间管理的核心要义。

一、df -h 命令详解：读懂每一列的含义

执行 `df -h` 后，你会看到类似下面的表格：

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   45G  2.8G  94% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
/dev/vdb1       200G  150G   40G  79% /data

每一列都承载着关键信息：
Filesystem： 磁盘分区或存储设备的名称。
Size： 分区总容量。-h 参数使其以 G、M 等人类可读格式显示。
Used： 已使用空间。
Avail： 剩余可用空间。这是最需要关注的数字之一。
Use%： 使用率百分比。当这个数字超过80%时，就应引起警惕；超过95%时，系统可能已处于危险边缘。
Mounted on： 挂载点，即该分区在系统目录树中的位置。

关键洞察： 进行Linux df -h查看磁盘空间占用分析时，首先要看`Use%`最高的行，其次是`Avail`最小的行。根目录 `/` 的使用率尤其敏感，因为它通常包含系统关键文件和日志。

二、df 命令进阶：你必须掌握的几个有用参数

除了基础的 `-h`，结合其他参数能让诊断更精准：

• `df -hT`： 多显示一列 `Type`，告知文件系统类型（如 ext4, xfs, tmpfs）。这对于判断是否因特定文件系统问题（如XFS的元数据占用过高）导致空间异常有帮助。
• `df -i`： 这是排查“磁盘未满却无法写入”问题的神技。 它显示inode的使用情况。每个文件都会消耗一个inode，如果文件数量极多（如海量小文件），即使磁盘空间充足，inode耗尽也会导致无法创建新文件。在鳄鱼Java的运维经验中，邮件服务器或图片缓存服务常出现此问题。
• `df --exclude-type=tmpfs`： 排除临时文件系统，让输出更聚焦于物理磁盘。
• `df -h /home /data`： 只查看指定挂载点的信息，快速聚焦。

一个成熟的Linux df -h查看磁盘空间占用流程，往往以 `df -h` 开始，用 `df -i` 辅助验证，实现全面探测。

三、追根溯源：当df显示空间不足，下一步该怎么做？

看到使用率超过90%，这仅仅是开始。真正的挑战是找到“谁”吃掉了空间。这里需要另一个强大工具链：`du` 命令。

标准排查四步法：

1. 定位到问题挂载点： 假设 `df -h` 显示 `/` 目录使用率94%。

2. 逐层深入，找到最大目录： 进入根目录，使用 `du -sh * | sort -rh | head -10`。这个组合命令非常高效：
- `du -sh *`： 估算当前目录下每个文件和目录的大小（-s 汇总，-h 人类可读）。
- `sort -rh`： 按人类可读的数字进行反向排序（从大到小）。
- `head -10`： 只显示前10个最大的结果。
在鳄鱼Java的一次线上应急中，我们正是通过此命令，在30秒内发现 `/var/log` 目录异常膨胀到了30G。

3. 继续深入： 进入上一步找到的最大目录（如 `/var`），重复 `du -sh * | sort -rh | head -10`，直到定位到具体的文件或最顶层的“肥胖”子目录。

4. 对可疑目录进行内容分析： 比如进入 `/var/log`，可以使用 `ls -lhS | head -10` 按文件大小排序，找出最大的日志文件。

四、实战案例：三大常见磁盘空间“杀手”及处理

根据鳄鱼Java社区的故障统计，以下三类问题最为高频：

案例一：日志文件失控
症状： `/var/log` 或应用自定义日志目录体积巨大。`du` 排查后发现有单个日志文件达到数十GB。
根治： 1. 日志轮转（Log Rotation）： 使用 `logrotate` 工具强制对日志进行按大小或时间切割、压缩和删除旧文件。这是治本之策。 2. 临时清理（慎用）： 对于非关键日志，可使用 `truncate -s 0 big_app.log`（清空内容但保留文件）或直接 `rm`。更安全的是使用 `: > big_app.log`。 3. 调整日志级别： 将生产环境不必要的DEBUG日志调整为INFO。

案例二：Docker容器与镜像占用
症状： `/var/lib/docker` 目录（Docker默认数据目录）占用率极高。
根治： 1. 清理无用资源：
`docker system prune -a`： 清理所有停止的容器、未使用的网络、构建缓存和悬空镜像。
`docker volume prune`： 清理未使用的数据卷。
2. 设置存储驱动限制：在Docker配置中限制日志驱动（json-file）的单容器日志大小和数量。

案例三：用户或应用缓存爆炸
症状： `/home` 目录或 `/tmp`，或类似 `/cache` 的应用目录占用高。
根治： 1. 清理用户家目录下的 `.cache` 等目录。 2. 使用 `tmpreaper` 等工具定期清理 `/tmp` 目录。 3. 为缓存应用（如Redis RDB/AOF， Squid）设置合理的磁盘使用策略和过期时间。

五、进阶技巧：找出被删除但未释放空间的文件

你是否遇到过 `df` 显示空间已满，但 `du` 统计各目录总和大大小于已用空间？这极有可能是由于文件被删除后，仍有进程在打开它，导致磁盘空间未被释放。这种文件在目录中不可见，却仍占用着空间。

诊断方法：
使用 `lsof | grep deleted` 命令。该命令会列出所有已被删除（deleted状态）但仍被进程打开的文件句柄。输出中会显示进程PID和文件路径。解决方案通常是重启持有该文件句柄的进程。在鳄鱼Java处理的案例中，一个Java应用因未正确关闭日志文件流，导致数十GB的已删除日志文件空间无法回收，重启应用后空间立即释放。

六、建立体系：从被动清理到主动监控

优秀的运维不是救火，而是防火。将Linux df -h查看磁盘空间占用纳入常态化监控体系至关重要。

1. 配置监控报警： 使用Zabbix、Prometheus（配合node_exporter）等监控工具，对关键挂载点的使用率和inode使用率设置阈值报警（如>85%预警，>95%紧急）。

2. 定期执行健康脚本： 编写一个简单的Shell脚本，定期（如每天）通过cron运行，收集 `df -h` 和 `df -i` 的输出，并发送报告或对超过阈值的分区进行预警。鳄鱼Java的运维团队就维护着一套这样的内部健康检查套件。

3. 容量规划： 定期回顾磁盘使用增长趋势，预测未来数月何时会达到容量上限，并提前进行扩容或数据归档方案规划。

总结与思考

掌握Linux df -h查看磁盘空间占用的完整技能树，意味着你拥有了从“症状感知”到“根因定位”再到“问题根治”的系统化能力。这远不止于记住一个命令，而是构建一套以 `df` 为起点，串联 `du`、`lsof`、`logrotate` 等工具，并最终融入监控体系的完整方法论。

现在，请立刻连接到你的服务器，执行一次 `df -h` 和 `df -i`：你的根分区还剩多少空间？哪个目录是最大的潜在风险点？是否有陈旧的Docker镜像或日志文件可以立即清理？磁盘空间管理如同家居整理，定期维护方能长治久安。希望这篇文章能成为你案头实用的指南。如果你在实践中遇到了更为棘手的磁盘空间谜题，欢迎到鳄鱼Java社区分享你的案例，我们一起探讨更精妙的解决方案。