问题现象
有些 Linux 服务器故障看起来很反直觉：业务程序提示无法写入文件，上传目录报错，日志突然停止增长，甚至 WordPress、PHP、MySQL 临时文件都开始异常；可执行 df -h 一看，磁盘空间明明还剩不少。这时不要只盯着容量，很可能是 inode 已经用完了。
inode 可以理解为文件系统用来记录“一个文件是谁、在哪里、权限是什么”的索引节点。每创建一个普通文件、目录、符号链接，通常都会占用一个 inode。磁盘容量决定能放多少数据，inode 数量则决定能创建多少个文件。小文件特别多时，容量可能只用了一小部分，inode 却已经耗尽。
先看 inode
排查第一步是同时查看容量和 inode，而不是只运行一个命令。容量使用情况看 df -h，inode 使用情况看 df -i。如果某个挂载点的 IUse% 接近或达到 100%，即使 Use% 还不高，也会出现无法新建文件的问题。
常见命令如下：df -h 用来看各分区剩余容量；df -i 用来看 inode 总数、已用数量和剩余数量。重点关注业务目录所在的挂载点，例如网站根目录、日志目录、缓存目录、上传目录所在分区。
为什么会耗尽
inode 耗尽最常见的原因不是大文件，而是大量小文件。比如 PHP Session 文件长期不清理、缓存插件生成海量缓存、图片缩略图目录失控、邮件队列堆积、临时目录没有轮转、爬虫或错误程序不断生成碎片文件。这类文件单个可能只有几 KB，却每个都要占一个 inode。
网站场景里尤其容易出现在 /tmp、/var/tmp、/var/cache、/var/lib/php/sessions、站点缓存目录、日志归档目录和上传缩略图目录。排查时可以从挂载点往下统计文件数量，例如使用 find /path -xdev -type f | wc -l 粗略估算文件数，再逐层定位异常目录。
定位目录
如果知道是哪块分区 inode 爆了，可以用分层统计的方法找出文件数量异常的目录。常用思路是先进入挂载点根目录，统计一级子目录文件数量，再进入数量最高的目录继续细分。这样比盲目删除文件安全得多。
示例命令可以是：for d in /var/*; do echo "$d $(find "$d" -xdev -type f 2>/dev/null | wc -l)"; done | sort -k2 -n。生产环境中文件很多时，这类命令可能较慢，建议在低峰期执行，或先缩小范围到明显可疑的目录。
处理方式
找到异常目录后，先判断文件是否可以删除，而不是直接清空。缓存文件通常可以按应用规则清理；过期 Session 可以按时间删除；日志应先确认是否已经归档或不再需要。删除大量文件时不要用会展开巨量参数的命令，例如 rm *，可以使用 find /path -type f -mtime +7 -delete 这类按条件处理的方式。
如果是业务程序持续制造小文件，只清理一次不能解决根因。需要检查缓存策略、日志轮转、队列消费、上传缩略图规则和定时清理任务。对于中小网站，速维云的 香港云服务器 或 美国云服务器 在部署站点时，也建议把日志轮转、缓存清理和监控一起规划好，避免问题积累到业务不可写才发现。
预防建议
预防 inode 耗尽，核心是让“文件数量”也进入日常监控。除了磁盘容量告警，还应定期检查 df -i，对 Session、缓存、临时文件、队列目录设置合理清理周期。日志系统要启用轮转，避免大量碎片化小日志长期堆在同一分区。
新建文件系统时也要考虑业务类型。如果是海量小文件业务，默认 inode 密度可能不够，需要在规划阶段选择更合适的文件系统参数，或把对象存储、数据库、缓存目录拆分出来。对普通网站来说，提前做好目录分区、自动清理和告警，通常就能避免大多数 inode 故障。
