当df -h显示磁盘空间充足但报“No space left on device”时，大概率是inode耗尽所致；需用df -i查Use%，结合du --inodes定位高密度目录，通过文件时间戳、命名规律和进程追踪识别异常源，并建立自动化监控哨兵实现四步闭环防御。
当系统突然报“No space left on device”，而 df -h 显示磁盘空间仍有富余，大概率是遭遇了“小文件炸弹”——大量短生命周期或失控生成的小文件迅速耗尽 inode，导致新建文件、日志写入、服务启动全部失败。识别它不靠猜，而靠分层监测和特征抓取。
盯紧 df -i 的 Use% 阈值
这是第一道防线。执行 df -i，重点看 IUse% 列：
- ≥85%：触发预警，需人工介入排查
- ≥90%：高风险，部分应用可能已出现创建失败
- 100%：确认爆炸发生，
touch test会直接报错
注意：不要只查根分区。Web 上传目录、容器存储路径（如 /var/lib/docker/overlay2）、监控指标落盘路径（如 /var/lib/node_exporter/textfile_collector/）常被单独挂载，必须逐个 df -i /mount/point 检查。
用 du --inodes 快速定位“文件密度中心”
inode 爆炸不是均匀分布的，而是集中在几个“重灾区”。比 find ... | wc -l 更高效的是：
NodeMaven – Premium Proxies for Account Management, Automation, and Scraping
下载
提供端到端的高端代理设置和使用指导，包括代理类型选择、地区定向、访问配置、API密钥验证和监控。
-
du --inodes -s /var/* 2>/dev/null | sort -nr | head -10—— 查看/var下各子目录的 inode 占用总量 -
du --inodes -S /tmp | sort -nr | head -5——-S排除子目录汇总，只看当前层直系目录，适合发现临时文件堆积点 - 对可疑目录进一步下钻：
du --inodes -s /var/log/nginx/* | sort -nr | head -3
典型高密度目录包括：/var/lib/php/sessions、/var/spool/postfix/maildrop、/var/tmp/systemd-private-*、未配置 maxage 的 logrotate 日志归档目录。
结合时间与命名模式识别异常生成源
单纯统计数量不够，要判断是否“失控”。进入高 inode 目录后运行：
-
ls -lt | head -5和ls -t | tail -5—— 看最新/最老文件的时间戳是否密集趋同（例如全是 2 分钟内创建），说明有脚本或服务在高频刷写 -
ls | head -10 | xargs -I{} basename {}—— 观察文件名是否有规律（如sess_abc123、metric_20260427_182000.prom、temp_1234567890.dat），可反向锁定生成程序 -
ps aux --forest | grep -E "(php|python|java|node)"+lsof -p PID | grep /path/to/suspicious/dir—— 查哪个进程正在往该目录持续写入
设置自动化哨兵，早于爆炸前预警
依赖人工巡检容易滞后。建议在监控系统中固化以下检查项：
- Zabbix 或 Prometheus 中部署采集脚本，每 5 分钟执行：
df -i | awk '$5 ~ /%/ {sub(/%/,"",$5); if($5 > 80) print $1,$5}' - 对关键路径（如
/tmp、/var/tmp、/data/upload）每日凌晨跑一次：du --inodes -s /tmp | awk '$1 > 500000 {print "ALERT: /tmp inode count "$1}' - 在 crontab 加入检测任务，发现连续 3 次
du --inodes -s /var/log | awk '{if($1>200000)exit 1}'就发钉钉告警
真正的防御不在爆炸后删文件，而在爆炸前掐断源头。盯住 inode 使用率、定位密度中心、识别生成节奏、固化自动哨兵——四步闭环，小文件炸弹就再难偷袭成功。
