“No space left on device”错误需先区分是磁盘块（df -h）耗尽还是inode（df -i）耗尽：前者查大文件用du定位清理，后者查海量小文件用find统计并针对性删除；优先执行低风险操作如清空/tmp、截断日志、清理Docker缓存，并建立定时监控与日志轮转预防机制。
磁盘满导致的写入错误（No space left on device）不是“能不能删文件”的问题，而是“删了是否真释放、删哪里最安全、删完会不会引发新故障”的系统性响应。关键在于分层定位、最小干预、留痕可逆。
先确认是块空间还是 inode 耗尽
两者表现一样，但处理逻辑完全不同：
-
块空间满：用
df -h查看Use%接近 100% 的挂载点；再用du -sh /* 2>/dev/null | sort -rh | head -10快速定位大目录 -
inode 满：用
df -i查看IUse%是否爆满；若满，说明有海量小文件（如日志碎片、session 缓存、容器临时层），执行find /var/log -type f | wc -l或find /tmp -maxdepth 2 -type f | wc -l验证
别急着 rm -rf，先止血再诊断
根分区写满时，很多命令会因无法创建临时文件而失败。优先执行低开销、高确定性的操作：
- 清空
/tmp（多数系统重启后自动重建）：sudo rm -rf /tmp/* - 轮转并截断活跃日志（不删文件，释放空间）：
sudo truncate -s 0 /var/log/syslog或sudo journalctl --vacuum-size=100M - 临时释放缓存（仅内存缓存，不影响数据）：
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches - 检查是否有被删除但未关闭的大文件（占用空间未释放）：
sudo lsof +L1，找到后用kill -HUP或重启对应进程
针对性清理常见“空间黑洞”
90% 的磁盘满来自这几类路径，按风险从低到高操作：
-
/var/log/：查
.log、.gz、.old文件，用logrotate配置或手动清理旧归档 -
/var/lib/docker/：Docker 环境重点排查，运行
docker system df -v，清理悬空镜像、构建缓存、未使用卷：docker system prune -a --volumes -
/home/*/Downloads、/root/.cache：用户级缓存和下载堆积，可批量清理：
find /home -name Downloads -type d -exec du -sh {} \; 2>/dev/null | sort -hr | head -5 -
/var/cache/apt/（Debian/Ubuntu）或
/var/cache/yum/（RHEL/CentOS）：用apt clean或yum clean all清理包缓存
长期可用的预防机制
救火不如设防。建议落地三项低成本动作：
- 每天定时检查：
df -h | awk '$5 > 85 {print "ALERT: " $1 " is " $5 " full"}'加入 cron - 对日志启用自动轮转与压缩：
sudo nano /etc/logrotate.d/myapp，配置size 100M+rotate 5+compress - 为关键服务（如数据库、消息队列）单独挂载磁盘，并限制其日志目录配额（
setquota或prjquota）
