“no space left on device”报错未必是磁盘空间耗尽，更可能是inode耗尽、大文件持续写入或已删除文件未释放所致；需依次执行df -h与df -i判断资源类型，用lsof +l1和iotop定位异常进程，再通过find和du扫描高危目录，最后验证并安全清理。
遇到“No space left on device”报错，说明磁盘已无法写入新数据。但问题不一定是“真没空间”，更可能是大文件正在持续写入、占满配额或触发了隐藏限制。排查要分三步走：先确认是空间满还是 inode 满，再定位谁在疯狂写，最后看是否已被删却未释放。
第一步：区分是容量耗尽，还是 inode 耗尽
运行两个命令，一眼判别类型：
-
df -h：看 Use% 是否达 100%，重点关注报错路径所在挂载点（如
/或/var）； -
df -i：看 IUse% 是否接近或等于 100% —— 若此处爆满，而
df -h显示还有空间，说明是海量小文件（如日志轮转碎片、邮件队列、Docker overlay 文件）吃光了 inode，删大文件无效，得清小文件。
第二步：锁定正在写入的大文件或进程
很多场景下，不是“已有大文件”，而是某个进程正把数据源源不断灌进一个文件（比如未限速的 dump、失控的日志、卡住的备份脚本）。这时需动态抓取：
- 用 lsof +L1 找“已删除但仍在写”的文件（常见于被 rm 掉的 access.log、binlog 等，进程还持着句柄往里写）；
- 用 lsof -w /path/to/mount | awk '$5 ~ /[uw]/ {print $0}' 列出所有对目标挂载点有写权限（
u= read/write,w= write-only）的打开文件，重点关注 size 增长快的项； - 结合 pidstat -d 1 或 iotop -o 实时观察哪些进程 IO 写入量异常高，再查其打开的文件：
ls -lh /proc/<pid>/fd/ | grep '->' | head -5</pid>。
第三步：快速定位静态大文件（尤其刚写入的）
若确认是新生成的大文件占满空间，优先查最近修改、体积突出的文件：
- 查过去 24 小时内大于 100MB 的文件：
find / -xdev -type f -mtime -1 -size +100M 2>/dev/null -exec ls -lh {} \;； - 重点扫描高危目录：
/var/log（应用/数据库日志）、/tmp和/var/tmp（临时输出）、/var/lib/mysql（binlog、ib_logfile、大表 .ibd）、/var/lib/postgresql/*/main/pg_wal（WAL 积压）； - 用
du -sh --max-depth=1 /var/* 2>/dev/null | sort -hr | head -5快速看出哪个子目录突然膨胀。
第四步：验证并安全处置
找到目标后别急着删。先确认：
- 该文件是否被关键进程占用（
lsof /path/to/file）； - 是否属于数据库事务日志或 WAL —— 直接删除可能引发主从不一致或崩溃；
- 能否用清空代替删除（
> /path/to/file），避免中断写入进程； - 是否应启用 logrotate、binlog_expire_days、pg_archivecleanup 等自动清理机制，防止复发。
