如何在Linux中查看磁盘挂载点当前的Inode占用 Linux清理琐碎小文件的方法-LINUX-PHP中文网

df -i 可直接查看各挂载点 inode 占用率，iuse% 达 100% 即确认 inode 耗尽，此时即使磁盘空间充足也无法创建文件，需重点检查 /、/var、/home 等业务分区。

如何在linux中查看磁盘挂载点当前的inode占用 linux清理琐碎小文件的方法

执行 df -i 是最快速、最权威的方式，它会列出所有已挂载文件系统当前的 inode 总数、已用数、空闲数和使用百分比（IUse% 列）。只要某挂载点的 IUse% 接近或等于 100%，就说明 inode 耗尽，哪怕 df -h 显示磁盘空间还很充裕，也无法创建新文件。

常见误判点：

df -i 默认统计所有挂载点，包括 tmpfs、devtmpfs 等内存文件系统，它们的 inode 使用率高是正常的，重点盯住根分区（/）、/var、/home 这类实际存储业务数据的挂载点
如果只关心某个路径，比如 /var/log，直接运行 df -i /var/log —— 它会自动定位到该路径所在的真实挂载点，不是查目录本身
某些旧版系统或容器环境里，df -i 可能不显示 IUse% 列（尤其在 ext2 或某些精简镜像中），此时可配合 stat -f / 查看 Inodes: 和 Inodes Free: 字段手动计算

想确认某个目录下到底有多少文件（含隐藏文件），最直觉的做法是 ls -a | wc -l。但它在文件数超 10 万后极易失败：内存耗尽、命令卡死、甚至直接报 ls: memory exhausted。

真正可行的替代方案：

提供端到端的高端代理设置和使用指导，包括代理类型选择、地区定向、访问配置、API密钥验证和监控。

下载

用 find /path -maxdepth 1 -type f | wc -l 绕过 ls 的排序开销，适合几十万级文件
对超大规模目录（如几百万小文件），优先用 find /path -maxdepth 1 -type f -print0 | xargs -0 -n 10000 echo | wc -l 分批处理，避免参数列表溢出
别依赖 ls -i 查数量——它只是显示每个文件的 inode 号，不统计；且当 inode 耗尽时，ls 本身可能连目录都进不去

面对数十万甚至上百万个几 KB 的小文件（比如日志碎片、临时上传残留），直接 rm -rf * 极大概率导致 shell 崩溃或卡死：shell 会先展开通配符生成超长参数列表，内核拒绝执行或耗尽内存。

安全高效的清理路径：

用 find /path -type f -delete —— 删除动作由 find 自身逐个发起，不依赖 shell 展开，内存友好
加时间条件更稳妥：find /path -type f -mtime +30 -delete，只删 30 天前的，避免误伤活跃文件
若需保留目录结构只清空内容，用 find /path -mindepth 1 -delete（注意 -mindepth 1 防止删掉父目录）
极端情况（inode 已满到 find 都报错），先用 echo * | xargs -n 1000 rm -f 分批删，但必须确保当前目录下没有空格或特殊字符的文件名，否则会出错

当 IUse% 达到 100%，文件系统已无法分配新 inode，此时即使执行 rm，也可能返回 No space left on device —— 不是因为磁盘块满了，而是没 inode 可写入目录项了。

这时的关键动作不是硬删，而是释放已有 inode：

检查是否有进程仍在占用已被删除的文件：lsof +L1 或 lsof | grep deleted，找到对应 PID 后重启服务（如 nginx、java 应用），让内核真正回收 inode
临时扩容不现实：ext4/xfs 文件系统的 inode 总数在格式化时固定，无法在线增加；只能迁移数据重建文件系统
后续预防比抢救更重要：监控脚本里必须包含 df -i 检查，尤其对 /var/spool、/tmp、/var/log 这类易堆积小文件的路径设低阈值告警（比如 >85% 就触发）