根分区空间告警但du统计偏小，主因是inode耗尽、已删未释放文件、挂载点遮挡或系统预留空间；需按df→df -i→sudo du→lsof +L1→mount顺序排查。
磁盘空间告警了，df -h 显示根分区 99%，但 du -sh /* 加起来才 60G？别急着删文件——问题很可能不在“看得见”的地方。真正卡住空间的，往往是隐藏行为、残留句柄或系统保留策略。
先看真实占用，别被表象骗
运行 df -h 确认哪个挂载点爆满，重点关注 Use% 列。但注意两点：
- 如果 df -i 显示 IUse% 接近 100%，说明是 inode 耗尽，不是空间不够——大量小文件（如日志碎片、session 文件）占满了索引节点，du 统计不出实际压力；
- df 显示的 Used + Avail < Size 是正常现象：ext4 默认为 root 预留 5% 空间（紧急保底），可通过 tune2fs -m 1 /dev/sda1 调低，不建议清零；
- 某些云盘或 LVM 卷可能有配额限制或 thin-provisioning 延迟释放，需结合 lvs、lvdisplay 或厂商控制台确认。
找大目录要带权限和过滤
直接在 / 下跑 du -sh * 很容易失败——大量 Permission denied 会掩盖真实结果，也跳过隐藏目录：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 用 sudo du -shx --max-depth=1 / 2>/dev/null | sort -hr：-x 防跨文件系统，2>/dev/null 屏蔽报错，结果才可信；
- 别漏掉 /var、/home、/opt、/usr/local 这些常驻大户，尤其 /var/log 和 /var/lib/docker；
- 加个 du -ah . | grep -E "^\s*[0-9.]+[TG]" 快速筛出 G/T 级文件，比纯排序更直给。
大文件≠可见文件，已删未释放最坑人
这是新手最常踩的坑：rm 删除了一个 20G 日志，df 却没变化。原因很常见：
- 进程仍在写该文件（比如 tail -f 或服务未重启），内核保留其 inode 和块指针，空间不回收；
- 用 lsof +L1 直接列出所有已删除但被打开的文件，输出里带 deleted 字样就是元凶；
- 对应处理：重启相关服务（如 nginx、java 应用、rsyslog），或用 echo > /proc/PID/fd/N 清空句柄（慎用，需确认业务影响）。
别忽略挂载点“遮挡”和缓存假象
有些空间“消失”是因为路径被覆盖了：
- 检查 mount | grep "^/dev"，确认关键目录（如 /data、/mnt）是否真的挂载成功；
- 若曾挂载过新盘到 /tmp，后来卸载了，但 /tmp 原有文件还在，此时 du 会统计它们，而 df 不计入——先 umount /tmp，再 du -sh /tmp 看原始大小；
- 包管理器缓存（apt/yum/dnf）、journald 日志、Docker 构建缓存都可能静默膨胀，用 journalctl --disk-usage、docker system df、apt clean 分别验证。
基本上就这些。排查顺序建议固定：df → df -i → sudo du -shx --max-depth=1 / 2>/dev/null → lsof +L1 → 检查 mount 和服务状态。不复杂但容易忽略细节。
