最常见原因是已删除但仍在被进程占用的文件，此时df计入空间而du无法统计；其他原因包括挂载覆盖、ext4预留5%空间、inode耗尽、快照或稀疏文件等。
磁盘空间满不是“删几个文件”就能解决的事，关键得先搞清空间到底被谁占了、为什么删了还不释放。
df -h 显示 95% 但 du 统计不到对应大小？查已删除但未释放的文件
这是最常被忽略的坑：文件被 rm 了，但还有进程在往它写日志，文件描述符没关，磁盘块就一直被占着。此时 df 和 du 结果严重不符（比如 df 说用了 40G，du -sh /* 加起来才 8G）。
- 用
lsof +L1直接列出所有已删除但仍有进程打开的文件，重点关注deleted标记那一列 - 常见罪魁是
nohup.out、app.log、docker/containers/*/json.log - 释放方式只有两种：
kill -USR1 <pid></pid>（如果进程支持重载日志）、或直接重启对应服务；truncate -s 0对这类文件无效
日志目录（/var/log）暴涨？别直接 rm，优先用 truncate 或 journalctl
直接 rm /var/log/syslog 可能导致 syslogd 崩溃或日志丢失，尤其当服务还在持续写入时。
- 对正在写的普通日志（如
/var/log/nginx/access.log）：用truncate -s 0 /path/to/log，清空内容但保留文件和 inode，进程无需重启 - 对 systemd 日志：用
journalctl --vacuum-size=200M或journalctl --vacuum-time=2weeks，安全可控 - 对已配置
logrotate的应用：手动触发logrotate -f /etc/logrotate.d/myapp，让它按规则切分归档 - 确认无进程占用后，再用
find /var/log -name "*.gz" -mtime +30 -delete清理旧压缩包
df -i 显示 100%？inode 耗尽比空间满更隐蔽
No space left on device 错误不一定代表磁盘满了——可能是 inode 用光了。常见于大量小文件场景（如临时缓存、容器 overlay、邮件队列）。
- 运行
df -i，看IUse%列是否接近或等于 100% - 定位高 inode 占用目录：
find /var -xdev -type f | cut -d/ -f 1-3 | sort | uniq -c | sort -n - 重点检查：
/var/lib/docker/overlay2（Docker）、/var/spool/postfix（邮件）、/tmp下残留的 session 文件 - 清理时注意：
rm -rf大量小文件极慢，可用find /path -type f -delete或rsync -a --delete-empty-dirs /dev/null/ /path/
ext4 预留 5% 空间不显示在 df Available 里？tune2fs 可调但慎用
根分区显示 “Used 95%、Avail 1.2G”，但实际总容量减去 Used 还剩更多——那部分就是 ext4 默认给 root 预留的 5%，防止系统彻底卡死。
- 查看当前预留比例：
tune2fs -l /dev/sda1 | grep "Reserved block count" - 临时释放（仅应急）：
tune2fs -m 1 /dev/sda1（改为预留 1%），但别设为 0，否则某些关键服务（如 MySQL）可能无法写入 - 这招不能替代真正清理，只是争取几小时缓冲时间；恢复默认用
tune2fs -m 5 /dev/sda1
真正麻烦的从来不是“怎么删”，而是“删完空间还不回来”——要么文件被进程锁着，要么 inode 耗尽，要么你删的是挂载点下的文件但实际数据在另一块盘上。动手前，先跑一遍 df -h 和 df -i，再决定下一步敲什么命令。
