inode耗尽时touch报“no space left on device”是因文件系统inode用完而非磁盘空间不足；用df -i查看use%定位热点，重点关注/var、/tmp等小文件密集区，超92%需预警清理。
inode 耗尽时 touch 报错 No space left on device 怎么快速定位
磁盘明明还有大量空间，touch 却报 “No space left on device”，八成是 inode 耗尽了。linux 文件系统为每个文件/目录分配一个 inode，不看数据大小，只看数量上限。
实操建议：
- 用
df -i查看各挂载点的 inode 使用率，重点关注Use%列 —— 超过 95% 就得立刻处理 -
df -i /home比df -i全局扫描更快，尤其当系统有多个挂载点时 - 别只盯着
/，/var（日志、容器层）、/tmp（临时文件暴增）才是 inode 热点区 - 某些 XFS 文件系统默认 inode 数量固定，创建时没预留足够余量，后期无法动态扩容
小文件密集场景下如何预防 inode 不足
邮件队列、日志轮转、监控采集、容器 overlayfs 层都会生成海量小文件，这是 inode 消耗主力。
实操建议：
- 应用层做归档：比如把
/var/log/nginx/*.log按天压缩后删除原始文本，减少单个目录下文件数 - 用
find /path -type f -mtime +7 -delete定期清理旧小文件，避免rm -rf误伤或卡住 - 新建 ext4 文件系统时加
-i 4096（每 4KB 数据配 1 个 inode），比默认的 16KB 更抗小文件 —— 但会略微增加元数据开销 - 对
/var/spool/postfix这类已知高 inode 压力目录，可单独挂载并调大mkfs.ext4 -N指定 inode 总数
ls -li 和 stat 查 inode 号时为什么结果不一致
同一个文件在不同命令里显示的 inode 号不同？不是 bug，是硬链接、挂载点或 bind mount 导致的视图差异。
实操建议：
-
ls -li显示的是当前路径下该文件名指向的 inode 号，如果存在硬链接，多个路径可能指向同一 inode -
stat /path/file显示的是该路径解析后的实际 inode，更权威；但若路径跨 bind mount 或 overlayfs，stat仍可能返回上层视图的 inode - 真正要确认是否同一文件，用
stat -c "%d:%i" /path/a /path/b对比dev:inode对 —— 设备号（%d）必须相同才有可比性 - 容器内看到的 inode 号通常和宿主机不一致，因为 overlayfs 在 upperdir 中重新映射了 inode，此时不能直接用 inode 号做跨环境追踪
监控脚本里怎么安全判断 inode 预警阈值
写自动化监控时，不能只看 df -i 的 Use%，它在某些场景下会失真。
实操建议：
- 避开
df -i | awk '//$/ {print $5}' | sed 's/%$//'这种脆弱解析 —— 字段顺序受 locale 影响，df -i --output=source,pcent,target更稳 - ext4 下，
Reserved block count也占用 inode 配额（虽不计入df -i的Used），但 root 用户仍可写入，所以预警阈值建议设为 92% 而非 95% - 对 NFS 挂载点，
df -i可能返回?或超时，需加超时控制：timeout 5 df -i /mnt/nfs 2>/dev/NULL - 监控项应同时采集
Inodes（总数）、IUsed（已用）、IFree（空闲），三者相加不等于总数说明有异常（如 XFS 的 finobt 启用时统计逻辑不同）
inode 不是“看不见的空间”，但它比磁盘空间更难感知 —— 没有明显增长趋势，却会在某个 creat() 系统调用时突然失败。最危险的是那些每天新增几千个临时文件、但从不清理的服务，它们不会报警，只会悄悄让新进程启动失败。