Linux 磁盘满了先查什么：df/du/journalctl 三步定位

磁盘满了，先别急着删文件。很多故障不是空间真的被业务数据占满，而是日志失控、已删除文件仍被进程占用，或者某个挂载点被误判。按下面三步走，通常十分钟就能定位到真正的元凶。

第一步：用 df 确认是哪块盘、哪个挂载点满了。先看整体：df -h。重点看 Use% 接近 100% 的那一行，以及它对应的 Mounted on。很多人只看根目录，却忽略了 /var、/var/log、/data 或 /home 可能是独立挂载的分区，根目录有空间不代表日志分区有空间。再用 df -i 看一眼 inode：文件数量太多时，磁盘还有空间也写不进文件，表现为 No space left on device。确认挂载点后，再进入下一步，不要在根目录盲目清理。

第二步：用 du 沿着挂载点一级一级往下找。进入出问题的挂载点，例如 cd /var，然后执行 du -sh * 2>/dev/null | sort -rh | head -20。先看一级目录谁最大，再 cd 进去重复一次，直到找到具体目录。常见的几类大户是：应用日志目录、备份目录、下载和临时目录、容器镜像与容器日志、数据库的归档与慢日志。注意两点：一是 du 会统计目录下所有文件，权限不足的目录会报错，报错不影响排序结果；二是不要一上来就 du -sh /*，根目录下可能包含 /proc、/sys 这类虚拟文件系统，虽然一般不会计入，但跨挂载点统计容易把问题看偏。定位到具体文件后，先看文件类型再决定处理方式，日志可以轮转或清理，备份要先确认保留策略，业务数据绝不能凭感觉删除。

第三步：用 journalctl 和进程占用排查“看不见”的空间。如果 du 算出来的占用明显小于 df 显示的已用空间，很可能有文件被删除但仍被进程占用。先查占用：lsof | grep deleted，或者直接看 /proc 下对应进程的 fd。处理办法是重启占用该文件的服务，或者让程序重新打开日志文件，而不是只删文件——只删文件空间不会释放。另一类常见情况是系统日志暴涨：journalctl --disk-usage 可以看到日志占用总量，journalctl -p err -b 可以查看本次启动以来的错误，journalctl --since “1 hour ago” 可以锁定最近一小时的异常。如果某个服务每秒都在报错，先修服务、停掉错误源，再清理日志，否则刚清完又会涨回去。需要长期控制时，可以通过 journald 的 SystemMaxUse 限制日志总大小，并配合 logrotate 对应用日志做按天轮转和保留天数限制。

一套实用的处理顺序是：先 df 定挂载点，再 du 定目录，最后 journalctl 和 lsof 定异常进程。清理时遵循先日志、后临时文件、再确认无用的备份的顺序，删除前用 ls -lh 确认文件大小和修改时间，重要目录先做一次备份或移动到临时位置观察一段时间。处理完后重新执行 df -h 确认空间恢复，并用 du 抽查一次，避免同一目录很快再次写满。把这三条命令记成固定流程，下次磁盘告警时就不用再凭感觉翻目录了。