磁盘空间告警常因inode耗尽、隐藏文件、已删除但未释放文件、深层大目录、预留空间或挂载覆盖导致，并非真满；应先用df -h和df -i排查，再结合lsof +L1、ncdu及tune2fs等工具精准定位。
磁盘空间告警不等于“真满了”，很多情况下是表象和实际不一致。排查关键不是盲目删文件，而是分清“谁占了、为什么没释放、是不是看错了”。下面几个环节最常出错，也是新手最容易反复踩坑的地方。
只看df，不查inode
磁盘显示已用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了，但进程还在写（比如tail -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快得多。