磁盘空间满是症状而非故障本身，真正原因在于日志堆积、小文件泛滥、进程句柄未释放；需用df -h、df -i、lsof | grep deleted交叉验证真假满，并通过du和find定位增长源，再针对性清理。
磁盘空间满不是故障本身，而是症状。真正的问题藏在日志堆积、小文件泛滥、进程句柄未释放这些细节里。排查关键不是删文件，而是搞清“谁在悄悄吃空间”。
先看表象：确认是不是真满了
别急着删，先用三条命令交叉验证：
-
df -h：查哪个挂载点 Use% 到了 100%，重点关注/、/var、/data这类常用路径； -
df -i：如果 Use% 显示 inode 已 100%，哪怕df -h还剩 30% 空间，也会报No space left on device； -
lsof | grep deleted：查有没有被rm但进程还在写的老日志——这类文件du看不到，df却算占用。
再挖根源：找增长最快的地方
定位到分区后，用 du 往下钻，注意加 -x 避免跨挂载点误统计：
- 查根目录下大目录：
sudo du -xsh /* 2>/dev/null | sort -hr； - 重点盯
/var/log（Nginx、应用日志是否轮转）、/var/lib/docker（容器日志和 overlay 是否膨胀）、/tmp（临时文件是否残留）、/var/lib/mysql（binlog、慢日志是否失控）； - 找单个大文件：
sudo find / -xdev -type f -size +500M 2>/dev/null -exec ls -lh {} \; | sort -k5 -hr。
区分真假满：两个最常踩的坑
很多“满了”其实是假象：
-
inode 耗尽：常见于日志切片太碎（比如每秒生成一个 1KB 日志），
df -i显示 100%，df -h却还有空间； -
文件删了没释放：
rm后du变小但df不变，说明进程还握着句柄，得重启对应服务或用truncate -s 0安全清空。
处理要分轻重缓急
优先做安全、可逆的操作：
- 日志类：用
logrotate -f强制轮转，或journalctl --vacuum-time=7d清 systemd 日志； - 临时文件：清理
/tmp下 7 天前的文件，find /tmp -type f -mtime +7 -delete； - Docker 场景：执行
docker system prune -af --volumes，并检查/etc/docker/daemon.json是否设了日志大小限制； - 数据库：MySQL 可
PURGE BINARY LOGS，PostgreSQL 清理pg_wal归档。
不复杂但容易忽略。
