Linux 磁盘满了怎么排查？空间、inode 与已删除文件占用
网站突然无法上传、数据库报写入失败，甚至 SSH 登录异常，都可能与磁盘资源耗尽有关。看到 No space left on device 后，应先确认哪个文件系统出了问题，再决定清理、暂停写入还是扩容。本文的命令以使用 GNU 工具的常见 Linux 发行版为例，先做只读排查。
确认是容量不足，还是 inode 耗尽
df -hT
df -i
df -hT /var/lib
第一条查看已挂载文件系统的容量和类型，第二条查看 inode 使用情况，第三条示范如何查询某个业务目录所在的文件系统。根目录有剩余空间，并不代表独立挂载的数据库盘、容器数据盘或临时目录也有空间。容器内看到的路径与宿主机挂载关系还需要单独核对。
Use% 接近满而 inode 充足，优先查大文件；容量仍有剩余但 IUse% 接近满，优先查大量小文件。inode 用于记录文件信息，因此海量缓存、会话文件或邮件小文件，可能在耗尽容量之前先耗尽 inode。不同文件系统的分配机制存在差异，应按实际类型判断。GNU df 文档
如果两项都有余量但仍不能写，继续检查用户或项目配额、只读挂载、应用写入目录，以及报错是否来自另一个文件系统。不要仅因系统盘“还有几 GB”就排除存储问题，也不要将写入失败一律理解为磁盘硬件故障。
用 du 从大目录逐层往下找
假设不足的是根文件系统，可以先做一层统计：
sudo du -xhd1 / 2>/dev/null
sudo du -xhd1 /var 2>/dev/null
sudo du --inodes -x -d1 /var 2>/dev/null
-x 限制在当前文件系统内，避免把其他挂载盘一起算入。先看哪一级目录异常，再针对该目录继续细分，不必直接对整台服务器做全文件排序。--inodes 可以辅助寻找小文件密集目录。统计会产生磁盘读取压力，大型生产机应缩小范围，避开业务高峰；示例隐藏了部分读取错误，需要完整诊断时去掉错误重定向并保留结果。GNU du 文档
把大目录与应用用途对应起来：下载缓存、上传附件、数据库、历史备份、容器层和日志处理方式完全不同。备份目录突然变大，可能是远程上传失败后本地堆积；日志增长快，可能只是另一项故障不断重试的结果。只腾空间而不查增长原因，故障往往会再次出现。
df 很满，du 却对不上：查被删除但仍打开的文件
sudo lsof +L1
文件从目录删除后，如果进程仍持有打开的文件描述符，占用空间可能尚未释放。lsof +L1 可列出链接计数小于一的打开文件，结果中的进程、路径和大小有助于确认这一类占用；它需要系统安装 lsof，并具备查看相关进程的权限。lsof 官方手册
发现一个很大的已删除日志后，先确认所属服务及其官方日志重开方式。优先使用服务支持的日志轮转或重新打开日志操作；必须重启服务时，应先核对业务影响和可用维护窗口。不要直接操作 /proc 文件描述符来清空未知内容，更不要因为进程占用大就强制结束数据库。
df 与 du 不一致也可能来自文件系统元数据、保留空间、快照、挂载遮挡或统计时业务持续写入。没有发现已删除文件时，继续调查文件系统机制，不应为了让两个数字接近而盲目清理。
只处理用途与保留要求都确认过的内容
历史日志应先确认留存要求、采集状态和是否仍在写入，再用既有日志轮转方案处理。系统日志、数据库事务日志、二进制日志和应用审计记录不是同一种东西，不能使用一个通配符统一删除。数据库目录中的数据文件、恢复日志和复制所需日志，应通过数据库支持的维护流程管理。
容器环境里也要先分清镜像、构建缓存、停止的容器和持久化卷。未知数据卷可能保存数据库或用户附件，不能把广泛清理命令当作通用急救步骤。若没有可以安全清理的对象，应评估增加存储容量或把已确认的数据迁移到其他位置。
扩容前做好可恢复备份，并确认平台是否支持相应操作。磁盘容量增加后，分区、逻辑卷或文件系统未必自动扩大；这些步骤因存储结构而异，需要按实际布局执行，不能直接套用一条扩容命令。
验证恢复，并监测增长速度
完成处理后重新运行 df -hT 和 df -i，再用应用自己的测试流程验证写入、上传或数据库事务。不要只看占用百分比下降：之前写入失败可能留下队列积压、任务重试或部分生成文件，也需要检查。
最后记录释放了什么、为什么可处理、由谁确认，以及处理前后的空间。为容量和 inode 分别设置告警，并关注每小时或每天的增长速度。若空间很快再次下降，先限制产生异常数据的业务流程，再继续追查增长源。