磁盘空间告警常因 inode 耗尽、隐藏文件、已删除但未释放文件、深层大目录、预留空间或挂载覆盖导致，并非真满；应先用 df - h 和 df - i 排查，再结合 lsof +L1、ncdu 及 tune2fs 等工具精准定位。
磁盘空间告警不等于“真满了”，很多情况下是表象和实际不一致。排查关键不是盲目删文件，而是分清“谁占了、为什么 没释放、是不是看错了”。下面几个环节最常出错，也是新手最容易反复踩坑的地方。
只看 df，不查 i node
磁盘显示已用 98%，但 du -sh /* 加起来才 60G——这大概率是 inode 耗尽了。小文件（比如日志碎片、session缓存、监控采集点）堆太多，会把 inode 用光，导致无法新建文件，即使还有几十 GB 空间也报“No space left on device”。
正确做法：
- 运行
df -i，看 IUse% 是否接近 100% - 定位高 inode 目录：
find /var -xdev -type f | cut -d "/" -f 1-4 | sort | uniq -c | sort -n - 清理目标：/var/log/journal、/var/lib/docker/overlay2/*/diff（Docker 小文件）、临时上传的未清理碎片
用 du 扫目录，却漏掉隐藏文件和已删除文件
du -sh *默认跳过以 . 开头的目录，而 /root/.cache、/var/.snapshots 这类路径可能悄悄吃掉几十 GB。更隐蔽的是：文件被 rm 了，但进程还在写（比如 t ail -f + logrotate 没生效），空间不会释放。
正确做法：
- 统计含隐藏项：
du -sh .[!.]* * 2>/dev/null | sort -hr - 查已删除但被占用的文件：
lsof +L1或lsof | grep deleted - 确认后重启对应服务（如 nginx、java 应用、rsyslog），或用
truncate -s 0安全清空日志而不中断句柄
在错误层级用 du，陷入“层层递进”陷阱
新手常从 / 开始 du -sh *，看到/var 大就进 /var 再du -sh *……结果花 20 分钟只查到第 3 层，其实大头在 /var/log/journal 或/var/lib/pgsql/data/base这种深层路径。
正确做法：
- 一步到位找大目录：
du -h --max-depth=2 / | grep '[0-9]G|[0-9]T' | sort -hr - 直接搜大文件：
find / -xdev -type f -size +500M 2>/dev/null -exec ls -lh {} ; - 装
ncdu交互式扫描：sudo ncdu /，支持键盘导航、实时排序、一键删除（慎用）
忽略保留空间和挂载覆盖问题
df -h显示 /dev/sda1 用了 45G，总容量 50G，但 du -sh / 只算出 40G——那 5G 哪去了？可能是 ext4 默认为 root 预留 5% 空间（tune2fs -l /dev/sda1 | grep "Reserved block count"可确认）。另外，如果 /mnt/data 挂载前目录里已有数据，挂载后原内容被隐藏，du扫不到，但空间仍被占着。
正确做法：
- 查预留比例：
tune2fs -l /dev/sda1 | grep "Reserved"；如需释放，sudo tune2fs -m 1 /dev/sda1 - 检查挂载覆盖：
mount | grep "on /"，再临时umount /mnt/data，进原目录du -sh确认
基本上就这些。真正卡住的，八成不是空间不够，而是“看不见的占用”+“误判的路径”。先跑 df -h && df -i，再lsof +L1 和ncdu /交叉验证，比手动一层层 cd 快得多。
