确认inode耗尽后，需依次执行：1.用df -i定位IUse%达100%的挂载点；2.用du --inodes -s /path/* | sort -nr | head -5定位高inode目录；3.用lsof +L1检查已删未释文件；4.重启服务或kill进程释放inode，并配置logrotate、tmpfs等长效防控措施。

Linux 系统中 inode 总数不足不是内核限制问题，而是文件系统创建时的静态设计约束——ext4、xfs 等主流文件系统在 mkfs 格式化阶段就固定了 inode 总数，运行时无法动态扩容。所谓“内核限制”是常见误解，真正瓶颈在文件系统层。排查重点应放在确认是否真为 inode 耗尽、定位消耗源头、验证释放效果，而非查找内核参数。

第一步：确认确实是 inode 耗尽，而非空间或权限问题

执行 df -i 查看所有挂载点的 inode 使用率：

• 若某挂载点（如 / 或 /var）的 IUse% 达到 100%，且新建空文件失败（touch /tmp/test 报 No space left on device），即可确认
• 注意：df -h 显示空间充足 ≠ inode 充足；各挂载点 inode 池完全独立，必须逐个检查
• 排除误判：确保没漏掉 /var/log/journal、/tmp、/var/spool 等高危路径

第二步：快速定位 inode 消耗大户目录

在问题挂载点下运行以下命令，按 inode 占用量降序列出前 5 个子目录：

Blender Geometry Nodes Script Generator

生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。

下载

• du --inodes -s /path/* 2>/dev/null | sort -nr | head -5
• 常见重灾区：/var/log/journal（systemd-journald 日志）、/var/spool/postfix（邮件队列）、/tmp（临时会话文件）、/var/lib/docker/overlay2（容器层）
• 若发现异常高值，进入该目录用 find . -type f | wc -l 验证文件总数

第三步：检查“已删未释”的 inode 占用

文件被 rm 后若仍有进程打开它，其 inode 不会释放：

• 运行 lsof +L1 或 lsof | grep deleted，查看处于 DEL 状态的文件及对应 PID
• 典型场景：rsyslog、dockerd、Java 应用持续写入旧日志文件；shell 重定向残留句柄（如 cat log > /tmp/out 后删 log）
• 清理方式：重启对应服务（systemctl restart rsyslog），或 kill 进程（kill -9 <pid></pid>）

第四步：验证与长期防控

清理后需确认 inode 是否真正释放：

• 再次运行 df -i，观察 IUse% 是否下降；若不变，说明还有残留占用
• 长期方案不依赖“扩容 inode”，而要控制小文件生成节奏：
  — 为 /tmp 挂 tmpfs 并设大小上限
  — 给 /var/log 配置 logrotate，启用 maxage 和 rotate
  — 容器环境定期清理 docker system prune