inode耗尽会导致touch或mkdir报“no space left on device”错误，即使磁盘空间充足；需用df -i查看使用率，find统计小文件，清理元凶目录，并将inode使用率纳入监控。
inode 耗尽导致 touch 或 mkdir 报错 No space left on device
磁盘明明还有空间，却提示“没空间”，大概率是 inode 用完了。linux 为每个文件/目录分配一个 inode，它不占磁盘数据块，但有独立上限。一旦耗尽，哪怕空着 90% 空间也无法创建新文件。
实操建议：
- 用
df -i查看各挂载点的 inode 使用率，重点关注Use%列 —— 超过 95% 就得干预 -
find /path -xdev -type f | wc -l快速统计某目录下文件总数（注意-xdev防止跨分区） - 小文件密集场景（如日志、缓存、邮件队列）最容易触发，比如
/var/spool/postfix/maildrop堆积百万个 1KB 邮件临时文件 - 格式化时可通过
mke2fs -i 4096调整 bytes per inode 比例（默认一般 8192–16384），值越小，同样磁盘能分更多 inode，但会略微增加 inode 表开销
ext4 下 tune2fs 动态调整 inode 数量不可行
很多人想用 tune2fs 增加现有文件系统的 inode 总数，但 ext2/3/4 不支持运行时扩容 inode 表 —— 它在格式化时静态分配，之后只读。
实操建议：
-
tune2fs -l /dev/sda1可查看当前Inode count和Free inodes，但无法修改前者 - 真要扩容 inode，只能备份 →
mkfs.ext4 -N 新数量重建 → 恢复，停机不可避免 - 误操作
tune2fs -i 0（禁用检查）或-c 0不影响 inode，别混淆；真正相关的是-i（bytes per inode）仅对新建文件系统生效 - SSD 上频繁重建文件系统会加速磨损，优先考虑清理或迁移，而非重格
查找并清理海量小文件的元凶目录
inode 耗尽往往不是均匀分布，而是某个目录突然爆炸式增长，比如未轮转的日志、失败的 rsync 临时文件、容器 overlay 差分层残留。
实操建议：
-
find /var -xdev -type d -print0 | xargs -0 -n1 sh -c 'echo "$(find "$0" -maxdepth 1 -type f | wc -l) $0"' | sort -nr | head -20—— 找出子文件最多前 20 的目录 - 警惕
/tmp下以.fuse_hidden或sess_开头的文件，常是挂起进程或 PHP 会话残留 - docker 用户重点查
/var/lib/docker/overlay2/*/diff和/var/lib/docker/volumes/*/._data，docker system prune -a后仍需手动确认 - 用
debugfs -R "stat <inode>" /dev/sda1</inode>可反查某个 inode 对应路径（需先从ls -i获取 inode 号），适合定位孤立硬链接
监控与预防：避免下次再被 No space left on device 拦住
靠人工查太被动，生产环境必须把 inode 使用率纳入基础监控项，和磁盘使用率同等对待。
实操建议：
- prometheus + Node Exporter 默认暴露
node_filesystem_files_free和node_filesystem_files，配 alert rule：当(node_filesystem_files - node_filesystem_files_free) / node_filesystem_files > 0.92时告警 - 定期执行
crontab清理任务时，避免用find ... -delete直删百万级文件 —— 它单线程遍历太慢且易阻塞，改用find ... -print0 | head -zn 10000 | xargs -0 rm分批 - 应用层写文件前，可加
statfs()系统调用检查f_ffree，比等open()失败更早感知风险（glibc 封装为statvfs()） - 不要迷信 “大磁盘=高 inode 上限” —— 10TB ext4 默认 inode 数可能还不到 1 亿，而千万级小文件就能打满
inode 是隐性资源，看不见摸不着，但崩起来比磁盘满更猝不及防。最麻烦的不是怎么救，而是它总在凌晨三点、你刚合上笔记本时悄悄耗尽。