linux无内置“磁盘存储池增长预警表”，需用df -h监控各挂载点use%（≥85%预警、≥90%紧急处理），du -sh结合sort -hr定位大目录，配合历史快照与df -i检查inode耗尽风险，构建可落地的预警链路。
Linux没有内置的“磁盘存储池增长预警表”
Linux本身不提供预置的、带时间序列预测功能的“增长预警表”。所谓“预警表”，其实是运维人员基于 df、du 和历史数据人工构建或脚本生成的判断依据，不是系统自带的配置项或命令输出。
怎么用 df 和 du 搭建基础预警逻辑
真正能落地的预警，靠的是组合命令 + 定期采集 + 阈值比对。关键不是找一张表，而是建立可复用的检查链路：
-
df -h看各挂载点当前使用率，重点关注Use%列 —— 超过85%就该介入，90%必须处理 -
du -sh /var/log/* 2>/dev/null | sort -hr | head -5快速定位日志目录中哪些子目录最占空间（比如nginx、mysql、journal） - 对重点路径做周期性快照：比如每天凌晨跑一次
df -P | awk '{print $5,$1}' | grep '%' | grep -v Use%，把结果追加到/var/log/disk-usage.log，就能形成简易增长趋势 - 注意
df和du结果不一致时，大概率是被删除但进程仍持有句柄的大文件 —— 用lsof +L1或lsof | grep deleted找出它们
为什么不能只看单次 df 输出就判断“要扩容”
很多误判来自忽略增长模式。同一块磁盘在不同场景下行为差异极大：
- 日志类路径（如
/var/log）可能每周暴涨 5GB，但 logrotate 正常后会回落 —— 这是假性增长，清理即可 - 数据库数据目录（如
/var/lib/mysql）如果连续 3 天每天涨 2GB 且无回落，才是真正需要扩容的信号 - LVM 卷组（
vgs输出）剩余空间低于10%时，即使df显示还有 20% 可用，也意味着无法再lvextend—— 这个细节常被跳过
容易被忽略的 inode 预警点
磁盘 block 没满但写不了文件？df -i 必须和 df -h 一起看。特别是以下路径：
-
/var/spool/postfix（邮件队列积压小文件） -
/var/lib/docker/overlay2（容器镜像层产生海量小文件） -
/tmp下大量临时 session 文件未清理
一旦 df -i 显示某挂载点 IUse% 超过 90%，touch 都会失败，但 df -h 完全看不出异常。
