空间没满，为什么还是写不进去
Linux 服务器上遇到“磁盘还有几十 GB，却提示 No space left on device”，很多人第一反应是分区统计不准，或者程序把空间吃光了。实际上，磁盘能不能继续写入，不只取决于容量，还取决于 inode 是否足够。
inode 可以理解为文件系统给每个文件准备的“编号和档案”。一个普通文件、一个目录、一个软链接，通常都会占用 inode。容量统计的是数据块还剩多少，inode 统计的是还能创建多少个文件对象。只要 inode 用完，即使磁盘空间还有余量，新文件也可能创建失败。
小文件太多最容易把 inode 吃光
inode 用尽常见于缓存目录、会话目录、邮件队列、临时上传目录、日志切片目录，以及某些程序生成大量缩略图或碎片文件的场景。单个文件可能只有几 KB，容量看起来不大，但文件数量一旦达到几十万、几百万，inode 就会先撑不住。
排查时不要只看 df -h，还要看 df -i。前者看容量，后者看 inode 使用率。如果某个分区 inode 使用率已经接近 100%，问题方向就很清楚：不是继续扩几 GB 空间就能解决，而是要处理文件数量。
先定位目录，再处理来源
发现 inode 紧张后，可以从挂载点开始逐层统计目录中文件数量，例如用 find /path -xdev -type f | wc -l 粗略判断，也可以配合 du --inodes 查看哪些目录 inode 占用高。生产环境不要一上来全盘扫描，尤其是业务高峰期，应该先锁定可疑目录，分批、限速地查。
清理时同样要谨慎。缓存文件、过期 session、旧日志、临时上传残留通常可以按时间规则清理；但数据库目录、程序运行目录、用户上传目录不能看到文件多就直接删。更稳妥的做法是先备份关键路径，确认文件用途，再制定清理规则。
避免再次发生，比临时清理更重要
inode 问题经常不是一次性故障，而是业务习惯长期积累的结果。比如日志只切割不压缩、缓存没有过期策略、上传失败文件没有回收、程序把每个小任务都落成单独文件，都会让 inode 使用率持续上升。
如果是网站或业务系统部署在云服务器上，建议把容量、inode、日志目录文件数一起纳入监控。像 速维云云服务器 这类按业务场景交付的环境，在上线前就应该确认分区规划、日志路径和备份策略，避免根分区同时承载系统、日志、缓存和上传文件。
什么时候需要调整文件系统或架构
如果业务天然会产生海量小文件，例如图片缩略图、对象缓存、邮件存储、采集任务结果，就不能只靠定期删除。需要考虑把数据放到独立分区、对象存储或专门的存储服务中，避免根分区被拖垮。
某些文件系统在创建时 inode 数量就基本确定，后期不一定能随意调整。新业务上线前，如果能预估文件数量远高于单文件体积，就要在格式化参数、分区规划和存储方案上提前设计。否则等线上 inode 打满，再迁移数据和重建文件系统，成本会高很多。
排查口诀
遇到“还有空间却写不了文件”，可以按这个顺序排查：先看报错路径属于哪个分区，再看 df -h 和 df -i，接着定位文件数量异常的目录，最后处理产生大量小文件的程序逻辑。容量、inode、文件数量三件事一起看，才能避免只治表面。
